In the growing market of the software industry today, users are clamoring for client applications that can be run not only from a desktop environment but also from the Internet. Users want the same functionality and support from Web-based applications as they get from those on their desktop, preferably packed with a thin-client interface. The most common solution, currently, is to develop two separate Java applications: one that executes as a desktop application and one that simulates much of the functionality of a desktop application, but is accessed from the Web. This is a burden to developers, who are required to write two separate applications that perform the same on different execution environments, but it is also a financial burden to software companies, which are forced to provide support for two separate applications. To alleviate this problem, Sun Microsystems has introduced Java Web Start, a client-side technology that enables Java applications to launch either from a desktop or from a Web page. This eliminates the need to develop Java support for Web applications, and also provides an efficient means to upgrade, maintain, and manage client-side Java applications with the support of any common Web server.
Java Web Start is a software technology that encompasses the portability of applets, the maintainability of Servlets and JavaServer Pages (JSP) technology, and the simplicity of markup languages such as XML and HTML. It is a Java-based application that allows full-featured Java 2 client applications to be launched, deployed, and updated from a standard Web server. Upon launching Java Web Start for the first time, the user may download new client applications from the Web; thereafter these applications may be initiated either through a link on a Web page or (in Windows) from desktop icons or the Start menu. Applications initialize quickly under Java Web Start, are cached on the client machine, and can be launched remotely offline. Additionally, because Java Web Start is built from Java 2 technology, it inherits the Java platform's complete security architecture.
Since Java Web Start is, in itself, a Java application, the software is platform independent and can be supported on any client system that supports the Java 2 platform. Java Web Start performs an update automatically when a client application is launched, downloading the latest code from the Web while simultaneously loading the application from a previous cache (provided that a cache exists). Java Web Start also provides a Java Application Manager utility, allowing end-users to organize their Java applications as well as providing a variety of options, such as clearing the cache of downloaded applications, specifying the use of multiple JREs, and setting HTTP proxies.
Java Web Start and the Java Plug-in serve one common purpose: to allow Java programs to run securely on any platform, from anywhere. Both Java technologies provide a "sandbox" secure environment from which Java programs may be launched and executed, as well as having the capability to cache applications and specify a JRE to use. The fundamental difference between Java Web Start and the Java Plug-in is that the Java Plug-in is restricted to running Java applets within the context of a Web browser. The Java Plug-in relies heavily on the JRE of the Web browser and cannot be executed without the browser running. Java Web Start, on the other hand, can launch a Java application from a single click on a link within a Web page or from a single click from the Java Application Manager. Within a Windows operating system environment, users can launch an application from the Start menu or by simply double-clicking on a desktop icon. A client application launched from a Web browser will not be impacted if the browser window is closed.
Although Java Web Start does support Java applets and does contain a built-in Appletviewer, the technology's primary purpose is to launch and deploy Java client applications. Some restrictions, such as policy files for applets, are not supported.
Java Web Start not only allows developers to develop applications (not just applets) that can be launched and executed from a Web page but also emphasizes a deployment scheme that provides transparent updates to existing client code without any user interaction. To help you understand this process, and to help you decide whether or not to develop your applications for compatibility with Java Web Start, we'll look at this product from the user's perspective. I'll start with a basic explanation of the two essential user scenarios: installing Java Web Start and downloading and launching applications from the Web using Java Web Start.
Unlike the Java Plug-In, which does not require the user to install any application program on the client machine, Java Web Start must be installed on every client machine that will be used to launch Java applications from the Web. When a user attempts to launch a Web-based application using Java Web Start, the Web browser will launch Java Web Start to start downloading the appropriate files.
If Java Web Start is installed on the local machine, then the desired application will launch and proceed normally. On the other hand, if Java Web Start is not installed, the user will be prompted to download the program. Once the user has agreed to download Java Web Start and the file has been downloaded, the user must run the program to install Java Web Start, as shown in Figure 1.
Figure 1. Installing Java Web Start
During the installation process, the Java Web Start setup program will determine if a Java 2 environment is installed on the client machine. If not, a setup dialog will appear, as shown in Figure 2.
Figure 2. Java Web Start searching for a Java 2 environment
Once Java Web Start has been installed, any open Web browsers must be shut down. A new MIME tag, with the extension of jnlp, is defined for the Web browser in order for the Web browser to initiate contact between itself, the Web server, and Java Web Start. (JNLP is an acronym for Java Network Launching Protocol. The JNLP file determines which JAR files and resources contribute to a client-side Java application.) Once the Web browser has been shut down and restarted, the user may, once again, click on the same link to launch the desired application. The Web browser will then contact Java Web Start and the application will begin the launching procedure.
When a user clicks on a link to launch a client-side Java application for the first time, the following process occurs:
- The Web browser is instructed to run Java Web Start.
- Java Web Start begins by launching a splash screen.
- Java Web Start then connects to the designated Web server and determines if any files have been downloaded for the desired Java application.
- The appropriate files are downloaded to the local machine.
- Java Web Start runs the downloaded application.
Java Web Start, along with the Java Web Start Application Manager, provides a consistent look-and-feel interface, as well as providing feedback to the user throughout the installation and launch process. Figure 3 shows the window that appears when Java Web Start first attempts to launch a client Java application.
Figure 3. Java Web Start downloading the client JAR files
After Java Web Start has downloaded an application to the local machine, the client program is executed. In the future, when a program is launched again from Java Web Start, Java Web Start will attempt to determine whether the client has the most current version of the application. During this procedure, a window similar to the one shown in Figure 4 will appear to the user.
Figure 4. Java Web Start checking the version of the application
From a user's perspective, the windows provide visual feedback that the client Java application is either in the launching process or in the update process. Additionally, the progress bar and the text feedback not only inform the user of how much time either process will take but also give the user a sense of when the update or launch will be complete. This is perhaps one of the product's most useful features, ensuring that users are informed of what is happening at every step of the application launch procedure.
The Application Manager's GUI (Graphical User Interface) provides a simple yet reasonable interface that allows users to specify a variety of options when launching an application. Each time the Application Manager is initiated a splash screen appears, as shown in Figure 5.
Figure 5. The Application Manager splash screen
Once the splash screen has disappeared, the main window for the Application Manager is displayed, as shown in Figure 6.
Figure 6. The Application Manager's main window
Within the Applications box, all the applications that are launched from Java Web Start can be viewed and launched. In the box below that, additional information is provided regarding the selected Java application (that is, in Figure 6, Draw 4), such as the vendor, the home page where more information can be found about the application, and a description of the program. This information is derived directly from the application's JNLP file (more on JNLP in a moment).
Under File Preferences, there are a variety of settings for the user to adjust and calibrate. Although most of these settings are auto-configured by Java Web Start, users are allowed to override various settings, such as the proxy settings, as shown below in Figure 7.
Figure 7. The Application Manager's Preferences tab
Users may also specify which version of JRE to use when launching an application, as shown in Figure 8.
Figure 8. Specifying the JRE
In essence, the purpose of the Application Manager is to provide a consolidating utility for managing all applications that adhere to Java Web Start guidelines and policies. In addition, the Application Manager allows more experienced users to configure some application settings. This offloads some of the work that developers would otherwise need to do, such as writing scripts or bat files to launch or configure an application. It is important to note that the Application Manager is useful only for applications written for the Java 2 platform and in compatibility with Java Web Start. The utility cannot detect other Java applications that reside on the local machine.
When choosing whether or not to develop your applications for compatibility with Java Web Start, it's wise to consider the full range of the user experience.
- Java Web Start must be installed on every machine that launches a client Java application from either the Web or from the Java Application Manager. Therefore, while a client Java application may be launched from a Web page, the application itself cannot be launched without first having Java Web Start installed on the local machine; thus the Web browser simply provides a convenient link for launching the program -- nothing more and nothing less.
- Java Web Start is only useful for applications that have been packaged correctly and in accordance to the Java Web Start guidelines. Additionally, a Web server is needed and must be
configured correctly to interpret all JNLP and MIME tags. Therefore, unless all client Java applications that are downloaded or launched from the Web meet these requirements, not every client Java application can be launched and managed from Java Web Start.
- There might be a slight confusion of the differences between applications and applets for Java Web Start and the Java Plug-In among users. Users may or may not understand why Java Web Start can manage and launch a list of client Java applications but is unable to have any connection to Java Applets that run with the Java Plug-in, despite the fact that either program can be launched from a Web browser.
- For users that are required to download Java Web Start for only one client Java application, again, the features of the Java Web Start Application Manager may be considered cumbersome and the installation process can be considered too much "hassle" for the execution of one client Java application.
- Java Web Start can only be used for client Java applications written for the Java 2 platform.
- Java Web Start can currently execute on Windows 95/98/NT/2000, Linux, and Solaris
From a development point of view, you should be able to write and design code for compatibility with Java Web Start as you would for a normal client-side Java application. You should be relatively free of worrying about packaging issues and roundabout techniques needed to update existing client code. The following are some simple rules you will need to adhere to when developing and deploying client-side Java applications for Java Web Start:
- Applications can be written normally as stand-alone applications for the Java 2 platform.
- If your application will need access to the local system, then each entry in a
JAR file must be signed.
- All the files for your application must be stored in a set of JAR files, including resources
such as images and sound files.
- Any access to load resources, such as images, must use the
getResourcemethod with a class loader. See Listing 1 below for an example of using the
//Obtain the current classloader ClassLoader classLoader = this.getClass().getClassLoader(); //Load the company logo image Image companyLogo = classLoader.getResource("images/companyLogo.gif");
The first time an application is downloaded from a Web server, all of its associated JAR files are downloaded to the local machine. Java Web Start will automatically determine where these files should be downloaded to, because default security protocols (such as local disk access) do apply. Security will be further discussed below.
From the perspective of application development and maintenance, Java Web Start makes updating application code easy. Because all the files for downloaded applications must be contained in a set of JAR files on the client machine, you need only to update the set of JAR files stored on the Web server. Java Web Start will determine, based on a versioning scheme discussed below, which files and resources need to be downloaded and updated on the client machine when the application is initially launched. Each time the user launches an application, Java Web Start will connect to the Web server that contains the set of JAR files and will download the appropriate files. Note that the only resources that a client may download are JAR files, images, and JNLP files.
Java Web Start uses HTTP requests to obtain resource files from a Web server, and also allows client-side Java applications to execute from behind a proxy server or firewall. Initially, Java Web Start will try to detect the proxy settings defined in the default Web browser of the local machine as well as using common proxy auto-configuration scripts. If additional information is needed, the Application Manager may be used to specify ports and proxies using the Preferences section.
To enable your Java application to execute using Java Web Start, you must create a Java Networking Language Protocol (JNLP) file for the application. The JNLP is an XML file that provides the basic elements and descriptions for your application. The JNLP conforms to the Java Community Process (JCP), under specification number JSR 000056 (see Resources).
The purpose of the JNLP file is as follows:
- To specify JAR files to download from the Web server
- To provide other possible package requirements
- To specify system properties
- To allow for any necessary run-time parameters
- To specify which version of the Java 2 platform to use
The JNLP file obtains and locates files in a manner similar to a Web browser, using only URLs and not specific file names. Listing 2 shows an example JNLP file.
<?xml version="1.0" encoding="UTF-8"?> <jnlp codebase=http://www.companySite.com/javaApp> <href="clientApp.jnlp"> <information> <title>This is my company's Java client application</title> <vendor>Company name</vendor> <icon href="companyLogo.gif"/> <homepage ref="reference/tips.html"> <offline-allowed/> </information> <resources> <j2se version=1.3/> <jar href="companySong.jar" part="music" download="lazy"/> </resources> <resources os="Windows"/> <nativelib="windowIconsForWindowOS.jar" part="windowIcons" download="eager"/> <application-desc main-class="com.company.ui.Client"/> <security> <all-permissions/> </security> </jnlp>
The following observations about the example JNLP file may assist you in creating your own files:
- In the first line, you can see that the encoding of the file is UTF-8 character encoding. Therefore, when editing a JNLP file, the final file should be converted using the native2ascii tool that is provided with the JDK to ensure a proper encoding of the file.
jnlp codebaseattribute is used to specify all relative URLs used in the JNLP file. The
hrefattribute is set (required) in order to have the application incorporated within the Java Web Start Application Manager.
- The information tags, such as title, vendor, and so forth, are used to provide additional information about the application from the Java Web Start Application Manager. The
homepage refattribute is specifically used to point to a Web URL so that a user may go to a Web page that provides more information about the application. The most interesting information tag is the
offline-allowedattribute; this attribute determines if the client Java application can be launched offline. When running a client Java application offline, Java Web Start will continue to determine the most recent files from the Web server; as in most cases, this scenario results in a quick timeout (because the location is specified to be launched offline) and the application is launched from the local cache.
- The resource tags allow for the JNLP file to specify which JAR files the application uses as well as how to download the JAR files; that is, either eagerly or lazily. This feature is quite useful when a client has a large number of files to be downloaded but not all the files are required for the client to execute. By default, most resources are downloaded eagerly, in which case the JAR files and resources are downloaded before the
application is launched. Resources that are downloaded lazily are only downloaded when the Java virtual machine (JVM) triggers a resource or file to be loaded from the application. An
example of a resource to be downloaded lazily would be the help files for a client; until the user actually requested a help file from the client, the files would not be downloaded, allowing for a faster launching and execution of the client. However, once the user had requested a help file, the appropriate JAR file will be downloaded during this request, with a window informing the user of an approximate download time.
- The last interesting tag within a JNLP file is the
securityattribute. By default, any client Java application that is launched from Java Web Start is executing within a secure, restricted environment in which local file access, network connections to other computers, and so forth are not allowed. However, for rich-featured clients that do want to have full access to the client machine and to the network, the
all-permissionsvalue is used to give the client complete access. To have full access to the local machine, all JAR files and resources used and loaded by the Java application must be digitally signed. Security is further discussed below.
To provide a more convenient and efficient packaging scheme for the JNLP file and the JAR files associated with an application, Java Web Start enables the distribution of Web Archive (WAR) files. A WAR file is a directory structure that contains a servlet that is packaged with a JNLP file and JAR files so that the entire bundle can be deployed easily on a Web server. The servlet itself is packaged in the jnlp-servlet.jar file, with
JnlpDownloadServlet serving as the main executing Java class that will be responsible for various tasks, such as:
- Generating JARDiff files
- Versioning based either per file or per directory in the WAR file
- Supporting download protocols as defined in the JNLP file
- Automatically installing URLs into the JNLP file, thereby eliminating the need for developers to hardcode URLs
It isn't essential that an application be bundled with a WAR file in order to be launched by Java Web Start. However, the addition of the WAR file could improve both management and upgrades to files stored on a Web server. The topic of WAR files is far too lengthy for the scope of this article. See Resources for links to additional information.
So far, we've discussed the overall deployment and management techniques required for both developers and users who want to implement Java Web Start. Before we go further, I'll summarize the deployment steps I've covered so far.
- The files used by the application are stored in JAR files.
- A JNLP must be created to inform Java Web Start of which JAR files are used by the application, how to download the necessary files, and so forth.
- A standard Web server is configured to accept MIME types understood by Java Web
- The JAR files are placed on a Web server.
- The user is required to download and install Java Web Start (one time only).
- The user runs the application for the first time; the JAR files are downloaded and then executed.
- The user may run the application again, launching it from either the Java Web Start Application Manager or a Web page. Java Web Start will download any files that need to be updated and then launch the application.
From a technical point of view, this summary may raise a question: how does Java Web Start determine which files are necessary to update? The answer is simple: the JNLP file. A unique URL with a version ID is associated with each resource defined in the JNLP file, as shown in Listing 3.
<jar href=http://www.companySite.com/javaApp/imageFiles.jar version="1.1+">
When an application is launched, Java Web Start inspects the JNLP file and creates an HTTP
GET request with the URL and version ID. If no version attribute is specified, then Java Web Start simply creates an HTTP
GET request of the JAR file. The
response status code and MIME type from the Web server are inspected by Java Web Start to determine if the JAR file has a newer version.
The JNLP file also allows JAR files to be updated incrementally, using the
JARDiff utility. The
JARDiff utility can download only specific files within a JAR file (and not the entire JAR file itself), thus enabling a faster download. See Resources to learn more about determining the configuration of a JNLP file.
Perhaps the most important issue to consider when deciding whether or not to develop your applications for compatibility with Java Web Start is security. Java Web Start allows client-side Java applications access to a variety of local-machine resources, such as file access, clipboard access, and so forth. Being derived from the Java 2 platform, however, the product inherits that platform's security architecture. As mentioned previously, the security attributes defined in the JNLP file determine the level of security that an application may have when launched via Java Web Start. By default, a restricted environment is employed, granting an application limited access to the network and the local machine. As with the applet sandbox, this guarantees that a malicious application cannot do any harm.
Another key element of Java Web Start's security is the use of digital code signing. When an application is launched or updated, its JAR files are downloaded to a client machine. Java Web Start uses the digital codes in those files to determine if any JAR files have been altered or modified since the initial signing of the files. If there is an inconsistency or if the files have not been signed, the application will not be launched from Java Web Start. Applications that have been signed correctly may have access to the local machine.
When running an application that requests unrestricted access to the local machine, the user will be initially presented with a dialog that explains the origin of the application or vendor and allows the user to grant additional privileges to the application. Furthermore, when an application requires the use of a local machine's resources and does not have a signed JAR file, Java Web Start will allow the user to explicitly grant the application the access via a Security Advisory dialog. For example, if a client Java application needed to be able to paste information into the Windows OS clipboard facility, a dialog box similar to the one shown in Figure 9 would appear.
Figure 9. Security Advisory dialog for application attempting to access the clipboard
Additional dialog windows will appear when an application attempts to access the local resources of a client machine, such as the filesystem, as displayed in Figure 10.
Figure 10. Security Advisory dialog for application attempting to access the filesystem
Users can grant applications access to the local machine in the following areas:
- Storing the current state of the application on the local machine
- Viewing the contents of local files
- Saving files to the local machine
- Opening files to the local machine
- Reading/writing to random access files on the local machine
- Printing from the local machine
Various classes in the JNLP API library allow developers to use a system's resources in an untrusted environment, assigning the user the responsibility to decide if the operation should be permitted.
Java Web Start offers a creative solution to developing and deploying client-side Java applications. Users are presented with a broad variety of options for launching, updating, and managing Java applications. Java developers gain the freedom to engineer software without much concern for the process of code fixes, updates, and distribution. Although the technology is new, Java Web Start is an attempt to define an industry standard. With its foundations in the proven Java 2 security architecture, Java Web Start has the potential to establish a common, consistent protocol for launching and deploying Java applications from the Web and the desktop.
|Sample code||j-webstart.zip||1 KB||HTTP|
- Download Java Web Start and view some demos of its use.
- Sun's "Developer's Guide for Java Web Start" offers technical details on Java Web Start and the FAQ provides answers to many common questions.
- JNLP is being developed under the Java Community Process.
Steve Kim holds a BS degree in Computer Science from North Carolina State University, with a minor in Science and Technology. He is a Sun Java Certified Programmer for Tivoli-IBM and works on client-side application development in Research Triangle Park, NC. Contact Steve at email@example.com.