Re: Java version for Maven 4?

[Xeno Amess]

actually if it can, just upgrading to 17 seems a good idea...
as spring's latest is for 17, maybe we can join forces to make the market
to 17...
(however I somehow love fiber so if people wanna 21 I just well be
happy)
I always think toolchains shall not be somehow public slaves for every
repo, and fulfil every of their requirements...
instead should become somehow master to force some outdated repo move on.
And as for the repos who wanna stay at 8, just let them use old toolchain
versions, and die out slowly, why should we even care for them and must
make sure they be able to use the latest maven version to build? We are not
slaves nor babysitters for kids after all.
If they want third party maintenance they can just pay for that, or hire
some group, I just don't think it that hard. like just what azul or
jetbrains jbm do...


Xeno Amess  于2024年2月21日周三 13:41写道：

> You are not the only one who hates jigsaw.
>
> As a real joke, about 4-6 years ago in a jackson mailing list, an [oracle
> employee] ask for them to delete module-info in the jars to make it
> runnable at lower jdk version, so yes even people in oracle (at least one)
> seems don't really agree with jigsaw...
>
> Gary Gregory  于2024年2月7日周三 07:38写道：
>
>> I have no use for JPMS today, I just don't want it to get in the way,
>> which
>> is impossible since there is no --dont-bother-me-jpms flag...
>>
>> Gary
>>
>> On Tue, Feb 6, 2024, 6:34 PM Martin Desruisseaux <
>> martin.desruisse...@geomatys.com> wrote:
>>
>> > Hello
>> >
>> > Le 2024-02-06 à 16 h 11, Hunter C Payne a écrit :
>> >
>> > > Nobody wants Jigsaw and the API improvements aren't enough to get
>> > > people to upgrade.
>> > >
>> > I cannot debate on whether a small minority, or a big minority, or a
>> > majority of developers want JPMS (a.k.a. Jigsaw), because I have no data
>> > for backing my claims. However, I have not see someone else providing
>> > reliable data (e.g. a serious study) for backing opposite claims
>> > neither. But one thing sure is that it is not "nobody wants Jigsaw",
>> > since at least two persons have expressed interest on this mailing list.
>> >
>> > Opinions based on personal experience are indicative of a market segment
>> > at best. Some peoples may base their opinions on their experience with
>> > Google or Amazon. My own personal experience is with space agencies,
>> > meteorological/oceanographical agencies, international standardization
>> > organizations, etc. They have different consumers, different
>> > constraints, different priorities. No consumer said directly "I want
>> > JPMS". But they do said "I want faster / more secure / more reliable
>> > software", and JPMS is one tool among others for achieving those goals.
>> > Not a panacea, but a significant help. For example, JPMS improves
>> > security by blocking at the JVM level all unauthorized accesses to
>> > internal packages. I'm not aware of any other non-deprecated solution
>> > providing this security at the JVM level. The few times that I spoke to
>> > peoples working in defence, they were very receptive to that kind of
>> > argument.
>> >
>> > My opinion is that as long as JPMS is so difficult to use in a
>> > non-trivial Maven or Gradle project, we cannot know if a relatively low
>> > adoption is really because of a lack of interest. Even if some
>> > communities are still not interested by JPMS no matter how easy, no
>> > personal experience can be generalized to the whole market. If a tool
>> > improving software security exists, I think it is a responsibility to
>> > make that tool accessible to developers who want to use it (again, I
>> > know that JPMS is not a panacea. But it helps).
>> >
>> > On the larger topic of API improvements in newer Java versions, Panama
>> > (coming final in Java 22) is a big feature given the important native
>> > libraries out there (e.g. for Artificial Intelligence). It may be of
>> > interest to Maven itself, e.g. for accessing C/C++ or Python build
>> tools.
>> >
>> >  Martin
>> >
>> >
>>
>

Re: Java version for Maven 4?

[Xeno Amess]

You are not the only one who hates jigsaw.

As a real joke, about 4-6 years ago in a jackson mailing list, an [oracle
employee] ask for them to delete module-info in the jars to make it
runnable at lower jdk version, so yes even people in oracle (at least one)
seems don't really agree with jigsaw...

Gary Gregory  于2024年2月7日周三 07:38写道：

> I have no use for JPMS today, I just don't want it to get in the way, which
> is impossible since there is no --dont-bother-me-jpms flag...
>
> Gary
>
> On Tue, Feb 6, 2024, 6:34 PM Martin Desruisseaux <
> martin.desruisse...@geomatys.com> wrote:
>
> > Hello
> >
> > Le 2024-02-06 à 16 h 11, Hunter C Payne a écrit :
> >
> > > Nobody wants Jigsaw and the API improvements aren't enough to get
> > > people to upgrade.
> > >
> > I cannot debate on whether a small minority, or a big minority, or a
> > majority of developers want JPMS (a.k.a. Jigsaw), because I have no data
> > for backing my claims. However, I have not see someone else providing
> > reliable data (e.g. a serious study) for backing opposite claims
> > neither. But one thing sure is that it is not "nobody wants Jigsaw",
> > since at least two persons have expressed interest on this mailing list.
> >
> > Opinions based on personal experience are indicative of a market segment
> > at best. Some peoples may base their opinions on their experience with
> > Google or Amazon. My own personal experience is with space agencies,
> > meteorological/oceanographical agencies, international standardization
> > organizations, etc. They have different consumers, different
> > constraints, different priorities. No consumer said directly "I want
> > JPMS". But they do said "I want faster / more secure / more reliable
> > software", and JPMS is one tool among others for achieving those goals.
> > Not a panacea, but a significant help. For example, JPMS improves
> > security by blocking at the JVM level all unauthorized accesses to
> > internal packages. I'm not aware of any other non-deprecated solution
> > providing this security at the JVM level. The few times that I spoke to
> > peoples working in defence, they were very receptive to that kind of
> > argument.
> >
> > My opinion is that as long as JPMS is so difficult to use in a
> > non-trivial Maven or Gradle project, we cannot know if a relatively low
> > adoption is really because of a lack of interest. Even if some
> > communities are still not interested by JPMS no matter how easy, no
> > personal experience can be generalized to the whole market. If a tool
> > improving software security exists, I think it is a responsibility to
> > make that tool accessible to developers who want to use it (again, I
> > know that JPMS is not a panacea. But it helps).
> >
> > On the larger topic of API improvements in newer Java versions, Panama
> > (coming final in Java 22) is a big feature given the important native
> > libraries out there (e.g. for Artificial Intelligence). It may be of
> > interest to Maven itself, e.g. for accessing C/C++ or Python build tools.
> >
> >  Martin
> >
> >
>

Re: Java version for Maven 4?

[Tamás Cservenák]

Howdy,

I think we want a vote about this, plus, Resolver is picking up the latest
Java features. So we ("movers") even have arguments why we need new Java
versions.
I wonder what "aligners" (those who want the same Java version to run Maven
and run their end product built by Maven, in other words "aligned on the
same Java") have to say here.

T

On Wed, Feb 7, 2024 at 4:55 AM Martijn Verburg 
wrote:

> Hi folks,
>
> Wanted to offer an one 'end user' data point. For transparency, I run Java
> engineering at Microsoft (including supporting Minecraft and LinkedIn
> subsidiaries). We're one of the Big Tech Co's that have moved 90%+ of their
> Java workloads off Java 8 onto 11+ :-).
>
> I acknowledge we're not representative of the whole ecosystem (Java is a
> broad Church as they say!) but our stance for 1P and 3P customers is to
> strongly encourage them to move to modern Java stacks, starting with the
> JDK. The ROI in security, stability, performance, developer productivity
> and reduction in Cost of Goods Sold (COGS) is *overwhelmingly* in favour of
> doing so, even despite some challenging efforts to move some apps off Java
> 8 (for the record, Java 11 -> 17/21 migrations are much, much faster).
>
> In short, we'd be fully supportive of Java 17/21 being the build JDK for
> Maven 4.0+. It's time for the Java ecosystem to move on from Java 8 and
> enjoy the massive improvements 11+ brings to the table. Keeping the 3.9.x
> (or 3.10.x) series at JDK 8 is a good compromise for students, academics,
> smaller entities or those who might be stuck on say kiosks or other
> environments where there is a technical limitation.  Adding an EOL to that
> is a sound idea and encourages folks to plan for modernization/migration or
> they could offer to extend the EOL by way of sponsorship, payment or
> engineering resource.
>
> Cheers,
> Martijn
>
>
> On Wed, 7 Feb 2024 at 15:46, Gary Gregory  wrote:
>
> > The JVM and JRE don't let you escape out of JPMS. Presumably this is why
> we
> > had to redo a bunch of Maven modules for Log4j on the master branch
> > (unreleased WIP for 3.0).
> >
> > Gary
> >
> > On Tue, Feb 6, 2024, 6:43 PM Martin Desruisseaux <
> > martin.desruisse...@geomatys.com> wrote:
> >
> > > Le 2024-02-07 à 00 h 37, Gary Gregory a écrit :
> > > >
> > > > I have no use for JPMS today, I just don't want it to get in the way,
> > > > which is impossible since there is no --dont-bother-me-jpms flag...
> > > >
> > > That option exists at the level of the proposed Maven 4 API and has a
> > > JUnit test [1]. Plugins have the possibility to expose it. Where does
> > > the idea that JPMS will be imposed to everyone come from?
> > >
> > >  Martin
> > >
> > > [1]https://github.com/apache/maven/pull/1378#issuecomment-1925933959
> > >
> >
>

Re: Java version for Maven 4?

[Martijn Verburg]

Hi folks,

Wanted to offer an one 'end user' data point. For transparency, I run Java
engineering at Microsoft (including supporting Minecraft and LinkedIn
subsidiaries). We're one of the Big Tech Co's that have moved 90%+ of their
Java workloads off Java 8 onto 11+ :-).

I acknowledge we're not representative of the whole ecosystem (Java is a
broad Church as they say!) but our stance for 1P and 3P customers is to
strongly encourage them to move to modern Java stacks, starting with the
JDK. The ROI in security, stability, performance, developer productivity
and reduction in Cost of Goods Sold (COGS) is *overwhelmingly* in favour of
doing so, even despite some challenging efforts to move some apps off Java
8 (for the record, Java 11 -> 17/21 migrations are much, much faster).

In short, we'd be fully supportive of Java 17/21 being the build JDK for
Maven 4.0+. It's time for the Java ecosystem to move on from Java 8 and
enjoy the massive improvements 11+ brings to the table. Keeping the 3.9.x
(or 3.10.x) series at JDK 8 is a good compromise for students, academics,
smaller entities or those who might be stuck on say kiosks or other
environments where there is a technical limitation.  Adding an EOL to that
is a sound idea and encourages folks to plan for modernization/migration or
they could offer to extend the EOL by way of sponsorship, payment or
engineering resource.

Cheers,
Martijn


On Wed, 7 Feb 2024 at 15:46, Gary Gregory  wrote:

> The JVM and JRE don't let you escape out of JPMS. Presumably this is why we
> had to redo a bunch of Maven modules for Log4j on the master branch
> (unreleased WIP for 3.0).
>
> Gary
>
> On Tue, Feb 6, 2024, 6:43 PM Martin Desruisseaux <
> martin.desruisse...@geomatys.com> wrote:
>
> > Le 2024-02-07 à 00 h 37, Gary Gregory a écrit :
> > >
> > > I have no use for JPMS today, I just don't want it to get in the way,
> > > which is impossible since there is no --dont-bother-me-jpms flag...
> > >
> > That option exists at the level of the proposed Maven 4 API and has a
> > JUnit test [1]. Plugins have the possibility to expose it. Where does
> > the idea that JPMS will be imposed to everyone come from?
> >
> >  Martin
> >
> > [1]https://github.com/apache/maven/pull/1378#issuecomment-1925933959
> >
>

Re: Java version for Maven 4?

[Gary Gregory]

The JVM and JRE don't let you escape out of JPMS. Presumably this is why we
had to redo a bunch of Maven modules for Log4j on the master branch
(unreleased WIP for 3.0).

Gary

On Tue, Feb 6, 2024, 6:43 PM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Le 2024-02-07 à 00 h 37, Gary Gregory a écrit :
> >
> > I have no use for JPMS today, I just don't want it to get in the way,
> > which is impossible since there is no --dont-bother-me-jpms flag...
> >
> That option exists at the level of the proposed Maven 4 API and has a
> JUnit test [1]. Plugins have the possibility to expose it. Where does
> the idea that JPMS will be imposed to everyone come from?
>
>  Martin
>
> [1]https://github.com/apache/maven/pull/1378#issuecomment-1925933959
>

Re: Java version for Maven 4?

[Martin Desruisseaux]

Le 2024-02-07 à 00 h 37, Gary Gregory a écrit :


I have no use for JPMS today, I just don't want it to get in the way, 
which is impossible since there is no --dont-bother-me-jpms flag...


That option exists at the level of the proposed Maven 4 API and has a 
JUnit test [1]. Plugins have the possibility to expose it. Where does 
the idea that JPMS will be imposed to everyone come from?


    Martin

[1]https://github.com/apache/maven/pull/1378#issuecomment-1925933959

Re: Java version for Maven 4?

[Gary Gregory]

I have no use for JPMS today, I just don't want it to get in the way, which
is impossible since there is no --dont-bother-me-jpms flag...

Gary

