BBB Rev C: Debian: PureJavaComm/JNA test fails

I’m trying to use PureJavaComm on my BBB/Rev C (Debian). I get the following results:

root@beaglebone:/opt/dnc/lib# java -cp PureJavaComm.jar:jna-4.0.0.jar purejavacomm.testsuite.TestSuite
PureJavaComm Test Suite
Using port: cu.usbserial-FTOXM3NX
TestMissingPort Exception in thread “main” java.lang.UnsatisfiedLinkError: /tmp/jna-3506402/jna7659204852244455440.tmp: /tmp/jna-3506402/jna7659204852244455440.tmp: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(
at java.lang.ClassLoader.loadLibrary0(
at java.lang.ClassLoader.loadLibrary(
at java.lang.Runtime.load0(
at java.lang.System.load(
at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(
at com.sun.jna.Native.loadNativeDispatchLibrary(
at com.sun.jna.Native.(
at com.sun.jna.NativeLong.(
at jtermios.linux.JTermiosImpl.(
at jtermios.JTermios.(
at purejavacomm.CommPortIdentifier.getPortIdentifier(
at purejavacomm.testsuite.TestFreeFormPortIdentifiers.testMissingPortInCommPortIdentifier(
at purejavacomm.testsuite.TestSuite.main(

The test works on Windows 7. Any suggestions???


Thanks suggesting Google!! I would never have thought of that!!

Seriously though, I’ve been trying to solve this problem for 7 days now. And I’ve Googled everything I can think of. Your “first hit” doesn’t tell me anything I don’t already know.

I believe this to be some sort of permissions or path problem with my Debian setup. That’s the reason the request for support is under Newbie/Debian. I’ve tried all of the path stuff that Java expects. I may have something wrong on the Java side, but I don’t think that is the case. I was hoping that someone that has been successful with PureJavaComm on BBB would be able to point me in the right direction. So, I’ll wait and see what happens.

You might want to try libbulldog (

Here’s an example:

It can do “advanced” Serial communication as well, but has not been tested on Debian. By “advanced” I mean settings things like setting parity, databits and stop bits. Maybe that is sufficient for you.

But you’ll probably have to tweak the Java side a little, I don’t know if the Debian devices match the angstrom serial devices.

What I can say about the error, though, is, that you will also get it, when the binary format does not match your system.


You might also want to consider using the LinuxSerialPort class of libbulldog directly! Then you shouldn’t have troubles due to Debian.

Does the file exist at that location? You seem to be trying to run your app as root, so its not a permission problem. Also from memory /tmp/ will not persist between reboots. SO perhaps not the best place to put any file that is needed long term.

Thanks for the help William.

Yes, I’m running as root. The Java software (JNA) is extracting the .so file form the Java jar file(similar to a zip file) and placing it in the /tmp directory. Once the file is extracted, it then passes the absolute path to the Java System.load() method … which loads the .so file. It doesn’t matter that the /tmp won’t persist because JNA deletes the .so file as soon as it is loaded. I will try to change the use of the /tmp directory to something else.

It’s good to know that permissions should not be a problem.


Thanks for the suggestion. I’ll look into it.

The error message is probably misleading, I had it several times until I realized that the native binary was not properly compiled for the am335x. The file was indeed there at the location but it just would not load. The problem can probably be solved by compiling the native binary for am335x.

The PureJavaComm documentation sais that - if you want to support other platforms, you have to create a custom JTermios Wrapper for the ARM platform. There’s a section for it (‘Adding more platforms’) on the website. Makre sure you build your libraries for arm with soft floatingpoints.

Many APIs package the native binary inside their java jar and upon program execution unzip it to a temp folder. That is a quite common practice, but I found it to be error prone.

Uhm, to correct myself: It’s probably not even necessary to implement the Java part of JTermios, the wrapper. Just make sure you build the native binary for arm with softfp. I suspect that the one you use has been built for i386.

You can use the linaro toolchain to crosscompile it on windows or compile it directly on the bone.

So what is the point of using Java if binaries like this do not work cross platform ?

Maybe you are very proficient in java and many of its libraries. It has got some really nice features. I never cared about the platform indepence that much. Many, many people worldwise use it and are proficient in it and there are lots of libraries available.

Datenheld, My point was why use a language, when if key feature is taken away . . . also it is not very proficient especially considering you’ve spent how many days here trying to troubleshoot an issue that should never have existed ? People who write libraries that brake key features in languages such as this should be shot.

I could go on all day, but THIS is one reason why Java is a horrible language. People are taught to write sloppy / crappy code like this, and told that it’s fine / good. It’s not fine, when you break a key feature in a language.

Anyway, do not take the above personally. but please do try to expand your horizons some.

You’re being too harsh on the topic. Most people didn’t really use java because of platform independence. In the beginnings of Java, applets were the killer feature. You could easily deliver fat client software with the webbrowser. It wasn’t that much about platform independence. Java is a lot more than platform independence.

Platform independence hast its limits by design. When you want to be independent of something, you need abstractions. Abstractions are leaky, though. When you then want to do something, which is not common to all(!) platforms you support, then you cannot generalize it. Or you make it possible but then you depend upon the details of the platform. Those details are for example the native library that PureJavaComm delivers.

also it is not very proficient especially considering you’ve spent how many days here trying to troubleshoot an issue that should never have existed

Well, I’m arguing against that by saying, that you will potentially have the same problem in every language that uses a runtime and does not compile to native code.

I could go on all day, but THIS is one reason why Java is a horrible language. People are taught to write sloppy / crappy code like this, and told that it’s fine / good. It’s not fine, when you break a key feature in a language.

Why is it a key feature to communicate with low level peripherals? Once you go beneath a leaky abstraction (and every abstraction is leaky), you will have tight dependencies. You cannot say the code is crappy. The things you want to do are simply not possible without writing native code. When you choose to write such code in Java, it is by design and not necessarily crappy. It’s all about the API for Java.

I could take a native i386 lib with a python API, pull it over to arm and then complain that it does not work as well. This is basically what you are doing currently, no offense meant.

Anyway, do not take the above personally. but please do try to expand your horizons some.

Well, personally, I am proficient in quite a lot languages. So I feel like I can judge languages quite well. Java has its flaws, but as a language, it is quite decent. You can write bad code in any language and Java code is not necessarily bad code, just because it breaks platform independence (reasoning: see above). I like Java because it’s object oriented and does not need extensive resource managing like C++. I can handle complexity with it much better, than in C. And since I use it at work, I am getting results very fast.

Well, it should be very obvious by now that I have a strong dislike for Java, and I was being too literal. This sort of situation really upsets me, and I’ve seen it happen on more than Java too. Most recently was with Nodejs, and an older package manager pulling in x86 / i386 specific code for my own BBB. This does not happen at all with NPM, at least not that I’ve seen yet.

Also since I do not use Java at all, I was under the impression that the JVM was supposed to handle all the hardware abstraction, but from what you’re saying here I was probably wrong. At least in the context of hardware architecture. This is how I feel it should be done however.

I still wont touch Java, and there is at least one more language I try to avoid at all costs too. But if it works for you, I say more power to you. It was not my intention to start a “holy crusade” in the name of development… Despite the fact that seems where I’ve taken us.

By the way, the only reason why I brought up cross platform as a key feature. Is that many languages out there have a strong framework to back them up. .NET( pick your language ), Nodejs ( which by its self technically isn’t a language ), Python, etc.

William, I, too, do think as well that Java lacks support for some features, in the JVM, too.

I also don’t think Java is the best language these days (speaking of languages and not of the runtime). It is well behind the .NET platform when it comes to pure languages, apart from Scala, but nobody uses that. C# for example is the “better Java” in my opinion.

I think the main reason why people pick up Java is because they know it already. It is so widely used in the industry, especially in enterprise software, that it is hard to compete with it. Economical factors play a role. Because there are so many Java programs, many Java Programmers are needed. And because there are many Java programmers, you write your programs in Java. After all, when you write software professionally, you got to make sure that you actually will always find people to build and maintain it. With Java this can be done quite easily. And while I’d prefer to code in Scala at work - you simply won’t find people who want to learn it or who already are proficient in it on the market. For managers, this is a major downside.

Problem solved!! If you follow the instructions on this page:

You will install the soft floating point version of Java. If you install the hard floating point version of Java, the problems of loading the native libraries (e.g. libc6 etc.) go away.

Problem solved!! If you follow the instructions on this page:

I’ve updated the page to suggest downloading “Hard Float” for Debian. It would be great if someone could report success/failure with version 8, but I suspect Oracle is continuing to test on BeagleBone Black.

This is the one i've been testing: