Re: [DISCUSS] Java version for Maven

[Hunter C Payne]

 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 
 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  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 
> 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 :
> > >
> > > 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

  

Re: [DISCUSS] Java version for Maven

[Robert Dean]

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  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 
> 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 :
> > >
> > > 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

Re: [DISCUSS] Java version for Maven

[Manfred Moser]

Given that it will still be quite a while until Maven 4 comes out and we 
are probably going to stick to the same Java version for Maven 4 until 
we move to 5, I would strongly suggest to go with Java 21.


There are a lot of further performance and other improvements from 17 to 
21. Also from our experience with the upgrade in the Trino project the 
leap from 17 to 21 is relatively small.


Manfred

On 2024-02-22 14:40, Brian Fox wrote:

That feels right to me based on the data and all the discussion so far.

On Thu, Feb 22, 2024 at 3:49 PM Tamás Cservenák  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 
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 
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

Re: [DISCUSS] Java version for Maven

[Brian Fox]

That feels right to me based on the data and all the discussion so far.

On Thu, Feb 22, 2024 at 3:49 PM Tamás Cservenák  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 
> 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  >:
> > >
> > > 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
> >
> >
>

Re: [DISCUSS] Java version for Maven

[Tamás Cservenák]

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 
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 :
> >
> > 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
>
>

Re: [DISCUSS] Java version for Maven

[Benjamin Marwell]

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 :
>
> 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

Re: [DISCUSS] Java version for Maven

[Brian Fox]

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.

On Thu, Feb 22, 2024 at 10:24 AM Xeno Amess  wrote:

> > The raw numbers are a more reasonable picture.
> Elliotte, this is just the begin of maven 4, and maven 4.x is not just for
> current projects, but for projects in the next several years.(and I guess
> nobody here wanna increasing jdk major version during a same maven major
> version?)
> So if we agree that projects in future be more likely for higher jdk
> versions, I think the normalization somehow reasonable...Just IMO
>
> Elliotte Rusty Harold  于2024年2月22日周四 21:23写道：
>
> > This is all very interesting data for reasons that go well beyond Maven.
> > Thanks!
> >
> > My personal takeaway is that JDK 8 is a much bigger part of the market
> > than I would have guessed and Java 11 and Java 7 are both much less.
> > It looks to me like the Java world is dividing into two camps: The
> > "risk averse, stay with what works and what we know" camp on Java 8
> > and the Bleeding Edge camp on the latest LTS release.
> >
> > It's possible that's not what's really happening. Java 9 really broke
> > compatibility and caused a lot of pain for folks, so it might just be
> > a split between devs who were burned by Java 9+ and devs who weren't.
> >
> > Either way, we started with only the last 30 days of data so I don't
> > think the normalization is reasonable. The lifespan of Java 8, 11, and
> > 17 are all years before this data was taken so it's not like those
> > clients couldn't have moved to Java 17 for some part of the period.
> > The raw numbers are a more reasonable picture. I do not agree that the
> > weighted pie shows what's dead and what's sliding out.
> >
> > On Thu, Feb 22, 2024 at 4:17 AM Tamás Cservenák 
> > wrote:
> > >
> > > For start I "normalized" the Java strings to a form like "Java 8" or
> > "Java
> > > 17". This resulted in pretty much similar results as Romain PDF (Azul
> > > report).
> > >
> > > But then realized, we should consider this: Not every LTS existed at
> the
> > > same time span (and we discuss the future here, not the past). Here is
> > some
> > > history I collected:
> > >
> > > - Java 8: Covers strings like "Java 1.8.0-25" (2014) to "Java
> 1.8.0-401"
> > > (2024), that is 10 year span.
> > > - Java 11: Covers strings like "Java 11-ea" (2018) to "Java 11.0.22"
> > > (2024), that is a 6 year span.
> > > - Java 17: Covers strings like "Java 17-ea" (2021) to "Java 17.0.10"
> > > (2024), that is a 3 year span.
> > > - Java 21: Covers strings like "Java 21-ea" (2023) to "Java 21.0.2"
> > (2024),
> > > that is 1 year span.
> > >
> > > So, "normalized" and "weighted" (by lifespan) results are these:
> > > https://gist.github.com/cstamas/d2e5560f24ebe6a667834aa1f44d6fc1
> > >
> > > Weighted pie immediately shows which Java versions are "dead" (are
> > present,
> > > but are "sliding out") and which ones are "alive and kicking" (and
> > adoption
> > > is quite high).
> > >
> > > ---
> > >
> > > Refs:
> > > - https://www.java.com/releases/
> > > - https://openjdk.org/projects/jdk/11/
> > > - https://openjdk.org/projects/jdk/17/
> > > - https://openjdk.org/projects/jdk/21/
> > >
> > > On Thu, Feb 22, 2024 at 8:50 AM Tamás Cservenák 
> > wrote:
> > >
> > > > Howdy,
> > > >
> > > > Maven UA is created like this:
> > > >
> > > >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L555
> > > >
> > > > I was hoping also for a list of "Apache Maven ..." lines with
> > occurrence
> > > > count.
> > > >
> > > > Now am unsure, for example if any other tool would use "Java X"
> string
> > in
> > > > its own UA, is that collected here?
> > > >
> > > > But let's cook with what we have :)
> > > >
> > > > T
> > > >
> > > >
> > > > On Thu, Feb 22, 2024, 08:03 Mateusz Gajewski <
> > > > mateusz.gajew...@starburstdata.com> wrote:
> > > >
> > > >> Do you have maven version and java version at the same time report?
> I
> > > >> wonder if old maven is used with old JDK :)
> > > >>
> > > >> On Wed, Feb 21, 2024 at 23:23 Brian Fox  wrote:
> > > >>
> > > >> > Hi everyone. I haven't caught up on this thread but Tamas pinged
> me
> > to
> > > >> get
> > > >> > some usage data from Central. Attached are the Maven versions and
> > JDK
> > > >> > Version counts as reported by User Agent by distinct IP for the
> > last 30
> > > >> > days:
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> 

[VOTE] Release Maven Resolver 2.0.0-alpha-8

[Tamás Cservenák]

Howdy,

Note: This is a seventh (alpha-4 was scrubbed) preview release of Resolver
2.0.0, that would allow any downstream consumers to try it out and adapt.
The supplier is aligned with Maven 4.0.0-alpha-12.

For configuration changes, see
https://maven.apache.org/resolver-archives/resolver-LATEST/configuration.html

IF the vote is successful, the staging site will NOT be moved to
https://maven.apache.org/resolver/ but instead will be made reachable from
https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-8/ only.

The 1.9.18 is still the "latest stable" release of Maven Resolver.

===

We solved 16 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628&version=12354186

There are still some issues in JIRA:
https://issues.apache.org/jira/projects/MRESOLVER/issues

Staging repository:
https://repository.apache.org/content/repositories/maven-2066/

Source release SHA512:
0b6056dea2698eb9c06bb1b12f682e4341def46194337802da147ded7062558446c9d35fafd93537a86c1ea13bf40b4c40c05f901cf8035bb705a65281c4077e

Staging site:
https://maven.apache.org/resolver-archives/resolver-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

Re: [DISCUSS] Java version for Maven

[Xeno Amess]

> The raw numbers are a more reasonable picture.
Elliotte, this is just the begin of maven 4, and maven 4.x is not just for
current projects, but for projects in the next several years.(and I guess
nobody here wanna increasing jdk major version during a same maven major
version?)
So if we agree that projects in future be more likely for higher jdk
versions, I think the normalization somehow reasonable...Just IMO

