The Java platform has rules about not allowing the same native library
to be loaded by more than one ClassLoader instance simultaneously.
These rules are designed to reduce the risk of violating the Java type
system and to prevent static state in C code from leaking up to the
The common JNLP code in the deployment workspace unpacks nativelib jar
files associated with JNLP extensions into the deployment cache, but
only one copy of these shared objects is made. This is fine in the
context of Java Web Start, but does not work at all for the Java
Plug-In, where multiple applets running simultaneously in the same JVM
may attempt to access the same JNLP extension and therefore the same
nativelib jar files.
To solve this problem, a temporary copy of the shared objects in each
nativelib jar file is made for each JNLP2ClassLoader which loads them.
This technique is similar to that used in the open-source
JNLPAppletLauncher project on java.net
(https://applet-launcher.dev.java.net/), but is simpler because it
builds on top of the existing JNLP infrastructure rather than
attempting to emulate portions of it.
We attempt to clean up the temporary copies of these shared objects
when the ClassLoader is unloaded. Failing that, upon JVM startup, we
attempt to clean up stale temporary copies from earlier JVM instances.
These cleanup mechanisms have been tested and verified.
Note that this work turned up a very interesting and longstanding
problem in the JOGL library
(https://jogl.dev.java.net/issues/show_bug.cgi?id=341) which was
preventing clean termination of JOGL applets and unloading of the