In particular, our simple installer uses the following items in a hard-wired fashion:
•Files in the cdrom-root/setup/ directory.
• Items in the cdrom-root/setup/res/ directory are the items to be installed on the client
computer. Typically, all JAR/ZIP files and the “readme” file are stored in this directory.
• The CDLauncher will look for the “ readme ”file exclusively with the given name: cdrom-
•In the cdrom-root/jre/ directory are listed all the JRE installation files organized in
separated directories for the given OS.
•In the cdrom-root/tempjre/ ,the native executable will look for the auxiliary JRE
needed to execute the CDLauncher application.
This installer uses a temporary JRE interpreter, located in the tempjre/ directory only
to launch the CDLauncher Java application. This one in turn will properly install
another JRE on the client computer, located in the jre/ directory, while the content
of the tempjre/ directory is never copied on the local hard disk.
An Installer Applet
A simple example of ad-hoc deployment is represented by an installer applet. Such an applet is
capable of saving some files on the local computer. This simple arrangement implements a one-
shot installation deployment circuit with little effort, while also showing how the Plug-In could
be used as an effective deployment means.
One common problem with applets is that they easily tend to get bulky, and their download can
be rather tedious. In fact, one of the shortcomings of the applet model is the little control the
developer has over the applet caching mechanism. Using this technique (that is, saving locally
applet's resources), we can “install” some parts or even the whole program locally on the client
hard disk. One can think of using the applet as a mere “installer” for opportunely placing files
on the client hard disk. When implementing this technique, some problems need to be solved.
The main hurdle is represented by the applet's security sandbox. We will use the Plug-In utility
included in the J2SE JRE distributed freely by Sun. This will solve nicely the JRE installation
problem (especially in an intranet environment, as we will see) from a developer's perspective,
but will require the end-user to download the JRE installation file (around 5MB). Of course,
one can use some alternative method, as shown in the previous example. The real problem is
that such a technique is quite obtrusive, and end-users hardly will allow an external application
to take control of their local hard disk.