Re: [DISCUSS] Java version for Maven

[Benjamin Marwell]

At this point, we have discussed many aspects.
Please feel to vote:

User List:
https://lists.apache.org/thread/ty321ns72qc6l26bjy58d9430ofg2w5t

Dev List:
https://lists.apache.org/thread/vngchrr3owd92v9y09lyfjjhwkl5hvtn

-
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

[Romain Manni-Bucau]

Hi Hervé

Im not sure why there is this belief toolchain improvement is needed, this
is NOT needed and CI already bypass it so for me this is not an enabler,
more a blocker IRL.
Let's improve plugins if they dont enable executable/env config but
toolchain is just a part of the execution of so troublesome to maintain
that I cant see it as a solution to any problem.

Le mer. 28 févr. 2024 à 08:03, Hervé Boutemy  a
écrit :

> Le mardi 27 février 2024, 13:32:36 CET Elliotte Rusty Harold a écrit :
> > Toolchains support using JDK 8 to compile even though JDK 17 is
> > executing Maven, which does handle this. Unfortunately toolchains are
> > poorly designed, badly documented, and not widely understood within
> > the community. I'm trying to improve some of the docs for toolchains,
> > but that only goes so far. There's a fundamental problem that
> > toolchains are incompatible with a hermetic, one click build.
>
> +1 (taking apart the "poorly designed" aspect)
>
> that's why toolchain improvement is one necessary enabler
>
> another one is plugins prerequisites history
>
> in the whole discussion, I did not find any other enabler: please chime in
> if
> you saw one
>
>
>
> -
> 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

[Hervé Boutemy]

Le lundi 26 février 2024, 13:42:19 CET Ceki Gulcu a écrit :
> Hello Bernd,
> 
> I was unaware of the capabilities of the release flag. Thank you for
> explaining.

a proof that even capabilities like --release flag from JDK 9 (JEP 247 https://
openjdk.org/jeps/247) need to be promoted because it's not sufficiently known



-
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

[Hervé Boutemy]

Le mardi 27 février 2024, 13:32:36 CET Elliotte Rusty Harold a écrit :
> Toolchains support using JDK 8 to compile even though JDK 17 is
> executing Maven, which does handle this. Unfortunately toolchains are
> poorly designed, badly documented, and not widely understood within
> the community. I'm trying to improve some of the docs for toolchains,
> but that only goes so far. There's a fundamental problem that
> toolchains are incompatible with a hermetic, one click build.

+1 (taking apart the "poorly designed" aspect)

that's why toolchain improvement is one necessary enabler

another one is plugins prerequisites history

in the whole discussion, I did not find any other enabler: please chime in if 
you saw one



-
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

[Hervé Boutemy]

Le mardi 27 février 2024, 18:33:43 CET sebb a écrit :
> On Tue, 27 Feb 2024 at 17:01, Benjamin Marwell  wrote:
> > > Compiling for Java 8 with
> > > Java 17 -release 8 is not the same as compiling with javac from JDK 8.
> > > They do not produce the same byte code.
+1 that's a fact

> > > There is a need to compile *with* JDK 8, not just compile *for* JDK 8.
I'd also add: do you also expect to run the unit and integration tests with JDK 
8?
could running be decoupled from compiling?

> > 
> > And when would that be needed?
I'd say it's a question of taste/aversion to risk: I personally fully trust JDK 
17 --release 8 to not produce anything wrong against JDK 8, but some may not 
trust
That's why I personally would accept building with JDK 17 --release 8 but would 
like to run UT/ITs with JDK 8

> 
> Isn't that needed for reproducible builds?

simply no

one concrete example from so many, just picking a random one: plexus-utils, 
that targets Java 8 bytecode 
https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/codehaus/plexus/plexus-utils/README.md

as you can see, some releases were done with JDK 11, some with JDK 17, some on 
*nix and others on Windows
Each is reproducible, even if the required environment to get the same binaries 
as the reference published to Maven Central for each is different

while at it, I'll add:
this does not mean that for each release, any environment different from the 
reference one gives a bad output;
it just gives a different binary that is expected to be functionnally 
equivalent = what we blindly trusted before we checked binaries



-
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

[Xeno Amess]

> people will be able to work on solutions after anyway.
Agreed as they can maintain a fork anyway if they really need.

From: Romain Manni-Bucau 
Sent: Wednesday, February 28, 2024 3:50:31 AM
To: Maven Developers List 
Subject: Re: [DISCUSS] Java version for Maven

Plain standard asf votes - or under the vote manager rules as allowed by
asf if it is agreed but means another discussion.

I dont care much the details but keeping energy for this thread starts to
be more negative on the community than anything positive IMHO so hope we
close it with a decision then move on.
Not everybody will be happy but we'll stop cycles hopefully and unhappy
people will be able to work on solutions after anyway.

Le mar. 27 févr. 2024 à 20:02, Aleksandar Kurtakov  a
écrit :

