Request for review- RFE 8005716

[Dean Long]

On 3/7/2013 10:18 AM, Jeremy Manson wrote:
> Hi guys,
>
> I'm really glad to see you are doing this.  We've done something 
> similar to good effect within Google (and we'll probably drop our 
> similar, internal patch and pick up this patch once it is pushed).
>
> Have you thought about support for having a JNI_OnLoad inside of a 
> main executable that *doesn't* have a postfixed _lib?  Our 
> Google-internal patch treats the main executable as a regular JNI 
> library if you execute a special System.loadFromLauncher() function. 
>  We also do the same thing with JVMTI.
>
Would that require additional changes to the JNI spec?  Is there an 
advantage to treating it as an unnamed library rather than
a named library (i.e. JNI_OnLoad_main)?

dl

> Nit: The comments that read like this:
>       * for example, L, and a native library called L is statically linked
>       * with the VM, then the JNI_OnLoad_L function exported by the library
> Should these read "linked with the VM", or "linked with the native 
> application loading the VM"?
>
> Jeremy
>
>
> On Wed, Mar 6, 2013 at 8:21 AM, Bob Vandette <bob.vandette at oracle.com 
> <mailto:bob.vandette at oracle.com>> wrote:
>
>
>     On Mar 5, 2013, at 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"
>     >
>     Good catch Dean.
>
>
>     > Looks like onLoadSymbols[] is unused in
>     Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib().
>     >
>     > 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.
>
>     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
>     <mailto: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/%7Ebpittore/8005716/jdk-webrev.00/>
>     >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/
>     <http://cr.openjdk.java.net/%7Ebpittore/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
>     >
>
>