Bug#858876: libjna-jni: causes NoClassDefFoundError

[Markus Koschany]

Am 12.04.2017 um 10:31 schrieb Emmanuel Bourg:
> On 04/11/2017 11:28 PM, Markus Koschany wrote:
[...]
>> 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.

I understand that your change was made with good intentions in mind but
it shifted the responsibility to ensure that a third party application
works with Debian from the third party upstream maintainer to Debian.
Java apps for end-users are usually bundled with all necessary libraries
and shell scripts and are completely independent from any system
libraries. Here the launch parameters should have been correctly set by
upstream, not the end-user. If they prefer to rely on system libraries
and depend on JNA then they also need to take care of all the
configuration stuff.

>> 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.

Right, but it silently "broke" Netbeans. Netbeans properly used the
available JNA mechanism by setting the jna.boot.library.name. Of course
I can rename every C++ library without changing the API but nevertheless
it breaks some assumptions how upstream intended it to be.

>> 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.

Sounds good. Then let's do that. I need to take care of another bug in
Netbeans (#857955) and could test this change/simplify the patch afterwards.

Markus



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