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
like
   <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
used.

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

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

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