Adding a link() Method to Method

[Jeremy Manson]

Hi Alan,

(Sorry about the delay - I was out of town)

In my cases, there may be a versioning issue AND the library might not
be there at all.  I could certainly use a versioning scheme to do this
and catch the ULE if the versioning method isn't present.  However,
the code gets pretty dirty.  I have to increment the version number
every time I add a native method and keep track of it from both native
code and Java.  Also, I have to watch carefully to make sure that I am
adding functionality in a monotonically increasing way.

That's a lot of logistical overhead from something that is a pretty
trivial platform addition.

Of course, the method could be made more complicated.  For example,
you could try to link from a specific native library.

I guess that the method's behavior in the presence of RegisterNatives
should be the same as its behavior with any native method that is
already linked - i.e., return true (presumably).


  /**
   * Attempts to link this method, per Section 5.6 of the Java
   * Virtual Machine Specification.  Returns {@code true} if this is
   * a Java method, if it is already linked, 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, if it is already
   * linked, 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.
   *
   * @since 1.7
   */
  public boolean tryLink();

Jeremy


On Thu, Aug 13, 2009 at 1:49 AM, Alan Bateman<Alan.Bateman at sun.com> wrote:
> Jeremy Manson wrote:
>>
>> Hi folks,
>>
>> 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.
>>    *
>>    * @since 1.7
>>    */
>>   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.
>>
>> Jeremy
>>
>
> In your example, is this a versioning issue with the native library? Just
> wondering if it would make more sense to write a native method that returns
> a version number of some such? One thing to mention is that you could
> encounter libraries that do their own linking with RegisterNatives.
>
> -Alan.
>
>
>
>
>