JDK-6606784 : Add support for launching applets from JNLP files
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.4.0,6,6u5,6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS:
    generic,windows,windows_nt,windows_xp generic,windows,windows_nt,windows_xp
  • CPU: generic,x86
  • Submitted: 2007-09-19
  • Updated: 2017-05-16
  • Resolved: 2008-02-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6u10 b12Fixed 7Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
The new out-of-process Java Plug-In is capable of spawning a new JVM
instance to run a particular applet. With this capability, it is now
feasible to launch applets directly from JNLP files, which can contain
elements describing a JRE version, JVM command-line arguments, heap
size and the like.

This capability would be a major improvement for developers. Existing
and future JNLP extensions for 3D, spatialized audio, video, etc.
would immediately work transparently for both applets and Java Web
Start applications.

The following describes the approximate launch sequence in the context
of the new Java Plug-In.

1. A plugin instance is created for an applet tag looking something
   <applet href="http://.../foo.jnlp">

2. A StartAppletMessage is passed to an attached client JVM process,
exactly as is currently done. Note that if a JVM instance must be
created for this purposes, the default command-line arguments are

3. The client JVM must recognize that the incoming parameters of the
StartAppletMessage represent a launch from a JNLP file rather than a
launch from a traditionally-formed applet tag -- the presence of the
"href" parameter is probably the best indication, in which case the
code base, archive tag, etc. (if present) would be ignored.

4. The client JVM makes the network connections to download the main
JNLP and parses it, downloading and parsing any extension JNLPs as
well. Ideally code from Java Web Start can be used unmodified for this

5. The client JVM determines based on the JRE version, command-line
arguments, etc. used to launch the current JVM whether the currently
executing JVM is capable of satisfying the parameters required by the

6. If the currently running JVM instance can not satisfy the
parameters requested in the JNLP file, a relaunch is needed. In this
case, the client JVM sends a message back to the web browser
containing all of the results of parsing all of the JNLPs, so that
re-downloading and re-parsing is not necessary. The associated data
structures for this purpose might be more complex than the basic
Serializer class currently supports (two-dimensional arrays of Strings
are about the most complex structure for which it has built-in
support). We would need to consider adding either more support to the
Serializer (for example, three-dimensional arrays of Strings) or
writing helper classes for serialization of this information.

7. Once we are in the JVM instance in which the launch will occur,
checks are needed to see whether all of the system properties, for
example, requested in the JNLP file are "secure" system properties. A
check to see whether the target applet is signed may be required at
this point. (Other policies enforced by Java Web Start in this area,
such as a maximum heap size, should be enforced as well.)

8. If all checks pass, the launch of the applet proceeds in this JVM.

Some issues:

 - javaws.jar will need to be placed on the boot class path along with
   deploy.jar and plugin.jar in JavaVM.c. We need to think about
   whether we want to guarantee the availability of things like the
   Java Web Start services (in particular, the PersistenceService) for
   all applets or just ones launched via JNLP files. We might need to
   play tricks with permissions and accessClassInPackage if we decide
   to only support this for JNLP-launched applets.

 - Some changes are known to be needed to the Applet2ClassLoader
   implementation in order to be compatible with support for Java Web
   Start. For example, the JNLPClassLoader overrides
   ClassLoader.findLibrary() in order to provide support for nativelib
   jar files. Currently the Applet2ClassLoader does not override
   findLibrary() at all.

   An issue in this area is that the Applet2ClassLoader is tightly
   bound to the Applet2SecurityManager, so we can't simply switch away
   from using the Applet2ClassLoader. Ideally we could refactor the
   bulk of the code in the JNLPClassLoader into a helper class (which
   wouldn't actually be a ClassLoader) so that the JNLPClassLoader
   would then become a thin skeleton and the Applet2ClassLoader could
   then refer to that code. Other solutions might be possible.
As part of this feature it would be nice if we could support changing the icon in security dialogs when a validated certificate is in use. This was requested on the JavaDesktop forums at http://forums.java.net/jive/thread.jspa?threadID=31538&tstart=0 . See comments for more details.
Support for the nativelib tag in extension JNLPs needs to be done slightly differently than in Java Web Start. In the Java Plug-In, it is feasible that more than one class loader in the same JVM instance may attempt to reference the same JNLP extension containing native code, and ultimately try to load the same DLL / .so off the local disk. Loading the same shared object in multiple class loaders is forbidden due to type safety issues (see section 11.2.4 in the book "The Java Native Interface").

The solution to this problem in the Java Plug-In's class loader supporting JNLP will be to make a fresh copy of the native library into a temporary directory before loading it in a given ClassLoader instance. Note that at most one copy needs to be made for a given ClassLoader. This is what is done in the JNLPAppletLauncher at http://applet-launcher.dev.java.net/ .

SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6606784.4

EVALUATION 6606784 : Add support for launching applets from JNLP files Added support for describing and launching applets inside the web browser via JNLP files through a new "jnlp_href" parameter to the applet, object and embed tags. The core Java Web Start code is reused to download and parse the JNLP descriptor and the applet's resources. Only the applet-desc tag is supported in the main JNLP file, as the launch type. The JNLP file may refer to extension JNLPs, etc., in exactly the same way that ordinary applications launched via Java Web Start do. The JNLP services (BasicService, PersistenceService, etc.) are accessible to applets launched via JNLP files. Refactoring was necessary at the bottommost level in these service implementations to abstract how they fetch the current JNLP class loader and from there the LaunchDescriptor. A new interface, JNLPClassLoaderIf, has been introduced which is implemented both by Java Web Start's JNLP class loader as well as the new Java Plug-In's. For technical reasons it is not possible to simply use Java Web Start's class loader in the context of the Java Plug-In. In order to support both old-style applets as well as applets launched via JNLP files in the new Java Plug-In, most of the code which handles applets in the new Java Plug-In was refactored into abstract base classes. Plugin2ClassLoader and Plugin2Manager have been introduced which contain the bulk of the code from the previous Applet2ClassLoader and Applet2Manager. Applet2ClassLoader and Applet2Manager are now specializations which support old-style applet concepts such as the class loader cache and legacy applet lifecycle. The new JNLP2ClassLoader and JNLP2Manager are specialized to handle the slightly different semantics of JNLP resource loading in the context of applets. More work is expected after the initial integration to iron out rough edges such as better integration with the Java Plug-In's gray box animation, etc. This work will be done under follow-on bug IDs. Early testing by ###@###.### and ###@###.### from SQE uncovered a few bugs in proxy and cookie handling as well as the SingleInstanceService which have been fixed in this putback. Approved by the CCC. testcase: [several standalone tests being integrated with this putback, but no individual regression test for this putback]

EVALUATION Kenneth's implementation proposal is sound. A note regarding the JNLP file access for normal applets is added under comments. This work package is split in the following modules - JWS reusability - Split JNLPClassLoader into JNLPClassLoaderTool + JNLPClassLoader - TinyBrowserJVM <-> FatExternalJVM JNLP messaging - FatExternalJVM : - JNLP parsing - JNLPClassLoaderTool usage in Applet2ClassLoader - JNLP/Jar validation -> possible FatExternalJVM switch - Security .. Each module shall be tested. Proper documentation will follow.