| Documentation Contents

# Java™ Rich Internet Applications Deployment Advice

Rich Internet Applications Development and Deployment > Rich Internet Applications Deployment Advice

Contents

- Unified Deployment Mechanism - Java Network Launch Protocol
- Deployment Toolkit Script
- Deploying Java Plug-in Applets
  - Using Applet Tag Attributes
  - Using JNLP
  - Using Applet Tag and JNLP Parameters
  - Determining final deployment information
- Deploying Java Web Start Applications
- Customizing the RIA Loading Experience
- Pack200 and Version Download
- Other Deployment Considerations
  - Order of Installation of JRE's
  - ClassLoader and Accessing Resources
  - Lazy Downloading
- Resources

## Unified Deployment Mechanism - Java Network Launch Protocol

Starting in release Java SE 6 update 10, Java Network Launch Protocol (JNLP) provides a unified mechanism for deploying rich internet applications (RIAs – applets and Java Web Start applications). RIAs launched using JNLP have the following powerful capabilities at their disposal:

- Access to JNLP extensions – Powerful JNLP extensions such as the Java binding to the OpenGL 3D API, the scene graph for the JavaFX run-time, and the NASA World Wind Java planetary and extra-planetary visualization system can now be used from applets and Java Web Start applications.
- Access to the JNLP APIs – Applets and Java Web Start applications have access to the JNLP APIs to gain user-controlled access to persistent storage (the PersistenceService), lazily-downloaded parts (the DownloadService), the local file system (the FileOpenService and FileSaveService), and much more. See the Java Tutorial lesson, Accessing the Client Using JNLP API for step by step instructions about using JNLP API.
- Auto-download, version selection and more – Building on the new Java Plug-in's architecture, applets launched via JNLP may utilize all of the features previously available to Java Web Start applications, such as JRE version selection, auto-download of a particular version of the JRE, passing command-line arguments and system properties to the JVM, and much more.

## Deployment Toolkit Script

To avoid browser compatibility issues, the Deployment Toolkit script provides JavaScript functions that automatically generate the HTML required to deploy RIAs. Developers should invoke these functions to deploy their solutions in a consistent fashion across various browsers.

The script exposes a single object, named deployJava, which contains the following public functions:

- `createWebStartLaunchButton(jnlp, minimumVersion)` - Outputs a launch button for the specified JNLP URL. When clicked, the button will ensure that an appropriate JRE is installed and then launch the JNLP application.
- `createWebStartLaunchButtonEx(jnlp, minimumVersion)` - Outputs a launch button for the specified JNLP URL. When clicked, the button will ensure that an appropriate JRE is installed and then launch the JNLP application. The JNLP file does not require a value for the `codebase` attribute. This function requires that the Java SE 6 update 18 release be present on the client. If the Java SE 6 update 18 release is not present on the client, then the user will be instructed to install the required software.
- `getBrowser()` - Returns the name of the browser currently running.
- `getJREs()` - Returns an array of currently-installed JRE version strings.
- `installJRE(requestVersion)` - Triggers the installation of the specified `requestVersion`, the latest version matching the specified `requestVersion`, or the latest JRE.
- `installLatestJRE()` - Triggers the installation of the latest JRE
- `isPlugin2()` - Determines if the next generation Java Plug-in is the default.
- `isWebStartInstalled(minimumVersion)` - Returns true if an installation of Java Web Start of the specified `minimumVersion` can be detected.
- `launch`- Launches JNLP application.
- `runApplet(attributes, parameters, minimumVersion)` - Ensures that an appropriate JRE is installed and then runs an applet.
- `setAdditionalPackages(packageList)` - Sets additional package list to be used by kernel installer.
- `setInstallerType(type)` - Sets the preferred install type : null, online, kernel.
- `versionCheck(version)` - Returns true if there is a matching JRE version currently installed (among those detected by the `getJREs()` function).
- `writeAppletTag(attributes, parameters)` - Outputs an applet tag with the specified attributes and parameters. The parameters argument is optional.

