Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Mar 18 18:16:36 UTC 2020


So, maybe I'm saying something naive, but isn't the difference between 
the two mechanisms mostly there to distinguish between JNI libraries and 
non-JNI libraries?

E.g. maybe we should add JNI somewhere in one of the factory (the one 
used by System.loadLibrary) and then document what are the differences 
between JNI and non-JNI libraries. We could even have different 
NativeLibrary impl for these two cases.

Seems to me that JNI libs feature:

* extra restrictions (cannot load same library in multiple loaders)
* auto-unloading guarantees (classloader-driven)

Or are there cases where you envision more mix and match? E.g. JNI 
libraries w/o auto-unloading?

Maurizio

On 18/03/2020 16:32, Mandy Chung wrote:
>
>
> On 3/18/20 8:59 AM, Alan Bateman wrote:
>> On 17/03/2020 23:09, Mandy Chung wrote:
>>>
>>> I have similar comment to myself and didn't come up good static 
>>> factory method names.   I give it a try again: what about 
>>> newNativeLibraries and newNativeLibrariesWithNoAutoUnload?
>> Would newTrustedNativeLibraries work? Everything else in the updated 
>> webrev looks good.
>
> "no auto unload" is also important.  what about 
> "newTrustedNativeLibrariesNoAutoUnload" a bit long?
>
> Mandy


More information about the core-libs-dev mailing list