Re: [DISCUSS] Java version for Maven

[Romain Manni-Bucau]

Hi Hervé,

+1000 on the philosophy!

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

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

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



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

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

Re: [DISCUSS] Java version for Maven

[Hervé Boutemy]

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

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

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

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

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


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

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


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

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

Regards,

Hervé

Le mardi 20 février 2024, 21:49:03 CET Tamás Cservenák a écrit :
> Howdy,
> 
> I intentionally used "Maven" here, and not "Maven 4" as I am sure the
> majority of Maven users do not run Maven on the same Java version they
> target with their build. We do not do that either.
> 
> Some snippets from Herve (who is the ONLY one doing reproducible checks,
> kudos for that) votes:
> 
> Sun, Feb 18, 2024, 9:38 AM
> [VOTE] Release Apache Maven Shade Plugin version 3.5.2
> Reproducible Build ok: reference build done with JDK 11 on *nix
> 
> Wed, Jan 31, 2024, 5:06 AM
> [VOTE] Release Apache Maven JLink Plugin version 3.2.0
> Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
> 022
> 
> Mon, Jan 8, 2024, 8:29 AM
> [VOTE] Release Maven Plugin Tools version 3.11.0
> Reproducible Builds ok: reference build done with JDK 8 on Windows with
> umask
> 
> Mon, Dec 18, 2023, 8:59 AM
> [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
> Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
> 022
> 
> Mon, Dec 18, 2023, 8:59 AM
> [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
> Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
> 022
> 
> Wed, Nov 29, 2023, 8:16 AM
> [VOTE] Apache Maven Build Cache Extension 1.1.0
> Reproducible Build ok: reference build done on *nix with JDK 11
> 
> Sun, Nov 19, 2023, 5:17 PM
> [VOTE] Release Maven Resolver 1.9.17
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
> 
> Sat, Oct 21, 2023, 4:34 PM
> VOTE] Apache Maven 4.0.0-alpha-8 release
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
> 
> Mon, Oct 2, 2023, 9:11 AM
> [VOTE] Release Apache Maven 3.9.5
> Reproducible not fully ok: reference build done with JDK 17 on *nix and
> umask 022
> 
> 
> 
> This CLEARLY shows the tendency:
> - Michael does releases on Java 8 (on windows!), he is a known "aligner"
> and windows person :)
> - Olivier used the "minimum" required Java version (for build cache).
> - Unsure why Herve used Java 11 for the Shade plugin... I mean, he could
> use 21 but also 8, but he shot for 11 that was EOL at the moment of release.
> - The rest is 21.
> 
> 
> 
> So, the question for those refusing anything other than Java 8 to _run_
> Maven (or to revert: for those refusing to run Maven on "latest LTS", that
> is currently 21):
> WHY?
> 
> 
> Thanks
> T





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

Re: [DISCUSS] Java version for Maven

[Romain Manni-Bucau]

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

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

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

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

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

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

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

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

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



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

> I think I mentioned it elsewhere but the fact that maven requires Java
> to run is actually a (sometimes annoying) implementation detail, so if
> maven would simply ship with a (stripped) JVM, being a native binary or
> actually would probably resolve some problems in the area of java
> discussions.
>
> That the java compiler (and surefire) reuses the JVM maven runs on might
> have been convenient in the past decades but if one really cares should
> actually be configured to use a dedicated JVM anyways.
>
>
> Am 20.02.24 um 21:49 schrieb Tamás Cservenák:
> > Howdy,
> >
> > I intentionally used "Maven" here, and not "Maven 4" as I am sure the
> > majority of Maven users do not run Maven on the same Java version they
> > target with their build. We do not do that either.
> >
> > Some snippets from Herve (who is the ONLY one doing reproducible checks,
> > kudos for that) votes:
> >
> > Sun, Feb 18, 2024, 9:38 AM
> > [VOTE] Release Apache Maven Shade Plugin version 3.5.2
> > Reproducible Build ok: reference build done with JDK 11 on *nix
> >
> > Wed, Jan 31, 2024, 5:06 AM
> > [VOTE] Release Apache Maven JLink Plugin version 3.2.0
> > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> umask
> > 022
> >
> > Mon, Jan 8, 2024, 8:29 AM
> > [VOTE] Release Maven Plugin Tools version 3.11.0
> > Reproducible Builds ok: reference build done with JDK 8 on Windows with
> > umask
> >
> > Mon, Dec 18, 2023, 8:59 AM
> > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
> > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> umask
> > 022
> >
> > Mon, Dec 18, 2023, 8:59 AM
> > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
> > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> umask
> > 022
> >
> > Wed, Nov 29, 2023, 8:16 AM
> > [VOTE] Apache Maven Build Cache Extension 1.1.0
> > Reproducible Build ok: reference build done on *nix with JDK 11
> >
> > Sun, Nov 19, 2023, 5:17 PM
> > [VOTE] Release Maven Resolver 1.9.17
> > Reproducible Build ok: reference build done with JDK 21 on *nix with
> umask
> > 022
> >
> > Sat, Oct 21, 2023, 4:34 PM
> > VOTE] Apache Maven 4.0.0-alpha-8 release
> > Reproducible Build ok: reference build done with JDK 21 on *nix with
> umask
> > 022
> >
> > Mon, Oct 2, 2023, 9:11 AM
> > [VOTE] Release Apache Maven 3.9.5
> > Reproducible not fully ok: reference build done with 

