Is the Java virtual machine language agnostic? [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editi开发者_如何转开发ng this post.

Closed 9 years ago.

Improve this question

Is it safe to say that the Java virtual machine was 'originally' designed for the Java programming language, but now, other developers have been able to write programming languages that compile to Java bytecode like Scala, Jython and JRuby.

There are still 'object oriented' references in the Java bytecode like interfaces, methods, fields. For example invokespecial is a call on a 'object' method.

It is not a pure stack virtual machine with pure a language agnostic instruction set. For example, a pure FORTH implementation would only have stack operations.

The question, is the JVM language agnostic or not?

The JVM is definitely not language-agnostic, and some languages can't be implemented efficiently on it. The JVM offers no memory addressing operations, for instance, so an implementation of a lower-level language like C would be horribly inefficient. But its set of primitives is capable of supporting many popular languages with features different from Java's, given a suitably smart compiler. The languages that can be implemented decently aren't necessarily just Java with syntactic sugar; but of course the more different you get from Java, the harder it is to implement the language

In the sense that the JVM and java bytecode is turing-complete, any other turing-complete language can be transformed and compiled to java bytecode and run on the JVM. It may be horribly inefficient, but not impossible. As for the strictest possible definition of "agnostic", there is no such thing. At a hardware-level, all processors have a defined set of binary instructions they support so at some point, any language will have to be transformed to an assembly compatible with the hardware it's supposed to execute on.

EDIT: The JVM was not developed in a vacuum, it was developed in conjunction with the JAVA programming language so it stands to reason that the Java language heavily influenced the design of the Java byte-code and the JVM. So in that sense, you could say that the JVM was designed with Java in mind. But it is also true that in the architecture, the JVM was consciously de-coupled from the Java language (through the intermediate bytecode format) so there are elements in the design that takes possible alternative languages into account.

The JVM is not language-agnostic; however, it's language is JVM bytecode. Consider that the assembly of the virtual machine and then you'll have a good idea of what the JVM runs. JVM bytecode was selected to facilitate running Java programs, but like any "complete enough" assembly, it can be used for many other things. The key is what's being done in the compilation process.

Other language barriers include the design that the JVM is a stack based machine, which means explicit addresses are nonsense to the JVM in the bytecode layer. There's no "load" or "store" operations; however, that doesn't stop people who want to implement languages that do addressing on the JVM. It just makes it harder for those who want to do addressing.

To do addressing on the JVM, you basically write a simulator; where you have an object containing the "address to object handle" lookup table. This allows you to do rudimentary addressing via simulation on a virtual machine that lacks addressing. It's not always pretty, and the quality of the simulation is only typically extended to the use cases that the simulated language would permit.

Yes, you do lose a bit of performance doing Address(the object) to Map(of object to Java heap reference) to (internally in the JVM) java heap reference to physical memory address. But that's what has to be done to keep the platform agnostic. If you had direct memory access, you would eventually be pushed into coding for different hardware platforms instead of coding for the virtual machine. Well, at least you would be pushed into platform specific code much earlier than occurs these days.

Ignoring the builtin OOP instructions some languages are better suited for a register based VM (like parrot) instead of a stack based VM (like JVM).

This paper covers the issue nicely: http://db.usenix.org/events/vee05/full_papers/p153-yunhe.pdf