This topic provides information to help you decide between an applet or a Java Web Start application for your rich Internet application (RIA). RIAs are applications that take advantage of the Internet.
This topic includes the following sections:
Java technology-based solutions are versatile when developed with good design principles. Two types of RIAs are available, based on their deployment mechanism and execution context:
Applets - These solutions run in the context of a web browser. They utilize the browser capabilities like session cookies, DOM access etc. Applets can be deployed by using Java Network Launch Protocol (JNLP) or by using applet tag attributes.
Java Web Start applications - Java Web Start applications are deployed from a browser the first time. After the application is downloaded and the user has accepted its security certificate, it behaves almost like a standalone application. When run from the user's desktop using Java Web Start, updates to the application are automatically downloaded.
The decision of whether to deploy a RIA inside the browser as an applet, or outside the browser as a Java Web Start application, impacts the design of the solution. However, properly structured programs can be easily deployed either inside or outside the browser.
A key methodology to follow during the design of your application is to use a component-based architecture. Traditional applications tend to construct their user interfaces, including the top-level Frame, in the main method. This programming style prevents easy re-deployment of the application in the browser, because it assumes that the application creates its own Frame. When running in the browser as an applet, the applet is implicitly the container that should hold the user interface for the application, and no top-level Frame is needed or desired.
Instead, during the development of your application, try to organize its functionality into one or more components that can be composed together. In this context, the term "component" refers to a GUI element that is a subclass of the AWT Component class, the Swing JComponent class, or another subclass. Instead of phrasing the application in terms of various methods that build user interfaces and return or show them, phrase the application in terms of Component subclasses, each of which adds their portion of the user interface to themselves. Then the application, which at that point is just a Component (and perhaps, for example, a menu bar) can be added to any kind of Container. The container might be a top-level Frame or an Applet. Using this methodology and architecture makes it easy to redeploy the application either inside or outside the browser, and enables this deployment decision to be changed at essentially any time without significantly impacting the development cycle of the application.
The SwingSet3 demo is an example that shows how to lay out components in a single cohesive unit. This demo is included in the JDK 8 Demos and Samples bundle that you can download. The constructor of the ButtonDemo class instantiates and lays out all required user interface components into one master panel. The DemoModule class is only responsible for displaying this master panel as an applet. This design enables the ButtonDemo to be reused or ported easily to another applet or application.
To determine whether to develop an applet or a Java Web Start application, see Section 11.2, "Rich Internet Applications Decision Guide."
Having decided on the type of client application that you plan to build, the next step is to build it. For applets, use the Chapter 12, "Applet Development Guide" to set up the applet, get the browser and the applet talking to each other, and to communicate with other applets. For Java Web Start applications, use the Java Web Start Developer's Guide.
Debugging is a natural part of development. In addition to using your Java IDE or the Java debugger, you can use the debugging facilities in the Java Console, as well as the JVM's Tracing and Logging capabilities. See Chapter 22, "Java Console, Tracing, and Logging" for information.
The Deployment trail in the Java Tutorials is a comprehensive resource to learn more about the development and deployment of RIAs.
Signing the application JAR files with a valid public key certificate and specifying the runtime permission in the JAR file manifest are critical. Applications that are deployed without these elements might not be allowed to run.
Deployment is a multi-step process. The following list provides an overview of deployment-related steps. See Section 11.3, "Rich Internet Applications Deployment Advice" for more information.
JNLP File: A JNLP file is created for Java Web Start applications and applets that are deployed using JNLP. If the RIA requires access to resources on the user's system, include the security element in the JNLP file. Otherwise, the RIA runs in the security sandbox. See JNLP File Syntax for information on the JNLP file.
JAR File Manifest: The JAR file manifest contains security and configuration information about the JAR file and the files it contains. Manifest attributes provide additional security for RIAs. See Chapter 26, "JAR File Manifest Attributes for Security" for more information.
Security Certificate: RIAs request permission from the user to run the first time they are launched, whether they run in the security sandbox or require access to a user's system. Sign and time stamp the JAR file for the RIA with a certificate from a recognized certificate authority. See Section 23.5, "Security Dialogs" and Section 23.1, "Setting the Security Level of the Java Client" for more information.
JAR Indexing: To keep the application from downloading JAR files before they are needed, use JAR Indexing. Jar Indexing works both for applets and Java Web Start applications. With Jar Indexing, the main JAR file contains an index file that tells which packages are in the other JAR files. When lazy-loading a resource, the underlying classloader uses the index to know what JAR file to download. Make sure that you create the index before you sign the JAR file.
Pack200 Compression: See Section 30.2, "Deploying JAR Files Compressed with Pack200" for information on how to use Pack200 compression to minimize download time for JAR files.
Deployment Toolkit: Use the Deployment Toolkit to set up your web page with cross-browser JavaScript you need to launch your app. The deployment toolkit is essentially a set of JavaScript functions that ensure deployment of applets consistently across various browsers.
For enterprises that provide a common execution environment and manage the applications that users access, the Deployment Rule Set feature enables the creation of rules that allow some applications to be run without security prompts while automatically blocking other applications. This feature is intended to be used internally in an organization. See Chapter 28, "Deployment Rule Set" for more information.
For users who need to run RIAs that are blocked because they do not meet current security requirements, the Exception Site List feature is provided. RIAs that are started from sites in the list prompt the user for permission to run. See Chapter 29, "Exception Site List" for more information.
To understand how the deployment of RIAs is handled, see Chapter 24, "Rich Internet Application Deployment Process".
Both applets and Java Web Start applications are easier to distribute than standard applications, because they are launched over the web. They both require permission from the user to run, so it is important that they be signed with a valid certificate from a trusted authority to enable the user to make an informed decision about running the application. RIAs can only access the user's system in highly controlled ways, unless extended access is requested when launched and is permitted by user.
The following table summarizes the differences between applets and Java Web Start applications:
| Feature | Applet | Java Web Start |
|---|---|---|
| Java version | Individual applets can specify the exact version, or version range, of the Java platform it will use. The Java Plug-in supports both static version requests (such as "8.0 update 20") and family version requests (such as "8.0 family"), and supports several backward compatibility mechanisms such as static and family ClassIDs in Internet Explorer. See Section 12.2.2, "Java Runtime Environment Version Selection" for details. | Java Web Start is also used only from the latest Java version installed on a system, but the version of Java Web Start run is independent of the version of the Java platform used. A Java Web Start application can specify the exact version, or version range, of the Java platform that it will use. |
| Cookies | Java Plug-in applets run in the same session as the browser, and have access to both "persistent" cookies and "session" cookies already stored in the browser session. | Java Web Start runs outside the browser process. It can access "persistent" cookies stored by the browser (it does this by using the WinINet API on Windows), but has no access to "session" cookies unless set in that application using the java.net.CookieManager and java.net.CookieHandler API's. |
| Browser Interactions | Java Plug-in includes the ability for applets to interact with the current browser session with the the Common DOM API. See Manipulating DOM of Applet's Web Page from the Java Tutorials. In addition, Java applets can invoke JavaScript functions present in the same web page as the applet and JavaScript code on a web page can interact with Java applets embedded on the page. See Invoking JavaScript Code From an Applet and Invoking Applet Methods From JavaScript Code from the Java Tutorials. | Java Web Start is limited to invoking the default browser to display specific URL's (see JNLP API). |
| Java Runtime | An applet can specify Java Runtime parameters used to launch that particular applet instance, without affecting the parameters used to launch other applets. Specifying Java Runtime parameters in the Java Control Panel is also supported for backward compatibility purposes. | Java Web Start applications have (limited) control over the Java Runtime parameters that are used to launch that application. |
| JNLP API | Applets launched using Java Network Launching Protocol (JNLP) have access to JNLP API, which allows sandbox applications access to persistent storage, download control, file I/O, and more. | Java Web Start includes access to the JNLP API, |
| Shortcuts | You can develop draggable applets. A Java applet that is deployed by specifying the draggable parameter can be dragged outside the browser and dynamically transformed into a Java Web Start application. The Java applet can be dragged by pressing the Alt key and the left mouse button and dragging the mouse. You can add a desktop shortcut that can be used to launch your application outside the browser. See Developing Draggable Applets in the Java Tutorials for more information. |
Java Web Start applications can install shortcuts that allow the application to be rerun, either online or offline, independent of the browser. |
For more information on the specific differences between Java Web Start and Java Plug-in, see Section 12.5, "Migrating Java Applets to the Java Network Launching Protocol".
The topics in this section provide information about JNLP, the Deployment Toolkit, and other considerations to be aware of when making deployment decisions.
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 capabilities at their disposal:
Access to JNLP extensions - Powerful JNLP extensions such as Java Binding for the Open GL OpenGL API (JOGL), JavaFX Scene Graph, and NASA World Wind Java SDK (a planetary and extra-planetary visualization system) can 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 more. See the Java Tutorial lesson, Accessing the Client Using JNLP API for step-by-step instructions about using JNLP API.
Version selection and more - Building on the Java Plug-in's architecture, applets launched using JNLP can utilize all of the features previously available to Java Web Start applications, such as JRE version selection, passing command-line arguments and system properties to the JVM, and more.
|
Tip: This section describes an older version of the Deployment Toolkit and is provided as a reference for legacy applications. See Chapter 19, "Deployment in the Browser" for information on the latest Deployment Toolkit. |
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.
The following sections provide information on additional items to consider when planning the deployment of your application.
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 java.net.URLClassLoader. In Java Web Start resources are loaded by the JNLPClassLoader, which extends java.net.URLClassLoader.
Access the ClassLoader being used with:
ClassLoader cl = Thread.getCurrent().getContextClassLoader();
The correct way to access resources is to use getResourceAsStream(), which returns the correct content whatever type of ClassLoader is used to access the resource. If the resource is already cached, the contents of the resource are returned from the cache directly, so there won't be extra network connections to the resource itself.
Modifying the contents of the Java deployment cache directly is not recommended. The cache is a private implementation of Java Web Start and Java Plug-in, and is subject to change anytime.
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 supports lazy downloading. It can be a way to significantly improve the download and startup time in some applications. 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. As much as possible, package your classes in JAR files instead of using individual classes.
The following table shows the properties that can be specified in the JNLP file to control the behavior of the RIA.
| Property | Allowed Value | Description |
|---|---|---|
javaws.cfg.jauthenticator |
true, false, all | A value of true or all, prevents Java Web Start software from installing the default JAuthenticator. |
jnlp.concurrentDownloads |
integer | Number of threads for concurrent download of JAR files |
jnlp.packEnabled |
true, false | A value of true indicates that the application's JAR files have been compressed using the Pack200 tool. See Section 30.2, "Deploying JAR Files Compressed with Pack200" for more information. |
jnlp.versionEnabled |
true, false | A value of true indicates that the application's JAR files have been versioned to enable the version download protocol.
Version download is the ability to request that specific versions of certain JAR files be used by applets and Java Web Start applications. When this property is set to <file> ::= <name> "__" <options> ".jar" <options> ::= "V" <version-id> Note: version 1.0 of The original JAR is used if the versioned JAR file is not found. |