Re: [DISCUSS] Java version for Maven

[Christoph Läubrich]

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


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



Am 20.02.24 um 21:49 schrieb Tamás Cservenák:

Howdy,

I intentionally used "Maven" here, and not "Maven 4" as I am sure the
majority of Maven users do not run Maven on the same Java version they
target with their build. We do not do that either.

Some snippets from Herve (who is the ONLY one doing reproducible checks,
kudos for that) votes:

Sun, Feb 18, 2024, 9:38 AM
[VOTE] Release Apache Maven Shade Plugin version 3.5.2
Reproducible Build ok: reference build done with JDK 11 on *nix

Wed, Jan 31, 2024, 5:06 AM
[VOTE] Release Apache Maven JLink Plugin version 3.2.0
Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
022

Mon, Jan 8, 2024, 8:29 AM
[VOTE] Release Maven Plugin Tools version 3.11.0
Reproducible Builds ok: reference build done with JDK 8 on Windows with
umask

Mon, Dec 18, 2023, 8:59 AM
[VOTE] Release Apache Maven Compiler Plugin version 3.12.0
Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
022

Mon, Dec 18, 2023, 8:59 AM
[VOTE] Release Apache Maven Compiler Plugin version 3.12.0
Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
022

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

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

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

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



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



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


Thanks
T



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

Re: 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: [DISCUSS] Java version for Maven

[Hunter C Payne]

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

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

Hunter

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

Thanks
David Jencks

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

Re: [DISCUSS] Java version for Maven

[David Jencks]

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

Thanks
David Jencks

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

Re: [DISCUSS] Java version for Maven

[Hunter C Payne]

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

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

Hunter

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

Thanks
David Jencks

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

Re: [DISCUSS] Java version for Maven

[David Jencks]

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

Thanks
David Jencks

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

Re: [DISCUSS] Java version for Maven

[Tamás Cservenák]

Romain,

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

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

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

T

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



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

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

Re: [DISCUSS] Java version for Maven

[Romain Manni-Bucau]

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

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

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

I think we need to consider two things:

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

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

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

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

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

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



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

> Howdy,
>
> I intentionally used "Maven" here, and not "Maven 4" as I am sure the
> majority of Maven users do not run Maven on the same Java version they
> target with their build. We do not do that either.
>
> Some snippets from Herve (who is the ONLY one doing reproducible checks,
> kudos for that) votes:
>
> Sun, Feb 18, 2024, 9:38 AM
> [VOTE] Release Apache Maven Shade Plugin version 3.5.2
> Reproducible Build ok: reference build done with JDK 11 on *nix
>
> Wed, Jan 31, 2024, 5:06 AM
> [VOTE] Release Apache Maven JLink Plugin version 3.2.0
> Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
> 022
>
> Mon, Jan 8, 2024, 8:29 AM
> [VOTE] Release Maven Plugin Tools version 3.11.0
> Reproducible Builds ok: reference build done with JDK 8 on Windows with
> umask
>
> Mon, Dec 18, 2023, 8:59 AM
> [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
> Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
> 022
>
> Mon, Dec 18, 2023, 8:59 AM
> [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
> Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
> 022
>
> Wed, Nov 29, 2023, 8:16 AM
> [VOTE] Apache Maven Build Cache Extension 1.1.0
> Reproducible Build ok: reference build done on *nix with JDK 11
>
> Sun, Nov 19, 2023, 5:17 PM
> [VOTE] Release Maven Resolver 1.9.17
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
>
> Sat, Oct 21, 2023, 4:34 PM
> VOTE] Apache Maven 4.0.0-alpha-8 release
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
>
> Mon, Oct 2, 2023, 9:11 AM
> [VOTE] Release Apache Maven 3.9.5
> Reproducible not fully ok: reference build done with JDK 17 on *nix and
> umask 022
>
> 
>
> This CLEARLY shows the tendency:
> - Michael does releases on Java 8 (on windows!), he is a known "aligner"
> and windows person :)
> - Olivier used the "minimum" required Java version (for build cache).
> - Unsure why Herve used Java 11 for the Shade plugin... I mean, he could
> use 21 but also 8, but he shot for 11 that was EOL at the moment of
> release.
> - The rest is 21.
>
> 
>
> So, the question for those refusing anything other than Java 8 to _run_
> Maven (or to revert: for those refusing to run Maven on "latest LTS", that
> is currently 21):
> WHY?
>
>
> Thanks
> T
>

