United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4642062 : cannot load same DLL from more than one applet in browser

Details
Type:
Enhancement
Submit Date:
2002-02-22
Status:
Closed
Updated Date:
2002-05-28
Project Name:
JDK
Resolved Date:
2002-05-28
Component:
hotspot
OS:
windows_2000
Sub-Component:
runtime
CPU:
x86
Priority:
P4
Resolution:
Won't Fix
Affected Versions:
1.4.0,1.4.1
Fixed Versions:

Related Reports
Duplicate:

Sub Tasks

Description

Name: gm110360			Date: 02/22/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :

Win family

A DESCRIPTION OF THE PROBLEM :
I have 2 applets that utilize same DLL, first loads
correctly in browser, second always fails
with "unstatisfied link error", "dll already loaded by
another classloader".

now, i've read all the other bug reports associated with
this and i still believe it to be a MAJOR bug.  isn't the
purpose of DLL (and SO) architecture to allow many
application codebases can access the same DLL codebase
(with different data contexts of course) ?  this
classloader BUG defeats the entire purpose of using SHARED
LIBRARIES...

it seems that if a classloader should ignore the list of
loaded libraries from all other classloaders and just call
the OS specific loadLibrary routine.  The OS will take care
of reference counting the DLL instance.  Given that the
OSes take care of shared library loading/unloading, the
functionality of the classloader to duplicate this list is
unnecessary (and would eliminate the problem in the first
place).

Which brings me to the second part of the bug report.  The
classloader needs to call the OS-specific unloadLibrary on
finalization to have the OS maintain the correct instance
count.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. load applet 1 with loadLibrary call to JNI.dll
2. load applet 2 with loadLibrary call to same JNI.dll
3. sit in awe

EXPECTED VERSUS ACTUAL BEHAVIOR :
expected result: second application should load the JNI.dll

actual result: "unsatisfied link error", "dll already
loaded by another classloader".

ERROR MESSAGES/STACK TRACES THAT OCCUR :
unsatisfied link error", "dll already loaded by another classloader".

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class app1 extends java.awt.Applet  {
  static {
    loadLibrary("myjni.dll");
  }
   ...
}


-----------------------------

public class app2 extends java.awt.Applet {
  static {
    loadLibrary("myjni.dll");
  }
   ...
}

---------- END SOURCE ----------

CUSTOMER WORKAROUND :
wish i knew
(Review ID: 143222) 
======================================================================

                                    

Comments
EVALUATION


###@###.### 2002-05-28
Will not fix.  This is intentional.  Each applet is loaded with its own 
classloader, and a native library cannot be loaded by more than one classloader.
This is in part a security concern, as we don't want one classloader's app to
muck up another classloader's app by tampering with native library state.
                                     
2004-06-11



Hardware and Software, Engineered to Work Together