Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Benjamin Marwell]

Hunter,

please keep to facts and do not get on a personal level:
> It isn't OK to just ignore their input
But then you say:
> Your personal taste shouldn't [...]

I think you just ignored some other dev's input yourself, as some already
voted for JDK11+.

> If you leave Java8, you leave behind everyone who can't upgrade their
source base.

That is not true, and the opposite has been said a few times now.
Yes, Java 8 users get behind regarding new features, which are Java17-only,
but that's not something new.
And then, I bet most Java 8 projects are not even on Maven 3.8. A lot are
not even on 3.6 yet.
They are already behind anyway. A new Maven JDK/JRE runtime version would
NOT change that,
nor would a Maven 4 release on Java 8.

Even then, you still were able to use toolchains and the --release switch
to use Maven 4 on your Java 8 project.
I did this for three years now, and never had issues.
Instead of just saying "you're leaving them behind" please state WHY this
would be true.
We have given you  facts that this is untrue (users CAN migrate), but
there's nothing
but an empty argument from your side. Please state why this would not be an
option in your view/opinion.

Some newer posts on this thread already stated that "attracting devs" would
be working,
because Maven should go with a recent LTS release, not with the oldest one.
So your assumption that I am the only one demanding this is wrong.

> PS Lambdas are only useful if there is function composition and
currying.  Java lacks both.
> So the debate over lambdas is pretty amusing to me.  It is just syntactic
sugar.

Some devs already voted in favour of syntactic sugar.
Most people here seem to doubt that they are not useful, and this is the
first time I heard of it.
Yes, Scala and Kotlin can do more -- but that doesn't make the status quo
for Java less valuable.

See posts from Romain, Delaney and Manfred for reference.

- Ben


Am Mo., 5. Juni 2023 um 21:41 Uhr schrieb Hunter C Payne
:

> Ok, so let's take these points one at a time:* Reduce build matrix, save
> energySo, less builds which is good but pretty minimal value.
> * Attract devsAbsolutely not.  If you want to attract devs, switch to a
> language that is actually growing (no I'm advocating for this).  That isn't
> Java.  If anything, this will lose you devs.  The company I work for will
> be leaving Maven if you stop supporting Java8.  That's 300 users you lose
> right there.  That's just 1 company.  You will lose users in droves if you
> stop Java8 support.  Many companies don't have/put enough resources into
> this type of upgrade.  Its hard to justify to the business and it makes
> lots of work for devs (expensive).  If it is cheaper to switch build
> systems that to upgrade the JVM, that's exactly what folks will do.  My
> company certainly will (not my decision so don't try to convince me, I'm
> not the one you have to convince).
>
> * CDS for non-OpenJ9-usersI'm not sure this is something that is really
> taken advantage of by Maven.  Perhaps I am wrong.
>
> * Better clarity of code (yes, I mean that)That you say that you actually
> mean this says it all.  Clearly this is something that isn't agreed upon
> universally.  Your personal taste shouldn't decide the future of a project
> used by so many others.
> * No additional work (we don't need to migrate, just use the features when
> modifying a line for a bug/feature anyway)This is simply not true.  There
> have been comments by devs on this very list, in this very discussion that
> disprove this point.  It isn't OK to just ignore their input because you
> really want to use lambdas.
>
> * We leave no one behind b/c of Maven 3.8/3.9, thus no drawbacks.You have
> that backwards.   If you leave Java8, you leave behind everyone who can't
> upgrade their source base.  It seems to me that the size of the group of
> Java8 folks you will leave behind is quite large.  So your argument about
> no drawbacks isn't credible.  There are no drawbacks for you, that isn't
> the same as there being no drawbacks for the entire user base.
> * By the time Maven 4 final is out, your views might have changed!I write
> most of my code in Scala so I doubt it seriously.
>
> Your points are not nearly as strong as you imply with your tone.  Some of
> them indicate a lack of understanding of some more advanced parts of FP
> which is understandable for Java devs but doesn't make your points
> correct.  And your analysis of the impact on the userbase is just plain
> wrong.  If you want people to bomb this list with complains, drop Java 8
> support and enjoy the rage postings you get from 100s to 1000s of devs who
> work for companies and projects that don't have to resources to upgrade.
>
> Hunter
> PS Lambdas are only useful if there is function composition and currying.
> Java lacks both.  So the debate over lambdas is pretty amusing to me.  It
> is just syntactic sugar.  It doesn't actually give you the ability to do
> other things like in Scala or Kotlin.  S

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Romain Manni-Bucau]

Do we really care about plugins Hervé? They are compatible with some maven
versions so cover the underlying prerequisites, no?

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



Le mar. 6 juin 2023 à 08:27, Hervé Boutemy  a écrit :

> > > notice that this will also impact all plugins: and given the few work
> done
> > > on
> > > plugins to clearly show what plugin version remains compatible with a
> JDK
> > > release, I feel we're not taking the topic the right way
> >
> > Can you detail it please? While we keep plugin-api java 8 compat - which
> is
> > not under discussion there - there is no more impact than today normally.
>
> currently, if you are still using JDK 7 or even earlier (not a shame, just
> a necessity), it's easy to select latest compatible Maven release:
> https://maven.apache.org/docs/history.html
>
> What about using latest compatible plugins?
> It's where finding documentation starts to become hard:
>
> - each plugin has it public documentation showing only the latest JDK
> prerequisite
>
> - our consolidated view itself is just known from experts only:
>
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html
>
>
> we added some time ago "System Requirements History" for that purpose =
> https://issues.apache.org/jira/browse/MPLUGIN-400
> for example, once a plugin has documented its history, you get:
>
> https://maven.apache.org/maven-release/maven-release-plugin/plugin-info.html#system-requirements
>
> Every plugin should document its system requirements history
> = we need to organise the work to make sure it's done in our own plugins:
> I did the job on a few ones, but it has to be generalised and I don't see
> anybody interested in doing the work (and I'm tired of doing myself the
> documentation cleanup on many aspects...)
>
> notice: now that I wrote that summary, I see we can:
> 1. add a check in dist-tool prerequisites report, to have a clear global
> view
> 2. add a check in DOCCK Maven Documentation Checker Plugin: it did not
> have any release for years, this will be a good reason to update it
> https://maven.apache.org/plugins/maven-docck-plugin/index.html
> https://issues.apache.org/jira/browse/MDOCCK-38 created
>
> Regards,
>
> Hervé
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hervé Boutemy]

> > notice that this will also impact all plugins: and given the few work done
> > on
> > plugins to clearly show what plugin version remains compatible with a JDK
> > release, I feel we're not taking the topic the right way
> 
> Can you detail it please? While we keep plugin-api java 8 compat - which is
> not under discussion there - there is no more impact than today normally.

currently, if you are still using JDK 7 or even earlier (not a shame, just a 
necessity), it's easy to select latest compatible Maven release:
https://maven.apache.org/docs/history.html

What about using latest compatible plugins?
It's where finding documentation starts to become hard:

- each plugin has it public documentation showing only the latest JDK 
prerequisite

- our consolidated view itself is just known from experts only:
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html


we added some time ago "System Requirements History" for that purpose = 
https://issues.apache.org/jira/browse/MPLUGIN-400
for example, once a plugin has documented its history, you get:
https://maven.apache.org/maven-release/maven-release-plugin/plugin-info.html#system-requirements

Every plugin should document its system requirements history
= we need to organise the work to make sure it's done in our own plugins: I did 
the job on a few ones, but it has to be generalised and I don't see anybody 
interested in doing the work (and I'm tired of doing myself the documentation 
cleanup on many aspects...)

notice: now that I wrote that summary, I see we can:
1. add a check in dist-tool prerequisites report, to have a clear global view
2. add a check in DOCCK Maven Documentation Checker Plugin: it did not have any 
release for years, this will be a good reason to update it
https://maven.apache.org/plugins/maven-docck-plugin/index.html
https://issues.apache.org/jira/browse/MDOCCK-38 created

Regards,

Hervé




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

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Sylwester Lachiewicz]

That's how we also our ci and local environment.
On prvarte laptops we use latest LTS and ea Java versions to build and
compile but use gha to check with other combinations.
Sometimes it's a bit huge
https://github.com/apache/maven-compiler-plugin/actions/runs/518201
- 3 latest Maven versions ("3.3.9", "3.8.8", "3.9.2")
- latest LTS Java "8", "11", "17" and non LTS "20"
- also people may use JDK from different vendors, previously not everything
was working in same way "temurin", "zulu", "microsoft", "adopt-openj9"

This results in around 120 runs donated by Azure/Microsoft resources (Thx!)

Then we do not run tests on Java 21-ea - to help with early bug detection
in Java or plugins - this would add around 6 more runs.
Believe me or not, but soon after Java 21 release someone will raise a bug
report if something isn't working (and that's good).

Recent bugs like https://github.com/google/error-prone/issues/3895 affected
also our pipeline (spotless plugin) - we can learn and adjust our setup.
"We" means The Community - everyone who can open PR and help improve our
products so everyone can benefot from it.

Sylwester


wt., 6 cze 2023 o 02:05 Henning Schmiedehausen 
napisał(a):

> Agreed, that is one way to do that, but it seems to me that this is a
> CI/integration test issue, not a build issue per se.
>
> We do the same thing in Jdbi: Build with the LTS JDK, then test against 8,
> 11, 17, current Java release:
> https://github.com/jdbi/jdbi/blob/master/.github/workflows/ci.yml
>
> Personally, I have zero interest in installing many JDKs on my laptop
> (hah!) and am happy to let the CI manage those. It's its job after all. :-)
>
> -h
>
>
> On Thu, Jun 1, 2023 at 9:51 AM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > define 3 Java versions in my toolchains.xml, and then add 3 executions
> for
> > surefire like here?
> >
> >
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/toolchains.html
> >
> > Thanks
> > T
> >
> >
> > On Thu, Jun 1, 2023 at 6:39 PM Gary Gregory 
> > wrote:
> >
> > > I claim it is not wasteful to run unit tests on Java 8, 11, and 17,
> which
> > > usually is the longest and most resource intensive part of a build.
> > >
> > > How would you do that were it not for a GitHub matrix?
> > >
> > > Gary
> > >
> > > On Thu, Jun 1, 2023, 08:01 Tamás Cservenák 
> wrote:
> > >
> > > > Howdy,
> > > >
> > > > From recent discussions I see an interesting pattern: it seems that
> > > people
> > > > (even our PMCs) are using Maven in a way that is making sure that
> "same
> > > > Java version" (I guess vendor + version) is used from "beginning" to
> > > "end".
> > > >
> > > > And "beginning" here means BUILDING (think workstations and CI and so
> > > on),
> > > > while "end" means PRODUCTION (deploying the stuff into production).
> > > >
> > > > Why is that?
> > > >
> > > > We all know that even before this "speedup" of Java releases (so to
> > say,
> > > up
> > > > to Java 8) we did put extra effort into supporting this (running
> Maven
> > on
> > > > different Java versions and producing another bytecode output). One
> > can:
> > > > - use source/target compiler flags + animal sniffer (if on Java 8 or
> > > older)
> > > > - use release compiler flag (if Java9+ used)
> > > > - use toolchains
> > > >
> > > > Why does any of these above "does not work" for those "aligning Java
> > from
> > > > beginning to end"?
> > > >
> > > > With today's tools like sdkman, jenv, homebrew, jbang, mvnw (and who
> > > knows
> > > > what) it is REALLY HARD to miss the automation of getting JDKs and
> > tools
> > > > (and keeping them up to date!!!) on workstations and CIs (deployment
> > not
> > > > counted here, but hopefully it is automated as well).
> > > >
> > > > Another point is that upcoming Maven 4 has tremendous improvements
> > > > targeting toolchains.
> > > >
> > > > Finally, a bit of digression, but very much related thing: as Niels
> > > > showcased on other thread in
> > > > https://github.com/nielsbasjes/ToolChainsInCiBuilds
> > > >
> > > > The CI "matrix" build's Java version part can be moved into Maven
> > itself.
> > > > Personally, I always hated "matrix" as they explode very easily (size
> > > wise)
> > > > but in MOST cases they really just "warm the oceans" (from HB) and do
> > not
> > > > do anything useful. I do keep _matrix useful_ for OS variations, but
> to
> > > > rebuild the same commit over and over with Java8, Java11, Java17 only
> > to
> > > > "be sure" it will work, is really an overkill (and very wasteful).
> The
> > > > added beauty of applying this pattern is that one can perform the
> whole
> > > > build and testing (using different Javas) even on their own
> > workstations.
> > > >
> > > > Does Maven miss some features (aside from those above) to make it
> > > possible
> > > > for those "aligning" Java versions to move?
> > > >
> > > > Thanks
> > > > T
> > > >
> > >
> >
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hervé Boutemy]

