Request for review- RFE 8005716

[BILL PITTORE]

On 3/5/2013 7:36 PM, Dean Long wrote:
> If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on 
> Windows, you can't just
> turn that into "_JNI_OnLoad at 8_" + <libname>.  I think it needs to be
> "_JNI_OnLoad_"  + <libname> + "@8"
I'll look into that. When I built for windows and ran our test, the 
JNI_OnLoad_TestStaticLib was exported without the decoration just based 
on the JNIEXPORT JNICALL specifiers on the function. I didn't do 
anything special to export it. But I recall this problem from another 
project.
1    0 00001014 JNI_OnLoad_TestStaticLib = 
@ILT+15(?JNI_OnLoad_TestStaticLib@@YGHPAUJavaVM_@@PAX at Z)
>
> Looks like onLoadSymbols[] is unused in 
> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib().
I'll remove that. I redid the call to findBuiltinJniFunction but forgot 
to remove that.

>
> Instead of adding getProcessHandle(), why not add 
> JVM_FindBuiltinLibraryEntry() instead?
> This would make it easier to support table-lookup when runtime symbol 
> information is missing or not
> supported by the platform.
Not sure I'm following you on this. Make JVM_FindBuiltinLibraryEntry() 
an exported function in the VM? How does it find JNI_OnLoad_L? Via a 
table setup by the developer/build system when the library is linked in?

bill

>
> dl
>
> On 3/5/2013 3:05 PM, bill.pittore at oracle.com wrote:
>> This request is tied to bugid 8005716 that deals with adding support 
>> for statically linked JNI libraries.
>>
>> The JEP is here: http://openjdk.java.net/jeps/178
>>
>> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716
>>
>> The webrevs are here:
>>
>> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/
>> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/
>>
>> The main piece of functionality is to check for the presence of 
>> JNI_OnLoad_libname to determine if the library specified by 'libname' 
>> has been statically linked into the VM. If the symbol is found, it is 
>> assumed that the library is linked in and will not be dynamically 
>> loaded.
>>
>> thanks,
>> bill
>