Java Reference
In-Depth Information
The installation logical sequence is always the following one:
1.
JRE and JNLP Application Helper (for example, Java Web Start)
2.
The core module
3.
Add-on modules
N
OTE
We are focusing only on the first-time activation, so updates and other deployment
services costs are not considered now.
Provided that our JNLP Client supports lazy resources downloads, we have to decide how to
distribute the resources weight between steps 2 and 3 of the previous list.
Another important and popular technique to generally reduce transfer costs is to include only
the required resources in the planned client configurations. As we saw in Chapter 4, often
applications come shipped with unneeded locale-specific data, or other platform-specific data
that is never used during application execution. In order to take the maximum advantage from
such JNLP features, developers have to divide platform-specific data in different JAR files and
then prepare JNLP files in order to take advantage of such arrangement. This could be time
consuming (often, locale-specific data is split in different files, for example), and if the
obtained JAR files are too small, it could even be not worth the cost. You should also consider
maintenance issues because the application evolves after the first release. Much will depend on
the tools you have for administering this (the packaging and creation of the JNLP resources
from your application resources).
Our Example
The resources decomposition in modules is straightforward in our case. We have only two
modules: the core and the draw editor add-on.
The core module contains the core executables and their resources, plus third-party libraries. In
this case, we use a standard set of icons for Swing applications provided by Sun. For concrete-
ness, we can map modules with JAR files, obtaining the following association.
Module
JAR File
core
textuale.jar
;
jlfgr-1_0.jar
draw add-on
draw.jar