Elliotte Rusty Harold  于2024年2月22日周四 21:23写道：

> This is all very interesting data for reasons that go well beyond Maven.
> Thanks!
>
> My personal takeaway is that JDK 8 is a much bigger part of the market
> than I would have guessed and Java 11 and Java 7 are both much less.
> It looks to me like the Java world is dividing into two camps: The
> "risk averse, stay with what works and what we know" camp on Java 8
> and the Bleeding Edge camp on the latest LTS release.
>
> It's possible that's not what's really happening. Java 9 really broke
> compatibility and caused a lot of pain for folks, so it might just be
> a split between devs who were burned by Java 9+ and devs who weren't.
>
> Either way, we started with only the last 30 days of data so I don't
> think the normalization is reasonable. The lifespan of Java 8, 11, and
> 17 are all years before this data was taken so it's not like those
> clients couldn't have moved to Java 17 for some part of the period.
> The raw numbers are a more reasonable picture. I do not agree that the
> weighted pie shows what's dead and what's sliding out.
>
> On Thu, Feb 22, 2024 at 4:17 AM Tamás Cservenák 
> wrote:
> >
> > For start I "normalized" the Java strings to a form like "Java 8" or
> "Java
> > 17". This resulted in pretty much similar results as Romain PDF (Azul
> > report).
> >
> > But then realized, we should consider this: Not every LTS existed at the
> > same time span (and we discuss the future here, not the past). Here is
> some
> > history I collected:
> >
> > - Java 8: Covers strings like "Java 1.8.0-25" (2014) to "Java 1.8.0-401"
> > (2024), that is 10 year span.
> > - Java 11: Covers strings like "Java 11-ea" (2018) to "Java 11.0.22"
> > (2024), that is a 6 year span.
> > - Java 17: Covers strings like "Java 17-ea" (2021) to "Java 17.0.10"
> > (2024), that is a 3 year span.
> > - Java 21: Covers strings like "Java 21-ea" (2023) to "Java 21.0.2"
> (2024),
> > that is 1 year span.
> >
> > So, "normalized" and "weighted" (by lifespan) results are these:
> > https://gist.github.com/cstamas/d2e5560f24ebe6a667834aa1f44d6fc1
> >
> > Weighted pie immediately shows which Java versions are "dead" (are
> present,
> > but are "sliding out") and which ones are "alive and kicking" (and
> adoption
> > is quite high).
> >
> > ---
> >
> > Refs:
> > - https://www.java.com/releases/
> > - https://openjdk.org/projects/jdk/11/
> > - https://openjdk.org/projects/jdk/17/
> > - https://openjdk.org/projects/jdk/21/
> >
> > On Thu, Feb 22, 2024 at 8:50 AM Tamás Cservenák 
> wrote:
> >
> > > Howdy,
> > >
> > > Maven UA is created like this:
> > >
> > >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L555
> > >
> > > I was hoping also for a list of "Apache Maven ..." lines with
> occurrence
> > > count.
> > >
> > > Now am unsure, for example if any other tool would use "Java X" string
> in
> > > its own UA, is that collected here?
> > >
> > > But let's cook with what we have :)
> > >
> > > T
> > >
> > >
> > > On Thu, Feb 22, 2024, 08:03 Mateusz Gajewski <
> > > mateusz.gajew...@starburstdata.com> wrote:
> > >
> > >> Do you have maven version and java version at the same time report? I
> > >> wonder if old maven is used with old JDK :)
> > >>
> > >> On Wed, Feb 21, 2024 at 23:23 Brian Fox  wrote:
> > >>
> > >> > Hi everyone. I haven't caught up on this thread but Tamas pinged me
> to
> > >> get
> > >> > some usage data from Central. Attached are the Maven versions and
> JDK
> > >> > Version counts as reported by User Agent by distinct IP for the
> last 30
> > >> > days:
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Wed, Feb 21, 2024 at 4:15 PM Hunter C Payne
> > >> >  wrote:
> > >> >
> > >> >>  I also want to stress that we care about what maven supports far
> more
> > >> >> than what it requires to build.  If it needs JDK 17 to build but
> the
> > >> jars
> > >> >> are compliant with Java 8, that's fine with me.
> > >> >>
> > >> >> Hunter
> > >> >>
> > >> >> On Wednesday, February 21, 2024 at 12:47:33 PM PST, Romain
> > >> >> Manni-Bucau  wrote:
> > >> >>
> > >> >>  Hmm, not sure im ready for a 200M vanilla build tool even if it
> would
> > >> >> have
> > >> >> been ok legally...
> > >> >>
> > >> >> Le mer. 21 févr. 2024 à 21:41, Hunter C Payne
> > >> >>  a écrit :
> > >> >>
> > >> >> >  I might be wrong but I understood that shipping the JRE/JVM
> > >> required a
> > >> >> > license and this is why most people don't ship with a JVM
> bundled.
> > >> But
> > >

Re: [DISCUSS] Java version for Maven

[Elliotte Rusty Harold]

This is all very interesting data for reasons that go well beyond Maven. Thanks!

My personal takeaway is that JDK 8 is a much bigger part of the market
than I would have guessed and Java 11 and Java 7 are both much less.
It looks to me like the Java world is dividing into two camps: The
"risk averse, stay with what works and what we know" camp on Java 8
and the Bleeding Edge camp on the latest LTS release.

It's possible that's not what's really happening. Java 9 really broke
compatibility and caused a lot of pain for folks, so it might just be
a split between devs who were burned by Java 9+ and devs who weren't.

Either way, we started with only the last 30 days of data so I don't
think the normalization is reasonable. The lifespan of Java 8, 11, and
17 are all years before this data was taken so it's not like those
clients couldn't have moved to Java 17 for some part of the period.
The raw numbers are a more reasonable picture. I do not agree that the
weighted pie shows what's dead and what's sliding out.