Le mardi 6 juin 2023, 01:54:27 CEST Henning Schmiedehausen a écrit :
> To get this discussion a bit more back to actual substance:
> 
> Do you still need toolchains with JDK 11/17? I set the release version to
> "8" (or anything else) in my builds, ripped out all the toolchains and it
> "just works". We have done this for Jdbi for ages (require Java 11+ as the
> build JDK; we even enforce "latest LTS" for releases) and compile to Java 8
> bytecode. So far, we had zero complaints from users that the resulting
> releases do not work / cause problems on JDK 8.
> 
> It seems to me that toolchains are only relevant if you need to compile to
> Java 1.6 or lower (shudder). The current LTS supports any version post-7 as
> release target.
> 
> Am I missing something?
Yes: you are perfectly describing compiling
the missed part is unit-tests and *-tests execution = when they target Java 8 
bytecode, people want to execute tests against JDK 8

Regards,

Hervé



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

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Hervé Boutemy]

I think this difference during Maven build between compile time JDK vs tests 
execution time JDK is key for normal users choice. And ease of setup if 
multiple JDKs are involved (= it's not easy to have configured prerequisites in 
place)

I suppose good articles showing the full setup to do so would perhaps help 
normal users to learn how to do such a nice setup: knowledge on the many 
pieces to do this is not well known

something like a good Baeldung article?

and with something like the Toolchains improvements to more easily deploy 
prerequisites, perhaps this could fly

Regards,

Hervé

Le jeudi 1 juin 2023, 18:51:20 CEST Tamás Cservenák a écrit :
> Howdy,
> 
> define 3 Java versions in my toolchains.xml, and then add 3 executions for
> surefire like here?
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/toolchains.
> html
> 
> Thanks
> T
> 
> On Thu, Jun 1, 2023 at 6:39 PM Gary Gregory  wrote:
> > I claim it is not wasteful to run unit tests on Java 8, 11, and 17, which
> > usually is the longest and most resource intensive part of a build.
> > 
> > How would you do that were it not for a GitHub matrix?
> > 
> > Gary
> > 
> > On Thu, Jun 1, 2023, 08:01 Tamás Cservenák  wrote:
> > > Howdy,
> > > 
> > > From recent discussions I see an interesting pattern: it seems that
> > 
> > people
> > 
> > > (even our PMCs) are using Maven in a way that is making sure that "same
> > > Java version" (I guess vendor + version) is used from "beginning" to
> > 
> > "end".
> > 
> > > And "beginning" here means BUILDING (think workstations and CI and so
> > 
> > on),
> > 
> > > while "end" means PRODUCTION (deploying the stuff into production).
> > > 
> > > Why is that?
> > > 
> > > We all know that even before this "speedup" of Java releases (so to say,
> > 
> > up
> > 
> > > to Java 8) we did put extra effort into supporting this (running Maven
> > > on
> > > different Java versions and producing another bytecode output). One can:
> > > - use source/target compiler flags + animal sniffer (if on Java 8 or
> > 
> > older)
> > 
> > > - use release compiler flag (if Java9+ used)
> > > - use toolchains
> > > 
> > > Why does any of these above "does not work" for those "aligning Java
> > > from
> > > beginning to end"?
> > > 
> > > With today's tools like sdkman, jenv, homebrew, jbang, mvnw (and who
> > 
> > knows
> > 
> > > what) it is REALLY HARD to miss the automation of getting JDKs and tools
> > > (and keeping them up to date!!!) on workstations and CIs (deployment not
> > > counted here, but hopefully it is automated as well).
> > > 
> > > Another point is that upcoming Maven 4 has tremendous improvements
> > > targeting toolchains.
> > > 
> > > Finally, a bit of digression, but very much related thing: as Niels
> > > showcased on other thread in
> > > https://github.com/nielsbasjes/ToolChainsInCiBuilds
> > > 
> > > The CI "matrix" build's Java version part can be moved into Maven
> > > itself.
> > > Personally, I always hated "matrix" as they explode very easily (size
> > 
> > wise)
> > 
> > > but in MOST cases they really just "warm the oceans" (from HB) and do
> > > not
> > > do anything useful. I do keep _matrix useful_ for OS variations, but to
> > > rebuild the same commit over and over with Java8, Java11, Java17 only to
> > > "be sure" it will work, is really an overkill (and very wasteful). The
> > > added beauty of applying this pattern is that one can perform the whole
> > > build and testing (using different Javas) even on their own
> > > workstations.
> > > 
> > > Does Maven miss some features (aside from those above) to make it
> > 
> > possible
> > 
> > > for those "aligning" Java versions to move?
> > > 
> > > Thanks
> > > T





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

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Romain Manni-Bucau]

*Just for the record*.

Toolchain has a great use case IMHO: enable to run on multiple jdk the same
plugin (think surefire/failsafe for ex) without any matrix or CI trick.
The big plus: you test the code runs with all versions you need against the
same binary without side effects. Sometimes it is important cause even
without API breakage the JRE has bugs you want to cover.
That said agree most projects will just not use that (nor will), it is a
bit like using some particular lib, it fits a particular need.
But using toolchain just cause the maven requisite goes too fast sounds
like making the entry cost higher for users, not only in installation but
in understanding and debugging too + will break all ToolProvider/embedded
cases.

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



Le mar. 6 juin 2023 à 02:05, Henning Schmiedehausen <
henn...@schmiedehausen.org> a écrit :

> Agreed, that is one way to do that, but it seems to me that this is a
> CI/integration test issue, not a build issue per se.
>
> We do the same thing in Jdbi: Build with the LTS JDK, then test against 8,
> 11, 17, current Java release:
> https://github.com/jdbi/jdbi/blob/master/.github/workflows/ci.yml
>
> Personally, I have zero interest in installing many JDKs on my laptop
> (hah!) and am happy to let the CI manage those. It's its job after all. :-)
>
> -h
>
>
> On Thu, Jun 1, 2023 at 9:51 AM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > define 3 Java versions in my toolchains.xml, and then add 3 executions
> for
> > surefire like here?
> >
> >
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/toolchains.html
> >
> > Thanks
> > T
> >
> >
> > On Thu, Jun 1, 2023 at 6:39 PM Gary Gregory 
> > wrote:
> >
> > > I claim it is not wasteful to run unit tests on Java 8, 11, and 17,
> which
> > > usually is the longest and most resource intensive part of a build.
> > >
> > > How would you do that were it not for a GitHub matrix?
> > >
> > > Gary
> > >
> > > On Thu, Jun 1, 2023, 08:01 Tamás Cservenák 
> wrote:
> > >
> > > > Howdy,
> > > >
> > > > From recent discussions I see an interesting pattern: it seems that
> > > people
> > > > (even our PMCs) are using Maven in a way that is making sure that
> "same
> > > > Java version" (I guess vendor + version) is used from "beginning" to
> > > "end".
> > > >
> > > > And "beginning" here means BUILDING (think workstations and CI and so
> > > on),
> > > > while "end" means PRODUCTION (deploying the stuff into production).
> > > >
> > > > Why is that?
> > > >
> > > > We all know that even before this "speedup" of Java releases (so to
> > say,
> > > up
> > > > to Java 8) we did put extra effort into supporting this (running
> Maven
> > on
> > > > different Java versions and producing another bytecode output). One
> > can:
> > > > - use source/target compiler flags + animal sniffer (if on Java 8 or
> > > older)
> > > > - use release compiler flag (if Java9+ used)
> > > > - use toolchains
> > > >
> > > > Why does any of these above "does not work" for those "aligning Java
> > from
> > > > beginning to end"?
> > > >
> > > > With today's tools like sdkman, jenv, homebrew, jbang, mvnw (and who
> > > knows
> > > > what) it is REALLY HARD to miss the automation of getting JDKs and
> > tools
> > > > (and keeping them up to date!!!) on workstations and CIs (deployment
> > not
> > > > counted here, but hopefully it is automated as well).
> > > >
> > > > Another point is that upcoming Maven 4 has tremendous improvements
> > > > targeting toolchains.
> > > >
> > > > Finally, a bit of digression, but very much related thing: as Niels
> > > > showcased on other thread in
> > > > https://github.com/nielsbasjes/ToolChainsInCiBuilds
> > > >
> > > > The CI "matrix" build's Java version part can be moved into Maven
> > itself.
> > > > Personally, I always hated "matrix" as they explode very easily (size
> > > wise)
> > > > but in MOST cases they really just "warm the oceans" (from HB) and do
> > not
> > > > do anything useful. I do keep _matrix useful_ for OS variations, but
> to
> > > > rebuild the same commit over and over with Java8, Java11, Java17 only
> > to
> > > > "be sure" it will work, is really an overkill (and very wasteful).
> The
> > > > added beauty of applying this pattern is that one can perform the
> whole
> > > > build and testing (using different Javas) even on their own
> > workstations.
> > > >
> > > > Does Maven miss some features (aside from those above) to make it
> > > possible
> > > > for those "aligning" Java versions to move?
> > > >
> > > > Thanks
> > > > T
> > > >
> > >
> >
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hervé Boutemy]

it's not about *one not wanting* to upgrade (anybody can use JDK 17 if they 
want currently)

it's about *one forcing everybody else* to upgrade (and enter the toolchain 
setup question)


I'd be curious to see what will happen the day one of the base plugin force to 
upgrade:
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html

Regards,

Hervé

Le mardi 19 juillet 2022, 21:28:07 CEST Delany a écrit :
> Elliotte, you make it sound like they don't *want* to upgrade to JDK17. But
> who wouldn't want that?
> Its usually the business holding that back. If I can tell the business,
> sorry, but Maven requires it - then that's the end of the conversation.
> They won't argue. Switching to another build system to avoid doing the
> inevitable is just making more work.
> 
> What little I know, I appreciate the bold move to JDK17 and I guess it'll
> pay off in the long run. Who knows what's next around the corner.
> 
> Regards,
> Delany
> 
> On Tue, 19 Jul 2022 at 20:39, Elliotte Rusty Harold 
> 
> wrote:
> > On Tue, Jul 19, 2022 at 12:25 PM Karl Heinz Marbaise 
> > 
> > wrote:
> > > Hi to all,
> > > 
> > > what do you think about using JDK17 as minimum requirement for running
> > > the future Apache Maven 4.0.0 ?
> > 
> > Bluntly, its an atrocious idea that work would likely lead to forks of
> > maven or a lot of projects abandoning it for other build systems, as well
> > as many more never upgrading.
> > 
> > Developer preference does not outweigh the needs of the massive installed
> > base.
> > 
> > > Kind regards
> > > Karl Heinz Marbaise
> > > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > 
> > > --
> > 
> > Elliotte Rusty Harold
> > elh...@ibiblio.org





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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Delany]

You need toolchains if your code needs the JAXB classes removed in JDK11.
Delany


On Tue, 6 Jun 2023 at 01:54, Henning Schmiedehausen <
henn...@schmiedehausen.org> wrote:

> To get this discussion a bit more back to actual substance:
>
> Do you still need toolchains with JDK 11/17? I set the release version to
> "8" (or anything else) in my builds, ripped out all the toolchains and it
> "just works". We have done this for Jdbi for ages (require Java 11+ as the
> build JDK; we even enforce "latest LTS" for releases) and compile to Java 8
> bytecode. So far, we had zero complaints from users that the resulting
> releases do not work / cause problems on JDK 8.
>
> It seems to me that toolchains are only relevant if you need to compile to
> Java 1.6 or lower (shudder). The current LTS supports any version post-7 as
> release target.
>
> Am I missing something?
>
> Oh, I am totally cool with Maven 4 requiring Java 17 to run. In fact, this
> will give us an opportunity to actually use java 17 code to *write* maven,
> which in turn will collapse all of those thousand little domain objects
> into single line records. Can't wait for that. :-)
>
> The challenge for plugin writers will be to support Maven 3.x (mostly 3.8,
> 3.9) and 4 evenly. The current set of available modules and libraries makes
> that hard. A page with "use this to be compatible with that" would be
> helpful.
>
> -h
>
>
>
>
> On Mon, Jun 5, 2023 at 2:23 PM Delany  wrote:
>
> > Your inclination to ignore points of the debate doesn't do your own
> > arguments any justice.
> > Multiple times it's been explained that raising the required runtime JDK
> in
> > Maven 4 will not prevent you from
> > - building with a lower JDK (via toolchains)
> > - targeting a lower JDK (via the release property)
> > - building with Maven 3
> >
> > This is the main point of the debate, not the language.
> >
> > On Mon, 5 Jun 2023 at 21:42, Hunter C Payne
> >  wrote:
> >
> > > * Attract devsAbsolutely not.  If you want to attract devs, switch to a
> > > language that is actually growing (no I'm advocating for this).  That
> > isn't
> > > Java.  If anything, this will lose you devs.  The company I work for
> will
> > > be leaving Maven if you stop supporting Java8.  That's 300 users you
> lose
> > > right there.  That's just 1 company.  You will lose users in droves if
> > you
> > > stop Java8 support.  Many companies don't have/put enough resources
> into
> > > this type of upgrade.  Its hard to justify to the business and it makes
> > > lots of work for devs (expensive).  If it is cheaper to switch build
> > > systems that to upgrade the JVM, that's exactly what folks will do.  My
> > > company certainly will (not my decision so don't try to convince me,
> I'm
> > > not the one you have to convince).
> > >
> > > * CDS for non-OpenJ9-usersI'm not sure this is something that is really
> > > taken advantage of by Maven.  Perhaps I am wrong.
> > >
> > > * Better clarity of code (yes, I mean that)That you say that you
> actually
> > > mean this says it all.  Clearly this is something that isn't agreed
> upon
> > > universally.  Your personal taste shouldn't decide the future of a
> > project
> > > used by so many others.
> > > * No additional work (we don't need to migrate, just use the features
> > when
> > > modifying a line for a bug/feature anyway)This is simply not true.
> There
> > > have been comments by devs on this very list, in this very discussion
> > that
> > > disprove this point.  It isn't OK to just ignore their input because
> you
> > > really want to use lambdas.
> > >
> > > * We leave no one behind b/c of Maven 3.8/3.9, thus no drawbacks.You
> have
> > > that backwards.   If you leave Java8, you leave behind everyone who
> can't
> > > upgrade their source base.  It seems to me that the size of the group
> of
> > > Java8 folks you will leave behind is quite large.  So your argument
> about
> > > no drawbacks isn't credible.  There are no drawbacks for you, that
> isn't
> > > the same as there being no drawbacks for the entire user base.
> > > * By the time Maven 4 final is out, your views might have changed!I
> write
> > > most of my code in Scala so I doubt it seriously.
> > >
> > > Your points are not nearly as strong as you imply with your tone.  Some
> > of
> > > them indicate a lack of understanding of some more advanced parts of FP
> > > which is understandable for Java devs but doesn't make your points
> > > correct.  And your analysis of the impact on the userbase is just plain
> > > wrong.  If you want people to bomb this list with complains, drop Java
> 8
> > > support and enjoy the rage postings you get from 100s to 1000s of devs
> > who
> > > work for companies and projects that don't have to resources to
> upgrade.
> > >
> > > Hunter
> > > PS Lambdas are only useful if there is function composition and
> currying.
> > > Java lacks both.  So the debate over lambdas is pretty amusing to me.
> It
> > > is just syntactic sugar.  It doesn't actually

RE: Question - JDK Minimum of future Apache Maven 4.0.0

[Jeremy Landis]

Toolchains is not needed. Many plugins don't even support it.  However, the 
'release' flag only checks stuff in java itself as well as your codes direct 
usage.  It doesn't look in the libraries you use indirectly.  For that you need 
the enforcer plugin to look at the byte code.  Trust the cross compilation...it 
works!

Jeremy


-Original Message-
From: Henning Schmiedehausen  
Sent: Monday, June 5, 2023 7:54 PM
To: Maven Developers List 
Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0

To get this discussion a bit more back to actual substance:

Do you still need toolchains with JDK 11/17? I set the release version to "8" 
(or anything else) in my builds, ripped out all the toolchains and it "just 
works". We have done this for Jdbi for ages (require Java 11+ as the build JDK; 
we even enforce "latest LTS" for releases) and compile to Java 8 bytecode. So 
far, we had zero complaints from users that the resulting releases do not work 
/ cause problems on JDK 8.

It seems to me that toolchains are only relevant if you need to compile to Java 
1.6 or lower (shudder). The current LTS supports any version post-7 as release 
target.

Am I missing something?

Oh, I am totally cool with Maven 4 requiring Java 17 to run. In fact, this will 
give us an opportunity to actually use java 17 code to *write* maven, which in 
turn will collapse all of those thousand little domain objects into single line 
records. Can't wait for that. :-)

The challenge for plugin writers will be to support Maven 3.x (mostly 3.8,
3.9) and 4 evenly. The current set of available modules and libraries makes 
that hard. A page with "use this to be compatible with that" would be helpful.

-h




On Mon, Jun 5, 2023 at 2:23 PM Delany  wrote:

> Your inclination to ignore points of the debate doesn't do your own 
> arguments any justice.
> Multiple times it's been explained that raising the required runtime 
> JDK in Maven 4 will not prevent you from
> - building with a lower JDK (via toolchains)
> - targeting a lower JDK (via the release property)
> - building with Maven 3
>
> This is the main point of the debate, not the language.
>
> On Mon, 5 Jun 2023 at 21:42, Hunter C Payne 
>  wrote:
>
> > * Attract devsAbsolutely not.  If you want to attract devs, switch 
> > to a language that is actually growing (no I'm advocating for this).  
> > That
> isn't
> > Java.  If anything, this will lose you devs.  The company I work for 
> > will be leaving Maven if you stop supporting Java8.  That's 300 
> > users you lose right there.  That's just 1 company.  You will lose 
> > users in droves if
> you
> > stop Java8 support.  Many companies don't have/put enough resources 
> > into this type of upgrade.  Its hard to justify to the business and 
> > it makes lots of work for devs (expensive).  If it is cheaper to 
> > switch build systems that to upgrade the JVM, that's exactly what 
> > folks will do.  My company certainly will (not my decision so don't 
> > try to convince me, I'm not the one you have to convince).
> >
> > * CDS for non-OpenJ9-usersI'm not sure this is something that is 
> > really taken advantage of by Maven.  Perhaps I am wrong.
> >
> > * Better clarity of code (yes, I mean that)That you say that you 
> > actually mean this says it all.  Clearly this is something that 
> > isn't agreed upon universally.  Your personal taste shouldn't decide 
> > the future of a
> project
> > used by so many others.
> > * No additional work (we don't need to migrate, just use the 
> > features
> when
> > modifying a line for a bug/feature anyway)This is simply not true.  
> > There have been comments by devs on this very list, in this very 
> > discussion
> that
> > disprove this point.  It isn't OK to just ignore their input because 
> > you really want to use lambdas.
> >
> > * We leave no one behind b/c of Maven 3.8/3.9, thus no drawbacks.You have
> > that backwards.   If you leave Java8, you leave behind everyone who can't
> > upgrade their source base.  It seems to me that the size of the 
> > group of
> > Java8 folks you will leave behind is quite large.  So your argument 
> > about no drawbacks isn't credible.  There are no drawbacks for you, 
> > that isn't the same as there being no drawbacks for the entire user base.
> > * By the time Maven 4 final is out, your views might have changed!I 
> > write most of my code in Scala so I doubt it seriously.
> >
> > Your points are not nearly as strong as you imply with your tone.  
> > Some
> of
> > them indicate a lack of understanding of some more advanced parts of 
> > FP which is understandable for Java devs but doesn't make your 
> > points correct.  And your analysis of the impact on the userbase is 
> > just plain wrong.  If you want people to bomb this list with 
> > complains, drop Java 8 support and enjoy the rage postings you get 
> > from 100s to 1000s of devs
> who
> > work for companies and projects that don't have to resources to upgrade.
> >
> > Hunter
> > P

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Henning Schmiedehausen]

Uhm, I have definitely gotten pushback when I ported some changes back to
the 3.8.x branch. The wording was (paraphrasing)  "maven 3.8 is dead and we
do not plan to do any further releases, so don't add code to it". This was
with Maven 3.8.4  :-)

-h

On Wed, May 31, 2023 at 3:37 AM Guillaume Nodet  wrote:

> Le mer. 31 mai 2023 à 12:28, Michael Osipov  a écrit
> :
>
> > On 2023/05/31 10:03:34 Guillaume Nodet wrote:
> > > Le mer. 31 mai 2023 à 11:21, Michael Osipov  a
> > écrit :
> > >
> > > > > I think with those improvements, requiring JDK 17 for master should
> > be
> > > > > doable.  Any concerns of suggestions ?
> > > >
> > > > I am against this. There are enough people who cannot move to Java 17
> > for
> > > > a plethora of reasons regardless of Toolchains support. We provide a
> > low
> > > > level tool and it should have a low barrier to use. Maven 4 should be
> > used
> > > > as a transitional version to 5 to cut old ties and solve many issues
> --
> > > > even if we are in alpha phase now.
> > > > I bet many people will stick for 3.9.x or even 3.8.x for the years to
> > come.
> > > >
> > >
> > > I don't get the argument here.  If people can stick with old versions
> of
> > > maven, this is actually an argument for moving the next releases
> forward,
> > > because that won't be a problem for them.
> >
> > If Maven 4 will be the only option for them since 3.x won't be maintained
> > anymore then this is a problem for many.
> >
>
> Who said so ?  If there's a need and will to maintain the 3.x branch, so be
> it.  No one is forbidden to work on those branches.
>
>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> 
> Guillaume Nodet
>

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Henning Schmiedehausen]

Agreed, that is one way to do that, but it seems to me that this is a
CI/integration test issue, not a build issue per se.

We do the same thing in Jdbi: Build with the LTS JDK, then test against 8,
11, 17, current Java release:
https://github.com/jdbi/jdbi/blob/master/.github/workflows/ci.yml

Personally, I have zero interest in installing many JDKs on my laptop
(hah!) and am happy to let the CI manage those. It's its job after all. :-)

-h


On Thu, Jun 1, 2023 at 9:51 AM Tamás Cservenák  wrote:

> Howdy,
>
> define 3 Java versions in my toolchains.xml, and then add 3 executions for
> surefire like here?
>
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/toolchains.html
>
> Thanks
> T
>
>
> On Thu, Jun 1, 2023 at 6:39 PM Gary Gregory 
> wrote:
>
> > I claim it is not wasteful to run unit tests on Java 8, 11, and 17, which
> > usually is the longest and most resource intensive part of a build.
> >
> > How would you do that were it not for a GitHub matrix?
> >
> > Gary
> >
> > On Thu, Jun 1, 2023, 08:01 Tamás Cservenák  wrote:
> >
> > > Howdy,
> > >
> > > From recent discussions I see an interesting pattern: it seems that
> > people
> > > (even our PMCs) are using Maven in a way that is making sure that "same
> > > Java version" (I guess vendor + version) is used from "beginning" to
> > "end".
> > >
> > > And "beginning" here means BUILDING (think workstations and CI and so
> > on),
> > > while "end" means PRODUCTION (deploying the stuff into production).
> > >
> > > Why is that?
> > >
> > > We all know that even before this "speedup" of Java releases (so to
> say,
> > up
> > > to Java 8) we did put extra effort into supporting this (running Maven
> on
> > > different Java versions and producing another bytecode output). One
> can:
> > > - use source/target compiler flags + animal sniffer (if on Java 8 or
> > older)
> > > - use release compiler flag (if Java9+ used)
> > > - use toolchains
> > >
> > > Why does any of these above "does not work" for those "aligning Java
> from
> > > beginning to end"?
> > >
> > > With today's tools like sdkman, jenv, homebrew, jbang, mvnw (and who
> > knows
> > > what) it is REALLY HARD to miss the automation of getting JDKs and
> tools
> > > (and keeping them up to date!!!) on workstations and CIs (deployment
> not
> > > counted here, but hopefully it is automated as well).
> > >
> > > Another point is that upcoming Maven 4 has tremendous improvements
> > > targeting toolchains.
> > >
> > > Finally, a bit of digression, but very much related thing: as Niels
> > > showcased on other thread in
> > > https://github.com/nielsbasjes/ToolChainsInCiBuilds
> > >
> > > The CI "matrix" build's Java version part can be moved into Maven
> itself.
> > > Personally, I always hated "matrix" as they explode very easily (size
> > wise)
> > > but in MOST cases they really just "warm the oceans" (from HB) and do
> not
> > > do anything useful. I do keep _matrix useful_ for OS variations, but to
> > > rebuild the same commit over and over with Java8, Java11, Java17 only
> to
> > > "be sure" it will work, is really an overkill (and very wasteful). The
> > > added beauty of applying this pattern is that one can perform the whole
> > > build and testing (using different Javas) even on their own
> workstations.
> > >
> > > Does Maven miss some features (aside from those above) to make it
> > possible
> > > for those "aligning" Java versions to move?
> > >
> > > Thanks
> > > T
> > >
> >
>

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Henning Schmiedehausen]

