[3.5.1] file name format is too restrictive

[zsawyer]

This came up when developing under windows.

I have have many native libraries. 2 for each platform [1 for 32 bit and 1 for 64 bit] that I am supporting.
I am shipping the those libraries within the jar. Only one of those libs will work so naturally I only want one file outside the jar. What I did was write the appropriate resource to a file with a generic name "library".
As you can see there is no extension. The file does not adhere to any of the platform specific naming rules. So I passed the absolute file path to

NativeLibrary.getInstance(String) 

but this will end up with

java.lang.UnsatisfiedLinkError: Unable to load library 'C:\mypath\library' : The specified module could not be found.
    at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:194)
    at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:283)
    at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:244)

even though the file is right there.

Changing the file's name to "library.dll" will have JNA load it correctly.

I initially was using a temporary file (File.createTempFile() and had the same issue because I left the extension as ".tmp".

So here is the request:
When an absolute path name is supplied please allow the file to be loaded no matter what the name is.

Thanks

[twall]

On Apr 7, 2013, at 9:51 PM, zsawyer wrote:

This came up when developing under windows.

I have have many native libraries. 2 for each platform [1 for 32 bit and 1 for 64 bit] that I am supporting.
I am shipping the those libraries within the jar. Only one of those libs will work so naturally I only want one file outside the jar. What I did was write the appropriate resource to a file with a generic name "library".
As you can see there is no extension. The file does not adhere to any of the platform specific naming rules. So I passed the absolute file path to

NativeLibrary.getInstance(String)

but this will end up with

java.lang.UnsatisfiedLinkError: Unable to load library 'C:\mypath\library'
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:194)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:283)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:244)

even though the file is right there.

Changing the file's name to "library.dll" will have JNA load it correctly.

I initially was using a temporary file (File.createTempFile() and had the same issue because I left the extension as ".tmp".

So here is the request:
When an absolute path name is supplied please allow the file to be loaded no matter what the name is.

That seems reasonable, I can't think of scenarios where that might cause problems.

Note that 3.5.2 uses an in-jar lookup mechanism so you only need to include the DLL resources in the appropriate place in your classpath (win32-x86-64/mylibrary.dll and win32-x86/mylibrary.dll) for JNA to find them automatically.

[zsawyer]

Thank you for that fast feedback.
If JNA already implements JAR lookup that is great and I will use that instead.
I have been peeking at the code at https://github.com/twall/jna/blob/master/src/com/sun/jna/Native.java#L613 to find out the naming scheme. Is there a documentation for that, that I haven't been able to find?

Also I would like to take this chance and thank you for this great project, it is most helpful and porting my code JNI to JNA will help with changes in the Java code and make the native library easily available for other projects without compiling a custom DLL every time. So Thanks! :)

[zsawyer]

Update: loading the native from the jar works nicely however 3.5.2 doesn't yet support equalizing of arch amd64 and x86-64. But looking at the master's code tells me 3.5.3 will have it :) - can't wait.
Do you think it is likely that further equalizations (i.e. in regards of os.name) are possible, maybe as a fallback?
For example: Like w32ce dlls might work on win32 too?

[twall]

Could you elaborate what you mean about "further equalizations"?

[zsawyer]

Yes, sorry.
What I meant here was that for os.arch different names mean the same thing

  if ("x86_64".equals(arch) || "amd64".equals(arch)) {
      arch = "x86-64";
  }

This effectively means that "win32-x86_64/library.dll" and "win32-amd64//library.dll" are essentially equal (hence my use of the word equalization) and sine 3.6.0 only "win32-x86_64/library.dll" will be loaded.

For me this raised the question if this could also be applied to the os.name attribute so that for example WinCE libraries could be used on regular Win32 systems. Note how instead of win32 the osPrefix will use w32ce for regular windows.

       case Platform.WINDOWS:
            osPrefix = "w32ce-" + arch;
            break;
        case Platform.WINDOWSCE:
            osPrefix = "w32ce-" + arch;
            break;

Since it is generally preferred to use the library specifically compiled for an os it would have to be a fallback. For example when no "win32-..." libraries are present, try the "w32ce-..." ones since they might work as well.

[twall]

w32ce and win32 are distinctly different beasts, even if they may be semi-compatible at the source code level.

I don't see any rationale that warrants such a merge.

[zsawyer]

Thanks for clarifying, that is what I meant.

[twall]

Addressed and tested with 9740335.