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

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

On Thu, Mar 7, 2013 at 3:26 PM, Dean Long <dean.long at oracle.com> 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 JNIOnLoad 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. JNIOnLoadmain)? A couple of advantages, neither of which is a home run, but which are worth considering:

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 libfoo.so (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 libfoo.so, 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.)

Jeremy

More information about the core-libs-dev mailing list