> On Tue, Feb 27, 2024 at 8:16 PM Xeno Amess  wrote:
>
> > whose vote would count and what be the majority:)
> > for example should my vote count? or not?
> > or just some committers? but why just committers(or not)(as some of them
> > might have less contributions even than non-committers)?
> > or just pmc?
> > or everyone share 1 vote(wow I don't think it shall work this way)
> >
>
> This is something that should be defined by Apache Foundation and/or Maven
> PMC. I don't plan to neither dive into the discussion more nor to try
> imposing our rules on another project.
> If the project believes that continuing such discussion in circles brings
> anything good - so be it.
>
>
>
> >
> >
> > Aleksandar Kurtakov  于2024年2月28日周三 01:15写道：
> >
> > > On Tue, Feb 27, 2024 at 6:13 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Not sure we'll converge guys but shouldnt we make a vote? Seems we
> all
> > > > understand the impacts technically so maybe time to decide else we'll
> > > still
> > > > be there in a year.
> > > >
> > >
> > > This is exactly what I try in the Eclipse community - vote, majority
> wins
> > > and move on.
> > > If there is one thing I'm 100% sure now is that no one from one camp
> will
> > > convince someone from the other camp so all the endless discussions
> bring
> > > only extra stress.
> > >
> > >
> > > >
> > > > Le mar. 27 févr. 2024 à 16:41, John Neffenger  a
> > > écrit :
> > > >
> > > > > On 2/26/24 11:42 AM, Basil Crow wrote:
> > > > > > We had a similar conversation in the Jenkins community, and I
> wrote
> > > up
> > > > > > our conclusions here:
> > > > >
> > > > > We also had a similar conversation in the NetBeans community, with
> > the
> > > > > final vote to drop JDK 8 (vote result: 20 to 1.5). See here:
> > > > >
> > > > > [VOTE][RESULT] Minimum JDK build and run policy (dropping JDK 8)
> > > > > https://lists.apache.org/thread/oq8bof3owctq0ot6xwk03n3w45d09zcc
> > > > >
> > > > > In particular, see the comments from James Gosling:
> > > > >
> > > > > Re: Lets talk about JDK 8 (new year edition)
> > > > > https://lists.apache.org/thread/sspm6fy1xq0jn2k8lfprn47v69g88jvh
> > > > >
> > > > >"So….  In my opinion, JDK8 must die."
> > > > >"Stop the unholy contortions to coexist.  Kill it.  Nail its
> > coffin
> > > > > closed.  Do not look back."
> > > > >
> > > > > I couldn't agree more. :-)
> > > > >
> > > > > John
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Aleksandar Kurtakov
> > > Red Hat Eclipse Team
> > >
> >
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
>

Re: [DISCUSS] Java version for Maven

[Romain Manni-Bucau]

Plain standard asf votes - or under the vote manager rules as allowed by
asf if it is agreed but means another discussion.

I dont care much the details but keeping energy for this thread starts to
be more negative on the community than anything positive IMHO so hope we
close it with a decision then move on.
Not everybody will be happy but we'll stop cycles hopefully and unhappy
people will be able to work on solutions after anyway.

Le mar. 27 févr. 2024 à 20:02, Aleksandar Kurtakov  a
écrit :

> On Tue, Feb 27, 2024 at 8:16 PM Xeno Amess  wrote:
>
> > whose vote would count and what be the majority:)
> > for example should my vote count? or not?
> > or just some committers? but why just committers(or not)(as some of them
> > might have less contributions even than non-committers)?
> > or just pmc?
> > or everyone share 1 vote(wow I don't think it shall work this way)
> >
>
> This is something that should be defined by Apache Foundation and/or Maven
> PMC. I don't plan to neither dive into the discussion more nor to try
> imposing our rules on another project.
> If the project believes that continuing such discussion in circles brings
> anything good - so be it.
>
>
>
> >
> >
> > Aleksandar Kurtakov  于2024年2月28日周三 01:15写道：
> >
> > > On Tue, Feb 27, 2024 at 6:13 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Not sure we'll converge guys but shouldnt we make a vote? Seems we
> all
> > > > understand the impacts technically so maybe time to decide else we'll
> > > still
> > > > be there in a year.
> > > >
> > >
> > > This is exactly what I try in the Eclipse community - vote, majority
> wins
> > > and move on.
> > > If there is one thing I'm 100% sure now is that no one from one camp
> will
> > > convince someone from the other camp so all the endless discussions
> bring
> > > only extra stress.
> > >
> > >
> > > >
> > > > Le mar. 27 févr. 2024 à 16:41, John Neffenger  a
> > > écrit :
> > > >
> > > > > On 2/26/24 11:42 AM, Basil Crow wrote:
> > > > > > We had a similar conversation in the Jenkins community, and I
> wrote
> > > up
> > > > > > our conclusions here:
> > > > >
> > > > > We also had a similar conversation in the NetBeans community, with
> > the
> > > > > final vote to drop JDK 8 (vote result: 20 to 1.5). See here:
> > > > >
> > > > > [VOTE][RESULT] Minimum JDK build and run policy (dropping JDK 8)
> > > > > https://lists.apache.org/thread/oq8bof3owctq0ot6xwk03n3w45d09zcc
> > > > >
> > > > > In particular, see the comments from James Gosling:
> > > > >
> > > > > Re: Lets talk about JDK 8 (new year edition)
> > > > > https://lists.apache.org/thread/sspm6fy1xq0jn2k8lfprn47v69g88jvh
> > > > >
> > > > >"So….  In my opinion, JDK8 must die."
> > > > >"Stop the unholy contortions to coexist.  Kill it.  Nail its
> > coffin
> > > > > closed.  Do not look back."
> > > > >
> > > > > I couldn't agree more. :-)
> > > > >
> > > > > John
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Aleksandar Kurtakov
> > > Red Hat Eclipse Team
> > >
> >
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
>

Re: [DISCUSS] Java version for Maven

[Aleksandar Kurtakov]

On Tue, Feb 27, 2024 at 8:16 PM Xeno Amess  wrote:

> whose vote would count and what be the majority:)
> for example should my vote count? or not?
> or just some committers? but why just committers(or not)(as some of them
> might have less contributions even than non-committers)?
> or just pmc?
> or everyone share 1 vote(wow I don't think it shall work this way)
>

This is something that should be defined by Apache Foundation and/or Maven
PMC. I don't plan to neither dive into the discussion more nor to try
imposing our rules on another project.
If the project believes that continuing such discussion in circles brings
anything good - so be it.



>
>
> Aleksandar Kurtakov  于2024年2月28日周三 01:15写道：
>
> > On Tue, Feb 27, 2024 at 6:13 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Not sure we'll converge guys but shouldnt we make a vote? Seems we all
> > > understand the impacts technically so maybe time to decide else we'll
> > still
> > > be there in a year.
> > >
> >
> > This is exactly what I try in the Eclipse community - vote, majority wins
> > and move on.
> > If there is one thing I'm 100% sure now is that no one from one camp will
> > convince someone from the other camp so all the endless discussions bring
> > only extra stress.
> >
> >
> > >
> > > Le mar. 27 févr. 2024 à 16:41, John Neffenger  a
> > écrit :
> > >
> > > > On 2/26/24 11:42 AM, Basil Crow wrote:
> > > > > We had a similar conversation in the Jenkins community, and I wrote
> > up
> > > > > our conclusions here:
> > > >
> > > > We also had a similar conversation in the NetBeans community, with
> the
> > > > final vote to drop JDK 8 (vote result: 20 to 1.5). See here:
> > > >
> > > > [VOTE][RESULT] Minimum JDK build and run policy (dropping JDK 8)
> > > > https://lists.apache.org/thread/oq8bof3owctq0ot6xwk03n3w45d09zcc
> > > >
> > > > In particular, see the comments from James Gosling:
> > > >
> > > > Re: Lets talk about JDK 8 (new year edition)
> > > > https://lists.apache.org/thread/sspm6fy1xq0jn2k8lfprn47v69g88jvh
> > > >
> > > >"So….  In my opinion, JDK8 must die."
> > > >"Stop the unholy contortions to coexist.  Kill it.  Nail its
> coffin
> > > > closed.  Do not look back."
> > > >
> > > > I couldn't agree more. :-)
> > > >
> > > > John
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > Aleksandar Kurtakov
> > Red Hat Eclipse Team
> >
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team

Re: [DISCUSS] Java version for Maven

[Xeno Amess]

whose vote would count and what be the majority:)
for example should my vote count? or not?
or just some committers? but why just committers(or not)(as some of them
might have less contributions even than non-committers)?
or just pmc?
or everyone share 1 vote(wow I don't think it shall work this way)


Aleksandar Kurtakov  于2024年2月28日周三 01:15写道：

> On Tue, Feb 27, 2024 at 6:13 PM Romain Manni-Bucau 
> wrote:
>
> > Not sure we'll converge guys but shouldnt we make a vote? Seems we all
> > understand the impacts technically so maybe time to decide else we'll
> still
> > be there in a year.
> >
>
> This is exactly what I try in the Eclipse community - vote, majority wins
> and move on.
> If there is one thing I'm 100% sure now is that no one from one camp will
> convince someone from the other camp so all the endless discussions bring
> only extra stress.
>
>
> >
> > Le mar. 27 févr. 2024 à 16:41, John Neffenger  a
> écrit :
> >
> > > On 2/26/24 11:42 AM, Basil Crow wrote:
> > > > We had a similar conversation in the Jenkins community, and I wrote
> up
> > > > our conclusions here:
> > >
> > > We also had a similar conversation in the NetBeans community, with the
> > > final vote to drop JDK 8 (vote result: 20 to 1.5). See here:
> > >
> > > [VOTE][RESULT] Minimum JDK build and run policy (dropping JDK 8)
> > > https://lists.apache.org/thread/oq8bof3owctq0ot6xwk03n3w45d09zcc
> > >
> > > In particular, see the comments from James Gosling:
> > >
> > > Re: Lets talk about JDK 8 (new year edition)
> > > https://lists.apache.org/thread/sspm6fy1xq0jn2k8lfprn47v69g88jvh
> > >
> > >"So….  In my opinion, JDK8 must die."
> > >"Stop the unholy contortions to coexist.  Kill it.  Nail its coffin
> > > closed.  Do not look back."
> > >
> > > I couldn't agree more. :-)
> > >
> > > John
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
>

Re: [DISCUSS] Java version for Maven

[sebb]

On Tue, 27 Feb 2024 at 17:01, Benjamin Marwell  wrote:
>
> > Compiling for Java 8 with
> > Java 17 -release 8 is not the same as compiling with javac from JDK 8.
> > They do not produce the same byte code. There is a need to compile
> > *with* JDK 8, not just compile *for* JDK 8.
>
> And when would that be needed?

Isn't that needed for reproducible builds?

>
> On Tue, 27 Feb 2024, 13:33 Elliotte Rusty Harold, 
> wrote:
>
> > On Mon, Feb 26, 2024 at 7:24 PM Benjamin Marwell 
> > wrote:
> > >
> > > > 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.
> > >
> >
> > No, that's not the point. You are claiming that #1 and #2 are the
> > same. I do not believe they are the same. Compiling for Java 8 with
> > Java 17 -release 8 is not the same as compiling with javac from JDK 8.
> > They do not produce the same byte code. There is a need to compile
> > *with* JDK 8, not just compile *for* JDK 8.
> >
> > Toolchains support using JDK 8 to compile even though JDK 17 is
> > executing Maven, which does handle this. Unfortunately toolchains are
> > poorly designed, badly documented, and not widely understood within
> > the community. I'm trying to improve some of the docs for toolchains,
> > but that only goes so far. There's a fundamental problem that
> > toolchains are incompatible with a hermetic, one click build.
> >
> > --
> > 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

Re: [DISCUSS] Java version for Maven

[Aleksandar Kurtakov]

On Tue, Feb 27, 2024 at 6:13 PM Romain Manni-Bucau 
wrote:

> Not sure we'll converge guys but shouldnt we make a vote? Seems we all
> understand the impacts technically so maybe time to decide else we'll still
> be there in a year.
>

This is exactly what I try in the Eclipse community - vote, majority wins
and move on.
If there is one thing I'm 100% sure now is that no one from one camp will
convince someone from the other camp so all the endless discussions bring
only extra stress.


>
> Le mar. 27 févr. 2024 à 16:41, John Neffenger  a écrit :
>
> > On 2/26/24 11:42 AM, Basil Crow wrote:
> > > We had a similar conversation in the Jenkins community, and I wrote up
> > > our conclusions here:
> >
> > We also had a similar conversation in the NetBeans community, with the
> > final vote to drop JDK 8 (vote result: 20 to 1.5). See here:
> >
> > [VOTE][RESULT] Minimum JDK build and run policy (dropping JDK 8)
> > https://lists.apache.org/thread/oq8bof3owctq0ot6xwk03n3w45d09zcc
> >
> > In particular, see the comments from James Gosling:
> >
> > Re: Lets talk about JDK 8 (new year edition)
> > https://lists.apache.org/thread/sspm6fy1xq0jn2k8lfprn47v69g88jvh
> >
> >"So….  In my opinion, JDK8 must die."
> >"Stop the unholy contortions to coexist.  Kill it.  Nail its coffin
> > closed.  Do not look back."
> >
> > I couldn't agree more. :-)
> >
> > John
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team

Re: [DISCUSS] Java version for Maven

[Benjamin Marwell]

> Compiling for Java 8 with
> Java 17 -release 8 is not the same as compiling with javac from JDK 8.
> They do not produce the same byte code. There is a need to compile
> *with* JDK 8, not just compile *for* JDK 8.

And when would that be needed?


On Tue, 27 Feb 2024, 13:33 Elliotte Rusty Harold, 
wrote:

> On Mon, Feb 26, 2024 at 7:24 PM Benjamin Marwell 
> wrote:
> >
> > > 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.
> >
>
> No, that's not the point. You are claiming that #1 and #2 are the
> same. I do not believe they are the same. Compiling for Java 8 with
> Java 17 -release 8 is not the same as compiling with javac from JDK 8.
> They do not produce the same byte code. There is a need to compile
> *with* JDK 8, not just compile *for* JDK 8.
>
> Toolchains support using JDK 8 to compile even though JDK 17 is
> executing Maven, which does handle this. Unfortunately toolchains are
> poorly designed, badly documented, and not widely understood within
> the community. I'm trying to improve some of the docs for toolchains,
> but that only goes so far. There's a fundamental problem that
> toolchains are incompatible with a hermetic, one click build.
>
> --
> 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
>
>

Re: [DISCUSS] Java version for Maven

[Romain Manni-Bucau]

Not sure we'll converge guys but shouldnt we make a vote? Seems we all
understand the impacts technically so maybe time to decide else we'll still
be there in a year.

Le mar. 27 févr. 2024 à 16:41, John Neffenger  a écrit :

> On 2/26/24 11:42 AM, Basil Crow wrote:
> > We had a similar conversation in the Jenkins community, and I wrote up
> > our conclusions here:
>
> We also had a similar conversation in the NetBeans community, with the
> final vote to drop JDK 8 (vote result: 20 to 1.5). See here:
>
> [VOTE][RESULT] Minimum JDK build and run policy (dropping JDK 8)
> https://lists.apache.org/thread/oq8bof3owctq0ot6xwk03n3w45d09zcc
>
> In particular, see the comments from James Gosling:
>
> Re: Lets talk about JDK 8 (new year edition)
> https://lists.apache.org/thread/sspm6fy1xq0jn2k8lfprn47v69g88jvh
>
>"So….  In my opinion, JDK8 must die."
>"Stop the unholy contortions to coexist.  Kill it.  Nail its coffin
> closed.  Do not look back."
>
> I couldn't agree more. :-)
>
> John
>
> -
> 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

[John Neffenger]

On 2/26/24 11:42 AM, Basil Crow wrote:

We had a similar conversation in the Jenkins community, and I wrote up
our conclusions here:


We also had a similar conversation in the NetBeans community, with the 
final vote to drop JDK 8 (vote result: 20 to 1.5). See here:


[VOTE][RESULT] Minimum JDK build and run policy (dropping JDK 8)
https://lists.apache.org/thread/oq8bof3owctq0ot6xwk03n3w45d09zcc

In particular, see the comments from James Gosling:

Re: Lets talk about JDK 8 (new year edition)
https://lists.apache.org/thread/sspm6fy1xq0jn2k8lfprn47v69g88jvh

  "So….  In my opinion, JDK8 must die."
  "Stop the unholy contortions to coexist.  Kill it.  Nail its coffin 
closed.  Do not look back."


I couldn't agree more. :-)

John

-
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

[Ceki Gulcu]

On 2/25/2024, 2:49 PM Elliotte Rusty Harold wrote:


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


On 2/26/2024 8:22 PM, Benjamin Marwell wrote:


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

I wrote about 6 or 7 paragraphs of word salad to essentially convey the
same message as Benjamin.

If the goal is verification of the artifact with respect to the code in
the software repo, the verifier needs the same JDK version as the
version used to produce the artifact being checked in order to compare
binaries. The Java version can be any Java version and only depends on
the producer of the artifact (the owner of the artifact). Obviously,
this Java version needs to be equal or higher than the "release"
version, but that is it.

Claiming that if the release version is 8, the Java version must also be
8 seems quite incorrect.


-- 
Ceki Gülcü

Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

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

On Tue, Feb 27, 2024 at 1:33 PM Elliotte Rusty Harold 
wrote:

> but that only goes so far. There's a fundamental problem that
> toolchains are incompatible with a hermetic, one click build.
>
>
Why so? Could you elaborate?

T





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

Re: [DISCUSS] Java version for Maven

[Elliotte Rusty Harold]

On Mon, Feb 26, 2024 at 7:24 PM Benjamin Marwell  wrote:
>
> > 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.
>

No, that's not the point. You are claiming that #1 and #2 are the
same. I do not believe they are the same. Compiling for Java 8 with
Java 17 -release 8 is not the same as compiling with javac from JDK 8.
They do not produce the same byte code. There is a need to compile
*with* JDK 8, not just compile *for* JDK 8.

Toolchains support using JDK 8 to compile even though JDK 17 is
executing Maven, which does handle this. Unfortunately toolchains are
poorly designed, badly documented, and not widely understood within
the community. I'm trying to improve some of the docs for toolchains,
but that only goes so far. There's a fundamental problem that
toolchains are incompatible with a hermetic, one click build.

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

Re: [DISCUSS] Java version for Maven

[Basil Crow]

We had a similar conversation in the Jenkins community, and I wrote up
our conclusions here:

https://www.jenkins.io/blog/2023/11/06/introducing-2-2-2-java-support-plan/

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

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

Re: [DISCUSS] Java version for Maven

[Ceki Gulcu]

Hello Bernd,

I was unaware of the capabilities of the release flag. Thank you for
explaining.

-- 
Ceki Gülcü

Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

On 2/25/2024 1:37 AM, Bernd Eckenfels wrote:
> It has been mentioned before, but just to add, since the bytecode
> level is IMHO the smallest problem:
> 
> Jorge Solórzano wrote on 25. Feb 2024 00:41 (GMT +01:00):
>> you can use JDK 17 to produce Java 8 bytecode using Java 8
>> features, that is the distinction I made between runtime and build time,
>> but it looks it's still not clear.
> 
> In the past a newer JDK version could compile for an older Bytecode version 
> and
> compatible with the source code constructs, BUT it used its own classlibrary 
> which
> had usually different method and therefore create NON-compat results. For that
> reason you had to provide the old bootpath if you wanted a clean build (or, 
> since this
> Is nearly the same work than just using the old JDK always use the same 
> build/target
> Version, this was very typical for java7 builds and many think it is needed 
> for 8 as well).
> 
> But, this is no longer a problem since Java9, the new -release option does 
> not only simplify
> -source and -target into a single option it additionally makes the Java 
> compiler use an
> internal list of approved JCL signatures, therefore being save for cross 
> compile (only
> If you switch to the new flag).
> 
> Unfortunatelly -release 8 has still problems with removed libraries, so it is 
> a bit of a
> work to use newer JDKs to compile old codebase (not a drop-in in some cases 
> like jaxb).
> 
> Btw Java8 POMs are a bit annoying since you can’t build them on Java 8
> With maven.compiler.release and you can’t (should not) build them on 9+ with
> maven.compiler.target. Luckily you can solve that with a profile activated by 
> runtime version.
> https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-release.html
> 
> Gruß
> Bernd
> — 
> https://bernd.eckenfels.net
> 


-
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

[Elliotte Rusty Harold]

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

Re: [DISCUSS] Java version for Maven

[Karl Heinz Marbaise]

On 24.02.24 23:42, Jorge Solórzano 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.


Yes true, but I don't want to make their problems to our problems.

If they are stuck to JDK 8 they can use Maven 3.9.X problem solved.



The Java ecosystem is moving forward and Maven should not get stuck with a
10 years old JDK version.


Yes I agree here.



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.*


As Tamas already asked why 3.10.. 3.9.6 is already JDK 8..




*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.


newer JDK version are not stable? and as I mentioned before I don't want
to make their problem to our problem...If they are stuck with JDK 8 use
Maven 3.X done.




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.


An LTS version of Maven? Who should support that ? In which way ? such
thing will have a big impact on the project meaning someone (or maybe
more than one person) has to do work on that to support old state... If
an enterprise wants to have that support they should start to pay for
that support... enterprise level support without paying... I would say
no to that...



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.


Same as before...

In particular this: "expect timely security patches to " who can
guarantee that? We are an open source project... you can not force
anyone in the project to work on particular issue at a particular time..




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.


They can stuck at Maven 3.9.X with JDK 8 ... so no problem at all.




*Advantages of Maven 4.0 (Targeting Java 17):*


My suggesting here is JDK21... because JDK 17 is also older version...
and Maven 4 GA is not yet there which is fine.. so we are talking about
the future...



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.


JDK 21 even more ...virtual threads for example could be an interesting
thing for many things in Maven itself but that is a different story.



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.


what are modern dev practices related to a JDK version?


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.


JDK 21 will 

Re: [DISCUSS] Java version for Maven

[Bernd Eckenfels]

It has been mentioned before, but just to add, since the bytecode
level is IMHO the smallest problem:

Jorge Solórzano wrote on 25. Feb 2024 00:41 (GMT +01:00):
> you can use JDK 17 to produce Java 8 bytecode using Java 8
> features, that is the distinction I made between runtime and build time,
> but it looks it's still not clear.

In the past a newer JDK version could compile for an older Bytecode version and
compatible with the source code constructs, BUT it used its own classlibrary 
which
had usually different method and therefore create NON-compat results. For that
reason you had to provide the old bootpath if you wanted a clean build (or, 
since this
Is nearly the same work than just using the old JDK always use the same 
build/target
Version, this was very typical for java7 builds and many think it is needed for 
8 as well).

But, this is no longer a problem since Java9, the new -release option does not 
only simplify
-source and -target into a single option it additionally makes the Java 
compiler use an
internal list of approved JCL signatures, therefore being save for cross 
compile (only
If you switch to the new flag).

Unfortunatelly -release 8 has still problems with removed libraries, so it is a 
bit of a
work to use newer JDKs to compile old codebase (not a drop-in in some cases 
like jaxb).

Btw Java8 POMs are a bit annoying since you can’t build them on Java 8
With maven.compiler.release and you can’t (should not) build them on 9+ with
maven.compiler.target. Luckily you can solve that with a profile activated by 
runtime version.
https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-release.html

Gruß
Bernd
— 
https://bernd.eckenfels.net

-
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

[Jorge Solórzano]

On Sat, Feb 24, 2024, 17:24 Hunter C Payne
 wrote:

>  Is a JDK 17 capable of building JDK 8 jars from JDK 17 source?


No, it doesn't, you can use JDK 17 to produce Java 8 bytecode using Java 8
features, that is the distinction I made between runtime and build time,
but it looks it's still not clear.

To use Java 17 features, you need to produce Java 17 bytecode, and that
requires at least Java 17 as runtime.

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

Re: [DISCUSS] Java version for Maven

[Hunter C Payne]

 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 
 wrote:  
 
 On Sat, Feb 24, 2024, 16:55 Tamás Cservenák  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  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
> 

Re: [DISCUSS] Java version for Maven

[Jorge Solórzano]

On Sat, Feb 24, 2024, 16:55 Tamás Cservenák  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  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 

Re: [DISCUSS] Java version for Maven

[Bernd Eckenfels]

Hello,

thanks Jorge I fully support your summary.

 want to bring an additional points in support for newer runtime Java: Because 
Maven alone isn’t the complete ecosystem and many other tools have higher 
requirements already. Fr example both Jenkins (maven-style jobs) as well as 
SonarQube scanner plugins can’t be used with Java 8 anymore.

And yes such a shift was not only for those big tech-Gigants which are stuck on 
Java8 a pain, but also for many other users - but this is in the past. Most 
have migrated to be finally able to use the -release option as a quality of 
life improvement even though they have to target Java 8 Bytecode level.

I think there is absolutely no problem to move along with a new major version 
of maven, in fact it’s the only sane moment to do so. I am sure many plug-in 
authors are eager to raise their minimum version just to be able to use new 
external technologies. And if the whole ecosystem understands there is a 3.d 
and 4.x branch, the better…

Gruss
Bernd

Jorge Solórzano wrote on 24. Feb 2024 23:42 (GMT +01:00):

> 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.
— 
https://bernd.eckenfels.net

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

Jorge,

Allow me one question: why would we need 3.10 for this? Could not we set
same thing for existing 3.9.x?

T




On Sat, Feb 24, 2024, 23:43 Jorge Solórzano  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 

Re: [DISCUSS] Java version for Maven

[Jorge Solórzano]

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.

   

Re: [DISCUSS] Java version for Maven

[Xeno Amess]

Yep you got a point, I hate streams either.(especially when using streams
be not necessary.)

Romain Manni-Bucau  于2024年2月23日周五 22:43写道：

> From my experience people hating var will also hate completionstage and at
> some point streams (or they willfully embrace them just using forEach which
> is a counter usage IMHO).
> Every time I digged it was 100% a knowledge+(IT) culture thing.
> But once again, I'm not sure it is about us - if so I would say I don't
> care much - but how attracting we can be since our community is not crazy
> active outside.
>
> This is for an an opportunity we should take IMHO.
>
> Now if we just want to speak about style and lib usage I guess we have
> enough threads showing we all diverge so not sure there is a way to
> converge anytime - nor the need to be honest.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 23 févr. 2024 à 15:10, Tamás Cservenák  a
> écrit :
>
> > Make love not var!
> >
> > T
> >
> > On Fri, Feb 23, 2024 at 3:09 PM Xeno Amess  wrote:
> >
> > > I hate var.
> > > ____________
> > > From: Tamás Cservenák 
> > > Sent: Friday, February 23, 2024 9:52:08 PM
> > > To: Maven Developers List 
> > > Subject: Re: [DISCUSS] Java version for Maven
> > >
> > > Howdy,
> > >
> > > Some more stats based on 2nd package from Brian
> > >
> > > https://gist.github.com/cstamas/8207f8d70882090a1c63cdedc256ec56
> > >
> > > On Fri, Feb 23, 2024 at 2:08 PM Elliotte Rusty Harold <
> > elh...@ibiblio.org>
> > > wrote:
> > >
> > > > Yes, with var you still get type checks, unlike in Python. But I have
> > > > wasted so much time debugging Python code simply because the type of
> a
> > > > local variable wasn't right there in the declaration that I remain
> > > > unconvinced var was ever a good idea. I have been convinced by
> > > > experience that implicitly typed local variables dramatically reduce
> > > > debugging speed. This isn't something I believed two years ago. Back
> > > > then I mostly didn't think about it. But since then I have worked a
> > > > lot with implicit typing, and it is painful.
> > > >
> > > > IDEs are not a full solution. They're better in Java than Python, I
> > > > admit, but I spend more time reading code in tools like Github and
> > > > Critique than in IDEs.
> > > >
> > > > I don't think banning var goes against the community in any way. It's
> > > > simply another style choice for improved readability and
> > > > maintainability, like everything spotless and checkstyle currently
> do.
> > > >
> > > >
> > > > On Fri, Feb 23, 2024 at 12:58 PM Romain Manni-Bucau
> > > >  wrote:
> > > > >
> > > > > Le ven. 23 févr. 2024 à 13:44, Elliotte Rusty Harold <
> > > elh...@ibiblio.org>
> > > > a
> > > > > écrit :
> > > > >
> > > > > > On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau
> > > > > >  wrote:
> > > > > > >
> > > > > > > @Elliotte while you are pretty right in terms of *compile*
> > features
> > > > but
> > > > > > it
> > > > > > > ignores the biggest criteria for any ASF project : the
> community.
> > > > Even if
> > > > > > > silly, attracting people with Java 8 is born dead today (to
> > > > illustrate it
> > > > > > > just ask somebody to no more use "var" to do a PR for ex, he
> will
> > > > start
> > > > > > to
> > > > > > > "pf" ;)).
> > > > > >
> > > > > > Going off on a tangent but I would reject any PR that showed up
> in
> > my
> > > > > > code review queue that used "var", regardless of JDK version.
> It's
> > an
> > > > > > abomination that should never have been added to Java. It
> > prioritizes
> > > > > > a trivial speed up in writing code at the cost of a signifi

Re: [DISCUSS] Java version for Maven

[Romain Manni-Bucau]

