Sun’s Java Web Start makes installing Java applications as simple as tagging Web links to check and access centralized resources files. This advance offers a nice compromise between the ease of distribution provided by Java applets and the power of Java applications.
Applets vs. applications
Applets run in the Web browser and require no installation. The ease of updating applets is one of their most compelling benefits. Applet creators need only replace the class files or jars on their Web servers, and users get the newer version the next time they run the applet. However, a necessary yet limiting sandbox model and spotty browser support have led to a decline in Java applets’ popularity. Sun’s Java plug-in does a lot to address the later issue, but applets still have a declining fan base.
On the other hand, Java applications have only grown in popularity. Server-side developers and devotees of Sun’s Swing can tap a wide range of IDEs and the support of a strong Java community.
Of course, applications have their own drawbacks, most notably their difficulty of installation. Java promotes itself as a “write once, run anywhere” language, but application installation requires more operating system interaction than Java’s lowest common denominator can provide. Releasing new versions of installed applications is also problematic. Many third-party tools are available to simplify Java application installation and updating, but most are expensive and all greatly restrict the user’s choice of platforms.
Recognizing this problem, Sun created Java Web Start, which users need to install on their systems only once. After they’ve done so, they’re able to run any Java application packaged for Web Start execution without any further installation hassles. What’s more, Web Start seamlessly handles updated applications without any user intervention.
Installing Web Start
The Web Start end-user application, which is available for a multitude of platforms, can be found on Sun’s Web site. The installation process is simple, and in part three of this series we’ll see how to make it automatic in some cases.
Users with Web Start installed are able to launch Java applications from remote or local locations by navigating to URLs that end with the Java Network Launching Protocol (jnlp) extension. JNLP is not a network protocol (all Web Start traffic is through standard HTTP); it’s an XML DTD that provides the necessary information for Web Start to launch an application.
The JNLP file is created by the application developer and hosted on any Web server. The JNLP file contains a list of resources, typically jars, necessary to run the application, invocation instructions, and general application metadata.
Applications run through Web Start are contained within a security sandbox, much as applets run in a browser. At its most restrictive, the sandbox prevents the application from obtaining unfettered access to system resources including network interface, operating environment parameters, and the file system. To counter these restrictions, Web Start offers services that can be invoked by applications to provide carefully monitored access to additional system resources. If these services don’t provide sufficient capabilities to meet the application’s needs, Web Start-deployed applications can be signed via Java Archive (JARs) files, namely keytool and jarsigner, to gain the full rights to which application developers are accustomed.
Deploying an application through Web Start requires two steps. The first, and most basic, is packaging the required application resources. At its easiest, this means simply using the JAR application to place the application’s class files into one or more jars. The application JARs must be placed on a Web server to which users have access.
The bulk of the work required to enable Web Start is the creation of a JNLP file. The minimum required elements in a JNLP file are easily created, as shown in Listing A, which is the launch file for the draw demo on Sun’s Web site. One important item in this file is the codebase attribute, which is used to resolve any relative URLs in the remainder of the document. The JAR tags supply the list of JARs that should be included in the application’s classpath. The application’s desc tag provides the name of the class that contains the main method to be executed. The Web Start developer’s guide offers a full description of each element, including system property definitions, application arguments, and desktop icon specification.
Running the application
Running a Web Start-enabled application is handled entirely via user clicks on jlnp links in Web pages. Web Start will download the required resources as indicated in the JNLP file; JARs download via HTTP and cache on the local system. Web Start then invokes the main method on the class specified in the JNLP file’s application desc element.
On subsequent invocations of the same application, Web Start will contact the server to see if any of the required resources have been updated. If so, it will download those items and replace the cached runs. If during invocation the server is unavailable, Web Start will use the cached jars to launch the application.
When a user has run an application twice, Web Start will ask if the user would like to save a shortcut to that application on the desktop, which generally provides the user with an easy way to return to an application.
More Web Start
For more information about Web Start, check out the article “Deploy apps faster and easier with Java Web Start.”.
Users can also take advantage of the Web Start application manager interface, which is displayed when Web Start is invoked without a specific JNLP target. The interface displays a list of all the cached applications. In addition to cache and preference management tasks, the application manager allows users to launch any previously run Web Start deployed application.
In future articles, I’ll talk about the JNLP sandbox, services, and application signing.