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

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

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

Emmanuel Bourg

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