Request for review- RFE 8005716

Jeremy Manson jeremymanson at
Fri Mar 8 01:01:53 UTC 2013

On Thu, Mar 7, 2013 at 3:26 PM, Dean Long <dean.long at> wrote:

>  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
>   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)?
A couple of advantages, neither of which is a home run, but which are worth

First, it means you can write libraries that are intended to be both
statically and dynamically compiled without making any code changes.  Maybe
all this means is that JNI_OnLoad_foo should work if you are trying to load (maybe it already does, and I didn't see that feature.)

Second, you avoid potential name clashes with dynamic libraries named the
same thing.  This would be most useful in adding JNI_OnLoads to
general-purpose launchers, where the author of the launcher doesn't have
complete control over the code that gets loaded.  The only one of these I
know of in the wild is in Eclipse, so let's take that as an example.  I
could see Eclipse bundling all of its native code into a launcher, and
making itself into a single executable.  Let's say an Eclipse plugin wanted
to load a native library called, but Eclipse itself had a
JNI_OnLoad_foo in its launcher.  Blech.  Much better for the Eclipse
launcher to have a single JNI_OnLoad that delegates to initialization code
for foo.

(The problem is compounded when you think about the fact that these will
probably be (potentially different versions of) the same library.  This
implies a deep, deep need to worry about visibility / using Bdynamic when
compiling your launcher and your static libraries.)


More information about the core-libs-dev mailing list