- A Web-Centered Protocol
- What Is JNLP All About?
- An Example
- To Be Continued...
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
What Is JNLP All About?
JNLP is an XML-based technology for launching Java executables over the Web. Just imagine that you could specify the classpath resources in your application (images, JAR files, properties, files, etc.), scattered over the Web and giving their URLs, instead of relying on the local file system as normal Java applications do. This feature would give you the capability of deploying your application automatically (that is, installing needed application files and launching them properly) just by declaring where your files are on the Web.
Then imagine adding capabilities, such as distinguishing between versions of the same file depending on some local parameter, and so on. That would be great. Imagine you could say "If the locale is 'Chinese,' use the input framework extension and those JAR files there." Or "If the client platform is 'Windows', launch this installer here before running the application."
That would save a lot of coding effort (and such installation problems are very common), and would allow developers to have a great number of new unimagined capabilities.
But there is a subtlety. Who will configure the JVM to launch your application this way? The most obvious answer is: another application—a kind of launcher. This will prepare everything for the JVM to correctly execute your program. Remember that the JVM needs files copied locally on the file system in order to use them.
The JNLP protocol consists basically of a set of rules that describe how this launching mechanism should be implemented. Instead of setting the classpath variable, you will write a special XML file (or more than one) that describes carefully what the launcher (called the JNLP Client) should do before setting up a JVM instance to run your application.
What Do I Have to Pay for It?
You must have a JNLP Client already installed on your client machines. That is not a big problem because the JNLP Client installation can be made automatic, so end users will see the client launcher automatically downloaded and installed before the Java application the first time they launch the latter. You can set up the whole mechanism with little trouble for the end user. This is important because you can take advantage of this technology in a transparent way to your users. There are some drawbacks as well, however:
The JNLP Client (for example Java Web Start) has to be launched before your Java application will begin to run.
The user will see a splash screen that appears right before the application ever runs. (This screen informs the user of the JNLP Client initialization time.) End users may ask "What's that screen that appears?"
In the second article, you will see all pros and cons of this protocol. Now, you will see how it works.
A First Look
Our first very simple JNLP file is shown in Listing 1.
Listing 1. A Simple JNLP File
01 <?xml version="1.0" encoding="UTF-8"?> 02 <jnlp spec="1.0+" 03 codebase="file:///c:/test/" 04 href="test.jnlp"> 05 <information> 06 <title>Hello JNLP</title> 07 <homepage href="http://www.marinilli.com" /> 08 <vendor>Mauro's</vendor> 09 <offline/> 10 </information> 11 <resources> 12 <j2se version="1.2+" /> 13 <jar href="bin/test.jar" /> 14 </resources> 15 <application-desc /> 16 </jnlp>
You will see this file better in the second article of this tutorial. Here you just receive an intuitive description of the basic JNLP file syntax.
The jnlp element means that this XML file is a JNLP file. Sun provides all the details of the syntax (element definitions, schema, and so on) on its Web site. If you don't know about XML, try this site: http://www.xml.org/xml/. Anyway, you don't need any deep XML knowledge to use JNLP. Just run the following example, and try to modify it to your needs. JNLP is not a difficult protocol, and there are a number of free JNLP packaging tools around (see the links section at the end of the Part 2).
The information element provides some data about your application to the JNLP Client program. At lines 11–14, the resources element (the core of the protocol, as you will see later) describes all the files that compose your application. After having introduced a little taste of the JNLP syntax, you turn to its general mechanism.
But How Does It Work, Exactly?
The whole protocol works on a classic client-server scheme. The JNLP Client reads the XML file (called the JNLP file), and executes what's written in it, eventually contacting a JNLP server or a normal Web server for some help. The JNLP client is an application that runs locally on the client machine. Popular JNLP Clients are Java Web Start from Sun and OpenJNLP, an open source implementation. Both are free, like the whole technology (that is, you don't have to pay for using JNLP in your programs). The JNLP Server is usually implemented by a servlet, and is used only for some advanced features of the protocol. See the references section at the end of Part 2 for the URL of a free implementation of a JNLP server.
See Figure 1 for the details of the launching process.
){kind=link}
Figure 1 The JNLP mechanism.
Indeed, you may have different types of JNLP files, depending on what they describe. You always have a main JNLP file that points to all other files (JAR files, other JNLP files, and so on) as shown in Figure 2.
){kind=link}
Figure 2 The JNLP mechanism through XML files.
Actually, the objective of the JNLP client is to correctly initialize a JVM instance in order to execute the needed application.
JNLP allows you to do many more things than specifying where application files should be downloaded. Given the presence of a JNLP client, there is a wide range of features that could be supported by the JNLP protocol, as follows:
A richer client environment at runtime. Developers can use a new API that leverages the underlying JNLP Client, allowing standard runtime services to access system resources.
A secure deployment solution. End users can trust a reliable JNLP Client because it will not allow any harmful behavior by client applications.
Versioning and incremental updates. Each resource can be tagged with a version id and managed accordingly. Incremental updates are obtained using the JARDiff format.
Multiple JREs management and automatic installation of additional JREs and optional packages.
Offline operation. Deployed applications can work even without a connection with the deployment server. Even if it is a somewhat minimal feature, it is widely used in practice.
Automatic installation of native code/libraries. Some Java programs may need some platform-specific support for running.
JNLP Client management console. Although not part of the specifications, the JNLP Client is providing to end users a form of graphical configuration console (for instance, the management console of Java Web Start).
The capability of using platform-dependent facilities such as shortcuts, accelerators, and the like. Deployed applications are integrated on the native OS—providing shortcuts and launching scripts or other platform-dependent mechanisms So your Java application will look like a native application with a little effort.
You will now see a simple yet complete example of JNLP at work.