I always assumed that Java versions are a solved problem in JDK 9+ with
'-release' which creates bytecode for the targeted JDK and even ensures
that no classes or methods from the JDK are used that are not supported in
that version.

There is a desire for "everything must be the same" that I am not sure I
understand. I ship a lot of open source and compile everything with "latest
LTS" to Java 8 or Java 11. I have never seen a user complain that the
resulting artifacts do not work.

So why do I need that support? I am genuinely curious. It seems that there
is something that I am missing or are too naive about. What is the problem
that toolchains (in maven or gradle) solve that I am not aware of?

-h


On Thu, Jun 1, 2023 at 5:12 AM Christoph Läubrich 
wrote:

>  > Does Maven miss some features
>
> Just look at how gradle support toolchains:
>
> https://docs.gradle.org/current/userguide/toolchains.html
>
> That's all shows what maven refuses to support and leaving people think
> its easier to use the same JVM "from beginning to end":
>
> 1) First class declarative central configuration (no need to configure
> it here and there)
> 2) automatic discovery of installed toolchains
> 3) Support for automatically download if a matching one if not found
>
> All this has nothing to do with that is is *possible* to do so in maven
> as well, it is just not *convenient* to do so and as its is not *easy*
> as well (you can just miss a thing) people are skeptical and try to "be
> sure" by using the same JVM from start-to-end...
>
>
> Am 01.06.23 um 14:00 schrieb Tamás Cservenák:
> > Howdy,
> >
> >  From recent discussions I see an interesting pattern: it seems that
> people
> > (even our PMCs) are using Maven in a way that is making sure that "same
> > Java version" (I guess vendor + version) is used from "beginning" to
> "end".
> >
> > And "beginning" here means BUILDING (think workstations and CI and so
> on),
> > while "end" means PRODUCTION (deploying the stuff into production).
> >
> > Why is that?
> >
> > We all know that even before this "speedup" of Java releases (so to say,
> up
> > to Java 8) we did put extra effort into supporting this (running Maven on
> > different Java versions and producing another bytecode output). One can:
> > - use source/target compiler flags + animal sniffer (if on Java 8 or
> older)
> > - use release compiler flag (if Java9+ used)
> > - use toolchains
> >
> > Why does any of these above "does not work" for those "aligning Java from
> > beginning to end"?
> >
> > With today's tools like sdkman, jenv, homebrew, jbang, mvnw (and who
> knows
> > what) it is REALLY HARD to miss the automation of getting JDKs and tools
> > (and keeping them up to date!!!) on workstations and CIs (deployment not
> > counted here, but hopefully it is automated as well).
> >
> > Another point is that upcoming Maven 4 has tremendous improvements
> > targeting toolchains.
> >
> > Finally, a bit of digression, but very much related thing: as Niels
> > showcased on other thread in
> > https://github.com/nielsbasjes/ToolChainsInCiBuilds
> >
> > The CI "matrix" build's Java version part can be moved into Maven itself.
> > Personally, I always hated "matrix" as they explode very easily (size
> wise)
> > but in MOST cases they really just "warm the oceans" (from HB) and do not
> > do anything useful. I do keep _matrix useful_ for OS variations, but to
> > rebuild the same commit over and over with Java8, Java11, Java17 only to
> > "be sure" it will work, is really an overkill (and very wasteful). The
> > added beauty of applying this pattern is that one can perform the whole
> > build and testing (using different Javas) even on their own workstations.
> >
> > Does Maven miss some features (aside from those above) to make it
> possible
> > for those "aligning" Java versions to move?
> >
> > Thanks
> > T
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Henning Schmiedehausen]

To get this discussion a bit more back to actual substance:

Do you still need toolchains with JDK 11/17? I set the release version to
"8" (or anything else) in my builds, ripped out all the toolchains and it
"just works". We have done this for Jdbi for ages (require Java 11+ as the
build JDK; we even enforce "latest LTS" for releases) and compile to Java 8
bytecode. So far, we had zero complaints from users that the resulting
releases do not work / cause problems on JDK 8.

It seems to me that toolchains are only relevant if you need to compile to
Java 1.6 or lower (shudder). The current LTS supports any version post-7 as
release target.

Am I missing something?

Oh, I am totally cool with Maven 4 requiring Java 17 to run. In fact, this
will give us an opportunity to actually use java 17 code to *write* maven,
which in turn will collapse all of those thousand little domain objects
into single line records. Can't wait for that. :-)

The challenge for plugin writers will be to support Maven 3.x (mostly 3.8,
3.9) and 4 evenly. The current set of available modules and libraries makes
that hard. A page with "use this to be compatible with that" would be
helpful.

-h




On Mon, Jun 5, 2023 at 2:23 PM Delany  wrote:

> Your inclination to ignore points of the debate doesn't do your own
> arguments any justice.
> Multiple times it's been explained that raising the required runtime JDK in
> Maven 4 will not prevent you from
> - building with a lower JDK (via toolchains)
> - targeting a lower JDK (via the release property)
> - building with Maven 3
>
> This is the main point of the debate, not the language.
>
> On Mon, 5 Jun 2023 at 21:42, Hunter C Payne
>  wrote:
>
> > * Attract devsAbsolutely not.  If you want to attract devs, switch to a
> > language that is actually growing (no I'm advocating for this).  That
> isn't
> > Java.  If anything, this will lose you devs.  The company I work for will
> > be leaving Maven if you stop supporting Java8.  That's 300 users you lose
> > right there.  That's just 1 company.  You will lose users in droves if
> you
> > stop Java8 support.  Many companies don't have/put enough resources into
> > this type of upgrade.  Its hard to justify to the business and it makes
> > lots of work for devs (expensive).  If it is cheaper to switch build
> > systems that to upgrade the JVM, that's exactly what folks will do.  My
> > company certainly will (not my decision so don't try to convince me, I'm
> > not the one you have to convince).
> >
> > * CDS for non-OpenJ9-usersI'm not sure this is something that is really
> > taken advantage of by Maven.  Perhaps I am wrong.
> >
> > * Better clarity of code (yes, I mean that)That you say that you actually
> > mean this says it all.  Clearly this is something that isn't agreed upon
> > universally.  Your personal taste shouldn't decide the future of a
> project
> > used by so many others.
> > * No additional work (we don't need to migrate, just use the features
> when
> > modifying a line for a bug/feature anyway)This is simply not true.  There
> > have been comments by devs on this very list, in this very discussion
> that
> > disprove this point.  It isn't OK to just ignore their input because you
> > really want to use lambdas.
> >
> > * We leave no one behind b/c of Maven 3.8/3.9, thus no drawbacks.You have
> > that backwards.   If you leave Java8, you leave behind everyone who can't
> > upgrade their source base.  It seems to me that the size of the group of
> > Java8 folks you will leave behind is quite large.  So your argument about
> > no drawbacks isn't credible.  There are no drawbacks for you, that isn't
> > the same as there being no drawbacks for the entire user base.
> > * By the time Maven 4 final is out, your views might have changed!I write
> > most of my code in Scala so I doubt it seriously.
> >
> > Your points are not nearly as strong as you imply with your tone.  Some
> of
> > them indicate a lack of understanding of some more advanced parts of FP
> > which is understandable for Java devs but doesn't make your points
> > correct.  And your analysis of the impact on the userbase is just plain
> > wrong.  If you want people to bomb this list with complains, drop Java 8
> > support and enjoy the rage postings you get from 100s to 1000s of devs
> who
> > work for companies and projects that don't have to resources to upgrade.
> >
> > Hunter
> > PS Lambdas are only useful if there is function composition and currying.
> > Java lacks both.  So the debate over lambdas is pretty amusing to me.  It
> > is just syntactic sugar.  It doesn't actually give you the ability to do
> > other things like in Scala or Kotlin.  So I don't really understand why
> you
> > want to use them so much.  Are for loops really that hard to write?  I
> mean
> > there is already so much ceremony in Java that saving 3 or 4 keystrokes
> per
> > loop doesn't really make any difference.
> >
> >
> >On Monday, June 5, 2023 at 11:52:16 AM PDT, Tamás Cservenák 

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Manfred Moser]

I have to strongly disagree. If Maven wants to remain relevant it needs 
to be using a relatively modern JDK and language that is available to 
open source developers and interesting to work on.


Nobody wants to work on Java 8 code.

Ultimately the committers and project maintainers can vote and move on 
as desired. You can always use an old version of Maven or switch to some 
other build system that works with Java 8.


Personally I will certainly vote for the current LTS release of Java 
(17) .. and would in the future also vote for the next current LTS very 
soon. And I would vote against staying with an outdated version that 
reached EOL years ago.


Manfred

On 2023-06-05 15:31, Hunter C Payne wrote:

  Other projects have tried to do that (given they are different types of 
projects) and it turned out that keeping JVM8 support going when not compiling 
on JDK8 proved difficult and when push came to shove, it was JVM 8 support that 
was dropped.  I know that's not you or this project, but human nature is what 
it is and patterns tend to repeat.  So while I understand what you are saying, 
I have my doubts based upon past projects I have seen do this.

On the other hand, the reasons for the upgrade are always a bit weak and the 
upgrade really only created lots of support work for the devs and users (the 
security model is especially an issue) and yes they thought it would be 
seem-less too.  Writing code in any other JVM language would accomplish what 
you want far more effectively.  Instead you want to put lipstick on the pig and 
act like Java 21 is somehow like more modern languages (it isn't, it never will 
be).   Just because you can pass a function in Java, doesn't make it a FP 
language.  It has no currying, no function composition, it lacks a self-type, 
there are no concepts of co or contra variance in the types and that's just a 
short list off the top of my head.  That's the direction you are pushing with 
what you are asking about but Java 21 isn't the answer there as it has none of 
these things, while almost all of them would be useful in Maven itself.
So from my perspective, you are proposing a solution to a problem that doesn't 
exist while at the same time the solution you propose doesn't truly give you 
what you want.  Nobody wanting to a new language on their CV is going to need 
that language to be Java.  If they are joining the Maven project, it is likely 
because they want to contribute to Maven, not because Maven uses JDK 21.  And 
your users just don't want to be bothered and want their build system to work.  
It is hardly ideal and I have sympathy but it doesn't make dropping building of 
Maven by javac8 the right call.

Hunter
 On Monday, June 5, 2023 at 02:22:59 PM PDT, Delany 
 wrote:
  
  Your inclination to ignore points of the debate doesn't do your own

arguments any justice.
Multiple times it's been explained that raising the required runtime JDK in
Maven 4 will not prevent you from
- building with a lower JDK (via toolchains)
- targeting a lower JDK (via the release property)
- building with Maven 3

This is the main point of the debate, not the language.

On Mon, 5 Jun 2023 at 21:42, Hunter C Payne
 wrote:


* Attract devsAbsolutely not.  If you want to attract devs, switch to a
language that is actually growing (no I'm advocating for this).  That isn't
Java.  If anything, this will lose you devs.  The company I work for will
be leaving Maven if you stop supporting Java8.  That's 300 users you lose
right there.  That's just 1 company.  You will lose users in droves if you
stop Java8 support.  Many companies don't have/put enough resources into
this type of upgrade.  Its hard to justify to the business and it makes
lots of work for devs (expensive).  If it is cheaper to switch build
systems that to upgrade the JVM, that's exactly what folks will do.  My
company certainly will (not my decision so don't try to convince me, I'm
not the one you have to convince).

* CDS for non-OpenJ9-usersI'm not sure this is something that is really
taken advantage of by Maven.  Perhaps I am wrong.

* Better clarity of code (yes, I mean that)That you say that you actually
mean this says it all.  Clearly this is something that isn't agreed upon
universally.  Your personal taste shouldn't decide the future of a project
used by so many others.
* No additional work (we don't need to migrate, just use the features when
modifying a line for a bug/feature anyway)This is simply not true.  There
have been comments by devs on this very list, in this very discussion that
disprove this point.  It isn't OK to just ignore their input because you
really want to use lambdas.

* We leave no one behind b/c of Maven 3.8/3.9, thus no drawbacks.You have
that backwards.  If you leave Java8, you leave behind everyone who can't
upgrade their source base.  It seems to me that the size of the group of
Java8 folks you will leave behind is quite large.  So your argument about
no drawbacks isn't credible.  The

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hunter C Payne]

 Other projects have tried to do that (given they are different types of 
projects) and it turned out that keeping JVM8 support going when not compiling 
on JDK8 proved difficult and when push came to shove, it was JVM 8 support that 
was dropped.  I know that's not you or this project, but human nature is what 
it is and patterns tend to repeat.  So while I understand what you are saying, 
I have my doubts based upon past projects I have seen do this.

