To recap, a JNLP file must contain a descriptor element that could be one of four possible
types only. It always contains three other types of elements: an information element, a security
element(that is optional; it is described in Chapter 10), and many resources elements as
Before diving into JNLP details, it is important to briefly clarify situations in which this tech-
nology would be used.
When Adopting JNLP Technology Makes Sense
Generally speaking, when adopting the JNLP technology for your solution, all the considera-
tions regarding Java technology still apply. They apply in particular for the J2SE case (that is,
good RAM memory resources available on client machines, relatively new installed hardware,
and so on).
A strong motivation for choosing the JNLP solution is to improve an existing Java application
or to migrate an applet to a JNLP-deployed application.
It is essential to plan the JNLP Client deployment strategy in advance. Explicitly, how do you
intend to install the JNLP Client (for example, Java Web Start) on client platforms if it is not
already present? The capability to accomplish this task effectively is the real hurdle in adopting
the JNLP technology.
Server-side considerations also have to be taken into account. We require a certain control over
the deployment Web server, especially for the protocol's advanced features such as incremental
updates of JAR files.
When is it not a good idea to take it on? Regarding this aspect, all the considerations described
in the second chapter apply to the JNLP deployment technology too…in particular, when the
first-time launch cost is too high. In terms of bandwidth (using Java Web Start as an example),
we see that the JNLP client occupies roughly 6MB (almost 5.5MB for the J2SE JRE non-
localized and .5 MB for the Web Start non-localized executable). Adding in an average appli-
cation (say around .5 MB), the result is a total of 6.5MB (counting installer code, too).
Another important factor is whether end-users are willing to pay the JNLP Client installation
cost in terms of complexity, time, and so on. This is often the case in organizations that pro-
duce the software they use.
Let's spend some time discussing what JNLP technology provides developers. Although it
takes care of deployment, resource versioning in a secure end-user environment, and giving
extra runtime services, the technology is limited in some ways. First of all, security is at a
basic level, and authentication is limited to JAR files only. These are not severe limitations, but
they leave developers of advanced applications with some work to do. Regarding security and
other issues, such as per-user authentication, probably the best way to proceed is with in-house
development. However, for other kinds of services such as example debugging or logging,