Note the known-platform field in the HTTP request. It defines the J2SE JRE already installed
on the client machine. It must be always specified when requesting an extension.
Also note that all the usual attributes ( arch , os , locale ) together with the above mentioned
known-platform one, must be specified for any request.
Anyway, for allowing a minimal extension support also for basic Web servers, when the ver-
sion field is not specified, the extension request is handled like a normal file request, and the
client will accept and use the downloaded JNLP extension files.
Finally, let's see how new JREs can be downloaded using the extension mechanism provided
The attribute responsible for specifying JREs in the JNLP file is j2se . It can be used to specify
a particular URL from where a JRE can be downloaded, if not already present on the client
machine. Of course, the URL should point to a servlet or other code able to satisfy the JNLP
For example, given the following line in the JNLP file:
<j2se version=”1.4” href=”http://www.jrevendorsite.com/jnlpjre/” />
the JNLP client will issue the following HTTP GET request (assuming to have a Windows 2000
client with JRE version 1.3.1 already installed):
Otherwise, the URL can be omitted; in this case, the client is responsible for knowing the URL
where the given JRE could be downloaded. Clients such as Java Web Start typically will point
to Sun's JREs.
Providing Incremental Updates For JAR Files
JARDiff files are a special type of JAR files that describe the differences between two JAR
files. They are useful to save bandwidth during downloads.
Clients do not explicitly request JARDiff files. Instead, clients simply add the currently
installed version for that JAR resource to the request, together with the usual requested version.
Then, it is up to the server to decide whether to return a version-compatible JAR resource or a
JARDiff file that contains the pieces to be added to the JAR file currently installed on the
client, together with the instruction to assemble them.
Figure 12.1 depicts the mechanism for incremental updates.