Next Generation in Applet Java Plug-in Technology

Print-friendly Version

Articles Index

Applets are back!

It's time to take another look at Java applet technology for delivering your programs over the web. The Next-Generation Java Plug-in Technology runs applets in a different, more efficient and more reliable way than ever before. Now you can reap the following benefits:

• Improved reliability
• Improved user experience
• Applets launch in the background
• Built-in JNLP support
• Per-applet command line arguments
• Heap size, Java 2D API acceleration options
• Improved Java/JavaScript programming language integration
• Improved Windows Vista support
• Signed applets now work correctly in Protected Mode Internet Explorer

The next-generation Java Plug-in offers a completely redesigned architecture, and is available in the Java SE 6 Update 10. This plug-in 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 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.

The new way of executing applets has architectural similarities to Java Web Start technology, but tighter browser integration. Applets no longer execute in a Java Virtual Machine (JVM) inside the web browser. Instead, a separate JVM machine process is launched to execute applets. By default, only one JVM machine is launched, but you have the opportunity to launch more than one JVM machine, and you get support per-applet command-line arguments, so you can affect heap size or other requests.

Figure 1. Applet Architecture

In Figure 1 above, the clouds represent JVM instances. There is a small, headless JVM inside the browser that is used to manage the connections to one or more client JVMs that actually run the applets. In the diagram the Dukes represent applets. One JVM instance is running two applets and the other is running one.

Applets launch directly from JNLP files, make use of the same descriptor used by Java Web Start software, and allow more powerful parameters than the classic “archive", “code", and “cache_archive" parameters.

The new plug-in provides:

• access to advanced JNLP extensions previously available only to Java Web Start software applications. A small set was previously available, with restrictions, and these restrictions have now been removed.
• access to the JNLP APIs from applets.
• PersistenceService, DownloadService.
• control over heap size, command-line arguments, JRE version selection, and auto-download. You have the same capabilities as Java Web Start software for applications.

Now, you use something like the following on the web page:

<applet width="500" height="500">
   <param name="jnlp_href" value="my_applet.jnlp">
</applet>

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.

The applet behaves exactly like an application started with Java Web Start software. jnlp_href parameter bridges between the web page and the JNLP description of the applet. Applet tag and JNLP file have overlapping mechanisms for specifying things like the width and height.

In general you should use 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.

Now, it's also much easier to configure applets in several areas, including heap size, the Java version that needs to be used, classloader cache, borders, and more.

The <applet> tag and the JNLP file have overlapping mechanisms for specifying certain parameters. These conflicts are resolved as follows:

• width and height: these attributes are always taken from the <applet> tag and not from the JNLP file. The assumption is that the browser knows best how big the applet should be on the web page, and only the browser can support page-relative width and height (for example, width="50%").
   
  
• codebase: if the JNLP file specifies an absolute codebase in the <jnlp> tag, then that is used. Otherwise, it is composed using the rules described in the codebase handling section.
   
  
• code: when the jnlp_href parameter is specified, the applet's main class name is taken from the main-class parameter to the applet-desc tag in the JNLP file, and the code attribute is ignored. Note that this feature allows you to write one applet tag which has a fallback case for the classic Java Plug-in, but which enables more advanced functionality with the new Java Plug-in. See the "Compatibility" section below.
   
  
• Any applet parameters specified using the <param> tag are merged with those specified in the JNLP file. If the same parameter is specified through both the <applet> tag and the JNLP file, the <applet> tag's version overrides the JNLP file's version, except for the java_arguments and java_version parameters.
   
  
• The new java_arguments and java_version parameters are unnecessary in JNLP applets. The mechanisms in the JNLP file for requesting a JRE version, or passing command-line arguments to the JVM, are used instead. Command-line arguments and JRE version requests from the JNLP file override those specified in the HTML for the applet.
   
  
• Certain parameters, such as image, boxbgcolor, and so forth are useful early in the applet's startup process. It may be advantageous to specify such parameters in the HTML instead of in the JNLP file so that they are available immediately upon loading of the web page rather than after the separate downloading of the JNLP file.

In the past, the maximum heap size that could be specified for applets through the Java Control Panel was limited. This limitation is fixed in the new Java Plug-in, and applets can now utilize as much heap space as command-line applications. 

• 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 through JOGL:
   
  

  <APPLET archive="my_applet.jar" code="MyApplet" width="300" height="300"> <PARAM name="java_arguments" value="-Xmx256m -Dsun.java2d.noddraw=true"> </APPLET>

   
  

An applet may force itself into its own JVM machine instance separate from all other applets if you like:

<param name="separate_jvm" value="true" />

This is useful when migrating certain kinds of desktop applications to work in the web browser.

You can also run a particular applet on a particular version of the JRE, as shown below:

<j2se version="1.4+" ...>
<j2se version="1.5*" ...>

This approach is useful for enterprises that want to QA an applet against a particular JRE version, or the applet supersedes earlier version selection mechanisms like CLSID in Internet Explorer. If a very old JRE version is requested, restrictions are enforced and the user will be prompted if the applet attempts to load unsigned code.

Note that since JNLP support is first available in Java Plug-in in the Java Platform, Standard Edition 6 (Java SE 6) Update 10, version specifications like “1.4+" are basically meaningless. This will have more meaning when “1.7+" is needed.

In addition, you can use the <update> tag in the JNLP file to drastically reduce startup time for second and subsequent launches:

<update check="background">

In this case, it will use the version of the applet that is already in the cache, and downloads updated versions of the applet in the background. At the next launch, the new version is picked up.

The new plug-in also 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>

