I always assumed that Java versions are a solved problem in JDK 9+ with '-release' which creates bytecode for the targeted JDK and even ensures that no classes or methods from the JDK are used that are not supported in that version.
There is a desire for "everything must be the same" that I am not sure I understand. I ship a lot of open source and compile everything with "latest LTS" to Java 8 or Java 11. I have never seen a user complain that the resulting artifacts do not work. So why do I need that support? I am genuinely curious. It seems that there is something that I am missing or are too naive about. What is the problem that toolchains (in maven or gradle) solve that I am not aware of? -h On Thu, Jun 1, 2023 at 5:12 AM Christoph Läubrich <m...@laeubi-soft.de> wrote: > > Does Maven miss some features > > Just look at how gradle support toolchains: > > https://docs.gradle.org/current/userguide/toolchains.html > > That's all shows what maven refuses to support and leaving people think > its easier to use the same JVM "from beginning to end": > > 1) First class declarative central configuration (no need to configure > it here and there) > 2) automatic discovery of installed toolchains > 3) Support for automatically download if a matching one if not found > > All this has nothing to do with that is is *possible* to do so in maven > as well, it is just not *convenient* to do so and as its is not *easy* > as well (you can just miss a thing) people are skeptical and try to "be > sure" by using the same JVM from start-to-end... > > > Am 01.06.23 um 14:00 schrieb Tamás Cservenák: > > Howdy, > > > > From recent discussions I see an interesting pattern: it seems that > people > > (even our PMCs) are using Maven in a way that is making sure that "same > > Java version" (I guess vendor + version) is used from "beginning" to > "end". > > > > And "beginning" here means BUILDING (think workstations and CI and so > on), > > while "end" means PRODUCTION (deploying the stuff into production). > > > > Why is that? > > > > We all know that even before this "speedup" of Java releases (so to say, > up > > to Java 8) we did put extra effort into supporting this (running Maven on > > different Java versions and producing another bytecode output). One can: > > - use source/target compiler flags + animal sniffer (if on Java 8 or > older) > > - use release compiler flag (if Java9+ used) > > - use toolchains > > > > Why does any of these above "does not work" for those "aligning Java from > > beginning to end"? > > > > With today's tools like sdkman, jenv, homebrew, jbang, mvnw (and who > knows > > what) it is REALLY HARD to miss the automation of getting JDKs and tools > > (and keeping them up to date!!!) on workstations and CIs (deployment not > > counted here, but hopefully it is automated as well). > > > > Another point is that upcoming Maven 4 has tremendous improvements > > targeting toolchains. > > > > Finally, a bit of digression, but very much related thing: as Niels > > showcased on other thread in > > https://github.com/nielsbasjes/ToolChainsInCiBuilds > > > > The CI "matrix" build's Java version part can be moved into Maven itself. > > Personally, I always hated "matrix" as they explode very easily (size > wise) > > but in MOST cases they really just "warm the oceans" (from HB) and do not > > do anything useful. I do keep _matrix useful_ for OS variations, but to > > rebuild the same commit over and over with Java8, Java11, Java17 only to > > "be sure" it will work, is really an overkill (and very wasteful). The > > added beauty of applying this pattern is that one can perform the whole > > build and testing (using different Javas) even on their own workstations. > > > > Does Maven miss some features (aside from those above) to make it > possible > > for those "aligning" Java versions to move? > > > > Thanks > > T > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
