Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading
maurizio.cimadamore at oracle.com
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:
* classloader restrictions
* calling JNI hooks
* support linking of JNI methods
But I don't think we need such level of granularity for now.
>> 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?
More information about the core-libs-dev