X

Distributing a Java Web Start Application via CD-ROM

Guest Author

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.

Join the discussion

Comments ( 1 )
  • pratikbhagwat Wednesday, August 6, 2008

    godd site


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.