Java™ Runtime Environment Version Selection

Summary

Table of Contents

Architectural Overview

In Java SE 6 update 10, Oracle, Inc. is introducing a new implementation of the Java Plug-In, which is the piece of software which executes applets in the web browser. The new Java Plug-In is being introduced simultaneously for all of the platforms on which Oracle directly supports Java (Solaris, Linux, and Microsoft Windows) and all supported browser families (the Mozilla Firefox family of browsers as well as Internet Explorer 6 and 7).

The new plug-in offers a substantially redesigned architecture. Rather than executing applets in a Java™ virtual machine (JVM) instance which is embedded in the web browser's process, the JVM instance which executes the applet is now a separate process from the web browser. This architecture bears similarities to the "classic" Java Plug-In on the Solaris and Linux platforms, but the communications channel and relationship between the web browser and the attached JVM instance have been redesigned. The new plug-in now supports having more than one JVM instance simultaneously attached to the web browser.

Note that the new plug-in does not necessarily create a new JVM instance for each applet; like the classic plug-in, the default behavior of the new plug-in is to run all applets in the same JVM instance.

Not only does the new Java Plug-In support multiple simultaneously attached JVM instances, it supports multiple JRE versions. More precisely, it supports running an individual applet on top of a particular version of the JRE without affecting which JRE version is used to run any other applet in the same browser session. This capability is similar to that provided by Java Web Start, which allows selection of which version of the JRE is used to launch the application. When an earlier version of the JRE is selected via the new plug-in, the new plug-in's code is actually run on top of the earlier JRE version, again in similar fashion to how the Java Web Start launcher works.

Limitations

The new Java Plug-In's version selection mechanism works on JRE versions as far back as 1.4.2. JRE 1.3.1 and earlier are not supported. It is not possible to use the new Java Plug-In for some applets in the browser session and the classic Java Plug-In for other applets in the same browser session, for example to circumvent the 1.3.1 limitation.

Due to technical limitations of earlier versions of the JRE, on Unix/X11 platforms (Solaris and Linux), the earliest JRE version that can be selected is 5.0. Running applets on top of 1.4.2 using the new Java Plug-In is not supported on these platforms.

Version Selection Mechanisms

The new Java Plug-In provides a new platform- and browser-independent mechanism for selecting a JRE version upon which to launch an applet: the java_version applet parameter. This new parameter supports:

  • Selection of a particular JRE version ("1.5.0_11")
  • Selection of a particular JRE family ("1.5*")
  • Selection of a particular JRE family or later ("1.5+")

The new Deployment Toolkit can be used to specify this parameter in a browser-independent fashion, without writing HTML manually.

In order to provide the most complete information, the new version selection mechanism, as well as how it interoperates with the previously available browser-specific mechanisms, are detailed here. More details of the version selection behavior are provided in the following section.

The java_version parameter

The java_version parameter has been added to the <applet>, <object> and <embed> tags to provide browser-independent JRE version selection. The value of this parameter is a version string following the rules in the JNLP specification, Chapter 4 and Appendix A. In particular, selection of a particular JRE version, one in a particular family, or one in a given family or any later family are all supported.

The java_version parameter should be specified as a name/value pair in an embedded <param> tag when used with the <applet> and <object> tags, and via java_version=[version] when used with the <embed> tag. Other alternate or shorthand forms of syntax are not guaranteed to work across browsers. Consult the Using APPLET, OBJECT and EMBED tags section of the Java Plug-In Guide for details.

Note that in order to run on top of the latest available JRE on the system, no java_version parameter is necessary; this is the default behavior.

The examples below illustrate how to use the java_version parameter.

Relationship to the Other Mechanisms

Support for the java_version parameter is provided by the new Java Plug-In. If the new Java Plug-In is not present on a particular system, then browser-specific mechanisms are needed to download and install it in order to support per-applet JRE version selection. Generally speaking, the <object> tag and classid attribute is used in the Internet Explorer browser family to auto-download plugins, and the <embed> tag and MIME type is used in the Mozilla browser family for the same purpose. Please see the "recommended usage" subsections in the classid and version documentation below for more information on combining the java_version parameter with the <object> and <embed> tags.

Both the <object> and <embed> tags also support a certain amount of version selection of the plugin to be used to render a piece of content. For backward compatibility purposes, some of the previous version selection techniques for these tags are supported in the new plug-in, though changes to existing content will be needed to access all of the new features. Please see the classid backward compatibility and the version backward compatibility sections below for more information.

Examples