See the human readable version of the Deployment Toolkit for a detailed description of these public functions. See the following Java Tutorial lessons for more information about deploying RIAs:

- Deploying an Applet
- Deploying a Java Web Start application
- Deployment In-Depth

## Deploying Java Plug-in Applets

In the old Java Plug-in, applets always run with the latest version of JRE installed on a client machine. The old Deployment Security Policy provides more information about this behavior.

With the next generation Java Plug-in introduced in the Java SE 6 update 10 release, you can specify that the Java kernel (core set of Java classes absolutely required by the JRE) or normal online installer be automatically downloaded, if the specified minimum JRE version is not already installed on the client. If the specified minimum JRE version does not exist, the latest version of the JRE is downloaded from `www.java.com`.

In the case of a Java kernel download, any additional packages may also be specified for download as required by the applet.

### Using Applet Tag Attributes

Applets can be deployed via the applet tag. Parameters to configure deployment may be specified as attributes and parameters to the applet tag.

Use the `runApplet()` function in `deployJava` to ensure that a minimum Java Runtime Environment is available on a client machine before launching the applet.

    <script src="http://www.java.com/js/deployJava.js"></script>
    <script>
        var attributes = {codebase:'http://java.sun.com/products/plugin/1.5.0/demos/jfc/Java2D',
                          code:'java2d.Java2DemoApplet.class',
                          archive:'Java2Demo.jar',
                          width:710, height:540} ;
        var parameters = {fontSize:16} ;
        var version = '1.6' ;
        deployJava.runApplet(attributes, parameters, version);
    </script>

The above code will launch the Java 2D applet on JRE version 1.6.0 or higher with one parameter (fontSize).

To trigger the installation of Java kernel and additional packages, add the following before the deployJava.runApplet() function:

       deployJava.setInstallerType('kernel');
       // include any required packages as shown below
       deployJava.setAdditionalPackages('javax.swing, javax.xml');

### Using JNLP

To deploy applets using JNLP, specify the jnlp_href parameter in the applet tag as follows:

     <script src="http://www.java.com/js/deployJava.js"></script>
     <script>
        var attributes = { code:'java2d.Java2DemoApplet',  width:710, height:540} ;
        var parameters = {jnlp_href: 'java2d.jnlp'} ;
        deployJava.runApplet(attributes, parameters, '1.6');
     </script>

In this example, java2d.jnlp has the following deployment information

     <?xml version="1.0" encoding="UTF-8"?>
     <jnlp href="java2d.jnlp">
         <information>
           <title>Java2D Demo</title>
           <vendor>My Company, Inc.</vendor>
           <offline-allowed />
         </information>
         <resources>
           <j2se version="1.4+"
                 href="http://java.sun.com/products/autodl/j2se" />
           <jar href="Java2Demo.jar" main="true" />
           <!-- Specify if using JNLP extensions
                                    <extension name="SomeExtension"
                      href="http://some.server.com/some_extension.jnlp" />
                                    -->
         </resources>
         <applet-desc
             name="Java2D Demo"
             main-class="java2d.Java2DemoApplet"
             width="710"
             height="540">
         </applet-desc>
     </jnlp>

###
Using Applet Tag Attributes and JNLP parameters:

To deploy an applet that runs on the old and new Java Plug-ins, specify the applet tag attributes and JNLP parameters as shown in the example below:

    var attributes = {codebase:'http://java.sun.com/products/plugin/1.5.0/demos/jfc/Java2D',
                          code:'java2d.Java2DemoApplet.class', archive:'Java2Demo.jar', width:710, height:540} ;
    var parameters = {fontSize:16, jnlp_href:'java2d.jnlp'} ;
    var version = '1.6' ;
    deployJava.runApplet(attributes, parameters, version);

#### Determining final deployment information

The applet tag and JNLP file provide overlapping mechanisms to specify the same information. For example, width, height, code etc. may be specified both as attributes of the applet tag and in the JNLP file. The following rules are applied to various attributes in order to determine the final deployment information:

- `width` and `height`: These attributes are always taken from the `<applet>` tag and not from the JNLP file. The assumption is that the browser knows best how big the applet should be on the web page, and only the browser can support page-relative width and height (for example, `width="50%"`).
- `codebase`: It is recommended that you either:
  - leave the jnlp tag's codebase attribute empty for both the main and extension JNLP file, allowing the referencing JNLP file or `<applet>` tag to implicitly specify the codebase, or
  - specify an absolute URL for the codebase of any main or extension JNLP file

  Refer to CodeBase Determination for further information.

- `code`: The `code` attribute in the `<applet>` tag will be ignored.
- Any applet parameters specified using the `<param>` tag are merged with those specified in the JNLP file. If the same parameter is specified via both the `<applet>` tag and the JNLP file, the `<applet>` tag's version overrides the JNLP file's version, except for the `java_arguments` and `java_version` parameters.
- The new `java_arguments` and `java_version` parameters are unnecessary in JNLP applets. The mechanisms in the JNLP file for requesting a JRE version, or passing command-line arguments to the JVM, are used instead. Command-line arguments and JRE version requests from the JNLP file override those specified in the HTML for the applet.
- It may be advantageous to specify certain parameters desired early on in the applet's startup process, such as `image`, `boxbgcolor`, etc. in the HTML instead of in the JNLP file, because these are available immediately upon loading the web page rather than requiring the JNLP file to be downloaded separately first.

## Deploying Java Web Start Applications

A Java Web Start Application can be deployed simply by creating a JNLP file that describes only the title, vendor, java version, jar file(s), and main class of the application. Here is an example of a Java Web Start application's JNLP file:

    <jnlp spec="0.2 1.0"
          codebase="http://java.sun.com/javase/technologies/desktop/javawebstart/apps"
          href="notepad.jnlp">
       <information>
          <title>Notepad App</title>
          <vendor>Sun Microsystems, Inc.</vendor>
          <homepage href="http://java.sun.com/javase/technologies/desktop/javawebstart/demos.html"/>
          <description>Notepad Demo Description</description>
          <description kind="short">Notepad Demo Short Description</description>
          <icon href="images/notepad.gif"/>
          <offline-allowed/>
       </information>
       <resources>
          <j2se version="1.3+" href="http://java.sun.com/products/autodl/j2se"/>
          <j2se version="1.3+"/>
          <jar href="notepad.jar" main="true" download="eager"/>
       </resources>
       <application-desc main-class="Notepad"/>
    </jnlp>

The application can then be deployed simply by providing a link to the JNLP file on your web page:

    <a href="http://java.sun.com/javase/technologies/desktop/javawebstart/apps/notepad.jnlp">Launch Notepad</a>

Many other elements can be added to the JNLP file to control the user experience, security, and update process of the application, or to take advantage of several other features of the Java Network Launching Protocol (JNLP).

Java Web Start can use its Auto-Download mechanism to download the version of the JRE that it requires to run an application, but if the application wants to use advanced features of JNLP and Java Web Start that were added to a particular version, you may want to ensure that at least that version is installed before launching Java Web Start.

Suppose an application wants to use the SingleInstance Service (introduced in 1.5.0). Instead of just specifying <jnlp spec="1.5.0" .../> and letting the application fail on systems where only 1.4.2 or earlier is installed, you can use the deployJava javascript to ensure that at least version 1.5.0 is installed before launching Java Web Start.

    <script src="http://www.java.com/js/deployJava.js"></script>
    <script>
            var url = "http://java.sun.com/javase/technologies/desktop/javawebstart/apps/notepad.jnlp";
        deployJava.createWebStartLaunchButton(url, '1.6.0');
    </script>

For an application not having specific version requirements you can just use the function without supplying minimumVersion.

    <script>
        var url = "http://java.sun.com/javase/technologies/desktop/javawebstart/apps/notepad.jnlp";
        deployJava.createWebStartLaunchButton(url);
    </script>

## Customizing the RIA Loading Experience