On Thu, Feb 22, 2024 at 4:17 AM Tamás Cservenák  wrote:
>
> For start I "normalized" the Java strings to a form like "Java 8" or "Java
> 17". This resulted in pretty much similar results as Romain PDF (Azul
> report).
>
> But then realized, we should consider this: Not every LTS existed at the
> same time span (and we discuss the future here, not the past). Here is some
> history I collected:
>
> - Java 8: Covers strings like "Java 1.8.0-25" (2014) to "Java 1.8.0-401"
> (2024), that is 10 year span.
> - Java 11: Covers strings like "Java 11-ea" (2018) to "Java 11.0.22"
> (2024), that is a 6 year span.
> - Java 17: Covers strings like "Java 17-ea" (2021) to "Java 17.0.10"
> (2024), that is a 3 year span.
> - Java 21: Covers strings like "Java 21-ea" (2023) to "Java 21.0.2" (2024),
> that is 1 year span.
>
> So, "normalized" and "weighted" (by lifespan) results are these:
> https://gist.github.com/cstamas/d2e5560f24ebe6a667834aa1f44d6fc1
>
> Weighted pie immediately shows which Java versions are "dead" (are present,
> but are "sliding out") and which ones are "alive and kicking" (and adoption
> is quite high).
>
> ---
>
> Refs:
> - https://www.java.com/releases/
> - https://openjdk.org/projects/jdk/11/
> - https://openjdk.org/projects/jdk/17/
> - https://openjdk.org/projects/jdk/21/
>
> On Thu, Feb 22, 2024 at 8:50 AM Tamás Cservenák  wrote:
>
> > Howdy,
> >
> > Maven UA is created like this:
> >
> > https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L555
> >
> > I was hoping also for a list of "Apache Maven ..." lines with occurrence
> > count.
> >
> > Now am unsure, for example if any other tool would use "Java X" string in
> > its own UA, is that collected here?
> >
> > But let's cook with what we have :)
> >
> > T
> >
> >
> > On Thu, Feb 22, 2024, 08:03 Mateusz Gajewski <
> > mateusz.gajew...@starburstdata.com> wrote:
> >
> >> Do you have maven version and java version at the same time report? I
> >> wonder if old maven is used with old JDK :)
> >>
> >> On Wed, Feb 21, 2024 at 23:23 Brian Fox  wrote:
> >>
> >> > Hi everyone. I haven't caught up on this thread but Tamas pinged me to
> >> get
> >> > some usage data from Central. Attached are the Maven versions and JDK
> >> > Version counts as reported by User Agent by distinct IP for the last 30
> >> > days:
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Wed, Feb 21, 2024 at 4:15 PM Hunter C Payne
> >> >  wrote:
> >> >
> >> >>  I also want to stress that we care about what maven supports far more
> >> >> than what it requires to build.  If it needs JDK 17 to build but the
> >> jars
> >> >> are compliant with Java 8, that's fine with me.
> >> >>
> >> >> Hunter
> >> >>
> >> >> On Wednesday, February 21, 2024 at 12:47:33 PM PST, Romain
> >> >> Manni-Bucau  wrote:
> >> >>
> >> >>  Hmm, not sure im ready for a 200M vanilla build tool even if it would
> >> >> have
> >> >> been ok legally...
> >> >>
> >> >> Le mer. 21 févr. 2024 à 21:41, Hunter C Payne
> >> >>  a écrit :
> >> >>
> >> >> >  I might be wrong but I understood that shipping the JRE/JVM
> >> required a
> >> >> > license and this is why most people don't ship with a JVM bundled.
> >> But
> >> >> > perhaps that has changed since the Oracle v Google/Alphabet trial.
> >> >> > Hunter
> >> >> >
> >> >> >On Wednesday, February 21, 2024 at 12:00:54 PM PST, Benjamin
> >> Marwell
> >> >> <
> >> >> > bmarw...@apache.org> wrote:
> >> >> >
> >> >> >  FWIW, bazel changed its runtime requirement to Java 21.
> >> >> > But they are shipping their own Java Runtime, so their users won't
> >> >> notice.
> >> >> > [1]
> >> >> >
> >> >> > I think they are the first build tool to do that.
> >> >> >
> >> >> > I say this as a FYI fact only, not implying anything.
> >> >> > Make of it what you want.
> >> >> >
> >> >> > - Ben
> >> >> >
> >> >> > Am Di., 20. Feb. 2024 um 21:50 Uhr schrieb Tamás Cservenák
> >> >> > :
> >> >> >

Re: [DISCUSS] Java version for Maven

[Romain Manni-Bucau]

Guess we interleave too much topics.

Do we agree on the starting point which is we must comply to the "default"
JDK users will get by design, ie the --release one?
If so then we should just cover +65% of the targetted JDK and use the
minimum as min requirement for end users, period.
If not then we should refine the prerequisites to run maven.

Side note: this let us free to use java ea if we want on our CI and for
releases, we just have to ensure we run on the minimum supported versions
tests - without compilation to have some harnessing.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 22 févr. 2024 à 12:51, Tamás Cservenák  a
écrit :

> Exactly!
>
> When it all started, the "hurdle" to jump 8 > 11 was smaller, but
> whoever jumped, was literally free after.
> Today, as 11 is dead, the "hurdle" has been raised to 8 > 17, so whoever is
> still waiting, is just piling up problems and more work for themselves.
>
> T
>
> On Thu, Feb 22, 2024 at 12:49 PM Mateusz Gajewski <
> mateusz.gajew...@starburstdata.com> wrote:
>
> > Actually as Trino solves a federation problem, we pull in a lot of
> > dependencies (over 800) and we spent a significant amount of time
> patching
> > and fixing upstream dependencies like Hadoop, Hive, Parquet etc to
> migrate
> > to JDK 17 when it was released, and lately to 21. Migration from 11 to 17
> > was painful due to "strong encapsulation by default". From 17 to 21 was
> > pretty painless - just a bunch of libraries that needed ASM upgrade and
> > some deprecated encryption schemes. To my surprise, different OSS
> > communities are now much more aware of the new JDK versions so testing
> and
> > fixing happens in advance.
> >
> > On the "big companies stays legacy" topic, we sell the enterprise edition
> > of Trino (called Starburst Enterprise) which is on-premise, COTS software
> > to the largest (and probably oldest) companies in the world (from a
> > variety of sectors). When we plan to transition to a new JDK we inform
> our
> > customers several months in advance that this will happen. With JDK 17 we
> > saw some pushback and we delayed the transition for a couple of months,
> but
> > with JDK 21 the situation was totally different - we announced that this
> > would happen in advance too but this time the feedback was "oh, we've
> > already allowed JDK 21 usage in our infrastructure, go ahead". Which was
> > both surprising and encouraging.
> >
> > Times are changing.
> >
> > On Thu, Feb 22, 2024 at 11:22 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> @Tamás Cservenák  if you read carefully I never
> >> wrote
> >> "all Java 21 projects are toy projects" ;). Eclipse is also not a topic,
> >> it
> >> comes as a distro. Quarkus is still 17+21, trinodb is not something
> >> primarly embedding code, it is more a standalone so more counter
> examples
> >> from my understanding of what Maven stands for.
> >> And yes, a lot of java 21 code will be thrown away today, I never said
> 50%
> >> (even less 100% as you meant) but likely > 25%, sure. Same happent for
> >> java
> >> 8, 11, 17 so not sure why 21 would be different.
> >> Does not say 21 is not adopted - I literally wrote the opposite, just
> >> meant
> >> we should always interpret figures for what they are and identify their
> >> bias instead of biasing them more.
> >>
> >> Please note that --release does NOT solve anything, think to maven as an
> >> ecosystem - plugins - and we still want to run with the contextual java
> >> version I guess - if this hypothesis is wrong please close this thread
> and
> >> start a new about this minimalistic feature, if we want to drop that we
> go
> >> in the distro erea, drop plugins support but decision is not taken on
> the
> >> same points at all - we woud likely dont care of the java version we
> would
> >> go that path.
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Blog
> >>  | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn  | Book
> >> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >
> >>
> >>
> >> Le jeu. 22 févr. 2024 à 11:06, Tamás Cservenák  a
> >> écrit :
> >>
> >> > And one more remark regarding "toy projects":
> >> > You seriously mean that these numbers could be skewed by "toy
> projects"?
> >> > IMHO toy projects, while most probably represented here, are "lost,
> like
> >> > tears in the rain".
> >> >
> >> > T
> >> >
> >> > On Thu, Feb 22, 2024 at 10:39 AM Tamás Cservenák  >
> >> > wrote:
> >> >
> >> > > >> lot of java 21 tody is still PoC or

Re: [DISCUSS] Java version for Maven

[Tamás Cservenák]

Exactly!

When it all started, the "hurdle" to jump 8 > 11 was smaller, but
whoever jumped, was literally free after.
Today, as 11 is dead, the "hurdle" has been raised to 8 > 17, so whoever is
still waiting, is just piling up problems and more work for themselves.

T

On Thu, Feb 22, 2024 at 12:49 PM Mateusz Gajewski <
mateusz.gajew...@starburstdata.com> wrote:

> Actually as Trino solves a federation problem, we pull in a lot of
> dependencies (over 800) and we spent a significant amount of time patching
> and fixing upstream dependencies like Hadoop, Hive, Parquet etc to migrate
> to JDK 17 when it was released, and lately to 21. Migration from 11 to 17
> was painful due to "strong encapsulation by default". From 17 to 21 was
> pretty painless - just a bunch of libraries that needed ASM upgrade and
> some deprecated encryption schemes. To my surprise, different OSS
> communities are now much more aware of the new JDK versions so testing and
> fixing happens in advance.
>
> On the "big companies stays legacy" topic, we sell the enterprise edition
> of Trino (called Starburst Enterprise) which is on-premise, COTS software
> to the largest (and probably oldest) companies in the world (from a
> variety of sectors). When we plan to transition to a new JDK we inform our
> customers several months in advance that this will happen. With JDK 17 we
> saw some pushback and we delayed the transition for a couple of months, but
> with JDK 21 the situation was totally different - we announced that this
> would happen in advance too but this time the feedback was "oh, we've
> already allowed JDK 21 usage in our infrastructure, go ahead". Which was
> both surprising and encouraging.
>
> Times are changing.
>
> On Thu, Feb 22, 2024 at 11:22 AM Romain Manni-Bucau 
> wrote:
>
>> @Tamás Cservenák  if you read carefully I never
>> wrote
>> "all Java 21 projects are toy projects" ;). Eclipse is also not a topic,
>> it
>> comes as a distro. Quarkus is still 17+21, trinodb is not something
>> primarly embedding code, it is more a standalone so more counter examples
>> from my understanding of what Maven stands for.
>> And yes, a lot of java 21 code will be thrown away today, I never said 50%
>> (even less 100% as you meant) but likely > 25%, sure. Same happent for
>> java
>> 8, 11, 17 so not sure why 21 would be different.
>> Does not say 21 is not adopted - I literally wrote the opposite, just
>> meant
>> we should always interpret figures for what they are and identify their
>> bias instead of biasing them more.
>>
>> Please note that --release does NOT solve anything, think to maven as an
>> ecosystem - plugins - and we still want to run with the contextual java
>> version I guess - if this hypothesis is wrong please close this thread and
>> start a new about this minimalistic feature, if we want to drop that we go
>> in the distro erea, drop plugins support but decision is not taken on the
>> same points at all - we woud likely dont care of the java version we would
>> go that path.
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le jeu. 22 févr. 2024 à 11:06, Tamás Cservenák  a
>> écrit :
>>
>> > And one more remark regarding "toy projects":
>> > You seriously mean that these numbers could be skewed by "toy projects"?
>> > IMHO toy projects, while most probably represented here, are "lost, like
>> > tears in the rain".
>> >
>> > T
>> >
>> > On Thu, Feb 22, 2024 at 10:39 AM Tamás Cservenák 
>> > wrote:
>> >
>> > > >> lot of java 21 tody is still PoC or toy projects
>> > >
>> > > Quarkus, TrinoDB or Eclipse are not toy projects. So they fact there
>> ARE
>> > > "toy projects", you should not derive that "all Java 21 projects are
>> toy
>> > > projects".
>> > >
>> > > T
>> > >
>> > > On Thu, Feb 22, 2024 at 10:32 AM Romain Manni-Bucau <
>> > rmannibu...@gmail.com>
>> > > wrote:
>> > >
>> > >> [joke]this last diagram looks like you are looking for piece[/]
>> > >>
>> > >> I'm not sure the weight can be linear like that, it is not because
>> you
>> > are
>> > >> old that you will die - lot of java 21 tody is still PoC or toy
>> projects
>> > >> so
>> > >> should be in the weight somehow if we go this way.
>> > >>
>> > >> Ultimately your user agent idea was really better than java stat
>> alone
>> > >> since it is really a cross matrix/time unit we should check.
>> > >>
>> > >> Sadly all these stats miss, for my understanding, the dynamic behind
>> > (like
>> > >> seeing a random point in a exponential vs linear graph, alone you
>> don't
>> > >> know where you are going to).
>> > >>
>> > >> From memory, trying to use the last years figures it seems the
>> dynamic
>> > is
>> > >> to follow the LTS with so

Re: [DISCUSS] Java version for Maven

[Mateusz Gajewski]

Actually as Trino solves a federation problem, we pull in a lot of
dependencies (over 800) and we spent a significant amount of time patching
and fixing upstream dependencies like Hadoop, Hive, Parquet etc to migrate
to JDK 17 when it was released, and lately to 21. Migration from 11 to 17
was painful due to "strong encapsulation by default". From 17 to 21 was
pretty painless - just a bunch of libraries that needed ASM upgrade and
some deprecated encryption schemes. To my surprise, different OSS
communities are now much more aware of the new JDK versions so testing and
fixing happens in advance.

On the "big companies stays legacy" topic, we sell the enterprise edition
of Trino (called Starburst Enterprise) which is on-premise, COTS software
to the largest (and probably oldest) companies in the world (from a
variety of sectors). When we plan to transition to a new JDK we inform our
customers several months in advance that this will happen. With JDK 17 we
saw some pushback and we delayed the transition for a couple of months, but
with JDK 21 the situation was totally different - we announced that this
would happen in advance too but this time the feedback was "oh, we've
already allowed JDK 21 usage in our infrastructure, go ahead". Which was
both surprising and encouraging.

Times are changing.

On Thu, Feb 22, 2024 at 11:22 AM Romain Manni-Bucau 
wrote:

> @Tamás Cservenák  if you read carefully I never wrote
> "all Java 21 projects are toy projects" ;). Eclipse is also not a topic, it
> comes as a distro. Quarkus is still 17+21, trinodb is not something
> primarly embedding code, it is more a standalone so more counter examples
> from my understanding of what Maven stands for.
> And yes, a lot of java 21 code will be thrown away today, I never said 50%
> (even less 100% as you meant) but likely > 25%, sure. Same happent for java
> 8, 11, 17 so not sure why 21 would be different.
> Does not say 21 is not adopted - I literally wrote the opposite, just meant
> we should always interpret figures for what they are and identify their
> bias instead of biasing them more.
>
> Please note that --release does NOT solve anything, think to maven as an
> ecosystem - plugins - and we still want to run with the contextual java
> version I guess - if this hypothesis is wrong please close this thread and
> start a new about this minimalistic feature, if we want to drop that we go
> in the distro erea, drop plugins support but decision is not taken on the
> same points at all - we woud likely dont care of the java version we would
> go that path.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le jeu. 22 févr. 2024 à 11:06, Tamás Cservenák  a
> écrit :
>
> > And one more remark regarding "toy projects":
> > You seriously mean that these numbers could be skewed by "toy projects"?
> > IMHO toy projects, while most probably represented here, are "lost, like
> > tears in the rain".
> >
> > T
> >
> > On Thu, Feb 22, 2024 at 10:39 AM Tamás Cservenák 
> > wrote:
> >
> > > >> lot of java 21 tody is still PoC or toy projects
> > >
> > > Quarkus, TrinoDB or Eclipse are not toy projects. So they fact there
> ARE
> > > "toy projects", you should not derive that "all Java 21 projects are
> toy
> > > projects".
> > >
> > > T
> > >
> > > On Thu, Feb 22, 2024 at 10:32 AM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > >> [joke]this last diagram looks like you are looking for piece[/]
> > >>
> > >> I'm not sure the weight can be linear like that, it is not because you
> > are
> > >> old that you will die - lot of java 21 tody is still PoC or toy
> projects
> > >> so
> > >> should be in the weight somehow if we go this way.
> > >>
> > >> Ultimately your user agent idea was really better than java stat alone
> > >> since it is really a cross matrix/time unit we should check.
> > >>
> > >> Sadly all these stats miss, for my understanding, the dynamic behind
> > (like
> > >> seeing a random point in a exponential vs linear graph, alone you
> don't
> > >> know where you are going to).
> > >>
> > >> From memory, trying to use the last years figures it seems the dynamic
> > is
> > >> to follow the LTS with some lateness, ie current is 21 but people are
> > >> around 11-17. Like a sliding window.
> > >> Indeed the public polls I use - the ones you get on twitter from
> > intellij
> > >> or friends - for that conclusion are biased cause they hit more
> "geeks"
> > >> than standard work people but I don't have anything better right now
> in
> > >> terms of time serie.
> > >> Anyone has more comparative data about that?
> > >>
> > >> My proposal/thought was really to align on that dynamic - from the
> > latest
> > >>