[ANN] Apache Maven Shade Plugin 3.5.2 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Shade Plugin, version 3.5.2

This plugin provides the capability to package the artifact in an uber-jar, 
including its dependencies and to shade - i.e. rename - the packages of some 
of the dependencies.

https://maven.apache.org/plugins/maven-shade-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-shade-plugin
  3.5.2


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-shade-plugin/download.cgi

Release Notes - Maven Shade Plugin - Version 3.5.2

** Bug
* [MSHADE-420] - Reproducible Builds timestamp issue in some cases
* [MSHADE-462] - 3.5.1 not compatible with 3.4.1: The version cannot be 
empty
* [MSHADE-467] - Dependency-reduced POM with missing exclusions in 
concurrent build
* [MSHADE-469] - Cannot generate a jar since switching from 3.4.1 to 3.5.x

** Improvement
* [MSHADE-468] -  add plugin system requirements history section

** Dependency upgrade
* [MSHADE-463] - Bump asmVersion from 9.5 to 9.6
* [MSHADE-464] - Maven 3.6.3 as minimum requirements

Enjoy,

-The Apache Maven team



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

[DISCUSS] Java version for Maven

[Tamás Cservenák]

Howdy,

I intentionally used "Maven" here, and not "Maven 4" as I am sure the
majority of Maven users do not run Maven on the same Java version they
target with their build. We do not do that either.

Some snippets from Herve (who is the ONLY one doing reproducible checks,
kudos for that) votes:

Sun, Feb 18, 2024, 9:38 AM
[VOTE] Release Apache Maven Shade Plugin version 3.5.2
Reproducible Build ok: reference build done with JDK 11 on *nix

Wed, Jan 31, 2024, 5:06 AM
[VOTE] Release Apache Maven JLink Plugin version 3.2.0
Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
022

Mon, Jan 8, 2024, 8:29 AM
[VOTE] Release Maven Plugin Tools version 3.11.0
Reproducible Builds ok: reference build done with JDK 8 on Windows with
umask

Mon, Dec 18, 2023, 8:59 AM
[VOTE] Release Apache Maven Compiler Plugin version 3.12.0
Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
022

Mon, Dec 18, 2023, 8:59 AM
[VOTE] Release Apache Maven Compiler Plugin version 3.12.0
Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
022

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

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

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

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



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



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


Thanks
T

[RESULT] [VOTE] Release Apache Maven Shade Plugin version 3.5.2

[Hervé Boutemy]

Hi,

The vote has passed with the following result:

+1 : Romain Manni-Bucau, zhongming hua, Guillaume Nodet, Tamás Cservenák, 
Benjamin Marwell, Sylwester Lachiewicz, Slawomir Jaranowski, Karl Heinz 
Marbaise, Olivier Lamy
-1: Elliotte Rusty Harold

PMC quorum reached

I will promote the source release zip file to Apache distribution area and the 
artifacts to the central repo.

And let's continue merging PRs and giving feedback as much as possible



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

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

Community Over Code Asia 2024 Travel Assistance Applications now open!

[Gavin McDonald]

Hello to all users, contributors and Committers!

The Travel Assistance Committee (TAC) are pleased to announce that
travel assistance applications for Community over Code Asia 2024 are now
open!

We will be supporting Community over Code Asia, Hangzhou, China
July 26th - 28th, 2024.

TAC exists to help those that would like to attend Community over Code
events, but are unable to do so for financial reasons. For more info
on this year's applications and qualifying criteria, please visit the
TAC website at < https://tac.apache.org/ >. Applications are already
open on https://tac-apply.apache.org/, so don't delay!

The Apache Travel Assistance Committee will only be accepting
applications from those people that are able to attend the full event.

Important: Applications close on Friday, May 10th, 2024.

Applicants have until the the closing date above to submit their
applications (which should contain as much supporting material as
required to efficiently and accurately process their request), this
will enable TAC to announce successful applications shortly
afterwards.

As usual, TAC expects to deal with a range of applications from a
diverse range of backgrounds; therefore, we encourage (as always)
anyone thinking about sending in an application to do so ASAP.

For those that will need a Visa to enter the Country - we advise you to
apply
now so that you have enough time in case of interview delays. So do not
wait until you know if you have been accepted or not.

We look forward to greeting many of you in Hangzhou, China in July, 2024!

Kind Regards,

Gavin

(On behalf of the Travel Assistance Committee)

JDK 22 Release Candidates & Virtual Threads pinning heads-up

[David Delabassee]

Welcome to the latest OpenJDK Quality Outreach update!