It's now much easier to maintain backwards compatibility. You can author content that runs with earlier versions of Java Plug-in, but which takes advantage of new features by simply providing a fully-formed <applet> tag as well as the jnlp_href parameter. Earlier JRE versions ignore the jnlp_href parameter, and use the <applet> tag instead. The new Java Plug-in technology ignores the archive and code parameters and use only the JNLP file to launch the applet.

The NASA World Wind Java applet example, by the World Wind Java development team, illustrates how to deploy leading-edge libraries like NASA World Wind Java, as well as how to effectively combine HTML and content in a web page using JavaScript.

Figure 2. NASA World Wind Applet

The web page contains information about the Cascade mountain range (thanks to Wikipedia) and embeds World Wind Java as an applet to illustrate the locations of the mountains in the range. Incorporating World Wind in a web page is remarkably easy. Here is the <applet> tag embedding it on the page:

<applet id="wwjApplet" width=600 height=380             
	code="gov.nasa.worldwind.examples.applet.WWJApplet"             
	archive="BackwardCompatibility.jar">
<param name="jnlp_href" value="WWJApplet.jnlp">     
</applet> 

The WWJApplet ships with the standard World Wind Java distribution. You might choose to write your own applet class and embed World Wind inside it, as described below:

Here are the relevant portions of the WWJApplet.jnlp file:

<jnlp href="WWJApplet.jnlp">
<resources os="Windows">         
<property name="sun.java2d.noddraw" value="true"/>       
</resources>       
<resources>         
<j2se href="http://java.sun.com/products/autodl/j2se" version="1.4+"/>         
<jar href="worldwind.jar" main="true" />         
<extension name="jogl"            
 href="http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp" />       
</resources>       
<applet-descname="WWJ Applet"           
   main-class="gov.nasa.worldwind.examples.applet.WWJApplet"           
<!-- Overwritten by the surrounding web page -->           
						   width="100"            
						   height="100">       
</applet-desc>     
</jnlp> 

Some items to note:

• worldwind.jar is used as the main jar in this example. Ideally, it would be referenced as an extension JNLP from NASA's web site, which allows many different applications or applets all embedding World Wind to share the same downloaded jar file. See below for more details.
   
  
• World Wind Java uses the Java Binding to the OpenGL API, JOGL, for its hardware-accelerated 3D graphics. Note that the JOGL JNLP extension is incorporated into the application with a single line of code. Note also that on the Windows platform it is necessary to specify the system property -Dsun.java2d.noddraw=true due to driver-level conflicts between the OpenGL API and the DirectDraw/Direct3D APIs used by the Java 2D implementation by default on the Windows platform. This system property is needed on Windows for all applications and applets using JOGL.

The HTML links on the web page call JavaScript functions which interact with the applet to navigate it to the appropriate mountain. Here is an example of one of these links:

<a href="javascript:gotoLocation(MOUNT_RAINIER);">Mount Rainier</a>     
  (southeast of Tacoma, Washington) ...  

When the link is clicked, the JavaScript function gotoLocation is called. It is defined on the same web page:

function gotoLocation(locationString) {        
 var params = locationString.split(';');        
 if(params.length == 3)	// Lat/lon         
 getWWJApplet().gotoLatLon(parseFloat(params[1]),                                     
 parseFloat(params[2]));        ...     }  

The locations of the mountains are encoded as JavaScript strings in the HTML of the web page. The latitude, longitude, and other viewing information is parsed out of these strings and passed into the applet. The gotoLatLon method is defined on theWWJApplet class; the above call to this method initiates a JavaScript-to-Java call, passing the parameters from the JavaScript engine to Java. The World Wind applet takes in this notification and animates the viewpoint to the appropriate place. Note that the gotoLatLon method returns quickly, so that the browser is not waiting for it to complete; the animation is performed on a separate Java thread.

Figure 3. World Wind Applet with Mount St. Helen's Clicked

As mentioned above, the preferred method of incorporating World Wind Java into your application or applet is as a JNLP extension. This allows the World Wind code resources to be shared among many applications or applets from around the web which incorporate it. To reference the World Wind JNLP extension, you would add the following lines to your application's or applet's JNLP file in the <resources> section:

<extension name="worldwind" href="http://worldwind.arc.nasa.gov/java/0.4.1/webstart/worldwind.jnlp"/>     
<extension name="jogl"       
	 href="http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp"/>

Note that the World Wind extension JNLP is versioned, so you would need to consult the World Wind documentation or visit the forums to find the most current version to reference from your JNLP. The World Wind Central site is a useful source of up-to-date information on World Wind.

Using World Wind as an extension implies that you can not use the WWJApplet as your main-class directly. Due to the semantics of the JNLP file format, the main jar (main="true") must be defined in the main JNLP file. This is an easy restriction to satisfy, however. You can simply create your own subclass of WWJApplet (call it MyWWJApplet) which does nothing:

class MyWWJApplet extends WWJApplet {}

Compile this with worldwind.jar on the classpath, and then bundle this class into its own jar file. Reference that as your main jar and MyWWJApplet as your main-class, and then pull in World Wind as the extension JNLP.

The introduction of JNLP support in the Java Plug-in opens up many new possibilities for applet deployment and represents a large step forward in the unification of the deployment of Java content both in and out of the browser. Applets have come a long way since their inception, and now with the JNLP support, they're faster and more customizable than ever.

Release Notes for the Next-Generation Java Plug-in Technology
JNLP Support in the New Java Plug-in Technology
NASA World Wind Applet Test Page
Deploying - Java Plug-In forum
Java Plug-In forum on java.net