Java Web Start (JWS) allows you to launch full-featured Java applications with a single click from yourWeb browser. Sun Microsystems introduced version 1.0 of the framework in March 2001. Since J2SE version 1.4, it has been included by default with the Java Runtime Environment (JRE) and does not have to be installed separately. In this article, I review the main points of this important technology.
JWS is a helper application that gets associated with a Web browser. When a user clicks on a link that points to a Java Network Launching Protocol (JNLP) file, the browser launches JWS, which then automatically downloads, caches, and runs the given Java technology-based application.
The technology underlying JWS is the JNLP & API, which was developed via the Java Community Process. JWS is the reference implementation for the JNLP specification. The JNLP technology defines, among other things, a standard file format that describes how to launch a JNLP file.
Since installation links can be provided as usual HTTP URL links, someone on your development team may want to introduce a check to see if JWS is installed on the client side of a Web page. You can detect this in IE, for example, by using the following code:
on error resume next
If isIE = "true" Then
If Not(IsObject(CreateObject("JavaWebStart.isInstalled"))) Then
javawsInstalled = 0
javawsInstalled = 1
If Not(IsObject(CreateObject("JavaWebStart.isInstalled.220.127.116.11"))) Then
javaws142Installed = 0
javaws142Installed = 1
If Not(IsObject(CreateObject("JavaWebStart.isInstalled.18.104.22.168"))) Then
javaws150Installed = 0
javaws150Installed = 1
Developing applications for deployment with JWS is generally the same as developing stand-alone applications for the Java 2 platform. For instance, the entry point for the application is this standard code:
public static void main(String argv)
However, in order to support Web deployment—automatic download and launching of an application—and to ensure that an application can run in a secure sandbox, there are some additional considerations, which include:
- An application must be delivered as a set of JAR files.
- All application resources, such as files and images, must be stored in JAR files; and they must be referenced using the getResource mechanism in the Java 2 platform (see below).
- An application is allowed to use the System.exit call.
- An application that needs unrestricted access to the system will need to be delivered in a set of signed JAR files. All entries in each JAR file must be signed.
- If an application is written to run in a secure sandbox, it must follow these restrictions:
* No access to local disk.
* All JAR files must be downloaded from the same host.
* Network connections are enabled only to the host from which the JAR files are downloaded.
* No security manager can be installed.
* Limited access to system properties. The application has read/write access to all system properties defined in the JNLP file, as well as read-only access to the same set of properties as an applet.
JWS is built on top of the Java 2 platform, which provides a comprehensive security architecture. JWS also includes strong security features in Java 6.0, such as code signing.
Applications launched with JWS will, by default, run in a restricted environment (a "sandbox") with limited access to local computing resources, such as storage devices and the local network. In this sandbox environment, JWS can guarantee that a downloaded and potentially untrusted application cannot compromise the security of the local files or the network.
An application can request unrestricted access to your system. In this case, JWS will display a Security Warning dialog box when the application is launched for the first time. The security warning will show information about the vendor that developed the application.
If an application being invoked is delivered in one or more signed JAR files, JWS will verify that the contents of the JAR file have not been modified since they were signed. If verification of a digital signature fails, JWS will not run the application, since it may have been compromised by a third-party. By including the following settings in the JNLP file, an application can request a full set of permissions.
JNLP is a concept that is closely related to JWS; it is often used interchangeably with the term Web Start. It is the protocol (defined as an XML file format) that specifies how JWS applications are started. JNLP files include information, such as the location of the JAR package file and the name of the main class for the application, in addition to any other parameters for the program. With a properly configured browser, JNLP files are passed to a JRE, which in turn downloads the application onto the user's machine and starts executing it.
A JNLP file does not contain any binary data; instead, it contains URLs that point to all binary data and binary code resources. These files can also refer to other JNLP files, called extension descriptors. An extension descriptor typically describes a component that must be used in order to run the application. The resources described in the extension descriptor become part of the classpath for the application. This allows common functionality to be factored out and described once. Below is the sample of a typical JNLP file:
<?xml version="1.0" encoding="UTF-8"?>
<vendor>My Web Company</vendor>
The JNLP file describes how to launch the sample application titled Hello. In the JNLP file, it is specified that the Java 2 platform, version 1.3 or higher, is required to run this application, along with some general application information that can be displayed to the user during the download phase.
For a more detailed description of JNLP protocol and file formats, please read the specification.
JWS provides a platform-independent, secure, and robust deployment technology. It enables developers to deploy full-featured applications to end users by making the applications available on a standard Web server. With any Web browser, end users can launch the applications and be confident they always have the most-recent version.
One chief advantage of JWS over applets is that it has overcome many compatibility problems with browsers' Java plug-ins and different JVM versions. On the other hand, Web Start programs cannot communicate with the browser as easily as applets.
Peter V. Mikhalenko is a Sun certified professional who works for Deutsche Bank as a business consultant.