The first JDK 22 Release Candidates builds are now available [1]. At this 
stage, only P1 issues will still be evaluated. And with the JDK 22 General 
Availability set for March 19th, it is now time to fully focus on JDK 23. At 
the time of writing, one JEP has already been integrated in JDK 23, i.e., JEP 
455: 'Primitive Types in Patterns, instanceof, and switch (Preview)' [2]. But 
new JEP candidates [3][4] have recently been announced, so things should evolve 
rapidly.

I'd like to thank those of you who have already provided feedback on the JDK 22 
EA builds. Feedback is always extremely useful, even more, when it comes early 
in the development cycle. Another area where we need your help is Loom. So, 
please make sure to check the heads-up below that discusses the so-called 
Virtual Threads "pinning" issue.

[1] https://openjdk.org/projects/jdk/22/
[2] https://openjdk.org/jeps/455
[3] https://openjdk.org/jeps/465
[4] https://openjdk.org/jeps/466


## Heads-up: Virtual Threads “Pinning” Issue

Virtual threads became a permanent feature in JDK 21. This feature has been 
extremely well received by the Java ecosystem but there are still a few pain 
points. Much has been written about the so-called "pinning" issue that arises 
with synchronized methods or synchronized statements. The two most common cases 
are (a) a virtual thread parks (ex. doing socket I/O) while in a synchronized 
method, and (b) a virtual thread blocks entering a synchronized method because 
the object's associated monitor is held by another thread. In both cases, the 
underlying carrier/native thread is not "released" to do other work. 
Performance and scalability may suffer and in some cases, starvation and 
deadlock might happen. This recent "Virtual Threads Next Steps" video [5] 
explains in more details the why's and discusses some potential solutions.

New Loom early-access builds haven been recently published [6]. Those Loom EA 
builds have changes to the object monitor implementation that do not pin for 
these two common cases. The Loom team needs your help to test these updated 
object monitors with code that you know is using virtual threads and with 
libraries that are heavily synchronized. The goal is to gauge both reliability 
and performance.

The simplest way to report an issue or feedback is to use the Loom mailing list 
[7]. For the VM savvy, testing with both `-XX:LockingMode=1` (current default) 
and `-XX:LockingMode=2` would be extremely helpful as that would exercise the 
two locking modes currently implemented by the HotSpot VM.

[5] https://inside.java/2024/02/17/virtual-threads-next-steps/
[6] https://jdk.java.net/loom/
[7] https://mail.openjdk.org/pipermail/loom-dev/


## JDK 22 Release Candidates

The JDK 22 Release Candidate builds (builds 36) are available [8] and are 
provided under the GNU General Public License v2, with the Classpath Exception. 
The Release Notes are available here [9], and the javadocs here [10].

[8] https://jdk.java.net/22/
[9] https://jdk.java.net/22/release-notes
[10] https://download.java.net/java/early_access/jdk22/docs/api/


## JDK 23 Early-Access Builds

The JDK 23 Early-Access builds 10 are available [11], and are provided under 
the GNU General Public License v2, with the Classpath Exception. The Release 
Notes are available here [12].

### Changes in recent JDK 23 builds that may be of interest:

- JDK-8324287: Record total and free swap space in JFR
- JDK-8275338: Add JFR events for notable serialization situations
- JDK-8324665: Loose matching of space separators in the lenient date/time 
parsing mode
- JDK-8324066: "clhsdb jstack" should not by default scan for j.u.c locks 
because it can be very slow
- JDK-8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat 
pattern
- JDK-8325221: Obsolete TLABStats
- JDK-8322535: Change default AArch64 SpinPause instruction
- JDK-8323746: Add PathElement hashCode and equals
- JDK-8325570: Update to Graphviz 9.0.0
- JDK-8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files
- JDK-8320458: Improve structural navigation in API documentation
- JDK-8324068: Improve references to tags in the Doc Comment Spec
- JDK-8322366: Add IEEE rounding mode corruption check to JNI checks
- JDK-8321545: Override toString() for Format subclasses
- JDK-8324301: Obsolete MaxGCMinorPauseMillis
- JDK-8324632: Update Zlib Data Compression Library to Version 1.3.1
- JDK-8324771: Obsolete RAMFraction related flags
- JDK-8323645: Remove unused internal sun.net.www.protocol.jar.URLJarFileCa…
- JDK-8325150: (tz) Update Timezone Data to 2024a
- JDK-8324571: JDK 23 L10n resource files update

Note: Complete list of changes can be found here [13].

[11] https://jdk.java.net/23/
[12] https://jdk.java.net/23/release-notes
[13] https://github.com/openjdk/jdk/compare/jdk-23+6...jdk-23+10


## JavaFX Early-Access Builds:

These are early access builds of the JavaFX 22 & 23 Runtime