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
