On Sun, 09 Apr 2017 08:13:00 +0000 Niels Thykier <ni...@thykier.net> wrote:
> Any update on this? This bug is one of the last ~60 RC bugs in key
> packages for the stretch release. :)


I had a look at this issue. If we introduce the symlink
libjnidispatch.so -> libjnidispatch.system.so in /usr/lib/$MULTIARCH we
could indeed work around this bug which however exists because

a) Netbeans had to be patched to use Debian's system JNA files instead
of the embedded ones (see the netbeans-platform-nojnabinaries.patch),

and b) because of the fix for LP #1065253 [1].

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. According to the Ubuntu bug the bug
submitter tried to build a local Jenkins plugin but our system JNA
library and the custom local project didn't work well together. He also
came up with the correct solution for his problem: to pass
-DargLine="-Djna.nosys=true" to Maven.

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

Ways to resolve this bug

a) Revert the fix for LP #1065253
b) Reassign to Netbeans and rename the library name in

I tend to implement option a) because I think Debian should not diverge
from upstream in this case and user's should adjust their custom
projects as needed if Debian's system version is not compatible.



[1] https://bugs.launchpad.net/ubuntu/+source/libjna-java/+bug/1065253

Attachment: signature.asc
Description: OpenPGP digital signature

This is the maintainer address of Debian's Java team
Please use
debian-j...@lists.debian.org for discussions and questions.

Reply via email to