On Tue, Feb 6, 2024, 6:34 PM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Hello
>
> Le 2024-02-06 à 16 h 11, Hunter C Payne a écrit :
>
> > Nobody wants Jigsaw and the API improvements aren't enough to get
> > people to upgrade.
> >
> I cannot debate on whether a small minority, or a big minority, or a
> majority of developers want JPMS (a.k.a. Jigsaw), because I have no data
> for backing my claims. However, I have not see someone else providing
> reliable data (e.g. a serious study) for backing opposite claims
> neither. But one thing sure is that it is not "nobody wants Jigsaw",
> since at least two persons have expressed interest on this mailing list.
>
> Opinions based on personal experience are indicative of a market segment
> at best. Some peoples may base their opinions on their experience with
> Google or Amazon. My own personal experience is with space agencies,
> meteorological/oceanographical agencies, international standardization
> organizations, etc. They have different consumers, different
> constraints, different priorities. No consumer said directly "I want
> JPMS". But they do said "I want faster / more secure / more reliable
> software", and JPMS is one tool among others for achieving those goals.
> Not a panacea, but a significant help. For example, JPMS improves
> security by blocking at the JVM level all unauthorized accesses to
> internal packages. I'm not aware of any other non-deprecated solution
> providing this security at the JVM level. The few times that I spoke to
> peoples working in defence, they were very receptive to that kind of
> argument.
>
> My opinion is that as long as JPMS is so difficult to use in a
> non-trivial Maven or Gradle project, we cannot know if a relatively low
> adoption is really because of a lack of interest. Even if some
> communities are still not interested by JPMS no matter how easy, no
> personal experience can be generalized to the whole market. If a tool
> improving software security exists, I think it is a responsibility to
> make that tool accessible to developers who want to use it (again, I
> know that JPMS is not a panacea. But it helps).
>
> On the larger topic of API improvements in newer Java versions, Panama
> (coming final in Java 22) is a big feature given the important native
> libraries out there (e.g. for Artificial Intelligence). It may be of
> interest to Maven itself, e.g. for accessing C/C++ or Python build tools.
>
>  Martin
>
>

Re: Java version for Maven 4?

[Martin Desruisseaux]

Hello

Le 2024-02-06 à 16 h 11, Hunter C Payne a écrit :

Nobody wants Jigsaw and the API improvements aren't enough to get 
people to upgrade.


I cannot debate on whether a small minority, or a big minority, or a 
majority of developers want JPMS (a.k.a. Jigsaw), because I have no data 
for backing my claims. However, I have not see someone else providing 
reliable data (e.g. a serious study) for backing opposite claims 
neither. But one thing sure is that it is not "nobody wants Jigsaw", 
since at least two persons have expressed interest on this mailing list.


Opinions based on personal experience are indicative of a market segment 
at best. Some peoples may base their opinions on their experience with 
Google or Amazon. My own personal experience is with space agencies, 
meteorological/oceanographical agencies, international standardization 
organizations, etc. They have different consumers, different 
constraints, different priorities. No consumer said directly "I want 
JPMS". But they do said "I want faster / more secure / more reliable 
software", and JPMS is one tool among others for achieving those goals. 
Not a panacea, but a significant help. For example, JPMS improves 
security by blocking at the JVM level all unauthorized accesses to 
internal packages. I'm not aware of any other non-deprecated solution 
providing this security at the JVM level. The few times that I spoke to 
peoples working in defence, they were very receptive to that kind of 
argument.


My opinion is that as long as JPMS is so difficult to use in a 
non-trivial Maven or Gradle project, we cannot know if a relatively low 
adoption is really because of a lack of interest. Even if some 
communities are still not interested by JPMS no matter how easy, no 
personal experience can be generalized to the whole market. If a tool 
improving software security exists, I think it is a responsibility to 
make that tool accessible to developers who want to use it (again, I 
know that JPMS is not a panacea. But it helps).


On the larger topic of API improvements in newer Java versions, Panama 
(coming final in Java 22) is a big feature given the important native 
libraries out there (e.g. for Artificial Intelligence). It may be of 
interest to Maven itself, e.g. for accessing C/C++ or Python build tools.


    Martin

Re: Java version for Maven 4?

[Hunter C Payne]

 Scala has lousy support and the language is dying mainly because Scala3 seems 
like a Kotlin clone (with poor support).  The folks that run Scala are 
academics and it shows in their marketing and mismanagement of the language.  
However, Kotlin is growing and it would be very surprising for me to meet a 
Java dev under 25 that doesn't do most of their work in Kotlin or Scala.

For you is it more that the new features are really that good or is it that the 
new languages aren't innovating ATM?  For instance, perhaps Kotlin focuses on 
Android too much for a general purpose language?  The really sad part is that 
Kotlin (and Scala) would be a far better language for ML/analytics folks than 
Python but nobody uses it that way so the language's features are all focused 
on Android dev.

Hunter

On Tuesday, February 6, 2024 at 07:18:07 AM PST, Romain Manni-Bucau 
 wrote:  
 
 Le mar. 6 févr. 2024 à 16:12, Hunter C Payne
 a écrit :

>  There are also license differences between Java 8 and Java 9+.  And the
> improvements beyond 8 are not things the market seems to want.  Nobody
> wants Jigsaw and the API improvements aren't enough to get people to
> upgrade.  Those that really want new language features use Scala or Kotlin
> and those both run best on Java 8.  Just to add some other reasons why Java
> 9+ isn't really something the market wants.
>


While I agree with the JPMS - and I was agreeing until 3-4 years ago on the
rest - I kind of disagree with the rest which is no more true since java
17+ IMO. Also Scala is slowly dying while Kotlin does not get much more
traction every year now so world changed and our old habits must probably
too IMHO ;).


> Hunter
>
>    On Tuesday, February 6, 2024 at 06:01:07 AM PST, Elliotte Rusty Harold
>  wrote:
>
>  On Mon, Feb 5, 2024 at 8:46 PM Benjamin Marwell 
> wrote:
> >
>
> > Besides that, most big (tech) companies do not allow unmaintained or
> > unsupported software.
>
> How I wish that were true. Unmaintained and unsupported software is
> all over the place, in big tech, little tech, enterprise, and my
> mother's MacBook. I doubt you can install a Linux distro that doesn't
> depend critically on some unmaintained library no one is paying
> attention to.
>
> What big tech mono-repo companies do differently that most other
> companies don't is build everything from source themselves, kernel and
> build tools included, so that when some critical bug surfaces they can
> dig into the code and fix it. They are mostly not dependent on
> binaries shipped by third parties. It's a feasible option for
> companies in the hundreds of billions of dollars range. For the rest
> of us, not so much.
>
> --
> 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: Java version for Maven 4?

[Kévin Buntrock]

> Security issues. LTS support is a thing, and not just for JDKs.
Customers really, really want versions of tools and libraries they
don't have to upgrade, but that are supported when something does come
up. And when a security issue does come up, they want a drop in
replacement that fixes that one bug **and nothing else**. They want a
patch on the old release, not a new release that deprecates 32 methods
and classes, changes the behavior of 5 other methods, and requires
them to recompile their code and update seven other dependencies.
Customers hate being pushed into new versions when they're not ready
to migrate or don't see any personal benefit from  the "improvements".

I see a major contradiction here (as pointed by Tamás Cservenák). These
projects will for sure continue to use their 3.x version and will never
switch to the 4.x branch.


Le mar. 6 févr. 2024 à 16:18, Romain Manni-Bucau  a
écrit :

> Le mar. 6 févr. 2024 à 16:12, Hunter C Payne
>  a écrit :
>
> >  There are also license differences between Java 8 and Java 9+.  And the
> > improvements beyond 8 are not things the market seems to want.  Nobody
> > wants Jigsaw and the API improvements aren't enough to get people to
> > upgrade.  Those that really want new language features use Scala or
> Kotlin
> > and those both run best on Java 8.  Just to add some other reasons why
> Java
> > 9+ isn't really something the market wants.
> >
>
>
> While I agree with the JPMS - and I was agreeing until 3-4 years ago on the
> rest - I kind of disagree with the rest which is no more true since java
> 17+ IMO. Also Scala is slowly dying while Kotlin does not get much more
> traction every year now so world changed and our old habits must probably
> too IMHO ;).
>
>
> > Hunter
> >
> > On Tuesday, February 6, 2024 at 06:01:07 AM PST, Elliotte Rusty
> Harold
> >  wrote:
> >
> >  On Mon, Feb 5, 2024 at 8:46 PM Benjamin Marwell 
> > wrote:
> > >
> >
> > > Besides that, most big (tech) companies do not allow unmaintained or
> > > unsupported software.
> >
> > How I wish that were true. Unmaintained and unsupported software is
> > all over the place, in big tech, little tech, enterprise, and my
> > mother's MacBook. I doubt you can install a Linux distro that doesn't
> > depend critically on some unmaintained library no one is paying
> > attention to.
> >
> > What big tech mono-repo companies do differently that most other
> > companies don't is build everything from source themselves, kernel and
> > build tools included, so that when some critical bug surfaces they can
> > dig into the code and fix it. They are mostly not dependent on
> > binaries shipped by third parties. It's a feasible option for
> > companies in the hundreds of billions of dollars range. For the rest
> > of us, not so much.
> >
> > --
> > 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: Java version for Maven 4?

[Romain Manni-Bucau]

Le mar. 6 févr. 2024 à 16:12, Hunter C Payne
 a écrit :

>  There are also license differences between Java 8 and Java 9+.  And the
> improvements beyond 8 are not things the market seems to want.  Nobody
> wants Jigsaw and the API improvements aren't enough to get people to
> upgrade.  Those that really want new language features use Scala or Kotlin
> and those both run best on Java 8.  Just to add some other reasons why Java
> 9+ isn't really something the market wants.
>


While I agree with the JPMS - and I was agreeing until 3-4 years ago on the
rest - I kind of disagree with the rest which is no more true since java
17+ IMO. Also Scala is slowly dying while Kotlin does not get much more
traction every year now so world changed and our old habits must probably
too IMHO ;).


> Hunter
>
> On Tuesday, February 6, 2024 at 06:01:07 AM PST, Elliotte Rusty Harold
>  wrote:
>
>  On Mon, Feb 5, 2024 at 8:46 PM Benjamin Marwell 
> wrote:
> >
>
> > Besides that, most big (tech) companies do not allow unmaintained or
> > unsupported software.
>
> How I wish that were true. Unmaintained and unsupported software is
> all over the place, in big tech, little tech, enterprise, and my
> mother's MacBook. I doubt you can install a Linux distro that doesn't
> depend critically on some unmaintained library no one is paying
> attention to.
>
> What big tech mono-repo companies do differently that most other
> companies don't is build everything from source themselves, kernel and
> build tools included, so that when some critical bug surfaces they can
> dig into the code and fix it. They are mostly not dependent on
> binaries shipped by third parties. It's a feasible option for
> companies in the hundreds of billions of dollars range. For the rest
> of us, not so much.
>
> --
> 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: Java version for Maven 4?

[Hunter C Payne]

 There are also license differences between Java 8 and Java 9+.  And the 
improvements beyond 8 are not things the market seems to want.  Nobody wants 
Jigsaw and the API improvements aren't enough to get people to upgrade.  Those 
that really want new language features use Scala or Kotlin and those both run 
best on Java 8.  Just to add some other reasons why Java 9+ isn't really 
something the market wants.
Hunter

On Tuesday, February 6, 2024 at 06:01:07 AM PST, Elliotte Rusty Harold 
 wrote:  
 
 On Mon, Feb 5, 2024 at 8:46 PM Benjamin Marwell  wrote:
>

> Besides that, most big (tech) companies do not allow unmaintained or
> unsupported software.

How I wish that were true. Unmaintained and unsupported software is
all over the place, in big tech, little tech, enterprise, and my
mother's MacBook. I doubt you can install a Linux distro that doesn't
depend critically on some unmaintained library no one is paying
attention to.

What big tech mono-repo companies do differently that most other
companies don't is build everything from source themselves, kernel and
build tools included, so that when some critical bug surfaces they can
dig into the code and fix it. They are mostly not dependent on
binaries shipped by third parties. It's a feasible option for
companies in the hundreds of billions of dollars range. For the rest
of us, not so much.

-- 
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: Java version for Maven 4?

[Romain Manni-Bucau]

While I don't think google-http-java-client is something we can rely on to
decide anything for us for the 10 coming years, similarly not sure that
mono-repo in big companies is actually a thing we should consider as a
first citizen, in particular after the drawbacks big companies got trying
to align on nodejs style on CI/CD and the reverts we saw in the ecosystem
some years ago,
I however see that there is a good hidden point in that off topic: github
actions (I think it is a big consumer part of maven) almost never
references the maven version used to build which is quite shocking and
broken by design but is the current state of the art.
However even google-http-java-client moved to java 21 so your example kind
of confirms the coming outcome of this thread IMHO rather than trying to
oppose to it so I'm not sure what's the point is.

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



Le mar. 6 févr. 2024 à 15:00, Elliotte Rusty Harold  a
écrit :

> On Mon, Feb 5, 2024 at 8:46 PM Benjamin Marwell 
> wrote:
> >
>
> > Besides that, most big (tech) companies do not allow unmaintained or
> > unsupported software.
>
> How I wish that were true. Unmaintained and unsupported software is
> all over the place, in big tech, little tech, enterprise, and my
> mother's MacBook. I doubt you can install a Linux distro that doesn't
> depend critically on some unmaintained library no one is paying
> attention to.
>
> What big tech mono-repo companies do differently that most other
> companies don't is build everything from source themselves, kernel and
> build tools included, so that when some critical bug surfaces they can
> dig into the code and fix it. They are mostly not dependent on
> binaries shipped by third parties. It's a feasible option for
> companies in the hundreds of billions of dollars range. For the rest
> of us, not so much.
>
> --
> 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: Java version for Maven 4?

[Tamás Cservenák]

Eliotte,

You are missing the topic of this whole thread.
What you wrote in any of your mails is totally unrelated to the thread.

I do feel sorry, or unsure, maybe sympathize with your work issues and
difficulties, but I still cannot understand what all that has to do with
the ASF Maven Project?
This thread is about the "Java requirement for Maven4" that is not even GA
yet!
I am 99.999% sure it is NOT yet used (as it is not released yet) in any of
those 'big tech' companies, that tortures you.

Thanks
T

On Tue, Feb 6, 2024 at 3:01 PM Elliotte Rusty Harold 
wrote:

> On Mon, Feb 5, 2024 at 8:46 PM Benjamin Marwell 
> wrote:
> >
>
> > Besides that, most big (tech) companies do not allow unmaintained or
> > unsupported software.
>
> How I wish that were true. Unmaintained and unsupported software is
> all over the place, in big tech, little tech, enterprise, and my
> mother's MacBook. I doubt you can install a Linux distro that doesn't
> depend critically on some unmaintained library no one is paying
> attention to.
>
> What big tech mono-repo companies do differently that most other
> companies don't is build everything from source themselves, kernel and
> build tools included, so that when some critical bug surfaces they can
> dig into the code and fix it. They are mostly not dependent on
> binaries shipped by third parties. It's a feasible option for
> companies in the hundreds of billions of dollars range. For the rest
> of us, not so much.
>
> --
> 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: Java version for Maven 4?

[Elliotte Rusty Harold]

On Mon, Feb 5, 2024 at 8:46 PM Benjamin Marwell  wrote:
>

> Besides that, most big (tech) companies do not allow unmaintained or
> unsupported software.

How I wish that were true. Unmaintained and unsupported software is
all over the place, in big tech, little tech, enterprise, and my
mother's MacBook. I doubt you can install a Linux distro that doesn't
depend critically on some unmaintained library no one is paying
attention to.

What big tech mono-repo companies do differently that most other
companies don't is build everything from source themselves, kernel and
build tools included, so that when some critical bug surfaces they can
dig into the code and fix it. They are mostly not dependent on
binaries shipped by third parties. It's a feasible option for
companies in the hundreds of billions of dollars range. For the rest
of us, not so much.

-- 
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: Java version for Maven 4?

[Elliotte Rusty Harold]

On Tue, Feb 6, 2024 at 12:00 PM Tamás Cservenák  wrote:
>
> Howdy,
>
> For start, I think Martin assumed the "build time Java requirement for
> Maven4"?
>
> If so, my "vote" would be like:
> * build time: "latest LTS" (fixed at the moment when 4.0.0 GA happens,
> until then we just follow LTS), post GA "we adjust to latest LTS on each
> minor release (so 4.1, 4.2, etc)"
> * run time: this is the fun part: with Java 21 we already get a warning
> that `release=8` is deprecated. So, basically that above introduces a hard
> minimum limit (as given LTS allows). But I think we are with that, as it
> really makes sense that a Java build (and comprehension bla bla) tool
> _follow_ Java lifecycle, as things and new features are just flying past us
> (think JPMS support in Maven), etc.
>

That sounds like the tail is wagging the dog. I'd start with the
minimum version of Java we need to be able to build for. Right now I'd
say that's Java **1.7** as I can point to major open source projects
sitting underneath a lot of other projects and products that require
that. E.g. google-http-java-client

Given that, I wouldn't go higher for Maven itself than what can
generate jars for that version, ideally without warnings.

-- 
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: Java version for Maven 4?

[Christoph Läubrich]

I'm interested, how do I become a customer of "apache-maven", I'm not 
aware of such thing anyways there are some options:


1) Fork and fix that bug and deploy a new version to your 
company-artifact server for the version you are using (maven central is 
not a requirement for maven dependencies)


2) Participate in the projects you depend on so you are able to provide 
the patch in the version you like and having earned enough carma for 
some one with release power to release that specific version


3) Pay someone on the project to do so on your behalf (and enter some 
kind of customer-releation with that person) especially if special LTS 
support is required for specific combinations


Am 06.02.24 um 14:28 schrieb Elliotte Rusty Harold:

On Tue, Feb 6, 2024 at 10:50 AM Kévin Buntrock  wrote:


 From my modest point of view : glued to old stack projects do not move at
all. Why move to a new maven version if the one used works?



Security issues. LTS support is a thing, and not just for JDKs.
Customers really, really want versions of tools and libraries they
don't have to upgrade, but that are supported when something does come
up. And when a security issue does come up, they want a drop in
replacement that fixes that one bug **and nothing else**. They want a
patch on the old release, not a new release that deprecates 32 methods
and classes, changes the behavior of 5 other methods, and requires
them to recompile their code and update seven other dependencies.
Customers hate being pushed into new versions when they're not ready
to migrate or don't see any personal benefit from  the "improvements".




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Java version for Maven 4?

[Elliotte Rusty Harold]

On Tue, Feb 6, 2024 at 10:50 AM Kévin Buntrock  wrote:
>
> From my modest point of view : glued to old stack projects do not move at
> all. Why move to a new maven version if the one used works?
>

Security issues. LTS support is a thing, and not just for JDKs.
Customers really, really want versions of tools and libraries they
don't have to upgrade, but that are supported when something does come
up. And when a security issue does come up, they want a drop in
replacement that fixes that one bug **and nothing else**. They want a
patch on the old release, not a new release that deprecates 32 methods
and classes, changes the behavior of 5 other methods, and requires
them to recompile their code and update seven other dependencies.
Customers hate being pushed into new versions when they're not ready
to migrate or don't see any personal benefit from  the "improvements".


-- 
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: Java version for Maven 4?

[Elliotte Rusty Harold]

On Tue, Feb 6, 2024 at 8:01 AM Benjamin Marwell  wrote:
>
> > we need to think about companies
> that pay for old JDK support
>
> There was a suggestion on slack that companies could provide "dev and
> release manager" for Maven 3 and manage the JDK 8 Maven 3 until they lose
> interest. This already works well for other projects.
>

Perhaps, but we'd need to modify the release process. Today Maven and
plugins can pretty much only be released by a PMC member. If you
expect some other company to take it up, they'd need to be able to do
so without individual PMC members and without necessarily having the
same human being do the job every time. Employees move on even when
the job role stays the same.

Furthermore, one of the unforeseen problems Maven introduced to the
Java ecosystem was that, unlike with the JDK itself, Maven artifacts
can't be effectively forked because a third party can't publish under
the same group ID. It is no longer feasible for someone other than the
originator to release a drop-in replacement that fixes a bug.
Consequently any such maintainer would need to be able to release
org.apache.maven artifacts like the compiler plugin, the javadoc
plugin, etc. I'm not sure Apache is willing to grant that much
authority to a third party.

There are alternatives from the perspective of a big tech company that
has the resources to maintain their own JDK. They can switch to Gradle
or even maintain and release their own idiosyncratic build tool. Or
all of the above. Whether that matters here, I don't know.

-- 
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: Java version for Maven 4?

[Gary Gregory]

I like all 5 cents 

Gary

On Tue, Feb 6, 2024, 7:00 AM Tamás Cservenák  wrote:

> Howdy,
>
> For start, I think Martin assumed the "build time Java requirement for
> Maven4"?
>
> If so, my "vote" would be like:
> * build time: "latest LTS" (fixed at the moment when 4.0.0 GA happens,
> until then we just follow LTS), post GA "we adjust to latest LTS on each
> minor release (so 4.1, 4.2, etc)"
> * run time: this is the fun part: with Java 21 we already get a warning
> that `release=8` is deprecated. So, basically that above introduces a hard
> minimum limit (as given LTS allows). But I think we are with that, as it
> really makes sense that a Java build (and comprehension bla bla) tool
> _follow_ Java lifecycle, as things and new features are just flying past us
> (think JPMS support in Maven), etc.
>
> Example for similar setup that we already have:
> * maven-resolver: build enforces Java 21, but most of modules are still
> release=8, while some modules being release=11 and some are multi-release
> JARs (baseline is release=8 but support present for up to 17).
> * maven-indexer: here, dependency on Lucene 9.x (or 8.x? am unsure) made
> project 11+, but similarly as in resolver, Java 11+ HttpClient is used,
> etc. All modules are release=11.
>
> In both cases projects require "latest LTS" _for building the project_ (oh,
> and same is enforced for Maven, "latest Maven" is enforced). This just
> makes us have less work to figure out why (would) it fail on someone etc...
> We are sure requirements are fulfilled, and the one who builds it receives
> "sane" error messages as well, making him able to "fix" (by updating Java
> and/or Maven versions as needed). Again, all these serves _our benefit_, is
> not something done "just for fun".
>
> My 5 cents
> T
>
>
> On Tue, Feb 6, 2024 at 12:12 PM Olivier Lamy  wrote:
>
> > Personnaly (take it as a vote), I find this a good idea to say:
> > - 3.x: jdk 8 (whatever someone wants to release some fixes)
> > - 4.x: jdk 17
> >
> >
> > On Tue, 6 Feb 2024 at 20:50, Kévin Buntrock 
> > wrote:
> > >
> > > From my modest point of view : glued to old stack projects do not move
> at
> > > all. Why move to a new maven version if the one used works?
> > >
> > > Furthermore, I'm quite impressed by the number of projects starting in
> > java
> > > 21 for clients I was considering really shy new adopters. Java 21 is
> > here,
> > > works well, and gets adopted.
> > >
> > > Therefore, my vote goes to the current last LTS to run maven 4, a
> project
> > > not even released.
> > >
> > > Le mar. 6 févr. 2024 à 09:00, Benjamin Marwell  a
> > > écrit :
> > >
> > > > > we need to think about companies
> > > > that pay for old JDK support
> > > >
> > > > There was a suggestion on slack that companies could provide "dev and
> > > > release manager" for Maven 3 and manage the JDK 8 Maven 3 until they
> > lose
> > > > interest. This already works well for other projects.
> > > >
> > > > Even if no one stands up for volunteering: Maven 3 will continue to
> > work
> > > > just fine, even after releases of Maven 4.
> > > >
> > > >
> > > > About the companies who run their own JDK team:
> > > > Well, they made that a conscious decision. They surely had planned
> for
> > > > versions after Java 8. If not, I don't see why we should take their
> > problem
> > > > and make it ours.
> > > >
> > > > - Ben
> > > >
> > > >
> > > > On Mon, 5 Feb 2024, 23:15 Gary Gregory, 
> > wrote:
> > > >
> > > > > An interesting question for me is whether we need to think about
> > > > companies
> > > > > that pay for old JDK support and how that affects our support for
> > these
> > > > old
> > > > > JDKs.
> > > > >
> > > > > Gary
> > > > >
> > > > > On Mon, Feb 5, 2024, 4:28 PM Elliotte Rusty Harold <
> > elh...@ibiblio.org>
> > > > > wrote:
> > > > >
> > > > > > On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau <
> > > > rmannibu...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi Elliotte,
> > > > > >
> > > > > > > Java 11 support is already EOL for most vendor until you go
> > "premium"
> > > > > > > flavor which will likely be very few people and most of them
> > will be
> > > > > able
> > > > > > > to pay somebody to backport the needed stuff in custom distro
> of
> > > > their
> > > > > > work
> > > > > > > if needed anyday so not sure we should consider it.
> > > > > >
> > > > > > At least three big tech companies I know of build their own JDKs.
> > At
> > > > > > least one, possibly two, ship and support older JDKs for their
> > > > > > customers. None of them are tied to Oracle and what Oracle is
> > willing
> > > > > > to support. If Oracle and all its data went to the great bit
> > bucket in
> > > > > > the sky tomorrow, they'd keep right on rolling. It would not even
> > be a
> > > > > > speed bump. They don't pay for premium support. They compete to
> > > > > > provide premium support.*
> > > > > >
> > > > > > * There are some caveats here I won't go into for confidentiality
> > > > 

Re: Java version for Maven 4?

[Tamás Cservenák]

Howdy,

For start, I think Martin assumed the "build time Java requirement for
Maven4"?

If so, my "vote" would be like:
* build time: "latest LTS" (fixed at the moment when 4.0.0 GA happens,
until then we just follow LTS), post GA "we adjust to latest LTS on each
minor release (so 4.1, 4.2, etc)"
* run time: this is the fun part: with Java 21 we already get a warning
that `release=8` is deprecated. So, basically that above introduces a hard
minimum limit (as given LTS allows). But I think we are with that, as it
really makes sense that a Java build (and comprehension bla bla) tool
_follow_ Java lifecycle, as things and new features are just flying past us
(think JPMS support in Maven), etc.

Example for similar setup that we already have:
* maven-resolver: build enforces Java 21, but most of modules are still
release=8, while some modules being release=11 and some are multi-release
JARs (baseline is release=8 but support present for up to 17).
* maven-indexer: here, dependency on Lucene 9.x (or 8.x? am unsure) made
project 11+, but similarly as in resolver, Java 11+ HttpClient is used,
etc. All modules are release=11.

In both cases projects require "latest LTS" _for building the project_ (oh,
and same is enforced for Maven, "latest Maven" is enforced). This just
makes us have less work to figure out why (would) it fail on someone etc...
We are sure requirements are fulfilled, and the one who builds it receives
"sane" error messages as well, making him able to "fix" (by updating Java
and/or Maven versions as needed). Again, all these serves _our benefit_, is
not something done "just for fun".

My 5 cents
T


On Tue, Feb 6, 2024 at 12:12 PM Olivier Lamy  wrote:

