Native.load vs Native.loadLibrary

[Jeffrey A Cummings]

I am having some trouble moving to v 5.0.0. I've been using Native.loadLibrary and, even though it's deprecated it still works. However, I am attempting to switch to Native.load. It took me a while to realize that the first argument to the two functions are not the same. With loadLibrary, I can pass an absolute path. With load, I apparently can only pass the library name and have to do something else to tell it where to search. This strikes me as a step backward in terms of user friendliness. Nevertheless, I found NativeLibrary.addSearchPath but am having trouble making it work. Should the path argument to that function have a terminating path separator character or not?

– Jeff

Jeffrey A. Cummings
Engineering Specialist
Mission Analysis and Operations Department
Systems Analysis and Simulation Subdivision
Systems Engineering Division
Engineering and Technology Group
The Aerospace Corporation
571-304-7548
jeffrey.a...@aero.org

-----Original Message-----
From: jna-...@googlegroups.com [mailto:jna-...@googlegroups.com] On Behalf Of Matthias Bläsing
Sent: Wednesday, October 10, 2018 1:34 PM
To: jna-...@googlegroups.com
Subject: Re: Ignore binding error

Hi Nat,

Am Mittwoch, den 10.10.2018, 07:02 -0700 schrieb Nat:
> I am trying to write JNA app to handle different version of OpenSSL
> and it might have different methods defined depending on the compiler
> options. Is it possible to define a method that might not exist and
> make it to ignore the error when the symbol is not found? Currently,
> I'm getting "java.lang.UnsatistisfiedLinkError" with symbol not found
> error message when I have a method that does not have a corresponding
> symbol in the library.

depends which Mapping you are using:

* Regular Mapping (using interfaces) does the symbol lookup on
first invokation. So if you should by safe as long as you don't call
out into one of the missing functions. Even then you can recover:
You can catch the UnstatisfiedLinkError at lookup time and do
something intelligent as alternative
* Direct Mapping: I currently see no easy way

Maybe that helps

Matthias

--
You received this message because you are subscribed to the Google Groups "Java Native Access" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matthias Bläsing]

Hi Jeffrey,

Am Mittwoch, den 10.10.2018, 22:39 +0000 schrieb Jeffrey A Cummings:
> I am having some trouble moving to v 5.0.0. I've been using
> Native.loadLibrary and, even though it's deprecated it still
> works. However, I am attempting to switch to Native.load. It took
> me a while to realize that the first argument to the two functions
> are not the same. With loadLibrary, I can pass an absolute
> path. With load, I apparently can only pass the library name and
> have to do something else to tell it where to search.

Please have a look at the implementations:

Native#loadLibrary
https://github.com/java-native-access/jna/blob/master/src/com/sun/jna/Native.java#L634

Native#load
https://github.com/java-native-access/jna/blob/master/src/com/sun/jna/Native.java#L584

They are intentionally identical. The problem was/is, that introducing
the bounded generic causes the return type of the method to change.
That causes method lookup errors.

With the introduction of the new methods, the old one remain unchanged
and bindings targeting JNA 4.5.X + 5.Y can be implemented without using
reflection (just using deprecated methods)

> This strikes me as a step backward in terms of user
> friendliness. Nevertheless, I found NativeLibrary.addSearchPath but
> am having trouble making it work. Should the path argument to that
> function have a terminating path separator character or not?

We need to distinct the separator characters here: Do you mean the
separator char, that separates multiple directories in a single path
(File#separatorChar) or do you mean the separator that separated
multiple paths in a single string. (File#pathSeparatorChar)

JNA expects that only a single path is added via
NativeLibrary#addSearchPath. So if you are asking for the case of
multiple paths, that won't work (do multiple addSearchPath calls)

I does not matter if a trailing separator char is present. The path you
input into `addSearchPath` is concatenated with the library name via
the `java.io.File(String,String)` constructor.

I you experience further problems, I suggest:

- create a minimal sample for you problem
- run that with the system property `jna.debug_load` set to true
- show the code and output here

Greetings

Matthias

[Jeffrey A Cummings]

Can you give an example of a bounded generic extension of Library. Not the implementation I think, just the declarations and perhaps the second argument to Native.load?

– Jeff

Jeffrey A. Cummings
Engineering Specialist
Mission Analysis and Operations Department
Systems Analysis and Simulation Subdivision
Systems Engineering Division
Engineering and Technology Group
The Aerospace Corporation
571-304-7548
jeffrey.a...@aero.org

-----Original Message-----
From: jna-...@googlegroups.com [mailto:jna-...@googlegroups.com] On Behalf Of Matthias Bläsing

[Matthias Bläsing]

Hey Jeffrey,

Am Freitag, den 12.10.2018, 21:33 +0000 schrieb Jeffrey A Cummings:
> Can you give an example of a bounded generic extension of
> Library. Not the implementation I think, just the declarations and
> perhaps the second argument to Native.load?

sure - the whole jna-platform project was converted:

public interface User32 extends StdCallLibrary, WinUser, WinNT {

/** The instance. */
User32 INSTANCE = Native.load("user32", User32.class, W32APIOptions.DEFAULT_OPTIONS);

// Bindings from here on
}

with:

public interface StdCallLibrary extends Library, StdCall {
// Definitions
}


HTH

Matthias