Java Web Start to the rescue

Java applets fuelled Java's initial growth. The ability to download code over the network and run it on a variety of desktops offering a rich user interaction proved quite compelling. However, Java's Write Once, Run Anywhere (WORA) promise soon became strained as browsers began to bloat and several incompatibilities emerged that were caused by the Java language itself. In the meantime, Java proved a disruptive technology yet again by making a mark on the server side.

Recently, Java began making a comeback on the client side with technologies such as Java Plug-in and, more recently, Java Web Start. Also, the Java 2 Platform, Enterprise Edition (J2EE) incorporates technologies such as JavaServer Pages (JSP) that support desktops and a multitude of client devices by serving up HTML, XML, and so on.

Using markup languages to generate user interfaces proves advantageous due to those languages' ubiquity and light weight. However, a markup-language-based UI is fairly limited. Java Web Start overcomes this main limitation while preserving some of a markup-language UI's main benefits, such as using a network URL as a launching point, updating client applications without intervention, and so on. Using Java Web Start, it's possible to design desktop Web clients that provide a rich user experience decoupled from a browser.

In this article, I will primarily look at Java Web Start. However, to begin I will provide some background on the motivation behind the technology, and compare and contrast different approaches for designing Web clients using various available technologies.

At the trail's root: Java applets

"An applet is a small program that is intended not to be run on its own, but rather to be embedded inside another application" -- so says the Applet Javadoc. Browsers represent the typical application in which an applet is embedded. Coupled with the rapid growth and ubiquitous availability of browsers, applets provided a nice delivery vehicle for distributing applications to thousands, even millions of desktop clients with the click of a mouse.

Although applets offer several advantages -- a rich user interaction, for example -- they are restricted by the environment in which they execute: the browser. Another issue is that applets are embedded in HTML. HTML downloads quickly because it focuses solely on presentation. Applets are much more general, and therefore slower to render. Mixing the two on the same page results in an impedance mismatch.

Applet developers must also support different versions of Java in various browsers, making it difficult to meet the WORA paradigm. Further, the slow download time can make invoking a Java applet a jarring experience for the user, a problem that does not improve with subsequent uses.

Finally, from a security viewpoint, applets are restricted by the sandbox environment, which provides a powerful defense against rogue applications. Although this model is simple to understand, it is fairly inflexible in that it does not support actions, like local disk access, that are reasonable requirements even for network-downloadable code, provided that the actions can be accomplished securely.

Many of these issues are solved via the Java Plug-in. However, even with the Java Plug-in, the user interaction remains constrained by the application hosting the applet.

Java conquers the server turf

Java morphed from an applet-based language, as descried above, into the programming platform of choice on the server. The language's focus shifted heavily from the client to the server side. Using server-based technologies, it was easier from a program maintenance viewpoint to control from the server the user interface for the client. The user interface centers around markup technologies like HTML, XML, XHTML, and so on. Servlets and JSPs are Java-based technologies on the server side that can be used to serve up markup languages. Servlets and JSPs are an important part of J2EE, providing an entry point to the Web clients for other Java- and J2EE-related technologies on the server.

The server-centric approach offers a responsive user interface, albeit with interactivity limited by the markup language used for the client. An advantage of this approach: support for multiple kinds of clients, especially thin clients. Although the interactivity of many of these thin clients is inherently constrained by the nature of the device, thin clients typically can support one or more markup language.

Java comes back on the client

We looked at applets and then at Servlet/JSP-based technologies as the basis for Web client design. These technologies are primarily constrained by the environment in which they are hosted -- a browser or some similar technology. Although this may not prove to be a serious limitation to some applications, it is likely to limit many. A browser-based email client serves as a good example. Although browser-based email clients are quite popular, traditional email clients are more prevalent, especially in the workplace, where there is a need to sift through lots of email, apply filters, and be able to work offline in certain scenarios.

Java Web Start overcomes these user interface and connectivity limitations, and offers client-side software distribution features as well. The availability of Java Web Start on a number of different platforms makes it a powerful choice for designing desktop clients. For instance, you can use Java Web Start to add more interactive clients for J2EE applications.

Some of the ease-of-use and ease-of-programming features associated with Java Web Start include:

• Portability: Java Web Start is available on Windows, Solaris, and Linux, and is expected to be ported to other platforms.
• Caching: Applications launched with Java Web Start are cached locally. Thus, an already-downloaded application is launched on par with a traditionally installed application.
• Maintainability: If the remote application is updated, Java Web Start updates the locally cached version at the application's next invocation.
• Easy launching: Java Web Start allows applications to be launched independently of a Web browser. The application can also be launched through desktop shortcuts, making launching the Web-deployed application similar to launching a native application.
• Ability to work offline: An application can be used in situations where launching through the browser is inconvenient or impossible.

The table below compares the different technologies used for designing Web clients. These different factors influence the design of these Web clients.

