JEP 178

[Chris Hegarty]

>>> 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.

-Chris.