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.
