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.
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
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.
The jar element is used to add JAR files to the application's classpath, such as in the follow-
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).