On the other hand, the reasons for the upgrade are always a bit weak and the 
upgrade really only created lots of support work for the devs and users (the 
security model is especially an issue) and yes they thought it would be 
seem-less too.  Writing code in any other JVM language would accomplish what 
you want far more effectively.  Instead you want to put lipstick on the pig and 
act like Java 21 is somehow like more modern languages (it isn't, it never will 
be).   Just because you can pass a function in Java, doesn't make it a FP 
language.  It has no currying, no function composition, it lacks a self-type, 
there are no concepts of co or contra variance in the types and that's just a 
short list off the top of my head.  That's the direction you are pushing with 
what you are asking about but Java 21 isn't the answer there as it has none of 
these things, while almost all of them would be useful in Maven itself.
So from my perspective, you are proposing a solution to a problem that doesn't 
exist while at the same time the solution you propose doesn't truly give you 
what you want.  Nobody wanting to a new language on their CV is going to need 
that language to be Java.  If they are joining the Maven project, it is likely 
because they want to contribute to Maven, not because Maven uses JDK 21.  And 
your users just don't want to be bothered and want their build system to work.  
It is hardly ideal and I have sympathy but it doesn't make dropping building of 
Maven by javac8 the right call.

Hunter
On Monday, June 5, 2023 at 02:22:59 PM PDT, Delany 
 wrote:  
 
 Your inclination to ignore points of the debate doesn't do your own
arguments any justice.
Multiple times it's been explained that raising the required runtime JDK in
Maven 4 will not prevent you from
- building with a lower JDK (via toolchains)
- targeting a lower JDK (via the release property)
- building with Maven 3

This is the main point of the debate, not the language.

On Mon, 5 Jun 2023 at 21:42, Hunter C Payne
 wrote:

> * Attract devsAbsolutely not.  If you want to attract devs, switch to a
> language that is actually growing (no I'm advocating for this).  That isn't
> Java.  If anything, this will lose you devs.  The company I work for will
> be leaving Maven if you stop supporting Java8.  That's 300 users you lose
> right there.  That's just 1 company.  You will lose users in droves if you
> stop Java8 support.  Many companies don't have/put enough resources into
> this type of upgrade.  Its hard to justify to the business and it makes
> lots of work for devs (expensive).  If it is cheaper to switch build
> systems that to upgrade the JVM, that's exactly what folks will do.  My
> company certainly will (not my decision so don't try to convince me, I'm
> not the one you have to convince).
>
> * CDS for non-OpenJ9-usersI'm not sure this is something that is really
> taken advantage of by Maven.  Perhaps I am wrong.
>
> * Better clarity of code (yes, I mean that)That you say that you actually
> mean this says it all.  Clearly this is something that isn't agreed upon
> universally.  Your personal taste shouldn't decide the future of a project
> used by so many others.
> * No additional work (we don't need to migrate, just use the features when
> modifying a line for a bug/feature anyway)This is simply not true.  There
> have been comments by devs on this very list, in this very discussion that
> disprove this point.  It isn't OK to just ignore their input because you
> really want to use lambdas.
>
> * We leave no one behind b/c of Maven 3.8/3.9, thus no drawbacks.You have
> that backwards.  If you leave Java8, you leave behind everyone who can't
> upgrade their source base.  It seems to me that the size of the group of
> Java8 folks you will leave behind is quite large.  So your argument about
> no drawbacks isn't credible.  There are no drawbacks for you, that isn't
> the same as there being no drawbacks for the entire user base.
> * By the time Maven 4 final is out, your views might have changed!I write
> most of my code in Scala so I doubt it seriously.
>
> Your points are not nearly as strong as you imply with your tone.  Some of
> them indicate a lack of understanding of some more advanced parts of FP
> which is understandable for Java devs but doesn't make your points
> correct.  And your analysis of the impact on the userbase is just plain
> wrong.  If you want people to bomb this list with complains, drop Java 8
> support and enjoy the rage postings you get from 100s to 1

Re: [VOTE] Release Maven Project Info Reports Plugin version 3.4.5

[Slawomir Jaranowski]

+1

Jira report is not complete - contains 2 issues, but release notes has 4
https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/jira-report.html


sob., 3 cze 2023 o 15:10 Michael Osipov  napisał(a):

> Hi,
>
> we solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821&version=12353297
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MPIR/issues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1951/
>
> https://repository.apache.org/content/repositories/maven-1951/org/apache/maven/plugins/maven-project-info-reports-plugin/3.4.5/maven-project-info-reports-plugin-3.4.5-source-release.zip
>
> Source release checksum(s):
> maven-project-info-reports-plugin-3.4.5-source-release.zip
> sha512:
>
> 75631dc43b83190bceab61f7311d620824bf1d8c8efd406014c287021fa4aeedb6fc40fd111f8ecc7c742bc1ae55ba039fec65bb3bba3cf6a8f514cb9bbc44e6
>
> Staging site:
>
> https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Delany]

Your inclination to ignore points of the debate doesn't do your own
arguments any justice.
Multiple times it's been explained that raising the required runtime JDK in
Maven 4 will not prevent you from
- building with a lower JDK (via toolchains)
- targeting a lower JDK (via the release property)
- building with Maven 3

This is the main point of the debate, not the language.

On Mon, 5 Jun 2023 at 21:42, Hunter C Payne
 wrote:

> * Attract devsAbsolutely not.  If you want to attract devs, switch to a
> language that is actually growing (no I'm advocating for this).  That isn't
> Java.  If anything, this will lose you devs.  The company I work for will
> be leaving Maven if you stop supporting Java8.  That's 300 users you lose
> right there.  That's just 1 company.  You will lose users in droves if you
> stop Java8 support.  Many companies don't have/put enough resources into
> this type of upgrade.  Its hard to justify to the business and it makes
> lots of work for devs (expensive).  If it is cheaper to switch build
> systems that to upgrade the JVM, that's exactly what folks will do.  My
> company certainly will (not my decision so don't try to convince me, I'm
> not the one you have to convince).
>
> * CDS for non-OpenJ9-usersI'm not sure this is something that is really
> taken advantage of by Maven.  Perhaps I am wrong.
>
> * Better clarity of code (yes, I mean that)That you say that you actually
> mean this says it all.  Clearly this is something that isn't agreed upon
> universally.  Your personal taste shouldn't decide the future of a project
> used by so many others.
> * No additional work (we don't need to migrate, just use the features when
> modifying a line for a bug/feature anyway)This is simply not true.  There
> have been comments by devs on this very list, in this very discussion that
> disprove this point.  It isn't OK to just ignore their input because you
> really want to use lambdas.
>
> * We leave no one behind b/c of Maven 3.8/3.9, thus no drawbacks.You have
> that backwards.   If you leave Java8, you leave behind everyone who can't
> upgrade their source base.  It seems to me that the size of the group of
> Java8 folks you will leave behind is quite large.  So your argument about
> no drawbacks isn't credible.  There are no drawbacks for you, that isn't
> the same as there being no drawbacks for the entire user base.
> * By the time Maven 4 final is out, your views might have changed!I write
> most of my code in Scala so I doubt it seriously.
>
> Your points are not nearly as strong as you imply with your tone.  Some of
> them indicate a lack of understanding of some more advanced parts of FP
> which is understandable for Java devs but doesn't make your points
> correct.  And your analysis of the impact on the userbase is just plain
> wrong.  If you want people to bomb this list with complains, drop Java 8
> support and enjoy the rage postings you get from 100s to 1000s of devs who
> work for companies and projects that don't have to resources to upgrade.
>
> Hunter
> PS Lambdas are only useful if there is function composition and currying.
> Java lacks both.  So the debate over lambdas is pretty amusing to me.  It
> is just syntactic sugar.  It doesn't actually give you the ability to do
> other things like in Scala or Kotlin.  So I don't really understand why you
> want to use them so much.  Are for loops really that hard to write?  I mean
> there is already so much ceremony in Java that saving 3 or 4 keystrokes per
> loop doesn't really make any difference.
>
>
>On Monday, June 5, 2023 at 11:52:16 AM PDT, Tamás Cservenák <
> ta...@cservenak.net> wrote:
>
>  Seems people missed this (somewhat related) thread:
>
> https://lists.apache.org/thread/kpsrb28nst84vtohwngy3140g1r0ydd4
>
> Thanks
>
>
> On Mon, Jun 5, 2023, 20:40 Hunter C Payne  .invalid>
> wrote:
>
> >  Hi,  Karl, I'm not sure I agree you have "stated a benefit" so far.
> > There have been plenty of hand-wavy arguments but nothing really solid.
> > That's why you are getting so much push back.  Point to a specific
> feature
> > you need or some other thing that would help the project in some
> > significant way.  At the moment, the argument is basically, "its newer so
> > its better", I'm sorry but that simply is not true.  Make a better case
> and
> > you will get less pushback.
> > Hunter
> >
> >On Monday, June 5, 2023 at 06:03:26 AM PDT, Karl Heinz Marbaise <
> > khmarba...@gmx.de> wrote:
> >
> >  Hi,
> >
> > On 03.06.23 11:46, Hervé Boutemy wrote:
> > > +1
> > >
> > > I really don't what benefit we get from going to Java 17
> >
> > which was already part of the email:
> >
> >
> >  > Based on the argument we don't need  features of JDK17+ I see a number
> >  > of things which could make our handling/maintenance easier for example
> >  > using sealed classes to prevent exposing internal things to public
> which
> >  > could be used etc. also some other small features (`var` for example;
> >  > Text-Blocks in Test

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Romain Manni-Bucau]

Hunter, a language done for java (think mojo, no real choice to zmbrace
bytecode ecosystem) which is growing is java...scala is dead, groovy dont
grow anymore and kotlin kind of stopped too so maybe you do it everydays as
some people but ecosystem is clearly not on that side. This part is not
really discussable IMHO so guess your fight will only be yours there.

Le lun. 5 juin 2023 à 21:41, Hunter C Payne
 a écrit :

> Ok, so let's take these points one at a time:* Reduce build matrix, save
> energySo, less builds which is good but pretty minimal value.
> * Attract devsAbsolutely not.  If you want to attract devs, switch to a
> language that is actually growing (no I'm advocating for this).  That isn't
> Java.  If anything, this will lose you devs.  The company I work for will
> be leaving Maven if you stop supporting Java8.  That's 300 users you lose
> right there.  That's just 1 company.  You will lose users in droves if you
> stop Java8 support.  Many companies don't have/put enough resources into
> this type of upgrade.  Its hard to justify to the business and it makes
> lots of work for devs (expensive).  If it is cheaper to switch build
> systems that to upgrade the JVM, that's exactly what folks will do.  My
> company certainly will (not my decision so don't try to convince me, I'm
> not the one you have to convince).
>
> * CDS for non-OpenJ9-usersI'm not sure this is something that is really
> taken advantage of by Maven.  Perhaps I am wrong.
>
> * Better clarity of code (yes, I mean that)That you say that you actually
> mean this says it all.  Clearly this is something that isn't agreed upon
> universally.  Your personal taste shouldn't decide the future of a project
> used by so many others.
> * No additional work (we don't need to migrate, just use the features when
> modifying a line for a bug/feature anyway)This is simply not true.  There
> have been comments by devs on this very list, in this very discussion that
> disprove this point.  It isn't OK to just ignore their input because you
> really want to use lambdas.
>
> * We leave no one behind b/c of Maven 3.8/3.9, thus no drawbacks.You have
> that backwards.   If you leave Java8, you leave behind everyone who can't
> upgrade their source base.  It seems to me that the size of the group of
> Java8 folks you will leave behind is quite large.  So your argument about
> no drawbacks isn't credible.  There are no drawbacks for you, that isn't
> the same as there being no drawbacks for the entire user base.
> * By the time Maven 4 final is out, your views might have changed!I write
> most of my code in Scala so I doubt it seriously.
>
> Your points are not nearly as strong as you imply with your tone.  Some of
> them indicate a lack of understanding of some more advanced parts of FP
> which is understandable for Java devs but doesn't make your points
> correct.  And your analysis of the impact on the userbase is just plain
> wrong.  If you want people to bomb this list with complains, drop Java 8
> support and enjoy the rage postings you get from 100s to 1000s of devs who
> work for companies and projects that don't have to resources to upgrade.
>
> Hunter
> PS Lambdas are only useful if there is function composition and currying.
> Java lacks both.  So the debate over lambdas is pretty amusing to me.  It
> is just syntactic sugar.  It doesn't actually give you the ability to do
> other things like in Scala or Kotlin.  So I don't really understand why you
> want to use them so much.  Are for loops really that hard to write?  I mean
> there is already so much ceremony in Java that saving 3 or 4 keystrokes per
> loop doesn't really make any difference.
>
>
>On Monday, June 5, 2023 at 11:52:16 AM PDT, Tamás Cservenák <
> ta...@cservenak.net> wrote:
>
>  Seems people missed this (somewhat related) thread:
>
> https://lists.apache.org/thread/kpsrb28nst84vtohwngy3140g1r0ydd4
>
> Thanks
>
>
> On Mon, Jun 5, 2023, 20:40 Hunter C Payne  .invalid>
> wrote:
>
> >  Hi,  Karl, I'm not sure I agree you have "stated a benefit" so far.
> > There have been plenty of hand-wavy arguments but nothing really solid.
> > That's why you are getting so much push back.  Point to a specific
> feature
> > you need or some other thing that would help the project in some
> > significant way.  At the moment, the argument is basically, "its newer so
> > its better", I'm sorry but that simply is not true.  Make a better case
> and
> > you will get less pushback.
> > Hunter
> >
> >On Monday, June 5, 2023 at 06:03:26 AM PDT, Karl Heinz Marbaise <
> > khmarba...@gmx.de> wrote:
> >
> >  Hi,
> >
> > On 03.06.23 11:46, Hervé Boutemy wrote:
> > > +1
> > >
> > > I really don't what benefit we get from going to Java 17
> >
> > which was already part of the email:
> >
> >
> >  > Based on the argument we don't need  features of JDK17+ I see a number
> >  > of things which could make our handling/maintenance easier for example
> >  > using sealed classes to prevent exposing internal 

Re: [HEADS UP] Upcoming Resolver and Maven releases

[Henning Schmiedehausen]

I don't care about the threads. They are fine with me. I care about the
amount of ceremony that you create that eats into developer time. If you
want to do it for yourself: feel free to do so. It is your time after all.

But you and others then turn around and say "everyone now needs to do what
I am doing and you can no longer work the way that Apache always worked".
And I object to that.

There is value in ceremony for large, gnarly, critical changes that need
discussion. And those should be approached very carefully and slowly. But
having ceremony for a non-controversial, one line change that can be backed
out easily if needed, is ceremony for ceremonies' sake.

-h




On Wed, May 31, 2023 at 4:23 AM Tamás Cservenák  wrote:

> Henning,
>
> This intent of all threads (the "[HEADS UP]") that I have been creating
> since the 3.9.0 release was actually meant as a communication effort to
> users not on ML (btw, see related comm related discussions). What I usually
> do is copy the ponymail URL of the thread and post it on twitter or
> mastodon etc.
> People not on ML are still eager to be "in the loop", to get the news about
> 3.9.x just like you might be.
>
> While I understand your frustration about these threads (probably noise to
> you), please understand the intent behind these threads it as well.
>
> Thanks
> T
>
>
>
> On Sun, May 28, 2023 at 10:58 PM Henning Schmiedehausen <
> henn...@schmiedehausen.org> wrote:
>
> > You spend so much time on ceremony and bureaucracy by filing tickets that
> > no one is going to pick up or read and then creating pull requests that
> at
> > best will be glanced at and then "LGTM"ed.
> >
> > This is a trivial, non-controversial change that any committer can just
> > commit. Worst case scenario, someone else is going to comment on it and
> > then it can be iterated. That is how Apache has always worked and why CTR
> > is more efficient with a small team. Every committer is explicitly
> trusted
> > to work on the code base without constant "there needs to be a ticket.
> > there needs to be a PR. there needs to be a week of discussion whether
> that
> > change is good. there needs to be "approval" or "majority agreement" by
> > some star chamber that can decide what is good for the project.
> >
> > Reserve the ceremony and discussion for the large, gnarly, controversial
> > changes that warrant discussion and where there is value in doing more
> > upfront planning. But for god's sake, stop doing ceremony for ceremony's
> > sake.
> >
> > It is a literal one-liner. - https://github.com/apache/maven/pull/1132
> >
> > -h
> >
> >
> > On Fri, May 26, 2023 at 1:24 PM Tamás Cservenák 
> > wrote:
> >
> > > Howdy,
> > >
> > > good call, created https://issues.apache.org/jira/browse/MNG-7797
> > >
> > > Thanks
> > > T
> > >
> > > On Fri, May 26, 2023 at 10:09 PM Henning Schmiedehausen <
> > > henn...@schmiedehausen.org> wrote:
> > >
> > > > maven 3.9.2:
> > > >
> > > > mvn -DskipTests -Dmaven.plugin.validation=BRIEF -pl :jdbi3-core clean
> > > > install
> > > > [...]
> > > >
> > > > current 3.9.3-SNAPSHOT:
> > > >
> > > > mvn -DskipTests -Dmaven.plugin.validation=BRIEF -pl :jdbi3-core clean
> > > > install
> > > > [...]
> > > >
> > > > *[WARNING] Invalid value specified for property
> > maven.plugin.validation:
> > > > 'BRIEF'. Supported values are (case insensitive): [NONE, INLINE,
> > SUMMARY,
> > > > VERBOSE]*
> > > >
> > > > You shipped "BRIEF" in 3.9.2, removing it now breaks scripts that
> added
> > > > this to the command line or the pom.
> > > >
> > > > I suggest mapping "BRIEF" to "SUMMARY".
> > > >
> > > > -h
> > > >
> > > >
> > > > On Fri, May 26, 2023 at 12:46 AM Tamás Cservenák <
> ta...@cservenak.net>
> > > > wrote:
> > > >
> > > > > Howdy,
> > > > >
> > > > > Resolver 1.9.11 is shaping:
> > > > >
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.11
> > > > >
> > > > > one resolver issue under scrutiny:
> > > > > https://issues.apache.org/jira/browse/MRESOLVER-362
> > > > >
> > > > > Maven 3.9.3 as well:
> > > > >
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.3
> > > > >
> > > > > As usual, I plan these for next week, so if anyone has anything to
> > say,
> > > > > speak up!
> > > > >
> > > > > Thanks
> > > > > T
> > > > >
> > > >
> > >
> >
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hunter C Payne]

Ok, so let's take these points one at a time:* Reduce build matrix, save 
energySo, less builds which is good but pretty minimal value.
* Attract devsAbsolutely not.  If you want to attract devs, switch to a 
language that is actually growing (no I'm advocating for this).  That isn't 
Java.  If anything, this will lose you devs.  The company I work for will be 
leaving Maven if you stop supporting Java8.  That's 300 users you lose right 
there.  That's just 1 company.  You will lose users in droves if you stop Java8 
support.  Many companies don't have/put enough resources into this type of 
upgrade.  Its hard to justify to the business and it makes lots of work for 
devs (expensive).  If it is cheaper to switch build systems that to upgrade the 
JVM, that's exactly what folks will do.  My company certainly will (not my 
decision so don't try to convince me, I'm not the one you have to convince).

* CDS for non-OpenJ9-usersI'm not sure this is something that is really taken 
advantage of by Maven.  Perhaps I am wrong.

* Better clarity of code (yes, I mean that)That you say that you actually mean 
this says it all.  Clearly this is something that isn't agreed upon 
universally.  Your personal taste shouldn't decide the future of a project used 
by so many others.
* No additional work (we don't need to migrate, just use the features when
modifying a line for a bug/feature anyway)This is simply not true.  There have 
been comments by devs on this very list, in this very discussion that disprove 
this point.  It isn't OK to just ignore their input because you really want to 
use lambdas.

* We leave no one behind b/c of Maven 3.8/3.9, thus no drawbacks.You have that 
backwards.   If you leave Java8, you leave behind everyone who can't upgrade 
their source base.  It seems to me that the size of the group of Java8 folks 
you will leave behind is quite large.  So your argument about no drawbacks 
isn't credible.  There are no drawbacks for you, that isn't the same as there 
being no drawbacks for the entire user base.
* By the time Maven 4 final is out, your views might have changed!I write most 
of my code in Scala so I doubt it seriously.

Your points are not nearly as strong as you imply with your tone.  Some of them 
indicate a lack of understanding of some more advanced parts of FP which is 
understandable for Java devs but doesn't make your points correct.  And your 
analysis of the impact on the userbase is just plain wrong.  If you want people 
to bomb this list with complains, drop Java 8 support and enjoy the rage 
postings you get from 100s to 1000s of devs who work for companies and projects 
that don't have to resources to upgrade.

Hunter
PS Lambdas are only useful if there is function composition and currying.  Java 
lacks both.  So the debate over lambdas is pretty amusing to me.  It is just 
syntactic sugar.  It doesn't actually give you the ability to do other things 
like in Scala or Kotlin.  So I don't really understand why you want to use them 
so much.  Are for loops really that hard to write?  I mean there is already so 
much ceremony in Java that saving 3 or 4 keystrokes per loop doesn't really 
make any difference.


   On Monday, June 5, 2023 at 11:52:16 AM PDT, Tamás Cservenák 
 wrote:  
 
 Seems people missed this (somewhat related) thread:

https://lists.apache.org/thread/kpsrb28nst84vtohwngy3140g1r0ydd4

Thanks


On Mon, Jun 5, 2023, 20:40 Hunter C Payne 
wrote:

>  Hi,  Karl, I'm not sure I agree you have "stated a benefit" so far.
> There have been plenty of hand-wavy arguments but nothing really solid.
> That's why you are getting so much push back.  Point to a specific feature
> you need or some other thing that would help the project in some
> significant way.  At the moment, the argument is basically, "its newer so
> its better", I'm sorry but that simply is not true.  Make a better case and
> you will get less pushback.
> Hunter
>
>    On Monday, June 5, 2023 at 06:03:26 AM PDT, Karl Heinz Marbaise <
> khmarba...@gmx.de> wrote:
>
>  Hi,
>
> On 03.06.23 11:46, Hervé Boutemy wrote:
> > +1
> >
> > I really don't what benefit we get from going to Java 17
>
> which was already part of the email:
>
>
>  > Based on the argument we don't need  features of JDK17+ I see a number
>  > of things which could make our handling/maintenance easier for example
>  > using sealed classes to prevent exposing internal things to public which
>  > could be used etc. also some other small features (`var` for example;
>  > Text-Blocks in Tests etc) or using records in some situation (really
> immutability)..
>  >
>  >
>
>
> Kind regards
> Karl Heinz Marbaise
>
> >
> > I perfectly see the impact we'll have on our users: for what benefit?
> >
> > notice that this will also impact all plugins: and given the few work
> done on
> > plugins to clearly show what plugin version remains compatible with a JDK
> > release, I feel we're not taking the topic the right way
> >
> > Le vendredi 2 juin 2023, 01:50:5

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Tamás Cservenák]

Seems people missed this (somewhat related) thread:

https://lists.apache.org/thread/kpsrb28nst84vtohwngy3140g1r0ydd4

Thanks


On Mon, Jun 5, 2023, 20:40 Hunter C Payne 
wrote:

>  Hi,  Karl, I'm not sure I agree you have "stated a benefit" so far.
> There have been plenty of hand-wavy arguments but nothing really solid.
> That's why you are getting so much push back.  Point to a specific feature
> you need or some other thing that would help the project in some
> significant way.  At the moment, the argument is basically, "its newer so
> its better", I'm sorry but that simply is not true.  Make a better case and
> you will get less pushback.
> Hunter
>
> On Monday, June 5, 2023 at 06:03:26 AM PDT, Karl Heinz Marbaise <
> khmarba...@gmx.de> wrote:
>
>  Hi,
>
> On 03.06.23 11:46, Hervé Boutemy wrote:
> > +1
> >
> > I really don't what benefit we get from going to Java 17
>
> which was already part of the email:
>
>
>  > Based on the argument we don't need  features of JDK17+ I see a number
>  > of things which could make our handling/maintenance easier for example
>  > using sealed classes to prevent exposing internal things to public which
>  > could be used etc. also some other small features (`var` for example;
>  > Text-Blocks in Tests etc) or using records in some situation (really
> immutability)..
>  >
>  >
>
>
> Kind regards
> Karl Heinz Marbaise
>
> >
> > I perfectly see the impact we'll have on our users: for what benefit?
> >
> > notice that this will also impact all plugins: and given the few work
> done on
> > plugins to clearly show what plugin version remains compatible with a JDK
> > release, I feel we're not taking the topic the right way
> >
> > Le vendredi 2 juin 2023, 01:50:53 CEST Hunter C Payne a écrit :
> >>  I'm not sure I would worry too much about that David.  I think most
> devs
> >> who want better syntax moved from Java sometime ago.  They might still
> be
> >> on the JVM just not writing Java.  Also, Maven is a mature project.  I
> >> don't think devs considering contributing to it are thinking about using
> >> the latest and greatest version of Java.  Compatibility is probably a
> >> bigger concern for the user base.  Just my opinion.
> >>
> >> Hunter
> >>  On Thursday, June 1, 2023 at 04:17:26 PM PDT, David Jencks
> >>  wrote:
> >>
> >>  I wonder if having maven require java 8 syntax discourages any
> potential
> >> contributors who are used to coding using more recent developments. I
> have
> >> no idea how to tell, but maybe someone else does.
> >>
> >> David Jencks
> >>
> >>> On Jun 1, 2023, at 3:02 PM, Karl Heinz Marbaise 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> my clear opinion is to go  with most recent JDK LTS version for the
> >>> release point of Maven 4.0.0 which I assume will be JDK 21...
> >>>
> >>> That means clear the build time requirement which is completely
> >>> different from runtime of an application.
> >>>
> >>>
> >>> Older JDK's are supported by some vendors by having particular special
> >>> support which most of the time requires special contracts (means also
> >>> paying money for it)..some of them offering builds without paying money
> >>> yes..
> >>>
> >>> Older runtime target are supported with different approaches like
> >>> Toolchain or via `--release XX` which exists since JDK9+.
> >>>
> >>>
> >>> Furthermore if someone is not capable of upgrading the build
> environment
> >>> to JDK9+ they can continue to use Maven 3.8.X or Maven 3.9.X...
> >>>
> >>> If it would be requirement to port things back to 3.8.X or 3.9.X it
> >>> could be handled by someone who has the time etc. to do that ... if
> not,
> >>> those people might think of paying someone to do that work...
> >>>
> >>>
> >>> The given argument about JPMS for migration causes issues is from my
> >>> point of view false-positive because migration to newer JDK versions
> >>> does not require JPMS usage...
> >>>
> >>> Even platforms like AWS support JDK17 in the meantime which is the
> >>> runtime...
> >>>
> >>>
> >>> Based on the maintenance part it would mean in consequence to downgrade
> >>> to even JDK7... (or even lower) because you can get support for older
> >>> JDK version in some ways... (JDK7 from azul for example)
> >>>
> >>> Kind regards
> >>> Karl Heinz Marbaise
> >>>
> >>> [1]
> https://www.oracle.com/java/technologies/java-se-support-roadmap.html
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Benjamin Marwell]

