Introducing Java Web Start Technology

Underlying Assumption: People still want to run applications

"Not everything fits inside a Web browser. The driving force behind this product is the deployment of applications on the Web. We want it to be easier for users on the Web to get applications and use applications," said René Schmidt.

• One Click Activation--no additional steps
• Any browser--any version of Netscape, any version of Internet Explorer
• Any platform--all Java supported environments
• Anywhere--desktop,laptop, wireless, and so on
• Secure Paradigm

"First we go to a browser, like Internet Explorer, and on the Web page is a link. Instead of going to a Web page, you get an application. Java Webstart will make sure that all the resources for this application will be downloaded to the computer and then it starts the application," Schmidt said.

The application is launched in the sandbox, so it is secure. Access to crucial system resources is mediated by the JVM and is checked in advance by a SecurityManager class.

The application is hosted on a Web server. There is an HTML page, a JAR file which contains the code, and a Java Network Launcher Protocol (JNLP) file. Also, a helper application is launched. Once the application is cached locally, it is ready to run.

User Benefits

• One-click launch from any browser
• Fast second-time activation
• Robust applications
• Desktop integration
• Platform-neutral Application Manager
• Java technology and HTML seamlessly integrated
• Small download
• Secure and safe

Developer Benefits

• Transparent updates for free
• Supports multiple JREs
• Code signing and sandboxing
• Automatic installation of JREs
• Works with any Web server
• Application can show URL in browser
• Pre-configured proxies
• A better sandbox--ability to import/export files to local disk

The second time the application is clicked, there is no download phase. There is a quick check back to the Web server to look for software updates. If there is an update, it will be downloaded, otherwise the application just takes off.

"You can specify on the server what JRE you want to run on," said Schmidt. "And if the local machine does not have the latest version, then Java Web Start can actually download and install that JRE on the user's machine in a fully automatic way. Updates to the software are also handled in an automated fashion. At application launch, even if the application is cached, Java Web Start checks for software updates, and if they exist, they are downloaded and installed automatically."

"This is very significant," Schmidt said, "because it ensures complete environmental integrity for the application, which will eliminate the most common types of configuration and execution problems."

The Java Web Start security sandbox is based on well established Java technologies, which are already used for applets. Since the application is running outside the browser, there is only one way to sign the code, no matter what Web browser is in use, or what platform the client is running.

Data transmission bottlenecks are a constant concern, and deploying applications to end users helps to alleviate them. This is the strength of Java Web Start.

But one of the great strengths of tradition browser-based content is that everywhere in the world, everyone has access to the same information, presented in a consistent way. Java Web Start extends this paradigm to the domain of client-side applications.

Java Web Start offers:

• One-click access to services
• Transparent updates
• Access from anywhere

It is web-centric in the sense that the state is stored on a server.

Motivating factors are that people like applications, but they hate installing them, uninstalling them, upgrading them--the whole process is very problematic. Java Web Start alleviates these problems in a seamless way.

Usage Scenario

Many JavaOne attendees were using HTML-based email to pick up their email on workstations. If a richer email application was available through Java Web Start, it could be invoked with one-click access, just a like an HTML based application. And the functionality could be much more advanced. In this case, an email application might reduce server load by allowing email to be downloaded to the application, then dealt with locally until further communication is actually needed.

When to Use Web Start Technology?

HTML limitations:

• Limited interactivity
• Required to be on-line
• Limited use of client-side resources
• Potentially non-portable (DHTML)

Native Clients Limitations:

• Typically Windows-only or Windows-first
• Non-uniform installation/upgrade path

If users want greater interactivity, or they want to go offline--these may be motivators for using a client side application using Web Start. Client machines are now more powerful and capable of performing sophisticated processing.

What are the Tradeoffs?

First time activation is slower than HTML.

The download time for first-time invocation is on the order of minutes, as opposed to seconds for HTML. Subsequent invocations, however, will take the same amount of time as invoking any other application.

Java Web Start Technology Details

• Technology is being developed through the Java Community Process initiative JCP
• JSR-56: Network Launching Protocol and API for the Java platform ("JNLP")
• Expert Group: KL Group, SilverStream, and others

Java Network Launching Protocol (JNLP) File

A JNLP Client (such as a helper application for a Web browser) can automatically download, cache, and launch an application. JNLP is designed to minimize user interaction. For instance, it can be configured so that a user is not prompted for installation directories when the application is launched. Software updates will typically be programmed in the same automatic fashion.

The JNLP file is an XML document that describes an application or an extension.

Application Descriptor

Most commonly, a JNLP file is referred to as an application descriptor. It contains all the information that defines an application:

