As a case in point, I am slowly moving the plugins that I maintain ( https://basepom.github.io/) to Java 17 and 21, even though these are Maven 3.x.x plugins. I will require projects that adopt those to use 17 or 21 to run the build. Which is fine, because I can still deliver Java 8 or Java 11 compatible software even if building on a newer JDK.
Java 17 is "end of public support" in ~ 15 months. By that time, two newer LTS versions (21 and 25) will be available. And 21 gives a path to use things like FFI which do not exist in 17. This decision seems to be too much on the conservative side. Anyone who does not want to upgrade Java will not upgrade to Maven 4 anyway. -h On Sat, May 10, 2025 at 1:17 PM Tamás Cservenák <ta...@cservenak.net> wrote: > Howdy, > > very same sentiment over here as well. I am very disappointed with the > outcome. > > So, I am curious about folks voting -1... > > Is one of them planning to go rogue and surprise us all by doing a > Maven 4 GA release soon? :D > > Thanks > > T > > > > On Sat, May 10, 2025 at 8:58 PM Mirko Friedenhagen > <mfriedenha...@gmx.de.invalid> wrote: > > > > I completely second Manfred here: > > > > - People who are willing to use Maven 4 soonish should be considered > fast movers. So I guess these are already using Java 21 anyways. > > - Going from Java 17 to 21 does not require major adaptions if any in > code in my experience. > > - New LTS Java 25 comes out this year, so even 21 will not be the shiny > new version. > > > > Mit freundlichen Grüßen > > Mirko Friedenhagen > > — > > Sent from my mobile > > > > > Am 04.05.2025 um 20:45 schrieb Manfred Moser <manf...@simpligility.ca > >: > > > > > > Hi all, > > > > > > I find this extremely disappointing and also confusing. A majority of > binding and non-binding votes opted FOR adopting Java 21. How can this be > justified with our procedures? > > > > > > Here are my arguments for adopting Java 21 that seems to have been > asked for although they are imho obvious. > > > > > > * Maven 4 will be a brand new release with many changes. An upgrade of > the required Java version is already included. Changing that from 17 to 21 > does not have that much impact on users. > > > > > > * Java 21 is the latest current Java LTS release, and Java 25 as the > next LTS will be out in September .. that might even be before Maven 4 > ships. > > > > > > * Java 21 has numerous improvements on top of 17 that making > programming with it better (and newer versions are even better). > > > > > > * Programmers will be less inclined to help a project that uses an old > Java version (17 is 3 years old.. ) and therefore prohibits them for using > modern programming styles and usage. > > > > > > * Performance of Java 21 is better and it is more suitable to run on > containers (which is common for CI and CD systems these days. > > > > > > * As a project overall we should strive to provide modern powerful > tooling and that also includes using modern runtime versions and taking > advantage of new features. > > > > > > * A later upgrade to Java 21 in in 4.1 for example seem to make sense > sense for a minor version update. > > > > > > * Holding us back to Java 17 means we can not start refactoring the > code to take advantage of features from 18, 19, 20, and 21. > > > > > > Beyond that I want to discount the "valid" arguments: > > > > > > * Procedurally there is nothing wrong with changing in the RC phase. > There is no rule about how long that phase is and how many RCs there should > be. > > > > > > * The new constraints on users only apply if they upgrade to Maven 4 > .. which is completely optional. > > > > > > * Even people who voted with -1 said that they would like to upgrade > and that it would be nice, so what is really holding this back. > > > > > > I therefore ask for the conclusion to be reconsidered and following > our majority rules to adopt the raise to Java 21 as requirements for Maven > 4 before we release a final version. > > > > > > Manfred > > > > > >> On 2025-05-03 11:57 p.m., Matthias Bünger wrote: > > >> Morning everyone, > > >> first I would like to thank everybody who participated in the vote > [*1] about lifting the required Java version to 21 for Maven 4.0.0. > > >> > > >> The vote has ended with the following votes: > > >> > > >> -------------- > > >> Binding votes: > > >> > > >> +1: Sylwester Lachiewicz, Karl Heinz Marbaise, Tamás Cservenák, > Benjamin Marwell, Arnaud Héritier, Tibor Digaňa > > >> > > >> -1: Michael Osipov, Maarten Mulders, Olivier Lamy, Slawomir > Jaranowski, Hervé Boutemy > > >> > > >> > > >> Non-binding votes: > > >> > > >> +1: Gary Gregory, Mateusz Gajewski, Mantas Gridinas, Rodrigo Bourbon, > Willker Gomes, Hans Aikema, Martin Desruisseaux, Torsten Heit, Sandra > Parsick, Dawid Law, Philipp Picej, John Neffenger, Jeremy Landis, Daniel B. > Widdis, Michael Bien, Gregorz Grzybek, Kévin Buntrock, Jorge Solorzano, > Mark Derricutt, Matthias Bünger, Basil Crow, Romain Manni-Bucau, Thomas > Sundberg, Anders Hammar, Piotr P. Karwasz, Niels Basjes, Enrico Olivelli > > >> > > >> -1: Elliotte Rusty Harold > > >> > > >> -------------- > > >> > > >> 5 out of 11 binding votes are -1 with valid arguments, including that > there is no actual need to upgrade, that (it's too late, as ) we are > already in RC phase, and that it might put on new constraints to users. The > vote was (in line to the vote about lifting Maven 4 to Java 17) a > "procedural majority vote", meaing a simple majority of binding votes would > be enough to considered it to be passed. But due the high number of > negative votes and brought up arguments, I don't think we should ignore > them but take them into consideration for the benefit of the Maven > community. Therefore I call the vote to be non successful. We can > reevaluate in the future, including having a closer look at / discussion > about the benefits and constraints of raising the Java version. > > >> > > >> > > >> Wish you a happy sunday! > > >> Matthias > > >> > > >> [*1]: > https://lists.apache.org/thread/mjbx64vlbd346ov3l4wj6fy9vh8608vr > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > >> For additional commands, e-mail: dev-h...@maven.apache.org > > >> > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