Ok, here's a benefit of Java 11/17 or two:

* Reduce build matrix, save energy
* Attract devs
* CDS for non-OpenJ9-users
* Better clarity of code (yes, I mean that)
* No additional work (we don't need to migrate, just use the features when
modifying a line for a bug/feature anyway)
* We leave no one behind b/c of Maven 3.8/3.9, thus no drawbacks.
* By the time Maven 4 final is out, your views might have changed!

So Hunter, these have all been brought up before. We can continue with 8,
yes. But new projects will use Java 17 anyway, and Java 17 gives us less
complex code.

That really should be good enough. Really.

 - Ben


On Mon, 5 Jun 2023, 20:40 Hunter C Payne, 
wrote:

>  Hi,  Karl, I'm not sure I agree you have "stated a benefit" so far.
> There have been plenty of hand-wavy arguments but nothing really solid.
> That's why you are getting so much push back.  Point to a specific feature
> you need or some other thing that would help the project in some
> significant way.  At the moment, the argument is basically, "its newer so
> its better", I'm sorry but that simply is not true.  Make a better case and
> you will get less pushback.
> Hunter
>
> On Monday, June 5, 2023 at 06:03:26 AM PDT, Karl Heinz Marbaise <
> khmarba...@gmx.de> wrote:
>
>  Hi,
>
> On 03.06.23 11:46, Hervé Boutemy wrote:
> > +1
> >
> > I really don't what benefit we get from going to Java 17
>
> which was already part of the email:
>
>
>  > Based on the argument we don't need  features of JDK17+ I see a number
>  > of things which could make our handling/maintenance easier for example
>  > using sealed classes to prevent exposing internal things to public which
>  > could be used etc. also some other small features (`var` for example;
>  > Text-Blocks in Tests etc) or using records in some situation (really
> immutability)..
>  >
>  >
>
>
> Kind regards
> Karl Heinz Marbaise
>
> >
> > I perfectly see the impact we'll have on our users: for what benefit?
> >
> > notice that this will also impact all plugins: and given the few work
> done on
> > plugins to clearly show what plugin version remains compatible with a JDK
> > release, I feel we're not taking the topic the right way
> >
> > Le vendredi 2 juin 2023, 01:50:53 CEST Hunter C Payne a écrit :
> >>  I'm not sure I would worry too much about that David.  I think most
> devs
> >> who want better syntax moved from Java sometime ago.  They might still
> be
> >> on the JVM just not writing Java.  Also, Maven is a mature project.  I
> >> don't think devs considering contributing to it are thinking about using
> >> the latest and greatest version of Java.  Compatibility is probably a
> >> bigger concern for the user base.  Just my opinion.
> >>
> >> Hunter
> >>  On Thursday, June 1, 2023 at 04:17:26 PM PDT, David Jencks
> >>  wrote:
> >>
> >>  I wonder if having maven require java 8 syntax discourages any
> potential
> >> contributors who are used to coding using more recent developments. I
> have
> >> no idea how to tell, but maybe someone else does.
> >>
> >> David Jencks
> >>
> >>> On Jun 1, 2023, at 3:02 PM, Karl Heinz Marbaise 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> my clear opinion is to go  with most recent JDK LTS version for the
> >>> release point of Maven 4.0.0 which I assume will be JDK 21...
> >>>
> >>> That means clear the build time requirement which is completely
> >>> different from runtime of an application.
> >>>
> >>>
> >>> Older JDK's are supported by some vendors by having particular special
> >>> support which most of the time requires special contracts (means also
> >>> paying money for it)..some of them offering builds without paying money
> >>> yes..
> >>>
> >>> Older runtime target are supported with different approaches like
> >>> Toolchain or via `--release XX` which exists since JDK9+.
> >>>
> >>>
> >>> Furthermore if someone is not capable of upgrading the build
> environment
> >>> to JDK9+ they can continue to use Maven 3.8.X or Maven 3.9.X...
> >>>
> >>> If it would be requirement to port things back to 3.8.X or 3.9.X it
> >>> could be handled by someone who has the time etc. to do that ... if
> not,
> >>> those people might think of paying someone to do that work...
> >>>
> >>>
> >>> The given argument about JPMS for migration causes issues is from my
> >>> point of view false-positive because migration to newer JDK versions
> >>> does not require JPMS usage...
> >>>
> >>> Even platforms like AWS support JDK17 in the meantime which is the
> >>> runtime...
> >>>
> >>>
> >>> Based on the maintenance part it would mean in consequence to downgrade
> >>> to even JDK7... (or even lower) because you can get support for older
> >>> JDK version in some ways... (JDK7 from azul for example)
> >>>
> >>> Kind regards
> >>> Karl Heinz Marbaise
> >>>
> >>> [1]
> https://www.oracle.com/java/technologies/java-se-support-roadmap.html
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.or

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hunter C Payne]

 Hi,  Karl, I'm not sure I agree you have "stated a benefit" so far.  There 
have been plenty of hand-wavy arguments but nothing really solid.  That's why 
you are getting so much push back.  Point to a specific feature you need or 
some other thing that would help the project in some significant way.  At the 
moment, the argument is basically, "its newer so its better", I'm sorry but 
that simply is not true.  Make a better case and you will get less pushback.
Hunter

On Monday, June 5, 2023 at 06:03:26 AM PDT, Karl Heinz Marbaise 
 wrote:  
 
 Hi,

On 03.06.23 11:46, Hervé Boutemy wrote:
> +1
>
> I really don't what benefit we get from going to Java 17

which was already part of the email:


 > Based on the argument we don't need  features of JDK17+ I see a number
 > of things which could make our handling/maintenance easier for example
 > using sealed classes to prevent exposing internal things to public which
 > could be used etc. also some other small features (`var` for example;
 > Text-Blocks in Tests etc) or using records in some situation (really
immutability)..
 >
 >


Kind regards
Karl Heinz Marbaise

>
> I perfectly see the impact we'll have on our users: for what benefit?
>
> notice that this will also impact all plugins: and given the few work done on
> plugins to clearly show what plugin version remains compatible with a JDK
> release, I feel we're not taking the topic the right way
>
> Le vendredi 2 juin 2023, 01:50:53 CEST Hunter C Payne a écrit :
>>  I'm not sure I would worry too much about that David.  I think most devs
>> who want better syntax moved from Java sometime ago.  They might still be
>> on the JVM just not writing Java.  Also, Maven is a mature project.  I
>> don't think devs considering contributing to it are thinking about using
>> the latest and greatest version of Java.  Compatibility is probably a
>> bigger concern for the user base.  Just my opinion.
>>
>> Hunter
>>      On Thursday, June 1, 2023 at 04:17:26 PM PDT, David Jencks
>>  wrote:
>>
>>  I wonder if having maven require java 8 syntax discourages any potential
>> contributors who are used to coding using more recent developments. I have
>> no idea how to tell, but maybe someone else does.
>>
>> David Jencks
>>
>>> On Jun 1, 2023, at 3:02 PM, Karl Heinz Marbaise  wrote:
>>>
>>> Hi,
>>>
>>> my clear opinion is to go  with most recent JDK LTS version for the
>>> release point of Maven 4.0.0 which I assume will be JDK 21...
>>>
>>> That means clear the build time requirement which is completely
>>> different from runtime of an application.
>>>
>>>
>>> Older JDK's are supported by some vendors by having particular special
>>> support which most of the time requires special contracts (means also
>>> paying money for it)..some of them offering builds without paying money
>>> yes..
>>>
>>> Older runtime target are supported with different approaches like
>>> Toolchain or via `--release XX` which exists since JDK9+.
>>>
>>>
>>> Furthermore if someone is not capable of upgrading the build environment
>>> to JDK9+ they can continue to use Maven 3.8.X or Maven 3.9.X...
>>>
>>> If it would be requirement to port things back to 3.8.X or 3.9.X it
>>> could be handled by someone who has the time etc. to do that ... if not,
>>> those people might think of paying someone to do that work...
>>>
>>>
>>> The given argument about JPMS for migration causes issues is from my
>>> point of view false-positive because migration to newer JDK versions
>>> does not require JPMS usage...
>>>
>>> Even platforms like AWS support JDK17 in the meantime which is the
>>> runtime...
>>>
>>>
>>> Based on the maintenance part it would mean in consequence to downgrade
>>> to even JDK7... (or even lower) because you can get support for older
>>> JDK version in some ways... (JDK7 from azul for example)
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>> [1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html


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

  

Call for Presentations, Community Over Code Asia 2023

[Rich Bowen]

You are receiving this message because you are subscribed to one more
more developer mailing lists at the Apache Software Foundation.

The call for presentations is now open at
"https://apachecon.com/acasia2023/cfp.html";, and will be closed by
Sunday, Jun 18th, 2023 11:59 PM GMT.

The event will be held in Beijing, China, August 18-20, 2023.

We are looking for presentations about anything relating to Apache
Software Foundation projects, open-source governance, community, and
software development.
In particular, this year we are building content tracks around the
following specific topics/projects:

AI / Machine learning
API / Microservice
Community
CloudNative
Data Storage & Computing
DataOps
Data Lake & Data Warehouse
OLAP & Data Analysis
Performance Engineering
Incubator
IoT/IIoT
Messaging
RPC
Streaming
Workflow / Data Processing
Web Server / Tomcat

If your proposed presentation falls into one of these categories,
please select that topic in the CFP entry form. Or select Others if
it’s related to another topic or project area.

Looking forward to hearing from you!

Willem Jiang, and the Community Over Code planners


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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Karl Heinz Marbaise]

Hi,

On 03.06.23 11:46, Hervé Boutemy wrote:

+1

I really don't what benefit we get from going to Java 17


which was already part of the email:


> Based on the argument we don't need  features of JDK17+ I see a number
> of things which could make our handling/maintenance easier for example
> using sealed classes to prevent exposing internal things to public which
> could be used etc. also some other small features (`var` for example;
> Text-Blocks in Tests etc) or using records in some situation (really
immutability)..
>
>


Kind regards
Karl Heinz Marbaise



I perfectly see the impact we'll have on our users: for what benefit?

notice that this will also impact all plugins: and given the few work done on
plugins to clearly show what plugin version remains compatible with a JDK
release, I feel we're not taking the topic the right way

Le vendredi 2 juin 2023, 01:50:53 CEST Hunter C Payne a écrit :

  I'm not sure I would worry too much about that David.  I think most devs
who want better syntax moved from Java sometime ago.  They might still be
on the JVM just not writing Java.  Also, Maven is a mature project.  I
don't think devs considering contributing to it are thinking about using
the latest and greatest version of Java.  Compatibility is probably a
bigger concern for the user base.  Just my opinion.

