A JNLP Tutorial: Part 2—An Example
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The first article of this tutorial introduced the JNLP protocol, and illustrated a simple Java application composed of a single class that shows a message dialog box onscreen. You can think of any complex Java application instead, as long as it has a main method to be launched with.
You want to use JNLP to launch and update your applications seamlessly. After this simple example is discussed, I will introduce other particulars of this technology.
The JNLP Launching File
The core of the JNLP technology, as discussed in the first article, is the JNLP file. Indeed, you can have several types of JNLP files, but this article is limited to the one needed to launch applications—called the main JNLP file. Listing 1 shows the JNLP file that launches the Example class listed in the previous article.
Listing 1. The Launching JNLP File
00 <?xml version="1.0" encoding="utf-8"?> 01 <!-- JNLP File for SwingSet2 Demo Application --> 02 <jnlp 03 spec="1.0+" 04 codebase="http://localhost/apps" 05 href="example.jnlp"> 06 <information> 07 <title>Demo Application</title> 08 <vendor>Mauro Microsystems, Inc.</vendor> 09 <homepage href="docs/help.html"/> 10 <description>This is a Demo Application</description> 11 <description kind="short">A demo.</description> 12 <icon href="images/demologo.gif"/> 13 <offline-allowed/> 14 </information> 15 <security> 16 </security> 17 <resources> 18 <j2se version="1.3+"/> 19 <jar href="example.jar"/> 20 </resources> 21 <application-desc main-class="Example"/> 22 </jnlp>
Note the following:
Line 4 specifies the codebase for your application. This concept is analogous to the applet.
The information element (lines 6–14) provide some general data about your application, such as its title, the company/authors that provided it, and so on. (You can see how the Java Web Start JNLP Client uses this information in Figure 3).
Line 9 specifies the application homepage, where users can see some documentation, help support, and so on.
Lines 15–16 don't specify any security value, so the default value (untrusted) is used. Other possible values are trusted (but you have to sign with a valid certificate all the JAR files you provide) and the security level is specified for J2EE clients.
The resources element specifies which files and which constraints constitute the application. This element is quite rich in features (you can specify native libraries, native executables to be used, Java optional packages, locales ,and other constraints). In this case, it informs the JNLP Client that the application is composed of only one JAR file, and it requires an installed Java 2 JRE of version 1.3 or newer.
The application-desc element at line 21 says that (1) this JNLP file is for describing applications, and (2) specifies the main class—the one with the main method. If you didn't specify the main class, the JNLP Client would have tried to use the one in the JAR manifest file. If this latter one didn't exist, the JNLP Client would have issued an error.
Note that the previous example cannot run on a Java 2 JRE of version 1.2 or older. If a suitable JRE is not already installed, the JNLP Client will try to download it. Conversely, if a suited JRE is already installed, there is no need to install a new one. This solves the problem of Java applications—each one carrying its own JRE with multiple installations on the same machine. Furthermore, you can specify an exact JRE (providing an URL), for example, the IBM 1.4.1 JRE, available at the IBM site you supply.