Using a recent JDK, yet targeting 8 is a great idea Piotr! I brought up this subject a couple of times in the video calls, though, as far as I recall, the excuse was mostly the fact that Java 11 work is aimed for 3.x and the lack of time.
Personally, I would even favor using Java 17 and configuring the target for both `release-2.x` and `master`. In particular, JEP 355 (Text Blocks) released in Java 13 can help us to replace the XML configuration files in tests and hardcode them into the code. I also totally agree with the point of Andrew Marlow that using a modern JDK for 2.x will significantly decrease the maintenance burden. On Sun, Jun 12, 2022 at 1:13 PM Piotr P. Karwasz <[email protected]> wrote: > Hi all, > > Currently the `release-2.x` branch must be run using JDK 8 and uses > Maven's toolchains to compile Java 9+ code. This has many drawbacks: > * It is difficult for new contributors to run the build process, > * It requires a change to `JAVA_HOME` each time we build > `release-2.x`. I suppose most of you use a different default Java > version, > * the latest Maven Surefire plugin fails to run if there are Java 9+ > classes on the classpath: it performs a class scan in the current JVM > and forks only afterwards. > > From my own tests the `--release 8` switch on JDK 9+ works quite well > (i.e. the signatures of the JRE methods are those from JRE 8, not JRE > 9+, the classes use the correct bytecode version and it produces > errors if we use Java 9+ language features). Maybe we could switch to > compiling `release-2.x` using Java 11 with the `--release 8` after > 2.18.0 is out? I would keep the toolchains configuration exclusively > for the Maven Surefire plugin: it would scan the test classes using > the current JVM and fork an authentic JVM 8 to run the tests. What do > you think? > > Piotr >
