Java Reference
In-Depth Information
To recap, when parsing the XML file, it is as if the JNLP Client would compare those specified
values against the current ones. In the case when one of them doesn't match the current values
for that computer, the whole
resources
element is ignored.
N
OTE
When one of the properties above is not specified, the given resource is meant to be
used with all the possible values.
As a practical rule of thumb, it is a good idea to always include some default resource ele-
ments and then provide their specializations for locale data, platform-dependent parts, and so
on.
Code Resources
There are two types of code resources that can be described in the JNLP protocol: JAR files
and native libraries. Although they are both JAR files, one contains only Java code and other
application files, whereas the native library JAR files also contain shared libraries such as
Windows'
DLL
or UNIX's
so
files. The latter code resource type has to be treated differently
from plain JAR files because it is specific for some platforms only, and needs to be loaded dif-
ferently into the JVM.
JAR files
The
jar
element is used to add JAR files to the application's classpath, such as in the follow-
ing line:
<jar href=”com.mycompany.myjar.jar”/>
Although a less-frequent case, it is possible that some JAR files contain platform-specific
code. In this situation, the resources attributes (
os
and
arch
) need to be specified for these
resources as well.
For a JAR resource, we can specify different properties:
• Physical location on the deployment server. Using the
href
attribute, relative to the
codebase
assigned in the
<information>
element, just like a normal relative Web link.
• The current
version
of the JAR file.
•How the JNLP Client has to
download
the JAR file. Using the download attribute with
two possible values:
lazy
(the JAR file is downloaded when needed) and
eager
(together
with all other eager resources, at JRE initialization time).
