Pure Java Comm - Initial Contribution

[kgoderis]

Alternative Comm Port Provider based on https://github.com/nyholku/purejavacomm. PureJavaComm aims to be a drop-in replacement for Sun's (now Oracle) abandoned JavaComm and an easier to deploy alternative to RXTX. Note that RXTX native binaries are not provided for Apple's (newer) ARM64 architecture, and therefore this is the only alternative to get serial ports working

Signed-off-by : Karel Goderis [email protected]

[kgoderis]

@splatch Why is there an error on the DCO for this PR?

[splatch]

@splatch Why is there an error on the DCO for this PR?

Looks like bot does not recognize sign off for you commit. Can you do git commit -a -s on branch you used and force push to see if DCO will be happier?
It could be that earlier amend you did, did not preserve all necessary internals beyond commit message.

[kgoderis]

@splatch Why is there an error on the DCO for this PR?

Looks like bot does not recognize sign off for you commit. Can you do git commit -a -s on branch you used and force push to see if DCO will be happier? It could be that earlier amend you did, did not preserve all necessary internals beyond commit message.

mmh..... "nothing to commit, working tree clean"

[splatch]

mmh..... "nothing to commit, working tree clean"

@kgoderis Sorry, it should be git commit --amend -s, my bad.

[kgoderis]

mmh..... "nothing to commit, working tree clean"

@kgoderis Sorry, it should be git commit --amend -s, my bad.

Pfff.... It was because of a space between "off" and ":". LOL

[J-N-K]

Just for my understanding: Is there any limitation compared to the implementation we already have? Otherwise I would say we could also replace the code we use now. It seems to be confusing to have code that does not work on some architectures when we have very similar code that does.

[splatch]

Just for my understanding: Is there any limitation compared to the implementation we already have?

There is, pure java comm provides just a serial port API, nrjavaserial brings rfc2217 which handles serial over tcp. Whole rfc2217 support in nrjavaserial provides API compatible with rxtx: https://github.com/NeuronRobotics/nrjavaserial/blob/af0e83d320920cf0ca3cc8fd25a4f25f482fd0d6/src/main/java/gnu/io/rfc2217/TelnetSerialPort.java#L58.
Not sure if you can pair both without running into troubles.

[kgoderis]

@J-N-K Side question : is there a way to delay the loading of bundles that use serial transport bundles? I noticed that (in this case with pure java comm) some dependant bundles receive an empty serial port list from the SerialPortManager at first; one has to pause and reinitialize things in order to get connected the serial port

[kgoderis]

Just for my understanding: Is there any limitation compared to the implementation we already have? Otherwise I would say we could also replace the code we use now. It seems to be confusing to have code that does not work on some architectures when we have very similar code that does.

@J-N-K http://www.sparetimelabs.com/purejavacomm/purejavacomm.php

[kgoderis]

@openhab/core-maintainers When will this be merged ?

[splatch]

@kgoderis I think you may improve feature a bit by making certain features conditional. Given that purejavacomm can be default serial provider for mac, we could utilize karaf features with conditional elements:
https://github.com/apache/karaf/blob/karaf-4.4.3/features/core/src/test/resources/org/apache/karaf/features/internal/service/f06.xml#L26L33

Looking at it I think its possible to define a operating system condition through https://docs.osgi.org/specification/osgi.core/7.0.0/framework.namespaces.html#framework.namespaces.osgi.native, however I never really tested that . I been using Bundle-NativeCode several times, but never to detect OSX. ;-)

Standardized operating system labels are here: https://docs.osgi.org/reference/osnames.html

[kgoderis]

@splatch Ok, I tried something, and it is compiling, but I have no clue if that is any indication that things are working.

[kgoderis]

@openhab/core-maintainers Can someone verify the above?

[splatch]

It seems that conditional element can be specified under <feature> element to determine conditional dependencies. From this point of view proper place might be a upper level feature such as openhab.tp-serial (if one exists) which can make two conditions 1) for macos/aarch64 - which you made, calling feature openhab.tp-serial-purejavacomm, and 2) for anything else than macos/aarch64 pulling in openhab.tp-serial-rxtx.

[wborn]

See for example:

openhab-core/features/karaf/openhab-core/src/main/feature/feature.xml

Lines 523 to 533 in d3d0fe3

	<conditional>
	<condition>req:osgi.native;filter:="(osgi.native.osname=Linux)"</condition>
	<bundle>mvn:org.openhab.core.bundles/org.openhab.core.config.discovery.usbserial.linuxsysfs/${project.version}</bundle>
	</conditional>
	<bundle>mvn:org.openhab.core.bundles/org.openhab.core.config.discovery.usbserial.ser2net/${project.version}</bundle>
	<conditional>
	<condition>req:osgi.native;filter:="(osgi.native.osname=Windows*)"</condition>
	<bundle>mvn:org.openhab.core.bundles/org.openhab.core.config.discovery.usbserial.windowsregistry/${project.version}</bundle>
	</conditional>

[wborn]

Would be nice to know how well it performs compared to nrjavaserial. As I understand JNA based implementations perform a lot worse compared to implementations using JNI.

https://en.wikipedia.org/wiki/Java_Native_Access#Performance:

Benchmarks show JNA averages ten times slower than JNI.

[wborn]

Some bindings do not use the OH serial transport, so you won't be able to use these with your ARM64 Apples.

See: openhab/openhab-addons#7573

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/oh3-x-oh4-x-alternative-java-serial-provider/128462/34

[wborn]

Suggested change

	<version>4.0.0-SNAPSHOT</version>
	<version>4.3.0-SNAPSHOT</version>