Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Mar 18 18:16:36 UTC 2020
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?
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)
Or are there cases where you envision more mix and match? E.g. JNI
libraries w/o auto-unloading?
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