Adding a link() Method to Method, Redux

Jeremy Manson jeremymanson at google.com
Thu Feb 6 19:25:42 UTC 2014


Hi folks,

(
I sent this around in 2009, and it kind of got dropped.  We're forward
porting our patches to JDK8 now, so I've come across it again.  It would be
great not to have to keep forward porting it, and using reflection to
invoke it.  Original thread is here:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-August/002319.html

Original method follows...
)

I found myself in need of a method that determines whether a given
native method is linked, and links it if it is present.  My use case
prevents me from calling the method directly and catching an
UnsatisfiedLinkError, because the method has side effects.

This is not the first time I've needed such a method, so I implemented
it and dropped it into java.lang.reflect.Method. I thought I would ask
if it was something that should be added to the platform.  The
prototype looks like this:

   /**
    * Attempts to link this method, per Section 5.6 of the Java
    * Virtual Machine Specification.  Returns {@code true} if this is
    * a Java method, or if it is a native method and the Java Virtual
    * Machine succeeds in loading an appropriate native-language
    * definition of it; returns {@code false} otherwise.
    *
    * @return {@code true} if this is a Java method, or if it is a
    * native method and the Java Virtual Machine succeeds in
    * loading an appropriate native-language definition of it; returns
    * {@code false} otherwise.
    *
    */
   public boolean tryLink();

This is basically useful in any case where you would otherwise catch
UnsatisfiedLinkError, but can't invoke the method.  For example, if
you have a binary that lives on the system, but you aren't sure
whether that shared library provides the implementation you want.

(Another point in the design space would be to have it called link(),
return void, and throw an UnsatisfiedLinkError if it fails.  It is
also worth pointing out that the JVMS calls it "binding", not
"linking", so there is that possibility as well.)

What do you all think?  It seems equally as useful as the ability to
catch UnsatisfiedLinkError from native method invocation.

(2014 update: Alan thought I should add a versioning method to my native
library.  This is less direct, of course.  Thoughts?  Yes / no / maybe?)

Jeremy



More information about the core-libs-dev mailing list