Hi Very long discussion ... so my penny to the latest ones
- I don't believe that jdk 17 gives us more contributors ... The problem is somewhere else - another discussion can be about it - I am afraid that users can have more problems using jdk 17 + toolchains - using jdk 17 as target doesn't give us any boost with fixing bugs, we have many bugs ... I'm for jdk 8 as a target for Maven Core, in some of the important pieces we can use the milti release feature. Of course we should be able to execute with the latest jdk. niedz., 24 lip 2022 o 23:00 Michael Osipov <micha...@apache.org> napisał(a): > Am 2022-07-24 um 22:54 schrieb Andreas Sewe: > > On 20.07.22 15:39, Karl Heinz Marbaise wrote: > >> On 20.07.22 13:04, Romain Manni-Bucau wrote: > >>> > There is no need to use toolchain to run your build with JDK17 and > >>> > create code for Java 8... you can use --release 8 > >>> > (<maven.compiler.release>8</maven.compiler.release>)... > >>> > > >>> > No toolchain needed. > >>> > >>> So you run tests with java 17? This is not what you want if your prod > is > >>> in java 8, you can still get surprises so you need toolchain in your > >>> build (same happen for compilation since bytecode is not 1-1, only > >>> signatures). > >> > >> First what kind of surprises? > >> > >> Second can you show an example of different bytes codes? > > > > Just a regular Maven user here, but I'll give you an example, Karl > > Heinz, where testing against different Java versions was necessary to > > avoid shipping a blocker bug -- even though the bytecode didn't differ > > at all. > > > > Some context: We maintain a couple of plug-ins for different IDEs > > (Eclipse, IntelliJ, NetBeans). Each plugin needs to be compatible with a > > whole range of IDE versions, as not all our users (can) use the latest > > and greatest. And different IDE versions usually mean different Java > > requirements, too. > > > > In the case of the NetBeans plug-in (the same holds for Eclipse and > > IntelliJ, but these are build with Gradle and Maven+Tycho, respectively, > > rather than with plain Maven) this means that the plug-in needs to > > target Java 8 at the lower end, as older versions of NetBeans don't even > > run on the latest version of Java. Hence, we compile against Java 8. > > > > However, we *also* occasionally test against newer versions of Java > > (e.g., in our nightly builds) to catch errors like the following: > > > > The plug-in classloader of NetBeans [1] (and IntelliJ [2], FWIW) does > > not support multi-release JARs, which means that the following LOG4J2 > > statement fails when running on Java 9 or later. > > > > private static final Logger LOGGER = LogManager.getLogger(); > > > > As the plug-in classloader does not support the multi-release > > capabilities of the Log4J2 JAR, we end up in the Java 8 variant of > > getLogger(), which no longer works under newer versions of Java. The > > resulting ExceptionInInitializerError completely breaks our plug-in, but > > this luckily has been found during testing -- running the tests with > > Java 9 or later. > > > > I hope this example was useful to the discussion at hand. > > > > Now, at the moment we run Maven itself with Java 17 (as it speeds up our > > builds) and use toolchains to compile *and* test against Java 8. During > > our nightly build, however, we also pass in a system property which > > selects a different toolchain (ATM, Java 11). > > > > This works, but is not ideal, as our nightly sanity build not only tests > > against Java 11 but also builds against it; both maven-compiler-plugin > > and maven-surefire-plugin use the *same* toolchain. Unfortunately, this > > means that we don't have a guarantee that the test against Java 11 use > > the same bytecode that we ship, since the nightly build compiles with > > the Java 11 but we have to ship the code compiled against Java 8 (i.e., > > our lowest denominator). > > > > In an ideal world, our setup would look like this: > > > > - mvn: Runs with Java 17 > > - maven-compiler-plugin: --release 8 > > - maven-surefire-plugin: a Java 8/11/17 toolchain, selected by system > > property > > > > At the moment, we are not there yet, as we cannot use --release, as > > there cannot be separate toolchains for compilation and test. If that > > were to change with Maven 4, that would be great, of course. > > > > Hope this helps. > > As I said. Such an example and a move to Java 17 would cause just > friction without any lubricant. > > -- Sławomir Jaranowski
