Search this site


 Home  Howto index  Getting started with Java  Java for C programmers  Java for BASIC programmers

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.)

comments powered by Disqus

Written by Neil Coffey. Copyright © Javamex UK 2012. All rights reserved.