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

[Mandy Chung]

Alan, Maurizio,

New webrev:
http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240975/webrev.02/

newJavaNativeInterfaceLibraries  creates a NativeLIbraries for loading 
JNI native libraries.
   - native libraries are unloaded when the class loader is reclaimed.
   - Support of linking of native method as specified in the JNI spec.
   - Restriction on a native library that can only be loaded by one 
class loader.

newRawNativeLibraries creates  a raw NativeLibraries for loading non-JNI 
native libraries.
     -  non-JNI native library.  So JNI_OnLoad and JNI_OnUnload will be 
ignored.  No support for linking of native method.
     - Native libraries not auto-unloaded.  They may be explicitly 
unloaded via NativeLibraries::unload.
     - No relationship with class loaders.

The test is updated to show that JNI_OnLoad and JNI_OnUnload are ignored.

thanks
Mandy

On 3/18/20 5:39 PM, Mandy Chung wrote:
>
>
> On 3/18/20 12:13 PM, Maurizio Cimadamore wrote:
>>
>> 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
>
> OK, I will make some adjustment to ignore JNI_OnLoad and JNI_Unload.   
> I think this is a clean distinction of these two mechanisms.
>
>
> Will send an updated webrev later.
>
>>>
>>>> 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
>>
>
> Both are good to me.
>
>> 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.
>>
>
> I don't think we need that neither.
>
> Mandy
>> 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
>>>
>