JEP 178

[Bob Vandette]

On Mar 8, 2013, at 5:53 AM, Chris Hegarty wrote:

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

I think the current language works.  It just doesn't discuss the side effect of our current implementation
which doesn't prohibit calling a second static library after an initial System.loadLibrary succeeds.
An initial System.loadLibrary is required and loadLibrary calls for each library are required since it's the only 
way that library specific OnLoad methods will be called.

Bob.

> Maybe this needs to be loosened?
> 
> -Chris.
> 
> 
>