How does the Java Virtual Machine execute code written in other languages?

Question

Since Java 1.6 the JVM can run a myriad of programming languages on top of instead of just Java. I conceptually understand how Java is run on the Java VM, but not how other languages can run on it as well. To me, it all looks like black magic. Do you have any articles to point me to so I can better understand how this all fits together?

• Apoorv: Same way as your Intel/AMD/Solaris(??) processor can execute "any language" (although you don't really run languages, but just going with the flow here) that can be compiled into its native assembly code.
• user7043: The thing is, the JVM doesn't run Java. It runs a distinct (though related, and intentionally easy for Java compilers to create), more low-level language.
• Pomario: That is true. But the JVM started running other languages from version 6; you could not (or nobody did) run python or Groovy on it in version 1.4.2. Why is that so? What has changed?
• Apoorv: @delnan Or rather "more low-level model of execution, that the javac program knows how to build out of Java code".
• Apoorv: @Pomario Jython has been around for a while now. And this page seems to suggest that Jython scripts could run on 1.4.2.

Answer 1

The key is the native language of the JVM: the Java bytecode. Any language can be compiled into bytecode which the JVM understands - all you need for this is a compiler emitting bytecode. From then on, there is no difference from the JVM's point of view. So much so that you can take a compiled Scala, Clojure, Jython etc. class file and decompile it (using e.g. JAD) into normal looking Java source code.

You can find more details about this in the following articles / threads:

• Java virtual machine (Wikipedia)
• Why do we need other JVM languages (Stack Overflow)

I am not aware of any fundamental changes in the Java 5 or 6 JVMs which would have made it possible or easier for (code compiled from) other languages to run on it. In my understanding, the JVM 1.4 was more or less as capable in that respect as JVM 6 (there may be differences though; I am not a JVM expert). It was just that people started to develop other languages and/or bytecode compilers in the first half of the decade, and the results started to appear (and become wider known) around 2006 when Java 6 was published.

However, all these JVM versions share some limitations: the JVM is statically typed by nature, and up to release 7, did not support dynamic languages. This has changed with the introduction of invokedynamic, a new bytecode instruction which enables method invocation relying on dynamic type checking.

• Michael Borgwardt: It's not exactly true that the JVM did not "support" dynamic languages. They just had to use workarounds that had severe drawbacks.
• Péter Török: @MichaelBorgwardt, can we agree on that the JVM pre v7 tolerated dynamic languages (to some extent)? :-)
• Michael Borgwardt: That's a good way to put it :)

Answer 2

A virtual machine, like the JVM, is a program that accepts as input, usually files, a set of simple instructions (that are usually easy to convert to real CPU instructions), and actually compiles and runs them as native CPU instructions (usually using an on-demand compiler such as HotSpot or JIT).

It's essentially a layer of abstraction. It's usually much easier to port VM instruction set implementations to different processor architectures, because of several similarities (such as being stack based). It's also much easier to port different programming languages to VM instructions, since it's more oriented toward modern programming languages than the primitive CPU instructions. Many Virtual Machines such as the JVM and the CLR (.NET) contain instructions for calling virtual methods, and creating object instances.

So let's take a language for example. Call it MyLanguage. Since it is a programming language, it ultimately compiles down to a set of some CPU architecture instructions. So that means that, given a compatible, flexible Virtual Machine instruction set, it's also possible to compile MyLanguage down to a set of that VM's instructions.

There are always question of efficiency, since you might need to hack some workarounds in VM instruction sets that you wouldn't have to do natively, but it's still possible.

Answer 3

A JVM is a Turing-complete compute machine (except for limited memory), and any Turing-complete machine (physical or virtual) can execute any programming language (except for memory, performance and physical IO limitations).

• Péter Török: Erm.... why do we need compilers then? ;-)
• hotpaw2: Compilers and interpreters, themselves, can run on Turing machines (maybe slowly). Perhaps some pre-compilation/translation steps can improve the performance of running some given program in some given language?
• Péter Török: My point was that your statement "any Turing-complete machine (physical or virtual) can execute any programming language" literally means that the x86 CPU of my laptop can directly execute this nice Java source file I am working on right now. Or machine code for PowerPC processors. Without compilers - CPUs don't contain compilers right? :-)
• hotpaw2: Your "machine" is more than just the CPU.
• Yam Marcovic: @PéterTörök I see your point. He didn't elaborate on VMs like we did. But I think his answer still briefly answers the OP's question. The JVM can "run" other programming languages because it can "run" any programming language, because it is Turing complete. Not elaborate maybe, but still a concise and valid point. :)

Answer 4

For a moment just think of the JVM as a processor with its own instruction set like maybe the x86. The processor can execute say C code that has been compiled into into its machine language. Applying the same analogy to the JVM, Other languages can be executed on the JVM just like on other processors if those languages are compiled down to the machine instructions of the JVM. The JVM can then run these instructions for language X.

• cobi: your analogy is a nice one