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
