code; I'm talking about the object code. Take a Java binary, move it from machine to machine
and operating system to operating system, and the program will run.
This has always been the point of Java's “write once, run anywhere” slogan. This is also why
the higher-level virtual machine that the JVM offers is so important, and why the JVM is dif-
ferent from the kinds of virtual machines that simply virtualize the hardware. The JVM does
not just offer a layer of abstraction on top of the chip. The JVM offers a layer of abstraction
on the chip, the disk, the network, any other hardware, and the operating system itself. It is, of
course, more than just the raw JVM itself. It is a combination of the JVM and the libraries that
are included with that virtual machine that give this portability. But the combination of the
virtual machine and the libraries that go with it give a kind of portability that is unmatched.
Maybe programmers who have grown up in the age of the JVM (that is, the last dozen or
so years) don't realize what a revolution this is in the way programming is done. It used to
be [ 19 ] that writing portable code meant adding a lot of #define s and ifdef s to your code, and
having makefiles that would determine the environment and generate the actual makefile that
would define enough context for your code that you could get the code compiled. And when
that was done, you could start debugging, since the semantics of a library call on one OS might
be quite different from the semantics of that same call on another OS. [ 20 ] And you needed to
do this for every combination of processor and operating system on which you wanted your
code to run.
Things have gotten somewhat simpler over time just because of the consolidation of the com-
puter industry. There used to be a lot more variation in processors and a lot more different
operating systems than there are today. But even if you confine yourself to the major chip ar-
chitecture and the major operating systems, you probably have at least four combinations that
you have to worry about (Windows, Mac, and the two Linux flavors-of-the-day). And the mo-
bile phone manufacturers are making me feel young again, insisting that each phone have its
own processor and operating environment that are incompatible with any other phone's pro-
cessor and operating environment.
With the JVM, things are different. If there is a JVM on the environment, your program will
run. The same way it does with every other JVM. Or it is someone else's problem. Which
means that instead of tearing your hair out trying to fix your code, you can file a bug with the
Java organization and get the problem fixed.
I remember the first time that I realized the power of the JVM with respect to portability. This
was long ago (Java 1.0 had just been released), and my lab group had built a couple of large
libraries (Remote Method Invocation and Object Serialization, to be precise) and a couple
of demos of the then-new technology. All our work had been on Sun Sparc systems running