Using the <applet> tag to select a particular JRE version for an individual applet:

  <applet codebase="http://foo.bar.com/" code="MyApplet" ...>

     
            <param name="java_version" value="1.5.0_11">
  </applet>
          
  <applet codebase="http://foo.bar.com/" code="MyApplet" ...>

     
            <param name="java_version" value="1.5*">
  </applet>
          
  <applet codebase="http://foo.bar.com/" code="MyApplet" ...>

     
            <param name="java_version" value="1.5+">
  </applet>

Please see the section below on version selection behavior for details on how these requests are satisfied.

The Classid Attribute in Internet Explorer

The Internet Explorer browser uses the classid attribute of the <object> tag to indicate how the content of that tag should be displayed. The section of the Java Plug-In Developer Guide on Using the Applet, Object and Embed Tags describes in detail how to use the classid attribute, and also how to use it in conjunction with the codebase attribute to automatically download and install a particular JRE version if none is currently available on the system. The family CLSID concept was introduced more recently to provide a way to select an arbitrary JRE in a given family.

Not all of the classid options described in earlier documentation work in conjunction with the new Java Plug-In to both select, and potentially automatically download and install, a particular JRE version. This section describes what works in conjunction with the new plug-in, and what backward compatibility mechanisms are in place.

Recommended Usage

The recommended usage of the classid attribute is in conjunction with the java_version parameter described above. The dynamic classid, which always points to the latest installed JRE version, should be specified in the <object> tag in order to indicate that the latest version of the Java Plug-In, with multiple JRE support, should be used. The java_version parameter should then be used to specify the version of the JRE to use to run the applet.

Example of recommended usage:

  <object

     
            classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
     
            codebase="#"
    width="200" height="200">
      <param name="code" value="MyApplet">
       
            <param name="java_version" value="1.5*">
  </object>

Note that, at the current time, Oracle, Inc. is not providing a new CLSID to describe the new Java Plug-In, but instead overloading the usage of the dynamic classid. This means that if a previous version of the JRE is already installed which does not have multiple JRE version support in the Java Plug-In, the new Java Plug-In will not be automatically downloaded and installed, since a handler for that classid is already available. The result will be that the version selection via the java_version parameter will be ignored. The decision to not provide a new classid may be revisited in the future. For the time being, Oracle expects that sophisticated developers requiring multiple JRE version selection and automatic download of the new Java Plug-In will either document that their users must install and configure the new Java Plug-In in order to properly run their content, or will have administrative control over the client machines, as is common in many enterprises.

Backward Compatibility

To ease the transition for developers already using the classid attribute, two backward compatibility mechanisms have been introduced: the ability to use a classid to select either a specific JRE version, or an arbitrary JRE in a given family. In both cases, the expectation is that both the new Java Plug-In, and the target JRE version for the applet, are already installed and configured. In conjunction with these backward compatibility mechanisms, auto-downloading of any JRE, either the one supplying the new Java Plug-In or the one to be used to run the applet, is not supported.

Note that these backward compatibility mechanisms may be removed in a future release. Oracle recommends transitioning existing content to the new mechanisms described above.

Selecting a particular JRE version (1.5.0_11) for an individual applet:

  <object

     
         classid="clsid:CAFEEFAC-0015-0000-0011-ABCDEFFEDCBA"
    width="200" height="200">
      <param name="code" value="MyApplet">
  </object>
          
  <object

     
            classid="clsid:CAFEEFAC-0015-0000-FFFF-ABCDEFFEDCBA"
    width="200" height="200">
      <param name="code" value="MyApplet">
  </object>

Note that attempts to download older versions of the JRE using the codebase parameter will be ignored, because these classids are registered on the system to point to more recent versions of the DLLs during the installation process of the new Java Plug-In. Note also that the use of the java_version parameter in conjunction with these classids is not supported. Specifying both the java_version parameter as well as either a static or family classid will result in undefined behavior.

The version and jpi-version Attributes in the Mozilla Browser Family

The Mozilla browser family uses the MIME type in the <embed> tag to indicate how the content of that tag should be displayed. The section of the Java Plug-In Developer Guide on Using the Applet, Object and Embed Tags describes in detail how to use the <embed> tag and its support for automatic downloading of a particular version of the JRE.

Previous versions of the Java Plug-In used the version and jpi-version portions of the application/x-java-applet MIME type to perform JRE version selection. Not all of these mechanisms described in earlier documentation work in conjunction with the new Java Plug-In to both select, and potentially automatically download and install, a particular JRE version. This section describes what works in conjunction with the new plug-in, and what backward compatibility mechanisms are in place.

