Server-Side Deployment Support - Java Deployment with JNLP and WebStart - page 353

1. Request

http://www.server.com/…/file1.jar?
version-id=2&current-version=1s

JNLP Client JNLP Server

File 1
.jar

2. Server
Response

Delta
File 1-2
.jardiff

JNLP Server

12

3. Assembly

Delta
File 1-2
.jardiff

= +

File 2
.jar

File 1
.jar

F IGURE 12.1
The JARDiff working mechanism.

After a JAR file is requested, specifying the already installed version, the JNLP server may
return a JARDiff file, and the JNLP client will take care to build the new file from assembling
the JARDiff with the installed old JAR file.

N OTE

As of version 1.0 of the JNLP specification, JARDiff files are an optional feature. They
don't embody a conceptual characteristic in the protocol; rather they are just an
implementation-level enhancement.

The granularity level (that is, the smallest piece that can be handled) of differencing with
JARDiff files is class-level for code, and generally of a file entry inside the JAR file. To see it
in a slightly different way, it's like we could be able to patch JAR files, and our patches could
be no littler than Java classes items (contained into JAR files).

Getting back to Part I of this topic, we saw that some Java deployment solutions allow for finer
granularity levels (for instance, DeployDirector permits byte-level differences. This is to say
that it allows patching single classes).