Currently, Jenkins uses a private copy of JNA:
<dependency>
<groupId>net.java.dev.jna</groupId>
<artifactId>jna</artifactId>
<version>3.3.0-jenkins-3</version>
</dependency>
Due to using this private copy of jna, instead of the upstream version,
Jenkins is not keeping up with the latest fixes that are going into
JNA. This affects other platforms, such as FreeBSD, and Linux on ARM.
For example, these bugs are related:
- is related to
-
JENKINS-20481 Successful builds fails at the end (Could not initialize class hudson.util.jna.GNUCLibrary)
-
- Reopened
-
-
JENKINS-15682 archive artifacts hangs on ia64 slave due to JNA initialization error
-
- Resolved
-
-
JENKINS-10774 Jenkins unable to start if the /tmp/jna catalogue exists and is owned by a different user
-
- Resolved
-
-
JENKINS-21507 libpam4j problem under FreeBSD 10
-
- Resolved
-
-
JENKINS-22425 safeRestart (and restart) via url causes exception (missing libjnidispatch.so) on RaspberryPi (ARM)
-
- Resolved
-
-
JENKINS-10582 slave connection breaks thru EXCEPTION_ACCESS_VIOLATION
-
- Closed
-
-
JENKINS-24526 Update libpam4j to use JNA 4.1.0
-
- Resolved
-
-
JENKINS-24527 Update jna-posix so that it can compile with JNA 4.1.0
-
- Resolved
-
-
JENKINS-13298 Update JNA from version 3.3 to 3.4
-
- Resolved
-
-
JENKINS-24523 Update windows-slave-installer-module to use JNA 4.1.0
-
- Closed
-
-
JENKINS-24524 Update memory-monitor plugin to JNA 4.1.0
-
- Closed
-
-
JENKINS-20481 Successful builds fails at the end (Could not initialize class hudson.util.jna.GNUCLibrary)
-
- Reopened
-
-
JENKINS-15682 archive artifacts hangs on ia64 slave due to JNA initialization error
-
- Resolved
-
-
JENKINS-3603 UnsatisfiedLinkError: jnidispatch with openjdk on ARM when using --daemon option
-
- Resolved
-
-
JENKINS-3759 JNA does not delete temp files
-
- Resolved
-
-
JENKINS-13341 Upgrading to 1.458 with Jenkins on Ubuntu with OpenJDK cause Maven build to fail
-
- Resolved
-
-
JENKINS-15974 FATAL: Failed to link the library: interface hudson.util.jna.Kernel32
-
- Resolved
-
-
JENKINS-17131 Some weird exceptions while archiving with raspberry as slave
-
- Resolved
-
-
JENKINS-21252 UnsatisfiedLinkError on Startup
-
- Resolved
-
-
JENKINS-11872 UnsatisfiedLinkError when installing as Windows service
-
- Resolved
-
-
JENKINS-15792 jnidispatch (/com/sun/jna/linux-ppc64/libjnidispatch.so) not found in resource path
-
- Closed
-
-
JENKINS-18933 JNA version needs upgrade to avoid conflicts in /tmp/jna when building
-
- Closed
-
In newer versions of JNA, the com.sun.jna.Structure class has a new abstract method getFieldOrder().
Third party code which extends com.jna.Structure must define this method, otherwise it will not
compile against JNA 4.1.0.
See:
http://twall.github.io/jna/4.1.0/com/sun/jna/Structure.html#getFieldOrder%28%29
protected abstract java.util.List getFieldOrder()
Return this Structure's field names in their proper order. For example,
protected List getFieldOrder() {
{ ... });return Arrays.asList(new String[]
}
IMPORTANT When deriving from an existing Structure subclass, ensure that you augment the list provided by the superclass, e.g.
protected List getFieldOrder() {
List fields = new ArrayList(super.getFieldOrder());
fields.addAll(Arrays.asList(new String[] { ... }
));
return fields;
}
Field order must be explicitly indicated, since the field order as returned by Class.getFields() is not guaranteed to be predictable.