Intepreted or Compiled?
By nitkal on Mar 02, 2008
Here are some of the commonplace jargons about Java that distinguish it from the rest of the object oriented languages...It is interepreted, It is platform independent, it is dynamically linked and extensible, it can transport the state of objects across networks, it has a robust architecture..et cetera...These are certainly some of the reasons that make Java what it is today(though some of these features have some performance trade-offs too). One important feature that is associated with the Java brand is "Intepreted, Not Compiled"
There are many good articles that elucidate the difference between interpretation and compilation . This post is but a redundant synopsis of the many discrete articles...
The technical distinction between interpretation and compilation becomes clearer if the semantic(linguistic) distinction between these types of translations is understood. Lets suppose you are given a Spanish document and you intend to translate it to English. You employ two kinds of translators for this - one an interpreter and another a compiler. The interpreter takes the first Spanish line, translates it to English, voices it aloud to you, proceeds to the next line and so on. So if there are references to a previously read paragraph or line, he does the translation again for them. A compiler on the other hand takes the entire document, translates it to English, and hands over the document to you.
Langauge compilers and interpreters are but similar. In case of Java, the java compiler compiles the java code to bytecode. The bytecode is intepreted by the JVM and yes, it is line by line interpretation. So as it is obvious, this kind of intrepretation makes Java inherently slow. Here is an overview of the most popular interpretors/compilers for java
Enter JIT Compilers
JIT compilers operate on the Java bytecode, not the source code. So essentially, they are a part of the JVM. They are meant for translating the bytecode one method at a time to a form of native code so that the program executes faster than the usual interpretation.The translated code is stored in cache and is resused during program execution.This implies that JIT compilers do require more RAM attached to the JVM. JIT compilation is usually done on a separate thread from the application execution thread, so that the application does not have to wait for this compilation.
Enter Adaptive Compilers
JIT compilers were causing memory issues since they stored all natively compiled methods in cache, Adaptive Optmized compilers where introduced. These compile only those sections of the bytecode that are most frequently accessed into the native code and store them. They give better performance results compared to JIT compilers
Enter AOT compilers
AOT (Ahead of Time) compilers are meant for producing a monolithic executable for a specific platform from the bytecode and are used predominantly in embedded systems. They use static linking as against the traditional java dynamic linking,
require more ROM as against RAM as in case of JIT compilers, since
they store the compiled machine code in ROM/flash memory. So AOT compilers are best sutiable for systems where dynamic extensions are not used, but have performance issues with the traditional interpretation techniques/JIT compilation.
So now, is Java compiled or interpreted? The answer is probably, it is a bit of both....
And what makes Java platform neutral? Try this analogy ; Java bytecode is the machine code if the JVM is the OS. In other words, bytecode is the machine code that the JVM expects. So as long as you have the JVM , java bytecodes (that is the java class file) can run on any OS ( Solaris or Linux or Mac or Windows or the mobile phone or a toaster). The JVM is highly platform dependent though. Another feature of the bytecode is that it follows the big-endian representation of bytes for all OS , since it is the JVM that interprets it.