JDK-6658528 : Must make temporary copy of nativelib extensions for JNLP-launched applets
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-02-03
  • Updated: 2010-09-08
  • Resolved: 2008-03-25
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.
JDK 6
6u10 b13Fixed
Related Reports
Relates :  
JDK-6606784 - Add support for launching applets from JNLP files
Description
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 Java level.

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 must be made for each JNLP2ClassLoader which loads them.
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6658528.0 testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6658528/
04-02-2008
EVALUATION 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 Java level. 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 associated ClassLoader.
04-02-2008