Re: [DISCUSS] Java version for Maven

[Romain Manni-Bucau]

@Tamás Cservenák  if you read carefully I never wrote
"all Java 21 projects are toy projects" ;). Eclipse is also not a topic, it
comes as a distro. Quarkus is still 17+21, trinodb is not something
primarly embedding code, it is more a standalone so more counter examples
from my understanding of what Maven stands for.
And yes, a lot of java 21 code will be thrown away today, I never said 50%
(even less 100% as you meant) but likely > 25%, sure. Same happent for java
8, 11, 17 so not sure why 21 would be different.
Does not say 21 is not adopted - I literally wrote the opposite, just meant
we should always interpret figures for what they are and identify their
bias instead of biasing them more.

Please note that --release does NOT solve anything, think to maven as an
ecosystem - plugins - and we still want to run with the contextual java
version I guess - if this hypothesis is wrong please close this thread and
start a new about this minimalistic feature, if we want to drop that we go
in the distro erea, drop plugins support but decision is not taken on the
same points at all - we woud likely dont care of the java version we would
go that path.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 22 févr. 2024 à 11:06, Tamás Cservenák  a
écrit :

> And one more remark regarding "toy projects":
> You seriously mean that these numbers could be skewed by "toy projects"?
> IMHO toy projects, while most probably represented here, are "lost, like
> tears in the rain".
>
> T
>
> On Thu, Feb 22, 2024 at 10:39 AM Tamás Cservenák 
> wrote:
>
> > >> lot of java 21 tody is still PoC or toy projects
> >
> > Quarkus, TrinoDB or Eclipse are not toy projects. So they fact there ARE
> > "toy projects", you should not derive that "all Java 21 projects are toy
> > projects".
> >
> > T
> >
> > On Thu, Feb 22, 2024 at 10:32 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> [joke]this last diagram looks like you are looking for piece[/]
> >>
> >> I'm not sure the weight can be linear like that, it is not because you
> are
> >> old that you will die - lot of java 21 tody is still PoC or toy projects
> >> so
> >> should be in the weight somehow if we go this way.
> >>
> >> Ultimately your user agent idea was really better than java stat alone
> >> since it is really a cross matrix/time unit we should check.
> >>
> >> Sadly all these stats miss, for my understanding, the dynamic behind
> (like
> >> seeing a random point in a exponential vs linear graph, alone you don't
> >> know where you are going to).
> >>
> >> From memory, trying to use the last years figures it seems the dynamic
> is
> >> to follow the LTS with some lateness, ie current is 21 but people are
> >> around 11-17. Like a sliding window.
> >> Indeed the public polls I use - the ones you get on twitter from
> intellij
> >> or friends - for that conclusion are biased cause they hit more "geeks"
> >> than standard work people but I don't have anything better right now in
> >> terms of time serie.
> >> Anyone has more comparative data about that?
> >>
> >> My proposal/thought was really to align on that dynamic - from the
> latest
> >> to a limit to cover ~>=65% of people - more than fixing some version in
> >> stone.
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Blog
> >>  | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn  | Book
> >> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >
> >>
> >>
> >> Le jeu. 22 févr. 2024 à 10:17, Tamás Cservenák  a
> >> écrit :
> >>
> >> > For start I "normalized" the Java strings to a form like "Java 8" or
> >> "Java
> >> > 17". This resulted in pretty much similar results as Romain PDF (Azul
> >> > report).
> >> >
> >> > But then realized, we should consider this: Not every LTS existed at
> the
> >> > same time span (and we discuss the future here, not the past). Here is
> >> some
> >> > history I collected:
> >> >
> >> > - Java 8: Covers strings like "Java 1.8.0-25" (2014) to "Java
> 1.8.0-401"
> >> > (2024), that is 10 year span.
> >> > - Java 11: Covers strings like "Java 11-ea" (2018) to "Java 11.0.22"
> >> > (2024), that is a 6 year span.
> >> > - Java 17: Covers strings like "Java 17-ea" (2021) to "Java 17.0.10"
> >> > (2024), that is a 3 year span.
> >> > - Java 21: Covers strings like "Java 21-ea" (2023) to "Java 21.0.2"
> >> (2024),
> >> > that is 1 year span.
> >> >
> >> > So, "normalized" and "weighted" (by lifespan) results are these:
> >> > https://gist.github.com/cstamas/d2e5560f24ebe6a667834aa1f44

Re: [DISCUSS] Java version for Maven

[Tamás Cservenák]

And one more remark regarding "toy projects":
You seriously mean that these numbers could be skewed by "toy projects"?
IMHO toy projects, while most probably represented here, are "lost, like
tears in the rain".

T

On Thu, Feb 22, 2024 at 10:39 AM Tamás Cservenák 
wrote:

