Bug#858876: libjna-jni: causes NoClassDefFoundError

[Markus Koschany]

Am 11.04.2017 um 22:33 schrieb Emmanuel Bourg:
> On 04/11/2017 08:12 PM, Markus Koschany wrote:
> 
>> This issue could be resolved by changing the libary name to
>> jnidispatch.system in Netbeans. However I don't understand why we had to
>> change the name in the first place.
> 
> Actually Netbeans shouldn't have to specify the library name at all.
> libjna-java has been patched to use the system library by default, so
> any package using it has no need to fiddle with the library loading
> mechanism.

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]


>> In my opinion LP #1065253 is not a bug because Debian's system JNA works
>> as expected and for custom projects you just have to set
>> -Djna.nosys=true. We can't provide multiple versions of JNA due to the
>> usual reasons (code duplication, security impact).
> 
> The point of LP #1065253 is that our JNA library gets in the way of
> third party applications using their own incompatible version of JNA. We
> can't expect users to understand and fix this on their own by tweaking
> the invocation parameters.

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. In this special case there is even a recommended
way,-Djna.nosys=true, to get local packages working, thus there is
actually no reason to patch JNA.

>> Ways to resolve this bug
>>
>> a) Revert the fix for LP #1065253
>> b) Reassign to Netbeans and rename the library name in
>> netbeans-platform-nojnabinaries.patch
> 
> I think this is a netbeans issue, netbeans-platform-nojnabinaries.patch
> should be changed such that the jna.boot.library.name property is no
> longer set. This will use the default library wired in libjna-java.

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.

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]

Markus

[1]
https://anonscm.debian.org/cgit/pkg-java/netbeans.git/tree/debian/patches/netbeans-platform-nojnabinaries.patch
[2]
http://pkgs.fedoraproject.org/cgit/rpms/jna.git/tree/0002-Load-system-library.patch

-------------- 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/20170411/361f1007/attachment.sig>