Is a JDK 17 capable of building JDK 8 jars from JDK 17 source? If so, what
are we discussing/arguing/debating about? Seems to me that that configuration
gets you everything you want without forcing Maven 4 to not work with JVM/JRE 8.
Hunter
On Saturday, February 24, 2024 at 03:09:07 PM PST, Jorge Solórzano
<jor...@gmail.com> wrote:
On Sat, Feb 24, 2024, 16:55 Tamás Cservenák <ta...@cservenak.net> wrote:
> Jorge,
>
> Allow me one question: why would we need 3.10 for this? Could not we set
> same thing for existing 3.9.x?
>
Yes, but 3.10 can be used to better signal that is an LTS since the
beginning and will only contain critical bug fixes, breaking change should
not happen, in other words, that's not actively worked on and will be the
last version of the 3.x line.
Other than that, if it's agreed to just use 3.9 as LTS, then simply
s/3.10/3.9/ on the previous mail. :)
> 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.
> >
>
