Is nrjavaserial still maintained?

Hi all,

It looks like nrjavaserial fork used by openHAB is not patched against a certain race condition fixed in the upstream project:

Compare that to openHAB implementation:

An user seemed to hit this bug as reported here: Problem with modbus binding with dynamic on/off

I noticed that there are no issues enabled in the openhab/nrjavaserial. Is it still maintained or how is it kept up-to-date with upstream?

@Kai What is the status here?

I don’t know, I guess we are waiting for a 3.16.0 release, which isn’t there yet.
@wborn might know more about the diffs as the PR referred to above is from him.


We stopped using the openhab/nrjavaserial fork and instead now use the same code as NeuronRobotics/nrjavaserial but with some different compiler options with this wborn/nrjavaserial-builder.

The 3.15.0.OH2 version we use already has a couple of additional commits compared to the official nrjavaserial 3.15.0 release. Most notably the arm64 support I added upstream.

I can build a 3.15.0.OH3 version so it also contains the additional PRs I made (the IllegalMonitorStateException fix and properly named threads which is also nice).

Because this is an openhab-core dependency the only way to get it integrated into 2.5.x would either be a new openhab-core 2.5.x release (which is frozen) or adding some overrides to openhab-distro 2.5.x which I think is also not preferable @Kai?

The easiest fix might be to catch the IllegalMonitorStateException. For OH3 we need a new version anyways because nrjavaserial crashes on Windows when using Java 11 (nrjavaserial#131, openhab-core#1384). I might help out with that if it hasn’t been resolved by the time users start testing OH3.

1 Like

Indeed, I would only want to do this for really critical issues, which imho isn’t really the case here. Let us focus on getting an up-to-date Java11-compatible version for 3.0.

Thank you both. Understand the reasoning here and makes sense.

I will still check if this error is causing any side effects (e.g. Unclean port close, preventing re-opening the port), but if not, I agree it is of low priority.

This may be another manifestation in another binding. What should be a recoverable error becoming a port blocked.

There’s a PR for updating nrjavaserial to the official 3.20.0 release in OH3 now which should fix the IllegalMonitorStateException, see:


This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.