Hunter
 On Thursday, June 1, 2023 at 04:17:26 PM PDT, David Jencks
 wrote:

  I wonder if having maven require java 8 syntax discourages any potential
contributors who are used to coding using more recent developments. I have
no idea how to tell, but maybe someone else does.

David Jencks


On Jun 1, 2023, at 3:02 PM, Karl Heinz Marbaise  wrote:

Hi,

my clear opinion is to go  with most recent JDK LTS version for the
release point of Maven 4.0.0 which I assume will be JDK 21...

That means clear the build time requirement which is completely
different from runtime of an application.


Older JDK's are supported by some vendors by having particular special
support which most of the time requires special contracts (means also
paying money for it)..some of them offering builds without paying money
yes..

Older runtime target are supported with different approaches like
Toolchain or via `--release XX` which exists since JDK9+.


Furthermore if someone is not capable of upgrading the build environment
to JDK9+ they can continue to use Maven 3.8.X or Maven 3.9.X...

If it would be requirement to port things back to 3.8.X or 3.9.X it
could be handled by someone who has the time etc. to do that ... if not,
those people might think of paying someone to do that work...


The given argument about JPMS for migration causes issues is from my
point of view false-positive because migration to newer JDK versions
does not require JPMS usage...

Even platforms like AWS support JDK17 in the meantime which is the
runtime...


Based on the maintenance part it would mean in consequence to downgrade
to even JDK7... (or even lower) because you can get support for older
JDK version in some ways... (JDK7 from azul for example)

Kind regards
Karl Heinz Marbaise

[1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html



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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Karl Heinz Marbaise]

On 05.06.23 13:55, Romain Manni-Bucau wrote:

Hi


Le lun. 5 juin 2023 à 13:22, Elliotte Rusty Harold  a
écrit :


On Sun, Jun 4, 2023 at 10:59 AM Delany  wrote:


I think the point I'm making is no-one wants to write in an older version
of the language they started writing in. Its tedious. Anyone who started
writing java11 code is going to have a hard time accepting they need to
write in java8, just as a java8 will bulk at writing in java5. Of course
for the oldies it just feels nostalgic.



Strongly disagree. I personally would strongly prefer to stick to Java
*7*, although these days I use mostly 8 and 11. IMHO Java 8 and Java
11 were significant downgrades for clarity of code and ease of use.
While there were some nice improvements in libraries and VM in those
versions, they are completely swamped by the truly awful lambda syntax
and the useless pain of the Java Platform Module System.



This is a very interesting feedback cause we had the exact same on some
other ASF feedback in early lambdas days and today it is completely gone so
I guess it is just a habit thing.
So the point is either: do you fight against the scale of time or not and
if so is it ok for an asf project to reject potential contributors (because
it is what it means in practise, in particular when java 7 becomes hard to
get).


I second that... even today...




Note: I fully agree JPMS is useless but I also fully agree we don't need to
embrace it, it will not even be enabled until plexus-container does support
it, but it does not hurt, rest is more than fine and the new GC helps in a
software like maven.




Nor is it like we've finished the work of migrating onto Java 8. Just
this past week I replaced some code that hasn't been needed since Java
*1.4*.



This is a good point, my personal view on that is we had way too much
abstraction for the actual codepath we use so I would be +1 to drop most of
the deps we rely on to include a core and limited set in maven project,
this will help upgrades instead of having to rely on 50+ projects - indeed
just my 2cts.




Migrating to still newer Java versions is a distraction from far more
important work. We haven't even moved all the plugins off Java 7 yet.
The burden of proof is on people who want to migrate to Java 17 to
show how that will improve the project. That burden has not been met.



Nobody requested to migrate the code base, IMHO the points were mainly:

1. enable to use a "not too old" base version to keep it easy to contribute
and leverage interesting new features (note: not always API)
2. use an up to date and evolutive version (java 8 doesnt get all backports
these days, even in maintained distro so you can end up accessing a http
maven repo which is not supported depending the JVM you use)


Yep..


3. reduce the compatibility matrix right now since part of it is no more
useful for projects which will embrace mvn 4


Just build on most recent version of available JDK... and generate for
the target platform for example 11 (via --release)..


4. ensure you can upgrade dependencies and do no have to stick to
deprecated versions (libs started to drop java 8 support already)


That's another good point..




So yes Java 17 will not solve most of our issues but Java 8-21 support we
need to have already creates some in terms of validations, PR feedback, and
community message IMHO.



Since java 8 is covered by 3.9 I don't see why we would not take the
opportunity to move forward, syntax and details like that are a great
opportunity to learn for everybody more than a drawback from my past
experience and being able to use a reliable - cause we know it is supported
in the min version we use - http11 client with a better protocol support is
also important even if API didn't change much.


Yes Maven 3.9 or maybe 3.8.X will support JDK8... so no problem.


Kind regards
Karl Heinz Marbaise

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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Karl Heinz Marbaise]

Hi,

On 05.06.23 13:21, Elliotte Rusty Harold wrote:

On Sun, Jun 4, 2023 at 10:59 AM Delany  wrote:


I think the point I'm making is no-one wants to write in an older version
of the language they started writing in. Its tedious. Anyone who started
writing java11 code is going to have a hard time accepting they need to
write in java8, just as a java8 will bulk at writing in java5. Of course
for the oldies it just feels nostalgic.



Strongly disagree. I personally would strongly prefer to stick to Java
*7*,


> although these days I use mostly 8 and 11. IMHO Java 8 and Java

11 were significant downgrades for clarity of code and ease of use.


Ok... my experience is completely different... working from the
beginning on JDK8 after first GA of JDK11 on JDK 11 and now on JDK17 ...
also JDK 18...20 etc. At the moment experimenting with JDK21...



While there were some nice improvements in libraries and VM in those
versions, they are completely swamped by the truly awful lambda syntax
and the useless pain of the Java Platform Module System.


The JPMS is opt-in NOT opt-out.. and useless depends on the point of
view...

Lambda syntax etc. is a thing you should get used to... if not it's fine
don't use it...



Nor is it like we've finished the work of migrating onto Java 8.


Have we really decided to "migrate" to Java 8? We are changing code when
someone is working on it and willing to do that ... if not it's fine too...

It takes time to migrate that size of code base which is fine to do that
step by step and not as a big-bang part... because at that time can be
decided to use newer language features (if they make sense)..


>
 Just

this past week I replaced some code that hasn't been needed since Java
*1.4*.


That's very good...



Migrating to still newer Java versions is a distraction from far more
important work.


We are an open source project and anyone can work on anything a person
would like to work on...

And what is the important work ?

>
We haven't even moved all the plugins off Java 7 yet.

The burden of proof is on people who want to migrate to Java 17 to
show how that will improve the project. That burden has not been met.


So there is a need to prove that JDK17 is better for the project than
getting further and further behind...

From my point of view JDK11+ already proven that in itself... because
we gain performance (CDS or something like CraC etc), less memory..
which can improved by using JDK11+ language features etc. also making
things visible which only need to (JDK17: sealed classes without the
hard jump to the JPMS)...

BTW: Other projects already moved that path ... for example Maven Tycho
Project starting with 3.0.0 requires JDK17 as minimum Also
mentioning (several times) Spring Boot 3.0+ etc.


Kind regards
Karl Heinz Marbaise

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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Gary Gregory]

I'm having trouble reading this email, hang on, let me adjust the rabbit
ears on my black and white television... ah better now. I'm sorry what were
you saying? :-)

Gary

On Mon, Jun 5, 2023, 07:22 Elliotte Rusty Harold  wrote:

> On Sun, Jun 4, 2023 at 10:59 AM Delany  wrote:
> >
> > I think the point I'm making is no-one wants to write in an older version
> > of the language they started writing in. Its tedious. Anyone who started
> > writing java11 code is going to have a hard time accepting they need to
> > write in java8, just as a java8 will bulk at writing in java5. Of course
> > for the oldies it just feels nostalgic.
> >
>
> Strongly disagree. I personally would strongly prefer to stick to Java
> *7*, although these days I use mostly 8 and 11. IMHO Java 8 and Java
> 11 were significant downgrades for clarity of code and ease of use.
> While there were some nice improvements in libraries and VM in those
> versions, they are completely swamped by the truly awful lambda syntax
> and the useless pain of the Java Platform Module System.
>
> Nor is it like we've finished the work of migrating onto Java 8. Just
> this past week I replaced some code that hasn't been needed since Java
> *1.4*.
>
> Migrating to still newer Java versions is a distraction from far more
> important work. We haven't even moved all the plugins off Java 7 yet.
> The burden of proof is on people who want to migrate to Java 17 to
> show how that will improve the project. That burden has not been met.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Romain Manni-Bucau]

Hi


Le lun. 5 juin 2023 à 13:22, Elliotte Rusty Harold  a
écrit :

> On Sun, Jun 4, 2023 at 10:59 AM Delany  wrote:
> >
> > I think the point I'm making is no-one wants to write in an older version
> > of the language they started writing in. Its tedious. Anyone who started
> > writing java11 code is going to have a hard time accepting they need to
> > write in java8, just as a java8 will bulk at writing in java5. Of course
> > for the oldies it just feels nostalgic.
> >
>
> Strongly disagree. I personally would strongly prefer to stick to Java
> *7*, although these days I use mostly 8 and 11. IMHO Java 8 and Java
> 11 were significant downgrades for clarity of code and ease of use.
> While there were some nice improvements in libraries and VM in those
> versions, they are completely swamped by the truly awful lambda syntax
> and the useless pain of the Java Platform Module System.
>

This is a very interesting feedback cause we had the exact same on some
other ASF feedback in early lambdas days and today it is completely gone so
I guess it is just a habit thing.
So the point is either: do you fight against the scale of time or not and
if so is it ok for an asf project to reject potential contributors (because
it is what it means in practise, in particular when java 7 becomes hard to
get).

Note: I fully agree JPMS is useless but I also fully agree we don't need to
embrace it, it will not even be enabled until plexus-container does support
it, but it does not hurt, rest is more than fine and the new GC helps in a
software like maven.


>
> Nor is it like we've finished the work of migrating onto Java 8. Just
> this past week I replaced some code that hasn't been needed since Java
> *1.4*.
>

This is a good point, my personal view on that is we had way too much
abstraction for the actual codepath we use so I would be +1 to drop most of
the deps we rely on to include a core and limited set in maven project,
this will help upgrades instead of having to rely on 50+ projects - indeed
just my 2cts.


>
> Migrating to still newer Java versions is a distraction from far more
> important work. We haven't even moved all the plugins off Java 7 yet.
> The burden of proof is on people who want to migrate to Java 17 to
> show how that will improve the project. That burden has not been met.
>

Nobody requested to migrate the code base, IMHO the points were mainly:

1. enable to use a "not too old" base version to keep it easy to contribute
and leverage interesting new features (note: not always API)
2. use an up to date and evolutive version (java 8 doesnt get all backports
these days, even in maintained distro so you can end up accessing a http
maven repo which is not supported depending the JVM you use)
3. reduce the compatibility matrix right now since part of it is no more
useful for projects which will embrace mvn 4
4. ensure you can upgrade dependencies and do no have to stick to
deprecated versions (libs started to drop java 8 support already)

So yes Java 17 will not solve most of our issues but Java 8-21 support we
need to have already creates some in terms of validations, PR feedback, and
community message IMHO.
Since java 8 is covered by 3.9 I don't see why we would not take the
opportunity to move forward, syntax and details like that are a great
opportunity to learn for everybody more than a drawback from my past
experience and being able to use a reliable - cause we know it is supported
in the min version we use - http11 client with a better protocol support is
also important even if API didn't change much.


>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Elliotte Rusty Harold]

On Sun, Jun 4, 2023 at 10:59 AM Delany  wrote:
>
> I think the point I'm making is no-one wants to write in an older version
> of the language they started writing in. Its tedious. Anyone who started
> writing java11 code is going to have a hard time accepting they need to
> write in java8, just as a java8 will bulk at writing in java5. Of course
> for the oldies it just feels nostalgic.
>

Strongly disagree. I personally would strongly prefer to stick to Java
*7*, although these days I use mostly 8 and 11. IMHO Java 8 and Java
11 were significant downgrades for clarity of code and ease of use.
While there were some nice improvements in libraries and VM in those
versions, they are completely swamped by the truly awful lambda syntax
and the useless pain of the Java Platform Module System.

Nor is it like we've finished the work of migrating onto Java 8. Just
this past week I replaced some code that hasn't been needed since Java
*1.4*.

Migrating to still newer Java versions is a distraction from far more
important work. We haven't even moved all the plugins off Java 7 yet.
The burden of proof is on people who want to migrate to Java 17 to
show how that will improve the project. That burden has not been met.

-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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