>From my experience people hating var will also hate completionstage and at
some point streams (or they willfully embrace them just using forEach which
is a counter usage IMHO).
Every time I digged it was 100% a knowledge+(IT) culture thing.
But once again, I'm not sure it is about us - if so I would say I don't
care much - but how attracting we can be since our community is not crazy
active outside.

This is for an an opportunity we should take IMHO.

Now if we just want to speak about style and lib usage I guess we have
enough threads showing we all diverge so not sure there is a way to
converge anytime - nor the need to be honest.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 23 févr. 2024 à 15:10, Tamás Cservenák  a
écrit :

> Make love not var!
>
> T
>
> On Fri, Feb 23, 2024 at 3:09 PM Xeno Amess  wrote:
>
> > I hate var.
> > 
> > From: Tamás Cservenák 
> > Sent: Friday, February 23, 2024 9:52:08 PM
> > To: Maven Developers List 
> > Subject: Re: [DISCUSS] Java version for Maven
> >
> > Howdy,
> >
> > Some more stats based on 2nd package from Brian
> >
> > https://gist.github.com/cstamas/8207f8d70882090a1c63cdedc256ec56
> >
> > On Fri, Feb 23, 2024 at 2:08 PM Elliotte Rusty Harold <
> elh...@ibiblio.org>
> > wrote:
> >
> > > Yes, with var you still get type checks, unlike in Python. But I have
> > > wasted so much time debugging Python code simply because the type of a
> > > local variable wasn't right there in the declaration that I remain
> > > unconvinced var was ever a good idea. I have been convinced by
> > > experience that implicitly typed local variables dramatically reduce
> > > debugging speed. This isn't something I believed two years ago. Back
> > > then I mostly didn't think about it. But since then I have worked a
> > > lot with implicit typing, and it is painful.
> > >
> > > IDEs are not a full solution. They're better in Java than Python, I
> > > admit, but I spend more time reading code in tools like Github and
> > > Critique than in IDEs.
> > >
> > > I don't think banning var goes against the community in any way. It's
> > > simply another style choice for improved readability and
> > > maintainability, like everything spotless and checkstyle currently do.
> > >
> > >
> > > On Fri, Feb 23, 2024 at 12:58 PM Romain Manni-Bucau
> > >  wrote:
> > > >
> > > > Le ven. 23 févr. 2024 à 13:44, Elliotte Rusty Harold <
> > elh...@ibiblio.org>
> > > a
> > > > écrit :
> > > >
> > > > > On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau
> > > > >  wrote:
> > > > > >
> > > > > > @Elliotte while you are pretty right in terms of *compile*
> features
> > > but
> > > > > it
> > > > > > ignores the biggest criteria for any ASF project : the community.
> > > Even if
> > > > > > silly, attracting people with Java 8 is born dead today (to
> > > illustrate it
> > > > > > just ask somebody to no more use "var" to do a PR for ex, he will
> > > start
> > > > > to
> > > > > > "pf" ;)).
> > > > >
> > > > > Going off on a tangent but I would reject any PR that showed up in
> my
> > > > > code review queue that used "var", regardless of JDK version. It's
> an
> > > > > abomination that should never have been added to Java. It
> prioritizes
> > > > > a trivial speed up in writing code at the cost of a significant
> slow
> > > > > down in reading and debugging code. Working in Python for the last
> > > > > couple of years has thoroughly convinced me that strong, explicit
> > > > > compile time types are the right way to go. I've seen what happens
> > > > > when you don't have them, and it's not fun.
> > > > >
> > > >
> > > > I assume you never used it to write that cause you don't loose
> compile
> > > > checks, you are not slower to read nor debug but generally faster
> cause
> > > > readability is increased and if you miss

Re: [DISCUSS] Java version for Maven

[Tamás Cservenák]

Make love not var!

T

On Fri, Feb 23, 2024 at 3:09 PM Xeno Amess  wrote:

> I hate var.
> 
> From: Tamás Cservenák 
> Sent: Friday, February 23, 2024 9:52:08 PM
> To: Maven Developers List 
> Subject: Re: [DISCUSS] Java version for Maven
>
> Howdy,
>
> Some more stats based on 2nd package from Brian
>
> https://gist.github.com/cstamas/8207f8d70882090a1c63cdedc256ec56
>
> On Fri, Feb 23, 2024 at 2:08 PM Elliotte Rusty Harold 
> wrote:
>
> > Yes, with var you still get type checks, unlike in Python. But I have
> > wasted so much time debugging Python code simply because the type of a
> > local variable wasn't right there in the declaration that I remain
> > unconvinced var was ever a good idea. I have been convinced by
> > experience that implicitly typed local variables dramatically reduce
> > debugging speed. This isn't something I believed two years ago. Back
> > then I mostly didn't think about it. But since then I have worked a
> > lot with implicit typing, and it is painful.
> >
> > IDEs are not a full solution. They're better in Java than Python, I
> > admit, but I spend more time reading code in tools like Github and
> > Critique than in IDEs.
> >
> > I don't think banning var goes against the community in any way. It's
> > simply another style choice for improved readability and
> > maintainability, like everything spotless and checkstyle currently do.
> >
> >
> > On Fri, Feb 23, 2024 at 12:58 PM Romain Manni-Bucau
> >  wrote:
> > >
> > > Le ven. 23 févr. 2024 à 13:44, Elliotte Rusty Harold <
> elh...@ibiblio.org>
> > a
> > > écrit :
> > >
> > > > On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau
> > > >  wrote:
> > > > >
> > > > > @Elliotte while you are pretty right in terms of *compile* features
> > but
> > > > it
> > > > > ignores the biggest criteria for any ASF project : the community.
> > Even if
> > > > > silly, attracting people with Java 8 is born dead today (to
> > illustrate it
> > > > > just ask somebody to no more use "var" to do a PR for ex, he will
> > start
> > > > to
> > > > > "pf" ;)).
> > > >
> > > > Going off on a tangent but I would reject any PR that showed up in my
> > > > code review queue that used "var", regardless of JDK version. It's an
> > > > abomination that should never have been added to Java. It prioritizes
> > > > a trivial speed up in writing code at the cost of a significant slow
> > > > down in reading and debugging code. Working in Python for the last
> > > > couple of years has thoroughly convinced me that strong, explicit
> > > > compile time types are the right way to go. I've seen what happens
> > > > when you don't have them, and it's not fun.
> > > >
> > >
> > > I assume you never used it to write that cause you don't loose compile
> > > checks, you are not slower to read nor debug but generally faster cause
> > > readability is increased and if you miss the 35 char long type your
> > > preferred IDE will compensate that easily.
> > > It is literally similar to streams or even plain old java, it depends
> the
> > > habit of the coder but if we consider that we would also prevent
> foreach
> > > usage.
> > > You can also reverse it and write the exact same sentence on "not using
> > > var", how slow it is to read such a code where half of the chars don't
> > > bring any useful data or encourage palantir formatting to break on
> > multiple
> > > lines a single statement.
> > > So IMHO this is not something right to think nor even consider.
> > >
> > > Ultimately the point is not "do we think it is good or not", it is
> > > literally that if we go against the move then we go against the
> > community -
> > > keep in mind we should probably not be the primary citizens there - and
> > > therefore I'm not sure the point to be at Apache if we don't care about
> > our
> > > community.
> > > I'm clearly to stay there and enable people to join rather than staying
> > > alone 10 years ago (happy anniversary java 8 ;)).
> > >
> > >
> > > >
> > > > --
> > > > 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
> > > >
> > > >
> >
> >
> >
> > --
> > 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
> >
> >
>

Re: [DISCUSS] Java version for Maven

[Xeno Amess]

I hate var.

From: Tamás Cservenák 
Sent: Friday, February 23, 2024 9:52:08 PM
To: Maven Developers List 
Subject: Re: [DISCUSS] Java version for Maven

Howdy,

Some more stats based on 2nd package from Brian

https://gist.github.com/cstamas/8207f8d70882090a1c63cdedc256ec56

On Fri, Feb 23, 2024 at 2:08 PM Elliotte Rusty Harold 
wrote:

> Yes, with var you still get type checks, unlike in Python. But I have
> wasted so much time debugging Python code simply because the type of a
> local variable wasn't right there in the declaration that I remain
> unconvinced var was ever a good idea. I have been convinced by
> experience that implicitly typed local variables dramatically reduce
> debugging speed. This isn't something I believed two years ago. Back
> then I mostly didn't think about it. But since then I have worked a
> lot with implicit typing, and it is painful.
>
> IDEs are not a full solution. They're better in Java than Python, I
> admit, but I spend more time reading code in tools like Github and
> Critique than in IDEs.
>
> I don't think banning var goes against the community in any way. It's
> simply another style choice for improved readability and
> maintainability, like everything spotless and checkstyle currently do.
>
>
> On Fri, Feb 23, 2024 at 12:58 PM Romain Manni-Bucau
>  wrote:
> >
> > Le ven. 23 févr. 2024 à 13:44, Elliotte Rusty Harold 
> a
> > écrit :
> >
> > > On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau
> > >  wrote:
> > > >
> > > > @Elliotte while you are pretty right in terms of *compile* features
> but
> > > it
> > > > ignores the biggest criteria for any ASF project : the community.
> Even if
> > > > silly, attracting people with Java 8 is born dead today (to
> illustrate it
> > > > just ask somebody to no more use "var" to do a PR for ex, he will
> start
> > > to
> > > > "pf" ;)).
> > >
> > > Going off on a tangent but I would reject any PR that showed up in my
> > > code review queue that used "var", regardless of JDK version. It's an
> > > abomination that should never have been added to Java. It prioritizes
> > > a trivial speed up in writing code at the cost of a significant slow
> > > down in reading and debugging code. Working in Python for the last
> > > couple of years has thoroughly convinced me that strong, explicit
> > > compile time types are the right way to go. I've seen what happens
> > > when you don't have them, and it's not fun.
> > >
> >
> > I assume you never used it to write that cause you don't loose compile
> > checks, you are not slower to read nor debug but generally faster cause
> > readability is increased and if you miss the 35 char long type your
> > preferred IDE will compensate that easily.
> > It is literally similar to streams or even plain old java, it depends the
> > habit of the coder but if we consider that we would also prevent foreach
> > usage.
> > You can also reverse it and write the exact same sentence on "not using
> > var", how slow it is to read such a code where half of the chars don't
> > bring any useful data or encourage palantir formatting to break on
> multiple
> > lines a single statement.
> > So IMHO this is not something right to think nor even consider.
> >
> > Ultimately the point is not "do we think it is good or not", it is
> > literally that if we go against the move then we go against the
> community -
> > keep in mind we should probably not be the primary citizens there - and
> > therefore I'm not sure the point to be at Apache if we don't care about
> our
> > community.
> > I'm clearly to stay there and enable people to join rather than staying
> > alone 10 years ago (happy anniversary java 8 ;)).
> >
> >
> > >
> > > --
> > > 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
> > >
> > >
>
>
>
> --
> 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
>
>

Re: [DISCUSS] Java version for Maven

[Tamás Cservenák]

One ask for a volunteer:
We are all humans, and we all make mistakes. So I'd like to ask someone to
reproduce these results.
We should not take these for granted, as I may have missed/spoiled/broke
something.

All the data sources are in this thread (both sent by Brian).

Thanks
T

On Fri, Feb 23, 2024 at 3:02 PM Tamás Cservenák  wrote:

> Updated with 3.8.x and 3.9.x data, reload if opened
>
> T
>
> On Fri, Feb 23, 2024 at 2:52 PM Tamás Cservenák 
> wrote:
>
>> Howdy,
>>
>> Some more stats based on 2nd package from Brian
>>
>> https://gist.github.com/cstamas/8207f8d70882090a1c63cdedc256ec56
>>
>> On Fri, Feb 23, 2024 at 2:08 PM Elliotte Rusty Harold 
>> wrote:
>>
>>> Yes, with var you still get type checks, unlike in Python. But I have
>>> wasted so much time debugging Python code simply because the type of a
>>> local variable wasn't right there in the declaration that I remain
>>> unconvinced var was ever a good idea. I have been convinced by
>>> experience that implicitly typed local variables dramatically reduce
>>> debugging speed. This isn't something I believed two years ago. Back
>>> then I mostly didn't think about it. But since then I have worked a
>>> lot with implicit typing, and it is painful.
>>>
>>> IDEs are not a full solution. They're better in Java than Python, I
>>> admit, but I spend more time reading code in tools like Github and
>>> Critique than in IDEs.
>>>
>>> I don't think banning var goes against the community in any way. It's
>>> simply another style choice for improved readability and
>>> maintainability, like everything spotless and checkstyle currently do.
>>>
>>>
>>> On Fri, Feb 23, 2024 at 12:58 PM Romain Manni-Bucau
>>>  wrote:
>>> >
>>> > Le ven. 23 févr. 2024 à 13:44, Elliotte Rusty Harold <
>>> elh...@ibiblio.org> a
>>> > écrit :
>>> >
>>> > > On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau
>>> > >  wrote:
>>> > > >
>>> > > > @Elliotte while you are pretty right in terms of *compile*
>>> features but
>>> > > it
>>> > > > ignores the biggest criteria for any ASF project : the community.
>>> Even if
>>> > > > silly, attracting people with Java 8 is born dead today (to
>>> illustrate it
>>> > > > just ask somebody to no more use "var" to do a PR for ex, he will
>>> start
>>> > > to
>>> > > > "pf" ;)).
>>> > >
>>> > > Going off on a tangent but I would reject any PR that showed up in my
>>> > > code review queue that used "var", regardless of JDK version. It's an
>>> > > abomination that should never have been added to Java. It prioritizes
>>> > > a trivial speed up in writing code at the cost of a significant slow
>>> > > down in reading and debugging code. Working in Python for the last
>>> > > couple of years has thoroughly convinced me that strong, explicit
>>> > > compile time types are the right way to go. I've seen what happens
>>> > > when you don't have them, and it's not fun.
>>> > >
>>> >
>>> > I assume you never used it to write that cause you don't loose compile
>>> > checks, you are not slower to read nor debug but generally faster cause
>>> > readability is increased and if you miss the 35 char long type your
>>> > preferred IDE will compensate that easily.
>>> > It is literally similar to streams or even plain old java, it depends
>>> the
>>> > habit of the coder but if we consider that we would also prevent
>>> foreach
>>> > usage.
>>> > You can also reverse it and write the exact same sentence on "not using
>>> > var", how slow it is to read such a code where half of the chars don't
>>> > bring any useful data or encourage palantir formatting to break on
>>> multiple
>>> > lines a single statement.
>>> > So IMHO this is not something right to think nor even consider.
>>> >
>>> > Ultimately the point is not "do we think it is good or not", it is
>>> > literally that if we go against the move then we go against the
>>> community -
>>> > keep in mind we should probably not be the primary citizens there - and
>>> > therefore I'm not sure the point to be at Apache if we don't care
>>> about our
>>> > community.
>>> > I'm clearly to stay there and enable people to join rather than staying
>>> > alone 10 years ago (happy anniversary java 8 ;)).
>>> >
>>> >
>>> > >
>>> > > --
>>> > > 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
>>> > >
>>> > >
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>>

Re: [DISCUSS] Java version for Maven

[Tamás Cservenák]

Updated with 3.8.x and 3.9.x data, reload if opened

T

On Fri, Feb 23, 2024 at 2:52 PM Tamás Cservenák  wrote:

> Howdy,
>
> Some more stats based on 2nd package from Brian
>
> https://gist.github.com/cstamas/8207f8d70882090a1c63cdedc256ec56
>
> On Fri, Feb 23, 2024 at 2:08 PM Elliotte Rusty Harold 
> wrote:
>
>> Yes, with var you still get type checks, unlike in Python. But I have
>> wasted so much time debugging Python code simply because the type of a
>> local variable wasn't right there in the declaration that I remain
>> unconvinced var was ever a good idea. I have been convinced by
>> experience that implicitly typed local variables dramatically reduce
>> debugging speed. This isn't something I believed two years ago. Back
>> then I mostly didn't think about it. But since then I have worked a
>> lot with implicit typing, and it is painful.
>>
>> IDEs are not a full solution. They're better in Java than Python, I
>> admit, but I spend more time reading code in tools like Github and
>> Critique than in IDEs.
>>
>> I don't think banning var goes against the community in any way. It's
>> simply another style choice for improved readability and
>> maintainability, like everything spotless and checkstyle currently do.
>>
>>
>> On Fri, Feb 23, 2024 at 12:58 PM Romain Manni-Bucau
>>  wrote:
>> >
>> > Le ven. 23 févr. 2024 à 13:44, Elliotte Rusty Harold <
>> elh...@ibiblio.org> a
>> > écrit :
>> >
>> > > On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau
>> > >  wrote:
>> > > >
>> > > > @Elliotte while you are pretty right in terms of *compile* features
>> but
>> > > it
>> > > > ignores the biggest criteria for any ASF project : the community.
>> Even if
>> > > > silly, attracting people with Java 8 is born dead today (to
>> illustrate it
>> > > > just ask somebody to no more use "var" to do a PR for ex, he will
>> start
>> > > to
>> > > > "pf" ;)).
>> > >
>> > > Going off on a tangent but I would reject any PR that showed up in my
>> > > code review queue that used "var", regardless of JDK version. It's an
>> > > abomination that should never have been added to Java. It prioritizes
>> > > a trivial speed up in writing code at the cost of a significant slow
>> > > down in reading and debugging code. Working in Python for the last
>> > > couple of years has thoroughly convinced me that strong, explicit
>> > > compile time types are the right way to go. I've seen what happens
>> > > when you don't have them, and it's not fun.
>> > >
>> >
>> > I assume you never used it to write that cause you don't loose compile
>> > checks, you are not slower to read nor debug but generally faster cause
>> > readability is increased and if you miss the 35 char long type your
>> > preferred IDE will compensate that easily.
>> > It is literally similar to streams or even plain old java, it depends
>> the
>> > habit of the coder but if we consider that we would also prevent foreach
>> > usage.
>> > You can also reverse it and write the exact same sentence on "not using
>> > var", how slow it is to read such a code where half of the chars don't
>> > bring any useful data or encourage palantir formatting to break on
>> multiple
>> > lines a single statement.
>> > So IMHO this is not something right to think nor even consider.
>> >
>> > Ultimately the point is not "do we think it is good or not", it is
>> > literally that if we go against the move then we go against the
>> community -
>> > keep in mind we should probably not be the primary citizens there - and
>> > therefore I'm not sure the point to be at Apache if we don't care about
>> our
>> > community.
>> > I'm clearly to stay there and enable people to join rather than staying
>> > alone 10 years ago (happy anniversary java 8 ;)).
>> >
>> >
>> > >
>> > > --
>> > > 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
>> > >
>> > >
>>
>>
>>
>> --
>> 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
>>
>>