As you can see, while applets take roughly the same time to download on first use and each subsequent use, Java Web Start applications will load faster on subsequent uses due to the product's inherent caching features.

Another point to note: no single approach will cover all situations. Later, I'll show how you can employ a combined approach.

Java Network Launching Protocol and API

We explored Java Web Start briefly. Next, we'll look at the Java Network Launching Protocol (JNLP) specification, which is the basis for Java Web Start. JNLP provides a Web-centric protocol for provisioning (i.e., deployment and other issues associated with it) and running Java 2-based applications. The specification includes:

• A Web-centric application model with no installation phase, providing transparent and incremental updates.
• The syntax and semantics of a .JNLP file, which packages applications on a Web server and delivers and runs them on clients.
• A standard execution environment for an application, which is similar to the sandbox model but enhanced with additional APIs for local clipboard and disk access. Using standard code-signing techniques, it is possible to provide an unrestricted environment as well.

In essence, JNLP provides a way for an application to run from a codebase accessible over the Net. It provides an environment similar to what would happen if URLs were supported in the classpath, a hypothetical example of which would be:

java -classpath http://www.mysite.com/app/MyApp.jar com.mysite.app.Main

In addition, JNLP provides support for multiple versions of Java, support for native libraries, and a number of ease-of-use features. Java Web Start is a product based around the JNLP specification. Other products using the specification are also available (see Resources).

Having demonstrated the distinction between the JNLP specification and the products based on it, I will now turn primarily to Java Web Start. I will show each of its features, starting with making a simple application network accessible and deployable, then moving on to code signing, and finally to using some of the JNLP API. In the process, we will look at the .JNLP file, which describes an application as an XML document.

Java Web Start -- getting started

Now that you've briefly seen the JNLP specification, let's take a look at one product based on it: Java Web Start. To use Java Web Start's full feature set, some minimal installation and configuration is required on both the server and the client. We will look at each step using some simple examples, as outlined below.

Server-side setup

I'll show you how you can make the example program -- SimpleExample, a simple (Java Foundation Classes) JFC demonstration -- network accessible using JNLP. This example is provided as part of the Java SDK. As outlined in the developer's guide (see Resources), create the SimpleExample.jnlp file:

<?xml version="1.0" encoding="utf-8"?> 
<!-- JNLP File for SimpleExample Application --> 
  <jnlp
  codebase="http://anvil:8001/" 
  href="SimpleExample.jnlp"> 
    <information> 
       <title>Swing Application - Hello World</title> 
       <vendor>Rags</vendor> 
       <description>Swing Application - Hello World</description> 
       <description kind="short">Swing Application - Hello World</description> 
       <offline-allowed/> 
     </information> 
     <resources> 
       <j2se version="1.3"/> 
       <jar href="SimpleExample.jar"/> 
     </resources> 
     <application-desc main-class="SimpleExample"/> 
</jnlp>

The XML document above is self describing. Details about the application, including how it can be accessed by the Web server, are provided by the codebase property; more detailed information is enclosed between the <information> and </information> tags. The version tag illustrates which version of the Java 2 Platform, Standard Edition Runtime Environment should be used. It is possible to provide a prioritized list and specific values for the JRE versions. For more information on the syntax and semantics of the file, refer to the Resources section below.

Having created the .JNLP file, create the SimpleExample.html file used to launch the application:

<html>
  <head>
      <title>SimpleExample demo!</title>
  </head>
  <body>
       <a href="SimpleExample.jnlp">Launch SimpleExample Application</a>
  </body>
</html>

The developer's guide outlines how to develop the HTML file to detect whether or not Java Web Start is installed, and how to install it if necessary.

Package the application into the file SimpleExample.jar:

D:\jdk1.2\demo\jfc\SIMPLE>jar -cvf SimpleExample.jar *.class
added manifest
adding: SimpleExample.class (in=402) (out=283) (deflated 29%)
adding: SimpleExample$RadioListener.class (in=1444) (out=829) (deflated 42%)
adding: SimpleExample.class (in=3046) (out=1581) (deflated 48%)

Finally, configure the Web server to use the appropriate MIME type. The server must return the application/x-java-jnlp-file MIME type for JNLP files in order for Java Web Start to invoke. This is obviously Web-server-dependent. In Jigsaw, the jigadmin tool can achieve this. Tucked away in http-server/Indexers/default are extensions to which <JNLP> needs to be added to return the MIME type as noted above.

Client-side setup and deployment

Install Java Web Start version 1.0 or 1.0.1 on the client.

On the client side, launch a browser and point it to the HTML file on the server. If Java Web Start is correctly installed, the Web server configured for the .JNLP extension, and the application appropriately provisioned as indicated above, a splash screen should appear, followed by a window indicating that the application is being downloaded, as shown in Figure 1.

Finally, the networked application is launched locally, as shown in Figure 2.