Table of Contents
Java Plug-In technology (hereafter the "Java Plug-In"), which is
included in the Java Runtime Environment, enables Java applets to run
in popular web browsers on the desktop. The next-generation Java
Plug-In, new in Java SE 6 Update 10, provides powerful new
capabilities to applets in the web browser, while improving the
overall reliability and functionality of applets in a
backward-compatible manner.
The next-generation Java Plug-In offers a completely redesigned
architecture. Instead of executing applets in the same operating
system process as the web browser, the new plug-in runs one or more
Java virtual machine instances ("JVMs") which connect back to the
browser for full interoperability with the surrounding web page. This
architectural change offers many advantages and enables several new
features.
- Improved reliability. The JVM running the applet is
isolated from the web browser at the operating system level. If
something should go wrong while running the applet, or if an
uncooperative applet refuses to shut down, the new Java Plug-In
detects and handles the error condition gracefully; the web
browser is unaffected.
- Built-in JNLP support. The new plug-in offers the
capability to launch applets directly from JNLP files, unifying
deployment of Java content both in the browser and out of the
browser (via Java Web Start). Developers can now reuse JNLP
extensions for advanced functionality including the JavaFX run-time
libraries, 3D graphics
via OpenGL, and planetary-scale
terrain visualization within applets. Applets can now access
JNLP APIs for persistent data storage, local file system access,
and other useful functionality from sandboxed code.
- Per-applet command-line arguments. JVM command-line
arguments may be specified on a per-applet basis, providing
fine-grained control over options such as the heap size and Java
2D hardware acceleration features. JNLP-launched applets simply
incorporate the command-line arguments and/or system properties
into the JNLP file. Old-style applets can embed these arguments
in the HTML of the web page.
- Multiple Java Platform version support. Each individual applet
instance may request a different Java Platform version on which to run.
This feature is designed for enterprise customers which prefer to
qualify their applets against either a particular Java Platform version or
a particular Java Platform family. Both selection of a specific Java Platform
version, or any in a particular family, are supported in the new
plug-in.
- Improved Java/JavaScript communication. The bridge between
the JavaScript engine in the web browser and the Java programming
language has been completely reimplemented. The new
implementation is backward-compatible and features improved
reliability, performance and cross-browser portability, for both
Java calling JavaScript as well as JavaScript calling Java.
Formerly Mozilla-specific "LiveConnect" functionality, such as
the ability to call static Java methods, instantiate new Java
objects and reference third-party packages from JavaScript, is
now available in all browsers.
- Improved user experience. The new Java Plug-In starts
applets in the background, so the web browser always remains
responsive. Applets appear on the web page as they become ready
to run.
- Improved applet lifecycle management. Calls to the applet
lifecycle methods
init, start,
stop, and destroy are more
deterministic and cross-browser behavior has been improved. The
applet class loader cache and the legacy applet lifecycle,
required for backward compatibility, are fully supported and the
behavior of both has been improved.
- Better large heap support. Historically, the maximum heap
size that could be specified for applets via the Java Control
Panel has been limited. This limitation is fixed in the new Java
Plug-In; applets can now utilize as much heap space as
command-line applications.
- Better Windows Vista support. Signed applets running in
Protected Mode Internet Explorer on Microsoft's Windows Vista now
have the same privileges as normal user applications, eliminating
a portability barrier to this platform.
The new plug-in immediately fixes several longstanding bugs, among
them the following:
| 6359309 | Large setting for -Xmx param prevents plugin from starting in Internet Explorer |
| 6433218 | Java applet fails with Large Java Runtime Parameter setting |
| 6504236 | Implement IE Broker process for File I/O on Vista |
| 6516270 | Java applet failure with IE7 displaying "Several Java Virtual Machines running" error |
| 6528750 | JRE fails to load with large runtime parameter value |
| 6548078 | The Java Security Model is broken on Windows Vista with IE7 Protected Mode |
| 6559586 | This applet site freeze IE |
The new Java Plug-In is designed to work in the following browsers:
- Internet Explorer 6 and 7 on Windows XP and Vista
- Firefox 3 on Windows XP, Windows Vista, Solaris and Linux
As of this writing, the final version of Firefox 3 had not yet been
released. The latest nightly build of this browser can be downloaded
from the following locations:
We recommend using the latest nightly build.
Note that the new Java Plug-In does not work in Firefox 2. On
the Windows platform, when the new Java Plug-In is enabled via the
Java Control Panel, launching Firefox 2 will use the classic plug-in
and launching Firefox 3 will use the new plug-in. Sun Microsystems and
the Mozilla Foundation have been working closely in order to support
the new Java Plug-In in Firefox 3. Both organizations have mutually
decided not to back-port the required changes — which are
significant — to Firefox 2, as it is expected that most Firefox
users will upgrade to Firefox 3 a short time after its final version
has been released.
- Windows Platform
-
On the Windows platform, the new plug-in is automatically enabled for
running applets in the Internet Explorer and Firefox 3 web browsers
during installation of the Java Platform. No user intervention is necessary.
For the time being, both the classic and new plug-ins are shipped
side-by-side. In order to provide a fallback for backward
compatibility purposes, a switch has been provided in the Java Control
Panel to toggle which plug-in is used for applet execution. To toggle
between them, run the Java Control Panel, go to the Advanced tab, Java
Plug-in node, and toggle the checkbox labeled 'Enable the
next-generation Java Plug-in'.
- Unix Platforms (Solaris and Linux)
-
Place a symlink to .../jre/lib/{i386,sparc}/libnpjp2.so
into either your Firefox 3 firefox/plugins directory or
your ~/.mozilla/plugins directory. Remove any stray
preexisting symlinks to the libjavaplugin_oji.so library.
You may switch back to using the classic Java Plug-In by removing the
symlink to libnpjp2.so and reinstalling a symlink to
libjavaplugin_oji.so from the same Java Platform.
Much of the new functionality in the new Java Plug-In is exposed via
new parameters to the preexisting <applet>,
<object> and <embed> tags.
In general we recommend using the Deployment
Toolkit, also new in Java SE 6 update 10, to automatically
generate the HTML for the applet tag. The deployment advice guide shows how
to easily and portably deploy applets using the Deployment Toolkit.
All of the following parameters may simply be specified in the
parameters array passed in to the runApplet
method of the Deployment Toolkit's JavaScript library. Alternatively,
you may use either the nested PARAM tag, or the analogous syntax for
the EMBED tag, to add these parameters by hand to your existing
applets. Consult the Using
APPLET, OBJECT and EMBED tags section of the Java
Plug-In Guide for details. For the purpose of illustration, the
examples below use only the <applet> and
<param> tags.
All of the following parameters are optional; if they are not
specified, default values will be used.
The most significant new feature of the next-generation Java Plug-In
is built-in support for launching applets from JNLP files. Using the
JNLP file format as the applet descriptor allows applets to instantly
reuse JNLP extensions previously written for Java Web Start
applications, and significantly expands the capabilities of applets in
many other ways.
Specifies the JNLP file the new Java Plug-In should use to
launch the applet. Full documentation for this parameter is provided
in JNLP Support in the New Java Plug-In.
The new plug-in offers better customization of the image which is
displayed before the applet is loaded. Animated GIFs are now supported
as the target of the image parameter, as described in the
Special
Attributes section of the Java
Plug-In Developers' Guide. Additionally, the following new
parameters are now supported:
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.
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>
Note that both the java_arguments and
java_version parameters described here are essentially
stopgap measures. The recommended way to access this functionality is
via the new JNLP support in the new Java
Plug-In.
-
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.
Examples
- Specifying a larger-than-default maximum heap size:
-
<APPLET archive="my_applet.jar" code="MyApplet" width="300" height="300">
<PARAM name="java_arguments" value="-Xmx128m">
</APPLET>
- Specifying a non-default heap size and a Java 2D hardware
acceleration option typically used for applets using OpenGL via JOGL:
-
<APPLET archive="my_applet.jar" code="MyApplet" width="300" height="300">
<PARAM name="java_arguments" value="-Xmx256m -Dsun.java2d.noddraw=true">
</APPLET>
- Enabling verbose output of the garbage collector, and the
assertion facility in the Java programming language:
-
<APPLET archive="my_applet.jar" code="MyApplet" width="300" height="300">
<PARAM name="java_arguments" value="-verbose:gc -ea:MyApplet">
</APPLET>
Detailed Description
A set of "secure" JVM command-line arguments and system properties is
defined in the JNLP
File Syntax section of the Java
Web Start Developers' Guide. In the new plug-in, as long as all of
the JVM command-line arguments specified via the
java_arguments parameter are secure, then the applet, or
any classes it loads, may be unsigned.
Insecure JVM command-line arguments (in other words, those not on the
secure list) may also be specified via the java_arguments
parameter. In this case, there is the potential for a security risk,
so the Java Plug-In enforces the rule that no unsigned classes may
be loaded. In other words, only trusted code, for which the
user has accepted the security dialog, may be loaded by such a JVM
instance. If an attempt is made to load an unsigned or untrusted class
in a JVM instance for which insecure system properties have been
specified, a ClassNotFoundException will be thrown
indicating that the given class could not be loaded because it was not
signed.
There are relatively few restrictions on what command-line arguments
may be passed via the java_arguments parameter. In
general, the -Xbootclasspath argument is forbidden, as
well as any command-line argument used to specify a path, such as
-classpath or -jar. All other command-line
arguments, present and future, should be supported, with the caveat
about secure and insecure command-line arguments described above.
The command-line arguments passed via the java_arguments
parameter are added to any specified via the Java Applet Runtime
Settings dialog in the Java Control Panel. The command-line arguments
from the control panel are used for all JVM instances of the version
for which they are specified; the java_arguments
parameters do not completely replace them. (The Java Applet Runtime
Settings dialog has also been enhanced in 6u10 to better manage
multiple Java Platform versions, and now has the same capabilities as the Java
Applet Runtime Settings dialog used for Java Web Start.)
When JVM command-line arguments are specified, it is likely that the
new plug-in will need to launch another JVM instance in order to
satisfy them. In other words, it is unlikely that a preexisting JVM
instance will have been started with the correct set of command-line
arguments to satisfy the request. The rules for exactly when a new JVM
instance is launched to start a given applet are deliberately left
unspecified, as this functionality is brand new in the 6u10 release
and may need to change in subsequent releases. Here is a rough set of
guidelines for the sharing and creation of new JVM instances:
- If the command-line arguments used to start a preexisting JVM
instance are a superset of the requested arguments, the
preexisting JVM instance will be used.
- If a JVM instance is launched for the "default" set of
command-line arguments (i.e., those specified in the Java Control
Panel, with no
java_arguments specified), then this
JVM instance will never be used to launch any applet
that has even one command-line argument specified via
java_arguments.
-
-Xmx is handled specially: if a preexisting JVM
instance was started with for example -Xmx256m via
java_arguments, and a new applet requests
-Xmx128m, then new applet will very likely be run in
the preexisting JVM instance. In other words, -Xmx
specifications are matched with a greater-than-or-equal test.
There is no way to "name" a JVM instance used to launch a particular
applet and "force" subsequent applets into that JVM instance.
See the section on the separate_jvm parameter to isolate a
particular applet in its own JVM instance, separate from all other
applets.
Please provide your feedback if you have
comments or questions about this functionality.
Specifies a Java Platform version upon which to launch a particular applet.
Examples
- Specifying a particular Java Platform version for a particular applet:
-
<APPLET archive="my_applet.jar" code="MyApplet" width="300" height="300">
<PARAM name="java_version" value="1.5.0_09">
</APPLET>
-
- Requesting any Java Platform in a particular family for a particular applet:
-
<APPLET archive="my_applet.jar" code="MyApplet" width="300" height="300">
<PARAM name="java_version" value="1.5*">
</APPLET>
-
Detailed Description
The version selection support in the next-generation Java Plug-In and
associated backward compatibility mechanisms are described in a
separate document, Java Platform Version Selection
in the Next-Generation Java Plug-In.
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>
-
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 underspecified 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 new 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>
-
The default value of the classloader_cache parameter is
true; class loader caching is enabled by default.
The Java Control Panel has been enhanced to support the new features
in the Java Plug-In, in particular to manage multiple versions of the
Java Platform to be used for applet execution. The Java Applet Runtime Settings
dialog box, which is used to change global applet settings, now offers
the same level of control as the Java Application Runtime Settings
dialog box used for Java Web Start.
The user can now explicitly add and remove Java Platforms from the list. On the
Windows platform, all installed Java Platforms show up in the list
automatically. The "Find" button allows quick configuration of
additional Java Platforms that may have been simply unzipped on the local disk
rather than installed. The "Enabled" checkbox allows control over
which Java Platforms the new Java Plug-In will use when considering a given
applet's request to run on a particular version of the Java Platform.
As before, the Java Runtime Parameters field allows specification of
command-line arguments to be applied to all applets run in that
particular Java Platform version. However, we now recommend using the new
functionality in the Java Plug-In to specify command-line arguments on
a per-applet basis rather than globally. There are however some kinds
of command-line arguments that are still most efficiently specified
via the Java Control Panel, such as -Xdebug, which is
typically used during development.
For compatibility reasons, the new and classic Java Plug-Ins are
currently shipped side-by-side. If you find that your content does not
run properly in the new Java Plug-In, you can switch back to using the
classic plug-in.
On the Windows platform only, this setting can be switched in the Java
Control Panel. In the Advanced tab, under the Java Plug-In node, there
is a checkbox allowing toggling between the old and the new plug-ins.
After this setting is changed, it is necessary to restart the web
browser for it to take effect.
On the Linux and Solaris platforms, you may replace the symlink to
libnpjp2.so with a symlink to the classic plug-in,
libjavaplugin_oji.so. This must currently be done by
hand.
If you find applet content that executes correctly in the classic Java
Plug-In but not in the new Java Plug-In, please report this
compatibility issue on the Java Plug-In
forum.
The bridge between the Java and JavaScript programming languages,
known informally as LiveConnect, has been reimplemented. The new
implementation is backward-compatible and features improved
reliability, performance and cross-browser portability, for both Java
calling JavaScript as well as JavaScript calling Java. Formerly
Mozilla-specific LiveConnect functionality, such as the ability to
call static Java methods, instantiate new Java objects and reference
third-party packages from JavaScript, is now available in all
browsers.
The new LiveConnect specification is forthcoming.
Demonstrations of the new capabilities of the Java Plug-In are now available:
Please provide your feedback on the next-generation Java Plug-In on
the Java
Plug-In forum.
If you find a bug in the next-generation Java Plug-In, please report
it using the Sun Bug
Reporter. Please first query the Sun Bug Database under Category
Java Plugin, Subcategory plugin2 to see whether the bug
has been reported already. When filing a bug, please use the
Product/Category Java Plug-in, Subcategory plugin2, and
provide the following information:
- Operating system name and version
- Web Browser name and version
- URL of the applet not working, or better, a self-contained test case
- Clear instructions on how to execute the applet and reproduce the failure
- What the failure mode is (i.e., expected and actual behavior)
- The output from the Java Console (enable the Java Console in the Advanced tab of the Java Control Panel)
- Logging output (enable logging in the Advanced tab of the Java Control Panel)
- On Windows: logs go into e.g. C:/Documents and Settings/[username]/Application Data/Sun/Java/Deployment/log/
- On Unix: logs go into ~/.java/deployment/log/
Please find and send the correct log and trace files for the failure.
