I was going to answer: go for 17. But running the tests on the same language level is really a good argument. So much changed: HttpClient, TLS and cipher suites, DNS resolution (starting with Java 18 it will be pluggable!) etc.
Yes, in theory it should not fail. But this is (sadly) a strong argument against using Java 11+. If it's just for language features, we could also use kotlin, groovy or just a library like javaslang (now vavr.io) to receive some amount of what you would like to see. Groovy is even an Apache project and kotlin has excellent support. Both can mimic sealed classes, have advanced features like traits etc. Not saying I'm a big fan of this myself, but it *might* be an option to think about. Of course we could scare devs away or attract them. Who knows. So, I deeply regret it, but I'd say go for 8 and make an early Maven 5 release with Java 17, then make all the major changes (new pom etc) in Maven 6 instead of Maven 5. On Wed, 20 Jul 2022, 17:08 Jorge Solórzano, <jor...@gmail.com> wrote: > Yes, I agree with Romain (and also many others that have the same > concerns), expecting that the behavior of testing with one JDK that > targets a lower JDK will "just works" is naive. > > There are differences at bytecode level, just compile a class with > JDK17 --release 11 and the same class with JDK11 --release 11 and then > compare with diffoscope to see them, this is one of the reasons that > you need to use the same major JDK version to get Reproducible Builds, > you can't expect a build to be reproducible even if you target to the > same release. > > I don't expect the bytecode differences to be a real issue, yet > without proper testing (using the same runtime that you target) you > can't be sure. > > The HttpClient is one example where you have things like this bug: > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8245245, fixed > only in Java 16+, meaning that while it *works* on Java 17, it will > fail on Java 11. > > We all agree that Toolchains is the way to go for this kind of thing, > but it's important to mention that Toolchains create some friction for > end users and a more involved setup. > > And please don't get me wrong, I'm all for using JDK 17, but user > experience is also important. > > On Wed, Jul 20, 2022 at 4:23 PM Romain Manni-Bucau > <rmannibu...@gmail.com> wrote: > > > > Was more due to tests failling but there is no guarantee there is no > > difference in the bytecode on one side and the most important IMHO is the > > fact the run behavior can be different so at the end of the day you cant > > assume that because your build with java17 -release 8 worked that it will > > run on your prod. > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > Le mer. 20 juil. 2022 à 16:16, Tomo Suzuki <suzt...@google.com.invalid> > a > > écrit : > > > > > Hi Romain, > > > > > > > the while loop was not exactly the same > > > > > > Did you observe the difference in the while loop bytecode cause an > issue in > > > Java 8 users? > > > > > > Regards, > > > Tomo > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
