United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6658528 Must make temporary copy of nativelib extensions for JNLP-launched applets
JDK-6658528 : Must make temporary copy of nativelib extensions for JNLP-launched applets

Details
Type:
Bug
Submit Date:
2008-02-03
Status:
Closed
Updated Date:
2010-09-08
Project Name:
JDK
Resolved Date:
2008-03-25
Component:
deploy
OS:
generic
Sub-Component:
plugin
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10 (b13)

Related Reports
Relates:

Sub Tasks

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/
                                     
2008-02-04
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.
                                     
2008-02-04



Hardware and Software, Engineered to Work Together