Customize the RIA loading experience by providing a splash screen or a customized loading progress indicator to engage the end user during the loading process and to communicate measurable progress information. See the following topics for more information:

- Customizing the Rich Internet Application Loading Experience
- Customizing the Loading Experience topic in the Java Tutorials for step-by-step instructions and examples.

## Other Deployment Considerations

### Order of Installation of JRE's

If multiple JRE's are required to run various Java Plug-in applets on the same machine, it is recommended to install the JRE's in the order of their versions. The oldest version should be installed first and the newest version installed last. This will avoid the problem of the dynamic clsid {8AD9C840-044E-11D1-B3E9-00805F499D93} being used in an object tag that is not using the latest version of the JRE on the machine.

Starting from JRE 5.0u6 with SSV support, the above is not an issue because the latest version of JRE on the machine will be used. In addition, we have added a new dynamic version clsid {CAFEEFAC-FFFF-FFFF-FFFF-ABCDEFFEDCBA}. If the new dynamic clsid is used in the object tag, the latest version of the JRE will be used independently of the installation order of the JRE's.

Installation order should have no effect on Java Web Start. In any case the highest version of the JRE on the system will contain the version of Java Web Start that is run.

### ClassLoader and Accessing Resources

Resources accessed in a Java Web Start application or Java Plug-in applet may be cached on the client machine in the Deployment Cache. It is unwise to assume the format or content of this cache, as it may change between versions.

When porting stand alone programs to Java Web Start or Java Plug-in, problems can occur when code has inherent assumptions that it is loaded by the SystemClassLoader. In Java Plug-in resources are loaded by the PluginClassLoader (which extends sun.applet.AppletClassLoader, which in turn extends java.net.URLClassLoader). In Java Web Start resources are loaded by the JNLPClassLoader (which as of JDK 6 extends java.net.URLClassLoader).

Access the ClassLoader being used with:

>     ClassLoader cl = Thread.getCurrent().getContextClassLoader();

ClassLoader.getResource() returns a URL, but any code that assumes the URL is a JarURL to a FileURL, and then tries to decompose that FileURL to find the underlying file path will fail. The correct way to access resources is to use getResourceAsStream() which will return the correct content whatever type of ClassLoader is used to access the resource. If the resource is already cached, the contents of the resource will be returned from the cache directly, so there won't be extra network connections to the resource itself.

We do not recommend modifying the contents of the Java deployment cache directly. The cache is a private implementation of Java Web Start / Java Plug-in, and is subject to change anytime.

Many applications and libraries try to deploy properties files and other "resources" by including them in the same directory as the jar file that uses them, and then expect to be able to decompose the the URL returned from getResource() to construct the path to these files. Developers argue that this is needed so the application can later modify these property files or other "resources" for use in subsequent launchings of the app. When porting to web deployed applications, they then find they need to repackage these into the jar files of the app, and consider them only the "default" content, and use one of several other mechanisms to persist the modified versions on the client machine (by writing files or by using either the Preference API or the JNLP PersistenceService.)

### Lazy Downloading

When applications are large, it can be useful to only download the part of the application that is required to start up, and then download the rest on demand. This process is referred to as lazy downloading.

Java Web Start has support for lazy downloading, but few developers use it. It can be a way to significantly improve the download and startup time in some applications. To effectively use lazy downloading, Java Web Start must be aware which jar to download to resolve a request for a specific resource. Previous versions of Java Web Start required a complex specification of parts and packages to provide this information. Beginning with version 6.0, the same thing can be accomplished using Jar Indexing.

Jar Indexing is a simple and effective way to download only the required jars, and avoid downloading everything when a nonexistent resource is requested. See Jar Indexing.

Java Plug-in has built-in support for lazy downloading (that is, downloading is lazy by default), and also supports Jar Indexing. Developers should also try to NOT use individual classes but package them as JARs instead.

## Resources

- Client JRE Capabilities - Quick Reference
- Deployment trail in the Java Tutorials

Copyright © 1993, 2010, Oracle and/or its affiliates. All rights reserved. Please send comments using this Feedback page. | Java Technology