Java Reference
In-Depth Information
This is not a particularly novel approach to computing. The UCSD Pascal system did essen-
tially the same thing in 1978. The compiler for the Pascal language in that system generated
p-code (the equivalent of Java bytecodes) that was then run in a virtual machine, hiding the
differences in the underlying hardware and operating system from the users of the system.
The major difference between the UCSD system and the JVM is that the UCSD system ran on
early personal computers or PDP-11s, whereas the JVM runs on much more modern equip-
ment. This difference in speed of the underlying hardware was the difference between the
painfully slow UCSD system and a more than adequate implementation of the JVM.
When Java was first introduced, all JVMs ran the bytecodes through an interpreter. But within
a couple of years, the first just-in-time compilers were introduced. These compilers, which
first appeared in research languages such as Self, would take the bytecodes that were being
interpreted and compile them, on the fly, into native code. The most interesting thing about
these compilers is that the more some piece of code was used, the more optimized the com-
piled code would be. Just-in-time compilation also has the advantage of knowing the actual
usage of the code and the environment of the current program execution, so rather than having
to optimize for all possible runs (like a standard, single-time compiler and optimizer), the just-
in-time compiler can optimize for each particular run of the program. In theory, this should
enable programs that are compiled on the fly to be faster than those that are compiled in more
traditional fashion; in fact, such results are beginning to be seen with the current crop of vir-
tual machines.
The JVM has been a remarkably stable abstraction, even though the implementation of the
JVM has undergone considerable change over the years. Bytecodes that are generated by earli-
er versions of the Java compiler still run on the modern implementations of the JVM, although
they do so much more quickly than on the earlier JVM. There have been some changes to
the basic JVM in the past couple of years, but these changes have been additions that allow
other languages to compile to Java bytecodes and run within the JVM. Indeed, there are a
number of other languages that now make use of the JVM as their operating environment, in-
cluding Python (in the Jython incarnation) and functional languages such as Scala. There are
versions of FORTH, LOGO, and Pascal that run on the JVM. There is Ruby, JavaScript, PHP,
and no doubt others that I've not heard about. I have heard that are even tools that will convert
COBOL programs into Java so that the programs can be run on the JVM (I have not verified
this, nor do I intend to).
The point to this is that the JVM has become more than just a virtual machine for Java. It is
now a runtime environment for lots of different languages, offering enough value on its own
that it no longer needs to be tied to the particular syntax and semantics of the Java language.
Even though it was not originally intended to be a virtual machine for more than Java, it has
