JDK-6219879 : (cl) ClassLoader.NativeLibrary.load should be consistent in initialization of handleID
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang:class_loading
  • Affected Version: 6
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2005-01-21
  • Updated: 2017-11-09
  • Resolved: 2017-11-09
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 10
10Resolved
Related Reports
Duplicate :  
JDK-8164512 - Replace ClassLoader use of finalizer with phantom reference to unload native library
Description
There are some paths through the native implementation of load which do not
initialize handleID.  While not strictly necessary to clear the value, we should
consider doing so for consistency.  

###@###.### 2005-1-21 01:02:48 GMT
Comments
The fix to ensure handle is non-null has been pushed via JDK-8164512. So close this as a dup.
09-11-2017
This is not strictly necessary as NativeLibrary::handle is initialized to zero when an object is constructed. OTOH we should validate if the handle is set to non-zero when the native library is successfully loaded. I will add this check in the fix for JDK-8164512: if (!loaded || handle == 0) { throw new InternalError("Native library " + name + " not loaded"); }
22-09-2017
SUGGESTED FIX Add code to initialize the handleID on error: (*env)->SetLongField(env, this, handleID, (jlong)NULL); ###@###.### 2005-1-21 01:02:48 GMT
21-01-2005
EVALUATION The implementation is straight-forward. ###@###.### 2005-1-21 01:03:52 GMT
21-01-2005