[Bug]: java: 无法访问org.apache.plc4x.java.api.PlcConnection
anganing opened this issue · comments
What happened?
hello,
I use java8 and plc4x 0.11.0.
here is the excption:
my project cant't use java11 or higher only can use java8, now I wan to use plc4x 0.11.0 what can I do to fix the bug?
Version
v0.11.0
Programming Languages
- plc4j
- plc4go
- plc4c
- plc4net
Protocols
- AB-Ethernet
- ADS /AMS
- BACnet/IP
- CANopen
- DeltaV
- DF1
- EtherNet/IP
- Firmata
- KNXnet/IP
- Modbus
- OPC-UA
- S7
Hi, usually this error ("class file has wrong version 55.0, should be 52.0") means that you are trying to run a Java program compiled with a higher version of the compiler on a lower version of the JVM. If you can only use java8 anyway, you can try downloading the source code and compiling your own JAR package locally.
Hi, usually this error means that you are trying to run a Java program compiled with a higher version of the compiler on a lower version of the JVM. If you can only use java8 anyway, you can try downloading the source code and compiling your own JAR package locally.
only this way ? can you compiler a java8 jar of plc4x 0.11.0 to maven Central Repository
Hi, usually this error means that you are trying to run a Java program compiled with a higher version of the compiler on a lower version of the JVM. If you can only use java8 anyway, you can try downloading the source code and compiling your own JAR package locally.
only this way ? can you compiler a java8 jar of plc4x 0.11.0 to maven Central Repository
There is currently no specific plan in place. However, there was a previous discussion on the topic of the Java version, you may want to review it for additional insights.
#1059
If that's an issue, we really should do a new release soon and ensure the class version is the one of Java 8
In general we require Java 11 for building plc4x, but it should produce Java 8 compatible libraries. So definitely something we should investigate.
I can confirm that error. Can't use it with Java 8.
Ok ... so I guess we need to put in some extra effort to ensure this doesn't happen again. We once had a plugin to ensure this, but that was removed for some reason.
Ok ... I re-added the animal-sniffer plugin and indeed there are a number of places where we need to fix some things. Sorry for the inconvenience.
I'll make sure that we will do a new release as soon as possible.
Ok ... so there was some previous discussion about dropping 1.8 support in the community, however we never really did any form of official vote on it. I'll make sure that we do this. If Java 1.8 support is important to you, I would reccommend that you sign up to the dev@plc4x.apache.org mailinglist (by sending an empty email to dev-subscribe@plc4x.apache.org) However the problem is, that nobody officially admits to be using PLC4X and what they are using it for. So we navigate with what we know and that's basically that only the people working on PLC4X are actually using it.
Makes sense... well I'm just starting to use it. But I think that wouldn't make a difference. But if you like I can write a "success story" afterwards. I have to alter a 12 year old Java (JDK8) software of mine (non PLC but talking to S7-300 and Beckhoff). I don't want to alter the PLC code so I wanted to use PLC4X to read and write the necessary data. Of Course I can achieve this in different ways, but having plc4x in Java 8 compatible would help if there are no show stopper. Im on the Mailing list since version 0.1.x ;)
And why are you stuck with Java 1.8?
I had to use a library which was 1.8 only. But lucky me, that was an outdated information and this lib has been updated as well. But as I wrote in the other discussion, for the use case of retrofitting it would make sense to set the compatibility bar as low as possible.
Well currently the people voting on the dev-list make it appear we're going to be dropping 1.8 as nobody has voter otherwise so far.
I haven't voted ever (and it seems that I haven't got some E-Mails because of bouncers...), as I'm just a user and not a dev of this lib, yet :) It is your decision. I gave my honest opinion on this. If it isn't a big deal to hold on 1.8 compatibilty I would go that way as imho this is a great lib for Retrofitting projects. Maybe the time is not yet there, but the next IT department is just around the corner which will make security update demands / automatic processing data requests to special mechanicel enginerring companies ... So in my view the perfect lib for that use case.
@mrwhy-orig I am afraid we can't keep 1.8 as compile target as it is not only about us and our code but also dependencies (which Chris mentioned above), which we would need to confirm working with Java 8. The @dependabot is chasing always latest, vulnerability free, versions making it rather hard to automate process.
If you would like to invest time into making current develop working with Java 1.8 - please step up. Otherwise you can use 0.8 release which for sure worked with Java 8.
As this is open source there is also always the option to create a plc4x-jdk8 fork an maintain it.
@splatch @sruehl yes ofcourse there is always this option, to either fork it or use an outdated version (I tried v9 and it was compatible as well). And of course one should look out for the safest possible way. Don't get me wrong I'm, by no means, saying you have to do it. I'm sorry if I might have made that impression.
all good, @mrwhy-orig, don't worry. I think we can consider this ticket now closed as it has been decided to drop java 8 support.