Le mer. 20 juil. 2022 à 15:39, Karl Heinz Marbaise <khmarba...@gmx.de> a écrit :
> Hi, > > 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? > Works vs fails ;). One common example is all the IO stuff which does not have the exact same backports depending the JVM (version + vendor) you use. All the SSL or NIO stuff concretely. Don't have a 8-17 example handy but I know java 11 HttpClient fails on some http server whereas it got fixed in java 17, same for some certificate extension support but API is exactly the same and you can build/compile with both. > > Second can you show an example of different bytes codes? > Don't have it handy anymore (was when java 11 popped up) but typically the while loop was not exactly the same (so an asm detector would be doomed). Another common issue is about generic resolution which is not exactly the same and can lead to issues for your downstream consumers (will pass for you with java 17 - build/compile/tests - but not if a consumer build/compile with java 11). Overall it is not only a signature issue and --release does not solve all the issues, just a subpart. > > Kind regards > Karl Heinz Marbaise > > > > > 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 > > <mailto: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 > > <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 > > <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. > > > > > >
