From C to Java: an introduction to Java for C programmers
(Continued from our introduction to Java for C programmers.)
The Java deployment model
In C, the deployment model is generally to give the end user a machine code
executable that is directly runnable by the operating system. In reality, the
OS's intervention is generally required to do things such as relocate branch instructions
to point to the appropriate place in memory once the code is loaded in,
and to link in OS libraries, but the principle
is that a piece of 'native' machine code is run.
To support different platforms in C, different versions of the executable must
be compiled, and the user must be given the version to suit their platform.
(A common distribution pattern in UNIX environments where a C compiler is
readily available as standard is to distribute the program
as source code and have the user compile it on their specific machine.)
Java programs are distributed as class files. Recall that we said
that these contained Java in an intermediary bytecode format. The
individual Java Virtual Machine on a particular platform (Windows,
Solaris, Linux, Mac etc) then does the final job of translating the bytecode into
the native machine code for that platform. (And primitive JVMs may simply interpret it.)
Class files are typically packaged into a jar file, which is nothing
more than a zip file containing the class files with a particular directory structure
(and occasionally some auxiliary files).
This model is both good and bad news. The good news is that if the client has a JVM
installed, the files to distribute are typically small, and the same files can essentially
be distributed for any platform. A JVM is installed in the form of a Java Runtime
Environment, consisting of the JVM itself plus implementations of the class libraries
for that machine.
The bad news is that if the client does not already
have a JRE installed, or the one installed is too old, then the user must install one,
typically via a download in the order of tens of megabytes.
Sun provides freely-distributable JREs for various platforms.
But the user must still either
be directed to their web site, or else explicitly instructed to install the JRE that
they have been provided with. For moderate-to-large applications, this is
not so much of a problem, since the download and/or extra installation procedure
is likely to be perceived as "worth it", and the budget of the program is likely
to cover use of a commercial Java installer program if necessary.
But there's no Java equivalent of a "small standalone EXE".
Provided the client machine does have a JRE installed, an application installer can
also be written in Java, although as of Java 6 there is no standard framework for
doing so. (In other words, it is left up to the developer to work out which directories
to place files, how to add the application to any platform shortcut menu etc.)
I understand that this situation is to remedied in Java 7 to be released later in 2008.
Java also supports the creation of Applets: effectively mini Java
applications embedded in web pages, generally with some restrictions. The advantage of
Applets for simple tasks is that most web browsers already come with a Java runtime
installed, so there is no extra download/install stage for the user.
(And if there is, it is often handled by the browser.)