jna.nosys=true should be default

[rednoah]

Hi,

As more and more Java programs use JNA (FileBot, Processing, etc) and install themselves into the PATH (e.g. FileBot) other arbitrary other tools (e.g. Processing) that don't have -Djna.nosys=true set correctly will break.

Most JNA developer just use it, and think the libraries will be unpacked from the jar, and most don't even know that JNA will actually prefer any jnidispatch.dll that's in the PATH. Only FileBot correctly sets jna.nosys=true while almost any other tool using JNA is oblivious of this issue.

Setting -Djna.nosys=true by default would force the correct default behavior that is assumed by most JNA users anyway already.

Thoughts?

PS: this is probably only an issue on Windows

[rednoah]

Bump?

[twall]

The original intent of loading from the system was to allow individual packages to install JNA somewhere and adjust the PATH before launch, reducing the overhead of the automatic unpack. What wasn't accounted for was packages either installing into the system itself (linux distros) or adjusting PATH globally to affect all apps.

[ebourg]

FYI this issue is being addressed in Debian/Ubuntu, libjnidispatch.so has been renamed to avoid conflicts (only in Debian unstable/testing for now).

[unlimitedsola]

Any progress?

[matthiasblaesing]

5.0.0 will be an incompatible release (see CHANGES.md) so now would be a good time for anyone interesting getting the change done. Implementing means not only inverting the decision logik, but also:

• adding a note to the incompatible changes section in CHANGES.md
• update the documentation pointing to the attribute

[matthiasblaesing]

I would appreciate a test of PR #1013, which holds the changes requested here.

[codebutler]

This change seems to have broken JNA out of the box on Android:

java.lang.UnsatisfiedLinkError: Native library (com/sun/jna/android-x86/libjnidispatch.so) not found in resource path (.)

It works correctly with System.setProperty("jna.nosys", "false").

[matthiasblaesing]

@codebutler thank you for the heads-up. Indeed android is special in this regard. I pushed a suggested fix as PR #1040.

I rebuild the aar with that change and attach it here (Please rename the file to jna.aar after downloading, github did not like the aar extensions). Please check if that resolves the problem (without having to resort to changing jna.nosys.

jna.aar.zip

[matthiasblaesing]

I merged the change and made a snapshot version available via the sonatype snapshot repository:

https://oss.sonatype.org/content/repositories/snapshots/

https://oss.sonatype.org/content/repositories/snapshots/net/java/dev/jna/jna/5.2.0-SNAPSHOT/jna-5.2.0-20181127.165701-1.jar
https://oss.sonatype.org/content/repositories/snapshots/net/java/dev/jna/jna/5.2.0-SNAPSHOT/jna-5.2.0-20181127.165701-1.aar