I don't think that quite works. There are *four* Java versions in play. In decreasing order of importance, they are:
1. The Java version required by the project being built. That is, the byte code and API level of the project. 2. The Java version used to compile the project. 3. The Java version used to run Maven. 4. The Java version used to compile and build Maven itself. For #1, it is mandatory to support Java 8. There's just too much Java 8 still in use today. E.g. Presto, most of Google Cloud Platform, and and many, many others For #2, reproducible builds mean we have to be able to support what customers are using and that can be anything from Java 8 - 21. It is not sufficient to say Java 21 can compile to Java 8 since that does not produce the same byte code as compiling with Java 8. For #3, any reasonable Java version starts to be acceptable, though going past Java 8 makes life inconvenient for Java developers who routinely work with older JDKs. This version must be compatible with #2. If the JDK used to compile is the same as the JDK used to run Maven, then this shouldn't go past Java 8. Toolchains somewhat solve this problem. However configuring toolchains requires an extra plugin, changes to the pom.xml, and is one more thing for developers to learn and be confused by. Perhaps most problematically toolchains can't be fully configured in the pom.xml of the project but require setting up a completely separate file that needs to be customized per developer machine. It is a much better developer experience if Maven "just works" with whatever JDK and compiler the user has installed and is compiling with. If the JDK is bundled with Maven as some have suggested, then that ceases to be an issue as long as it still uses JAVA_HOME to compile with. For #4, sure, whatever. Any version will work as long as it doesn't impose constraints on #1, #2, or #3. The trick is to avoid the later requirements from forcing upgrades on the earlier requirements. If JDK 17 being used for the Maven codebase, means the user can't compile their project with JDK 8, then I think Maven should stick with the older JDK version too. Again, toolchains help here, but they're inconvenient and extra work. On Sat, Feb 24, 2024 at 10:43 PM Jorge Solórzano <jor...@gmail.com> wrote: > > Hi Maven Developers, > > A lot has been told already from both sides, but please, please, let's > focus on how to improve the current status and define how and what Java > version will be required for Maven, not on trivial discussions about using > var or virtual threads. > > Most developers would love to use the latest and greatest JDK, while > Enterprises want stability for deployments, here, we need to change the > mindset as the OpenJDK release cadence is not going to slow down. > > The Java ecosystem is moving forward and Maven should not get stuck with a > 10 years old JDK version. > > There are many trade-offs from both sides, many complaints, and (sorry to > be harsh) many absurd arguments for being stuck until 2030 with Java 8. > > I don't want to fall into the trap of "since I use it this way, I'm correct > and you don't ", so I will try to be as impartial as possible, I do agree > there is a need to support a Maven compatible with Java 8, I also do agree > that developers would like to use latest JDK features on Maven > core/plugins, so there needs to be a middle ground. > > First, we need to distinguish the difference between the required Java > version used at RUNTIME vs the Java version used at BUILD TIME, anyone can > compile a Java project at build time using Java 21 and target Java 8, so > here the issue is not about using Java 9+ (11, 17, 21) to compile code that > will be used at runtime in Java 8, and if every project makes uses of the > --release option of java compiler, there will be no issues as we are simply > targeting to Java 8, it doesn't matter if you compile with Java 11/17/21 > if, in the end, the produced bytecode is Java 8 compatible. What we are > talking about here is the Java version required at RUNTIME, meaning that if > we raise the Java version to something like Java 17, it will not work with > Java 11 or 8, with that point being clear, let's continue. > > Before my proposal, a little disclaimer: I'm just an occasional > contributor, not a committer or Maven PMC, and while would be great to have > a full-time job to work on Maven, is currently not my case. > > So, the proposal that could make everyone happy is this: > > This proposal suggests the introduction of a *Long-Term Support (LTS)* > version of *Maven 3.10.x *targeting *Java 8* and *Maven 4.0* targeting* > Java 17.* > > In other words, let's require Java 17 in Maven 4.0 at RUNTIME, and the same > day that Maven 4.0 is released, cut and release a version of Maven 3.10.0, > this version (3.10.x) will be marked as LTS, and "supported" for up to 3 or > 5 years (depending on needs) with only security or critical bug fixes, this > means that any new feature won't be backported to the 3.10.x branch, > something like supporting a new JDK version (like Java 25) will be added to > Maven 4. > > Why Java 17 and not Java 21? To be conservative and have a wider audience, > this should not be taken as a set-in-stone version, and if in 2 or 3 years > the Java ecosystem has moved fast enough, then a Maven version that targets > Java 21 or Java 25 should be possible in something like Maven 4.2 (or > whatever version is released to that date), and when the current 3.10.x > version "expires" in 3 or 5 years, mark a new LTS version rinse, and repeat. > > *Advantages of Maven 3.10.x (Targeting Java 8):* > > 1. > > *Stability and Compatibility:* Maven 3.10.x will provide stability and > compatibility for projects still reliant on Java 8. Many enterprises and > legacy projects continue to utilize Java 8 due to its stability and > extensive support. By maintaining a Maven version specifically for Java 8, > these projects can benefit from ongoing support without being forced to > migrate to newer Java versions prematurely. > 2. > > *Extended Support Period:* As an LTS version, Maven 3.10.x will receive > extended support and bug fixes, ensuring reliability for projects in > production environments. This extended support period is crucial for > enterprises with long-term projects that require stability and minimal > disruption. > 3. > > *Security Patches:* Security vulnerabilities are a significant concern > for software projects. With an LTS version like Maven 3.10.x, users can > expect timely security patches to address any potential vulnerabilities, > thus enhancing the overall security posture of their projects. > 4. > > *Maintaining Legacy Codebases:* Many organizations have substantial > investments in legacy codebases built on Java 8. Maven 3.10.x enables these > organizations to continue maintaining and evolving their existing projects > without the need for an immediate migration to newer Java versions, > reducing migration overheads and risks. > > *Advantages of Maven 4.0 (Targeting Java 17):* > > 1. > > *Compatibility with Latest Java Features:* Maven 4.0 targeting Java 17 > will empower developers to leverage the latest features and enhancements > introduced in newer Java versions. This compatibility fosters innovation > and enables developers to build modern, high-performance applications. > 2. > > *Performance Improvements:* Newer Java versions often come with > performance optimizations and improvements. By targeting Java 17, Maven 4.0 > can take advantage of these enhancements, resulting in faster builds and > improved developer productivity. > 3. > > *Support for Modern Development Practices:* Maven 4.0 can incorporate > support for modern development practices, tools, and frameworks that are > aligned with Java 17 and beyond. This includes improved support for > modularization, enhanced APIs, and better integration with contemporary > development ecosystems. > 4. > > *Community Engagement and Contribution:* Introducing Maven 4.0 targeting > Java 17 will attract developers interested in exploring the latest > technologies and contributing to the Maven ecosystem. This increased > community engagement can lead to faster innovation, broader platform > support, and overall ecosystem growth. > > *Conclusion:* In conclusion, the proposal is to introduce LTS versions of > Maven, namely Maven 3.10.x targeting Java 8 and Maven 4.0 targeting Java > 17, presents a balanced approach to cater to the diverse needs of the Java > development community. By providing stability, compatibility, and extended > support for legacy projects with Maven 3.10.x, and enabling compatibility > with the latest Java features and development practices with Maven 4.0, > this versioning strategy ensures that both current and future projects can > thrive within the Maven ecosystem. > > > Please, maintain a constructive argument, since we need to move forward. > Thank you! > > > Best regards. -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
