mvn test of jenkins plugins failed with libjna-java installed

Bug #1065253 reported by Jean-Baptiste Lallement on 2012-10-10
This bug affects 3 people
Affects Status Importance Assigned to Milestone
libjna-java (Ubuntu)

Bug Description

Quantal up to date

1. Install maven and libjna-java
2. Setup a basic plugin for jenkins (
3. cd to the project directory and run:
  $ mvn test
=> Verify that test failed
4. Uninstall libjna-java
5. Run: mvn test
=> Verify that test passed

With libjna-java mvn test failed with
 at Method)
 at com.sun.jna.NativeLibrary.getInstance(
 at com.sun.jna.Library$Handler.<init>(
 at com.sun.jna.Native.loadLibrary(
 at com.sun.jna.Native.loadLibrary(
 at hudson.util.jna.GNUCLibrary.<clinit>(

This is really annoying because libjna-java is a dependency of jenkins-common, which prevent building plugins for Jenkins on the same machine the server is installed on.

Add the following lines to your project's pom.xml


If you want to use 3.4.0 instead, update the version in pom.xml and run maven with:
$ mvn -DargLine="-Djna.nosys=true" test

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: libjna-java 3.2.7-4
ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
Uname: Linux 3.5.0-17-generic x86_64
ApportVersion: 2.6.1-0ubuntu3
Architecture: amd64
Date: Wed Oct 10 22:59:45 2012
 PATH=(custom, no user)
SourcePackage: libjna-java
UpgradeStatus: Upgraded to quantal on 2012-01-31 (252 days ago)

Jean-Baptiste Lallement (jibel) wrote :
Jean-Baptiste Lallement (jibel) wrote :

Result of mvn test

description: updated
description: updated
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libjna-java (Ubuntu):
status: New → Confirmed
Marius Gedminas (mgedmin) wrote :

This is still a problem in Ubuntu 15.10:

(Although I'm not sure "still" is the right word -- it worked for me before, in 15.04, unless I'm mistaken, and then regressed.)

Jesse Glick (jesse-glick) wrote :

It is unfortunate that JNA defaults to looking in a system location for, since that means that non-packaged Java applications which happen to put a different version in their classpath will pick up the wrong binary. You should need to opt in to using the system library. For purposes of this package I would suggest that the DLL be moved, and packages depending on this one which wish to use it should add that location to $LD_LIBRARY_PATH. (If they neglect to do so, the worst that happens is that JNA unpacks its bundled DLL into a temporary directory at runtime, with a small performance penalty.)

Matthias Klose (doko) wrote :

well, the distro should work by default. Why can't JNA be teached to look up in the classpath?

Emmanuel Bourg (ebourg) wrote :

@doko It does actually, that's the purpose of the jna.nosys property. When set to true JNA will skip the library path and look only into its classpath.

A simple workaround would be to rename the file installed by the libjna-jni package ( for example). Thus the packaged JNA would never conflict with other incompatible JNA jars used on the system, even when the jna.nosys property isn't specified.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libjna-java - 4.2.2-1

libjna-java (4.2.2-1) unstable; urgency=medium

  * Team upload.
  * New upstream release
  * Renamed the native library to avoid conflicts with other JNA jars used
    on the system (LP: #1065253)
  * Improved the reproducibility:
    - Use the year of the source date in the copyright notice of the javadoc
  * Standards-Version updated to 3.9.7 (no changes)
  * Use secure Vcs-* fields
  * Call dh_installchangelogs only once during the build

 -- Emmanuel Bourg <email address hidden> Wed, 23 Mar 2016 13:45:27 +0100

Changed in libjna-java (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers