Jeremy,
I don't know if you're on the core-libs-dev alias but we just posted the first
draft webrev for this feature on that alias.
See more responses inline below ..
On Mar 5, 2013, at 8:57 PM, Jeremy Manson wrote:
> (I'm going back and forth on whether or not our patch would be useful to you.
> Not handling multiple different libraries is a significant drawback.)
>
> Jeremy
>
> On Tuesday, March 5, 2013, Jeremy Manson <jeremyman...@google.com> wrote:
> > Hi Bob,
> > I was thinking of this:
> >> The current Java API that initiates the dynamic-library loading process
> >> needs to be enhanced to support
> >> built-in static libraries. A Java application that uses a static JNI
> >> library needs a way to notify the VM that
> >> the library code is already included in the application image. In this
> >> situation, a System.loadLibrary request
> >> for a static library should skip the usual platform-specific dynamic
> >> loading process.
> >
> > That's what our variant of System.loadLibrary does, even though we don't
> > differentiate between JNI_OnLoad_foo and JNI_OnLoad_bar. It's more-or-less
> > orthogonal from System.loadLibrary("foo") running JNI_OnLoad_foo.
> > (I wanted to call it "System.loadFromLauncher", but Martin dissuaded me.)
> > Question: If you have JNI_OnLoad_foo and JNI_OnLoad_bar, and you have a
> > symbol Java_com_sun_C_f in your static blob whose semantics depend on your
> > having run System.loadLibrary("bar"), but you have only run
> > System.loadLibrary("foo"), then do you intend to provide a way of
> > preventing the user from accidentally running Java_com_sun_C_f? Is that
> > buyer-beware? In our "load-the-world" scheme, all of the dynamically
> > exported symbols get loaded when we execute our special System.loadLibrary
> > variant, but I'm not sure if that is the best thing to do.
In our proposal, if you call System.loadLibrary("foo") you won't be able to see
or call Java_com_sun_C_f since the ClassLoader
will not have completed the linking and symbol registration process for library
"bar". This is consistent with the way that dynamic
libraries work.
> > Otherwise, if this doesn't manage to make JDK8 for some reason, or if JDK8
> > is pushed out by any significant amount, Google would be happy to be an
> > early adopter (and we may become one anyway, depending on how fast our
> > currently-in-the-works "turn all Java code into a statically build blob"
> > effort goes).
I've attached the current notice of review for this feature that went out to
core-lib-...@openjdk.net.
Bob.
> > Thanks for working on this! It makes me wish I had the opportunity to talk
> > with you two years ago, when we implemented this feature; it could have
> > saved us both some time and effort. Everyone kept telling me that no one
> > at Oracle owned or cared about JNI.
> >
> > Jeremy
> >
> > On Tue, Mar 5, 2013 at 5:01 PM, Bob Vandette <bob.vande...@oracle.com>
> > wrote:
> >
> > Hi Jeremy,
> >
> >
> >
> > Thanks for the offer but my proposal does not involve any special variants
> > of Sytem.loadLibrary.
> >
> >
> >
> > I prefer an implementation that minimizes the impact on existing Java code.
> > We dynamically detect static versus dynamic libraries and
> >
> > all other APIs remain unmodified. Since developers have to modify their
> > native library code to avoid multiply defined
> >
> > JNI_OnLoad symbols, we use that opportunity to detect static libraries by
> > requiring they provide a JNI_Onload_{libname}
> >
> > symbol for each static library.
> >
> >
> >
> > As for JVMTI, we plan on proposing an update to the JVMTI specification
> > that will allow the Agent_OnLoad symbol naming to follow
> >
> > a similar convention to our JNI specification change. This way no new
> > flags will be required.
> >
> >
> >
> > Bob Vandette
> >
> > Java Embedded Architect
> >
> > Oracle
> >
> >
> >
> >
> >
> > From: Jeremy Manson [mailto:jeremyman...@google.com]
> > Sent: Tuesday, March 05, 2013 6:30 PM
> > To: Bob Vandette; Martin Buchholz
> > Subject: JEP 178
> >
> >
> >
> > Hi Bob,
> >
> >
> >
> > My name is Jeremy Manson, and I work on the team responsible for the use of
> > the JDK at Google. I noticed your posting on JEP 178. It looks great.
> >
> >
> >
> > At Google, we use JNI pretty substantially, and we have implemented two
> > features that might be of interest to you:
> >
> >
> >
> > - First, if you invoke a special variant of System.loadLibrary(), you can
> > load symbols defined in
