search

pschichtel / JavaCAN

A simple JNI wrapper for the socketcan API provided by the Linux kernel. As it is wrapping a Linux Kernel API, it is intended for use on Linux only.
https://schich.tel
MIT License
49 stars 21 forks source link

Add note about JavaCAN use in Apache PLC4X #36

Closed splatch closed 2 years ago

splatch commented 2 years ago

Thank you for your awesome library!

pschichtel commented 2 years ago

Now that I think about it: The PLC4X transport uses JavaCAN 2.x. Are there plans to change that?

splatch commented 2 years ago

Now that I think about it: The PLC4X transport uses JavaCAN 2.x. Are there plans to change that?

I'm pretty sure ~dependabot~ spambot will report new release of JavaCan. I need to verify API changes, if you made any. We rely only on raw API which you was kind to introduce as result of feature request I made in #22. Looking at 3.x and epoll support you made it would definitely be great to utilize it. However, before this could happen, we would need to adjust PLC4X transport API. Currently it is built on top of netty. It is sub optimal for few cases (ie. when we just need to "wrap" another lib but under PLC4X api contract) and makes Java part very different from other languages where there is no netty. In order to make above I would need to discuss how to re-shape transport stuff and only then implement updated socketcan transport. FYI from 0.9 release PLC4X have its own CANTransport SPI which is built from 2 or 3 types. It is there to provide a way for ie. slcan interfaces on windows based hosts.

pschichtel commented 2 years ago

I think for your particular case nothing really changed, since as of now your are not using event driven io. The most significant change for you is probably the way the native libraries are bundled and loaded, since JavaCAN 3.x does not attempt architecture detection any more. About netty... There is still #20 which I still intent to tackle at some point, but as of now it is pretty awkward to to make netty do non-ip networking.