> Personnaly (take it as a vote), I find this a good idea to say:
> - 3.x: jdk 8 (whatever someone wants to release some fixes)
> - 4.x: jdk 17
>
>
> On Tue, 6 Feb 2024 at 20:50, Kévin Buntrock 
> wrote:
> >
> > From my modest point of view : glued to old stack projects do not move at
> > all. Why move to a new maven version if the one used works?
> >
> > Furthermore, I'm quite impressed by the number of projects starting in
> java
> > 21 for clients I was considering really shy new adopters. Java 21 is
> here,
> > works well, and gets adopted.
> >
> > Therefore, my vote goes to the current last LTS to run maven 4, a project
> > not even released.
> >
> > Le mar. 6 févr. 2024 à 09:00, Benjamin Marwell  a
> > écrit :
> >
> > > > we need to think about companies
> > > that pay for old JDK support
> > >
> > > There was a suggestion on slack that companies could provide "dev and
> > > release manager" for Maven 3 and manage the JDK 8 Maven 3 until they
> lose
> > > interest. This already works well for other projects.
> > >
> > > Even if no one stands up for volunteering: Maven 3 will continue to
> work
> > > just fine, even after releases of Maven 4.
> > >
> > >
> > > About the companies who run their own JDK team:
> > > Well, they made that a conscious decision. They surely had planned for
> > > versions after Java 8. If not, I don't see why we should take their
> problem
> > > and make it ours.
> > >
> > > - Ben
> > >
> > >
> > > On Mon, 5 Feb 2024, 23:15 Gary Gregory, 
> wrote:
> > >
> > > > An interesting question for me is whether we need to think about
> > > companies
> > > > that pay for old JDK support and how that affects our support for
> these
> > > old
> > > > JDKs.
> > > >
> > > > Gary
> > > >
> > > > On Mon, Feb 5, 2024, 4:28 PM Elliotte Rusty Harold <
> elh...@ibiblio.org>
> > > > wrote:
> > > >
> > > > > On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > Hi Elliotte,
> > > > >
> > > > > > Java 11 support is already EOL for most vendor until you go
> "premium"
> > > > > > flavor which will likely be very few people and most of them
> will be
> > > > able
> > > > > > to pay somebody to backport the needed stuff in custom distro of
> > > their
> > > > > work
> > > > > > if needed anyday so not sure we should consider it.
> > > > >
> > > > > At least three big tech companies I know of build their own JDKs.
> At
> > > > > least one, possibly two, ship and support older JDKs for their
> > > > > customers. None of them are tied to Oracle and what Oracle is
> willing
> > > > > to support. If Oracle and all its data went to the great bit
> bucket in
> > > > > the sky tomorrow, they'd keep right on rolling. It would not even
> be a
> > > > > speed bump. They don't pay for premium support. They compete to
> > > > > provide premium support.*
> > > > >
> > > > > * There are some caveats here I won't go into for confidentiality
> > > > > reasons, but I can say that Azul's business model works.
> > > > >
> > > > > > On the other side most libraries tend to move forward faster and
> if
> > > you
> > > > > > like big ones, i'll take Spring or JakartaEE as an example - big
> user
> > > > > base
> > > > > > rather than big company$ ;) - and they don't even support Java 11
> 

Re: Java version for Maven 4?

[Olivier Lamy]

Personnaly (take it as a vote), I find this a good idea to say:
- 3.x: jdk 8 (whatever someone wants to release some fixes)
- 4.x: jdk 17


On Tue, 6 Feb 2024 at 20:50, Kévin Buntrock  wrote:
>
> From my modest point of view : glued to old stack projects do not move at
> all. Why move to a new maven version if the one used works?
>
> Furthermore, I'm quite impressed by the number of projects starting in java
> 21 for clients I was considering really shy new adopters. Java 21 is here,
> works well, and gets adopted.
>
> Therefore, my vote goes to the current last LTS to run maven 4, a project
> not even released.
>
> Le mar. 6 févr. 2024 à 09:00, Benjamin Marwell  a
> écrit :
>
> > > we need to think about companies
> > that pay for old JDK support
> >
> > There was a suggestion on slack that companies could provide "dev and
> > release manager" for Maven 3 and manage the JDK 8 Maven 3 until they lose
> > interest. This already works well for other projects.
> >
> > Even if no one stands up for volunteering: Maven 3 will continue to work
> > just fine, even after releases of Maven 4.
> >
> >
> > About the companies who run their own JDK team:
> > Well, they made that a conscious decision. They surely had planned for
> > versions after Java 8. If not, I don't see why we should take their problem
> > and make it ours.
> >
> > - Ben
> >
> >
> > On Mon, 5 Feb 2024, 23:15 Gary Gregory,  wrote:
> >
> > > An interesting question for me is whether we need to think about
> > companies
> > > that pay for old JDK support and how that affects our support for these
> > old
> > > JDKs.
> > >
> > > Gary
> > >
> > > On Mon, Feb 5, 2024, 4:28 PM Elliotte Rusty Harold 
> > > wrote:
> > >
> > > > On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > > wrote:
> > > > >
> > > > > Hi Elliotte,
> > > >
> > > > > Java 11 support is already EOL for most vendor until you go "premium"
> > > > > flavor which will likely be very few people and most of them will be
> > > able
> > > > > to pay somebody to backport the needed stuff in custom distro of
> > their
> > > > work
> > > > > if needed anyday so not sure we should consider it.
> > > >
> > > > At least three big tech companies I know of build their own JDKs. At
> > > > least one, possibly two, ship and support older JDKs for their
> > > > customers. None of them are tied to Oracle and what Oracle is willing
> > > > to support. If Oracle and all its data went to the great bit bucket in
> > > > the sky tomorrow, they'd keep right on rolling. It would not even be a
> > > > speed bump. They don't pay for premium support. They compete to
> > > > provide premium support.*
> > > >
> > > > * There are some caveats here I won't go into for confidentiality
> > > > reasons, but I can say that Azul's business model works.
> > > >
> > > > > On the other side most libraries tend to move forward faster and if
> > you
> > > > > like big ones, i'll take Spring or JakartaEE as an example - big user
> > > > base
> > > > > rather than big company$ ;) - and they don't even support Java 11
> > > > anymore.
> > > >
> > > > Used by big tech customers. Not so much used by big tech companies
> > > > themselves, that tend to run on stacks developed in house over more
> > > > than a decade.
> > > >
> > > > --
> > > > 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: Java version for Maven 4?

[Kévin Buntrock]

>From my modest point of view : glued to old stack projects do not move at
all. Why move to a new maven version if the one used works?

Furthermore, I'm quite impressed by the number of projects starting in java
21 for clients I was considering really shy new adopters. Java 21 is here,
works well, and gets adopted.

Therefore, my vote goes to the current last LTS to run maven 4, a project
not even released.

Le mar. 6 févr. 2024 à 09:00, Benjamin Marwell  a
écrit :

> > we need to think about companies
> that pay for old JDK support
>
> There was a suggestion on slack that companies could provide "dev and
> release manager" for Maven 3 and manage the JDK 8 Maven 3 until they lose
> interest. This already works well for other projects.
>
> Even if no one stands up for volunteering: Maven 3 will continue to work
> just fine, even after releases of Maven 4.
>
>
> About the companies who run their own JDK team:
> Well, they made that a conscious decision. They surely had planned for
> versions after Java 8. If not, I don't see why we should take their problem
> and make it ours.
>
> - Ben
>
>
> On Mon, 5 Feb 2024, 23:15 Gary Gregory,  wrote:
>
> > An interesting question for me is whether we need to think about
> companies
> > that pay for old JDK support and how that affects our support for these
> old
> > JDKs.
> >
> > Gary
> >
> > On Mon, Feb 5, 2024, 4:28 PM Elliotte Rusty Harold 
> > wrote:
> >
> > > On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > > wrote:
> > > >
> > > > Hi Elliotte,
> > >
> > > > Java 11 support is already EOL for most vendor until you go "premium"
> > > > flavor which will likely be very few people and most of them will be
> > able
> > > > to pay somebody to backport the needed stuff in custom distro of
> their
> > > work
> > > > if needed anyday so not sure we should consider it.
> > >
> > > At least three big tech companies I know of build their own JDKs. At
> > > least one, possibly two, ship and support older JDKs for their
> > > customers. None of them are tied to Oracle and what Oracle is willing
> > > to support. If Oracle and all its data went to the great bit bucket in
> > > the sky tomorrow, they'd keep right on rolling. It would not even be a
> > > speed bump. They don't pay for premium support. They compete to
> > > provide premium support.*
> > >
> > > * There are some caveats here I won't go into for confidentiality
> > > reasons, but I can say that Azul's business model works.
> > >
> > > > On the other side most libraries tend to move forward faster and if
> you
> > > > like big ones, i'll take Spring or JakartaEE as an example - big user
> > > base
> > > > rather than big company$ ;) - and they don't even support Java 11
> > > anymore.
> > >
> > > Used by big tech customers. Not so much used by big tech companies
> > > themselves, that tend to run on stacks developed in house over more
> > > than a decade.
> > >
> > > --
> > > 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: Java version for Maven 4?

[Benjamin Marwell]

> we need to think about companies
that pay for old JDK support

There was a suggestion on slack that companies could provide "dev and
release manager" for Maven 3 and manage the JDK 8 Maven 3 until they lose
interest. This already works well for other projects.

Even if no one stands up for volunteering: Maven 3 will continue to work
just fine, even after releases of Maven 4.


About the companies who run their own JDK team:
Well, they made that a conscious decision. They surely had planned for
versions after Java 8. If not, I don't see why we should take their problem
and make it ours.

- Ben


On Mon, 5 Feb 2024, 23:15 Gary Gregory,  wrote:

> An interesting question for me is whether we need to think about companies
> that pay for old JDK support and how that affects our support for these old
> JDKs.
>
> Gary
>
> On Mon, Feb 5, 2024, 4:28 PM Elliotte Rusty Harold 
> wrote:
>
> > On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau  >
> > wrote:
> > >
> > > Hi Elliotte,
> >
> > > Java 11 support is already EOL for most vendor until you go "premium"
> > > flavor which will likely be very few people and most of them will be
> able
> > > to pay somebody to backport the needed stuff in custom distro of their
> > work
> > > if needed anyday so not sure we should consider it.
> >
> > At least three big tech companies I know of build their own JDKs. At
> > least one, possibly two, ship and support older JDKs for their
> > customers. None of them are tied to Oracle and what Oracle is willing
> > to support. If Oracle and all its data went to the great bit bucket in
> > the sky tomorrow, they'd keep right on rolling. It would not even be a
> > speed bump. They don't pay for premium support. They compete to
> > provide premium support.*
> >
> > * There are some caveats here I won't go into for confidentiality
> > reasons, but I can say that Azul's business model works.
> >
> > > On the other side most libraries tend to move forward faster and if you
> > > like big ones, i'll take Spring or JakartaEE as an example - big user
> > base
> > > rather than big company$ ;) - and they don't even support Java 11
> > anymore.
> >
> > Used by big tech customers. Not so much used by big tech companies
> > themselves, that tend to run on stacks developed in house over more
> > than a decade.
> >
> > --
> > 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: Java version for Maven 4?

[Xeno Amess]

well I just doubt.

From: Xeno Amess 
Sent: Tuesday, February 6, 2024 12:18:42 PM
To: Maven Developers List 
Subject: Re: Java version for Maven 4?

well nothing affensive but do any guys got any payments from those still-java-6 
companies for maintaining maven for them？

From: Gary Gregory 
Sent: Tuesday, February 6, 2024 6:14:32 AM
To: Maven Developers List 
Subject: Re: Java version for Maven 4?

An interesting question for me is whether we need to think about companies
that pay for old JDK support and how that affects our support for these old
JDKs.

Gary

On Mon, Feb 5, 2024, 4:28 PM Elliotte Rusty Harold 
wrote:

> On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau 
> wrote:
> >
> > Hi Elliotte,
>
> > Java 11 support is already EOL for most vendor until you go "premium"
> > flavor which will likely be very few people and most of them will be able
> > to pay somebody to backport the needed stuff in custom distro of their
> work
> > if needed anyday so not sure we should consider it.
>
> At least three big tech companies I know of build their own JDKs. At
> least one, possibly two, ship and support older JDKs for their
> customers. None of them are tied to Oracle and what Oracle is willing
> to support. If Oracle and all its data went to the great bit bucket in
> the sky tomorrow, they'd keep right on rolling. It would not even be a
> speed bump. They don't pay for premium support. They compete to
> provide premium support.*
>
> * There are some caveats here I won't go into for confidentiality
> reasons, but I can say that Azul's business model works.
>
> > On the other side most libraries tend to move forward faster and if you
> > like big ones, i'll take Spring or JakartaEE as an example - big user
> base
> > rather than big company$ ;) - and they don't even support Java 11
> anymore.
>
> Used by big tech customers. Not so much used by big tech companies
> themselves, that tend to run on stacks developed in house over more
> than a decade.
>
> --
> 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: Java version for Maven 4?

[Xeno Amess]

well nothing affensive but do any guys got any payments from those still-java-6 
companies for maintaining maven for them？

From: Gary Gregory 
Sent: Tuesday, February 6, 2024 6:14:32 AM
To: Maven Developers List 
Subject: Re: Java version for Maven 4?

An interesting question for me is whether we need to think about companies
that pay for old JDK support and how that affects our support for these old
JDKs.

Gary

On Mon, Feb 5, 2024, 4:28 PM Elliotte Rusty Harold 
wrote:

> On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau 
> wrote:
> >
> > Hi Elliotte,
>
> > Java 11 support is already EOL for most vendor until you go "premium"
> > flavor which will likely be very few people and most of them will be able
> > to pay somebody to backport the needed stuff in custom distro of their
> work
> > if needed anyday so not sure we should consider it.
>
> At least three big tech companies I know of build their own JDKs. At
> least one, possibly two, ship and support older JDKs for their
> customers. None of them are tied to Oracle and what Oracle is willing
> to support. If Oracle and all its data went to the great bit bucket in
> the sky tomorrow, they'd keep right on rolling. It would not even be a
> speed bump. They don't pay for premium support. They compete to
> provide premium support.*
>
> * There are some caveats here I won't go into for confidentiality
> reasons, but I can say that Azul's business model works.
>
> > On the other side most libraries tend to move forward faster and if you
> > like big ones, i'll take Spring or JakartaEE as an example - big user
> base
> > rather than big company$ ;) - and they don't even support Java 11
> anymore.
>
> Used by big tech customers. Not so much used by big tech companies
> themselves, that tend to run on stacks developed in house over more
> than a decade.
>
> --
> 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: Java version for Maven 4?

[Gary Gregory]

An interesting question for me is whether we need to think about companies
that pay for old JDK support and how that affects our support for these old
JDKs.

Gary

On Mon, Feb 5, 2024, 4:28 PM Elliotte Rusty Harold 
wrote:

> On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau 
> wrote:
> >
> > Hi Elliotte,
>
> > Java 11 support is already EOL for most vendor until you go "premium"
> > flavor which will likely be very few people and most of them will be able
> > to pay somebody to backport the needed stuff in custom distro of their
> work
> > if needed anyday so not sure we should consider it.
>
> At least three big tech companies I know of build their own JDKs. At
> least one, possibly two, ship and support older JDKs for their
> customers. None of them are tied to Oracle and what Oracle is willing
> to support. If Oracle and all its data went to the great bit bucket in
> the sky tomorrow, they'd keep right on rolling. It would not even be a
> speed bump. They don't pay for premium support. They compete to
> provide premium support.*
>
> * There are some caveats here I won't go into for confidentiality
> reasons, but I can say that Azul's business model works.
>
> > On the other side most libraries tend to move forward faster and if you
> > like big ones, i'll take Spring or JakartaEE as an example - big user
> base
> > rather than big company$ ;) - and they don't even support Java 11
> anymore.
>
> Used by big tech customers. Not so much used by big tech companies
> themselves, that tend to run on stacks developed in house over more
> than a decade.
>
> --
> 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: Java version for Maven 4?

[Elliotte Rusty Harold]

On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau  wrote:
>
> Hi Elliotte,

> Java 11 support is already EOL for most vendor until you go "premium"
> flavor which will likely be very few people and most of them will be able
> to pay somebody to backport the needed stuff in custom distro of their work
> if needed anyday so not sure we should consider it.

At least three big tech companies I know of build their own JDKs. At
least one, possibly two, ship and support older JDKs for their
customers. None of them are tied to Oracle and what Oracle is willing
to support. If Oracle and all its data went to the great bit bucket in
the sky tomorrow, they'd keep right on rolling. It would not even be a
speed bump. They don't pay for premium support. They compete to
provide premium support.*

* There are some caveats here I won't go into for confidentiality
reasons, but I can say that Azul's business model works.

> On the other side most libraries tend to move forward faster and if you
> like big ones, i'll take Spring or JakartaEE as an example - big user base
> rather than big company$ ;) - and they don't even support Java 11 anymore.

Used by big tech customers. Not so much used by big tech companies
themselves, that tend to run on stacks developed in house over more
than a decade.

-- 
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: Java version for Maven 4?

[Benjamin Marwell]

> I get the impression that folks who haven't worked in such large
> mono-repos aren't aware of just how big a multi-year effort it is to
> move a repo like that onto a new JDK version. And that's just the VM,
> even before you allow devs to change the language level and start
> using the new features and libraries. That's just the two really big
> mono-repos I have personally worked in. I'm willing to bet that some
> other big Java shops are in similar positions.

Sorry that I made the wrong impression. I know this is a big effort
from personal work experience.
But it can be done. It must be done. I asked the CI team to run all CI
builds with a parallel JDK 11 build,
and they did that. This way, it was easy to see which project was not
buildable using Java 11,
so teams could work on that.

For the apps I work on, my team uses all LTS versions plus the latest
GA version (if not an LTS release).
By the way, this was an excellent recommendation by a former IBM employee.

... and that was all done without raising the language level.

Besides that, most big (tech) companies do not allow unmaintained or
unsupported software.
I am puzzled how this could work out with the state of the libraries
you mentioned.
There must be other violations in the first place, and someone allowed
them to happen.
If they hadn't been allowed to happen, there would have been no need
to catch management attention.

> Switching back and forth between JDKs for open source development is
> doable but an unnecessary hassle.

I am puzzled why this would be needed. All Java 8 apps I know were
easy to build on Java 11 (with release=8)
after only very few adjustments.

That said, I do not think Apache Maven should wait for two companies
with mono-repos to update their technical debt.
It is just not justifiable for all the other users.

I agree with Gary that an EOL schedule might be our best shot here.

