12.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.

12.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"):

1. The list of available JREs is consulted. If there is an exact match of the version string, that JRE version is selected. Otherwise, if there are one or more installed JREs in the same family, the latest version is selected. Otherwise, the latest available JRE on the machine is selected.

2. The selected JRE version is compared against the security baseline for the family. (See Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer for more information.) If it is equal to or more recent than that version, no further prompting is done and the applet is launched.

3. Otherwise, the code for the applet is downloaded in a JVM instance of the selected JRE version. If the applet is signed and the user accepts the security dialog for the applet (or the code source has already been trusted), no further prompting is done and the applet is launched.

4. Otherwise, we are dealing with an unsigned applet on an "older" JRE version. A dialog box is presented indicating that this applet is requesting to run on top of an older JRE release, and asks the user whether he or she wants to allow it to. If the user clicks "yes", the applet is launched. If the user clicks "no", the applet is re-launched on top of the latest available JRE version.

When considering a request to launch an applet on a particular family, the most recent JRE from that family will be selected and the above steps starting from (2) will be followed.

When considering a request to launch an applet on a particular family or any later family, the latest available JRE will be used to launch the applet.

12.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.

Figure 12-1 Thread Interactions

Description of "Figure 12-1 Thread Interactions"

When the JavaScript interpreter is idle, the Java Plug-in executes a JavaScript to Java call on the per applet worker thread (JavaScript Interpreter Not Busy scenario).

When a Java to Javascript call is in progress and a JavaScript to Java call is made, the latter is executed on the same thread that made the Java to JavaScript call (Round Trip scenario).

When a thread is executing a Java to JavaScript call, another thread wanting to do the same will be blocked till the first thread has received its result and is done (JavaScript Interpreter Busy scenario)

In order to avoid thread related issues especially when multiple applets are running simultaneously, keep both Java to JavaScript and JavaScript to Java calls short and avoid round trips, if possible.

12.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.

For this reason, the Java Plug-in provides a way to opt out of the use of the Section 12.3.5, "Class Loader Caching" on an applet by applet basis.

12.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.

12.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.

12.2.7 Proxy Configuration

See Section 30.1, "Proxy Configuration" for details.

12.2.8 Security

See Chapter 23, "Setting the Security Level of the Java Client" for details.

12.3.1 Deployment using JNLP

jnlp_href

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

12.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>
 

12.3.3 Command-line Arguments

java-vm-args

Specifies an additional set of standard and non-standard virtual machine arguments that the application prefers the JNLP client to use when launching Java. When both java_arguments and java-vm-args are present, the java-vm-args arguments take precedence.

java_arguments

Specifies JVM command-line arguments to be used when executing this applet instance. Nearly all JVM command-line arguments are supported, though there are certain rules and restrictions. When both java_arguments and java-vm-args are present, the java-vm-args arguments take precedence.

The java_arguments option is primarily for the purpose of avoiding a client Java VM relaunch during applet startup. As a good practice, if both java_arguments and java-vm-args are specified, they should contain the same values.

separate_jvm

A boolean parameter specifying that a particular applet should run in its own JVM instance. This supports certain powerful desktop applets which can not tolerate any interference from other applets running in the same JVM and potentially consuming heap space or other resources.

<APPLET archive="my_applet.jar" code="MyApplet" width="300" height="300">
 <PARAM name="java_arguments" value="...">
 <PARAM name="separate_jvm" value="true">
</APPLET>

java_arguments = -Xmx256m
java-vm-args = -verbose

java_argument = -Xmx256m -verbose
java-vm-args = -verbose

java_arguments = -Xmx256m
java-vm-args = [not defined]

java_arguments = [not defined]
java-vm-args = -Xmx256m

12.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.

12.3.5 Class Loader Caching

classloader_cache

The Java Plug-in provides a way to opt out of the use of the class loader cache on an applet by applet basis.

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

For applets, the default value of the classloader_cache parameter is true; which indicates that class loader caching is enabled. For JNLP applets, class loader caching is disabled.

12.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.

12.3.7 Java Cache

Files you use in Java applications are stored in a special folder for quick execution later; this folder is also called the Java cache. The subpanel Temporary Internet Files in the General tab of the Java Contro Panel, which is described in Section 20.1, "General," enables you to view which files are stored in the Java cache and control how much disk space the cache can take up in your computer.

cache_archive

The cache_archive attribute contains a list of the files to be cached:

<param name="cache_archive" VALUE="a.jar,b.jar,c.jar">

Like the archive attribute in the applet tag, the list of jar files in the cache_archive attribute do not contain the full URL, but are always downloaded from the codebase specified in the embed or object tag.

12.4.1 Applet Status

Table 12-1 explains the meaning of values returned by the status method of the applet.

12.4.2 Applet Event Handlers

You can register event handlers for various events. The Java Plug-in software invokes these event handlers at various stages of the applet loading process. Table 12-2 describes applet events for which event handlers can be registered.

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

12.5.1 Advantages of Migrating to JNLP

Using JNLP with your applet provides the applet with access to the same resources that Java Web Start applications can access.

Migrating to a Java Web Start application provides the ability to launch the application independent of a Web browser. A user can be off-line or unable to access the browser. Desktop shortcuts can also launch the application, providing the user with the same experience as that of a native application.

12.5.2 Using JNLP with an Applet

Applets that are deployed with the applet tag can use JNLP. The JNLP file is specified in the jnlp_href attribute. Parameters to configure deployment can be specified as attributes and parameters. For example:

<applet code="java2d.Java2DemoApplet"          
        jnlp_href="dynamictree_applet.jnlp"         
        width="710" 
        height="540" >        
  <param name="param1" value="value1"/>
</applet> 

12.5.3 Migrating an Existing Java Applet

Java Web Start technology has built-in support for applets. It is possible to run your applet directly with Java Web Start technology without any re-compilation of the applet. All you need do is to convert your applet HTML tags to a Java Network Launching Protocol (JNLP) file, using the JNLP applet-desc element. For example:

<resources>
  <jar href="SwingSet2.jar"/>
</resources>
<applet-desc main-class="SwingSet2Applet" name="SwingSet" width="625" height="595">
  <param name="param1" value="value1"/>
  <param name="param2" value="value2"/>
</applet-desc>