Bug ID: JDK-4969756 win32: different apps can not load native libs with the same name from MLET

Versions (Unresolved/Resolved/Fixed)

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.

Other
5.0 b38Fixed


Name: poR10007			Date: 12/17/2003



The MLet service provides the ability to load MBean classes and native libraries
from a remote server. On win32 systems the algorithm of downloading and storing
native libraries in the TEMP directory does not allow to load native libraries
with the same name from different applications (and possibly from different
MLets). Let's one application creates a new MBeanServer, initializes m-let
service and calls getMBeansFromURL() to load an MBean stored in some jar-file.
The MBean uses a native library stored in the same jar file. When another
application running on the same system attempts to initialize an MBean
which uses the same native library, it fails. Looking at the API sources
I'd say any application trying to load a native library with the same name
through m-let service will fail.

The cause of the failure is that the temporary native library file on win32
system is write-locked while application using it is running. On Solaris
system this file can be re-written that's why the tests pass on Solaris.
But could be here a race condition when two application try to rewrite
this file simultaneously? It seems that the algorithm of dynamic loading of
native libraries should be improved.

The test reproducing the failure will be attached. Running on jdk1.5.0-b31
it fails on WinNT, Win2000 and WinXP platforms and passes on Solaris.

======================================================================

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b38 tiger-beta2 VERIFIED IN: tiger-b40
14-06-2004
PUBLIC COMMENTS .
10-06-2004
SUGGESTED FIX ======================================================================= Native library files are created using File.createTempFile() and File.deleteOnExit(). This guarantees two things, the filenames will never clash and the library files will be deleted from the disk on JVM exit. Remark: The latter is not true on Win32 platforms due to bug 4171239. File deletion (File.deleteOnExit()) does not work on Win32 unless all the opened file streams have been closed when this method is closed, which must not be the case for native libraries loaded by means of the System.loadLibrary() call. ###@###.### 2004-01-02 =======================================================================
02-01-2004
EVALUATION --- In order to avoid this problem the MLet service can rename the native library supplied in the jar file when copying it in the MLet library directory on disk. This will allow two separate applications using an MLet service configured with the same library directory to load the same native library as the name of the library on disk will be different (and unique). As a consequence of this fix, two MLets running on the same JVM will be able to load the same library too. ###@###.### 2003-12-18 --- Fix done. Same native library can be loaded now from two different MLets without file name clashes. ###@###.### 2004-01-02 ---
18-12-2003
WORK AROUND Call setLibraryDirectory on different MLets that may want to load libraries of the same name. ###@###.### 2003-12-17
17-12-2003