search

NeuronRobotics / nrjavaserial

A Java Serial Port system. This is a fork of the RXTX project that uses in jar loading of the native code.
Other
345 stars 143 forks source link

NoClassDefFoundError #105

Closed mvglasow closed 4 years ago

mvglasow commented 7 years ago

After building according to the instructions, I get the following error when I try to run the example code:

Exception in thread "main" java.lang.NoClassDefFoundError: com/sun/jna/platform/win32/Win32Exception
    at gnu.io.NRSerialPort.getAvailableSerialPorts(NRSerialPort.java:153)

OS is Linux 64-bit, which explains why Win32 platform classes are not present, but makes it the more puzzling that these classes ever get referenced.

andyrozman commented 7 years ago

You are (probably) missing dependencies. New version of nrjavaserial, requires you to have jna and jna-platform installed (4.2.2 version)

mvglasow commented 7 years ago

I just checked (searched for jna and libjna in Synaptic) and have the following packages installed:

The one I'm missing is libjna-java-doc, but I wouldn’t expect that to do any harm. There’s also libjna-posix-java and libjna-posix-java-doc (both version 1.0.1-2), which are not installed, but the version number suggests they are not part of the JNA core.

PeteSL commented 7 years ago

We ran into this and you need jna-platform.jar in your classpath for RXTXCommDriver to load. As far as I can tell, that is the only place where JNA is used and only to get those Win32 definitions. My question to the author is "Are you going to migrate all of the native code to JNA?" and "If not, why not?" The jna-platform.jar is basically a large set of definitions (2 meg worth) while the base jna.jar has all of the operating code (yes, you can program using jna.jar without jna-platform.jar but not vice versa). Having converted native Linux JNI code to JNA, I can say that while not trivial, it also was not difficult. I have participated with the development of another Java serial interface that is 100% based on JNA. The biggest issue is you need to use the Native library interfaces for performance reasons and that does carry some restrictions but that just means the developers need to understand the variances between native and non-native JNA methods and structures. Personally, I would like to see a migration to JNA which would make your ongoing maintenance significantly easier (no more keeping up with various distros or architectures) as long as you use the Native library interface to be as close as possible to c performance.