JEP 178 (original) (raw)

Chris Hegarty chris.hegarty at oracle.com
Fri Mar 8 02:53:45 PST 2013

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.

More information about the jdk8-dev mailing list