> >> lot of java 21 tody is still PoC or toy projects
>
> Quarkus, TrinoDB or Eclipse are not toy projects. So they fact there ARE
> "toy projects", you should not derive that "all Java 21 projects are toy
> projects".
>
> T
>
> On Thu, Feb 22, 2024 at 10:32 AM Romain Manni-Bucau 
> wrote:
>
>> [joke]this last diagram looks like you are looking for piece[/]
>>
>> I'm not sure the weight can be linear like that, it is not because you are
>> old that you will die - lot of java 21 tody is still PoC or toy projects
>> so
>> should be in the weight somehow if we go this way.
>>
>> Ultimately your user agent idea was really better than java stat alone
>> since it is really a cross matrix/time unit we should check.
>>
>> Sadly all these stats miss, for my understanding, the dynamic behind (like
>> seeing a random point in a exponential vs linear graph, alone you don't
>> know where you are going to).
>>
>> From memory, trying to use the last years figures it seems the dynamic is
>> to follow the LTS with some lateness, ie current is 21 but people are
>> around 11-17. Like a sliding window.
>> Indeed the public polls I use - the ones you get on twitter from intellij
>> or friends - for that conclusion are biased cause they hit more "geeks"
>> than standard work people but I don't have anything better right now in
>> terms of time serie.
>> Anyone has more comparative data about that?
>>
>> My proposal/thought was really to align on that dynamic - from the latest
>> to a limit to cover ~>=65% of people - more than fixing some version in
>> stone.
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le jeu. 22 févr. 2024 à 10:17, Tamás Cservenák  a
>> écrit :
>>
>> > For start I "normalized" the Java strings to a form like "Java 8" or
>> "Java
>> > 17". This resulted in pretty much similar results as Romain PDF (Azul
>> > report).
>> >
>> > But then realized, we should consider this: Not every LTS existed at the
>> > same time span (and we discuss the future here, not the past). Here is
>> some
>> > history I collected:
>> >
>> > - Java 8: Covers strings like "Java 1.8.0-25" (2014) to "Java 1.8.0-401"
>> > (2024), that is 10 year span.
>> > - Java 11: Covers strings like "Java 11-ea" (2018) to "Java 11.0.22"
>> > (2024), that is a 6 year span.
>> > - Java 17: Covers strings like "Java 17-ea" (2021) to "Java 17.0.10"
>> > (2024), that is a 3 year span.
>> > - Java 21: Covers strings like "Java 21-ea" (2023) to "Java 21.0.2"
>> (2024),
>> > that is 1 year span.
>> >
>> > So, "normalized" and "weighted" (by lifespan) results are these:
>> > https://gist.github.com/cstamas/d2e5560f24ebe6a667834aa1f44d6fc1
>> >
>> > Weighted pie immediately shows which Java versions are "dead" (are
>> present,
>> > but are "sliding out") and which ones are "alive and kicking" (and
>> adoption
>> > is quite high).
>> >
>> > ---
>> >
>> > Refs:
>> > - https://www.java.com/releases/
>> > - https://openjdk.org/projects/jdk/11/
>> > - https://openjdk.org/projects/jdk/17/
>> > - https://openjdk.org/projects/jdk/21/
>> >
>> > On Thu, Feb 22, 2024 at 8:50 AM Tamás Cservenák 
>> > wrote:
>> >
>> > > Howdy,
>> > >
>> > > Maven UA is created like this:
>> > >
>> > >
>> >
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L555
>> > >
>> > > I was hoping also for a list of "Apache Maven ..." lines with
>> occurrence
>> > > count.
>> > >
>> > > Now am unsure, for example if any other tool would use "Java X"
>> string in
>> > > its own UA, is that collected here?
>> > >
>> > > But let's cook with what we have :)
>> > >
>> > > T
>> > >
>> > >
>> > > On Thu, Feb 22, 2024, 08:03 Mateusz Gajewski <
>> > > mateusz.gajew...@starburstdata.com> wrote:
>> > >
>> > >> Do you have maven version and java version at the same time report? I
>> > >> wonder if old maven is used with old JDK :)
>> > >>
>> > >> On Wed, Feb 21, 2024 at 23:23 Brian Fox  wrote:
>> > >>
>> > >> > Hi everyone. I haven't caught up on this thread but Tamas pinged
>> me to
>> > >> get
>> > >> > some usage data from Central. Attached are the Maven versions and
>> JDK
>> > >> > Version counts as reported by User Agent by distinct IP for the
>> last
>> > 30
>> > >> > days:
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> > On Wed, Feb 21, 2024 at 4:15 PM Hunter C Payne
>> > >> >  wrote:
>> > >> >
>> > >> >

Re: [DISCUSS] Java version for Maven

[Tamás Cservenák]

So, my proposal would be:

* Maven build time requirement: "${current} LTS"
* Maven run time requirement: "${current - 1} LTS" (maybe ${current-2} but
i really see no point in that 3 LTS versions past 8).

Basically use Java LTS versions as stepping stones.

We could enforce this with parent POM: whenever we release a new parent
POM, we "align" with the "current LTS" in the moment of release, and as
parent POM is adopted, projects are moved as well. It just trickles down.

Hence, if we'd release parent POM right now, then it would be:
* it would enforce Java 21 build time (enforcer requireJavaVersion=21)
* it would produce Java 17 bytecode (release=17)

So, users would need to use Java 17 to run Maven. Those producing Java 8
bytecode could still happily use release=8 to create Java 8 bytecode.
Have to note that Java 21 also allows this, but already produces a warning
that "release=8 is deprecated".

Thanks
T

On Thu, Feb 22, 2024 at 10:39 AM Tamás Cservenák 
wrote:

> >> lot of java 21 tody is still PoC or toy projects
>
> Quarkus, TrinoDB or Eclipse are not toy projects. So they fact there ARE
> "toy projects", you should not derive that "all Java 21 projects are toy
> projects".
>
> T
>
> On Thu, Feb 22, 2024 at 10:32 AM Romain Manni-Bucau 
> wrote:
>
>> [joke]this last diagram looks like you are looking for piece[/]
>>
>> I'm not sure the weight can be linear like that, it is not because you are
>> old that you will die - lot of java 21 tody is still PoC or toy projects
>> so
>> should be in the weight somehow if we go this way.
>>
>> Ultimately your user agent idea was really better than java stat alone
>> since it is really a cross matrix/time unit we should check.
>>
>> Sadly all these stats miss, for my understanding, the dynamic behind (like
>> seeing a random point in a exponential vs linear graph, alone you don't
>> know where you are going to).
>>
>> From memory, trying to use the last years figures it seems the dynamic is
>> to follow the LTS with some lateness, ie current is 21 but people are
>> around 11-17. Like a sliding window.
>> Indeed the public polls I use - the ones you get on twitter from intellij
>> or friends - for that conclusion are biased cause they hit more "geeks"
>> than standard work people but I don't have anything better right now in
>> terms of time serie.
>> Anyone has more comparative data about that?
>>
>> My proposal/thought was really to align on that dynamic - from the latest
>> to a limit to cover ~>=65% of people - more than fixing some version in
>> stone.
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le jeu. 22 févr. 2024 à 10:17, Tamás Cservenák  a
>> écrit :
>>
>> > For start I "normalized" the Java strings to a form like "Java 8" or
>> "Java
>> > 17". This resulted in pretty much similar results as Romain PDF (Azul
>> > report).
>> >
>> > But then realized, we should consider this: Not every LTS existed at the
>> > same time span (and we discuss the future here, not the past). Here is
>> some
>> > history I collected:
>> >
>> > - Java 8: Covers strings like "Java 1.8.0-25" (2014) to "Java 1.8.0-401"
>> > (2024), that is 10 year span.
>> > - Java 11: Covers strings like "Java 11-ea" (2018) to "Java 11.0.22"
>> > (2024), that is a 6 year span.
>> > - Java 17: Covers strings like "Java 17-ea" (2021) to "Java 17.0.10"
>> > (2024), that is a 3 year span.
>> > - Java 21: Covers strings like "Java 21-ea" (2023) to "Java 21.0.2"
>> (2024),
>> > that is 1 year span.
>> >
>> > So, "normalized" and "weighted" (by lifespan) results are these:
>> > https://gist.github.com/cstamas/d2e5560f24ebe6a667834aa1f44d6fc1
>> >
>> > Weighted pie immediately shows which Java versions are "dead" (are
>> present,
>> > but are "sliding out") and which ones are "alive and kicking" (and
>> adoption
>> > is quite high).
>> >
>> > ---
>> >
>> > Refs:
>> > - https://www.java.com/releases/
>> > - https://openjdk.org/projects/jdk/11/
>> > - https://openjdk.org/projects/jdk/17/
>> > - https://openjdk.org/projects/jdk/21/
>> >
>> > On Thu, Feb 22, 2024 at 8:50 AM Tamás Cservenák 
>> > wrote:
>> >
>> > > Howdy,
>> > >
>> > > Maven UA is created like this:
>> > >
>> > >
>> >
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L555
>> > >
>> > > I was hoping also for a list of "Apache Maven ..." lines with
>> occurrence
>> > > count.
>> > >
>> > > Now am unsure, for example if any other tool would use "Java X"
>> string in
>> > > its own UA, is that collected here?
>> > >
>> > > But let's cook with what we have :)
>> > >
>> > > T
>> > >
>> > >
>> > > On Thu, Feb 22, 2024, 08:03 

Re: [DISCUSS] Java version for Maven

[Tamás Cservenák]

>> lot of java 21 tody is still PoC or toy projects

Quarkus, TrinoDB or Eclipse are not toy projects. So they fact there ARE
"toy projects", you should not derive that "all Java 21 projects are toy
projects".

T

