Just see some of the commits in master that made that buildable in newer JDKs for ideas on what things need to be updated in 2.x for similar convenience. I’m not so sure about the release process requiring Java 11, but I’d support having this offered for convenience. Really, any build enhancements that makes the 2.x branch maintainable while 3.x becomes the new current will be great since I assume we’d all like to continue maintaining bug fixes and such for 2.x for a few years at least.
— Matt Sicker > On Jun 12, 2022, at 16:47, Tim Perry <tim.v...@gmail.com> wrote: > > Piotr, > > I did a troll back through the history of the maven artifact in question > and I can see one of the admins removed the following line from the pom.xml > because it broke compilation with Java 8: > > <maven.compiler.release>8</maven.compiler.release> > > As you correctly guessed, this meant API compatibility wasn't checked when > building with Java 11 and explains what went wrong. Thanks for reminding me > what the issue was. Sorry to have brought this up, but I suppose we are > better safe than sorry. > > Happy Sunday. > Tim > > >> On Sun, Jun 12, 2022 at 8:26 PM Piotr P. Karwasz <piotr.karw...@gmail.com> >> wrote: >> >> Hi Tim, >> >>> On Sun, 12 Jun 2022 at 20:32, 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. >> >> Are you sure that the library was compiled with `--release 8` and not >> with `-source 8 -target 8`? `String#strip()` does not compile on my >> JDK 11, as well as `ByteBuffer#position(int)` uses the correct return >> type of `Buffer` (JRE 8) instead of `ByteBuffer` (JRE 11). >> >> Piotr >>