Recommended Usage

The recommended usage of the <embed> tag is to not specify any version or jpi-version in the MIME type of the applet. Instead, use the java_version parameter to choose a particular JRE version upon which to run the applet. If no previous Java version is installed, auto-download of the new Java Plug-In can be enabled using the pluginspage parameter:

  <embed code="MyApplet"

     
           type="application/x-java-applet"
     
            pluginspage="#"
    width="200" height="200">
     
           java_version="1.5*"
  </embed>

Note that, at the current time, Oracle, Inc. is not providing a new MIME type to describe the new Java Plug-In, but instead overloading the usage of the application/x-java-applet MIME type. This means that if a previous version of the JRE is already installed which does not have multiple JRE version support in the Java Plug-In, the new Java Plug-In will not be automatically downloaded and installed, since a plugin supporting that MIME type is already available. The result will be that the version selection via the java_version parameter will be ignored. The decision to not provide a new MIME type may be revisited in the future. For the time being, Oracle expects that sophisticated developers requiring multiple JRE version selection and automatic download of the new Java Plug-In will either document that their users must install and configure the new Java Plug-In in order to properly run their content, or will have administrative control over the client machines, as is common in many enterprises.

Backward Compatibility

To ease the transition for developers already using the version and jpi-version portions of the MIME type, a limited degree of backward compatibility is supported in the new Java Plug-In. Specifically, the version attribute is supported to request an arbitrary JRE in a given family or any later family. Using the jpi-version attribute to select a particular JRE version is no longer supported. Its use is strongly discouraged since it may disrupt correct operation of the new Java Plug-In.

Note that this backward compatibility mechanism may be removed in a future release. Oracle recommends transitioning existing content to the new mechanisms described above.

To use the version attribute to require the 1.5 JRE or a later one:

  <embed code="MyApplet"

     
           type="application/x-java-applet;version=1.5"
    width="200" height="200">
  </embed>

Note that the semantics of the version attribute imply that the above tag is equivalent to using the java_version parameter with a value of 1.5+. Since the new Java Plug-In is delivered with Java SE 6 update 10, which is a later version than 5.0, this version request essentially has no effect.

Note also that combining the version attribute with the java_version parameter is not supported. Specifying both the java_version parameter as well as a version attribute will result in undefined behavior.

Version Selection Behavior

All of the version selection mechanisms described above are implemented using the same underlying code path. This section describes in general terms the discovery of particular JRE versions and the user experience as it relates to version selection.

On all platforms, the new plug-in locates JREs to use from the entries listed in the Java Control Panel ("Java" tab, "View" button under "Java Applet Runtime Settings"). 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:\Documents and Settings\[username]\Application Data\Oracle\Java\Deployment. On Unix platforms, it is generally located in ~/.java/deployment/deployment.properties.

On Windows platforms, both the Java Control Panel and the new Java Plug-In will automatically detect the installed JREs and add them to the available set. On Unix platforms, auto-detection of installed JREs is not supported. The Java Applet Runtime Settings dialog in the Java Control Panel may be used to manually add JREs to the known list for the new Java Plug-In. See the section in the release notes on changes in the Java Control Panel for more details.

By default the new Java Plug-In will execute all applets in the latest JRE version named in this list. It will only execute an applet on an earlier JRE version 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. 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.

Differences in Behavior Compared to Previous Versions

Compared to the "classic" Java Plug-In, the new Java Plug-In once again enables selection of a particular update release of the JRE. Like recent releases of the "classic" plug-in, it also supports selection of either a JRE family or the latest installed JRE, adding new cross-browser version selection mechanisms that are comparable to those available in Java Web Start. It provides a certain degree of backward compatibility with applet content using existing version selection mechanisms in both the Internet Explorer and Mozilla browser families.

More specifically, the new plug-in attempts to honor static CLSIDs in Internet Explorer. Current versions of the classic plug-in always redirect static CLSIDs to the latest installed JRE version.

The user experience is slightly different than in the classic plug-in. In particular, displaying a warning dialog on a per-applet basis if the applet selects an older JRE version is new behavior. However, it is needed due to the added flexibility of being able to select a JRE version on an applet-by-applet basis. The display of warning dialogs is intended to be as similar to that in Java Web Start as possible, and more unification between these two technologies is planned in the future.

Conclusion

The JRE version selection capabilities of the new Java Plug-In are intended to solve longstanding problems in enterprise deployments of applet content.