On Thu, Feb 22, 2024 at 10:32 AM Romain Manni-Bucau 
wrote:

> [joke]this last diagram looks like you are looking for piece[/]
>
> I'm not sure the weight can be linear like that, it is not because you are
> old that you will die - lot of java 21 tody is still PoC or toy projects so
> should be in the weight somehow if we go this way.
>
> Ultimately your user agent idea was really better than java stat alone
> since it is really a cross matrix/time unit we should check.
>
> Sadly all these stats miss, for my understanding, the dynamic behind (like
> seeing a random point in a exponential vs linear graph, alone you don't
> know where you are going to).
>
> From memory, trying to use the last years figures it seems the dynamic is
> to follow the LTS with some lateness, ie current is 21 but people are
> around 11-17. Like a sliding window.
> Indeed the public polls I use - the ones you get on twitter from intellij
> or friends - for that conclusion are biased cause they hit more "geeks"
> than standard work people but I don't have anything better right now in
> terms of time serie.
> Anyone has more comparative data about that?
>
> My proposal/thought was really to align on that dynamic - from the latest
> to a limit to cover ~>=65% of people - more than fixing some version in
> stone.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le jeu. 22 févr. 2024 à 10:17, Tamás Cservenák  a
> écrit :
>
> > For start I "normalized" the Java strings to a form like "Java 8" or
> "Java
> > 17". This resulted in pretty much similar results as Romain PDF (Azul
> > report).
> >
> > But then realized, we should consider this: Not every LTS existed at the
> > same time span (and we discuss the future here, not the past). Here is
> some
> > history I collected:
> >
> > - Java 8: Covers strings like "Java 1.8.0-25" (2014) to "Java 1.8.0-401"
> > (2024), that is 10 year span.
> > - Java 11: Covers strings like "Java 11-ea" (2018) to "Java 11.0.22"
> > (2024), that is a 6 year span.
> > - Java 17: Covers strings like "Java 17-ea" (2021) to "Java 17.0.10"
> > (2024), that is a 3 year span.
> > - Java 21: Covers strings like "Java 21-ea" (2023) to "Java 21.0.2"
> (2024),
> > that is 1 year span.
> >
> > So, "normalized" and "weighted" (by lifespan) results are these:
> > https://gist.github.com/cstamas/d2e5560f24ebe6a667834aa1f44d6fc1
> >
> > Weighted pie immediately shows which Java versions are "dead" (are
> present,
> > but are "sliding out") and which ones are "alive and kicking" (and
> adoption
> > is quite high).
> >
> > ---
> >
> > Refs:
> > - https://www.java.com/releases/
> > - https://openjdk.org/projects/jdk/11/
> > - https://openjdk.org/projects/jdk/17/
> > - https://openjdk.org/projects/jdk/21/
> >
> > On Thu, Feb 22, 2024 at 8:50 AM Tamás Cservenák 
> > wrote:
> >
> > > Howdy,
> > >
> > > Maven UA is created like this:
> > >
> > >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L555
> > >
> > > I was hoping also for a list of "Apache Maven ..." lines with
> occurrence
> > > count.
> > >
> > > Now am unsure, for example if any other tool would use "Java X" string
> in
> > > its own UA, is that collected here?
> > >
> > > But let's cook with what we have :)
> > >
> > > T
> > >
> > >
> > > On Thu, Feb 22, 2024, 08:03 Mateusz Gajewski <
> > > mateusz.gajew...@starburstdata.com> wrote:
> > >
> > >> Do you have maven version and java version at the same time report? I
> > >> wonder if old maven is used with old JDK :)
> > >>
> > >> On Wed, Feb 21, 2024 at 23:23 Brian Fox  wrote:
> > >>
> > >> > Hi everyone. I haven't caught up on this thread but Tamas pinged me
> to
> > >> get
> > >> > some usage data from Central. Attached are the Maven versions and
> JDK
> > >> > Version counts as reported by User Agent by distinct IP for the last
> > 30
> > >> > days:
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Wed, Feb 21, 2024 at 4:15 PM Hunter C Payne
> > >> >  wrote:
> > >> >
> > >> >>  I also want to stress that we care about what maven supports far
> > more
> > >> >> than what it requires to build.  If it needs JDK 17 to build but
> the
> > >> jars
> > >> >> are compliant with Java 8, that's fine with me.
> > >> >>
> > >> >> Hunter
> > >> >>
> > >> >> On Wednesday, February 21, 2024 at 12:47:33 PM PST, Romain
> > >> >> Manni-Bucau  wrote:
> > >> >>
> > >> >>  Hmm, not sure im ready for a 200M v

Re: [DISCUSS] Java version for Maven

[Romain Manni-Bucau]

[joke]this last diagram looks like you are looking for piece[/]

I'm not sure the weight can be linear like that, it is not because you are
old that you will die - lot of java 21 tody is still PoC or toy projects so
should be in the weight somehow if we go this way.

Ultimately your user agent idea was really better than java stat alone
since it is really a cross matrix/time unit we should check.

Sadly all these stats miss, for my understanding, the dynamic behind (like
seeing a random point in a exponential vs linear graph, alone you don't
know where you are going to).

>From memory, trying to use the last years figures it seems the dynamic is
to follow the LTS with some lateness, ie current is 21 but people are
around 11-17. Like a sliding window.
Indeed the public polls I use - the ones you get on twitter from intellij
or friends - for that conclusion are biased cause they hit more "geeks"
than standard work people but I don't have anything better right now in
terms of time serie.
Anyone has more comparative data about that?

My proposal/thought was really to align on that dynamic - from the latest
to a limit to cover ~>=65% of people - more than fixing some version in
stone.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 22 févr. 2024 à 10:17, Tamás Cservenák  a
écrit :

> For start I "normalized" the Java strings to a form like "Java 8" or "Java
> 17". This resulted in pretty much similar results as Romain PDF (Azul
> report).
>
> But then realized, we should consider this: Not every LTS existed at the
> same time span (and we discuss the future here, not the past). Here is some
> history I collected:
>
> - Java 8: Covers strings like "Java 1.8.0-25" (2014) to "Java 1.8.0-401"
> (2024), that is 10 year span.
> - Java 11: Covers strings like "Java 11-ea" (2018) to "Java 11.0.22"
> (2024), that is a 6 year span.
> - Java 17: Covers strings like "Java 17-ea" (2021) to "Java 17.0.10"
> (2024), that is a 3 year span.
> - Java 21: Covers strings like "Java 21-ea" (2023) to "Java 21.0.2" (2024),
> that is 1 year span.
>
> So, "normalized" and "weighted" (by lifespan) results are these:
> https://gist.github.com/cstamas/d2e5560f24ebe6a667834aa1f44d6fc1
>
> Weighted pie immediately shows which Java versions are "dead" (are present,
> but are "sliding out") and which ones are "alive and kicking" (and adoption
> is quite high).
>
> ---
>
> Refs:
> - https://www.java.com/releases/
> - https://openjdk.org/projects/jdk/11/
> - https://openjdk.org/projects/jdk/17/
> - https://openjdk.org/projects/jdk/21/
>
> On Thu, Feb 22, 2024 at 8:50 AM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > Maven UA is created like this:
> >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L555
> >
> > I was hoping also for a list of "Apache Maven ..." lines with occurrence
> > count.
> >
> > Now am unsure, for example if any other tool would use "Java X" string in
> > its own UA, is that collected here?
> >
> > But let's cook with what we have :)
> >
> > T
> >
> >
> > On Thu, Feb 22, 2024, 08:03 Mateusz Gajewski <
> > mateusz.gajew...@starburstdata.com> wrote:
> >
> >> Do you have maven version and java version at the same time report? I
> >> wonder if old maven is used with old JDK :)
> >>
> >> On Wed, Feb 21, 2024 at 23:23 Brian Fox  wrote:
> >>
> >> > Hi everyone. I haven't caught up on this thread but Tamas pinged me to
> >> get
> >> > some usage data from Central. Attached are the Maven versions and JDK
> >> > Version counts as reported by User Agent by distinct IP for the last
> 30
> >> > days:
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Wed, Feb 21, 2024 at 4:15 PM Hunter C Payne
> >> >  wrote:
> >> >
> >> >>  I also want to stress that we care about what maven supports far
> more
> >> >> than what it requires to build.  If it needs JDK 17 to build but the
> >> jars
> >> >> are compliant with Java 8, that's fine with me.
> >> >>
> >> >> Hunter
> >> >>
> >> >> On Wednesday, February 21, 2024 at 12:47:33 PM PST, Romain
> >> >> Manni-Bucau  wrote:
> >> >>
> >> >>  Hmm, not sure im ready for a 200M vanilla build tool even if it
> would
> >> >> have
> >> >> been ok legally...
> >> >>
> >> >> Le mer. 21 févr. 2024 à 21:41, Hunter C Payne
> >> >>  a écrit :
> >> >>
> >> >> >  I might be wrong but I understood that shipping the JRE/JVM
> >> required a
> >> >> > license and this is why most people don't ship with a JVM bundled.
> >> But
> >> >> > perhaps that has changed since the Oracle v Google/Alphabet trial.
> >> >> > Hunter
> >> >> >
> >> >> >On Wednesday, February 21, 2024 at 12:00:54 PM PST, Benjamin
> >> Marwell
> >> >> <
> >>