Re: [DISCUSS] Java version for Maven

[Tamás Cservenák]

Howdy,

Some more stats based on 2nd package from Brian

https://gist.github.com/cstamas/8207f8d70882090a1c63cdedc256ec56

On Fri, Feb 23, 2024 at 2:08 PM Elliotte Rusty Harold 
wrote:

> Yes, with var you still get type checks, unlike in Python. But I have
> wasted so much time debugging Python code simply because the type of a
> local variable wasn't right there in the declaration that I remain
> unconvinced var was ever a good idea. I have been convinced by
> experience that implicitly typed local variables dramatically reduce
> debugging speed. This isn't something I believed two years ago. Back
> then I mostly didn't think about it. But since then I have worked a
> lot with implicit typing, and it is painful.
>
> IDEs are not a full solution. They're better in Java than Python, I
> admit, but I spend more time reading code in tools like Github and
> Critique than in IDEs.
>
> I don't think banning var goes against the community in any way. It's
> simply another style choice for improved readability and
> maintainability, like everything spotless and checkstyle currently do.
>
>
> On Fri, Feb 23, 2024 at 12:58 PM Romain Manni-Bucau
>  wrote:
> >
> > Le ven. 23 févr. 2024 à 13:44, Elliotte Rusty Harold 
> a
> > écrit :
> >
> > > On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau
> > >  wrote:
> > > >
> > > > @Elliotte while you are pretty right in terms of *compile* features
> but
> > > it
> > > > ignores the biggest criteria for any ASF project : the community.
> Even if
> > > > silly, attracting people with Java 8 is born dead today (to
> illustrate it
> > > > just ask somebody to no more use "var" to do a PR for ex, he will
> start
> > > to
> > > > "pf" ;)).
> > >
> > > Going off on a tangent but I would reject any PR that showed up in my
> > > code review queue that used "var", regardless of JDK version. It's an
> > > abomination that should never have been added to Java. It prioritizes
> > > a trivial speed up in writing code at the cost of a significant slow
> > > down in reading and debugging code. Working in Python for the last
> > > couple of years has thoroughly convinced me that strong, explicit
> > > compile time types are the right way to go. I've seen what happens
> > > when you don't have them, and it's not fun.
> > >
> >
> > I assume you never used it to write that cause you don't loose compile
> > checks, you are not slower to read nor debug but generally faster cause
> > readability is increased and if you miss the 35 char long type your
> > preferred IDE will compensate that easily.
> > It is literally similar to streams or even plain old java, it depends the
> > habit of the coder but if we consider that we would also prevent foreach
> > usage.
> > You can also reverse it and write the exact same sentence on "not using
> > var", how slow it is to read such a code where half of the chars don't
> > bring any useful data or encourage palantir formatting to break on
> multiple
> > lines a single statement.
> > So IMHO this is not something right to think nor even consider.
> >
> > Ultimately the point is not "do we think it is good or not", it is
> > literally that if we go against the move then we go against the
> community -
> > keep in mind we should probably not be the primary citizens there - and
> > therefore I'm not sure the point to be at Apache if we don't care about
> our
> > community.
> > I'm clearly to stay there and enable people to join rather than staying
> > alone 10 years ago (happy anniversary java 8 ;)).
> >
> >
> > >
> > > --
> > > 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
> > >
> > >
>
>
>
> --
> 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
>
>

Re: [DISCUSS] Java version for Maven

[Elliotte Rusty Harold]

Yes, with var you still get type checks, unlike in Python. But I have
wasted so much time debugging Python code simply because the type of a
local variable wasn't right there in the declaration that I remain
unconvinced var was ever a good idea. I have been convinced by
experience that implicitly typed local variables dramatically reduce
debugging speed. This isn't something I believed two years ago. Back
then I mostly didn't think about it. But since then I have worked a
lot with implicit typing, and it is painful.

IDEs are not a full solution. They're better in Java than Python, I
admit, but I spend more time reading code in tools like Github and
Critique than in IDEs.

I don't think banning var goes against the community in any way. It's
simply another style choice for improved readability and
maintainability, like everything spotless and checkstyle currently do.


On Fri, Feb 23, 2024 at 12:58 PM Romain Manni-Bucau
 wrote:
>
> Le ven. 23 févr. 2024 à 13:44, Elliotte Rusty Harold  a
> écrit :
>
> > On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau
> >  wrote:
> > >
> > > @Elliotte while you are pretty right in terms of *compile* features but
> > it
> > > ignores the biggest criteria for any ASF project : the community. Even if
> > > silly, attracting people with Java 8 is born dead today (to illustrate it
> > > just ask somebody to no more use "var" to do a PR for ex, he will start
> > to
> > > "pf" ;)).
> >
> > Going off on a tangent but I would reject any PR that showed up in my
> > code review queue that used "var", regardless of JDK version. It's an
> > abomination that should never have been added to Java. It prioritizes
> > a trivial speed up in writing code at the cost of a significant slow
> > down in reading and debugging code. Working in Python for the last
> > couple of years has thoroughly convinced me that strong, explicit
> > compile time types are the right way to go. I've seen what happens
> > when you don't have them, and it's not fun.
> >
>
> I assume you never used it to write that cause you don't loose compile
> checks, you are not slower to read nor debug but generally faster cause
> readability is increased and if you miss the 35 char long type your
> preferred IDE will compensate that easily.
> It is literally similar to streams or even plain old java, it depends the
> habit of the coder but if we consider that we would also prevent foreach
> usage.
> You can also reverse it and write the exact same sentence on "not using
> var", how slow it is to read such a code where half of the chars don't
> bring any useful data or encourage palantir formatting to break on multiple
> lines a single statement.
> So IMHO this is not something right to think nor even consider.
>
> Ultimately the point is not "do we think it is good or not", it is
> literally that if we go against the move then we go against the community -
> keep in mind we should probably not be the primary citizens there - and
> therefore I'm not sure the point to be at Apache if we don't care about our
> community.
> I'm clearly to stay there and enable people to join rather than staying
> alone 10 years ago (happy anniversary java 8 ;)).
>
>
> >
> > --
> > 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
> >
> >



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

Re: [DISCUSS] Java version for Maven

[Romain Manni-Bucau]

Le ven. 23 févr. 2024 à 13:44, Elliotte Rusty Harold  a
écrit :

> On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau
>  wrote:
> >
> > @Elliotte while you are pretty right in terms of *compile* features but
> it
> > ignores the biggest criteria for any ASF project : the community. Even if
> > silly, attracting people with Java 8 is born dead today (to illustrate it
> > just ask somebody to no more use "var" to do a PR for ex, he will start
> to
> > "pf" ;)).
>
> Going off on a tangent but I would reject any PR that showed up in my
> code review queue that used "var", regardless of JDK version. It's an
> abomination that should never have been added to Java. It prioritizes
> a trivial speed up in writing code at the cost of a significant slow
> down in reading and debugging code. Working in Python for the last
> couple of years has thoroughly convinced me that strong, explicit
> compile time types are the right way to go. I've seen what happens
> when you don't have them, and it's not fun.
>

I assume you never used it to write that cause you don't loose compile
checks, you are not slower to read nor debug but generally faster cause
readability is increased and if you miss the 35 char long type your
preferred IDE will compensate that easily.
It is literally similar to streams or even plain old java, it depends the
habit of the coder but if we consider that we would also prevent foreach
usage.
You can also reverse it and write the exact same sentence on "not using
var", how slow it is to read such a code where half of the chars don't
bring any useful data or encourage palantir formatting to break on multiple
lines a single statement.
So IMHO this is not something right to think nor even consider.

Ultimately the point is not "do we think it is good or not", it is
literally that if we go against the move then we go against the community -
keep in mind we should probably not be the primary citizens there - and
therefore I'm not sure the point to be at Apache if we don't care about our
community.
I'm clearly to stay there and enable people to join rather than staying
alone 10 years ago (happy anniversary java 8 ;)).


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

Re: [DISCUSS] Java version for Maven

[Elliotte Rusty Harold]

On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau
 wrote:
>
> @Elliotte while you are pretty right in terms of *compile* features but it
> ignores the biggest criteria for any ASF project : the community. Even if
> silly, attracting people with Java 8 is born dead today (to illustrate it
> just ask somebody to no more use "var" to do a PR for ex, he will start to
> "pf" ;)).

Going off on a tangent but I would reject any PR that showed up in my
code review queue that used "var", regardless of JDK version. It's an
abomination that should never have been added to Java. It prioritizes
a trivial speed up in writing code at the cost of a significant slow
down in reading and debugging code. Working in Python for the last
couple of years has thoroughly convinced me that strong, explicit
compile time types are the right way to go. I've seen what happens
when you don't have them, and it's not fun.

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

Re: [DISCUSS] Java version for Maven

[Michael Bien]

On 23.02.24 01:42, Hunter C Payne wrote:

The performance benefits aren't provided by the compiler, they come from 
hotspot and that's the JVM version at runtime that matters there.
this is only partially correct. Many optimizations are based on 
invokedynamic which only exists post bytecode level 9.
A whole category of String related optimizations unlocks simply by 
recompiling something with --release 11 or later. Running on a more 
modern JVM without the bytecode level bump, won't help in that case.


There are also hundreds of behind the scenes optimizations which are 
unlocked for free just by using new API. For example stream.transferTo() 
is going to be not only more convenient and less error prone, but also 
likely more efficient than the dozens of stream copy variations which 
show up in projects (why? because it takes into account what exact 
streams/channels etc are involved). If you see a new method in the JDK: 
there is probably a reason why it was introduced.



That being said: in discussions like this, focusing on individual 
features is often not helpful. Since the next post will be likely about 
"I don't care about 1-10% faster/more memory efficient String 
concatenation in my CI build since at my current gig we get CI for free 
due to the geothermal power plant in the backyard".


From a birds eye view projects fall into two categories:

 a) short living projects which die on JDK X within the lifespan of JDK 
X. This is a completely valid strategy since it is often known that 
something is going to be rewritten from scratch, not needed anymore or 
replaced at some point in future.
 b) long living projects which will have to upgrade, since projects 
don't exist in a vacuum. The environment moves on, JDK X compatible 
dependencies which still get security updates will disappear at some 
point etc etc.


I would assume that it is not controversial to call maven a long living 
project. So this discussion here should be about: when is the best time 
to bump the JDK version - I would argue that maven 4 is pretty good timing!


If you want maven on JDK 8 till 2030+, I would be curious about two things:
 - why can't you use maven 3.x?
 - what exactly *should* happen after 2030+? Should maven die (is mvn 
category a) after all?)? Should there be a jump from 8 to JDK 3x and the 
community should deal with all the piled up problems all at once? Why is 
delaying this event the better strategy when compared to incremental 
steps? What is the JDK 8 exit strategy?



best regards,

-mbien

Re: [DISCUSS] Java version for Maven

[Romain Manni-Bucau]

@Elliotte while you are pretty right in terms of *compile* features but it
ignores the biggest criteria for any ASF project : the community. Even if
silly, attracting people with Java 8 is born dead today (to illustrate it
just ask somebody to no more use "var" to do a PR for ex, he will start to
"pf" ;)).
So most of the challenge here is to stay an active community and not a
dying one and using recent enough JDK is a good way to encourage it IMHO.

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



Le ven. 23 févr. 2024 à 13:15, Elliotte Rusty Harold  a
écrit :

> On Fri, Feb 23, 2024 at 12:20 AM Robert Dean  wrote:
>
> > 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. :)
>
> Given the amount of tech debt still in Maven from Maven 2 and earlier,
> I don't think shifting the JDK version is likely to have any positive
> impact or let improvements arise any faster. In fact, the opposite is
> likely true. This is a variant of the xkcd 927 problem.
>
> --
> 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
>
>

Re: [DISCUSS] Java version for Maven

[Elliotte Rusty Harold]

On Fri, Feb 23, 2024 at 12:20 AM Robert Dean  wrote:

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

Given the amount of tech debt still in Maven from Maven 2 and earlier,
I don't think shifting the JDK version is likely to have any positive
impact or let improvements arise any faster. In fact, the opposite is
likely true. This is a variant of the xkcd 927 problem.

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

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

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 

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 

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

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 

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 

Re: [DISCUSS] Java version for Maven

[Tamás Cservenák]

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 Apache Maven Compiler Plugin version 3.12.0
> >> > > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> >> > umask
> >> > > 022
> >> > >
> >> > > Wed, Nov 29, 2023, 8:16 AM
> >> > > [VOTE] Apache Maven Build Cache Extension 1.1.0
> >> > > Reproducible Build ok: reference build done on *nix with JDK 11
> >> > >
> >> > > Sun, Nov 19, 2023, 5:17 PM
> >> > > [VOTE] Release Maven Resolver 1.9.17
> >> > > Reproducible Build ok: reference build done with JDK 21 on *nix with
> >> > umask
> >> > > 022
> >> > >
> >> > > Sat, Oct 21, 2023, 4:34 PM
> >> > > VOTE] Apache Maven 4.0.0-alpha-8 release
> >> > > Reproducible Build ok: reference build done with JDK 21 on *nix with
> >> > umask
> >> > > 022
> >> > >
> >> > > Mon, Oct 2, 2023, 9:11 AM
> >> > > [VOTE] Release Apache Maven 3.9.5
> >> > > Reproducible not fully ok: reference build done with JDK 17 on *nix
> >> and
> >> > > umask 022
> >> > >
> >> > > 
> >> > >
> >> > > This CLEARLY shows the tendency:
> >> > > - Michael does releases on Java 8 (on windows!), he is a known
> >> "aligner"
> >> > > and windows person :)
> >> > > - Olivier used the "minimum" required Java version (for build
> cache).
> >> > > - Unsure why Herve used Java 11 for the Shade plugin... I mean, he
> >> could
> >> > > use 21 but also 8, but he shot for 11 that was EOL at the moment of
> >> > release.
> >> > > - The rest 

Re: [DISCUSS] Java version for Maven

[Mateusz Gajewski]

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 Apache Maven Compiler Plugin version 3.12.0
>> > > Reproducible Builds ok: reference build done on *nix with JDK 21 and
>> > umask
>> > > 022
>> > >
>> > > Wed, Nov 29, 2023, 8:16 AM
>> > > [VOTE] Apache Maven Build Cache Extension 1.1.0
>> > > Reproducible Build ok: reference build done on *nix with JDK 11
>> > >
>> > > Sun, Nov 19, 2023, 5:17 PM
>> > > [VOTE] Release Maven Resolver 1.9.17
>> > > Reproducible Build ok: reference build done with JDK 21 on *nix with
>> > umask
>> > > 022
>> > >
>> > > Sat, Oct 21, 2023, 4:34 PM
>> > > VOTE] Apache Maven 4.0.0-alpha-8 release
>> > > Reproducible Build ok: reference build done with JDK 21 on *nix with
>> > umask
>> > > 022
>> > >
>> > > Mon, Oct 2, 2023, 9:11 AM
>> > > [VOTE] Release Apache Maven 3.9.5
>> > > Reproducible not fully ok: reference build done with JDK 17 on *nix
>> and
>> > > umask 022
>> > >
>> > > 
>> > >
>> > > This CLEARLY shows the tendency:
>> > > - Michael does releases on Java 8 (on windows!), he is a known
>> "aligner"
>> > > and windows person :)
>> > > - Olivier used the "minimum" required Java version (for build cache).
>> > > - Unsure why Herve used Java 11 for the Shade plugin... I mean, he
>> could
>> > > use 21 but also 8, but he shot for 11 that was EOL at the moment of
>> > release.
>> > > - The rest is 21.
>> > >
>> > > 
>> > >
>> > > So, the question for those refusing anything other than Java 8 to
>> _run_
>> > > Maven (or to revert: for those refusing to run Maven on "latest LTS",
>> > that
>> > > is currently 21):
>> > > WHY?
>> > >
>> > >
>> > > Thanks
>> > > T
>> >
>> > -
>> > 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

