+1 (non-binding) Actually, it should not make any difference if one builds a plugin using Java 11 or Java 17 (or even Java 21 with a warning) and targets Java 8 using the "--release 8" option (and that dependencies are compatible), so just for using --release option is actually enough (even if the lift was to Java 9) as it does not restrict the use of a newer JDK, and the --release option ensures compatibility with previous versions API.
In any case, the ecosystem should start moving forward even if it is just for lifting the build requirement, yet as many already mentioned there are some caveats, as there is no big advantage for building with Java 11+ but compiling to Java 8 (the features are limited to Java 8 anyway) beyond the safety net and prevent the warning, it could potentially make the testing with Java 8 harder (maybe not with toolchains?), but if the test matrix will be Java 11, 17, 21 and latest-ea and crossing fingers that Java 8 works, it's also fine (I also compile with newer JDKs to older bytecode without major issues), but it should be clear what will be the approach to follow. Now, what I would love to see, is the lift of the runtime requirement for Maven 4.0 to at least Java 11, there has been a lot of discussion around this without any consensus, but I think it is time, then have plugins follow the lifting and compile to Java 11 too, leaving the 3.x branch compatible with Java 8, but the 4.x branch with minimum Java 11, please note that I'm not talking about breaking API compatibility, one plugin build for Java 8 (and from the 3.x branch) should work without issues in Maven 4.x running with Java 11+ as this is one of the goals of Maven 4.x, and this change will be more meaningful than just lifting the build requirement. Based on the 2023 State of the Java Ecosystem[1] it should now be a good bet to start using Java 11, and those who still need Java 8 compatibility, can and will still be using the 3.x branch (even if it's unmaintained). [1] https://newrelic.com/resources/report/2023-state-of-the-java-ecosystem On Mon, Nov 13, 2023 at 8:38 PM Karl Heinz Marbaise <khmarba...@gmx.de> wrote: > Hi, > > currently we have already the build requirements for Maven Core at JDK11+ > > So in consequence I would suggest to lift the minimum requirement for > building plugins to JDK11. > > That means also we can use "--release 8" option > (<maven.compiler.release>8</maven.compiler.release>) instead of > source/target which is not correct based on the warnings we get like: > "[WARNING] bootstrap class path not set in conjunction with -source 8" > which we get in all plugins based on the configuration in maven parent > using this: > > <javaVersion>8</javaVersion> > <maven.compiler.source>1.${javaVersion}</maven.compiler.source> > <maven.compiler.target>1.${javaVersion}</maven.compiler.target> > > which is not correct because we don't use animalsniffer anymore. > > So my suggestion is to lift the JDK build requirements to JDK11... > and use the <maven.compiler.release>8</maven.compiler.release> which > will prevent the warning. Also brings us back the safety net which > animal-sniffer was before. > > > Later on version of maven-parent (v42?) should change the whole > configuration (there are some related parts like maven-pmd-plugin, > maven-enforcer-plugin (enforce-byte-code max)..also toolchain-plugin... > > Furthermore we could get rid of the profile for JDK11+ related to > spotless-maven-plugin ... > > Based on the upgrade to maven-parent v41 we could also enhance the build > pipelines to build on JDK21 > > WDYT? > > Kind regards > Karl Heinz Marbaise > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
