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

[Mandy Chung]

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.

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.

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

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