11 Applet Development Guide

11.2.1 Java Runtime Environment

With the Java Plug-in, applets are not run in the JVM inside the browser. Instead, they are executed in a separate process. The same JVM process can be shared between multiple applets, or applets can be placed into different processes depending on whether the existing JVMs match the applet requirements and have enough resources to execute the applet. An applet can request a specific version of the JRE to be used and can specify what options to pass to the JVM. An applet can also request to be executed in the separate JVM.

The browser and the applet can still communicate with one another, however. Existing APIs have been re-engineered to use process sockets, so everything continues to work as it did before, only better. This architecture provides a number of benefits:

• Applets that require different versions of the JRE can run simultaneously.

• Applets can specify JRE start-up parameters such as heap size. (A new applet uses an existing JRE if it's requirements are a subset of an existing JRE, otherwise, a new JRE instance is launched.);

• The message-passing interfaces are written in Java, so they run on all supported platforms, in the same way, so cross-browser compatibility is enhanced.

With that architecture, a new JRE can be launched whenever it is needed. However, an applet runs in an existing JRE when the following conditions are met:

1. The JRE version required by the applet matches an existing JRE.

2. The launch parameters for the JRE satisfy the applet's requirements.

11.2.2 Java Runtime Environment Version Selection

On all platforms, the Java Plug-in locates JREs to use from the entries listed in the Java Control Panel ("Java" tab, "View" button). The available JREs in this list are encoded in the deployment.properties file whose location is platform-dependent. On the Windows platform, it is generally located in C:\Users\[username]\AppData\LocalLow\Sun\Java\Deployment. On Solaris, Linux, and OS X platforms, it is generally located in ~/.java/deployment/deployment.properties.

On Windows platforms, both the Java Control Panel and the Java Plug-in automatically detect the installed JREs and add them to the available set. On Solaris, Linux, and OS X platforms, auto-detection of installed JREs is not supported. The Java Runtime Environment Settings dialog, which is accessed by clicking View in the Java tab of the Java Control Panel, can be used to manually add JREs to the known list for the Java Plug-in.

By default, the Java Plug-in executes all applets in the latest JRE version named in this list. The Java Plug-in executes an applet on an earlier JRE version only if explicitly requested.

When considering a request to launch an applet on a specific JRE version (for example, a particular update release like "1.5.0_11"):

11.2.3 Thread Considerations

A web browser's JavaScript interpreter engine is single thread. The Java Plug-in is capable of managing multiple threads. The Java Plug-in creates a separate worker thread for every applet. Applets themselves may be multi-threaded. Applets making JavaScript to Java calls and vice versa should be designed with the thread related issues in mind.

The following figure shows the thread interactions between the JavaScript Interpreter, Java Plug-in, and an applet.

11.2.4 Classloader Cache and Interaction between Applets

Normally, if two applets have the same codebase and archive parameters, they will be loaded by the same class loader instance. This behavior is required for backward compatibility, and is relied on by several real-world applications. The result is that multiple applets on the same web page may access each others' static variables at the Java language level, effectively allowing the multiple applets to be written as though they comprised a single application.

While this feature enables certain kinds of applications to be conveniently written, it has certain drawbacks. It interferes with termination of applets, in particular when multiple instances of the same applet are active. It makes the programming model for applets more complex, since it is under specified exactly when the static fields of an applet will be re-initialized, and when they will be maintained from run to run of the same applet. It causes imprecise behavior of certain user interface operations within the Java Plug-in due to the inability to identify exactly which applet initiated a particular request.

11.2.5 Applet Garbage Collection

Garbage collection occurs on an applet instance immediately after the destroy method finishes. The garbage collection applies to all memory acquired by the applet, except for static variables. Statics are preserved in the classloader cache, along with the classes themselves, for as long as the class loader is present.

So when does the class loader go away? That behavior is not specified. It's up to the implementation of the Java virtual machine and its interactions with the operating system. You can expect it be retained for as long as possible, but to be discarded when the memory is needed for other purposes.

11.2.6 Applet Privileges

Sign all applets with a valid certificate from a recognized certificate authority to provide a better user experience. An applet runs in a secure sandbox that prevents it from interacting with the user's system, unless authorized. To obtain that authorization, the applet must request permissions when it is launched and the user must agree to run the applet. Permissions are needed to:

• Print

• Access the file system

• Access browser cookies

• Access other system resources

The basic applet security model is an all or nothing proposition. An applet with permissions has full access to the user's system. Without permissions, the applet has virtually no access at all.

Deployment of applets using JNLP gives the applets access to JNLP APIs similar to Java Web Start applications, which gives the applet controlled access to a user's system, under control of the user. For example, using JNLP provides the ability to save or open a file selected by the user and the ability to print.

11.2.7 Proxy Configuration

11.2.8 Security

11.3.1 Deployment using JNLP

jnlp_href

The file containing information for the plug-in to use to launch the applet.

11.3.2 Loading Screen

The Java Plug-in offers better customization of the image that is displayed before the applet is loaded. Animated GIFs are supported as the target of the image parameter. Additionally, the following parameters are supported:

boxborder

A boolean parameter indicating whether a one-pixel border should be drawn around the edge of the applet's area while displaying the image shown before the applet is loaded. Defaults to true. We recommend setting this value to false, in particular when using an animated GIF as the loading image, to avoid the possibility of flicker.

centerimage

A boolean parameter indicating whether the loading image should be centered within the area of the applet instead of originating at the upper left corner. Defaults to false.

Example using the boxborder and centerimage parameters:

<APPLET archive="large_archive.jar"
 code="MyApplet"
 width="300" height="300">
 <!-- Use an animated GIF as an indeterminate progress bar
 while the applet is loading -->
 <PARAM NAME="image" VALUE="animated_gif.gif">
 <!-- Turn off the box border for better blending with the
 surrounding web page -->
 <PARAM NAME="boxborder" VALUE="false">
 <!-- Center the image in the applet's area -->
 <PARAM NAME="centerimage" VALUE="true">
 </APPLET>
 

11.3.3 Command-line Arguments

11.3.4 JRE Version Selection

java_version

Specifies a JRE version upon which to launch a particular applet.

Use the Deployment Toolkit to specify an older version of the JRE, if needed. In an enterprise environment, the preferred method of requesting an older version of the JRE is to use the Deployment Rule Set feature.

11.3.6 Security

permissions

Specifies the level of permissions that the applet needs to run. The following values are valid:

• sandbox - The applet runs in the security sandbox.

• all-permissions - The applet requires access to resources on the user's system.

• default - The level of permissions is determined by the Permissions attribute in the manifest for the main JAR file.

<APPLET archive="my_applet.jar" code="MyApplet" width="300" height="300">
 <PARAM name="permissions" value="sandbox" />
 </APPLET>

If this parameter is omitted, default is assumed. If the parameter is present and not set to default, the value must match the value of the Permissions attribute in the manifest for any JAR file that has the Permissions attribute, otherwise the applet is blocked.

11.3.7 Java Cache

11.4.1 Applet Status

11.4.2 Applet Event Handlers

You can register or determine an event handler in the JavaScript code of a web page as shown in the following code examples:

// use an anonymous function
applet.onLoad(function() {
 //event handler for ready state
}

// use a regular function
function onLoadHandler() {
 // event handler for ready state
}

// Use method form
applet.onLoad(onLoadHandler);

// Use attribute form
applet.onLoad = onLoadHandler;

// get current event handler
var handler = applet.onLoad