Bug#858876: libjna-jni: causes NoClassDefFoundError

[Emmanuel Bourg]

On 04/11/2017 11:28 PM, Markus Koschany wrote:

> I'm sure the upstream developers of Netbeans are all ears for your
> proposal. They had set the jna.boot.library.name property to
> jnidispatch-410, so I had to change it to jnidispatch to get it working
> with Debian's system jar. [1]

The Netbeans developers basically did the same thing we did in
libjna-java/4.2.2-1: they renamed the library to avoid conflicts. But
Debian packages don't have to set jna.boot.library.name directly, it
seems libnb-platform18-java and netbeans are the only packages doing
this in Debian [1].


> I beg to differ. I think we should expect that people read the
> documentation. I think we are mainly responsible to ensure that all
> packages in Debian are working well together. It is nearly impossible to
> cover all use cases especially if you take customized local user
> packages into account.

This isn't a matter of reading the documentation. Imagine a end user,
not a developer, installing a third party application using JNA.
Initially it works fine. Then he installs an unrelated Debian package
depending on libjna-java, for example gradle. This breaks the third
party application, he might not even see the relevant stacktrace or
understand what it means. Fixing this could involve modifying the launch
parameters inside a shell script or a .desktop file. It isn't reasonable
to expect non technical users to do this, and we should shield our users
from these troubles.


> Yes, I could try to remove the jna.boot.library.name property completely
> from Netbeans or more precisely libnb-platforms-java which is actually
> the package in use here. However it doesn't feel right to me to diverge
> from upstream JNA and other distributions if we don't have to.

This isn't a significant divergence from upstream. The API and the
behavior are unchanged, the modification is invisible. We simply
adjusted the location of the library to avoid conflicts.


> I just checked Fedora and they don't rename the library name. They seem
> to enforce the system library under all circumstances instead. Is this
> something we could use in Debian too? [2]

Fedora doesn't rename the library but relocates it under a 'jna'
directory (the full path is /usr/lib64/jna/libjnidispatch.so). Thus the
library isn't directly on the JVM library path and doesn't conflict with
third party applications. This is roughly equivalent to our solution.

Fedora also dropped support for the jna.boot.library.name property. This
is probably a good idea, any package using libjna-java, even those like
netbeans redefining jna.boot.library.name would work without
modification. This is a functional divergence though.

I can implement this. The netbeans patch can later be simplified since
tweaking jna.boot.library.name will be no longer necessary.

Emmanuel Bourg

[1] https://codesearch.debian.net/search?q=jna.boot.library.name

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20170412/6d87b340/attachment.sig>