> 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). 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 à 11:58, Jorge Solórzano <jor...@gmail.com> a écrit : > > > > > > Fair enough, they can remain just for backward compatibility, but even > > > if javac does not remove it, it doesn't mean that are useful having > > > --release, and there are probably more for backward compatibility than > > > anything else, again, this is just to drop legacy baggage. > > > > That's not legacy baggage because it's officially supported. So no > legacy. > > > > To be honest I don't understand that. The JDK (javac) supports that so > > why should be remove such support for that in Maven? > > The fact that JDK (javac) supports that, doesn't mean it's not legacy, > there are many > features, APIs, and so on that are still there just for backward > compatibility. > > I still haven't seen any single project that sets the source and the > target with different > versions and the source should always be lower than the target, > meaning that you still > need to compile up to the current JDK version. Just to give you an > example, you can compile a > class using javac --source 14 --target 17 (you need JDK 17), but you can't > use > javac --source 17 --target 14 (you can't use new features that target > older versions), > if you are using --target 17, why would you don't use --source 17 in > the first place? > > The JEP 247 (--release) was designed to link against the > implementation of the given > platform version as it was demonstrated that the --source and --target > were not enough > to avoid accidentally using APIs only available in the current version > of the platform. > > If you compile with --source 8 and --target 8 using JDK 17, you could > potentially end up > using APIs that should not be supposed to be used for that version. > There are many examples out there like > https://issues.apache.org/jira/browse/LUCENE-7292 > that shows this issue. > > Just quoting Brian Goetz: > "The --release flag was added later, and in most cases, should replace > uses of --source and --target." > * https://stackoverflow.com/a/61715683/1990790 > > My point is that if Maven starts requiring JDK 17 (or even JDK 11), > that would mean that > if you want to compile to older platforms you will need to use: > a) Toolchains (which is not the most user-friendly feature) > b) or --release > > The use of --source and --target is just error-prone to get > cross-compile issues and should be avoided. > The only single place that might make sense to keep them is when using > Toolchains *and* that the JDK > is version 8 or lower where --release is not included. > > So, enough bikeshedding from me, I tried to explain it the best > possible way and I don't really > have any issue if the feature is there as I simply ignore it and use > only --release. > > > > > Does that really matter? They build with Java 17 and produce code for > > JDK8 ... that's the point here.. > > > > Some test are being executed on different JDK's if really needed. > > > > What kind of tests do you need to run on different JDK's to find which > > kind of issues? If you need such kind of tests I suppose you are using > > very special things... (If that's a good idea anyway) but of course that > > could happen and yes than you can use toolchains in Maven to handle such > > cases. > > > > Don't get me wrong, I totally get the point that you can build with > JDK 17 and produce > code for JDK8, as I said, that's the easy part. > > Yet when you are running tests, the normal thing to do is to test on > the JDK that you > are targeting even if you are compiling with a recent JDK, it's the > backward scenario > of using JDK8 to compile, but test with JDK 11, JDK 17, etc. > On CI (GitHub Actions, GitLab CI, etc) for instance, you trigger the > build and test with > different JDK versions (a build matrix), to ensure it works with newer > JDKs. > If Maven starts to require JDK 17 as runtime, it means that you are > forced to use > Toolchains, and it's not a bad thing, but it creates more friction for > users. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
