I've run into an issue where javac 11+ will emit valid java 8 code for functions that weren't added to Java until after java 8. When the code is run on Java 8 runtime errors appear complaining about functions missing from classes that are part of the JRE. Most recently I ran into this when I used java.lang.String@strip() in a library cross-compiled to java 8 bytecode with Java 11 javac.
As long as there is some method to prevent the compiler from emitting code that won't work on Java 8, I don't see a reason to compile with Java 8. However, if this issue can't be prevented, then I think moving to Java 9+ will result in the accidental release of code that won't work on Java 8. FWIW, I haven't compiled with anything but Java 11+ for the last year and a half. It is possible more recent versions of the java compiler warn you if you use functions or maybe there is a maven plugin that would help here. On Sun, Jun 12, 2022 at 6:24 PM Volkan Yazıcı <vol...@yazi.ci> wrote: > 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 <piotr.karw...@gmail.com> > 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 > > >
