Summary
The next-generation Java Plug-In technology (hereafter the "Java
Plug-In") provides fine-grained control over which Java Runtime
Environment (JRE) version is used to execute each applet in the web
browser. This document describes the version selection mechanisms
available and the behavior thereof, including differences in behavior
compared to the "classic" Java Plug-In.
Table of Contents
In Java SE 6 update 10, Sun Microsystems, 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 Sun
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.
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.
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 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.
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.
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>
Selecting the latest JRE from a particular family:
<applet codebase="http://foo.bar.com/" code="MyApplet" ...>
<param name="java_version" value="1.5*">
</applet>
Selecting a JRE from a particular family or any later family:
<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 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.
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="http://java.sun.com/out-of-proc-plugin-url-placeholder.exe#1,6,0,10"
width="200" height="200">
<param name="code" value="MyApplet">
<param name="java_version" value="1.5*">
</object>
Note that, at the current time, Sun Microsystems, 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, Sun 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.
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. Sun 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>
Selecting the latest JRE from a particular family (1.5) using the
family CLSID:
<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 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.
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="http://java.sun.com/out-of-proc-plugin-url-placeholder.xpi"
width="200" height="200">
java_version="1.5*"
</embed>
Note that, at the current time, Sun Microsystems, 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, Sun 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.
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. Sun 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.
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\Sun\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"):
- 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.
- 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.
- 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.
- 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.
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.
The JRE version selection capabilities of the new Java Plug-In are
intended to solve longstanding problems in enterprise deployments of
applet content. Please provide your feedback either via Sun Partner
channels or on the Java Plug-In
forum.
| 
