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

Maurizio Cimadamore maurizio.cimadamore at
Wed Mar 18 19:13:25 UTC 2020

On 18/03/2020 18:40, Mandy Chung wrote:
> On 3/18/20 11:16 AM, Maurizio Cimadamore wrote:
>> 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?
> I think such distinction is kind of blurry at the moment.   One thing 
> for sure is that JNI native method binding won't happen with the 
> native libraries loaded through this new mechanism.
> OTOH, should JNI_OnLoad and JNI_Unload be invoked if it is a non-JNI 
> library?  The new mechanism still does.  I expect that this will be 
> cleared up from panama specification.
Should defo not happen in Panama-loaded libraries
> However, you raise a good point that this is not only about 
> auto-unloading (which I got trapped as this patch is all about).    No 
> JNI native method binding is another significant part.
>> 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)
> JNI native method binding will lookup methods from these libraries.
Yeah that too
>> Or are there cases where you envision more mix and match? E.g. JNI 
>> libraries w/o auto-unloading?
> No as unloading is important for native library loaded by custom loaders.
> I can't really think of a good static factory method name.
> would newNonJavaNativeLIbraries be slightly clearer?




could be an option.

Another option, in case we do care about mix and match, would be to use 
a builder - which would allow us to specify whether we want:

* auto-unloading
* classloader restrictions
* calling JNI hooks
* support linking of JNI methods

But I don't think we need such level of granularity for now.


> Mandy
>> 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