JNI errors on ARM32HF during execution of tests using azul java 11

[Lamarqe]

I downloaded the Release 5.2.1 build and execute the SerialTest class.

I do this on a raspberry PI, using the Azul Java 11 JDK (zulu11.43.100-ca-jdk11.0.9.1-linux_aarch32hf).

This results in the following JNI errors:

unsupported JNI version 0x00000002 required by /tmp/libNRJavaSerialv8_HF_root_0/libNRJavaSerialv8_HF.so
/tmp/libNRJavaSerialv8_root_0/libNRJavaSerialv8.so: /tmp/libNRJavaSerialv8_root_0/libNRJavaSerialv8.so: cannot open shared object file: No such file or directory
unsupported JNI version 0x00000002 required by /tmp/libNRJavaSerialv7_HF_root_0/libNRJavaSerialv7_HF.so
/tmp/libNRJavaSerialv7_root_0/libNRJavaSerialv7.so: /tmp/libNRJavaSerialv7_root_0/libNRJavaSerialv7.so: cannot open shared object file: No such file or directory

I recompiled all java classes. The situation remains unchanged. Problem seems to be located within the .so files listed in the error messages. (I did not yet dig deeper how to rebuild these).

Assumption is that these errors are mission critical. Correct?

Note: The error occurs currently for OpenHAB 3.0 and their official builds (openhabian). They include the build linked above.

I submitted a support request, but after digging deeper, here seems the more appropriate place for submitting the issue report.

[MrDOS]

Leaving those errors aside, does serial port access work? If you modify that test to print a list of available serial ports – something like:

@Test
public void test() throws Exception {
    Enumeration identifiers = gnu.io.CommPortIdentifier.getPortIdentifiers();
    while (identifiers.hasMoreElements()) {
        System.out.println(((gnu.io.CommPortIdentifier) identifiers.nextElement()).getName());
    }
}

does that print anything?

The reason I ask is because those errors are likely spurious. The Java portion of the library is aware of several different ARM versions of the native portion of the library, and tries to load each in turn until it finds one which works (prioritizing the ones which are newer – i.e., least likely to work). Looking at the list, the fact the error messages stop after libNRJavaSerialv7.so suggest that it succeeded in loading libNRJavaSerialv6_HF.so – the library I would expect to be loaded on a Raspberry Pi.

[Lamarqe]

First of all, I executed the ReadTest, not the SerialTest, as accidentally linked above.

This prints indeed the available ttys. However, the test never returns. Is this a correct behavior?

Starting point for the issue report is that my OH serial connection based functionality does not work (no data is shown). I concluded based on the error messages, the non-returning test and the non-functional OH serial items, that these errors are mission-critical.

[MrDOS]

If you can get the library to print some available ports, then it's definitely succeeding in loading one of the native libraries (and, I think, the most appropriate library for your platform). The other errors are definitely a red herring.

That “read test” waits to receive data on the last listed serial port at 115,200 baud. Unless you have some hardware attached which is periodically emitting data at that baud rate, it will never complete. So I don't think there's a problem there, either.

At a superficial level, it does look like NRJavaSerial is working. I'm not really familiar with openHAB, but you should see if you can get any more logs out of it to see whether the device bindings think they're connecting to the device at all and are then unable to control it, or if they just get no response. And check your cabling. From the documentation for the ComfoAir bindings, it looks like you need a null modem cable between the ComfoAir and the Pi, not a straight cable.

[Lamarqe]

Thank you for the evlation of the situation. I will move on with focus to my OH setup.

Not the right place here, just to explain: The hardeware (wiring) setup is correct. The setup works in my OH 2.5 installation. It stops as soon as I plug in the the new SD card with the OH 3 installation. (Also the JNI errors appeared in this setting first time, it must be caused by the Java 11 Zulu version which I had to introduce as part of the upgrade.

[MrDOS]

Ah, interesting. We've got enough other people using Java 11 by now that that by itself shouldn't be a problem. And the fact you can get a port listing proves that the library is working for you under that JRE, anyway. Listing the ports actually involves quite a lot of the internal mechanics of the library, so getting that far is a half-decent indicator of other functionality, too.

Do reply back if you can get any further logs out of openHAB which implicate NRJS. And good luck!