Next-Generation Java™ Plug-In Technology Introduced in Java SE 6 update 10

Table of Contents

• Introduction
• Supported Platforms and Browsers
• Installation
• New Parameters to the <applet>, <object> and <embed> tags
  • JNLP Support
    • jnlp_href
  • Loading Screen
    • boxborder
    • centerimage
  • Command-line Arguments and JRE Version Selection
    • java_arguments
    • java_version
    • separate_jvm
  • Class Loader Caching
    • classloader_cache
• Java Control Panel Changes
  • Applet Runtime Settings
  • Switching Between the New and Classic Plug-Ins
• Cross-Domain XML Support
  • Alternate locations for policy files
• Simplified Common DOM Support
• New LiveConnect Specification
• Experimental Functionality
• Demos
• Additional Resources
• Feedback

Introduction

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, introduced 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 JRE version support. Each individual applet instance may request a different JRE version on which to run. This feature is designed for enterprise customers which prefer to qualify their applets against either a particular JRE version or a particular JRE family. Both selection of a specific JRE 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:

Supported Platforms and Browsers

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

While other browsers are not specifically supported by Sun, if the browser is on one of the supported platforms and supports the latest version of the NPAPI and NPRuntime interfaces, the new Java Plug-In for Firefox (npjp2.dll on Windows and libnpjp2.so on Unix platforms) should work in the browser. (Certain functionality, such as cookie access, access to browser proxy settings and access to the browser's authentication results may not currently work.)

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.

Installation

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

New Parameters to the <applet>, <object> and <embed> tags

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.

JNLP Support

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.

jnlp_href

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.

Loading Screen

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:

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>

Command-line Arguments and JRE Version Selection

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; see the discussion of command line argument specification in JNLP-launched applets.

java_arguments

Specifies JVM command-line arguments to be used when executing this applet instance.

Examples

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

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

3. Enabling the assertion facility in the Java programming language:

   <APPLET archive="my_applet.jar" code="MyApplet" width="300" height="300">
       <PARAM name="java_arguments" value="-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. All command-line arguments specified via the java_arguments parameter must come from this secure set.

A more thorough discussion of the handling of per-applet JVM command line arguments, including interaction with arguments specified in the Java Control Panel, is in the section on command line arguments for JNLP-launched applets. The java_arguments parameter and command line arguments for JNLP-launched applets are built with the same underlying mechanism, so their handling is similar.

java_version

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

Examples

1. Specifying a particular JRE 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 JRE 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, JRE Version Selection in the Next-Generation Java Plug-In.

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>

Class Loader Caching

classloader_cache

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.

Java Control Panel Changes

Applet Runtime Settings

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 JRE 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 JREs from the list. On the Windows platform, all installed JREs show up in the list automatically. The "Find" button allows quick configuration of additional JREs that may have been simply unzipped on the local disk rather than installed. The "Enabled" checkbox allows control over which JREs the new Java Plug-In will use when considering a given applet's request to run on a particular version of the JRE.

As before, the Java Runtime Parameters field allows specification of command-line arguments to be applied to all applets run in that particular JRE 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.

Switching Between the New and Classic Plug-Ins

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.

Cross-Domain XML Support

Ordinarily, unsigned Java applets or applications may only connect back to the web server from which they originated. This restriction prevents an applet from causing denial-of-service attacks by making rapid connections to arbitrary machines on the Internet.

In Java SE 6 update 10, both the Java Web Start and Java Plug-In technologies contain preliminary support for cross-domain policy files, which specify how unsigned code may access web services on the Internet. The crossdomain.xml policy file is hosted on a given server and allows either selected clients, or clients from anywhere, to connect to that server. Cross-domain policy files make accessing web services much easier, particularly from unsigned applets.

General documentation on cross-domain policy files may be found here:

• Cross-domain policy file specification (non-Sun site)
• Policy file changes (non-Sun site)

Java Web Start and the Java Plug-In currently implement only a subset of the cross-domain policy file functionality. Specifically, site access restrictions are not supported. Access to a particular server is only granted if the crossdomain.xml file is present and contains only an entry granting access from all domains:

    <cross-domain-policy>
        <allow-access-from domain="*" />
    </cross-domain-policy>

Alternate locations for policy files

By default, if an applet attempts to connect to the host www.server.com, the system will look for a cross-domain policy file at http://www.server.com/crossdomain.xml. Some web services, however, publish their cross-domain policy files at alternate locations.

An applet or application may specify one or more alternate policy file locations using the jnlp.altCrossDomainXMLFiles system property, which takes a comma-separated list of URLs from which policy files may be loaded. For example:

 -Djnlp.altCrossDomainXMLFiles=http://photos.googleapis.com/data/crossdomain.xml,http://foo.bar.com/baz/crossdomain.xml

Simplified Common DOM Support

Since Java SE 1.4, applet developers have been able to traverse the Document Object Model (DOM) of the document containing their applet using the Common DOM API. The Common DOM implementation has been rewritten and simplified in the new Java Plug-In, and is now both more robust and easier to use.

Most importantly, the bootstrapping mechanism for acquiring the the Document object has been simplified. There is now one simple entry point which can be called from any thread:

    package com.sun.java.browser.plugin2;
    
    public class DOM {
        public static final org.w3c.dom.Document getDocument(Applet applet)
            throws org.w3c.dom.DOMException;
    }

An applet may call this method as follows:

    org.w3c.dom.Document document =
        com.sun.java.browser.plugin2.DOM.getDocument(this);

    org.w3c.dom.Document document = null;
    try {
        Class c = Class.forName("com.sun.java.browser.plugin2.DOM");
        Method m = c.getMethod("getDocument",
                               new Class[] { java.applet.Applet.class });
        document = (org.w3c.dom.Document)
            m.invoke(null, new Object[] { this });
    } catch (Exception e) {
        e.printStackTrace();
    }
    if (document != null) {
        // ... Manipulate the document ...
    }

Once you have acquired the Document object, you may cast it to HTMLDocument, and generally use any of the APIs in the org.w3c.dom namespace.

The implementation of the Document and other APIs is thread safe; changes to the document by multiple threads will be performed in an unspecified order. Applets still need to take care, and perform appropriate synchronization, if they intend to modify the same portion of the document concurrently.

The following is a simple test applet which descends recursively into the DOM of the document which contains it, and prints each HTML tag and its attributes to the Java Console. Note that it is not specified exactly which attributes are returned when querying a given node for its attributes, so the output is slightly different on different browsers. Most applets that modify the DOM will probably not be affected by these differences, as they will likely look up and manipulate specific attributes of a node rather than query for all of the available attributes.

• DOMDump test case
• DOMDump.java applet source code

For more information, see:

• Javadoc for the new Common DOM entry point
• Common DOM API reference

New LiveConnect Specification

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.

A new LiveConnect specification both documents the behavior of the Java/JavaScript bridge in the new Java Plug-In, and specifies how alternate implementations of a Java Plug-In should behave to support portability of mixed Java/JavaScript code.

Experimental Functionality

With Java SE 6 Update 10, Sun Microsystems, Inc. introduces a new paradigm for application deployment over the Internet: the ability to drag a live, running applet out of the web browser, dynamically transforming it into an application running on the desktop. The application can be re-launched later from a desktop shortcut or launch menu item using the standard JNLP and Java Web Start technologies. This capability is unique to the Java platform, and represents a complete unification of development and deployment in the web browser and on the desktop.

This functionality is currently considered experimental, and may change or be removed in future releases. With that caveat, Sun welcomes your comments, suggestions and other feedback on this capability, in particular via the Java Plug-In forum.

To enable an individual applet to be dragged out of the web browser, add the following parameter to your <applet> tag:

<param name="draggable" value="true">

By default, the gesture to drag the applet out of the web browser is Alt + Left click + Drag. On some platforms (X11 in particular), this particular gesture is usually intercepted by the window manager to move entire windows around the desktop. You can customize exactly what gesture initiates the drag operation by providing a public isAppletDragStart method on your applet class:

public boolean isAppletDragStart(MouseEvent e);

This method will be called for each candidate MouseEvent: those occurring over the applet or any of its sub-components. When your applet first returns true from this method, the Java Plug-In will initiate the drag operation and make the applet track the mouse pointer. It is currently implicitly assumed that a mouse release event involving mouse button 1 ends the drag operation, placing the applet on the desktop.

Note that even after the applet has been dropped on to the desktop, the drag gesture can still be used to move it around the screen. The isAppletDragStart method will continue to be called for these repeated move operations around the screen. You can change the behavior before and after the applet is dropped on to the desktop, if you like, using the notification methods below.

When the drag operation begins, the applet is removed from its original parent container in the web page and placed in a new, undecorated, top-level window. A Frame is used for applets subclassing java.applet.Applet; a JFrame is used for applets subclassing javax.swing.JApplet.

If your applet supplies the method

public void appletDragStarted();

• the applet has been removed from its original parent
• it has been placed into the new undecorated top-level Frame or JFrame
• the new Frame or JFrame is not yet visible

public void appletDragFinished();

By default, a small, floating "close button" will be drawn above and to the right of the applet's region, and tracks the applet as it moves around the screen. You can customize this user interface. If your applet defines the method

public void setAppletCloseListener(ActionListener l);

If the user clicks the close button while the web page that originally contained the applet is still visible, then the applet will be placed back into its original location on the page, and the method

public void appletRestored();

If the user drags an applet out of the web page and then navigates away from that web page, or shuts down the web browser, the applet is conceptually "disconnected" from the web browser. This means that certain services, such as Java/JavaScript communication, are disabled. Other browser services, such as the implementaton of AppletContext.showDocument(), are replaced with alternate implementations that have slightly less fine-grained control. Specifically:

• Any attempt to call from Java to JavaScript via the netscape.javascript.JSObject class will result in a JSException.
• Any calls to AppletContext.showDocument will open a new browser window. If a call is made to showDocument(URL url, String target), the target will be ignored.
• Calls to AppletContext.showStatus will display the string in the Java Console (assuming it is open) rather than in the browser's status bar.
• Queries of proxy settings and cookies, which are normally redirected back to the web browser, are instead handled by the platform-specific settings. For example, on the Windows platform, the proxy settings for Internet Explorer are implicitly the system-wide proxy settings, and will be used for a disconnected applet even if Firefox was originally used to launch the applet.

A significant unification occurs when the new JNLP support in the Java Plug-In is used to describe the applet in conjunction with the draggable applet feature. In this case, the applet really does transform exactly in to a Java Web Started application as it is disconnected from the browser. If the new jnlp_href applet parameter is used, and the shortcut tag in the JNLP file is added in order to request that a desktop shortcut and/or start menu option be added, then these shortcuts will be created (possibly after the user accepts a dialog box, depending on their Java Control Panel settings) as the applet is disconnected from the web browser. The shortcut can then be double-clicked to re-launch the applet. This means that the operation of dragging the applet out of the browser can be used as the installation step for your application.

While re-launching the applet from a desktop shortcut, the appletDragStarted and appletDragFinished methods will still be called under the same conditions as when the applet was dragged out of the browser, so you only need to write any setup code once and it will still work for the shortcut re-launch scenario.

NOTE that the shortcut creation process requires the use of an absolute codebase in the jnlp tag in the applet's JNLP file. This unfortunately does not follow the best practice advice for deployment with the new Java Plug-In, which is to leave the codebase unspecified and allow it to be picked up from the web browser. We hope to improve this behavior in later builds. Additionally, for your desktop shortcut to size the applet correctly, you should specify the desired width and height in the applet-desc tag in your JNLP file, since when relaunching from the shortcut, the browser will not be available to help size the applet. This behavior may also be improved in later builds.

Here is a simple example illustrating some of the features above. The applet below can be dragged out of the browser by left-clicking and dragging on the red bar at the top of the applet. The applet defines the isAppletDragStart method to change the drag gesture in this way. Once dragged out, it can be closed by clicking the small "X" in the upper right corner of the applet. The applet defines the setAppletCloseListener method to gain visual control of the close button. If the applet is disconnected from the browser, a prompt to create a desktop shortcut will be shown. This is achieved using the <shortcut> tag in the applet's JNLP file. Double-clicking the shortcut icon will re-launch the applet without opening the web browser.

The applet below requires the new Java Plug-In, and currently runs in IE 6 and later as well as the Firefox 3 early access builds. It does not run in Firefox 2.

The two buttons on the applet illustrate how the services provided to the applet change as it is disconnected from the browser. Clicking the "Reopen Web Page" button will use the AppletContext.showDocument() API to navigate the browser to the originating page of the applet. If this button is clicked while the original web page hosting the applet is still visible, it will essentially force a reload and cause the applet to be disconnected from the browser. Once the applet has been disconnected, however, clicking this button will cause a new web browser window to be opened, which is how the JNLP BrowserService API works. This happens because once the applet has been disconnected from the browser, it can no longer communicate with that browser instance.

Clicking the "Show Applet Status" button will change the browser's status bar while the applet is still connected to the browser, and will print its output to the Java Console once the applet has been disconnected from the browser.

The source code for this example may be downloaded here:

• Source code
• Associated JNLP file

Demos

Demonstrations of the new capabilities of the Java Plug-In are now available:

• Several Scene Graph Demos (opens new window) are now available as applets. There is an in-depth discussion of the deployment of these examples.
• A JavaFX Script demonstration applet (opens new window) shows how to deploy this new kind of Java platform content on the web. There is an in-depth discussion of the deployment of this example.
• Some simple LiveConnect tests (opens new window) illustrate some of the new Java/JavaScript interoperability features of the new Java Plug-In.
• A NASA World Wind Java applet example (opens new window) shows how to embed the Earth in full 3D on a web page. There is an in-depth discussion of the deployment of this example.
• Jake2 running as an applet (opens new window) illustrates the future of game deployment over the Internet. There is an in-depth discussion of the deployment of this example.

Additional Resources

• The JavaOne 2008 technical session on the new Java Plug-In provides a high-level overview of the new functionality now available to applet developers.
• An Ask the Experts session covering Java SE 6 Update 10 answers some common questions about the new Java Plug-In.

Feedback

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.