Which is the minimal Java version plc4j should support

[sruehl]

Currently the Java version which supports building of all parts of Apache PLC4X is at least Java 11 (Currently with Java 19 the Apache Kafka integration module is excluded from the build as the plugins it requires are incompatible with this version)

[chrisdutz]

Usually I would have said, that we should stay as low as possible, but given the fact that officially nobody seems to be using PLC4X (At least none admits it publicly) I think we should make our lives easier and give up on that constraint. But I do think we should stay at an LTS version.

[sruehl]

even at 17 you gain so many QOL features which make java a bit more un-verbose :)

[chrisdutz]

But please don't add too much of thise super undebuggable streaming stuff ;-)

[sruehl]

git gud :P

[glcj]

Unless it is strictly necessary, I keep the minimum 11LTS.

[splatch]

From longevity point of view we (connectorio) still aim Java 11 as a baseline because many runtimes still rely on it. Its not that you have to use Java 11 at runtime, just need to compile to java 11 bytecode.

[mrwhy-orig]

I've read on several places that minimal version is 8, so I'd think the documentation/website should be updated, or is it still possible to use plain plc4j without any KAFKA etc. with version 8?

[chrisdutz]

Oh .. ok ... so I thought we were still supporting Java 1.8 (as we never officially change anything) ... so we should either officially declare 1.8 dead or make sure the build produces 1.8 compatible libraries.

[chrisdutz]

Yeah ... I bet so ... but let's face it ... it adds more work and restrictions to the folks building it. Nobody - and I mean ... really nobody - admits to be using PLC4X or what for. This makes it super challenging for the folks working on it to get any form of consulting gigs. So I think there should be some sort of payment ... and if it's not money, then it should at least be: Officially admitting to be using it ;-)

[mrwhy-orig]

Yeah, I do understand this position. In my case, as I wrote in the corresponding issue someone else opened, I have to deal with an old software (Java 1.8) and I don't want to alter the PLC code directly. So I think PLC4X could be a great help for "Retrofitting" where you somekind of bound to use old hard- and software. But therefore it should use the min required version as possible, to be able to run everywhere with very little constraints. But, yeah, if it makes the life of the devs much harder it has to be considered to omit this line usecase. In my particular UC I found a way to use a newer JDK and I will try to use PLC4x, especally because I have to deal with 2 different PLCs atm (S7-300 and Beckhoff). I like the idea behind PLC4x and would love to use it more often, but I'm just a freelancer and unfortunately not always in a position where I can freely choose which tools I gonna use.

[doleron]

I just came here but let me give my 5 cents. As far as I understand, the lower the JDK the bigger the user base. More users mean a better library (more user feedback, more contribs, etc). In addition, many automation stuff runs on old "certified" machines where updating the system JDK may be not available. Thus, even though I love the idea of setting 11 or 17 as a minimum, I may recommend defining grandma 1.8 as a minimum requirement.

[chrisdutz]

In the past we have supported Java 8 and while in general I would say: Yes, more users are better", the past has shown, that more users just means more work for us ;-) While in other regions of the IT world usually more users brings in more contributors, for some reason in the automation space more people just means more work. They open issues, and if you don't fix them with topmost priority, they close the issue, complaining about how shitty support is.

We just decided to invest our available resources better. Because keeping things compatible with Java 8 cost's time ... There are many dependencies, that no longer support Java 8. There usually are CVEs and other vulnerabilities and incompatabilities when sticking with these ... if we stuck with these old versions, we'd have to invest time into finding workarounds, ensuring CVEs for these old libs don't effect the codebase. This is all time we then wouldn't have to work on other things. So we decided to give up on Java 8 and rather move forward.

After all ... we asked several times: "Does anyone need Java 8" and I think we got only one person actually saying that. All others "just immagine that it would be better" without actually saying it.

So as long as not a significant amount of people/companies publicly admit that they are using PLC4X and could use that ... as going back would require work ... work that's totally not fun ... also being wiling to finance the work on it, I see no chance, that we'll be going back. At least I will not do that.

In other projects, I even recommended, that providing a Java 8 backward compatible fork might be something someone would be willing to maintain as a commercial alternative. This way the costs of maintaining the super-old Java support are covered by the people causing this need because they want to save the money of updating Java.

[doleron]

Hi @chrisdutz !

In the past we have supported Java 8 and while in general I would say: Yes, more users are better", the past has shown, that more users just means more work for us ;-) While in other regions of the IT world usually more users brings in more contributors, for some reason in the automation space more people just means more work. They open issues, and if you don't fix them with topmost priority, they close the issue, complaining about how shitty support is.

I can imagine. This kind of user is disgusting!

We just decided to invest our available resources better. Because keeping things compatible with Java 8 cost's time ... There are many dependencies, that no longer support Java 8. There usually are CVEs and other vulnerabilities and incompatabilities when sticking with these ... if we stuck with these old versions, we'd have to invest time into finding workarounds, ensuring CVEs for these old libs don't effect the codebase. This is all time we then wouldn't have to work on other things. So we decided to give up on Java 8 and rather move forward.

After all ... we asked several times: "Does anyone need Java 8" and I think we got only one person actually saying that. All others "just immagine that it would be better" without actually saying it.

So as long as not a significant amount of people/companies publicly admit that they are using PLC4X and could use that ... as going back would require work ... work that's totally not fun ... also being wiling to finance the work on it, I see no chance, that we'll be going back. At least I will not do that.

In other projects, I even recommended, that providing a Java 8 backward compatible fork might be something someone would be willing to maintain as a commercial alternative. This way the costs of maintaining the super-old Java support are covered by the people causing this need because they want to save the money of updating Java.

Perfect!. In general, I recommend forgetting all the old stuff such as C++ 11, java 1.8, and Python 2 (God who uses Python 2 today?). Thus, I totally agree. Java 11 all the way.