JEP 178

[Chris Hegarty]

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.