Java Rich Internet Applications Guide > Java Rich Internet Applications Deployment Advice
The following topics are covered:
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:
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:
If multiple JREs are required to run various Java Plug-in applets on the same machine, it is recommended to install the JREs 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 computer.
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, a new dynamic version CLSID {CAFEEFAC-FFFF-FFFF-FFFF-ABCDEFFEDCBA} has been added. 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 JREs.
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.
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.)
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.
