Personally, given that Maven that still requires XML and that the language
innovation happens these days outside of the Java language itself, the
technical debt cleanup argument doesn't carry as much weight for me. And
requiring 21 seems like a really big jump from 7-8. The performance benefits
aren't provided by the compiler, they come from hotspot and that's the JVM
version at runtime that matters there. So the provided arguments about the
benefits of a later JDK aren't really limited by what language Maven uses in
its built pipeline nor the source version it is compiled with. Instead it is
the version of the JVM that the end user uses that matters for the performance
benefits.
Hunter
On Thursday, February 22, 2024 at 04:20:49 PM PST, Robert Dean
<rdea...@gmail.com> wrote:
As an end user, having a single version of Maven that could build all
my projects (Java 8 - 21) would be preferred, even if it requires Java
21 to run. That would allow for build pipeline standardization on a
single version of Maven and simplify things for developers.
That being said, if retiring Java 8 and lower output support allows
Maven to shed technical debt and deliver improvements faster, I'd get
over my disappointment. :)
Regards,
Robert Dean
On Thu, Feb 22, 2024 at 3:49 PM Tamás Cservenák <ta...@cservenak.net> wrote:
>
> I think this starts to make reasonable picture:
>
> If you are on Java 8, use Maven 3
> If you are on Java 9+ use Maven 4 (once out).
>
> For start, Maven3 has no idea (notion) about "classpaths" vs "modulepaths"
> (is not quite true stated like this, it has SOME heuristics, that is mostly
> shoot-and-miss).
>
> So, I think it makes sense to have Maven 4 as Java 17, as folks in "big
> tech" with strict processes, policies and what not will not migrate anyway
> to Maven4. They have Maven3.
>
> T
>
>
> On Thu, Feb 22, 2024 at 9:23 PM Benjamin Marwell <bmarw...@apache.org>
> wrote:
>
> > Brian, any Chance you could make a stacked 100% graph for every *week*
> > of the past two years?
> > We could then see where we are heading…
> > (or the raw numbers per week, so we could work with that).
> >
> > That's probably a lot to ask, but I think it will show us how "fast"
> > the progression was (and will be).
> >
> > @Tamas please consider the support times are different by vendor.
> > I have seen Java 8 support well beyond 2030 *shudder*.
> >
> > Seeing all those numbers, I now feel a lot more confident that Maven 4
> > should be 17 (runtime), 21 (build)
> > and Java 8 users should stay with 3.x.x.
> > Elliotte gave a good reason for this: There are two camps now (read:
> > ALREADY).
> > There is no reason to not go with either of them.
> >
> > Am Do., 22. Feb. 2024 um 19:56 Uhr schrieb Brian Fox <bri...@infinity.nu>:
> > >
> > > We dumped 30 days because that gives a good snapshot of what's happening
> > > right now. If we dumped for example the whole year, then it really blurs
> > > the lines all over the place and things newer will be less prominent just
> > > because they didn't have as much time. 30 days is how we typically bucket
> > > things when we want a form of relative popularity.
> > >
> > > As far as toy projects skewing, Tamas is right, the scale of central data
> > > is so large that it's insignificant. Also remember we only counted each
> > IP
> > > once per entry so even projects downloading over and over won't skew the
> > > results.
> >
> > ---------------------------------------------------------------------
> > 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
