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