[zhongming hua]

I added a piece of information: OpenJDK releases are currently pointed
to the vendor's binary address.
For example, OpenJDK17 Latest Release
(https://wiki.openjdk.org/display/JDKUpdates/JDK+17u), it points to
https://github.com/adoptium/temurin17-binaries/releases/tag/jdk-17.0.10%2B7

Tamás Cservenák  于2024年2月22日周四 07:08写道：
>
> Thanks for sharing!
>
> On Wed, Feb 21, 2024 at 11:23 PM 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 Apache Maven Compiler Plugin version 3.12.0
> >> > > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> >> > umask
> >> > > 022
> >> > >
> >> > > Wed, Nov 29, 2023, 8:16 AM
> >> > > [VOTE] Apache Maven Build Cache Extension 1.1.0
> >> > > Reproducible Build ok: reference build done on *nix with JDK 11
> >> > >
> >> > > Sun, Nov 19, 2023, 5:17 PM
> >> > > [VOTE] Release Maven Resolver 1.9.17
> >> > > Reproducible Build ok: reference build done with JDK 21 on *nix with
> >> > umask
> >> > > 022
> >> > >
> >> > > Sat, Oct 21, 2023, 4:34 PM
> >> > > VOTE] Apache Maven 4.0.0-alpha-8 release
> >> > > Reproducible Build ok: reference build done with JDK 21 on *nix with
> >> > umask
> >> > > 022
> >> > >
> >> > > Mon, Oct 2, 2023, 9:11 AM
> >> > > [VOTE] Release Apache Maven 3.9.5
> >> > > Reproducible not fully ok: reference build done with JDK 17 on *nix
> >> and
> >> > > umask 022
> >> > >
> >> > > 
> >> > >
> >> > > This CLEARLY shows the tendency:
> >> > > - Michael does releases on Java 8 (on windows!), he is a known
> >> "aligner"
> >> > > and windows person :)
> >> > > - Olivier used the "minimum" required Java version (for build cache).
> >> > > - Unsure why Herve used Java 11 for the Shade plugin... I mean, he
> >> could
> >> > > use 21 but also 8, but he shot for 11 that was EOL at the moment of
> >> > release.
> >> > > - The rest is 21.
> >> > >
> >> > > 
> >> > >
> >> > > So, the question for those refusing anything other than Java 8 to
> >> _run_
> >> > > Maven (or to revert: for those refusing to run Maven on "latest LTS",
> >> > that
> >> > > is currently 21):
> >> > > WHY?
> >> > >
> >> > >
> >> > > Thanks
> >> 

Re: [DISCUSS] Java version for Maven

[Tamás Cservenák]

Thanks for sharing!

On Wed, Feb 21, 2024 at 11:23 PM 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 Apache Maven Compiler Plugin version 3.12.0
>> > > Reproducible Builds ok: reference build done on *nix with JDK 21 and
>> > umask
>> > > 022
>> > >
>> > > Wed, Nov 29, 2023, 8:16 AM
>> > > [VOTE] Apache Maven Build Cache Extension 1.1.0
>> > > Reproducible Build ok: reference build done on *nix with JDK 11
>> > >
>> > > Sun, Nov 19, 2023, 5:17 PM
>> > > [VOTE] Release Maven Resolver 1.9.17
>> > > Reproducible Build ok: reference build done with JDK 21 on *nix with
>> > umask
>> > > 022
>> > >
>> > > Sat, Oct 21, 2023, 4:34 PM
>> > > VOTE] Apache Maven 4.0.0-alpha-8 release
>> > > Reproducible Build ok: reference build done with JDK 21 on *nix with
>> > umask
>> > > 022
>> > >
>> > > Mon, Oct 2, 2023, 9:11 AM
>> > > [VOTE] Release Apache Maven 3.9.5
>> > > Reproducible not fully ok: reference build done with JDK 17 on *nix
>> and
>> > > umask 022
>> > >
>> > > 
>> > >
>> > > This CLEARLY shows the tendency:
>> > > - Michael does releases on Java 8 (on windows!), he is a known
>> "aligner"
>> > > and windows person :)
>> > > - Olivier used the "minimum" required Java version (for build cache).
>> > > - Unsure why Herve used Java 11 for the Shade plugin... I mean, he
>> could
>> > > use 21 but also 8, but he shot for 11 that was EOL at the moment of
>> > release.
>> > > - The rest is 21.
>> > >
>> > > 
>> > >
>> > > So, the question for those refusing anything other than Java 8 to
>> _run_
>> > > Maven (or to revert: for those refusing to run Maven on "latest LTS",
>> > that
>> > > is currently 21):
>> > > WHY?
>> > >
>> > >
>> > > Thanks
>> > > T
>> >
>> > -
>> > 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]

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 Apache Maven Compiler Plugin version 3.12.0
> > > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> > umask
> > > 022
> > >
> > > Wed, Nov 29, 2023, 8:16 AM
> > > [VOTE] Apache Maven Build Cache Extension 1.1.0
> > > Reproducible Build ok: reference build done on *nix with JDK 11
> > >
> > > Sun, Nov 19, 2023, 5:17 PM
> > > [VOTE] Release Maven Resolver 1.9.17
> > > Reproducible Build ok: reference build done with JDK 21 on *nix with
> > umask
> > > 022
> > >
> > > Sat, Oct 21, 2023, 4:34 PM
> > > VOTE] Apache Maven 4.0.0-alpha-8 release
> > > Reproducible Build ok: reference build done with JDK 21 on *nix with
> > umask
> > > 022
> > >
> > > Mon, Oct 2, 2023, 9:11 AM
> > > [VOTE] Release Apache Maven 3.9.5
> > > Reproducible not fully ok: reference build done with JDK 17 on *nix and
> > > umask 022
> > >
> > > 
> > >
> > > This CLEARLY shows the tendency:
> > > - Michael does releases on Java 8 (on windows!), he is a known
> "aligner"
> > > and windows person :)
> > > - Olivier used the "minimum" required Java version (for build cache).
> > > - Unsure why Herve used Java 11 for the Shade plugin... I mean, he
> could
> > > use 21 but also 8, but he shot for 11 that was EOL at the moment of
> > release.
> > > - The rest is 21.
> > >
> > > 
> > >
> > > So, the question for those refusing anything other than Java 8 to _run_
> > > Maven (or to revert: for those refusing to run Maven on "latest LTS",
> > that
> > > is currently 21):
> > > WHY?
> > >
> > >
> > > Thanks
> > > T
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
java_version,version_count
Java 1.8.0_382,1393438
Java 17.0.10,1001367
Java 17.0.9,570622
Java 21.0.2,529117
Java 21.0.1,283869
Java 11.0.22,278228
Java 17.0.7,268306
Java 17.0.8.1,259908
Java 11.0.21,240155
Java 17.0.2,180392
Java 17.0.8,145560
Java 17.0.6,139473
Java 1.8.0_292,138687
Java 1.8.0_392,121122
Java 1.8.0_402,117920
Java 19.0.2,110573
Java 17.0.5,108176
Java 1.8.0_342,98935
Java 11.0.16,93427
Java 11.0.10,85030
Java 21,84248
Java 20.0.2,80392
Java 17.0.1,77423
Java 11.0.14.1,66802
Java 11.0.11,63485
Java 11.0.19,59590
Java 20.0.1,58030
Java 18.0.2.1,57879
Java 11.0.20,55293
Java 1.8.0_202,51614

Re: [DISCUSS] Java version for Maven

[Hunter C Payne]

 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 Apache Maven Compiler Plugin version 3.12.0
> > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> umask
> > 022
> >
> > Wed, Nov 29, 2023, 8:16 AM
> > [VOTE] Apache Maven Build Cache Extension 1.1.0
> > Reproducible Build ok: reference build done on *nix with JDK 11
> >
> > Sun, Nov 19, 2023, 5:17 PM
> > [VOTE] Release Maven Resolver 1.9.17
> > Reproducible Build ok: reference build done with JDK 21 on *nix with
> umask
> > 022
> >
> > Sat, Oct 21, 2023, 4:34 PM
> > VOTE] Apache Maven 4.0.0-alpha-8 release
> > Reproducible Build ok: reference build done with JDK 21 on *nix with
> umask
> > 022
> >
> > Mon, Oct 2, 2023, 9:11 AM
> > [VOTE] Release Apache Maven 3.9.5
> > Reproducible not fully ok: reference build done with JDK 17 on *nix and
> > umask 022
> >
> > 
> >
> > This CLEARLY shows the tendency:
> > - Michael does releases on Java 8 (on windows!), he is a known "aligner"
> > and windows person :)
> > - Olivier used the "minimum" required Java version (for build cache).
> > - Unsure why Herve used Java 11 for the Shade plugin... I mean, he could
> > use 21 but also 8, but he shot for 11 that was EOL at the moment of
> release.
> > - The rest is 21.
> >
> > 
> >
> > So, the question for those refusing anything other than Java 8 to _run_
> > Maven (or to revert: for those refusing to run Maven on "latest LTS",
> that
> > is currently 21):
> > WHY?
> >
> >
> > Thanks
> > T
>
> -
> 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]

Romain,

1) please do not talk nonsense (about dropping toolchains), as this thread
is unrelated to it (and is not gonna happen)
2) your PDF... did you _read it_? Do you really expect volunteers to
support companies WHO PAY for Java8 (to some third party, like Azul) to
support their business for free?

T

On Wed, Feb 21, 2024 at 9:47 PM 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 Apache Maven Compiler Plugin version 3.12.0
> > > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> > umask
> > > 022
> > >
> > > Wed, Nov 29, 2023, 8:16 AM
> > > [VOTE] Apache Maven Build Cache Extension 1.1.0
> > > Reproducible Build ok: reference build done on *nix with JDK 11
> > >
> > > Sun, Nov 19, 2023, 5:17 PM
> > > [VOTE] Release Maven Resolver 1.9.17
> > > Reproducible Build ok: reference build done with JDK 21 on *nix with
> > umask
> > > 022
> > >
> > > Sat, Oct 21, 2023, 4:34 PM
> > > VOTE] Apache Maven 4.0.0-alpha-8 release
> > > Reproducible Build ok: reference build done with JDK 21 on *nix with
> > umask
> > > 022
> > >
> > > Mon, Oct 2, 2023, 9:11 AM
> > > [VOTE] Release Apache Maven 3.9.5
> > > Reproducible not fully ok: reference build done with JDK 17 on *nix and
> > > umask 022
> > >
> > > 
> > >
> > > This CLEARLY shows the tendency:
> > > - Michael does releases on Java 8 (on windows!), he is a known
> "aligner"
> > > and windows person :)
> > > - Olivier used the "minimum" required Java version (for build cache).
> > > - Unsure why Herve used Java 11 for the Shade plugin... I mean, he
> could
> > > use 21 but also 8, but he shot for 11 that was EOL at the moment of
> > release.
> > > - The rest is 21.
> > >
> > > 
> > >
> > > So, the question for those refusing anything other than Java 8 to _run_
> > > Maven (or to revert: for those refusing to run Maven on "latest LTS",
> > that
> > > is currently 21):
> > > WHY?
> > >
> > >
> > > Thanks
> > > T
> >
> > -
> > 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

[Romain Manni-Bucau]

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 Apache Maven Compiler Plugin version 3.12.0
> > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> umask
> > 022
> >
> > Wed, Nov 29, 2023, 8:16 AM
> > [VOTE] Apache Maven Build Cache Extension 1.1.0
> > Reproducible Build ok: reference build done on *nix with JDK 11
> >
> > Sun, Nov 19, 2023, 5:17 PM
> > [VOTE] Release Maven Resolver 1.9.17
> > Reproducible Build ok: reference build done with JDK 21 on *nix with
> umask
> > 022
> >
> > Sat, Oct 21, 2023, 4:34 PM
> > VOTE] Apache Maven 4.0.0-alpha-8 release
> > Reproducible Build ok: reference build done with JDK 21 on *nix with
> umask
> > 022
> >
> > Mon, Oct 2, 2023, 9:11 AM
> > [VOTE] Release Apache Maven 3.9.5
> > Reproducible not fully ok: reference build done with JDK 17 on *nix and
> > umask 022
> >
> > 
> >
> > This CLEARLY shows the tendency:
> > - Michael does releases on Java 8 (on windows!), he is a known "aligner"
> > and windows person :)
> > - Olivier used the "minimum" required Java version (for build cache).
> > - Unsure why Herve used Java 11 for the Shade plugin... I mean, he could
> > use 21 but also 8, but he shot for 11 that was EOL at the moment of
> release.
> > - The rest is 21.
> >
> > 
> >
> > So, the question for those refusing anything other than Java 8 to _run_
> > Maven (or to revert: for those refusing to run Maven on "latest LTS",
> that
> > is currently 21):
> > WHY?
> >
> >
> > Thanks
> > T
>
> -
> 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

[Hunter C Payne]

 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 
 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 Apache Maven Compiler Plugin version 3.12.0
> Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
> 022
>
> Wed, Nov 29, 2023, 8:16 AM
> [VOTE] Apache Maven Build Cache Extension 1.1.0
> Reproducible Build ok: reference build done on *nix with JDK 11
>
> Sun, Nov 19, 2023, 5:17 PM
> [VOTE] Release Maven Resolver 1.9.17
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
>
> Sat, Oct 21, 2023, 4:34 PM
> VOTE] Apache Maven 4.0.0-alpha-8 release
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
>
> Mon, Oct 2, 2023, 9:11 AM
> [VOTE] Release Apache Maven 3.9.5
> Reproducible not fully ok: reference build done with JDK 17 on *nix and
> umask 022
>
> 
>
> This CLEARLY shows the tendency:
> - Michael does releases on Java 8 (on windows!), he is a known "aligner"
> and windows person :)
> - Olivier used the "minimum" required Java version (for build cache).
> - Unsure why Herve used Java 11 for the Shade plugin... I mean, he could
> use 21 but also 8, but he shot for 11 that was EOL at the moment of release.
> - The rest is 21.
>
> 
>
> So, the question for those refusing anything other than Java 8 to _run_
> Maven (or to revert: for those refusing to run Maven on "latest LTS", that
> is currently 21):
> WHY?
>
>
> Thanks
> T

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

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 Apache Maven Compiler Plugin version 3.12.0
> Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
> 022
>
> Wed, Nov 29, 2023, 8:16 AM
> [VOTE] Apache Maven Build Cache Extension 1.1.0
> Reproducible Build ok: reference build done on *nix with JDK 11
>
> Sun, Nov 19, 2023, 5:17 PM
> [VOTE] Release Maven Resolver 1.9.17
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
>
> Sat, Oct 21, 2023, 4:34 PM
> VOTE] Apache Maven 4.0.0-alpha-8 release
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
>
> Mon, Oct 2, 2023, 9:11 AM
> [VOTE] Release Apache Maven 3.9.5
> Reproducible not fully ok: reference build done with JDK 17 on *nix and
> umask 022
>
> 
>
> This CLEARLY shows the tendency:
> - Michael does releases on Java 8 (on windows!), he is a known "aligner"
> and windows person :)
> - Olivier used the "minimum" required Java version (for build cache).
> - Unsure why Herve used Java 11 for the Shade plugin... I mean, he could
> use 21 but also 8, but he shot for 11 that was EOL at the moment of release.
> - The rest is 21.
>
> 
>
> So, the question for those refusing anything other than Java 8 to _run_
> Maven (or to revert: for those refusing to run Maven on "latest LTS", that
> is currently 21):
> WHY?
>
>
> Thanks
> T

-
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

[Elliotte Rusty Harold]

On Wed, Feb 21, 2024 at 7:40 AM Hervé Boutemy  wrote:
>
> for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll have to 
> update our plans https://maven.apache.org/developers/compatibility-plan.html
>

Not sure where this comes from. There's no one EOL date for any
version. It depends on the vendor. The dates on that page I spot
checked don't seem to match up with Oracle's announced dates, or that
of any other vendor I looked at.


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

Re: [DISCUSS] Java version for Maven

[Romain Manni-Bucau]

Le mer. 21 févr. 2024 à 10:40, Xeno Amess  a écrit :

> Hi.
> I use toolchain for multi-release-jars
> please don't drop it or provide another way for building multi release jars
>

I assume you mean compiler plugin, good news is that it is built-in and
named executable:
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#executable
.


