Distributing a Java Web Start Application via CD-ROM

by Luan O'Carroll

Isn't Java Web Start (JWS) supposed to allow web-based distribution of applications? So why would one want to distribute a Java Web Start (JWS) application via CD-ROM? Well, for a number of reasons. For larger applications, a complete installation can still be a major download even with high-speed broadband. Secondly, not all desktops are online, and not all can access the internet (for corporate security reasons, for example). And, lastly, some people just like CDs.

A client company required that their application be distributed worldwide, including to places where broadband coverage is sparse. The application contains information about a large number of products, including detailed drawings and diagrams. All this information constituted a major part of the application, and a complete installation including the JVM amounts to over 40 MB. In addition to this, the company wanted to be able to distribute the application on CDs at trade fairs and with promotional materials; therefore, a CD-based distribution was required. Normally a CD install is possible using either commercial or open source installers, of which there are many. However, when an application is to run with Java Web Start, it needs to be installed in a specific location and not at the user's discretion, as is the norm for installers.

This article describes the steps involved in installing an application that installs both from CD and the internet. The installation process requires that:

  1. The installed application must check for updates and integrate with the JWS cache.
  2. The installation should work on a machine without an existing or up-to-date version of Java.
  3. The installed application should not require an internet connection.
  4. A installation must be easy to use and must provide a simple user interface.

Application installation is normally carried out with a generic installer application, but a traditional install process would effectively create a separate application that is unaware of JWS. Each time an update is released, the user would have to download and install the new version, whereas a JWS application only downloads those components that have been updated, making the process far more efficient and reliable. The article therefore also describes a JWS application installer.

JWS Primer

Java Web Start allows Java applications to be launched via a link to a JNLP file. The JNLP file describes the main method or entry point into the application and it references the resources used by the application.

When a JWS application is launched, the JVM tries to access the required resources, updating them if necessary, and copies the file to its cache. On subsequent attempts to launch the application, JWS can check this cache and skip download of the resources. If the client machine is offline or if the server cannot be contacted, then JWS can run the application in an offline mode.

If the JWS launch file (the JNLP) were placed on CD, JWS would attempt to contact the server and download any new files. Obviously this would defeat the purpose of distributing the files via CD if the client machine is online. Instead, we need some way to update the JWS cache as though the application had been previously loaded by JWS.

Updating the JWS Cache

The Java 5 version of JWS includes a little known -import option that imports a JWS application into the cache from a specified location.

The CD image at this location is just a copy of what you would normally place on the web server: the JNLP file, plus the .jars and resources referred to by that JNLP file. If you use a servlet to serve up the JNLP, then the CD image will need a self-contained snapshot of the generated JNLP file.

The CD image can thus be installed into the JWS cache by calling:

<JAVA_HOME>/jre/bin/javaws -codebase <CACHE_IMAGE> -import <CACHE_IMAGE>/<XXXX>.jnlp

where <JAVA_HOME> is the root of the (possible new) JVM, <CACHE_IMAGE> is location of the JWS application on the CD, and <XXXX> is the name of the application JNLP file. Later, we will see how this command is automated and wrapped in a simple GUI.

In installing the cached application, JWS conveniently prompts the user to install desktop and menu shortcuts for starting the application. Once the JWS install has been completed, we can again call JWS to start the newly installed application.

<JAVA_HOME>/jre/bin/javaws -import <CACHE_IMAGE>/<XXXX>.jnlp

Again the CD is used, but this time JWS will use the installation referred to by the JNLP file. If the machine is connected to the internet, it will check for updates in the normal way, as part of the process, and then start the application. If there is no network connection, the application will launch as delivered on CD.

The next time the user starts the application they can use the menu or desktop shortcuts and the CD will no longer be needed. Alternatively, the user can start the application from a link on a web page that points to the same URL/JNLP file combination; i.e., the original version from the website.

JVM Complications

One gotcha in all of this is that the above commands require the presence of a JVM, and in some rare cases this may not be installed or may not be available by default on the system path and therefore some extra measures are needed to locate a usable JVM. Furthermore, when a user inserts the CD, the installation should begin, and the installation should check for the presence of an existing JVM. The process of checking for a JVM is then as follows:

  1. Check for a JVM (for the installer).
  2. Install the JVM if not present.
  3. Launch the installer, showing the usual license information.
  4. Install the target JVM (if required by the application and different from 1 above).
  5. Import the JWS cache.
  6. Start the JWS application.

Some further complications arise from the fact that the minimum JVM for the JWS -import option is Java 5, so even if a JVM is present and usable for the application, this import option will still require a fairly recent JVM. Secondly, the import process takes some time and must complete before the application is launched, and this sort of delayed execution is difficult to achieve with many of the normal installers.

Given these complications, it was necessary to build a custom launch application that could perform these steps.

Read the rest of the article.


godd site

Posted by pratikbhagwat on August 05, 2008 at 08:49 PM PDT #

Post a Comment:
Comments are closed for this entry.

John O'Conner


« July 2016