Yes, that looks like it would address my concern. Thank you.
> On Jun 12, 2022, at 11:43 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > 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 >>>> >>> >>