> 
> From: Romain Manni-Bucau 
> Sent: Wednesday, February 21, 2024 3:48:43 PM
> To: Maven Developers List 
> Subject: Re: [DISCUSS] Java version for Maven
>
> Hi Hervé,
>
> +1000 on the philosophy!
>
> On the toolchain support I still fail to see why maven has toolchain
> anywhere in its code.
> Look it how it is used:
> * Tools are generally setup with env variables (JAVA_HOME, JAVA17_HOME,
> JAVAEA_HOME or alike)
> * Most plugins able to switch the JDK can switch the executable in their
> config and use by default ${env.JAVAxx_HOME} or whatever is desired which
> is the same indirection than toolchain but without the downside to setup a
> toolchain.xml. Then plugins can just use the binary (optionally PathExt on
> windows to get the extension) and be it, works really well.
>
> So overall I think we could drop toolchain which ultimately still misses a
> few parts to be complete in terms of env setup and make a shared-executable
> stronger - likely the future base of exec plugin even if not required.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 21 févr. 2024 à 08:39, Hervé Boutemy  a
> écrit :
>
> > for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll
> have
> > to update our plans
> > https://maven.apache.org/developers/compatibility-plan.html
> >
> > the approach I'd love to promote is "what do we require to not hurt our
> > diversity of users when upgrading minimum prerequisites" (and I'm doing
> it
> > on my free time because I do care about the diversity of our community)
> > => let's work on the enablers
> >
> > Java prerequisite for Maven core is something, but everything will start
> > from plugins: that's why we started the plugins "requirement history"
> > see for example
> > https://maven.apache.org/plugins/maven-shade-plugin/plugin-info.html
> >
> > for a summary on our own plugins, see last column of
> >
> >
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html
> >
> > As you can see, not many plugins are not covered yet: who wants to work
> on
> > this?
> >
> >
> > Another good item cited is improving decoupling JDK of Maven from JDK to
> > compile and run tests.
> > IIRC, Guillaume prepared something about auto-importing available JDKs
> > from sdkman, which is a great idea: I don't know if this was closed done,
> > but I suppose other JDK switcher tools should be supported, I'm
> > particularly interested on knowing what Windows users need
> > One aspect that I know is not well done is that the MANIFEST in jar
> > describes JDK release from Maven core, not target: we should probably do
> > something
> > Another aspect is that toolchains support has to be enabled in pom.xml:
> it
> > would be useful for it to work from just CLI also.
> >
> > I'm sure there are other features that would be useful on this: who wants
> > to work on this?
> >
> >
> > The 2 previous enablers look sufficient to me: any other enabler someone
> > thinks about?
> >
> > And more importantly: who wants to work on it? plan, track progress,
> > document, explain?
> > we need community's help to prepare a smooth change: updating our plans
> > will be a consequence of this preparation
> >
> > Regards,
> >
> > Hervé
> >
> > Le mardi 20 février 2024, 21:49:03 CET Tamás Cservenák a écrit :
> > > 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:
> > >
&

Re: [DISCUSS] Java version for Maven

[Martin Desruisseaux]

Le 2024-02-21 à 10 h 40, Xeno Amess a écrit :


I use toolchain for multi-release-jars please don't drop it or provide 
another way for building multi release jars


I hope to make a proposal as a side-effect of a "Module Source 
Hierarchy" proposal, when we will reach that point (after control on 
module-path, then control on --add-exports option and a few others).


    Martin

Re: [DISCUSS] Java version for Maven

[Xeno Amess]

Hi.
I use toolchain for multi-release-jars
please don't drop it or provide another way for building multi release jars

From: Romain Manni-Bucau 
Sent: Wednesday, February 21, 2024 3:48:43 PM
To: Maven Developers List 
Subject: Re: [DISCUSS] Java version for Maven

Hi Hervé,

+1000 on the philosophy!

On the toolchain support I still fail to see why maven has toolchain
anywhere in its code.
Look it how it is used:
* Tools are generally setup with env variables (JAVA_HOME, JAVA17_HOME,
JAVAEA_HOME or alike)
* Most plugins able to switch the JDK can switch the executable in their
config and use by default ${env.JAVAxx_HOME} or whatever is desired which
is the same indirection than toolchain but without the downside to setup a
toolchain.xml. Then plugins can just use the binary (optionally PathExt on
windows to get the extension) and be it, works really well.

So overall I think we could drop toolchain which ultimately still misses a
few parts to be complete in terms of env setup and make a shared-executable
stronger - likely the future base of exec plugin even if not required.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 21 févr. 2024 à 08:39, Hervé Boutemy  a
écrit :

> for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll have
> to update our plans
> https://maven.apache.org/developers/compatibility-plan.html
>
> the approach I'd love to promote is "what do we require to not hurt our
> diversity of users when upgrading minimum prerequisites" (and I'm doing it
> on my free time because I do care about the diversity of our community)
> => let's work on the enablers
>
> Java prerequisite for Maven core is something, but everything will start
> from plugins: that's why we started the plugins "requirement history"
> see for example
> https://maven.apache.org/plugins/maven-shade-plugin/plugin-info.html
>
> for a summary on our own plugins, see last column of
>
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html
>
> As you can see, not many plugins are not covered yet: who wants to work on
> this?
>
>
> Another good item cited is improving decoupling JDK of Maven from JDK to
> compile and run tests.
> IIRC, Guillaume prepared something about auto-importing available JDKs
> from sdkman, which is a great idea: I don't know if this was closed done,
> but I suppose other JDK switcher tools should be supported, I'm
> particularly interested on knowing what Windows users need
> One aspect that I know is not well done is that the MANIFEST in jar
> describes JDK release from Maven core, not target: we should probably do
> something
> Another aspect is that toolchains support has to be enabled in pom.xml: it
> would be useful for it to work from just CLI also.
>
> I'm sure there are other features that would be useful on this: who wants
> to work on this?
>
>
> The 2 previous enablers look sufficient to me: any other enabler someone
> thinks about?
>
> And more importantly: who wants to work on it? plan, track progress,
> document, explain?
> we need community's help to prepare a smooth change: updating our plans
> will be a consequence of this preparation
>
> Regards,
>
> Hervé
>
> Le mardi 20 février 2024, 21:49:03 CET Tamás Cservenák a écrit :
> > 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 wi

Re: [DISCUSS] Java version for Maven

[Romain Manni-Bucau]

Le mer. 21 févr. 2024 à 09:07, Hervé Boutemy  a
écrit :

> ok, you want to contribute on decoupling JDK of Maven vs JDK of compiler
> and
> tests: perhaps we'll need to open a separate discussion to avoid hijacking
> the
> global plan, but let's have one roundtrip
>

Just to clarify: I don't want but for the rare cases you want to do it you
can already.


>
> scenario is: I use JDK 21 to run Maven, but I need JDK 8 to run my unit
> and
> integration tests
> of course, i have both JDKs on my machine
>

Assuming you have JAVA8_HOME setup you set
${env.JAVA8_HOME}/bin/java in surefire and be it.


>
> I see how I can manually configure toolchain.xml, modify pom.xml etc... to
> do
> that: it works, it's cumbersome
>
> How does "dropping toolchains" help?
>

Does not help, read it the opposite way, "toolchain does not help".


>
> Defining a common plan will probably require a dedicated discussion,
> perhaps
> some wiki pages, perhaps some meeting between people interested to have
> more
> live ideation before sharing proposal on the ML (which is necessary for
> wider
> community discussion)
>

Sure, my point was not to create a debate on that now, just that we should
probably not see toolchain as a solution cause it hurts more it helps.


>
> Le mercredi 21 février 2024, 08:48:43 CET Romain Manni-Bucau a écrit :
> > Hi Hervé,
> >
> > +1000 on the philosophy!
> >
> > On the toolchain support I still fail to see why maven has toolchain
> > anywhere in its code.
> > Look it how it is used:
> > * Tools are generally setup with env variables (JAVA_HOME, JAVA17_HOME,
> > JAVAEA_HOME or alike)
> > * Most plugins able to switch the JDK can switch the executable in their
> > config and use by default ${env.JAVAxx_HOME} or whatever is desired which
> > is the same indirection than toolchain but without the downside to setup
> a
> > toolchain.xml. Then plugins can just use the binary (optionally PathExt
> on
> > windows to get the extension) and be it, works really well.
> >
> > So overall I think we could drop toolchain which ultimately still misses
> a
> > few parts to be complete in terms of env setup and make a
> shared-executable
> > stronger - likely the future base of exec plugin even if not required.
> >
> > 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 mer. 21 févr. 2024 à 08:39, Hervé Boutemy  a
> >
> > écrit :
> > > for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll
> have
> > > to update our plans
> > > https://maven.apache.org/developers/compatibility-plan.html
> > >
> > > the approach I'd love to promote is "what do we require to not hurt our
> > > diversity of users when upgrading minimum prerequisites" (and I'm
> doing it
> > > on my free time because I do care about the diversity of our community)
> > > => let's work on the enablers
> > >
> > > Java prerequisite for Maven core is something, but everything will
> start
> > > from plugins: that's why we started the plugins "requirement history"
> > > see for example
> > > https://maven.apache.org/plugins/maven-shade-plugin/plugin-info.html
> > >
> > > for a summary on our own plugins, see last column of
> > >
> > >
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/jo
> > > b/master/site/dist-tool-prerequisites.html
> > >
> > > As you can see, not many plugins are not covered yet: who wants to
> work on
> > > this?
> > >
> > >
> > > Another good item cited is improving decoupling JDK of Maven from JDK
> to
> > > compile and run tests.
> > > IIRC, Guillaume prepared something about auto-importing available JDKs
> > > from sdkman, which is a great idea: I don't know if this was closed
> done,
> > > but I suppose other JDK switcher tools should be supported, I'm
> > > particularly interested on knowing what Windows users need
> > > One aspect that I know is not well done is that the MANIFEST in jar
> > > describes JDK release from Maven core, not target: we should probably
> do
> > > something
> > > Another aspect is that toolchains support has to be enabled in
> pom.xml: it
> > > would be useful for it to work from just CLI also.
> > >
> > > I'm sure there are other features that would be useful on this: who
> wants
> > > to work on this?
> > >
> > >
> > > The 2 previous enablers look sufficient to me: any other enabler
> someone
> > > thinks about?
> > >
> > > And more importantly: who wants to work on it? plan, track progress,
> > > document, explain?
> > > we need community's help to prepare a smooth change: updating our plans
> > > will be a consequence of this preparation
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le mardi 20 février 2024, 21:49:03 CET Tamás Cservenák a 

Re: [DISCUSS] Java version for Maven

[Hervé Boutemy]

ok, you want to contribute on decoupling JDK of Maven vs JDK of compiler and 
tests: perhaps we'll need to open a separate discussion to avoid hijacking the 
global plan, but let's have one roundtrip

scenario is: I use JDK 21 to run Maven, but I need JDK 8 to run my unit and 
integration tests
of course, i have both JDKs on my machine

I see how I can manually configure toolchain.xml, modify pom.xml etc... to do 
that: it works, it's cumbersome

How does "dropping toolchains" help?

Defining a common plan will probably require a dedicated discussion, perhaps 
some wiki pages, perhaps some meeting between people interested to have more 
live ideation before sharing proposal on the ML (which is necessary for wider 
community discussion)

Le mercredi 21 février 2024, 08:48:43 CET Romain Manni-Bucau a écrit :
> Hi Hervé,
> 
> +1000 on the philosophy!
> 
> On the toolchain support I still fail to see why maven has toolchain
> anywhere in its code.
> Look it how it is used:
> * Tools are generally setup with env variables (JAVA_HOME, JAVA17_HOME,
> JAVAEA_HOME or alike)
> * Most plugins able to switch the JDK can switch the executable in their
> config and use by default ${env.JAVAxx_HOME} or whatever is desired which
> is the same indirection than toolchain but without the downside to setup a
> toolchain.xml. Then plugins can just use the binary (optionally PathExt on
> windows to get the extension) and be it, works really well.
> 
> So overall I think we could drop toolchain which ultimately still misses a
> few parts to be complete in terms of env setup and make a shared-executable
> stronger - likely the future base of exec plugin even if not required.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github 
> | LinkedIn  | Book
>  >
> 
> 
> Le mer. 21 févr. 2024 à 08:39, Hervé Boutemy  a
> 
> écrit :
> > for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll have
> > to update our plans
> > https://maven.apache.org/developers/compatibility-plan.html
> > 
> > the approach I'd love to promote is "what do we require to not hurt our
> > diversity of users when upgrading minimum prerequisites" (and I'm doing it
> > on my free time because I do care about the diversity of our community)
> > => let's work on the enablers
> > 
> > Java prerequisite for Maven core is something, but everything will start
> > from plugins: that's why we started the plugins "requirement history"
> > see for example
> > https://maven.apache.org/plugins/maven-shade-plugin/plugin-info.html
> > 
> > for a summary on our own plugins, see last column of
> > 
> > https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/jo
> > b/master/site/dist-tool-prerequisites.html
> > 
> > As you can see, not many plugins are not covered yet: who wants to work on
> > this?
> > 
> > 
> > Another good item cited is improving decoupling JDK of Maven from JDK to
> > compile and run tests.
> > IIRC, Guillaume prepared something about auto-importing available JDKs
> > from sdkman, which is a great idea: I don't know if this was closed done,
> > but I suppose other JDK switcher tools should be supported, I'm
> > particularly interested on knowing what Windows users need
> > One aspect that I know is not well done is that the MANIFEST in jar
> > describes JDK release from Maven core, not target: we should probably do
> > something
> > Another aspect is that toolchains support has to be enabled in pom.xml: it
> > would be useful for it to work from just CLI also.
> > 
> > I'm sure there are other features that would be useful on this: who wants
> > to work on this?
> > 
> > 
> > The 2 previous enablers look sufficient to me: any other enabler someone
> > thinks about?
> > 
> > And more importantly: who wants to work on it? plan, track progress,
> > document, explain?
> > we need community's help to prepare a smooth change: updating our plans
> > will be a consequence of this preparation
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le mardi 20 février 2024, 21:49:03 CET Tamás Cservenák a écrit :
> > > 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 

Re: [DISCUSS] Java version for Maven

[Christoph Läubrich]

I just wanted to note that it is not true that no one is using 
toolchains, maybe maven devs don't do it ;-)


e.g. github java setup action supports toolchains:

https://github.com/actions/setup-java

and it was added because many users asked for it / requested it.


For me toolchains become *less important* now that Java 9+ has the 
--target option but now we are back at that maven (+its core plugins) 
historically is/was stuck at Java 8 ... circle closed :-P


Am 21.02.24 um 08:48 schrieb Romain Manni-Bucau:

Hi Hervé,

+1000 on the philosophy!

On the toolchain support I still fail to see why maven has toolchain
anywhere in its code.
Look it how it is used:
* Tools are generally setup with env variables (JAVA_HOME, JAVA17_HOME,
JAVAEA_HOME or alike)
* Most plugins able to switch the JDK can switch the executable in their
config and use by default ${env.JAVAxx_HOME} or whatever is desired which
is the same indirection than toolchain but without the downside to setup a
toolchain.xml. Then plugins can just use the binary (optionally PathExt on
windows to get the extension) and be it, works really well.

So overall I think we could drop toolchain which ultimately still misses a
few parts to be complete in terms of env setup and make a shared-executable
stronger - likely the future base of exec plugin even if not required.

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



Le mer. 21 févr. 2024 à 08:39, Hervé Boutemy  a
écrit :


for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll have
to update our plans
https://maven.apache.org/developers/compatibility-plan.html

the approach I'd love to promote is "what do we require to not hurt our
diversity of users when upgrading minimum prerequisites" (and I'm doing it
on my free time because I do care about the diversity of our community)
=> let's work on the enablers

Java prerequisite for Maven core is something, but everything will start
from plugins: that's why we started the plugins "requirement history"
see for example
https://maven.apache.org/plugins/maven-shade-plugin/plugin-info.html

for a summary on our own plugins, see last column of

https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html

As you can see, not many plugins are not covered yet: who wants to work on
this?


Another good item cited is improving decoupling JDK of Maven from JDK to
compile and run tests.
IIRC, Guillaume prepared something about auto-importing available JDKs
from sdkman, which is a great idea: I don't know if this was closed done,
but I suppose other JDK switcher tools should be supported, I'm
particularly interested on knowing what Windows users need
One aspect that I know is not well done is that the MANIFEST in jar
describes JDK release from Maven core, not target: we should probably do
something
Another aspect is that toolchains support has to be enabled in pom.xml: it
would be useful for it to work from just CLI also.

I'm sure there are other features that would be useful on this: who wants
to work on this?


The 2 previous enablers look sufficient to me: any other enabler someone
thinks about?

And more importantly: who wants to work on it? plan, track progress,
document, explain?
we need community's help to prepare a smooth change: updating our plans
will be a consequence of this preparation

Regards,

Hervé

Le mardi 20 février 2024, 21:49:03 CET Tamás Cservenák a écrit :

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 Apache Maven Compiler Plugin version 3.12.0
Reproducible Builds ok: reference build done on *nix with JDK 21 and

umask

022

Wed, Nov 29, 2023, 8:16 AM
[VOTE] Apache Maven Build Cache Extension 1.1.0
Reproducible Build ok: reference build done on *nix with JDK 11

Sun, Nov 19, 2023, 

Re: [DISCUSS] Java version for Maven

[Romain Manni-Bucau]

Hi Hervé,

+1000 on the philosophy!

On the toolchain support I still fail to see why maven has toolchain
anywhere in its code.
Look it how it is used:
* Tools are generally setup with env variables (JAVA_HOME, JAVA17_HOME,
JAVAEA_HOME or alike)
* Most plugins able to switch the JDK can switch the executable in their
config and use by default ${env.JAVAxx_HOME} or whatever is desired which
is the same indirection than toolchain but without the downside to setup a
toolchain.xml. Then plugins can just use the binary (optionally PathExt on
windows to get the extension) and be it, works really well.

