> 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. You can compile Java 8 bytecode with a Java 8 JDK from a Maven running Java 17+ using toolchains or with the -release flag from any version 9+. > 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. That is the point. If you built the project with JDK 21 using the -release=8, you can get the same (reproducible) output with a similar OS and JDK 21. > 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. Where did you get that from? Even before I switched my projects to 11/17, I required 11+ for building (b/c of -release=8). The only inconvenience I see here is installing Java 8, and all the workarounds needed because Java 8 is the odd man out: * javadoc linter not as strict as the others * no release flag I find projects requiring JDK 8 for builds very inconvenient. What does *compatible* mean anyway? -release, good enough. Or just use toolchains > If JDK > 17 being used for the Maven codebase, means the user can't compile > their project with JDK 8 We already said this a few times. Toolchains. Release Flag. Staying on 3.9.x. - Ben Am So., 25. Feb. 2024 um 14:50 Uhr schrieb Elliotte Rusty Harold <elh...@ibiblio.org>: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
