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.
