Repository navigation
jna.nosys=true should be default #384
Description
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
Reacted by Michael Ahlers, Viktor Alenkov, cryptokat, eugene yokota, Sola, Staffan Forsell and Charles Blaxland
Reacted by Leo
Activity
rednoah commentedon Dec 7, 2015
Bump?
twall commentedon Dec 9, 2015
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 commentedon Mar 29, 2016
FYI this issue is being addressed in Debian/Ubuntu, libjnidispatch.so has been renamed to avoid conflicts (only in Debian unstable/testing for now).
Prevent JNA library conflicts on AppVeyor
unlimitedsola commentedon Feb 27, 2018
Any progress?
matthiasblaesing commentedon Mar 6, 2018
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:
[java-native-access#384] Make jna.nosys=true default
matthiasblaesing commentedon Sep 15, 2018
I would appreciate a test of PR #1013, which holds the changes requested here.
[java-native-access#384] Make jna.nosys=true default
codebutler commentedon Nov 25, 2018
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 commentedon Nov 25, 2018
@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
aarwith that change and attach it here (Please rename the file tojna.aarafter downloading, github did not like the aar extensions). Please check if that resolves the problem (without having to resort to changingjna.nosys.jna.aar.zip
matthiasblaesing commentedon Nov 27, 2018
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
Upgrade to latest maven release (java-native-access#384)