You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Martin Desruisseaux <ma...@geomatys.com> on 2025/05/24 18:21:53 UTC
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Hello all
Le 2025-05-24 à 15 h 33, Elliotte Rusty Harold a écrit :
> If you want to upgrade the minimum Java version, you need a better
> reason than that. I haven't yet heard a reason strong enough to
> convince me. Others have other opinions.
>
Java 9+ for supporting JPMS. This is needed not only in some plugins
(compiler, javadoc, maybe surefire), but also in some places of Maven
core (class-path versus module-path, cache of module-info). Even if not
everyone is interested in JPMS, trying to enable JPMS while preserving
Java 8 compatibility (e.g. with reflection) would have been difficult.
Java 16+ for starting the migration to records. Some data structures in
Maven core overlap with Java records. In particular, all the classes
generated from the `maven.mdo` file, but not only. In short term,
migrating to records would remove the need to declare constructors,
hashCode and equals methods, thus making classes simpler and reducing
the risk of bugs. In medium term, "derived record creation" (currently
in preview) could replace builders. That would be a massive
simplification of record-like classes.
Java 24+ (in a later Maven version) for class-file API. It would resolve
at least some of the compatibility problems observed when new Java
versions are released and Maven wants to analyse the byte code.
> I would much rather people invested their time into fixing Maven bugs
> and improving the health of the codebase rather than continuously
> migrating code from one Java version to the next.
>
There is two distinct tasks:
* Making sure that Maven is compatible with latest Java version. This
is the task that sometime requires work. This task must be done in
any cases.
* Upgrading the minimum Java version. Assuming that above task is
done, this task is not much more than changing the value of some
properties.
Upgrading the minimum Java version does not force us to migrate any
code. But we can start using new API that make some tasks easier, thus
saving time.
Martin
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Guillaume Nodet <gn...@apache.org>.
------------------------
Guillaume Nodet
Le dim. 25 mai 2025 à 13:30, Elliotte Rusty Harold <el...@ibiblio.org> a
écrit :
>
> As much as I would like to rip out Modello and chuck it into the
> Mariana trench, I don't think that's likely to happen.
Why is that so ? If you want to replace it with something else, I’d be
fine. We’re mostly using velocity templates, so the two things we’re using
from modello now are: the modello model and the xsd generator. But if
what you want is get rid of code generation, I don’t see why we would want
to add maintenance burden (manually maintaining hundreds of classes)
instead of less.
Consequently
> this is a non-starter. If you do manage to rip out and replace
> Modello, then we can talk about record classes, but I don't want to
> have both Modello and record classes, which is what would likely
> happen if we tried this today.
I don’t see why both are related. A single change to the velocity
templates (which is in the maven core source code, not modello) would allow
the switch. That sounds like a good idea to give it a try to me.
>
>
> > Java 24+ (in a later Maven version) for class-file API. It would resolve
> > at least some of the compatibility problems observed when new Java
> > versions are released and Maven wants to analyse the byte code.
>
> This one is interesting. Unfortunately it's far too early to require
> Java 24+ for users, which is what we'd need for this, since users
> would need to run code that calls this API. I don't want to predict
> exactly when this will be possible. However, it's multiple years away.
> Most big dev shops are extremely slow to upgrade. 3 years ago when I
> left Google, they had just finished a multi-year company wide
> migration to Java 11. Meta isn't as big a Java shop, but they too were
> using Java 11 at least through late 2024. They and others will
> eventually get to Java 25, but that's years in the future.
If big shops are slow to upgrade, we don’t have to care about them, as I
doubt this is only the case for the JDK. It will also concern Maven, so I
don’t see why we should bother taking them into account since they won’t
be using Maven 4 before years anyway.
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, May 25, 2025, 14:40 Tamás Cservenák <ta...@cservenak.net> wrote:
> > As repeated many times on this mailing list, JPMS is opt-in.
>
> For the sake of Maven users we have to _clearly_ communicate these things:
>
> - Maven4 will try to give "first class citizen" support for JPMS
> - BUT, it is opt-in, in a way, if user decides to NOT use JPMS, no
> change is needed on user side
>
> In other words, if you don't use JPMS, you can just ignore it, and
> just use Maven 4 as you did so far with Maven3.
>
> But, if you do want to use it, it will allow you to fully express your
> setup (declaratively), instead as today, where you had to rely on
> hacks, some sort of heuristics and a lot of luck ("will it work?") :)
>
Or try to do what we do in Commons and use the Moditect Maven plugin. It
seems to cover most of not all use cases.
Gary
>
> (In general, I always tried (and assumed everyone else is doing the
> same) to deliver some Maven "new feature", IF it would in any way
> interfere with existing builds to leave it "dormant", in a way that
> new feature needs conscious user decision, some config, switch.
> whatever to become active. There was ONE exception to this on my side:
> the new JDK HTTP transport. But even in this case, we always provide
> "escape hatch")
>
> Thanks
> T
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Tamás Cservenák <ta...@cservenak.net>.
> As repeated many times on this mailing list, JPMS is opt-in.
For the sake of Maven users we have to _clearly_ communicate these things:
- Maven4 will try to give "first class citizen" support for JPMS
- BUT, it is opt-in, in a way, if user decides to NOT use JPMS, no
change is needed on user side
In other words, if you don't use JPMS, you can just ignore it, and
just use Maven 4 as you did so far with Maven3.
But, if you do want to use it, it will allow you to fully express your
setup (declaratively), instead as today, where you had to rely on
hacks, some sort of heuristics and a lot of luck ("will it work?") :)
(In general, I always tried (and assumed everyone else is doing the
same) to deliver some Maven "new feature", IF it would in any way
interfere with existing builds to leave it "dormant", in a way that
new feature needs conscious user decision, some config, switch.
whatever to become active. There was ONE exception to this on my side:
the new JDK HTTP transport. But even in this case, we always provide
"escape hatch")
Thanks
T
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 2025-05-25 à 19 h 12, Hunter C Payne a écrit :
> My experiences with JPMS have been universally been bad.
>
Your experience of JPMS, or your experience of Maven 3 / Gradle support
of JPMS?
> If you are going to do this, you need to make the default for it to be
> completely disabled.
>
As repeated many times on this mailing list, JPMS is opt-in.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Jorge Solorzano <jo...@gmail.com>.
On Sun, May 25, 2025 at 7:14 PM Hunter C Payne
<hu...@yahoo.com.invalid> wrote:
>
> I believe JPMS has been around for something like 15 years. And after 15 years of pushing it hard, it doesn't seem like it is used by too many people.
Java 9 introduced the Java Platform Module System (JPMS) in September
2017 — just eight years ago, not 15. Many "enterprises" remain on Java
8 due to legacy constraints, limited migration incentives, or risk
aversion. Even within open source ecosystems, adoption of JPMS has
been limited, despite its clear benefits for modularity and
encapsulation. In that context, eight years is not a long time — but
even so, there hasn’t been a significant or coordinated push to
promote JPMS adoption.
> If people are not using it by now, how good of an idea is it to push it now? I feel like the market has spoken (over and over again) on this topic. My experiences with JPMS have been universally been bad. If you are going to do this, you need to make the default for it to be completely disabled. If you don't, don't expect adoption of M4.
As Martin mentions, this is your experience of JPMS, or your
experience of Maven 3 / Gradle support of JPMS?
In my experience, JPMS has helped me write better-structured code.
Adopting a modular mindset is challenging at first, but once
understood, it pays off. That said, I recognize that many developers
prioritize speed and convenience over clean architecture — leading to
issues like split packages and poorly designed APIs becoming the norm.
What I found most difficult was the lack of tooling support. Tools
like Maven 3 and Eclipse IDE had limited support for JPMS, which
forced me to implement awkward workarounds — especially when working
with multi-release JARs (MR-JARs), where support was almost
nonexistent. If Maven 4 addresses these limitations, it would be a
much-needed improvement for developers looking to adopt JPMS more
seriously.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Hunter C Payne <hu...@yahoo.com.INVALID>.
I believe JPMS has been around for something like 15 years. And after 15 years of pushing it hard, it doesn't seem like it is used by too many people. If people are not using it by now, how good of an idea is it to push it now? I feel like the market has spoken (over and over again) on this topic. My experiences with JPMS have been universally been bad. If you are going to do this, you need to make the default for it to be completely disabled. If you don't, don't expect adoption of M4.
Hunter
On Sunday, May 25, 2025 at 10:04:23 AM PDT, Martin Desruisseaux <ma...@geomatys.com> wrote:
Le 2025-05-25 à 13 h 28, Elliotte Rusty Harold a écrit :
> Can you be more specific? Is there some code we need to produce or
> compile that we cannot compile with Java 8?
>
Yes. Maven 4 core and the compiler plugin 4.0.0-beta already got the
following Java 9+ dependencies:
* MODULE_PATH, UPGRADE_MODULE_PATH, PATCH_MODULE_PATH,
ANNOTATION_PROCESSOR_MODULE_PATH enumeration values of
javax.tools.StandardLocation (used in
org.apache.maven.api.JavaPathType).
* java.lang.module.ModuleDescriptor (used in
org.apache.maven.impl.DefaultDependencyResolverResult).
* javax.tools.StandardJavaFileManager.setLocationForModule(...) and
related methods (used in compiler plugin).
* Maybe more that I forgot.
> We are still trying to figure out how to lay out code for multi-module
> projects.
>
The choice is left to users. The discussion was only about the *default*
layout, and the difficulty was not in JPMS per se but in finding a
compromise with Maven 3 habits.
> That we haven't yet figured this out and haven't really needed to.
> suggests that maybe multi-module projects aren't all that important in
> the real world.
>
I think that the problem is rather widespread misunderstanding about
JPMS, in part by lack of user's experience since JPMS is difficult to
leverage fully in Maven 3 and Gradle. This is suggested by the fact that
we see peoples blaming JPMS for what are Maven and Gradle problems (lack
of control on class-path versus module-path, way to compile tests). See
also next paragraph.
> JPMS has pretty much failed. It's not clear it was ever needed in the
> first place.
>
Before to said that JPMS failed, let first give it a real chance with
real support in Maven 4. Needs exist without peoples realizing it. For
example, Maven recently puts in place a mechanism based on ClassLoader
for isolating the dependencies of a plugin from other plugins (e.g. if a
plugin uses Log4J, do not bring LogJ4 in the environment of all other
plugins). If Maven was using JPMS, this isolation would be supported
natively with no need for extra complexity (except in case of
conflicting versions, but we can still manage with java.lang.ModuleLayer).
Another need seen in my work is reducing the "class-path hell" such as
dependencies put twice with different versions. Not everyone use the
Maven enforcer plugin. This is another example of service that could be
handled natively by JPMS instead of adding another layer of complexity.
It has been reported that JPMS improves JVM startup time, but I didn't
benchmark myself.
> That said, I would like to be able to support multi-module builds, but
> what exactly can't we do without requiring Java 11?
>
Using the module-specific API of javax.tools for compilation and javadoc
generation.
> There's plenty of Java 8 code that is fully compatible with JPMS.
>
They can be partially compatible with some work duplication. For
example, services declared in META-INF/services must be repeated in
module-info, with a risk of inconsistency if the developer updates the
former but forgot to also update the latter. But if, for example, an
application loads JAR files dynamically, then it cannot be fully
compatible with JPMS without using Java 9+ API. Using
java.lang.ClassLoader alone loads the JAR file as if it was on the
class-path. If the developer wants to load the JAR file as if it was on
the module-path, she needs to use java.lang.ModuleLayer.
> All that said, if you can demonstrate in detail that Java 11 is
> required for Maven to build projects that use JPMS, and we have a plan
> for addressing everything else needed to support multi-module builds,
> then I would find that a compelling reason to require Java 11.
>
I have more than a plan: it is almost done for the compiler plugin, and
I started to look at the other plugins. Java 11 is required, we need all
the API listed at the beginning of this email, this is already
integrated in Maven 4 + compiler plugin 4.0.0-beta and already deployed
on Maven central (the deployed versions do not yet offer full JPMS
support however). The compiler plugin on the master branch already
offers full multi-modules support for compiling the main code. The work
is also completed for compiling the test code, but that work has not
been merged yet. Details there:
* https://github.com/Geomatys/maven/wiki
* https://github.com/Geomatys/maven-compiler-plugin/wiki
We need to also update the resources, javadoc and Surefire. I'm working
on that.
>> Java 16+ for starting the migration to records.
>>
> As much as I would like to rip out Modello and chuck it into the
> Mariana trench, I don't think that's likely to happen. Consequently
> this is a non-starter.
>
The plan is not te remove Modello, but to modify the code that it
generates. There is also various classes not generated by modello that
would be done manually.
Martin
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 2025-05-25 à 13 h 28, Elliotte Rusty Harold a écrit :
> Can you be more specific? Is there some code we need to produce or
> compile that we cannot compile with Java 8?
>
Yes. Maven 4 core and the compiler plugin 4.0.0-beta already got the
following Java 9+ dependencies:
* MODULE_PATH, UPGRADE_MODULE_PATH, PATCH_MODULE_PATH,
ANNOTATION_PROCESSOR_MODULE_PATH enumeration values of
javax.tools.StandardLocation (used in
org.apache.maven.api.JavaPathType).
* java.lang.module.ModuleDescriptor (used in
org.apache.maven.impl.DefaultDependencyResolverResult).
* javax.tools.StandardJavaFileManager.setLocationForModule(...) and
related methods (used in compiler plugin).
* Maybe more that I forgot.
> We are still trying to figure out how to lay out code for multi-module
> projects.
>
The choice is left to users. The discussion was only about the *default*
layout, and the difficulty was not in JPMS per se but in finding a
compromise with Maven 3 habits.
> That we haven't yet figured this out and haven't really needed to.
> suggests that maybe multi-module projects aren't all that important in
> the real world.
>
I think that the problem is rather widespread misunderstanding about
JPMS, in part by lack of user's experience since JPMS is difficult to
leverage fully in Maven 3 and Gradle. This is suggested by the fact that
we see peoples blaming JPMS for what are Maven and Gradle problems (lack
of control on class-path versus module-path, way to compile tests). See
also next paragraph.
> JPMS has pretty much failed. It's not clear it was ever needed in the
> first place.
>
Before to said that JPMS failed, let first give it a real chance with
real support in Maven 4. Needs exist without peoples realizing it. For
example, Maven recently puts in place a mechanism based on ClassLoader
for isolating the dependencies of a plugin from other plugins (e.g. if a
plugin uses Log4J, do not bring LogJ4 in the environment of all other
plugins). If Maven was using JPMS, this isolation would be supported
natively with no need for extra complexity (except in case of
conflicting versions, but we can still manage with java.lang.ModuleLayer).
Another need seen in my work is reducing the "class-path hell" such as
dependencies put twice with different versions. Not everyone use the
Maven enforcer plugin. This is another example of service that could be
handled natively by JPMS instead of adding another layer of complexity.
It has been reported that JPMS improves JVM startup time, but I didn't
benchmark myself.
> That said, I would like to be able to support multi-module builds, but
> what exactly can't we do without requiring Java 11?
>
Using the module-specific API of javax.tools for compilation and javadoc
generation.
> There's plenty of Java 8 code that is fully compatible with JPMS.
>
They can be partially compatible with some work duplication. For
example, services declared in META-INF/services must be repeated in
module-info, with a risk of inconsistency if the developer updates the
former but forgot to also update the latter. But if, for example, an
application loads JAR files dynamically, then it cannot be fully
compatible with JPMS without using Java 9+ API. Using
java.lang.ClassLoader alone loads the JAR file as if it was on the
class-path. If the developer wants to load the JAR file as if it was on
the module-path, she needs to use java.lang.ModuleLayer.
> All that said, if you can demonstrate in detail that Java 11 is
> required for Maven to build projects that use JPMS, and we have a plan
> for addressing everything else needed to support multi-module builds,
> then I would find that a compelling reason to require Java 11.
>
I have more than a plan: it is almost done for the compiler plugin, and
I started to look at the other plugins. Java 11 is required, we need all
the API listed at the beginning of this email, this is already
integrated in Maven 4 + compiler plugin 4.0.0-beta and already deployed
on Maven central (the deployed versions do not yet offer full JPMS
support however). The compiler plugin on the master branch already
offers full multi-modules support for compiling the main code. The work
is also completed for compiling the test code, but that work has not
been merged yet. Details there:
* https://github.com/Geomatys/maven/wiki
* https://github.com/Geomatys/maven-compiler-plugin/wiki
We need to also update the resources, javadoc and Surefire. I'm working
on that.
>> Java 16+ for starting the migration to records.
>>
> As much as I would like to rip out Modello and chuck it into the
> Mariana trench, I don't think that's likely to happen. Consequently
> this is a non-starter.
>
The plan is not te remove Modello, but to modify the code that it
generates. There is also various classes not generated by modello that
would be done manually.
Martin
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Jpms is not a topic, you can use jpms and mjars using a makefilr do maven
can be rewritten in go and it would work (otherwise toolchain and java
min+n couldn't work).
Now to be concrete: how to we exit this thread, vote is quite pointless and
will be in loop I fear so we need a way to move forward.
Do we expect a list of people listing features from maven 4 they want on
legacy project in the oss land to prove java < 21 is required or do we just
use java 21 until needed (we can always revert to java 17, wouldnt be the
first time at apache), enables to move forward without blocking anyone
really willing to adopt M4 (not just playing).
Le dim. 25 mai 2025, 13:51, Tamás Cservenák <ta...@cservenak.net> a écrit :
> Eliotte,
>
> While I sometimes find your hunting and fishing stories
> amusing, I also find them very tiresome.
>
> Maven is not a subcontractor or anything like that for any
> of the companies you keep talking about. Maven is not
> (contractually or in any other way) obliged to "deliver
> best experience" or even "support" to those companies
> you keep talking about.
>
> As it was said multiple times here, they are most probably
> happily using Maven3 and will keep using it.
>
> Please stop parroting these things _in relation_ to Maven 4.
>
> This is getting VERY demotivating, at least to me.
>
> I am here to have fun, and not to present some
> "corporate HOWTOs" I had experienced in my life
> (and very much hated). I understand your professional
> past had this and that taught you, but this is not your job.
> You are not better or worse by fixing or not fixing bugs
> here (or introducing them by doing other changes). This is
> an open source project, that does not account for
> spent hours, milestones and what not. Here
> the "do not touch until broken" is not in effect,
> as we do not aim for profit. There is no profit involved here.
> There is nothing "corporate" around here,
> this is supposed to be FUN.
>
> (in fact, there is: profit is when you have chance to
> sit with any of other maven-ers and have a beer with them,
> spend good time as you would with your friends,
> and NOT company coworkers. But this stands even
> for "online" chats, playing CSGO etc)
>
> So, I kindly ask you: Please stop.
>
> On Sun, May 25, 2025 at 1:30 PM Elliotte Rusty Harold
> <el...@ibiblio.org> wrote:
> >
> > On Sat, May 24, 2025 at 6:22 PM Martin Desruisseaux
> > <ma...@geomatys.com> wrote:
> >
> > > Java 9+ for supporting JPMS. This is needed not only in some plugins
> > > (compiler, javadoc, maybe surefire), but also in some places of Maven
> > > core (class-path versus module-path, cache of module-info). Even if not
> > > everyone is interested in JPMS, trying to enable JPMS while preserving
> > > Java 8 compatibility (e.g. with reflection) would have been difficult.
> >
> > Can you be more specific? Is there some code we need to produce or
> > compile that we cannot compile with Java 8? We are still trying to
> > figure out how to lay out code for multi-module projects. That we
> > haven't yet figured this out and haven't really needed to. suggests
> > that maybe multi-module projects aren't all that important in the real
> > world. JPMS has pretty much failed. It's not clear it was ever needed
> > in the first place. That said, I would like to be able to support
> > multi-module builds, but what exactly can't we do without requiring
> > Java 11? There's plenty of Java 8 code that is fully compatible with
> > JPMS. There's also some that isn't, typically due to split packages.
> > However, those problems aren't resolved by upgrading the JDK. In fact,
> > that's a reason a lot of projects avoid JPMS completely. All that
> > said, if you can demonstrate in detail that Java 11 is required for
> > Maven to build projects that use JPMS, and we have a plan for
> > addressing everything else needed to support multi-module builds, then
> > I would find that a compelling reason to require Java 11. It isn't
> > easy though. I took a run at this myself during quarantine and got
> > nowhere.
> >
> > > Java 16+ for starting the migration to records. Some data structures in
> > > Maven core overlap with Java records. In particular, all the classes
> > > generated from the `maven.mdo` file, but not only. In short term,
> > > migrating to records would remove the need to declare constructors,
> > > hashCode and equals methods, thus making classes simpler and reducing
> > > the risk of bugs. In medium term, "derived record creation" (currently
> > > in preview) could replace builders. That would be a massive
> > > simplification of record-like classes.
> >
> > As much as I would like to rip out Modello and chuck it into the
> > Mariana trench, I don't think that's likely to happen. Consequently
> > this is a non-starter. If you do manage to rip out and replace
> > Modello, then we can talk about record classes, but I don't want to
> > have both Modello and record classes, which is what would likely
> > happen if we tried this today.
> >
> > > Java 24+ (in a later Maven version) for class-file API. It would
> resolve
> > > at least some of the compatibility problems observed when new Java
> > > versions are released and Maven wants to analyse the byte code.
> >
> > This one is interesting. Unfortunately it's far too early to require
> > Java 24+ for users, which is what we'd need for this, since users
> > would need to run code that calls this API. I don't want to predict
> > exactly when this will be possible. However, it's multiple years away.
> > Most big dev shops are extremely slow to upgrade. 3 years ago when I
> > left Google, they had just finished a multi-year company wide
> > migration to Java 11. Meta isn't as big a Java shop, but they too were
> > using Java 11 at least through late 2024. They and others will
> > eventually get to Java 25, but that's years in the future.
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Jorge Solorzano <jo...@gmail.com>.
+1000 to Tamás comment,
On Sun, May 25, 2025 at 1:52 PM Tamás Cservenák <ta...@cservenak.net> wrote:
>
> Eliotte,
>
> While I sometimes find your hunting and fishing stories
> amusing, I also find them very tiresome.
>
> Maven is not a subcontractor or anything like that for any
> of the companies you keep talking about. Maven is not
> (contractually or in any other way) obliged to "deliver
> best experience" or even "support" to those companies
> you keep talking about.
>
> As it was said multiple times here, they are most probably
> happily using Maven3 and will keep using it.
>
> Please stop parroting these things _in relation_ to Maven 4.
>
> This is getting VERY demotivating, at least to me.
>
> I am here to have fun, and not to present some
> "corporate HOWTOs" I had experienced in my life
> (and very much hated). I understand your professional
> past had this and that taught you, but this is not your job.
> You are not better or worse by fixing or not fixing bugs
> here (or introducing them by doing other changes). This is
> an open source project, that does not account for
> spent hours, milestones and what not. Here
> the "do not touch until broken" is not in effect,
> as we do not aim for profit. There is no profit involved here.
> There is nothing "corporate" around here,
> this is supposed to be FUN.
>
> (in fact, there is: profit is when you have chance to
> sit with any of other maven-ers and have a beer with them,
> spend good time as you would with your friends,
> and NOT company coworkers. But this stands even
> for "online" chats, playing CSGO etc)
>
> So, I kindly ask you: Please stop.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Tamás Cservenák <ta...@cservenak.net>.
Eliotte,
While I sometimes find your hunting and fishing stories
amusing, I also find them very tiresome.
Maven is not a subcontractor or anything like that for any
of the companies you keep talking about. Maven is not
(contractually or in any other way) obliged to "deliver
best experience" or even "support" to those companies
you keep talking about.
As it was said multiple times here, they are most probably
happily using Maven3 and will keep using it.
Please stop parroting these things _in relation_ to Maven 4.
This is getting VERY demotivating, at least to me.
I am here to have fun, and not to present some
"corporate HOWTOs" I had experienced in my life
(and very much hated). I understand your professional
past had this and that taught you, but this is not your job.
You are not better or worse by fixing or not fixing bugs
here (or introducing them by doing other changes). This is
an open source project, that does not account for
spent hours, milestones and what not. Here
the "do not touch until broken" is not in effect,
as we do not aim for profit. There is no profit involved here.
There is nothing "corporate" around here,
this is supposed to be FUN.
(in fact, there is: profit is when you have chance to
sit with any of other maven-ers and have a beer with them,
spend good time as you would with your friends,
and NOT company coworkers. But this stands even
for "online" chats, playing CSGO etc)
So, I kindly ask you: Please stop.
On Sun, May 25, 2025 at 1:30 PM Elliotte Rusty Harold
<el...@ibiblio.org> wrote:
>
> On Sat, May 24, 2025 at 6:22 PM Martin Desruisseaux
> <ma...@geomatys.com> wrote:
>
> > Java 9+ for supporting JPMS. This is needed not only in some plugins
> > (compiler, javadoc, maybe surefire), but also in some places of Maven
> > core (class-path versus module-path, cache of module-info). Even if not
> > everyone is interested in JPMS, trying to enable JPMS while preserving
> > Java 8 compatibility (e.g. with reflection) would have been difficult.
>
> Can you be more specific? Is there some code we need to produce or
> compile that we cannot compile with Java 8? We are still trying to
> figure out how to lay out code for multi-module projects. That we
> haven't yet figured this out and haven't really needed to. suggests
> that maybe multi-module projects aren't all that important in the real
> world. JPMS has pretty much failed. It's not clear it was ever needed
> in the first place. That said, I would like to be able to support
> multi-module builds, but what exactly can't we do without requiring
> Java 11? There's plenty of Java 8 code that is fully compatible with
> JPMS. There's also some that isn't, typically due to split packages.
> However, those problems aren't resolved by upgrading the JDK. In fact,
> that's a reason a lot of projects avoid JPMS completely. All that
> said, if you can demonstrate in detail that Java 11 is required for
> Maven to build projects that use JPMS, and we have a plan for
> addressing everything else needed to support multi-module builds, then
> I would find that a compelling reason to require Java 11. It isn't
> easy though. I took a run at this myself during quarantine and got
> nowhere.
>
> > Java 16+ for starting the migration to records. Some data structures in
> > Maven core overlap with Java records. In particular, all the classes
> > generated from the `maven.mdo` file, but not only. In short term,
> > migrating to records would remove the need to declare constructors,
> > hashCode and equals methods, thus making classes simpler and reducing
> > the risk of bugs. In medium term, "derived record creation" (currently
> > in preview) could replace builders. That would be a massive
> > simplification of record-like classes.
>
> As much as I would like to rip out Modello and chuck it into the
> Mariana trench, I don't think that's likely to happen. Consequently
> this is a non-starter. If you do manage to rip out and replace
> Modello, then we can talk about record classes, but I don't want to
> have both Modello and record classes, which is what would likely
> happen if we tried this today.
>
> > Java 24+ (in a later Maven version) for class-file API. It would resolve
> > at least some of the compatibility problems observed when new Java
> > versions are released and Maven wants to analyse the byte code.
>
> This one is interesting. Unfortunately it's far too early to require
> Java 24+ for users, which is what we'd need for this, since users
> would need to run code that calls this API. I don't want to predict
> exactly when this will be possible. However, it's multiple years away.
> Most big dev shops are extremely slow to upgrade. 3 years ago when I
> left Google, they had just finished a multi-year company wide
> migration to Java 11. Meta isn't as big a Java shop, but they too were
> using Java 11 at least through late 2024. They and others will
> eventually get to Java 25, but that's years in the future.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Sat, May 24, 2025 at 6:22 PM Martin Desruisseaux
<ma...@geomatys.com> wrote:
> Java 9+ for supporting JPMS. This is needed not only in some plugins
> (compiler, javadoc, maybe surefire), but also in some places of Maven
> core (class-path versus module-path, cache of module-info). Even if not
> everyone is interested in JPMS, trying to enable JPMS while preserving
> Java 8 compatibility (e.g. with reflection) would have been difficult.
Can you be more specific? Is there some code we need to produce or
compile that we cannot compile with Java 8? We are still trying to
figure out how to lay out code for multi-module projects. That we
haven't yet figured this out and haven't really needed to. suggests
that maybe multi-module projects aren't all that important in the real
world. JPMS has pretty much failed. It's not clear it was ever needed
in the first place. That said, I would like to be able to support
multi-module builds, but what exactly can't we do without requiring
Java 11? There's plenty of Java 8 code that is fully compatible with
JPMS. There's also some that isn't, typically due to split packages.
However, those problems aren't resolved by upgrading the JDK. In fact,
that's a reason a lot of projects avoid JPMS completely. All that
said, if you can demonstrate in detail that Java 11 is required for
Maven to build projects that use JPMS, and we have a plan for
addressing everything else needed to support multi-module builds, then
I would find that a compelling reason to require Java 11. It isn't
easy though. I took a run at this myself during quarantine and got
nowhere.
> Java 16+ for starting the migration to records. Some data structures in
> Maven core overlap with Java records. In particular, all the classes
> generated from the `maven.mdo` file, but not only. In short term,
> migrating to records would remove the need to declare constructors,
> hashCode and equals methods, thus making classes simpler and reducing
> the risk of bugs. In medium term, "derived record creation" (currently
> in preview) could replace builders. That would be a massive
> simplification of record-like classes.
As much as I would like to rip out Modello and chuck it into the
Mariana trench, I don't think that's likely to happen. Consequently
this is a non-starter. If you do manage to rip out and replace
Modello, then we can talk about record classes, but I don't want to
have both Modello and record classes, which is what would likely
happen if we tried this today.
> Java 24+ (in a later Maven version) for class-file API. It would resolve
> at least some of the compatibility problems observed when new Java
> versions are released and Maven wants to analyse the byte code.
This one is interesting. Unfortunately it's far too early to require
Java 24+ for users, which is what we'd need for this, since users
would need to run code that calls this API. I don't want to predict
exactly when this will be possible. However, it's multiple years away.
Most big dev shops are extremely slow to upgrade. 3 years ago when I
left Google, they had just finished a multi-year company wide
migration to Java 11. Meta isn't as big a Java shop, but they too were
using Java 11 at least through late 2024. They and others will
eventually get to Java 25, but that's years in the future.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org