Am Mo., 5. Feb. 2024 um 19:56 Uhr schrieb Elliotte Rusty Harold
:
>
> On Mon, Feb 5, 2024 at 12:01 PM Benjamin Marwell  wrote:
>
> > Why 17? 11 is often earlier EOL'd than 8 and 17, so I see absolutely
> > no advantage of going to 11:
> >
>
> The advantage of going with 11 instead of 17 is that at least 2 really
> big tech companies I could name (and who you can probably guess from
> my linked in) have only recently completed their own migration to Java
> 11. At least one of those two companies might still employ a PMC
> member (though I haven't checked post-layoffs), maybe more than one.
> Both have actively supported Maven development over the years, though
> that support ebbs and flows depending on corporate priorities.
>
> I get the impression that folks who haven't worked in such large
> mono-repos aren't aware of just how big a multi-year effort it is to
> move a repo like that onto a new JDK version. And that's just the VM,
> even before you allow devs to change the language level and start
> using the new features and libraries. That's just the two really big
> mono-repos I have personally worked in. I'm willing to bet that some
> other big Java shops are in similar positions.
>
> Switching back and forth between JDKs for open source development is
> doable but an unnecessary hassle. I've done it before, but even
> switching from JDK 8 to 11 is an extra paper cut. It kills time every
> time spotless fails simply because I'm using Java 8 instead of 11.
>
> Most importantly, it will be even harder to sell management on the
> benefit of spending developer time on Maven 4 development, if it isn't
> suitable for that company's own open source projects which, last I
> checked, were still on Java 8. (OK, I just spot checked and the first
> one I looked at is in fact still compiling for Java *1.7*, probably
> because that's where their customers are).
>
> I'm thinking back to the projects I had to justify to management a few
> years and one company back, and it definitely would have been harder
> then if I had to tell them what we were contributing would only work
> on Java 11 or later. Maybe today I could sell them on Java 11 (or
> maybe not, if they aren't paying attention to Maven at all any more)
> but Java 17 would be a non-starter. They might prefer to spend their
> resources on a build tool they own, or maybe just not spend the dev
> hours at all.
>
> tldr: every uptick in version requirements bleeds that many more
> contributors out of the pool.
>
> --
> 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: Java version for Maven 4?

[Tamás Cservenák]

Howdy,

and sorry, I could not hold my breath...

Basically, you talk about some project somewhere that has been built with
Maven3 for the past 10 years. Fine: You can continue building it using the
same Maven3 for another 10 years, nothing stops you. But I see really
nothing, but really nothing that all this you wrote has to do with Maven4.

Again, nothing stops you to use Maven3 for another 10 years, but really. We
are not about to pull the plug on it, or whatever (as Maven4 GA is not yet
out nor will be in near future), and that pool of contributors you mention
can still freely contribute, and we will happily accept patches, as always.

/irony on
Just please pass to them, that project is under staffed, so if we get
overwhelmed count of PRs, processing may take some time.
/irony off

Thanks
T





On Mon, Feb 5, 2024 at 7:56 PM Elliotte Rusty Harold 
wrote:

> On Mon, Feb 5, 2024 at 12:01 PM Benjamin Marwell 
> wrote:
>
> > Why 17? 11 is often earlier EOL'd than 8 and 17, so I see absolutely
> > no advantage of going to 11:
> >
>
> The advantage of going with 11 instead of 17 is that at least 2 really
> big tech companies I could name (and who you can probably guess from
> my linked in) have only recently completed their own migration to Java
> 11. At least one of those two companies might still employ a PMC
> member (though I haven't checked post-layoffs), maybe more than one.
> Both have actively supported Maven development over the years, though
> that support ebbs and flows depending on corporate priorities.
>
> I get the impression that folks who haven't worked in such large
> mono-repos aren't aware of just how big a multi-year effort it is to
> move a repo like that onto a new JDK version. And that's just the VM,
> even before you allow devs to change the language level and start
> using the new features and libraries. That's just the two really big
> mono-repos I have personally worked in. I'm willing to bet that some
> other big Java shops are in similar positions.
>
> Switching back and forth between JDKs for open source development is
> doable but an unnecessary hassle. I've done it before, but even
> switching from JDK 8 to 11 is an extra paper cut. It kills time every
> time spotless fails simply because I'm using Java 8 instead of 11.
>
> Most importantly, it will be even harder to sell management on the
> benefit of spending developer time on Maven 4 development, if it isn't
> suitable for that company's own open source projects which, last I
> checked, were still on Java 8. (OK, I just spot checked and the first
> one I looked at is in fact still compiling for Java *1.7*, probably
> because that's where their customers are).
>
> I'm thinking back to the projects I had to justify to management a few
> years and one company back, and it definitely would have been harder
> then if I had to tell them what we were contributing would only work
> on Java 11 or later. Maybe today I could sell them on Java 11 (or
> maybe not, if they aren't paying attention to Maven at all any more)
> but Java 17 would be a non-starter. They might prefer to spend their
> resources on a build tool they own, or maybe just not spend the dev
> hours at all.
>
> tldr: every uptick in version requirements bleeds that many more
> contributors out of the pool.
>
> --
> 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: Java version for Maven 4?

[Romain Manni-Bucau]

Hi Elliotte,

While I share the wish 1 repo = 1 JDK, I have a hard time to see how any
company - including the ones you cite - can seriously bet on Java 11 today
for the future (not saying it wasnt hard to reach Java 11 today but we are
discussing on what we'll do tomorrow) and why it would pushback the
constraint to all the related tools.
Java 11 support is already EOL for most vendor until you go "premium"
flavor which will likely be very few people and most of them will be able
to pay somebody to backport the needed stuff in custom distro of their work
if needed anyday so not sure we should consider it.
On the other side most libraries tend to move forward faster and if you
like big ones, i'll take Spring or JakartaEE as an example - big user base
rather than big company$ ;) - and they don't even support Java 11 anymore.
So we go with Java 11 with our Maven 4 we'll likely be off most of our
users, increase potential contributors work (think PR and needed builds to
pass) without any actual gain for the project overall except maybe a few
big vendors with part of them already migrated out of maven or even
building their own build system.
I'm not sure I see it as a very weighty in the balance from my window.
So in terms of schedule - I know, the thread about EOL and maintenance got
quite closed so it will never be a thing at Maven - I think we should
embrace the future and ensure we follow main practises rather than looking
a few people cause we are about community more than companies.

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



Le lun. 5 févr. 2024 à 19:56, Elliotte Rusty Harold  a
écrit :

> On Mon, Feb 5, 2024 at 12:01 PM Benjamin Marwell 
> wrote:
>
> > Why 17? 11 is often earlier EOL'd than 8 and 17, so I see absolutely
> > no advantage of going to 11:
> >
>
> The advantage of going with 11 instead of 17 is that at least 2 really
> big tech companies I could name (and who you can probably guess from
> my linked in) have only recently completed their own migration to Java
> 11. At least one of those two companies might still employ a PMC
> member (though I haven't checked post-layoffs), maybe more than one.
> Both have actively supported Maven development over the years, though
> that support ebbs and flows depending on corporate priorities.
>
> I get the impression that folks who haven't worked in such large
> mono-repos aren't aware of just how big a multi-year effort it is to
> move a repo like that onto a new JDK version. And that's just the VM,
> even before you allow devs to change the language level and start
> using the new features and libraries. That's just the two really big
> mono-repos I have personally worked in. I'm willing to bet that some
> other big Java shops are in similar positions.
>
> Switching back and forth between JDKs for open source development is
> doable but an unnecessary hassle. I've done it before, but even
> switching from JDK 8 to 11 is an extra paper cut. It kills time every
> time spotless fails simply because I'm using Java 8 instead of 11.
>
> Most importantly, it will be even harder to sell management on the
> benefit of spending developer time on Maven 4 development, if it isn't
> suitable for that company's own open source projects which, last I
> checked, were still on Java 8. (OK, I just spot checked and the first
> one I looked at is in fact still compiling for Java *1.7*, probably
> because that's where their customers are).
>
> I'm thinking back to the projects I had to justify to management a few
> years and one company back, and it definitely would have been harder
> then if I had to tell them what we were contributing would only work
> on Java 11 or later. Maybe today I could sell them on Java 11 (or
> maybe not, if they aren't paying attention to Maven at all any more)
> but Java 17 would be a non-starter. They might prefer to spend their
> resources on a build tool they own, or maybe just not spend the dev
> hours at all.
>
> tldr: every uptick in version requirements bleeds that many more
> contributors out of the pool.
>
> --
> 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: Java version for Maven 4?

[Gary Gregory]

Based on my experience, I think we (FOSS developers) can create our own
momentum by "simply" creating an EOL schedule. I have seen this EOL aspect
motivate the move away from Jetty 9 for example. Since Maven 4 is not out,
there is nothing to EOL in Maven 3 land unless you want to say that only
3.9.x is maintained and old versions are on an EOL schedule of x.

Gary

On Mon, Feb 5, 2024, 1:56 PM Elliotte Rusty Harold 
wrote:

> On Mon, Feb 5, 2024 at 12:01 PM Benjamin Marwell 
> wrote:
>
> > Why 17? 11 is often earlier EOL'd than 8 and 17, so I see absolutely
> > no advantage of going to 11:
> >
>
> The advantage of going with 11 instead of 17 is that at least 2 really
> big tech companies I could name (and who you can probably guess from
> my linked in) have only recently completed their own migration to Java
> 11. At least one of those two companies might still employ a PMC
> member (though I haven't checked post-layoffs), maybe more than one.
> Both have actively supported Maven development over the years, though
> that support ebbs and flows depending on corporate priorities.
>
> I get the impression that folks who haven't worked in such large
> mono-repos aren't aware of just how big a multi-year effort it is to
> move a repo like that onto a new JDK version. And that's just the VM,
> even before you allow devs to change the language level and start
> using the new features and libraries. That's just the two really big
> mono-repos I have personally worked in. I'm willing to bet that some
> other big Java shops are in similar positions.
>
> Switching back and forth between JDKs for open source development is
> doable but an unnecessary hassle. I've done it before, but even
> switching from JDK 8 to 11 is an extra paper cut. It kills time every
> time spotless fails simply because I'm using Java 8 instead of 11.
>
> Most importantly, it will be even harder to sell management on the
> benefit of spending developer time on Maven 4 development, if it isn't
> suitable for that company's own open source projects which, last I
> checked, were still on Java 8. (OK, I just spot checked and the first
> one I looked at is in fact still compiling for Java *1.7*, probably
> because that's where their customers are).
>
> I'm thinking back to the projects I had to justify to management a few
> years and one company back, and it definitely would have been harder
> then if I had to tell them what we were contributing would only work
> on Java 11 or later. Maybe today I could sell them on Java 11 (or
> maybe not, if they aren't paying attention to Maven at all any more)
> but Java 17 would be a non-starter. They might prefer to spend their
> resources on a build tool they own, or maybe just not spend the dev
> hours at all.
>
> tldr: every uptick in version requirements bleeds that many more
> contributors out of the pool.
>
> --
> 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: Java version for Maven 4?

[Elliotte Rusty Harold]

On Mon, Feb 5, 2024 at 12:01 PM Benjamin Marwell  wrote:

> Why 17? 11 is often earlier EOL'd than 8 and 17, so I see absolutely
> no advantage of going to 11:
>

The advantage of going with 11 instead of 17 is that at least 2 really
big tech companies I could name (and who you can probably guess from
my linked in) have only recently completed their own migration to Java
11. At least one of those two companies might still employ a PMC
member (though I haven't checked post-layoffs), maybe more than one.
Both have actively supported Maven development over the years, though
that support ebbs and flows depending on corporate priorities.

I get the impression that folks who haven't worked in such large
mono-repos aren't aware of just how big a multi-year effort it is to
move a repo like that onto a new JDK version. And that's just the VM,
even before you allow devs to change the language level and start
using the new features and libraries. That's just the two really big
mono-repos I have personally worked in. I'm willing to bet that some
other big Java shops are in similar positions.

Switching back and forth between JDKs for open source development is
doable but an unnecessary hassle. I've done it before, but even
switching from JDK 8 to 11 is an extra paper cut. It kills time every
time spotless fails simply because I'm using Java 8 instead of 11.

Most importantly, it will be even harder to sell management on the
benefit of spending developer time on Maven 4 development, if it isn't
suitable for that company's own open source projects which, last I
checked, were still on Java 8. (OK, I just spot checked and the first
one I looked at is in fact still compiling for Java *1.7*, probably
because that's where their customers are).

I'm thinking back to the projects I had to justify to management a few
years and one company back, and it definitely would have been harder
then if I had to tell them what we were contributing would only work
on Java 11 or later. Maybe today I could sell them on Java 11 (or
maybe not, if they aren't paying attention to Maven at all any more)
but Java 17 would be a non-starter. They might prefer to spend their
resources on a build tool they own, or maybe just not spend the dev
hours at all.

tldr: every uptick in version requirements bleeds that many more
contributors out of the pool.

-- 
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: Java version for Maven 4?

[Benjamin Marwell]

Those who need Java 8 to *run* Maven will probably not upgrade to
Maven 4 anyway, as their builds will have other problems preventing
them from upgrading.
A few third-party plugins already moved to Java 11+, thinking of spotless.

That said:

+1 Stick with 8 for Maven 3.9.x and maybe a 3.10.x (not part of this thread)
+1 to use Java 17 for Maven 4.

Why 17? 11 is often earlier EOL'd than 8 and 17, so I see absolutely
no advantage of going to 11:

* https://endoflife.date/ibm-semeru-runtime
* https://endoflife.date/azul-zulu
* https://endoflife.date/bellsoft-liberica
* https://endoflife.date/eclipse-temurin (on par here)
* https://endoflife.date/oracle-jdk (valid for premier support, not
for extended support)

Am So., 4. Feb. 2024 um 15:01 Uhr schrieb Elliotte Rusty Harold
:
>
> If we're actually voting
>
> +1 for Java 8
> -1 for Java 17 or any later version.
>
> I can live with Java 11 if I have to, though I really don't see the
> point. Anything past Java 11 ranges from a major hassle to blocker for
> corporate developers, including those at big tech companies like Meta
> and Google, who are stuck on older versions as a matter of policy and
> internal support.
>
> On Sat, Feb 3, 2024 at 2:17 PM Martin Desruisseaux
>  wrote:
> >
> > Hello
> >
> >  From the replies in this thread, it seems to me that there is a
> > consensus for moving Maven 4 to some Java version after 8. I see:
> >
> >   * 0 in favour of Java 11
> >   * 1.5 in favour of Java 17 (the .5 is because I split a vote between
> > Java 17 and 21)
> >   * 2.5 in favour of Java 21
> >   * 4 seem neutral (including myself)
> >
> > Do we take that as an agreement to require Java 21 for building Maven 4?
> >
> > On a related question, what should be the minimal Java version for
> > *running* Maven 4? Keeping in mind that if Java 21 (for example) was
> > required, users would still be able to compile for an older Java version
> > using the --release option.
> >
> >  Martin
> >
>
>
> --
> 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: Java version for Maven 4?

[Xeno Amess]

I vote for kill jdk8 out as to force them upgrade to 11+

From: Tamás Cservenák 
Sent: Sunday, February 4, 2024 10:35:55 PM
To: Maven Developers List 
Subject: Re: Java version for Maven 4?

Howdy,

See Inline.

On Sun, Feb 4, 2024 at 3:01 PM Elliotte Rusty Harold 
wrote:

> I can live with Java 11 if I have to, though I really don't see the
> point. Anything past Java 11 ranges from a major hassle to blocker for
> corporate developers, including those at big tech companies like Meta
> and Google, who are stuck on older versions as a matter of policy and
> internal support.
>
>
I see no problem here, those who are stuck with Java 8, can stick (sorry
for the pun) with Maven 3.9.x forever as well.

This thread is about Maven4, and its GA is still far away, so I see no need
for it to adapt somewhere in the unknown-how-far future (once it becomes
GA) for the sake of those who are stuck in the past.



Thanks
T



> On Sat, Feb 3, 2024 at 2:17 PM Martin Desruisseaux
>  wrote:
> >
> > Hello
> >
> >  From the replies in this thread, it seems to me that there is a
> > consensus for moving Maven 4 to some Java version after 8. I see:
> >
> >   * 0 in favour of Java 11
> >   * 1.5 in favour of Java 17 (the .5 is because I split a vote between
> > Java 17 and 21)
> >   * 2.5 in favour of Java 21
> >   * 4 seem neutral (including myself)
> >
> > Do we take that as an agreement to require Java 21 for building Maven 4?
> >
> > On a related question, what should be the minimal Java version for
> > *running* Maven 4? Keeping in mind that if Java 21 (for example) was
> > required, users would still be able to compile for an older Java version
> > using the --release option.
> >
> >  Martin
> >
>
>
> --
> 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: Java version for Maven 4?

[Tamás Cservenák]

Howdy,

See Inline.

On Sun, Feb 4, 2024 at 3:01 PM Elliotte Rusty Harold 
wrote:

> I can live with Java 11 if I have to, though I really don't see the
> point. Anything past Java 11 ranges from a major hassle to blocker for
> corporate developers, including those at big tech companies like Meta
> and Google, who are stuck on older versions as a matter of policy and
> internal support.
>
>
I see no problem here, those who are stuck with Java 8, can stick (sorry
for the pun) with Maven 3.9.x forever as well.

This thread is about Maven4, and its GA is still far away, so I see no need
for it to adapt somewhere in the unknown-how-far future (once it becomes
GA) for the sake of those who are stuck in the past.



Thanks
T



> On Sat, Feb 3, 2024 at 2:17 PM Martin Desruisseaux
>  wrote:
> >
> > Hello
> >
> >  From the replies in this thread, it seems to me that there is a
> > consensus for moving Maven 4 to some Java version after 8. I see:
> >
> >   * 0 in favour of Java 11
> >   * 1.5 in favour of Java 17 (the .5 is because I split a vote between
> > Java 17 and 21)
> >   * 2.5 in favour of Java 21
> >   * 4 seem neutral (including myself)
> >
> > Do we take that as an agreement to require Java 21 for building Maven 4?
> >
> > On a related question, what should be the minimal Java version for
> > *running* Maven 4? Keeping in mind that if Java 21 (for example) was
> > required, users would still be able to compile for an older Java version
> > using the --release option.
> >
> >  Martin
> >
>
>
> --
> 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: Java version for Maven 4?

[Gary Gregory]

FWIW, I work for a large company and our business unit just switched to
Java 17 after eons on Java 8. I think requiring Java 17 or 21 to run Maven
is fine. The existing tooling supports generating Java 8 binaries for those
who need it.

Gary

On Sun, Feb 4, 2024, 9:01 AM Elliotte Rusty Harold 
wrote:

> If we're actually voting
>
> +1 for Java 8
> -1 for Java 17 or any later version.
>
> I can live with Java 11 if I have to, though I really don't see the
> point. Anything past Java 11 ranges from a major hassle to blocker for
> corporate developers, including those at big tech companies like Meta
> and Google, who are stuck on older versions as a matter of policy and
> internal support.
>
> On Sat, Feb 3, 2024 at 2:17 PM Martin Desruisseaux
>  wrote:
> >
> > Hello
> >
> >  From the replies in this thread, it seems to me that there is a
> > consensus for moving Maven 4 to some Java version after 8. I see:
> >
> >   * 0 in favour of Java 11
> >   * 1.5 in favour of Java 17 (the .5 is because I split a vote between
> > Java 17 and 21)
> >   * 2.5 in favour of Java 21
> >   * 4 seem neutral (including myself)
> >
> > Do we take that as an agreement to require Java 21 for building Maven 4?
> >
> > On a related question, what should be the minimal Java version for
> > *running* Maven 4? Keeping in mind that if Java 21 (for example) was
> > required, users would still be able to compile for an older Java version
> > using the --release option.
> >
> >  Martin
> >
>
>
> --
> 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: Java version for Maven 4?

[Elliotte Rusty Harold]

If we're actually voting

+1 for Java 8
-1 for Java 17 or any later version.

I can live with Java 11 if I have to, though I really don't see the
point. Anything past Java 11 ranges from a major hassle to blocker for
corporate developers, including those at big tech companies like Meta
and Google, who are stuck on older versions as a matter of policy and
internal support.

On Sat, Feb 3, 2024 at 2:17 PM Martin Desruisseaux
 wrote:
>
> Hello
>
>  From the replies in this thread, it seems to me that there is a
> consensus for moving Maven 4 to some Java version after 8. I see:
>
>   * 0 in favour of Java 11
>   * 1.5 in favour of Java 17 (the .5 is because I split a vote between
> Java 17 and 21)
>   * 2.5 in favour of Java 21
>   * 4 seem neutral (including myself)
>
> Do we take that as an agreement to require Java 21 for building Maven 4?
>
> On a related question, what should be the minimal Java version for
> *running* Maven 4? Keeping in mind that if Java 21 (for example) was
> required, users would still be able to compile for an older Java version
> using the --release option.
>
>  Martin
>


-- 
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: Java version for Maven 4?

[Christoph Läubrich]

If maven itself can (and want) to stick to older java versions, can then 
please this one kindly be considered:


https://issues.apache.org/jira/browse/MNG-8040

for example the tycho-maven-plugin (and probably others as well) the 
issue is that *dependencies* of the project have moved to higher 
versions, so one either can't get bugfixes/new features anymore or 
require a higher version implicitly (currently java 17 for Tycho but 
soon Java 21).


Giving plugins the opportunity to declare minimum version and maven give 
good error message instead of fail would be very helpful.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Java version for Maven 4?

[Romain Manni-Bucau]

Side note: dont think toolchain enhancements is a requirement at all, lot
of users keep rejecting this additional work (and to be honest I can agree
1nd it does not help more things than using properties to switch the
env/executable in plugins) so only question for me is the baseline and
minimum requirement when 4 will be final.
It is probably wise to start fresh since it will be frozen for years so the
lts at that moment does not sound crazy to not cumulate debts before
starting.

Le sam. 3 févr. 2024 à 16:43, Tamás Cservenák  a
écrit :

> Similarly, this topic (to me at least) somewhat correlates with another
> "wrong reflex" (that somehow get roots in project):
> - compile against maven-core 3.2.5
> - compile with Java 8+ "as we support Maven on Java 8"
> Funnily, both are from 2014, just 10 years old.
>
> IMHO,
> We SHOULD compile against the latest, to pick up the latest deprecations,
> and not be "detached", but follow changes in core (and resolver).
> We SHOULD compile with latest to benefit from latest improvements (how many
> of us said just one thing: is FASTer to build on 21.0.2 than 8.xxx).
> Javadoc is the third (important) thing, and more will just come...
>
> And so on...
>
> T
>
> On Sat, Feb 3, 2024 at 4:36 PM Tamás Cservenák 
> wrote:
>
> > The non problems:
> > - members building project with ancient java versions and calling -1 on
> > release votes (as turns out,by mistake)
> > - javadoc inconsistencies: what is allowed and what not
> > - being stuck in a 20 year tech stack
> > ...
> >
> > Again, _build time requirement_ has nothing to do with _runtime
> > requirement_.
> >
> > Or in other words, a bit of rephrasing:
> > For example, desktop app devs who develop apps "certified to work on
> older
> > OS-es (than current)" _develop those apps on "lower end" of supported
> OSes
> > version_?
> > So, if a macOS app CAN work on macOS 12 (current is 14), it MUST be
> > developed on macOS 12?
> >
> >
> >
> >
> > On Sat, Feb 3, 2024, 16:25 Michael Osipov  wrote:
> >
> >> Am 2024-02-03 um 15:16 schrieb Martin Desruisseaux:
> >> > Hello
> >> >
> >> >  From the replies in this thread, it seems to me that there is a
> >> > consensus for moving Maven 4 to some Java version after 8. I see:
> >> >
> >> >   * 0 in favour of Java 11
> >> >   * 1.5 in favour of Java 17 (the .5 is because I split a vote between
> >> > Java 17 and 21)
> >> >   * 2.5 in favour of Java 21
> >> >   * 4 seem neutral (including myself)
> >> >
> >> > Do we take that as an agreement to require Java 21 for building Maven
> 4?
> >> >
> >> > On a related question, what should be the minimal Java version for
> >> > *running* Maven 4? Keeping in mind that if Java 21 (for example) was
> >> > required, users would still be able to compile for an older Java
> >> version
> >> > using the --release option.
> >>
> >> I still don't understand what non-problem you are trying to solve here?!
> >> I think that your time and our time would be better invested in solving
> >> real problems, just look into JIRA how many issues have piled up.
> >>
> >> M
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >
>

Re: Java version for Maven 4?

[Tamás Cservenák]

Similarly, this topic (to me at least) somewhat correlates with another
"wrong reflex" (that somehow get roots in project):
- compile against maven-core 3.2.5
- compile with Java 8+ "as we support Maven on Java 8"
Funnily, both are from 2014, just 10 years old.

IMHO,
We SHOULD compile against the latest, to pick up the latest deprecations,
and not be "detached", but follow changes in core (and resolver).
We SHOULD compile with latest to benefit from latest improvements (how many
of us said just one thing: is FASTer to build on 21.0.2 than 8.xxx).
Javadoc is the third (important) thing, and more will just come...

And so on...

T

On Sat, Feb 3, 2024 at 4:36 PM Tamás Cservenák  wrote:

> The non problems:
> - members building project with ancient java versions and calling -1 on
> release votes (as turns out,by mistake)
> - javadoc inconsistencies: what is allowed and what not
> - being stuck in a 20 year tech stack
> ...
>
> Again, _build time requirement_ has nothing to do with _runtime
> requirement_.
>
> Or in other words, a bit of rephrasing:
> For example, desktop app devs who develop apps "certified to work on older
> OS-es (than current)" _develop those apps on "lower end" of supported OSes
> version_?
> So, if a macOS app CAN work on macOS 12 (current is 14), it MUST be
> developed on macOS 12?
>
>
>
>
> On Sat, Feb 3, 2024, 16:25 Michael Osipov  wrote:
>
>> Am 2024-02-03 um 15:16 schrieb Martin Desruisseaux:
>> > Hello
>> >
>> >  From the replies in this thread, it seems to me that there is a
>> > consensus for moving Maven 4 to some Java version after 8. I see:
>> >
>> >   * 0 in favour of Java 11
>> >   * 1.5 in favour of Java 17 (the .5 is because I split a vote between
>> > Java 17 and 21)
>> >   * 2.5 in favour of Java 21
>> >   * 4 seem neutral (including myself)
>> >
>> > Do we take that as an agreement to require Java 21 for building Maven 4?
>> >
>> > On a related question, what should be the minimal Java version for
>> > *running* Maven 4? Keeping in mind that if Java 21 (for example) was
>> > required, users would still be able to compile for an older Java
>> version
>> > using the --release option.
>>
>> I still don't understand what non-problem you are trying to solve here?!
>> I think that your time and our time would be better invested in solving
>> real problems, just look into JIRA how many issues have piled up.
>>
>> M
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>

Re: Java version for Maven 4?

[Tamás Cservenák]

The non problems:
- members building project with ancient java versions and calling -1 on
release votes (as turns out,by mistake)
- javadoc inconsistencies: what is allowed and what not
- being stuck in a 20 year tech stack
...

Again, _build time requirement_ has nothing to do with _runtime
requirement_.

Or in other words, a bit of rephrasing:
For example, desktop app devs who develop apps "certified to work on older
OS-es (than current)" _develop those apps on "lower end" of supported OSes
version_?
So, if a macOS app CAN work on macOS 12 (current is 14), it MUST be
developed on macOS 12?




On Sat, Feb 3, 2024, 16:25 Michael Osipov  wrote:

> Am 2024-02-03 um 15:16 schrieb Martin Desruisseaux:
> > Hello
> >
> >  From the replies in this thread, it seems to me that there is a
> > consensus for moving Maven 4 to some Java version after 8. I see:
> >
> >   * 0 in favour of Java 11
> >   * 1.5 in favour of Java 17 (the .5 is because I split a vote between
> > Java 17 and 21)
> >   * 2.5 in favour of Java 21
> >   * 4 seem neutral (including myself)
> >
> > Do we take that as an agreement to require Java 21 for building Maven 4?
> >
> > On a related question, what should be the minimal Java version for
> > *running* Maven 4? Keeping in mind that if Java 21 (for example) was
> > required, users would still be able to compile for an older Java version
> > using the --release option.
>
> I still don't understand what non-problem you are trying to solve here?!
> I think that your time and our time would be better invested in solving
> real problems, just look into JIRA how many issues have piled up.
>
> M
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

Re: Java version for Maven 4?

[Martin Desruisseaux]

Le 2024-02-03 à 16 h 25, Michael Osipov a écrit :

I still don't understand what non-problem you are trying to solve 
here?! I think that your time and our time would be better invested in 
solving real problems, just look into JIRA how many issues have piled up.


For the Java version topic, it is impossible to use HTML headings in 
Javadoc in a way compatible with both Java 11 and Java 17. If the build 
passes on one version, it fails on the other, unless compile-time 
Javadoc checks are disabled. This topic was raised because it was the 
cause of CI failures in pull request.


On the larger topic, the problem that I'm trying to resolve is JPMS 
support in Maven 4.


    Martin



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Java version for Maven 4?

[Michael Osipov]

Am 2024-02-03 um 15:16 schrieb Martin Desruisseaux:

Hello

 From the replies in this thread, it seems to me that there is a 
consensus for moving Maven 4 to some Java version after 8. I see:


  * 0 in favour of Java 11
  * 1.5 in favour of Java 17 (the .5 is because I split a vote between
    Java 17 and 21)
  * 2.5 in favour of Java 21
  * 4 seem neutral (including myself)

Do we take that as an agreement to require Java 21 for building Maven 4?

On a related question, what should be the minimal Java version for 
*running* Maven 4? Keeping in mind that if Java 21 (for example) was 
required, users would still be able to compile for an older Java version 
using the --release option.


I still don't understand what non-problem you are trying to solve here?! 
I think that your time and our time would be better invested in solving 
real problems, just look into JIRA how many issues have piled up.


M


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Java version for Maven 4?

[Guillaume Nodet]

Before actually changing the runtime requirement, I’d like to make sure we
have good enough support for toolchains on the dev side and in CI (Jenkins,
GitHub actions…).
On the dev side, I once proposed to have an easy integration with sdkman, I
think I did raise a PR for that months ago…


Guillaume Nodet



Le sam. 3 févr. 2024 à 15:17, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Hello
>
>  From the replies in this thread, it seems to me that there is a
> consensus for moving Maven 4 to some Java version after 8. I see:
>
>   * 0 in favour of Java 11
>   * 1.5 in favour of Java 17 (the .5 is because I split a vote between
> Java 17 and 21)
>   * 2.5 in favour of Java 21
>   * 4 seem neutral (including myself)
>
> Do we take that as an agreement to require Java 21 for building Maven 4?
>
> On a related question, what should be the minimal Java version for
> *running* Maven 4? Keeping in mind that if Java 21 (for example) was
> required, users would still be able to compile for an older Java version
> using the --release option.
>
>  Martin
>
>

Re: Java version for Maven 4?

[Martin Desruisseaux]

Hello

From the replies in this thread, it seems to me that there is a 
consensus for moving Maven 4 to some Java version after 8. I see:


 * 0 in favour of Java 11
 * 1.5 in favour of Java 17 (the .5 is because I split a vote between
   Java 17 and 21)
 * 2.5 in favour of Java 21
 * 4 seem neutral (including myself)

Do we take that as an agreement to require Java 21 for building Maven 4?

On a related question, what should be the minimal Java version for 
*running* Maven 4? Keeping in mind that if Java 21 (for example) was 
required, users would still be able to compile for an older Java version 
using the --release option.


    Martin

Re: Java version for Maven 4?

[Matthias Bünger]

I'm close to Ben and Manfred,

I think Maven can get a lot of value (for maintaining as for runtime) by
switching to Maven 21 a base for itself.

Matthias

Am 22.01.2024 um 13:33 schrieb Benjamin Marwell:

To add some more information, I have seen some extreme reduction in
build times after switching from Java 11 to 17 or even 21 (just for
build, not the runtime).
We can still verify it runs on 11/17 by using the integration tests,
but having the (possibly parallel) unit- and integration tests
compile, run and package on 21 is an *extreme* improvement in build
time.

As always, YMMV. But why waste time...

Since with Semeru and Temurin all major vendors have published their
JDK21 at last,
I see no reason to use a lower Java version to build maven with.
It is easily available for everyone who wants to contribute.

If I read the thread correctly, there were no objections to raising
the build time requirements.

It will also remove a lot of unneeded profiles (Java 8 Javadoc fix,
possibly build chains and module-info profiles),
in case any of those are present.

- Ben

-
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: Java version for Maven 4?

[Guillaume Nodet]

Le lun. 22 janv. 2024 à 09:52, Hervé Boutemy  a écrit :
>
> Le dimanche 21 janvier 2024, 22:03:59 CET Guillaume Nodet a écrit :
> > At build time, I think it's fine to bump to whatever is needed to make
> > our life manageable. If 17 is required, so be it.
> +1
>
> my biggest concern with Maven 4 is not JDK runtime requirement, but plugins
> future when a plugin wants to be able to use the new Maven 4 API
>
> IIUC, Maven 4 has a compatibility layer to run Maven Plugin 3.x (= built with
> Maven 3 plugin API).
> On our core plugins, there is a Maven 4 branch that tests what the plugin
> would become when it migrates to new Maven 4 API (and check that Maven 4 API
> works as expected)
>
> But IIUC, once a plugin uses Maven 4 API, it de-facto cannot be run on Maven 3
>
> Questions:
> - is that true at plugin level or goal level?

It has to be at the plugin level.  The main reason is that all goals
share the same
classloader and the rules to build the classloader will very probably change
between the Maven 3 API and the Maven 4 API, as the Maven 4 API should
provide a much smaller class loader than the current one.
See https://issues.apache.org/jira/browse/MNG-7955

> - new Maven 4 API for now is not so much about providing new features, but
> improving/clarifying plugin  expectations from Maven core: are there known
> features in Maven 4 API not available in Maven 3 that would bring stronger
> interest in writing a goal for Maven 4?
>
> concern: does it mean that we either should not upgrade our master branches to
> Maven 4 API too early? Will we need to maintain a 3.x branch in parallel to 4/
> main branch?
> And the questions I have for plugins maintained at Maven project level will
> impact every third party plugin maintainer: we need to make things explicit,
> IMHO
> The JVM upgrade in parallel IMHO is less a concern, as it is a consequence of
> previous plugin prerequisite choice on Maven
>
> Hervé
>
> >
> > Guillaume
> >
> > Le sam. 20 janv. 2024 à 19:18, Martin Desruisseaux
> >
> >  a écrit :
> > > Hello
> > >
> > > I would like a little clarification about the Java version for Maven 4.
> > > I saw debate on this mailing list, but has a decision been reached? I
> > > got the impression that Maven 4 would require Java 11, but last time I
> > > checked, the pom.xml file was still declaring Java 8 as the target. If
> > > Java 11 is the target, updating the pom.xml would unlock some features
> > > and make some code a little bit simpler.
> > >
> > > Related question: even if Maven 4 targets Java 8 or 11, would it be
> > > acceptable to require Java 17 with `--release 8` or `--release 11`
> > > option only for Maven 4 compilation (not execution)? I ask because as
> > > far as I know, we cannot write code buildable with both Java 11 and Java
> > > 17 if the code uses HTML headings in Javadoc comments and the Javadoc
> > > checks are enabled. If the project builds on Java 11, then it fails on
> > > Java 17. Or if it builds on Java 17, then it fails on Java 11. For
> > > building on both versions, we must either avoid HTML headings, or
> > > disable Javadoc checks (more details at [1]). Using HTML headings is not
> > > very important, so they could be removed. But the `--release 11`
> > > approach would allow a more gradual transition to newest Java versions
> > > while preserving compatibility for users.
> > >
> > >  Martin
> > >
> > > [1]https://github.com/apache/maven/pull/1378#issuecomment-1902173221
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 

Guillaume Nodet

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Java version for Maven 4?

[Manfred Moser]

I agree with observations ... in the Trino project we switched to 
require Java 17 ages ago and now switched to 21 for the project itself. 
The language improvements to 17 and then to 21 allow for a lot of code 
improvements on the source level.


As a build tool that supports building other versions and has a huge 
codebase the case for allowing as many improvements as possible can not 
the underappreciated. I vote for at least having 17 as requirement and 
would also be fine with 21. After all by the time Maven 4 really 
stabilizes and becomes commonly used we are probably close to the next LTS.


Manfred


On 2024-01-22 4:33 a.m., Benjamin Marwell wrote:

To add some more information, I have seen some extreme reduction in
build times after switching from Java 11 to 17 or even 21 (just for
build, not the runtime).
We can still verify it runs on 11/17 by using the integration tests,
but having the (possibly parallel) unit- and integration tests
compile, run and package on 21 is an *extreme* improvement in build
time.

As always, YMMV. But why waste time...

Since with Semeru and Temurin all major vendors have published their
JDK21 at last,
I see no reason to use a lower Java version to build maven with.
It is easily available for everyone who wants to contribute.

If I read the thread correctly, there were no objections to raising
the build time requirements.

It will also remove a lot of unneeded profiles (Java 8 Javadoc fix,
possibly build chains and module-info profiles),
in case any of those are present.

- Ben

-
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: Java version for Maven 4?

[Romain Manni-Bucau]

Le lun. 22 janv. 2024 à 13:34, Benjamin Marwell  a
écrit :

> To add some more information, I have seen some extreme reduction in
> build times after switching from Java 11 to 17 or even 21 (just for
> build, not the runtime).
> We can still verify it runs on 11/17 by using the integration tests,
> but having the (possibly parallel) unit- and integration tests
> compile, run and package on 21 is an *extreme* improvement in build
> time.
>
> As always, YMMV. But why waste time...
>
> Since with Semeru and Temurin all major vendors have published their
> JDK21 at last,
> I see no reason to use a lower Java version to build maven with.
> It is easily available for everyone who wants to contribute.
>
> If I read the thread correctly, there were no objections to raising
> the build time requirements.
>
> It will also remove a lot of unneeded profiles (Java 8 Javadoc fix,
> possibly build chains and module-info profiles),
> in case any of those are present.
>

Not sure since you will replace it by the same amount (more actually) of
toolchain setups so guess the only real point (some of the perf enhancement
are backported by some vendors so not justified alone) is to enable more
things at build time, rest will not change much from my window (but it is
already a step forward, just wanted to highlight we complexify elsewhere
simplifying there).


>
> - Ben
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Java version for Maven 4?

[Benjamin Marwell]

To add some more information, I have seen some extreme reduction in
build times after switching from Java 11 to 17 or even 21 (just for
build, not the runtime).
We can still verify it runs on 11/17 by using the integration tests,
but having the (possibly parallel) unit- and integration tests
compile, run and package on 21 is an *extreme* improvement in build
time.

As always, YMMV. But why waste time...

Since with Semeru and Temurin all major vendors have published their
JDK21 at last,
I see no reason to use a lower Java version to build maven with.
It is easily available for everyone who wants to contribute.

If I read the thread correctly, there were no objections to raising
the build time requirements.

It will also remove a lot of unneeded profiles (Java 8 Javadoc fix,
possibly build chains and module-info profiles),
in case any of those are present.

- Ben

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Java version for Maven 4?

[Tamás Cservenák]

Definitely the improvement is targeting Maven 4 API, hence only plugins
using Maven 4 API would benefit from it.

Backporting this to Maven 3 is nearly impossible.
Basically what we have in Maven 3 (and related plugins, that fiddle with
classpath/modulepath) is what we stay with in Maven 3 "universe" (i.e.
"works as today does").

T



On Mon, Jan 22, 2024 at 11:11 AM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Le 2024-01-22 à 09 h 52, Hervé Boutemy a écrit :
>
> > are there known features in Maven 4 API not available in Maven 3 that
> > would bring stronger interest in writing a goal for Maven 4?
> >
> If accepted, the way to determine where to put dependencies (class-path,
> module-path, etc.) would require Maven 4 new API. It would impact
> maven-compiler-plugin, maven-javadoc-plugin and maven-surefire-plugin
> among others. The use of the new API by plugins would be required for
> giving control to users about where to put dependencies.
>
> After "class-path versus module-path" issue is addressed, more may
> follow. A next issue is the management of "--add-exports" options and
> its friends, which would also require new API.
>
>
> > concern: does it mean that we either should not upgrade our master
> > branches to Maven 4 API too early?
> >
> The pull request for path management is not yet merged, and tests need
> to be added. But after merged and tested, I would propose to upgrade
> only three plugins at first: maven-compiler-plugin, maven-javadoc-plugin
> and maven-surefire-plugin (I can volunteer for submitting patches for
> them as well). After experience shows that the API works well for those
> 3 plugins, other plugins could be migrated.
>
>
> > Will we need to maintain a 3.x branch in parallel to 4/main branch?
> I think yes for those who have 2 or more types of paths (e.g.,
> class-path and module-path options). For the other plugins, maybe not.
>
>  Martin
>
>

Re: Java version for Maven 4?

[Martin Desruisseaux]

Le 2024-01-22 à 09 h 52, Hervé Boutemy a écrit :

are there known features in Maven 4 API not available in Maven 3 that 
would bring stronger interest in writing a goal for Maven 4?


If accepted, the way to determine where to put dependencies (class-path, 
module-path, etc.) would require Maven 4 new API. It would impact 
maven-compiler-plugin, maven-javadoc-plugin and maven-surefire-plugin 
among others. The use of the new API by plugins would be required for 
giving control to users about where to put dependencies.


After "class-path versus module-path" issue is addressed, more may 
follow. A next issue is the management of "--add-exports" options and 
its friends, which would also require new API.



concern: does it mean that we either should not upgrade our master 
branches to Maven 4 API too early?


The pull request for path management is not yet merged, and tests need 
to be added. But after merged and tested, I would propose to upgrade 
only three plugins at first: maven-compiler-plugin, maven-javadoc-plugin 
and maven-surefire-plugin (I can volunteer for submitting patches for 
them as well). After experience shows that the API works well for those 
3 plugins, other plugins could be migrated.




Will we need to maintain a 3.x branch in parallel to 4/main branch?
I think yes for those who have 2 or more types of paths (e.g., 
class-path and module-path options). For the other plugins, maybe not.


    Martin

Re: Java version for Maven 4?

[Hervé Boutemy]

Le dimanche 21 janvier 2024, 22:03:59 CET Guillaume Nodet a écrit :
> At build time, I think it's fine to bump to whatever is needed to make
> our life manageable. If 17 is required, so be it.
+1

my biggest concern with Maven 4 is not JDK runtime requirement, but plugins 
future when a plugin wants to be able to use the new Maven 4 API

IIUC, Maven 4 has a compatibility layer to run Maven Plugin 3.x (= built with 
Maven 3 plugin API).
On our core plugins, there is a Maven 4 branch that tests what the plugin 
would become when it migrates to new Maven 4 API (and check that Maven 4 API 
works as expected)

But IIUC, once a plugin uses Maven 4 API, it de-facto cannot be run on Maven 3

Questions:
- is that true at plugin level or goal level?
- new Maven 4 API for now is not so much about providing new features, but 
improving/clarifying plugin  expectations from Maven core: are there known 
features in Maven 4 API not available in Maven 3 that would bring stronger 
interest in writing a goal for Maven 4?

concern: does it mean that we either should not upgrade our master branches to 
Maven 4 API too early? Will we need to maintain a 3.x branch in parallel to 4/
main branch?
And the questions I have for plugins maintained at Maven project level will 
impact every third party plugin maintainer: we need to make things explicit, 
IMHO
The JVM upgrade in parallel IMHO is less a concern, as it is a consequence of 
previous plugin prerequisite choice on Maven

Hervé

> 
> Guillaume
> 
> Le sam. 20 janv. 2024 à 19:18, Martin Desruisseaux
> 
>  a écrit :
> > Hello
> > 
> > I would like a little clarification about the Java version for Maven 4.
> > I saw debate on this mailing list, but has a decision been reached? I
> > got the impression that Maven 4 would require Java 11, but last time I
> > checked, the pom.xml file was still declaring Java 8 as the target. If
> > Java 11 is the target, updating the pom.xml would unlock some features
> > and make some code a little bit simpler.
> > 
> > Related question: even if Maven 4 targets Java 8 or 11, would it be
> > acceptable to require Java 17 with `--release 8` or `--release 11`
> > option only for Maven 4 compilation (not execution)? I ask because as
> > far as I know, we cannot write code buildable with both Java 11 and Java
> > 17 if the code uses HTML headings in Javadoc comments and the Javadoc
> > checks are enabled. If the project builds on Java 11, then it fails on
> > Java 17. Or if it builds on Java 17, then it fails on Java 11. For
> > building on both versions, we must either avoid HTML headings, or
> > disable Javadoc checks (more details at [1]). Using HTML headings is not
> > very important, so they could be removed. But the `--release 11`
> > approach would allow a more gradual transition to newest Java versions
> > while preserving compatibility for users.
> > 
> >  Martin
> > 
> > [1]https://github.com/apache/maven/pull/1378#issuecomment-1902173221





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Java version for Maven 4?

[Romain Manni-Bucau]

Same there while surefire/invoker runs respect supported versions.

Le dim. 21 janv. 2024 à 22:04, Guillaume Nodet  a écrit :

> At build time, I think it's fine to bump to whatever is needed to make
> our life manageable. If 17 is required, so be it.
>
> Guillaume
>
> Le sam. 20 janv. 2024 à 19:18, Martin Desruisseaux
>  a écrit :
> >
> > Hello
> >
> > I would like a little clarification about the Java version for Maven 4.
> > I saw debate on this mailing list, but has a decision been reached? I
> > got the impression that Maven 4 would require Java 11, but last time I
> > checked, the pom.xml file was still declaring Java 8 as the target. If
> > Java 11 is the target, updating the pom.xml would unlock some features
> > and make some code a little bit simpler.
> >
> > Related question: even if Maven 4 targets Java 8 or 11, would it be
> > acceptable to require Java 17 with `--release 8` or `--release 11`
> > option only for Maven 4 compilation (not execution)? I ask because as
> > far as I know, we cannot write code buildable with both Java 11 and Java
> > 17 if the code uses HTML headings in Javadoc comments and the Javadoc
> > checks are enabled. If the project builds on Java 11, then it fails on
> > Java 17. Or if it builds on Java 17, then it fails on Java 11. For
> > building on both versions, we must either avoid HTML headings, or
> > disable Javadoc checks (more details at [1]). Using HTML headings is not
> > very important, so they could be removed. But the `--release 11`
> > approach would allow a more gradual transition to newest Java versions
> > while preserving compatibility for users.
> >
> >  Martin
> >
> > [1]https://github.com/apache/maven/pull/1378#issuecomment-1902173221
>
>
>
> --
> 
> Guillaume Nodet
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Java version for Maven 4?

[Guillaume Nodet]

At build time, I think it's fine to bump to whatever is needed to make
our life manageable. If 17 is required, so be it.

Guillaume

Le sam. 20 janv. 2024 à 19:18, Martin Desruisseaux
 a écrit :
>
> Hello
>
> I would like a little clarification about the Java version for Maven 4.
> I saw debate on this mailing list, but has a decision been reached? I
> got the impression that Maven 4 would require Java 11, but last time I
> checked, the pom.xml file was still declaring Java 8 as the target. If
> Java 11 is the target, updating the pom.xml would unlock some features
> and make some code a little bit simpler.
>
> Related question: even if Maven 4 targets Java 8 or 11, would it be
> acceptable to require Java 17 with `--release 8` or `--release 11`
> option only for Maven 4 compilation (not execution)? I ask because as
> far as I know, we cannot write code buildable with both Java 11 and Java
> 17 if the code uses HTML headings in Javadoc comments and the Javadoc
> checks are enabled. If the project builds on Java 11, then it fails on
> Java 17. Or if it builds on Java 17, then it fails on Java 11. For
> building on both versions, we must either avoid HTML headings, or
> disable Javadoc checks (more details at [1]). Using HTML headings is not
> very important, so they could be removed. But the `--release 11`
> approach would allow a more gradual transition to newest Java versions
> while preserving compatibility for users.
>
>  Martin
>
> [1]https://github.com/apache/maven/pull/1378#issuecomment-1902173221



-- 

Guillaume Nodet

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Java version for Maven 4?

[Tamás Cservenák]

Howdy,

Maven master (home of Maven 4) is currently Java 8 level.
But many of us agreed that if someone needs Java 8 (or even below), they
can use Maven 3.x (3.9.x or 3.8.x even). Those two are pretty much in
"bugfix" mode, dormant, but not dead.

Personally, if we are about to move, I'd not move to 11, it is already
dead, but rather 17. On 21 javac already warns that release=8 is soon to be
dropped.
This way, we could cover all versions: Maven 3.x works even today up to 21,
and Maven 4 (using release=x) could cover bytecode from Java 9+ while
running on Java 17+.

These are my 5 cents.
T

On Sat, Jan 20, 2024 at 7:17 PM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Hello
>
> I would like a little clarification about the Java version for Maven 4.
> I saw debate on this mailing list, but has a decision been reached? I
> got the impression that Maven 4 would require Java 11, but last time I
> checked, the pom.xml file was still declaring Java 8 as the target. If
> Java 11 is the target, updating the pom.xml would unlock some features
> and make some code a little bit simpler.
>
> Related question: even if Maven 4 targets Java 8 or 11, would it be
> acceptable to require Java 17 with `--release 8` or `--release 11`
> option only for Maven 4 compilation (not execution)? I ask because as
> far as I know, we cannot write code buildable with both Java 11 and Java
> 17 if the code uses HTML headings in Javadoc comments and the Javadoc
> checks are enabled. If the project builds on Java 11, then it fails on
> Java 17. Or if it builds on Java 17, then it fails on Java 11. For
> building on both versions, we must either avoid HTML headings, or
> disable Javadoc checks (more details at [1]). Using HTML headings is not
> very important, so they could be removed. But the `--release 11`
> approach would allow a more gradual transition to newest Java versions
> while preserving compatibility for users.
>
>  Martin
>
> [1]https://github.com/apache/maven/pull/1378#issuecomment-1902173221
>

Java version for Maven 4?

[Martin Desruisseaux]

Hello

I would like a little clarification about the Java version for Maven 4. 
I saw debate on this mailing list, but has a decision been reached? I 
got the impression that Maven 4 would require Java 11, but last time I 
checked, the pom.xml file was still declaring Java 8 as the target. If 
Java 11 is the target, updating the pom.xml would unlock some features 
and make some code a little bit simpler.


Related question: even if Maven 4 targets Java 8 or 11, would it be 
acceptable to require Java 17 with `--release 8` or `--release 11` 
option only for Maven 4 compilation (not execution)? I ask because as 
far as I know, we cannot write code buildable with both Java 11 and Java 
17 if the code uses HTML headings in Javadoc comments and the Javadoc 
checks are enabled. If the project builds on Java 11, then it fails on 
Java 17. Or if it builds on Java 17, then it fails on Java 11. For 
building on both versions, we must either avoid HTML headings, or 
disable Javadoc checks (more details at [1]). Using HTML headings is not 
very important, so they could be removed. But the `--release 11` 
approach would allow a more gradual transition to newest Java versions 
while preserving compatibility for users.


    Martin

[1]https://github.com/apache/maven/pull/1378#issuecomment-1902173221