JEP 178

[Bob Vandette]

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 <jeremymanson at 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-dev at 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.vandette at 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:jeremymanson at 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