• JAR file contents
• JREs and optional packages
• Application name and other display information
• Application runtime parameters and system properties

There is a one-to-one correspondence between an application descriptor and an application.

The JNLP file is similar to a traditional executable format. Traditionally applications are delivered as binary platform-dependent files. For example, on Windows, an application is delivered as a MyApp.exe executable. The executable format is designed so the Windows operating system can load the application and execute it. It also contains information about external dependencies, for example . This format is file-centric: all external references are references to files on the local file system.

In contrast, the JNLP file does not contain any binary data itself, but instead contains URLs pointing to where the data can be obtained. The JNLP file format is web-centric: the references to external resources are URLs, instead of file names.

The external resources referred to by a JNLP file are image files that can be used as icons, JAR files for the executable code, and extensions. Extensions are a JNLP concept that covers downloadable contents such as optional packages and JREs.

Extension Descriptor

Using an extension descriptor, a set of related resources (such as JAR files) can be bundled together. This simplifies writing application descriptors, since dependencies on a single extension can replace dependencies on a potentially large set of JAR files. For example, a JNLP extension could be the Java 2 SE optional package for XML parsing. This extension might be used by a large number of applications. Thus, by factoring the resources used for the XML parsing out into an extension descriptor, the job of writing application descriptors becomes more manageable.

The term extension in this specification covers a wide variety of libraries. An extension can contain platform-specific native code as well as JAR files. Thus, virtually any kind of code can be delivered using the extension mechanism. An extension will typically provide new APIs for one or more JREs, for example an optional package. But it can also contain a new JRE.

Thus, extensions are not limited to just adding functionality on top of a JRE, but can actually contain a new version of a JRE.

A JNLP file that describes an extension is called an extension descriptor. The extension descriptor contains two parts:

• JAR files that implement the API for the extension.
• An installer which installs native code for the extension.

Similar to the application descriptor, the extension descriptor does not contain any binary data itself, but contains URL references to how it can be obtained from the Web. A primary feature of extensions is that they can contain platform-dependent JAR files and/or native code. The JNLP Client communicates the platform requirements to the Web server when it downloads an extension, and the Web server can return different implementations for different platforms. Platform-dependent native code must be installed by the installer part of an extension.

Extensions provide a versatile mechanism for the JNLP Client to get new updates of the Java 2 platform and for application developers to bundle their libraries in a way that makes them instantly available for use in JNLP files.

Downloading Resources

The JNLP Client can download four different kinds of resources: JAR files, images, extensions, and JNLP files. All resources in a JNLP file are uniquely named using either a URL or a URL/version-id pair. A typical application deployed using JNLP will consist of a set of JAR files and a set of images. The image files are icons that can be used by the JNLP Client to integrate the application into the desktop environment. They are not for use by the application itself. JAR files, images, and JNLP files can be downloaded using standard HTTP GET requests. For example:

http://www.mysite.com/app/MyApp.jar

This basic download protocol works from a standard unmodified Web server. This leverages existing Web server technology, which is important to achieve wide-spread use of a new technology on the Internet.

To provide more control and better utilization of bandwidth, a version-based download protocol is also supported. The version-based protocol is designed to:

• Allow several versions of an application to coexist on a server at a given time. In particular, this means that an application that is distributed as several JAR files can be safely upgraded. A JNLP Client that is downloading JAR files right as a Web server is being updated will never download JAR files that are a mix between two application versions.
• Provide a unique URL for an application independent of its version. This allows a JNLP Client to automatically detect and flush old versions out of the cache.
• Make it possible to incrementally update already-downloaded JAR files. This can substantially minimize the download requirements for upgrading to a new version.
• Allow users to stay with a given version rather than always receiving the latest version from the Web server. For example, a JNLP Client can download an updated version in the background, while the already-downloaded version is being used.

The version-based protocol requires special support on the Web server. This support can be provided using servlets, CGI-scripts, or by similar means.

The use of the version-based protocol is specified in the JNLP file on a per-resource basis. Depending on the facilities the Web server offers (and possibly other factors), the application developer can choose whether the version-based protocol should be used or not.

The only exception is for extensions, which must be downloaded from a Web server that supports this version-based protocol. Most applications can be deployed without requiring the use of extensions.

Caching and Offline Launching

JNLP is a launching protocol, not a general installation protocol for software components. A high-level model of a JNLP Client is represented by pseudocode that would allow URLs in the classpath argument of the java command, for example, something like this (not legal code):

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

com.mysite.app.Main

An application deployed using JNLP is not "installed" in the traditional sense before it is launched. In fact, not all JAR files need to be downloaded before an application is launched. A JAR file can either be eagerly downloaded before an application is launched, or be lazily downloaded during the execution of an application. (Lazy download is a standard feature of the Java 2 class loading mechanism.)