So overall I think we could drop toolchain which ultimately still misses a
few parts to be complete in terms of env setup and make a shared-executable
stronger - likely the future base of exec plugin even if not required.

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



Le mer. 21 févr. 2024 à 08:39, Hervé Boutemy  a
écrit :

> for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll have
> to update our plans
> https://maven.apache.org/developers/compatibility-plan.html
>
> the approach I'd love to promote is "what do we require to not hurt our
> diversity of users when upgrading minimum prerequisites" (and I'm doing it
> on my free time because I do care about the diversity of our community)
> => let's work on the enablers
>
> Java prerequisite for Maven core is something, but everything will start
> from plugins: that's why we started the plugins "requirement history"
> see for example
> https://maven.apache.org/plugins/maven-shade-plugin/plugin-info.html
>
> for a summary on our own plugins, see last column of
>
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html
>
> As you can see, not many plugins are not covered yet: who wants to work on
> this?
>
>
> Another good item cited is improving decoupling JDK of Maven from JDK to
> compile and run tests.
> IIRC, Guillaume prepared something about auto-importing available JDKs
> from sdkman, which is a great idea: I don't know if this was closed done,
> but I suppose other JDK switcher tools should be supported, I'm
> particularly interested on knowing what Windows users need
> One aspect that I know is not well done is that the MANIFEST in jar
> describes JDK release from Maven core, not target: we should probably do
> something
> Another aspect is that toolchains support has to be enabled in pom.xml: it
> would be useful for it to work from just CLI also.
>
> I'm sure there are other features that would be useful on this: who wants
> to work on this?
>
>
> The 2 previous enablers look sufficient to me: any other enabler someone
> thinks about?
>
> And more importantly: who wants to work on it? plan, track progress,
> document, explain?
> we need community's help to prepare a smooth change: updating our plans
> will be a consequence of this preparation
>
> Regards,
>
> Hervé
>
> Le mardi 20 février 2024, 21:49:03 CET Tamás Cservenák a écrit :
> > 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 Apache Maven Compiler Plugin version 3.12.0
> > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> umask
> > 022
> >
> > Wed, Nov 29, 2023, 8:16 AM
> > [VOTE] Apache Maven Build Cache Extension 1.1.0
> > Reproducible Build ok: reference build done on *nix with JDK 11
> >
> > Sun, Nov 19, 2023, 5:17 PM
> > [VOTE] Release Maven Resolver 1.9.17
> > Reproducible Build ok: reference build done with JDK 21 on *nix with
> umask
> > 022
> >
> > Sat, Oct 21, 2023, 4:34 PM
> > VOTE] Apache Maven 4.0.0-alpha-8 release
> > Reproducible Build ok: reference build done with JDK 21 on *nix with

Re: [DISCUSS] Java version for Maven

[Hervé Boutemy]

for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll have to 
update our plans https://maven.apache.org/developers/compatibility-plan.html

the approach I'd love to promote is "what do we require to not hurt our 
diversity of users when upgrading minimum prerequisites" (and I'm doing it on 
my free time because I do care about the diversity of our community)
=> let's work on the enablers

Java prerequisite for Maven core is something, but everything will start from 
plugins: that's why we started the plugins "requirement history"
see for example 
https://maven.apache.org/plugins/maven-shade-plugin/plugin-info.html

for a summary on our own plugins, see last column of
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html

As you can see, not many plugins are not covered yet: who wants to work on this?


Another good item cited is improving decoupling JDK of Maven from JDK to 
compile and run tests.
IIRC, Guillaume prepared something about auto-importing available JDKs from 
sdkman, which is a great idea: I don't know if this was closed done, but I 
suppose other JDK switcher tools should be supported, I'm particularly 
interested on knowing what Windows users need
One aspect that I know is not well done is that the MANIFEST in jar describes 
JDK release from Maven core, not target: we should probably do something
Another aspect is that toolchains support has to be enabled in pom.xml: it 
would be useful for it to work from just CLI also.

I'm sure there are other features that would be useful on this: who wants to 
work on this?


The 2 previous enablers look sufficient to me: any other enabler someone thinks 
about?

And more importantly: who wants to work on it? plan, track progress, document, 
explain?
we need community's help to prepare a smooth change: updating our plans will be 
a consequence of this preparation

Regards,

Hervé

Le mardi 20 février 2024, 21:49:03 CET Tamás Cservenák a écrit :
> 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 Apache Maven Compiler Plugin version 3.12.0
> Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
> 022
> 
> Wed, Nov 29, 2023, 8:16 AM
> [VOTE] Apache Maven Build Cache Extension 1.1.0
> Reproducible Build ok: reference build done on *nix with JDK 11
> 
> Sun, Nov 19, 2023, 5:17 PM
> [VOTE] Release Maven Resolver 1.9.17
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
> 
> Sat, Oct 21, 2023, 4:34 PM
> VOTE] Apache Maven 4.0.0-alpha-8 release
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
> 
> Mon, Oct 2, 2023, 9:11 AM
> [VOTE] Release Apache Maven 3.9.5
> Reproducible not fully ok: reference build done with JDK 17 on *nix and
> umask 022
> 
> 
> 
> This CLEARLY shows the tendency:
> - Michael does releases on Java 8 (on windows!), he is a known "aligner"
> and windows person :)
> - Olivier used the "minimum" required Java version (for build cache).
> - Unsure why Herve used Java 11 for the Shade plugin... I mean, he could
> use 21 but also 8, but he shot for 11 that was EOL at the moment of release.
> - The rest is 21.
> 
> 
> 
> So, the question for those refusing anything other than Java 8 to _run_
> Maven (or to revert: for those refusing to run Maven on "latest LTS", that
> is currently 21):
> WHY?
> 
> 
> Thanks
> T





-
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

[Romain Manni-Bucau]

> So it IS about us, the volunteers.
> Is not about THEM, downstream users.

Not for me, for me and anything ASF is 100% about users and 0% about doers.
Anything not aligned on that should stay a personal github project for me.

> if they are stuck (due whatever policy or who knows what), they can just
> stay with 3.9, 3.8 or whatever suits them.
> Why align with the "stuck" ones?

Don't get me wrong, I don't think we should stick to java 8 but we should
embrace our users and ensure they can embrace what we deliver.
If you release maven 4 in 2025 and nobody can use it except a few then it
will stay a niche project compared to today where it is the main java build
tool.
Add the fact you will need ~2 years for maven 4 to be usable by people,
then you just killed the project and its community IMHO.

This is why I think we should stick to something in between, use not
something outdated - as we all saw, java 21 warns about java 8 - but not
the ultimate latest.
That where my LTS-1 comes - but not today it means Java 21 with the
projection we can do of a final release.

If your point was about the "then" the reasoning is similar.
See how alpha and beta are just dead releases except for people able to
build a snapshot, if you release something with a too high minimum java
version, it will be the same.

Keep in mind a tool to be adapted must work, be efficient etc...but should
also respect the 5mn setup.
For a java person assuming you have a correct java is ok and then it must
stay curl $maven && unzip && bin/mvn, please never any toolchain nor more
advanced setup.
It works theorically but there is likely no way people adopt it IMHO.

Also please just consider the polls - even if they are all biased, the
figures are significative enough - about java usage,
https://www.azul.com/wp-content/uploads/final-2023-state-of-java-report.pdf
for example. 2 LTS is generally always covering most people and hopefully
it will go a bit faster in some years but as of today you really need 2 LTS
if you want to be mainstream. Even JakartaEE just pushed back from 21 to 17
as a requirement due to the pressure from the communityand at ASF we
don't really care about code at the end ;).

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



Le mer. 21 févr. 2024 à 07:00, Christoph Läubrich  a
écrit :

> I think I mentioned it elsewhere but the fact that maven requires Java
> to run is actually a (sometimes annoying) implementation detail, so if
> maven would simply ship with a (stripped) JVM, being a native binary or
> actually would probably resolve some problems in the area of java
> discussions.
>
> That the java compiler (and surefire) reuses the JVM maven runs on might
> have been convenient in the past decades but if one really cares should
> actually be configured to use a dedicated JVM anyways.
>
>
> Am 20.02.24 um 21:49 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 Apache Maven Compiler Plugin version 3.12.0
> > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> umask
> > 022
> >
> > Wed, Nov 29, 2023, 8:16 AM
> > [VOTE] Apache Maven Build Cache Extension 1.1.0
> > Reproducible Build ok: reference build done on *nix with JDK 11
> >
> > Sun, Nov 19, 2023, 5:17 PM
> > [VOTE] Release Maven Resolver 1.9.17
> > Reproducible Build ok: reference build done with JDK 21 on *nix with
> umask
> > 022
> >
> > Sat, Oct 21, 2023, 4:34 PM
> > VOTE] Apache Maven 4.0.0-alpha-8 release
> > Reproducible Build ok: reference build done with JDK 21 on *nix with
> umask
> > 022
> >
> > Mon, Oct 2, 2023, 9:11 AM
> > [VOTE] Release Apache Maven 3.9.5
> > Reproducible not fully ok: reference build done with 

Re: [DISCUSS] Java version for Maven

[Christoph Läubrich]

I think I mentioned it elsewhere but the fact that maven requires Java 
to run is actually a (sometimes annoying) implementation detail, so if 
maven would simply ship with a (stripped) JVM, being a native binary or 
actually would probably resolve some problems in the area of java 
discussions.


That the java compiler (and surefire) reuses the JVM maven runs on might 
have been convenient in the past decades but if one really cares should 
actually be configured to use a dedicated JVM anyways.



Am 20.02.24 um 21:49 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 Apache Maven Compiler Plugin version 3.12.0
Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
022

Wed, Nov 29, 2023, 8:16 AM
[VOTE] Apache Maven Build Cache Extension 1.1.0
Reproducible Build ok: reference build done on *nix with JDK 11

Sun, Nov 19, 2023, 5:17 PM
[VOTE] Release Maven Resolver 1.9.17
Reproducible Build ok: reference build done with JDK 21 on *nix with umask
022

Sat, Oct 21, 2023, 4:34 PM
VOTE] Apache Maven 4.0.0-alpha-8 release
Reproducible Build ok: reference build done with JDK 21 on *nix with umask
022

Mon, Oct 2, 2023, 9:11 AM
[VOTE] Release Apache Maven 3.9.5
Reproducible not fully ok: reference build done with JDK 17 on *nix and
umask 022



This CLEARLY shows the tendency:
- Michael does releases on Java 8 (on windows!), he is a known "aligner"
and windows person :)
- Olivier used the "minimum" required Java version (for build cache).
- Unsure why Herve used Java 11 for the Shade plugin... I mean, he could
use 21 but also 8, but he shot for 11 that was EOL at the moment of release.
- The rest is 21.



So, the question for those refusing anything other than Java 8 to _run_
Maven (or to revert: for those refusing to run Maven on "latest LTS", that
is currently 21):
WHY?


Thanks
T



-
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

[Hunter C Payne]

 Its more about supporting an ancient JVM/JDK than compiling Maven on an 
ancient version.  So as long as Maven targets 8 or less in its build, I don't 
think anyone cares (at least I don't) what the actual version of the JDK you 
use in the build pipeline.  Go ahead and have a source setting of 17 and a 
target setting of 8 and as long as it works, I'm fine with it.

Other possible reasons are licensing changes after Java 8 can be a concern for 
some companies (I don't know enough about the law to know if that is a good 
reason or not).  There are some poor souls out there that have really ancient 
setups from 20 years ago and trying to get those working on Java 9+ can be 
challenging.  That's really the big reason people have an opinion on this.  
Also, Java 8 is the last Sun version of Java.  Some old folks still have strong 
opinions on Oracle's ownership of Java.  I'm not one of those folks.

Hunter

On Tuesday, February 20, 2024 at 08:52:20 PM PST, David Jencks 
 wrote:  
 
 From your first paragraph I’d guess you would be on the “maven built on a 
recent LTS java” side.  I was wondering, given these omnipresent IDES,  and 
possibly from a philosophical perspective, what the arguments for “maven built 
on an antique JVM” would be.

Thanks
David Jencks

> On Feb 20, 2024, at 8:10 PM, Hunter C Payne 
>  wrote:
> 
> IDEs, including the 2 you named, have a configuration system for multiple 
> JDKs.  This allows devs to build for multiple versions of the JVM.  Likewise, 
> Maven has multiple ways to configure multiple JDKs for use by different 
> phases or plugins used in a given compilation setup and to target different 
> versions of the JVM.  Javac can target any older version than itself when 
> compiling to classfiles.  So my JDK 17 can compile for Java 8-17 but not 18 
> or higher.
> 
> On the JVM, packaging is just a jar and inside that jar's classfiles will be 
> a specific minimum version of the JVM required for it to run.  Generally 
> speaking, for a variety of reasons, most Java code is backwards compatible to 
> Java 8 which was released about 15 years ago.  No specific code is that 
> backwards compatible but most of it is.  That's why you don't realize that 
> these things exist.  Because unless you are a professional developer, why 
> would you ever care in a language with 15 years of backwards compatibility 
> baked into the culture and large base of 3rd party code.  Hope this answers 
> your question.
> 
> Hunter
> 
>    On Tuesday, February 20, 2024 at 08:01:27 PM PST, David Jencks 
> wrote:  
> 
> I’ve been wondering for some time… My uninformed impression is that most 
> corporate development uses Eclipse or IntilliJ, which I believe run only on 
> the java version they come packaged with, which presumably is not usually the 
> target java version for the code being developed.  Aside from packaging 
> questions (IIUC there’s no way for the maven project to ship a java 
> implementation), why should Maven be different?
> 
> Thanks
> David Jencks
> 
>> On Feb 20, 2024, at 1:30 PM, Tamás Cservenák  wrote:
>> 
>> Romain,
>> 
>> you immediately revealed your WHY:
>> Take off your "paid dev" hat, and please try again.
>> 
>> We ARE an open source project.
>> So it IS about us, the volunteers.
>> Is not about THEM, downstream users.
>> 
>> As it was told a million times:
>> if they are stuck (due whatever policy or who knows what), they can just
>> stay with 3.9, 3.8 or whatever suits them.
>> Why align with the "stuck" ones?
>> 
>> T
>> 
>> PS: and no, I just collected the last release VOTEs w/ Herve responses on
>> ML. If you consider that biased, then you have a problem ;)
>> 
>> 
>> 
>> On Tue, Feb 20, 2024 at 10:18 PM Romain Manni-Bucau 
>> wrote:
>> 
 I am sure the majority of Maven users do not run Maven on the same Java
>>> version they target with their build.
>>> 
>>> Do you use that and the following figures to do a biased conclusion?
>>> 
>>> "If people don't use the same version then we can higher the version"?
>>> 
>>> I think we need to consider two things:
>>> 
>>> * We are OSS dev so not representative of the majority - in a company you
>>> most of the time use the same version you target and want to run that, just
>>> either laziness, policy or quality (building with different versions can
>>> lead to surprises and falsy passing tests = broken prod), sadly it is hard
>>> to find data there but I'm pretty sure it is a common experience
>>> * Guess there is a "use the first matching version I have" in the stats you
>>> mention, so if you target 11 and have 17 you would use 17 but does not mean
>>> you are ok to run 21 (random numbers, move them a bit to be a counter
>>> example on whatever digit you want for maven 4)
>>> * Guess very few people want to have >= 1 JDK
>>> 
>>> So clearly the question is not the latest LTS which would be for me just a
>>> moving version we can't support and would be bad for our end users IMHO but
>>> only the version we pick to start at 

Re: [DISCUSS] Java version for Maven

[David Jencks]

From your first paragraph I’d guess you would be on the “maven built on a 
recent LTS java” side.  I was wondering, given these omnipresent IDES,  and 
possibly from a philosophical perspective, what the arguments for “maven built 
on an antique JVM” would be.

Thanks
David Jencks

> On Feb 20, 2024, at 8:10 PM, Hunter C Payne 
>  wrote:
> 
> IDEs, including the 2 you named, have a configuration system for multiple 
> JDKs.  This allows devs to build for multiple versions of the JVM.  Likewise, 
> Maven has multiple ways to configure multiple JDKs for use by different 
> phases or plugins used in a given compilation setup and to target different 
> versions of the JVM.  Javac can target any older version than itself when 
> compiling to classfiles.  So my JDK 17 can compile for Java 8-17 but not 18 
> or higher.
> 
> On the JVM, packaging is just a jar and inside that jar's classfiles will be 
> a specific minimum version of the JVM required for it to run.  Generally 
> speaking, for a variety of reasons, most Java code is backwards compatible to 
> Java 8 which was released about 15 years ago.  No specific code is that 
> backwards compatible but most of it is.  That's why you don't realize that 
> these things exist.  Because unless you are a professional developer, why 
> would you ever care in a language with 15 years of backwards compatibility 
> baked into the culture and large base of 3rd party code.  Hope this answers 
> your question.
> 
> Hunter
> 
>On Tuesday, February 20, 2024 at 08:01:27 PM PST, David Jencks 
>  wrote:  
> 
> I’ve been wondering for some time… My uninformed impression is that most 
> corporate development uses Eclipse or IntilliJ, which I believe run only on 
> the java version they come packaged with, which presumably is not usually the 
> target java version for the code being developed.  Aside from packaging 
> questions (IIUC there’s no way for the maven project to ship a java 
> implementation), why should Maven be different?
> 
> Thanks
> David Jencks
> 
>> On Feb 20, 2024, at 1:30 PM, Tamás Cservenák  wrote:
>> 
>> Romain,
>> 
>> you immediately revealed your WHY:
>> Take off your "paid dev" hat, and please try again.
>> 
>> We ARE an open source project.
>> So it IS about us, the volunteers.
>> Is not about THEM, downstream users.
>> 
>> As it was told a million times:
>> if they are stuck (due whatever policy or who knows what), they can just
>> stay with 3.9, 3.8 or whatever suits them.
>> Why align with the "stuck" ones?
>> 
>> T
>> 
>> PS: and no, I just collected the last release VOTEs w/ Herve responses on
>> ML. If you consider that biased, then you have a problem ;)
>> 
>> 
>> 
>> On Tue, Feb 20, 2024 at 10:18 PM Romain Manni-Bucau 
>> wrote:
>> 
 I am sure the majority of Maven users do not run Maven on the same Java
