Can't we perform this check via configuring animal-sniffer-maven-plugin <https://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin> to work with the `java18` signature <https://mvnrepository.com/artifact/org.codehaus.mojo.signature/java18>?
On Sun, Jun 12, 2022 at 8:32 PM Tim Perry <tim.v...@gmail.com> wrote: > 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 > > > > > >