Conceptually, all resources always reside on the Web server. A JNLP Client is allowed and encouraged to cache resources that are downloaded from the Web. This will improve consecutive startup times and minimize network traffic. All resources are uniquely named with either a URL or with a URL/version-id pair. Those names must be used as keys into the cache. The cache mechanism is implementation-dependent. For example, it could be a directory hierarchy on the local file system or the resources could be kept in a database.

For extensions that have installers, the installer must be able to both install and uninstall the extension. Thus, extensions are not necessarily installed permanently on the local system.

If all resources that a particular application needs are cached locally, then a JNLP Client can launch the particular application without being online. However, most applications deployed using JNLP are expected to be web-centric, in other words, they will typically connect back to a Web server or database to retrieve their state. Hence, many applications will only work online. In the JNLP file, it can be specified if the application will work offline or not.

A JNLP Client can, for example, use this information to prevent an application from being launched if the system is offline.

Application Environment

The application environment defines a common set of services and system settings that an application launched with JNLP can depend on. The core of this environment is the Java 2 Platform Standard Edition. In addition, this specification defines additional APIs and settings:

• Configured HTTP proxies.
• A secure execution environment that is similar to the well-known Applet sandbox.
• An API to securely and dynamically lookup and access features on the client platform, such as instructing the default browser to display a URL.

The application environment is defined as a set of required services that must be implemented by all implementations that conform to this specification, and a set of optional services that are not required to be implemented. Applications must check for the presence of optional services and handle their absence sensibly.

An Example

When a user clicks on a link pointing to a JNLP file, the browser will download the file and invoke the helper application with the name of the downloaded file as an argument. The helper application (the JNLP Client) interprets the JNLP file, which will direct it to download and locally cache the JAR files and other resources for the particular application. When all JAR files have been downloaded, the application is launched.

A sample JNLP file, which is an XML document, is shown below:

<?xmlversion="1.0" encoding="UTF-8"?>

<!--JNLP file for SwingSet2 Demo Application -->

<jnlpcodebase="http://www.mysite.com/app">

    <information>

     <title>SwingSet2 Demo</title>

     <vendor>My Web Company</vendor>

     <homepage href=/old?u=http%3A%2F%2Fdeveloper.java.sun.com%2Fdeveloper%2FtechnicalArticles%2Fjavaone00%2Fdeveloper%2F%26quot%3Bdoc%2Findex.html%26quot%3B%2F%26gt&y=1999

     <icon href=/old?u=http%3A%2F%2Fdeveloper.java.sun.com%2Fdeveloper%2FtechnicalArticles%2Fjavaone00%2Fdeveloper%2F%26quot%3Bswingset2.jpg%26quot%3B%2F%26gt&y=1999

     <offline/>

 </information>

 <security>

    <unrestricted/>

 </security>

  <jre version="1.3"

  <resources>

  <jar href=/old?u=http%3A%2F%2Fdeveloper.java.sun.com%2Fdeveloper%2FtechnicalArticles%2Fjavaone00%2Fdeveloper%2F%26quot%3BSwingSet2.jar%26quot%3B%2F%26gt&y=1999

 </resources>

<application-desc main-class="com.mysite.SwingSet2"/>

 </jnlp>

The JNLP file describes how to launch the demo application SwingSet2. In the JNLP file, it is specified that the Java 2 platform, version 1.3 is required to run this application, along with some general application information that can be displayed to the user during the download phase.

Comparing JNLP with other Technologies

The JNLP technology is related to Java Applets. Java Applets are automatically downloaded, cached, and launched by a Web browser without requiring any user interaction. And Applets are executed in a secure sandbox environment by default.

Applets are a core part of the Java 2 SE. Many of the technologies that are used by JNLP are borrowed from the Applet technology, such as the downloading of code and the secure sandbox.

Applications launched with JNLP do not run inside a browser window, but are instead separate applications that are run on separate Java Virtual Machines (JVMs). Thus, applications launched with JNLP are typically more like traditional desktop applications that are commonly distributed as shrink-wrapped software, in other words on CDs.

JNLP is not intended to be a general installer for applications. It is particularly targeted to Web-deployed Java Technology-based applications. Specifically, applications that can be downloaded from the Web and which store most of their state on the Web.

The JNLP protocol defines how Java Runtime Environments and optional packages can be installed automatically. This will typically require the JREs and optional packages to be bundled in a traditional installer.

Reference URLs

Java Network Launcher Protocol and API Specification

JNLP Spec.pdf

Java Web Start

Presentation Slides