Add note about JavaCAN use in Apache PLC4X

[splatch]

No description provided.

[splatch]

Thank you for your awesome library!

[pschichtel]

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

[splatch]

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]

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.