JEP 178

[Bob Vandette]

On Mar 7, 2013, at 1:23 PM, Chris Hegarty wrote:

> 
>>>> That's what our variant of System.loadLibrary does, even though we don't differentiate between JNI_OnLoad_foo and JNI_OnLoad_bar.  It's more-or-less orthogonal from System.loadLibrary("foo") running JNI_OnLoad_foo.
>>>> (I wanted to call it "System.loadFromLauncher", but Martin dissuaded me.)
>>>> Question: If you have JNI_OnLoad_foo and JNI_OnLoad_bar, and you have a symbol Java_com_sun_C_f in your static blob whose semantics depend on your having run System.loadLibrary("bar"), but you have only run System.loadLibrary("foo"), then do you intend to provide a way of preventing the user from accidentally running Java_com_sun_C_f?  Is that buyer-beware?  In our "load-the-world" scheme, all of the dynamically exported symbols get loaded when we execute our special System.loadLibrary variant, but I'm not sure if that is the best thing to do.
>> 
>> In our proposal, if you call System.loadLibrary("foo") you won't be able to see or call Java_com_sun_C_f since the ClassLoader
>> will not have completed the linking and symbol registration process for library "bar".  This is consistent with the way that dynamic
>> libraries work.
> 
> Bob,
> 
> I may be reading the code wrong, but with the current proposed changes, once System.loadLibrary("foo") is invoked successfully, then any other classes, loaded from the same classloader, that have native methods will have access to the same global symbols, irrelevant if System.loadLibrary("bar") is invoked or not. I'm not sure if this is a problem, or not. But it may lead to users scratching their heads why everything seems to be linked ok, but their JNI_OnLoad_bar not being called.
> 
> I apologize if I am wrong here, it is difficult to actually test.

Yes, I stand corrected.  I naively assumed that we more tightly coupled native libraries with their associated class.
If I were to start over, I would have maintained a per class list of native libraries in order to isolate native functions 
between classes and provide faster native method resolution but that's not the way it works.  We currently search
each native library loaded in a classLoader for EVERY native method we link.

Since the classLoader maintains the list of native libraries that are available for all classes loaded we would end up 
with the behavior you describe.  I'm not sure there is much that can be done about this since we're using a single
handle for all static libraries and all global symbols in the executable are visible.

I still think we need the unique OnLoad entrypoints in order to allow for the detection of static libraries in the process 
and to allow any optional load-time initialization (at System.loadLibrary).

Bob.

> 
> -Chris.