Jorge, Allow me one question: why would we need 3.10 for this? Could not we set same thing for existing 3.9.x?
T On Sat, Feb 24, 2024, 23:43 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. >
