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

[Maurizio Cimadamore]

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

newJavaNativeInterfaceLibraries

vs.

newRawNativeLibraries

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.

Maurizio

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