> > > > 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
