On 07/03/2013 20:11, Bob Vandette wrote:
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).
I agree. Just wondering if this causes an incompatibility with the
proposed update to the JNI specification:
"A System.loadLibrary or equivalent API must succeed for this
library to be considered loaded."
Maybe this needs to be loosened?
-Chris.
