ch.vorburger.exec
ch.vorburger.exec copied to clipboard
vorburger
3.1.5 targets java 8 but calls a java 9 method
The following commit introduces the usage of AtomicReference.compareAndExchange, which is not introduced until Java 9
https://github.com/vorburger/ch.vorburger.exec/commit/2c1c76d9c244c97c9f957d45ff857c92f33ca502#diff-a4593f7471e706655a68330d9002e94cdba9af21bfba0c0788d570f125609855R70
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/atomic/AtomicReference.html#compareAndExchange(V,V)
@thomasbao12 in light of an upcoming #187 I'm reviewing old open issues, and it seems to me that with the various changes made to AtomicExecuteResultHandler since you raised this issue, this is no longer relevant.
Also, the project now targets Java 11 and won't support Java 8 anymore.
OK for you to close this issue?
We are still on Java 8 (unfortunately) for now, so we won't be able to upgrade until we make progress on that. But we have already forked mariadb4j to support jdk8, I think we can likely fork this too if needed.
As a sidenote, given that you're not on JDK11, is there still a benefit to using commons-exec? I wonder what a patch to use ProcessHandle would look like
Hi @mosesn , I know your pain but its now 2024 it should be the year you try and jump onto LTS 21. The world is moving too fast and the products you are using should be support 8 - 21 at this time and very soon if not already java 8 will be removed like it has been for many of the tools I'm using.
You should be able to cross compile your code to have a jdk8 release if need for the libraries you have inhouse. You can see here what we changed in our pom.xml to move from jdk8 only to jdk21. https://github.com/qld-gov-au/seleniumHelper/compare/v4.9.1.001...v4.21.0.003
@mosesn I have seen hsqldb support multi flavours, they are still ant based, unsure if you wish to go that path your own internal works. http://sourceforge.net/p/hsqldb/svn/HEAD/tree/base/trunk/build/build.xml line 751. Here is spring framework supporting jdk8 and higher with different jdk's. https://github.com/spring-projects/spring-framework/blob/v5.3.36/.github/workflows/ci.yml and then in v6.x they started at jdk17 https://github.com/spring-projects/spring-framework/blob/v6.1.8/.github/workflows/build-and-deploy-snapshot.yml#L18
Also @mosesn ,
JDK8 is not the same JDK8 from many years ago. There is subtle features that have been quietly backported into higher patch versions of the JDK8 ecosystem.
An old previous company jdk at the 202 or earlier patch level is a very different beast to a openJDK version 1.8.0_412+ version. I've also been caught out on the new features that now exist in 2024 that did not exist in 2019.
Also with the major movements in licencing by our friendly company, it may be time to scare management and get off 8 asap.
@duttonw the details will bore you, but management is supportive of getting off Java 8 and we have technical impediments (we're in a monorepo and on a version of spark that's incompatible with jdk17). We would love to be off Java 8 but it's a long way!
It seems you may need to start the move to get to current spark re-review apache spark doc's as that product as they do support jdk21, their homepage is not kept up to date it seems.
https://issues.apache.org/jira/browse/SPARK-43831 https://github.com/apache/spark/actions/runs/9459352167 (master) https://github.com/apache/spark/blob/v3.5.1/.github/workflows/build_java21.yml (v3.5.1)
v3.4.0 has jdk 17.
If you are way older than that. I do feel your pain.
@thomasbao12 with the merge of #126, that Java 9+ AtomicReference is actually gone now...
... that's on the current main, which will be a 3.3.0, when it's released in the future (there is no release with that, yet).
I'm personally actually not really opposed to "restoring" Java 8 compability for this library, if this helps users.
Would anyone like to put in the work and raise a PR which does the needful? @mosesn @thomasbao12 @duttonw