Java Reference
In-Depth Information
independent pieces, and then ensure that those pieces really stay independent. There are also
features of the language that make it easier to explain to others what you are doing and how
the system fits together, which also aid in this sort of multiperson effort.
I find the Java language and environment to be a useful tool when the code that I am writing
needs to run on multiple platforms. The claim that you can write your code once and run it
anywhere with the Java language and the Java virtual machine is, to a large extent, true. It has
been bashed for a number of reasons, some of them absolutely true, but most of which have to
do with the graphics libraries or the look-and-feel of the user interface. These are hard prob-
lems, and it isn't even clear what the right answer is with respect to some of them. I remember
debates in the Java organization about whether “write once, run anywhere” meant that the user
interface would look the same on all platforms, or meant that the user interface would look
like the native interface on the platform, a problem especially vexing if you support both Win-
dows and Mac. It is also true that running everywhere does not always mean running
optim-
ally
everywhere. For real performance-sensitive applications, some tuning might be needed.
But for the most part, Java bytecodes will run the same on the Java virtual machine no matter
what the platform. And this is certainly a far cry from the kind of “portable” C or C++ code
that we've had in the past, where “portability” meant that you could compile most or all of
the code on any machine (after running the appropriate configuration files), and then start de-
bugging once the compile completed successfully. Java's notion of portability has to do with
the object code, and if there is any debugging to be done, it is the responsibility of the virtual
machine vendor, not the application writer. Having a portable binary format is a different sort
of thing, and a real advantage if you are going to run on multiple machines.
Java is a useful tool when the code you are writing is going to be used for a long time, either
by itself or as a component or library that is designed to have lots of different users. There are
complexities with getting a Java program started, and there are complexities that make Java
an inconvenient choice for a one-off, quick hack, or experimental program. In fact, I would
venture to say that Java is best used on systems that are designed before they are written (at
least to some level of exactitude) rather than those that grow as the code is produced.
Finally, I would say that Java is a useful tool if the code you are writing needs to be reliable. Of
course, all of us write programs that are meant to be reliable. But there is a trade-off between
the kinds of freedoms we can have in writing our code and the reliability that the language and
environment force on us. The Java language and environment have made a number of design
decisions that are meant to make the code written more reliable, even if it makes the program-
mer's experience somewhat more difficult.