>>> version they target with their build.
>>> 
>>> Do you use that and the following figures to do a biased conclusion?
>>> 
>>> "If people don't use the same version then we can higher the version"?
>>> 
>>> I think we need to consider two things:
>>> 
>>> * We are OSS dev so not representative of the majority - in a company you
>>> most of the time use the same version you target and want to run that, just
>>> either laziness, policy or quality (building with different versions can
>>> lead to surprises and falsy passing tests = broken prod), sadly it is hard
>>> to find data there but I'm pretty sure it is a common experience
>>> * Guess there is a "use the first matching version I have" in the stats you
>>> mention, so if you target 11 and have 17 you would use 17 but does not mean
>>> you are ok to run 21 (random numbers, move them a bit to be a counter
>>> example on whatever digit you want for maven 4)
>>> * Guess very few people want to have >= 1 JDK
>>> 
>>> So clearly the question is not the latest LTS which would be for me just a
>>> moving version we can't support and would be bad for our end users IMHO but
>>> only the version we pick to start at 4.0.0.
>>> Choices stay:
>>> 
>>> * Latest LTS at that moment to start fresh and not inherit from a legacy at
>>> day 0
>>> * Latest LTS - 1 - which would enable to cover more projects and get more
>>> adoptions
>>> * Something older but I don't find any valid reason since people skipping 2
>>> LTS will likely never reach maven 4 before we discuss to move our baseline
>>> again.
>>> 
>>> The other question we should probably anticipate is when do we move our
>>> support version range.
>>> Since java is not more predictable in terms of releases I think it can make
>>> sense to target for "new" releases only 2 (maybe 3 but really unsure?) LTS
>>> - indeed with best effort on later versions but no guarantee upfront.
>>> With such a policy calendar can be communicated and people can follow or
>>> not without surprises.
>>> 
>>> So today, since we don't have yet a final I think 21 can make sense but not
>>> cause it is the current latest, cause it will likely be the ~N-1 at 4.0.0
>>> 

Re: [DISCUSS] Java version for Maven

[Hunter C Payne]

 IDEs, including the 2 you named, have a configuration system for multiple 
JDKs.  This allows devs to build for multiple versions of the JVM.  Likewise, 
Maven has multiple ways to configure multiple JDKs for use by different phases 
or plugins used in a given compilation setup and to target different versions 
of the JVM.  Javac can target any older version than itself when compiling to 
classfiles.  So my JDK 17 can compile for Java 8-17 but not 18 or higher.

On the JVM, packaging is just a jar and inside that jar's classfiles will be a 
specific minimum version of the JVM required for it to run.  Generally 
speaking, for a variety of reasons, most Java code is backwards compatible to 
Java 8 which was released about 15 years ago.  No specific code is that 
backwards compatible but most of it is.  That's why you don't realize that 
these things exist.  Because unless you are a professional developer, why would 
you ever care in a language with 15 years of backwards compatibility baked into 
the culture and large base of 3rd party code.  Hope this answers your question.

Hunter

On Tuesday, February 20, 2024 at 08:01:27 PM PST, David Jencks 
 wrote:  
 
 I’ve been wondering for some time… My uninformed impression is that most 
corporate development uses Eclipse or IntilliJ, which I believe run only on the 
java version they come packaged with, which presumably is not usually the 
target java version for the code being developed.  Aside from packaging 
questions (IIUC there’s no way for the maven project to ship a java 
implementation), why should Maven be different?

Thanks
David Jencks

> On Feb 20, 2024, at 1:30 PM, Tamás Cservenák  wrote:
> 
> Romain,
> 
> you immediately revealed your WHY:
> Take off your "paid dev" hat, and please try again.
> 
> We ARE an open source project.
> So it IS about us, the volunteers.
> Is not about THEM, downstream users.
> 
> As it was told a million times:
> if they are stuck (due whatever policy or who knows what), they can just
> stay with 3.9, 3.8 or whatever suits them.
> Why align with the "stuck" ones?
> 
> T
> 
> PS: and no, I just collected the last release VOTEs w/ Herve responses on
> ML. If you consider that biased, then you have a problem ;)
> 
> 
> 
> On Tue, Feb 20, 2024 at 10:18 PM Romain Manni-Bucau 
> wrote:
> 
>>> I am sure the majority of Maven users do not run Maven on the same Java
>> version they target with their build.
>> 
>> Do you use that and the following figures to do a biased conclusion?
>> 
>> "If people don't use the same version then we can higher the version"?
>> 
>> I think we need to consider two things:
>> 
>> * We are OSS dev so not representative of the majority - in a company you
>> most of the time use the same version you target and want to run that, just
>> either laziness, policy or quality (building with different versions can
>> lead to surprises and falsy passing tests = broken prod), sadly it is hard
>> to find data there but I'm pretty sure it is a common experience
>> * Guess there is a "use the first matching version I have" in the stats you
>> mention, so if you target 11 and have 17 you would use 17 but does not mean
>> you are ok to run 21 (random numbers, move them a bit to be a counter
>> example on whatever digit you want for maven 4)
>> * Guess very few people want to have >= 1 JDK
>> 
>> So clearly the question is not the latest LTS which would be for me just a
>> moving version we can't support and would be bad for our end users IMHO but
>> only the version we pick to start at 4.0.0.
>> Choices stay:
>> 
>> * Latest LTS at that moment to start fresh and not inherit from a legacy at
>> day 0
>> * Latest LTS - 1 - which would enable to cover more projects and get more
>> adoptions
>> * Something older but I don't find any valid reason since people skipping 2
>> LTS will likely never reach maven 4 before we discuss to move our baseline
>> again.
>> 
>> The other question we should probably anticipate is when do we move our
>> support version range.
>> Since java is not more predictable in terms of releases I think it can make
>> sense to target for "new" releases only 2 (maybe 3 but really unsure?) LTS
>> - indeed with best effort on later versions but no guarantee upfront.
>> With such a policy calendar can be communicated and people can follow or
>> not without surprises.
>> 
>> So today, since we don't have yet a final I think 21 can make sense but not
>> cause it is the current latest, cause it will likely be the ~N-1 at 4.0.0
>> time.
>> 
>> 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 mar. 20 févr. 2024 à 21:50, Tamás Cservenák  a
>> écrit :
>> 
>>> Howdy,
>>> 
>>> I 

Re: [DISCUSS] Java version for Maven

[David Jencks]

I’ve been wondering for some time… My uninformed impression is that most 
corporate development uses Eclipse or IntilliJ, which I believe run only on the 
java version they come packaged with, which presumably is not usually the 
target java version for the code being developed.  Aside from packaging 
questions (IIUC there’s no way for the maven project to ship a java 
implementation), why should Maven be different?

Thanks
David Jencks

> On Feb 20, 2024, at 1:30 PM, Tamás Cservenák  wrote:
> 
> Romain,
> 
> you immediately revealed your WHY:
> Take off your "paid dev" hat, and please try again.
> 
> We ARE an open source project.
> So it IS about us, the volunteers.
> Is not about THEM, downstream users.
> 
> As it was told a million times:
> if they are stuck (due whatever policy or who knows what), they can just
> stay with 3.9, 3.8 or whatever suits them.
> Why align with the "stuck" ones?
> 
> T
> 
> PS: and no, I just collected the last release VOTEs w/ Herve responses on
> ML. If you consider that biased, then you have a problem ;)
> 
> 
> 
> On Tue, Feb 20, 2024 at 10:18 PM Romain Manni-Bucau 
> wrote:
> 
>>> I am sure the majority of Maven users do not run Maven on the same Java
>> version they target with their build.
>> 
>> Do you use that and the following figures to do a biased conclusion?
>> 
>> "If people don't use the same version then we can higher the version"?
>> 
>> I think we need to consider two things:
>> 
>> * We are OSS dev so not representative of the majority - in a company you
>> most of the time use the same version you target and want to run that, just
>> either laziness, policy or quality (building with different versions can
>> lead to surprises and falsy passing tests = broken prod), sadly it is hard
>> to find data there but I'm pretty sure it is a common experience
>> * Guess there is a "use the first matching version I have" in the stats you
>> mention, so if you target 11 and have 17 you would use 17 but does not mean
>> you are ok to run 21 (random numbers, move them a bit to be a counter
>> example on whatever digit you want for maven 4)
>> * Guess very few people want to have >= 1 JDK
>> 
>> So clearly the question is not the latest LTS which would be for me just a
>> moving version we can't support and would be bad for our end users IMHO but
>> only the version we pick to start at 4.0.0.
>> Choices stay:
>> 
>> * Latest LTS at that moment to start fresh and not inherit from a legacy at
>> day 0
>> * Latest LTS - 1 - which would enable to cover more projects and get more
>> adoptions
>> * Something older but I don't find any valid reason since people skipping 2
>> LTS will likely never reach maven 4 before we discuss to move our baseline
>> again.
>> 
>> The other question we should probably anticipate is when do we move our
>> support version range.
>> Since java is not more predictable in terms of releases I think it can make
>> sense to target for "new" releases only 2 (maybe 3 but really unsure?) LTS
>> - indeed with best effort on later versions but no guarantee upfront.
>> With such a policy calendar can be communicated and people can follow or
>> not without surprises.
>> 
>> So today, since we don't have yet a final I think 21 can make sense but not
>> cause it is the current latest, cause it will likely be the ~N-1 at 4.0.0
>> time.
>> 
>> 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 mar. 20 févr. 2024 à 21:50, Tamás Cservenák  a
>> écrit :
>> 
>>> 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 Apache Maven Compiler Plugin version 3.12.0
>>> Reproducible Builds ok: reference build done on *nix with JDK 21 

Re: [DISCUSS] Java version for Maven

[Tamás Cservenák]

Romain,

you immediately revealed your WHY:
Take off your "paid dev" hat, and please try again.

We ARE an open source project.
So it IS about us, the volunteers.
Is not about THEM, downstream users.

As it was told a million times:
if they are stuck (due whatever policy or who knows what), they can just
stay with 3.9, 3.8 or whatever suits them.
Why align with the "stuck" ones?

T

PS: and no, I just collected the last release VOTEs w/ Herve responses on
ML. If you consider that biased, then you have a problem ;)



On Tue, Feb 20, 2024 at 10:18 PM Romain Manni-Bucau 
wrote:

> > I am sure the majority of Maven users do not run Maven on the same Java
> version they target with their build.
>
> Do you use that and the following figures to do a biased conclusion?
>
> "If people don't use the same version then we can higher the version"?
>
> I think we need to consider two things:
>
> * We are OSS dev so not representative of the majority - in a company you
> most of the time use the same version you target and want to run that, just
> either laziness, policy or quality (building with different versions can
> lead to surprises and falsy passing tests = broken prod), sadly it is hard
> to find data there but I'm pretty sure it is a common experience
> * Guess there is a "use the first matching version I have" in the stats you
> mention, so if you target 11 and have 17 you would use 17 but does not mean
> you are ok to run 21 (random numbers, move them a bit to be a counter
> example on whatever digit you want for maven 4)
> * Guess very few people want to have >= 1 JDK
>
> So clearly the question is not the latest LTS which would be for me just a
> moving version we can't support and would be bad for our end users IMHO but
> only the version we pick to start at 4.0.0.
> Choices stay:
>
> * Latest LTS at that moment to start fresh and not inherit from a legacy at
> day 0
> * Latest LTS - 1 - which would enable to cover more projects and get more
> adoptions
> * Something older but I don't find any valid reason since people skipping 2
> LTS will likely never reach maven 4 before we discuss to move our baseline
> again.
>
> The other question we should probably anticipate is when do we move our
> support version range.
> Since java is not more predictable in terms of releases I think it can make
> sense to target for "new" releases only 2 (maybe 3 but really unsure?) LTS
> - indeed with best effort on later versions but no guarantee upfront.
> With such a policy calendar can be communicated and people can follow or
> not without surprises.
>
> So today, since we don't have yet a final I think 21 can make sense but not
> cause it is the current latest, cause it will likely be the ~N-1 at 4.0.0
> time.
>
> 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 mar. 20 févr. 2024 à 21:50, Tamás Cservenák  a
> écrit :
>
> > 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 Apache Maven Compiler Plugin version 3.12.0
> > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> umask
> > 022
> >
> > Wed, Nov 29, 2023, 8:16 AM
> > [VOTE] Apache Maven Build Cache Extension 1.1.0
> > Reproducible Build ok: reference build done on *nix with JDK 11
> >
> > Sun, Nov 19, 2023, 5:17 PM
> > [VOTE] Release Maven Resolver 1.9.17
> > Reproducible Build ok: reference build done with JDK 21 on *nix with
> umask
> > 022
> >
> > Sat, Oct 21, 2023, 4:34 PM
> > VOTE] Apache Maven 4.0.0-alpha-8 release
> > Reproducible Build ok: reference build done with JDK 21 on *nix with
> umask
> > 022
> >
> > Mon, Oct 2, 2023, 9:11 AM
> > [VOTE] Release Apache Maven 3.9.5
> > Reproducible not fully ok: reference build 

Re: [DISCUSS] Java version for Maven

[Romain Manni-Bucau]

> I am sure the majority of Maven users do not run Maven on the same Java
version they target with their build.

Do you use that and the following figures to do a biased conclusion?

"If people don't use the same version then we can higher the version"?

I think we need to consider two things:

* We are OSS dev so not representative of the majority - in a company you
most of the time use the same version you target and want to run that, just
either laziness, policy or quality (building with different versions can
lead to surprises and falsy passing tests = broken prod), sadly it is hard
to find data there but I'm pretty sure it is a common experience
* Guess there is a "use the first matching version I have" in the stats you
mention, so if you target 11 and have 17 you would use 17 but does not mean
you are ok to run 21 (random numbers, move them a bit to be a counter
example on whatever digit you want for maven 4)
* Guess very few people want to have >= 1 JDK

So clearly the question is not the latest LTS which would be for me just a
moving version we can't support and would be bad for our end users IMHO but
only the version we pick to start at 4.0.0.
Choices stay:

* Latest LTS at that moment to start fresh and not inherit from a legacy at
day 0
* Latest LTS - 1 - which would enable to cover more projects and get more
adoptions
* Something older but I don't find any valid reason since people skipping 2
LTS will likely never reach maven 4 before we discuss to move our baseline
again.

The other question we should probably anticipate is when do we move our
support version range.
Since java is not more predictable in terms of releases I think it can make
sense to target for "new" releases only 2 (maybe 3 but really unsure?) LTS
- indeed with best effort on later versions but no guarantee upfront.
With such a policy calendar can be communicated and people can follow or
not without surprises.

So today, since we don't have yet a final I think 21 can make sense but not
cause it is the current latest, cause it will likely be the ~N-1 at 4.0.0
time.

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



Le mar. 20 févr. 2024 à 21:50, Tamás Cservenák  a
écrit :

> 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 Apache Maven Compiler Plugin version 3.12.0
> Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
> 022
>
> Wed, Nov 29, 2023, 8:16 AM
> [VOTE] Apache Maven Build Cache Extension 1.1.0
> Reproducible Build ok: reference build done on *nix with JDK 11
>
> Sun, Nov 19, 2023, 5:17 PM
> [VOTE] Release Maven Resolver 1.9.17
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
>
> Sat, Oct 21, 2023, 4:34 PM
> VOTE] Apache Maven 4.0.0-alpha-8 release
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
>
> Mon, Oct 2, 2023, 9:11 AM
> [VOTE] Release Apache Maven 3.9.5
> Reproducible not fully ok: reference build done with JDK 17 on *nix and
> umask 022
>
> 
>
> This CLEARLY shows the tendency:
> - Michael does releases on Java 8 (on windows!), he is a known "aligner"
> and windows person :)
> - Olivier used the "minimum" required Java version (for build cache).
> - Unsure why Herve used Java 11 for the Shade plugin... I mean, he could
> use 21 but also 8, but he shot for 11 that was EOL at the moment of
> release.
> - The rest is 21.
>
> 
>
> So, the question for those refusing anything other than Java 8 to _run_
> Maven (or to revert: for those refusing to run Maven on "latest LTS", that
> is currently 21):
> WHY?
>
>
> Thanks
> T
>