Request for review- RFE 8005716 (original) (raw)

Bob Vandette bob.vandette at oracle.com
Wed Mar 6 16:21:40 UTC 2013

On Mar 5, 2013, at 7:36 PM, Dean Long wrote:

If JNIONLOADSYMBOLS contains something like "JNIOnLoad at 8" on Windows, you can't just turn that into "JNIOnLoad at 8" + . I think it needs to be "JNIOnLoad" + + "@8" Good catch Dean.

Looks like onLoadSymbols[] is unused in JavajavalangClassLoader00024NativeLibraryfindBuiltinLib().

Instead of adding getProcessHandle(), why not add JVMFindBuiltinLibraryEntry() instead? This would make it easier to support table-lookup when runtime symbol information is missing or not supported by the platform.

Bill has already factored out the implementation of getProcessHandle. Although your approach is cleaner, I'm concerned about creating a VM version dependency. For a traditional JRE that doesn't even require static library support, we'd have to make sure to run on a VM that support JNI_VERSION_1_8. It looks like the JDK maintains their own copy of jni.h. If they didn't do that, we would have already gone down that path. The jdk sources already contain several instances of dlopen, dlysym and the Windows equivalents so I don't see a need to add a new VM function.

Bob.

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/viewbug.do?bugid=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 JNIOnLoadlibname 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

More information about the core-libs-dev mailing list