RFE check native code version

[snazy]

Today we've experienced a "strange" java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.Native failure.

The root cause (on some machines) was just that we use JNA 4.0.0 but someone installed the Debian package libjna-java (which is at 3.2.x). So the native methods could not be looked up.

Please add some version marker to the native code that can be checked by Native to ensure that versions between Java and native code matches.

(I don't know why there's a libjna-java or libjna-jni package since jna.jar has everything in it)

[twall]

JNA does indeed verify that the native version matches that in the Java code (with 4.2 minor changes which do not affect internal APIs are allowed).

It would be useful to understand why that mechanism was not working in this case. Could you provide the full stack trace?

There also exists a -Djna.nosys=true setting to avoid ever picking up a system-installed version of JNA.

On Mar 5, 2015, at 4:46 PM, Robert Stupp notifications@github.com wrote:

Today we've experienced a "strange" java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.Native failure.

The root cause (on some machines) was just that we use JNA 4.0.0 but someone installed the Debian package libjna-java (which is at 3.2.x). So the native methods could not be looked up.

Please add some version marker to the native code that can be checked by Native to ensure that versions between Java and native code matches.

(I don't know why there's a libjna-java or libjna-jni package since jna.jar has everything in it)

—
Reply to this email directly or view it on GitHub.

[snazy]

The reason is pretty simple (for version 4.0.0 ; tag 4.0):
Native.java calls initIDs(); at line 139 - that's before the native lib version check. And it fails with:

    [junit] java.lang.UnsatisfiedLinkError: Can't obtain updateLastError method for class com.sun.jna.Native
    [junit]     at com.sun.jna.Native.initIDs(Native Method)
    [junit]     at com.sun.jna.Native.<clinit>(Native.java:139)

It's still present in master branch at line 143 in Native.java

[twall]

That'd require some sort of resource-based lookup independent of JNI method mapping. Not sure it's worth the effort.

[matthiasblaesing]

This problem was again raised here:

https://groups.google.com/forum/#!topic/jna-users/wPm_fXOvfG4

Running jna against an libjnidispatch.so/.dll prior to:

Exception in thread "main" java.lang.ExceptionInInitializerError
Caused by: java.lang.IllegalArgumentException: Invalid sizeof type 4
        at com.sun.jna.Native.sizeof(Native Method)
        at com.sun.jna.Native.<clinit>(Native.java:161)

The referenced PR does two things:

• it moves the version check in the static initializer block in Native.java before other calls and gives the expected message about non-matching version
• Fix a problem when minor goes beyond one digit. The current code resolves 5.10.0 to be compatible with 5.1