Re: [DISCUSS] Java version for Maven

[Tamás Cservenák]

For start I "normalized" the Java strings to a form like "Java 8" or "Java
17". This resulted in pretty much similar results as Romain PDF (Azul
report).

But then realized, we should consider this: Not every LTS existed at the
same time span (and we discuss the future here, not the past). Here is some
history I collected:

- Java 8: Covers strings like "Java 1.8.0-25" (2014) to "Java 1.8.0-401"
(2024), that is 10 year span.
- Java 11: Covers strings like "Java 11-ea" (2018) to "Java 11.0.22"
(2024), that is a 6 year span.
- Java 17: Covers strings like "Java 17-ea" (2021) to "Java 17.0.10"
(2024), that is a 3 year span.
- Java 21: Covers strings like "Java 21-ea" (2023) to "Java 21.0.2" (2024),
that is 1 year span.

So, "normalized" and "weighted" (by lifespan) results are these:
https://gist.github.com/cstamas/d2e5560f24ebe6a667834aa1f44d6fc1

Weighted pie immediately shows which Java versions are "dead" (are present,
but are "sliding out") and which ones are "alive and kicking" (and adoption
is quite high).

---

Refs:
- https://www.java.com/releases/
- https://openjdk.org/projects/jdk/11/
- https://openjdk.org/projects/jdk/17/
- https://openjdk.org/projects/jdk/21/

On Thu, Feb 22, 2024 at 8:50 AM Tamás Cservenák  wrote:

> Howdy,
>
> Maven UA is created like this:
>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L555
>
> I was hoping also for a list of "Apache Maven ..." lines with occurrence
> count.
>
> Now am unsure, for example if any other tool would use "Java X" string in
> its own UA, is that collected here?
>
> But let's cook with what we have :)
>
> T
>
>
> On Thu, Feb 22, 2024, 08:03 Mateusz Gajewski <
> mateusz.gajew...@starburstdata.com> wrote:
>
>> Do you have maven version and java version at the same time report? I
>> wonder if old maven is used with old JDK :)
>>
>> On Wed, Feb 21, 2024 at 23:23 Brian Fox  wrote:
>>
>> > Hi everyone. I haven't caught up on this thread but Tamas pinged me to
>> get
>> > some usage data from Central. Attached are the Maven versions and JDK
>> > Version counts as reported by User Agent by distinct IP for the last 30
>> > days:
>> >
>> >
>> >
>> >
>> >
>> > On Wed, Feb 21, 2024 at 4:15 PM Hunter C Payne
>> >  wrote:
>> >
>> >>  I also want to stress that we care about what maven supports far more
>> >> than what it requires to build.  If it needs JDK 17 to build but the
>> jars
>> >> are compliant with Java 8, that's fine with me.
>> >>
>> >> Hunter
>> >>
>> >> On Wednesday, February 21, 2024 at 12:47:33 PM PST, Romain
>> >> Manni-Bucau  wrote:
>> >>
>> >>  Hmm, not sure im ready for a 200M vanilla build tool even if it would
>> >> have
>> >> been ok legally...
>> >>
>> >> Le mer. 21 févr. 2024 à 21:41, Hunter C Payne
>> >>  a écrit :
>> >>
>> >> >  I might be wrong but I understood that shipping the JRE/JVM
>> required a
>> >> > license and this is why most people don't ship with a JVM bundled.
>> But
>> >> > perhaps that has changed since the Oracle v Google/Alphabet trial.
>> >> > Hunter
>> >> >
>> >> >On Wednesday, February 21, 2024 at 12:00:54 PM PST, Benjamin
>> Marwell
>> >> <
>> >> > bmarw...@apache.org> wrote:
>> >> >
>> >> >  FWIW, bazel changed its runtime requirement to Java 21.
>> >> > But they are shipping their own Java Runtime, so their users won't
>> >> notice.
>> >> > [1]
>> >> >
>> >> > I think they are the first build tool to do that.
>> >> >
>> >> > I say this as a FYI fact only, not implying anything.
>> >> > Make of it what you want.
>> >> >
>> >> > - Ben
>> >> >
>> >> > Am Di., 20. Feb. 2024 um 21:50 Uhr schrieb Tamás Cservenák
>> >> > :
>> >> > >
>> >> > > Howdy,
>> >> > >
>> >> > > I intentionally used "Maven" here, and not "Maven 4" as I am sure
>> the
>> >> > > majority of Maven users do not run Maven on the same Java version
>> they
>> >> > > target with their build. We do not do that either.
>> >> > >
>> >> > > Some snippets from Herve (who is the ONLY one doing reproducible
>> >> checks,
>> >> > > kudos for that) votes:
>> >> > >
>> >> > > Sun, Feb 18, 2024, 9:38 AM
>> >> > > [VOTE] Release Apache Maven Shade Plugin version 3.5.2
>> >> > > Reproducible Build ok: reference build done with JDK 11 on *nix
>> >> > >
>> >> > > Wed, Jan 31, 2024, 5:06 AM
>> >> > > [VOTE] Release Apache Maven JLink Plugin version 3.2.0
>> >> > > Reproducible Builds ok: reference build done on *nix with JDK 21
>> and
>> >> > umask
>> >> > > 022
>> >> > >
>> >> > > Mon, Jan 8, 2024, 8:29 AM
>> >> > > [VOTE] Release Maven Plugin Tools version 3.11.0
>> >> > > Reproducible Builds ok: reference build done with JDK 8 on Windows
>> >> with
>> >> > > umask
>> >> > >
>> >> > > Mon, Dec 18, 2023, 8:59 AM
>> >> > > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
>> >> > > Reproducible Builds ok: reference build done on *nix with JDK 21
>> and
>> >> > umask
>> >> > > 022
>> >> > >
>> >> > > Mon, Dec 18, 2023, 8:59 AM
>> >> > > [VOTE] Release Ap