Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#858876: libjna-jni: causes NoClassDefFoundError
24 views
Skip to first unread message
YOSHINO Yoshihito
Mar 28, 2017, 1:50:02 AM3/28/17
to
Package: libjna-jni
Version: 4.2.2-2
Severity: grave
Justification: renders package unusable
Dear Maintainer,
netbeans with native look and feel enabled fails to look up libjnidispatch.so:
INFO [org.netbeans.core.nativeaccess.NativeWindowSystemImpl]
java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.Native
at com.sun.jna.platform.unix.X11.<clinit>(X11.java:380)
at com.sun.jna.platform.WindowUtils$X11WindowUtils.getAlphaVisualIDs(WindowUtils.java:1537)
at com.sun.jna.platform.WindowUtils$X11WindowUtils.isWindowAlphaSupported(WindowUtils.java:1487)
[catch] at com.sun.jna.platform.WindowUtils.isWindowAlphaSupported(WindowUtils.java:1823)
at org.netbeans.core.nativeaccess.NativeWindowSystemImpl.isWindowAlphaSupported(Unknown
Source)
at org.netbeans.core.windows.FloatingWindowTransparencyManager$1.run(Unknown
Source)
at java.lang.Thread.run(Thread.java:745)
This is apparently caused by a change introduced in 4.2.2-1:
> * Renamed the native library to avoid conflicts with other JNA jars used
> on the system (LP: #1065253)
Workaround: Creating a symlink libjnidispatch.so -> libjnidispatch.system.so
fixes this error.
Regards,
--
YOSHINO Yoshihito <yy.y....@gmail.com>
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'),
(500, 'oldstable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
Versions of packages libjna-jni depends on:
ii libc6 2.24-9
ii libffi6 3.2.1-6
libjna-jni recommends no packages.
libjna-jni suggests no packages.
-- no debconf information
Version: 4.2.2-2
Severity: grave
Justification: renders package unusable
Dear Maintainer,
netbeans with native look and feel enabled fails to look up libjnidispatch.so:
INFO [org.netbeans.core.nativeaccess.NativeWindowSystemImpl]
java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.Native
at com.sun.jna.platform.unix.X11.<clinit>(X11.java:380)
at com.sun.jna.platform.WindowUtils$X11WindowUtils.getAlphaVisualIDs(WindowUtils.java:1537)
at com.sun.jna.platform.WindowUtils$X11WindowUtils.isWindowAlphaSupported(WindowUtils.java:1487)
[catch] at com.sun.jna.platform.WindowUtils.isWindowAlphaSupported(WindowUtils.java:1823)
at org.netbeans.core.nativeaccess.NativeWindowSystemImpl.isWindowAlphaSupported(Unknown
Source)
at org.netbeans.core.windows.FloatingWindowTransparencyManager$1.run(Unknown
Source)
at java.lang.Thread.run(Thread.java:745)
This is apparently caused by a change introduced in 4.2.2-1:
> * Renamed the native library to avoid conflicts with other JNA jars used
> on the system (LP: #1065253)
Workaround: Creating a symlink libjnidispatch.so -> libjnidispatch.system.so
fixes this error.
Regards,
--
YOSHINO Yoshihito <yy.y....@gmail.com>
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'),
(500, 'oldstable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
Versions of packages libjna-jni depends on:
ii libc6 2.24-9
ii libffi6 3.2.1-6
libjna-jni recommends no packages.
libjna-jni suggests no packages.
-- no debconf information
Emmanuel Bourg
Mar 28, 2017, 6:30:03 AM3/28/17
to
Le 28/03/2017 à 07:41, YOSHINO Yoshihito a écrit :
> Workaround: Creating a symlink libjnidispatch.so -> libjnidispatch.system.so
> fixes this error.
Hi,
> Workaround: Creating a symlink libjnidispatch.so -> libjnidispatch.system.so
> fixes this error.
Thank you for the report. The symlink was in the same directory? What
JRE did you use?
Emmanuel Bourg
YOSHINO Yoshihito
Mar 28, 2017, 1:20:03 PM3/28/17
to
Hi Emmanuel,
On Tue, Mar 28, 2017 at 4:47 PM, Emmanuel Bourg <ebo...@apache.org> wrote:
> Thank you for the report. The symlink was in the same directory? What
> JRE did you use?
Yes, in the same directory. I use openjdk-8-jre:i386.
On Tue, Mar 28, 2017 at 4:47 PM, Emmanuel Bourg <ebo...@apache.org> wrote:
> Thank you for the report. The symlink was in the same directory? What
> JRE did you use?
Niels Thykier
Apr 9, 2017, 4:20:02 AM4/9/17
to
Any update on this? This bug is one of the last ~60 RC bugs in key
packages for the stretch release. :)
Thanks,
~Niels
Markus Koschany
Apr 11, 2017, 5:40:03 PM4/11/17
to
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
> 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
Markus Koschany
Apr 12, 2017, 5:10:02 AM4/12/17
to
Am 12.04.2017 um 10:31 schrieb Emmanuel Bourg:
> On 04/11/2017 11:28 PM, Markus Koschany wrote:
[...]
> 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
> 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,
>> 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.
>
> 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.
>
> 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]
>
> 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
Emmanuel Bourg
Apr 12, 2017, 11:50:03 AM4/12/17
to
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
> 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]
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.
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.
> 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.
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]
> 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
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.
[1] https://codesearch.debian.net/search?q=jna.boot.library.name
YOSHINO Yoshihito
Apr 17, 2017, 11:50:02 AM4/17/17
to
Package: libjna-jni
Followup-For: Bug #858876
Control: reopen -1
Dear Maintainer,
Sorry for the delay.
I have upgraded this package, while this error still persists.
Exactly the same error message appears in the netbeans log.
Creating the symlink works around this error.
Followup-For: Bug #858876
Control: reopen -1
Dear Maintainer,
Sorry for the delay.
I have upgraded this package, while this error still persists.
Exactly the same error message appears in the netbeans log.
Creating the symlink works around this error.
Markus Koschany
Apr 17, 2017, 6:00:02 PM4/17/17
to
Am 17.04.2017 um 21:08 schrieb Emmanuel Bourg:
> library is now hardcoded and can't be changed by a system property.
> Creating a symlink should have no effect. Could this be caused by an
> embedded jar in netbeans ?
I can confirm that I see the same error message in the messages.log
file. When I change the following line in my patch from:
System.setProperty( "jna.boot.library.name", "jnidispatch" );
to
System.setProperty( "jna.boot.library.name", "jnidispatch.system" );
the INFO warning in the log file is gone.
I'm quite sure that we don't use an embedded jar of JNA somewhere in
Netbeans. I removed everything when I repacked the tarball. I also had
to make sure to patch libs.jna/nbproject/project.properties, so that the
build system doesn't try to install those external non-existent JNA
jars, otherwise the build would have failed.
I suspect that Netbeans' System.setProperty does something differently
and not what we expect or the patch for libjna-jni was incomplete.
Markus
> Le 17/04/2017 à 17:45, YOSHINO Yoshihito a écrit :
>
>> I have upgraded this package, while this error still persists.
>> Exactly the same error message appears in the netbeans log.
>> Creating the symlink works around this error.
>
> Thank you for the feedback. That's odd because the renamed path of the
>
>> I have upgraded this package, while this error still persists.
>> Exactly the same error message appears in the netbeans log.
>> Creating the symlink works around this error.
>
> library is now hardcoded and can't be changed by a system property.
> Creating a symlink should have no effect. Could this be caused by an
> embedded jar in netbeans ?
I can confirm that I see the same error message in the messages.log
file. When I change the following line in my patch from:
System.setProperty( "jna.boot.library.name", "jnidispatch" );
to
System.setProperty( "jna.boot.library.name", "jnidispatch.system" );
the INFO warning in the log file is gone.
I'm quite sure that we don't use an embedded jar of JNA somewhere in
Netbeans. I removed everything when I repacked the tarball. I also had
to make sure to patch libs.jna/nbproject/project.properties, so that the
build system doesn't try to install those external non-existent JNA
jars, otherwise the build would have failed.
I suspect that Netbeans' System.setProperty does something differently
and not what we expect or the patch for libjna-jni was incomplete.
Markus
Emmanuel Bourg
Apr 17, 2017, 7:10:02 PM4/17/17
to
Le 17/04/2017 à 17:45, YOSHINO Yoshihito a écrit :
> I have upgraded this package, while this error still persists.
> Exactly the same error message appears in the netbeans log.
> Creating the symlink works around this error.
> Exactly the same error message appears in the netbeans log.
> Creating the symlink works around this error.
Thank you for the feedback. That's odd because the renamed path of the
library is now hardcoded and can't be changed by a system property.
Creating a symlink should have no effect. Could this be caused by an
embedded jar in netbeans ?
Emmanuel Bourg
library is now hardcoded and can't be changed by a system property.
Creating a symlink should have no effect. Could this be caused by an
embedded jar in netbeans ?
Markus Koschany
Apr 18, 2017, 4:20:02 PM4/18/17
to
Hi,
Am 18.04.2017 um 11:15 schrieb Emmanuel Bourg:
> Le 18/04/2017 à 00:07, Emmanuel Bourg a écrit :
>
>> I'll get another look.
>
> I wrote a simple test case:
>
> import com.sun.jna.platform.unix.X11;
> public class JNATest {
> public static void main(String[] args) throws Exception {
> System.setProperty("jna.boot.library.name", "jnidispatch.foo");
> System.out.println("XAllocSizeHints: " + X11.INSTANCE.XAllocSizeHints());
> }
> }
>
> Compiled and executed with the system JNA jar:
>
> java -cp .:/usr/share/java/jna.jar:/usr/share/java/jna-platform.jar JNATest
>
> And this always works, even if the jna.boot.library.name property
> contains a bogus name.
>
> Renaming libjnidispatch.system.so to libjnidispatch.so triggers
> an UnsatisfiedLinkError.
>
> I checked again the JNA code and there is no other occurrence of
> jna.boot.library.* besides the ones removed in 4.2.2-3.
>
> This issue really looks like an embedded jar. If it isn't in netbeans
> directly, it could be in one of its dependencies.
I must admit I don't know what's going wrong here. I have checked
libnb-platform18-java again but I can't find embedded code copies of
JNA. (I grepped for com.sun.jna). I have also made sure that no external
jar files are downloaded at build time. [1]
I suggest to reassign this bug to libnb-platform18-java for now. I will
update the netbeans-platform-nojnabinaries.patch accordingly which will
hopefully fix this permanently. If you or someone else find an embedded
code copy of JNA in Netbeans or libnb-platform18-java, please let me
know. Obviously this would be very disappointing after all the work that
went into the packaging.
Regards,
Markus
[1]
https://sources.debian.net/src/libnb-platform18-java/8.1%2Bdfsg1-4/debian/patches/netbeans-platform-empty-binaries-list.patch/
Am 18.04.2017 um 11:15 schrieb Emmanuel Bourg:
> Le 18/04/2017 à 00:07, Emmanuel Bourg a écrit :
>
>> I'll get another look.
>
> I wrote a simple test case:
>
> import com.sun.jna.platform.unix.X11;
> public class JNATest {
> public static void main(String[] args) throws Exception {
> System.setProperty("jna.boot.library.name", "jnidispatch.foo");
> System.out.println("XAllocSizeHints: " + X11.INSTANCE.XAllocSizeHints());
> }
> }
>
> Compiled and executed with the system JNA jar:
>
> java -cp .:/usr/share/java/jna.jar:/usr/share/java/jna-platform.jar JNATest
>
> And this always works, even if the jna.boot.library.name property
> contains a bogus name.
>
> Renaming libjnidispatch.system.so to libjnidispatch.so triggers
> an UnsatisfiedLinkError.
>
> I checked again the JNA code and there is no other occurrence of
> jna.boot.library.* besides the ones removed in 4.2.2-3.
>
> This issue really looks like an embedded jar. If it isn't in netbeans
> directly, it could be in one of its dependencies.
I must admit I don't know what's going wrong here. I have checked
libnb-platform18-java again but I can't find embedded code copies of
JNA. (I grepped for com.sun.jna). I have also made sure that no external
jar files are downloaded at build time. [1]
I suggest to reassign this bug to libnb-platform18-java for now. I will
update the netbeans-platform-nojnabinaries.patch accordingly which will
hopefully fix this permanently. If you or someone else find an embedded
code copy of JNA in Netbeans or libnb-platform18-java, please let me
know. Obviously this would be very disappointing after all the work that
went into the packaging.
Regards,
Markus
[1]
https://sources.debian.net/src/libnb-platform18-java/8.1%2Bdfsg1-4/debian/patches/netbeans-platform-empty-binaries-list.patch/
Markus Koschany
Apr 19, 2017, 4:40:03 PM4/19/17
to
Control: reassign -1 libnb-platform18-java
Hi,
As discussed in this bug report and on IRC, I am going to reassign this
bug to libnb-platform18-java. We haven't found any hints of embedded jar
files. It is strange that the recent change of libjna-java had no effect
on Netbeans though. For the sake of moving forward I will change the
jna.boot.library.name to jnidispatch.system.
Markus
Hi,
As discussed in this bug report and on IRC, I am going to reassign this
bug to libnb-platform18-java. We haven't found any hints of embedded jar
files. It is strange that the recent change of libjna-java had no effect
on Netbeans though. For the sake of moving forward I will change the
jna.boot.library.name to jnidispatch.system.
Markus
0 new messages