You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Guillaume Nodet <gn...@apache.org> on 2023/05/31 08:29:51 UTC
Re: Question - JDK Minimum of future Apache Maven 4.0.0
I'd like to resume this discussion about switching master to require JDK 17.
These past days, I've been working on improving the usage of toolchains
(first inside maven, but now completely in the maven-toolchains-plugin)
with [1]. If we want to go further, we could simplify the selection by
modifying the POM somehow to add a specific section, but I suspect most
people will just use the release flag on the compiler to target bytecode.
The only downside I see, beyond the additional configuration (though the
goal is that users don't really have to generate/maintain the toolchains)
is that the selection of the toolchain is done during the build, so that
JDK profile based activation can not be used. Note that the use of
environment variables is also another way to work around, for example in
github [2].
I think with those improvements, requiring JDK 17 for master should be
doable. Any concerns of suggestions ?
Cheers,
Guillaume
[1] https://github.com/apache/maven-toolchains-plugin/pull/14
[2]
https://github.com/B3Partners/kadaster-gds2/blob/b0cd5c392bc1f48dec11c83c828254a868264467/.github/ubuntu-toolchains.xml
Le mar. 19 juil. 2022 à 18:25, Karl Heinz Marbaise <kh...@gmx.de> a
écrit :
> Hi to all,
>
> what do you think about using JDK17 as minimum requirement for running
> the future Apache Maven 4.0.0 ?
>
> Kind regards
> Karl Heinz Marbaise
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Hervé Boutemy <he...@free.fr>.
requirements history column has just been added to dist tool report:
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html
on 52 plugins we maintain, 3 have published prerequisites history to help users know what version to use when latest has too modern prerequisites
for people interested in helping us, you can see how to provide us a PR by looking at issues linked from https://issues.apache.org/jira/browse/MPLUGIN-400
PLEASE HELP US
Regards,
Hervé
Le mardi 6 juin 2023, 09:30:39 CEST Romain Manni-Bucau a écrit :
> @Hervé: was not really my point, more than forcing the maven version as
> plugins do also forces the java version so as soon as we decide for maven
> plugins are good. They can be compiled with java 8 and run on maven 3+4
> while API is stable or just maven 4 if not. For external plugins some are
> already compiled with java 11 only so will not run on java 8 builds even if
> 3.9 supports it so think this part is really good technically - agree with
> you in terms of doc we can be better but requires a lot of time and effort
> as you mentionned.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau>
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> Le mar. 6 juin 2023 à 09:11, Hervé Boutemy <he...@free.fr> a écrit :
> > you're right that we're currently talking about core, not plugins
> >
> > but this question will inevitably extend from core to plugins, and there
> > are
> > much more plugin developers than core developers
> >
> > then I think that getting a large view is useful
> >
> > and honestly, now that I had the opportunity to do the summary and find
> > dist-
> > tool + DOCCK-38 improvements, I know how to continue to prepare the future
> > of
> > this JDK prerequisite question on plugins
> >
> > I'll just need that people interested in upgrading JDK prerequisite help
> > doing
> > the hard documentation work required to make that move in a smooth way =
> > avoid
> > the "I only care about users who can use latest JDK" effect
> >
> > Regards,
> >
> > Hervé
> >
> > Le mardi 6 juin 2023, 08:29:16 CEST Romain Manni-Bucau a écrit :
> > > Do we really care about plugins Hervé? They are compatible with some
> >
> > maven
> >
> > > versions so cover the underlying prerequisites, no?
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> >
> > https://github.com/rmannibucau>
> >
> > > | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > >
> > > <
> >
> > https://www.packtpub.com/application-development/java-ee-8-high-performanc
> > e
> >
> > > Le mar. 6 juin 2023 à 08:27, Hervé Boutemy <he...@free.fr> 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/jo
> >
> > > > b/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.ht
> >
> > > > ml#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-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Hervé: was not really my point, more than forcing the maven version as
plugins do also forces the java version so as soon as we decide for maven
plugins are good. They can be compiled with java 8 and run on maven 3+4
while API is stable or just maven 4 if not. For external plugins some are
already compiled with java 11 only so will not run on java 8 builds even if
3.9 supports it so think this part is really good technically - agree with
you in terms of doc we can be better but requires a lot of time and effort
as you mentionned.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 6 juin 2023 à 09:11, Hervé Boutemy <he...@free.fr> a écrit :
> you're right that we're currently talking about core, not plugins
>
> but this question will inevitably extend from core to plugins, and there
> are
> much more plugin developers than core developers
>
> then I think that getting a large view is useful
>
> and honestly, now that I had the opportunity to do the summary and find
> dist-
> tool + DOCCK-38 improvements, I know how to continue to prepare the future
> of
> this JDK prerequisite question on plugins
>
> I'll just need that people interested in upgrading JDK prerequisite help
> doing
> the hard documentation work required to make that move in a smooth way =
> avoid
> the "I only care about users who can use latest JDK" effect
>
> Regards,
>
> Hervé
>
> Le mardi 6 juin 2023, 08:29:16 CEST Romain Manni-Bucau a écrit :
> > Do we really care about plugins Hervé? They are compatible with some
> maven
> > versions so cover the underlying prerequisites, no?
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau>
> > | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > Le mar. 6 juin 2023 à 08:27, Hervé Boutemy <he...@free.fr> 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/jo
> > > b/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.ht
> > > ml#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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Hervé Boutemy <he...@free.fr>.
you're right that we're currently talking about core, not plugins
but this question will inevitably extend from core to plugins, and there are
much more plugin developers than core developers
then I think that getting a large view is useful
and honestly, now that I had the opportunity to do the summary and find dist-
tool + DOCCK-38 improvements, I know how to continue to prepare the future of
this JDK prerequisite question on plugins
I'll just need that people interested in upgrading JDK prerequisite help doing
the hard documentation work required to make that move in a smooth way = avoid
the "I only care about users who can use latest JDK" effect
Regards,
Hervé
Le mardi 6 juin 2023, 08:29:16 CEST Romain Manni-Bucau a écrit :
> Do we really care about plugins Hervé? They are compatible with some maven
> versions so cover the underlying prerequisites, no?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau>
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> Le mar. 6 juin 2023 à 08:27, Hervé Boutemy <he...@free.fr> 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/jo
> > b/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.ht
> > ml#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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Do we really care about plugins Hervé? They are compatible with some maven
versions so cover the underlying prerequisites, no?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 6 juin 2023 à 08:27, Hervé Boutemy <he...@free.fr> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Hervé Boutemy <he...@free.fr>.
> > 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le sam. 3 juin 2023 à 11:46, Hervé Boutemy <he...@free.fr> a écrit :
> +1
>
> I really don't what benefit we get from going to Java 17
>
> 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
>
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.
>
> 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
> > <da...@gmail.com> 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 <kh...@gmx.de>
> 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 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...
> > >
> > >
> > > 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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Benjamin Marwell <bm...@apache.org>.
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, <hu...@yahoo.com.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 <
> khmarbaise@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
> >> <da...@gmail.com> 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 <kh...@gmx.de>
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Hervé Boutemy <he...@free.fr>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Gary Gregory <ga...@gmail.com>.
Note that Apache Commons Compress supports pack200.
Gary
On Tue, Jun 6, 2023, 09:52 Delany <de...@gmail.com> wrote:
> Hi Jeremy. We're talking about the possibility of a drop-in replacement.
> But what you're suggesting requires alterations to the code, and having
> struggled with JAXB and its many unofficial plugins I can vouch for the
> difficulty in doing that.
> Perhaps it would have been easier if OpenJDK took responsibility for
> providing the packages and the plugin and setup a nice document somewhere
> to explain, but that's not what I found.
>
> Anyway, today I'm sitting with a version of izpack that depends on the
> Pack200 compression class removed from JDK17. Ok, so just add
> https://github.com/pack200/pack200 right? Oh, but izpack expects
> java.util.jar.Pack200 not io.pack200.Pack200. Should I update izpack? Yeah,
> and I've tried twice already, and will try again. Also tried rebuilding the
> izpack version from source, but it doesn't match with what was released.
> Next I'll try shading, etc, etc.
> Suffice to say there are issues.
> Delany
>
> On Tue, 6 Jun 2023 at 14:34, Jeremy Landis <je...@hotmail.com>
> wrote:
>
> > Delany,
> >
> > "You need toolchains if your code needs the JAXB classes removed in
> JDK11.
> > Delany"
> >
> > That isn't accurate. You do not need toolchains for jaxb. You need to
> > add the correct libraries. I can understand that statement from a dev
> that
> > doesn't quite understand the history of EE inside java but its 100% easy
> to
> > do without adding toolchains.
> >
> > Jeremy
> >
> > -----Original Message-----
> > From: Delany <de...@gmail.com>
> > Sent: Tuesday, June 6, 2023 1:33 AM
> > To: Maven Developers List <de...@maven.apache.org>
> > Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0
> >
> > You need toolchains if your code needs the JAXB classes removed in JDK11.
> > Delany
> >
> >
> > On Tue, 6 Jun 2023 at 01:54, Henning Schmiedehausen <
> > henning@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 <de...@gmail.com>
> > 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
> > > > <hu...@yahoo.com.invalid> 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 <
> > > > > tamas@cservenak.net> wrote:
> > > > >
> > > > > Seems people missed this (somewhat related) thread:
> > > > >
> > > > > https://l/
> > > > > ists.apache.org%2Fthread%2Fkpsrb28nst84vtohwngy3140g1r0ydd4&data=0
> > > > > 5%7C01%7C%7Cfb40fc3fc64e4a82761708db664fa4cf%7C84df9e7fe9f640afb43
> > > > > 5aaaaaaaaaaaa%7C1%7C0%7C638216264486404797%7CUnknown%7CTWFpbGZsb3d
> > > > > 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > > > > D%7C3000%7C%7C%7C&sdata=E1edIICCiPIKLDyysEEehIxEgA1zL09VYb53duEoB8
> > > > > 4%3D&reserved=0
> > > > >
> > > > > Thanks
> > > > >
> > > > >
> > > > > On Mon, Jun 5, 2023, 20:40 Hunter C Payne
> > > > > <hunterpayne2001@yahoo.com .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 < khmarbaise@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 <da...@gmail.com> 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 <
> > > khmarbaise@gmx.de
> > > > >
> > > > > > 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.o/
> > > racle.com%2Fjava%2Ftechnologies%2Fjava-se-support-roadmap.html&data=05
> > > %7C01%7C%7Cfb40fc3fc64e4a82761708db664fa4cf%7C84df9e7fe9f640afb435aaaa
> > > aaaaaaaa%7C1%7C0%7C638216264486404797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> > > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
> > > C%7C&sdata=s92AGcmmP%2BxmWuUWMdvqOEOPhZQARF6jT4gSsMY8lRI%3D&reserved=0
> > > > > >
> > > > > >
> > > > > > ----------------------------------------------------------------
> > > > > > ----- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Delany <de...@gmail.com>.
Hi Jeremy. We're talking about the possibility of a drop-in replacement.
But what you're suggesting requires alterations to the code, and having
struggled with JAXB and its many unofficial plugins I can vouch for the
difficulty in doing that.
Perhaps it would have been easier if OpenJDK took responsibility for
providing the packages and the plugin and setup a nice document somewhere
to explain, but that's not what I found.
Anyway, today I'm sitting with a version of izpack that depends on the
Pack200 compression class removed from JDK17. Ok, so just add
https://github.com/pack200/pack200 right? Oh, but izpack expects
java.util.jar.Pack200 not io.pack200.Pack200. Should I update izpack? Yeah,
and I've tried twice already, and will try again. Also tried rebuilding the
izpack version from source, but it doesn't match with what was released.
Next I'll try shading, etc, etc.
Suffice to say there are issues.
Delany
On Tue, 6 Jun 2023 at 14:34, Jeremy Landis <je...@hotmail.com> wrote:
> Delany,
>
> "You need toolchains if your code needs the JAXB classes removed in JDK11.
> Delany"
>
> That isn't accurate. You do not need toolchains for jaxb. You need to
> add the correct libraries. I can understand that statement from a dev that
> doesn't quite understand the history of EE inside java but its 100% easy to
> do without adding toolchains.
>
> Jeremy
>
> -----Original Message-----
> From: Delany <de...@gmail.com>
> Sent: Tuesday, June 6, 2023 1:33 AM
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0
>
> You need toolchains if your code needs the JAXB classes removed in JDK11.
> Delany
>
>
> On Tue, 6 Jun 2023 at 01:54, Henning Schmiedehausen <
> henning@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 <de...@gmail.com>
> 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
> > > <hu...@yahoo.com.invalid> 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 <
> > > > tamas@cservenak.net> wrote:
> > > >
> > > > Seems people missed this (somewhat related) thread:
> > > >
> > > > https://l/
> > > > ists.apache.org%2Fthread%2Fkpsrb28nst84vtohwngy3140g1r0ydd4&data=0
> > > > 5%7C01%7C%7Cfb40fc3fc64e4a82761708db664fa4cf%7C84df9e7fe9f640afb43
> > > > 5aaaaaaaaaaaa%7C1%7C0%7C638216264486404797%7CUnknown%7CTWFpbGZsb3d
> > > > 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > > > D%7C3000%7C%7C%7C&sdata=E1edIICCiPIKLDyysEEehIxEgA1zL09VYb53duEoB8
> > > > 4%3D&reserved=0
> > > >
> > > > Thanks
> > > >
> > > >
> > > > On Mon, Jun 5, 2023, 20:40 Hunter C Payne
> > > > <hunterpayne2001@yahoo.com .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 < khmarbaise@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 <da...@gmail.com> 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 <
> > khmarbaise@gmx.de
> > > >
> > > > > 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.o/
> > racle.com%2Fjava%2Ftechnologies%2Fjava-se-support-roadmap.html&data=05
> > %7C01%7C%7Cfb40fc3fc64e4a82761708db664fa4cf%7C84df9e7fe9f640afb435aaaa
> > aaaaaaaa%7C1%7C0%7C638216264486404797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
> > C%7C&sdata=s92AGcmmP%2BxmWuUWMdvqOEOPhZQARF6jT4gSsMY8lRI%3D&reserved=0
> > > > >
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > ----- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
RE: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Jeremy Landis <je...@hotmail.com>.
Delany,
"You need toolchains if your code needs the JAXB classes removed in JDK11.
Delany"
That isn't accurate. You do not need toolchains for jaxb. You need to add the correct libraries. I can understand that statement from a dev that doesn't quite understand the history of EE inside java but its 100% easy to do without adding toolchains.
Jeremy
-----Original Message-----
From: Delany <de...@gmail.com>
Sent: Tuesday, June 6, 2023 1:33 AM
To: Maven Developers List <de...@maven.apache.org>
Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0
You need toolchains if your code needs the JAXB classes removed in JDK11.
Delany
On Tue, 6 Jun 2023 at 01:54, Henning Schmiedehausen < henning@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 <de...@gmail.com> 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
> > <hu...@yahoo.com.invalid> 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 <
> > > tamas@cservenak.net> wrote:
> > >
> > > Seems people missed this (somewhat related) thread:
> > >
> > > https://l/
> > > ists.apache.org%2Fthread%2Fkpsrb28nst84vtohwngy3140g1r0ydd4&data=0
> > > 5%7C01%7C%7Cfb40fc3fc64e4a82761708db664fa4cf%7C84df9e7fe9f640afb43
> > > 5aaaaaaaaaaaa%7C1%7C0%7C638216264486404797%7CUnknown%7CTWFpbGZsb3d
> > > 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > > D%7C3000%7C%7C%7C&sdata=E1edIICCiPIKLDyysEEehIxEgA1zL09VYb53duEoB8
> > > 4%3D&reserved=0
> > >
> > > Thanks
> > >
> > >
> > > On Mon, Jun 5, 2023, 20:40 Hunter C Payne
> > > <hunterpayne2001@yahoo.com .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 < khmarbaise@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 <da...@gmail.com> 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 <
> khmarbaise@gmx.de
> > >
> > > > 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.o/
> racle.com%2Fjava%2Ftechnologies%2Fjava-se-support-roadmap.html&data=05
> %7C01%7C%7Cfb40fc3fc64e4a82761708db664fa4cf%7C84df9e7fe9f640afb435aaaa
> aaaaaaaa%7C1%7C0%7C638216264486404797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
> C%7C&sdata=s92AGcmmP%2BxmWuUWMdvqOEOPhZQARF6jT4gSsMY8lRI%3D&reserved=0
> > > >
> > > >
> > > > ----------------------------------------------------------------
> > > > ----- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Delany <de...@gmail.com>.
You need toolchains if your code needs the JAXB classes removed in JDK11.
Delany
On Tue, 6 Jun 2023 at 01:54, Henning Schmiedehausen <
henning@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 <de...@gmail.com> 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
> > <hu...@yahoo.com.invalid> 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 <
> > > tamas@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 <hunterpayne2001@yahoo.com
> > > .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 <
> > > > khmarbaise@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
> > > > >> <da...@gmail.com> 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 <
> khmarbaise@gmx.de
> > >
> > > > 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-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
RE: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Jeremy Landis <je...@hotmail.com>.
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 <he...@schmiedehausen.org>
Sent: Monday, June 5, 2023 7:54 PM
To: Maven Developers List <de...@maven.apache.org>
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 <de...@gmail.com> 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
> <hu...@yahoo.com.invalid> 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 <
> > tamas@cservenak.net> wrote:
> >
> > Seems people missed this (somewhat related) thread:
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
> > ts.apache.org%2Fthread%2Fkpsrb28nst84vtohwngy3140g1r0ydd4&data=05%7C
> > 01%7C%7C230889510b4d49b5f9e708db6620422b%7C84df9e7fe9f640afb435aaaaa
> > aaaaaaa%7C1%7C0%7C638216060954040394%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> > C%7C%7C&sdata=m0Xv1jDQIJ5tqgovvXOzJ0k8mS06%2BcjO6M%2F3NyiS7wY%3D&res
> > erved=0
> >
> > Thanks
> >
> >
> > On Mon, Jun 5, 2023, 20:40 Hunter C Payne <hunterpayne2001@yahoo.com
> > .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
> > > < khmarbaise@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
> > > >> <da...@gmail.com> 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
> > > >>> <khmarbaise@gmx.de
> >
> > > 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw
> > > ww.oracle.com%2Fjava%2Ftechnologies%2Fjava-se-support-roadmap.html
> > > &data=05%7C01%7C%7C230889510b4d49b5f9e708db6620422b%7C84df9e7fe9f6
> > > 40afb435aaaaaaaaaaaa%7C1%7C0%7C638216060954040394%7CUnknown%7CTWFp
> > > bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> > > I6Mn0%3D%7C3000%7C%7C%7C&sdata=hclJ3PGTE471LlgzWfO%2BOyOvl6tphOeqR
> > > bzMPUd57q4%3D&reserved=0
> > >
> > >
> > > ------------------------------------------------------------------
> > > --- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > > additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Henning Schmiedehausen <he...@schmiedehausen.org>.
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 <de...@gmail.com> 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
> <hu...@yahoo.com.invalid> 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 <
> > tamas@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 <hunterpayne2001@yahoo.com
> > .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 <
> > > khmarbaise@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
> > > >> <da...@gmail.com> 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 <khmarbaise@gmx.de
> >
> > > 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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Manfred Moser <ma...@simpligility.ca>.
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 <de...@gmail.com> 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
> <hu...@yahoo.com.invalid> 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 <
>> tamas@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 <hunterpayne2001@yahoo.com
>> .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 <
>>> khmarbaise@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
>>>>> <da...@gmail.com> 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 <kh...@gmx.de>
>>> 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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Hunter C Payne <hu...@yahoo.com.INVALID>.
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 <de...@gmail.com> 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
<hu...@yahoo.com.invalid> 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 <
> tamas@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 <hunterpayne2001@yahoo.com
> .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 <
> > khmarbaise@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
> > >> <da...@gmail.com> 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 <kh...@gmx.de>
> > 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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Delany <de...@gmail.com>.
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
<hu...@yahoo.com.invalid> 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 <
> tamas@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 <hunterpayne2001@yahoo.com
> .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 <
> > khmarbaise@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
> > >> <da...@gmail.com> 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 <kh...@gmx.de>
> > 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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Hunter C Payne <hu...@yahoo.com.INVALID>.
So one dev said he specifically was dealing with an issue that someone else said wouldn't happen. That's a binary decision which someone can't control, it is just true or not true (i'm assuming that the person who posted knew what they were talking about). That isn't the same as a matter of taste which doesn't materially impact someones ability to work with the source base. Functionality trumps taste in my opinion. That's why I treated those two matters differently.
As for Java lambdas, they don't really save you any keystrokes compared to a Java for comprehension so I just don't see the point. Once you have real functions as first class objects with all the typing, currying and composition that comes with a real FP language, then you can do a lot more with less. In the case of Java, you get so little for so much upgrade headache. In the case of other FP languages, you get a huge number of new design patterns that fit a lot of use cases better than you can do with pure-OO. So its a matter of degree to me. You would really have to spend sometime coding in one of those languages to understand exactly what I mean but I hope this illustrates why some of us really don't care about upgrading JVM versions. The language and its features that you use doesn't necessarily depend on later JVMs anymore.
All that being said, I have said my peace and I don't think continuing to reply will help anything. I appreciate you listening.
Hunter
On Monday, June 5, 2023 at 11:53:28 PM PDT, Benjamin Marwell <bm...@apache.org> wrote:
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
<hu...@yahoo.com.invalid>:
> 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 <
> tamas@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 <hunterpayne2001@yahoo.com
> .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 <
> > khmarbaise@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
> > >> <da...@gmail.com> 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 <kh...@gmx.de>
> > 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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Benjamin Marwell <bm...@apache.org>.
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
<hu...@yahoo.com.invalid>:
> 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 <
> tamas@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 <hunterpayne2001@yahoo.com
> .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 <
> > khmarbaise@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
> > >> <da...@gmail.com> 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 <kh...@gmx.de>
> > 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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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
<hu...@yahoo.com.invalid> 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 <
> tamas@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 <hunterpayne2001@yahoo.com
> .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 <
> > khmarbaise@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
> > >> <da...@gmail.com> 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 <kh...@gmx.de>
> > 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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Hunter C Payne <hu...@yahoo.com.INVALID>.
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 <hu...@yahoo.com.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 <
> khmarbaise@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
> >> <da...@gmail.com> 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 <kh...@gmx.de>
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Tamás Cservenák <ta...@cservenak.net>.
Seems people missed this (somewhat related) thread:
https://lists.apache.org/thread/kpsrb28nst84vtohwngy3140g1r0ydd4
Thanks
On Mon, Jun 5, 2023, 20:40 Hunter C Payne <hu...@yahoo.com.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 <
> khmarbaise@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
> >> <da...@gmail.com> 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 <kh...@gmx.de>
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Hunter C Payne <hu...@yahoo.com.INVALID>.
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 <kh...@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
>> <da...@gmail.com> 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 <kh...@gmx.de> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
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
>> <da...@gmail.com> 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 <kh...@gmx.de> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
On 05.06.23 13:21, Elliotte Rusty Harold wrote:
> On Sun, Jun 4, 2023 at 10:59 AM Delany <de...@gmail.com> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Gary Gregory <ga...@gmail.com>.
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 <el...@ibiblio.org> wrote:
> On Sun, Jun 4, 2023 at 10:59 AM Delany <de...@gmail.com> 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
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
On 05.06.23 13:55, Romain Manni-Bucau wrote:
> Hi
>
>
> Le lun. 5 juin 2023 à 13:22, Elliotte Rusty Harold <el...@ibiblio.org> a
> écrit :
>
>> On Sun, Jun 4, 2023 at 10:59 AM Delany <de...@gmail.com> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
Le lun. 5 juin 2023 à 13:22, Elliotte Rusty Harold <el...@ibiblio.org> a
écrit :
> On Sun, Jun 4, 2023 at 10:59 AM Delany <de...@gmail.com> 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
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Sun, Jun 4, 2023 at 10:59 AM Delany <de...@gmail.com> 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
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Delany <de...@gmail.com>.
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.
You claim jdk8 is more stable than jdk17, but I would argue the reverse.
Problematic classes are continually being deprecated and removed, and
better syntax makes code more readable, whatever the language. Improvements
in the latest JEPs come out of an ecosystem vastly more organised (see
https://openjdk.org/jeps/296).
Not that stability is really the big issue for a build tool, but
performance improvements also contribute to stability. What's the latest in
JDK20? JEP 250 introduces compact object headers, reducing memory
requirements by up to 20%. I'd love it if my build took 20% less memory
(especially mvnd).
Using the latest LTS is a signal of intent. Its a way of saying "this
project is active, the maintainers are engaged, we are keeping up-to-date
and we're able to balance the demands of legacy, and if you are starting a
new project you should choose Maven"
Delany
On Sat, 3 Jun 2023 at 23:05, Hunter C Payne
<hu...@yahoo.com.invalid> wrote:
> Folks who think like that have been using Scala or Kotlin for at least 5
> years by now. If you are still writing Java, it isn't for new features.
> Hunter
>
> PS If you want to use "new features" use Scala or Kotlin. If you want
> stability, use Java8. Using Java17 is a middle ground that gets nobody
> anything they way. That's why are having a hard time naming a new feature
> you want/need.
> On Saturday, June 3, 2023 at 06:16:11 AM PDT, Delany <
> delany.middleton@gmail.com> wrote:
>
> There may not be a killer feature, but the cumulative changes are
> appreciated, especially when you're used to them. Having closed the door on
> whatever came before List.of its like a miniature thorn in my side every
> time its not available.
>
> What motivated the change to JDK8? Were there any negative repercussions
> from that? All I'm reading is guesses about the impact. Is there an actual
> example of when the required JDK was raised and a tool was dropped or lost
> out to another because of it?
>
> Anyway, if there's nothing substantial to gain from the change from 8 to
> 17, then I don't see what is so disruptive about requiring it. Given that
> there's no single killer feature, and no obviously drawback, the argument
> should probably center on principles and even on determining a rule for
> Maven to follow (this isn't the first time this chestnut of an argument has
> come up).
>
> The vendor(s) and the source of the language are two different entities, so
> who is Maven beholden to? Since vendor interests are monetized in a way
> that Maven is not its more reasonable to expect Maven to follow Java's lead
> (rather than a vendor's support lifecycle).
>
> Despite the core principle of backward compatibility in the Java ecosystem,
> not adopting the latest LTS for a major Maven release is clearly going
> against Java's efforts to promote more regular update cycles and all the
> many automation and security benefits that comes with that. When
> people/businesses push back against updates I immediately think they must
> have some sub-standard DevOps workflow. Given that DevOps/JS cynics will
> probably gravitate to Java ecosystem this is unsurprising. Java is full of
> conservative sentiment.
>
> On the other hand there's the integrity of the language. Other languages
> make a hard fork, while Java risks being multiple languages - fun for those
> with decades of experience, but not encouraging to new faces who must
> choose between 5 different ways to solve a problem. One of my colleagues
> regularly portrays tech envy in sexual terms. Well guess what, we're human
> not robots and yes its "sexier" and more "satisfying" to work with JDK17.
> Ignoring that fact is itself irrational.
>
> Delany
>
> On Sat, 3 Jun 2023 at 11:46, Hervé Boutemy <he...@free.fr> wrote:
>
> > +1
> >
> > I really don't what benefit we get from going to Java 17
> >
> > 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
> > > <da...@gmail.com> 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 <kh...@gmx.de>
> > 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 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...
> > > >
> > > >
> > > > 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-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Hunter C Payne <hu...@yahoo.com.INVALID>.
Folks who think like that have been using Scala or Kotlin for at least 5 years by now. If you are still writing Java, it isn't for new features.
Hunter
PS If you want to use "new features" use Scala or Kotlin. If you want stability, use Java8. Using Java17 is a middle ground that gets nobody anything they way. That's why are having a hard time naming a new feature you want/need.
On Saturday, June 3, 2023 at 06:16:11 AM PDT, Delany <de...@gmail.com> wrote:
There may not be a killer feature, but the cumulative changes are
appreciated, especially when you're used to them. Having closed the door on
whatever came before List.of its like a miniature thorn in my side every
time its not available.
What motivated the change to JDK8? Were there any negative repercussions
from that? All I'm reading is guesses about the impact. Is there an actual
example of when the required JDK was raised and a tool was dropped or lost
out to another because of it?
Anyway, if there's nothing substantial to gain from the change from 8 to
17, then I don't see what is so disruptive about requiring it. Given that
there's no single killer feature, and no obviously drawback, the argument
should probably center on principles and even on determining a rule for
Maven to follow (this isn't the first time this chestnut of an argument has
come up).
The vendor(s) and the source of the language are two different entities, so
who is Maven beholden to? Since vendor interests are monetized in a way
that Maven is not its more reasonable to expect Maven to follow Java's lead
(rather than a vendor's support lifecycle).
Despite the core principle of backward compatibility in the Java ecosystem,
not adopting the latest LTS for a major Maven release is clearly going
against Java's efforts to promote more regular update cycles and all the
many automation and security benefits that comes with that. When
people/businesses push back against updates I immediately think they must
have some sub-standard DevOps workflow. Given that DevOps/JS cynics will
probably gravitate to Java ecosystem this is unsurprising. Java is full of
conservative sentiment.
On the other hand there's the integrity of the language. Other languages
make a hard fork, while Java risks being multiple languages - fun for those
with decades of experience, but not encouraging to new faces who must
choose between 5 different ways to solve a problem. One of my colleagues
regularly portrays tech envy in sexual terms. Well guess what, we're human
not robots and yes its "sexier" and more "satisfying" to work with JDK17.
Ignoring that fact is itself irrational.
Delany
On Sat, 3 Jun 2023 at 11:46, Hervé Boutemy <he...@free.fr> wrote:
> +1
>
> I really don't what benefit we get from going to Java 17
>
> 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
> > <da...@gmail.com> 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 <kh...@gmx.de>
> 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 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...
> > >
> > >
> > > 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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Delany <de...@gmail.com>.
There may not be a killer feature, but the cumulative changes are
appreciated, especially when you're used to them. Having closed the door on
whatever came before List.of its like a miniature thorn in my side every
time its not available.
What motivated the change to JDK8? Were there any negative repercussions
from that? All I'm reading is guesses about the impact. Is there an actual
example of when the required JDK was raised and a tool was dropped or lost
out to another because of it?
Anyway, if there's nothing substantial to gain from the change from 8 to
17, then I don't see what is so disruptive about requiring it. Given that
there's no single killer feature, and no obviously drawback, the argument
should probably center on principles and even on determining a rule for
Maven to follow (this isn't the first time this chestnut of an argument has
come up).
The vendor(s) and the source of the language are two different entities, so
who is Maven beholden to? Since vendor interests are monetized in a way
that Maven is not its more reasonable to expect Maven to follow Java's lead
(rather than a vendor's support lifecycle).
Despite the core principle of backward compatibility in the Java ecosystem,
not adopting the latest LTS for a major Maven release is clearly going
against Java's efforts to promote more regular update cycles and all the
many automation and security benefits that comes with that. When
people/businesses push back against updates I immediately think they must
have some sub-standard DevOps workflow. Given that DevOps/JS cynics will
probably gravitate to Java ecosystem this is unsurprising. Java is full of
conservative sentiment.
On the other hand there's the integrity of the language. Other languages
make a hard fork, while Java risks being multiple languages - fun for those
with decades of experience, but not encouraging to new faces who must
choose between 5 different ways to solve a problem. One of my colleagues
regularly portrays tech envy in sexual terms. Well guess what, we're human
not robots and yes its "sexier" and more "satisfying" to work with JDK17.
Ignoring that fact is itself irrational.
Delany
On Sat, 3 Jun 2023 at 11:46, Hervé Boutemy <he...@free.fr> wrote:
> +1
>
> I really don't what benefit we get from going to Java 17
>
> 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
> > <da...@gmail.com> 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 <kh...@gmx.de>
> 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 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...
> > >
> > >
> > > 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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Hervé Boutemy <he...@free.fr>.
+1
I really don't what benefit we get from going to Java 17
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
> <da...@gmail.com> 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 <kh...@gmx.de> 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 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...
> >
> >
> > 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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Olivier Lamy <ol...@apache.org>.
Perso I do not have any issue using 17.
By curiosity, I wonder what sort of 17 (or 9+) features we really want/need?
Pattern matching for switch?
record (so we can get rid of Modello but record will be not compatible
with previous standard beans).
On Fri, 2 Jun 2023 at 09:17, David Jencks <da...@gmail.com> 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 <kh...@gmx.de> 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 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...
> >
> >
> > 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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Hunter C Payne <hu...@yahoo.com.INVALID>.
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 <da...@gmail.com> 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 <kh...@gmx.de> 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 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...
>
>
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by David Jencks <da...@gmail.com>.
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 <kh...@gmx.de> 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 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...
>
>
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
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 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...
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Michael Osipov <mi...@apache.org>.
On 2023/06/01 06:28:18 Guillaume Nodet wrote:
> JDK 8 active support ended 15 months ago, so I think that's definitely fine
> to require a newer version. I don't think we should wait and support JDK 8
> until 2030 and then switch from JDK 8 to what, JDK 24 ? That's really not a
> good plan imho and that's what maintenance branches are used for. The JDK
> release cycle has changed and the whole java ecosystem is adapting to this
> faster release cycle.
So what? All we need to make sure that Maven runs on it, not requires it.
> So I think we should:
> * maintain a 3.x branch with JDK 8 and provide bug fixes
> * set up 4.x branches to require at least the oldest actively supported
> JDK at the time the first micro version is released (so that would be 17 by
> the time 4.0.0 comes out) and 21 by the end of 2026 (maybe 4.2.0 ?)
> JDK 17 can still target JDK 8 for compilation, so that should cover most
> needs.
We do already actively support newer JDKs.
> If needed, we could even automatically download a JRE 17 at first usage
> (using [1] but we'd have to check for upgrades, etc...) and continue the
> work for discovering toolchains [2], etc... to help users. We could also
> make JDK toolchains much easier to use by modifying the project model and
> adding specific support for it. That would allow selecting the toolchains
> very early in the build, thus allowing toolchain based jdk activation, and
> would make the configuration much simpler. Though I have a feeling that
> all this is not really necessary...
This sounds like a total waste of time and yet another NIH syndrome. Someone else has invented package managers aleady.
I am still against, we gain very little compared to the junk we still have in the basement. It requires a massive cleanup: JIRA has > 2000 open issues and rising. Cases, important ones not resolved for years. I don't see a reason to do something new if the foundation isn't clean.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Martijn Verburg <ma...@gmail.com>.
As an FYI - https://adoptium.net/en-GB/support/ can give a guide as to the
thinking around OSS support for Java 8 (Nov 2026 is the minimum timeline,
it may extend).
Cheers,
Martijn
On Thu, 1 Jun 2023 at 23:36, Elliotte Rusty Harold <el...@ibiblio.org>
wrote:
> On Thu, Jun 1, 2023 at 10:47 AM Romain Manni-Bucau
> <rm...@gmail.com> wrote:
>
> > Yep but this is also something an OSS product don't want to rely on (ie
> > particular vendor specificities which can change), so we should probably
> > stick to the global dates and align on these ones consistently.
> >
>
> Yes, but that principle implies the opposite. We should not rely on
> the particular vendor specificities of Oracle's commercial release,
> including when they decide to stop supporting JDK 8.
>
> The open source release of JDK 8 is available and will continue to be
> so for years. It is supported and maintained by multiple companies,
> organizations, and individuals, not just Oracle. It is an active
> project with quarterly releases and many active committers:
>
> https://wiki.openjdk.org/display/jdk8u/Main
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Thu, Jun 1, 2023 at 10:47 AM Romain Manni-Bucau
<rm...@gmail.com> wrote:
> Yep but this is also something an OSS product don't want to rely on (ie
> particular vendor specificities which can change), so we should probably
> stick to the global dates and align on these ones consistently.
>
Yes, but that principle implies the opposite. We should not rely on
the particular vendor specificities of Oracle's commercial release,
including when they decide to stop supporting JDK 8.
The open source release of JDK 8 is available and will continue to be
so for years. It is supported and maintained by multiple companies,
organizations, and individuals, not just Oracle. It is an active
project with quarterly releases and many active committers:
https://wiki.openjdk.org/display/jdk8u/Main
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 1 juin 2023 à 12:39, Elliotte Rusty Harold <el...@ibiblio.org> a
écrit :
> On Thu, Jun 1, 2023 at 6:28 AM Guillaume Nodet <gn...@apache.org> wrote:
> >
> > JDK 8 active support ended 15 months ago, so I think that's definitely
> fine
> > to require a newer version.
>
> This is a common misconception. JDK 8 is fully supported by multiple
> companies including Azul. It also seems supported by Oracle:
>
> "For Java SE 8, Oracle will continue to release new updates on its
> public websites for personal/individual users or for non-production,
> development/testing purposes. However, commercial/business use of
> those public releases in production is restricted and requires a
> commercial license."
>
Yep but this is also something an OSS product don't want to rely on (ie
particular vendor specificities which can change), so we should probably
stick to the global dates and align on these ones consistently.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Tamás Cservenák <ta...@cservenak.net>.
On Thu, Jun 1, 2023 at 12:51 PM Michael Osipov <mi...@apache.org> wrote:
> Neither nor. Many use OpenJDK in production even w/o any commercial plans
> because they are happy with that. So there is also C.
>
And that is fine, if they are happy with it, they should be happy with
other "same age" tech, so they probably don't want to migrate to Maven 4
anyway....
But seemingly we are again back at Delany's question: what do customer
(app/lib runtime) requirements have to do with the build tool's required
JDK?
T
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Michael Osipov <mi...@apache.org>.
Neither nor. Many use OpenJDK in production even w/o any commercial plans because they are happy with that. So there is also C.
On 2023/06/01 10:48:28 Tamás Cservenák wrote:
> This is silly.
> So we need to support Java 8 in the future (not yet happened) Maven 4
> releases due:
>
> A) hobbyist (personal/individual users or for non-production,
> development/testing purposes)
>
> OR
>
> B) commercial entities paying for licenses (commercial/business use of
> those public releases in production is restricted and requires a commercial
> license)
>
> Which one, A or B?
>
> For me, cas A hobbyists will happily use the latest Java LTS. And in case B
> support DID end in a sense Guillaume meant it.
>
> Thanks
> T
>
> On Thu, Jun 1, 2023 at 12:39 PM Elliotte Rusty Harold <el...@ibiblio.org>
> wrote:
>
> > On Thu, Jun 1, 2023 at 6:28 AM Guillaume Nodet <gn...@apache.org> wrote:
> > >
> > > JDK 8 active support ended 15 months ago, so I think that's definitely
> > fine
> > > to require a newer version.
> >
> > This is a common misconception. JDK 8 is fully supported by multiple
> > companies including Azul. It also seems supported by Oracle:
> >
> > "For Java SE 8, Oracle will continue to release new updates on its
> > public websites for personal/individual users or for non-production,
> > development/testing purposes. However, commercial/business use of
> > those public releases in production is restricted and requires a
> > commercial license."
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Tamás Cservenák <ta...@cservenak.net>.
This is silly.
So we need to support Java 8 in the future (not yet happened) Maven 4
releases due:
A) hobbyist (personal/individual users or for non-production,
development/testing purposes)
OR
B) commercial entities paying for licenses (commercial/business use of
those public releases in production is restricted and requires a commercial
license)
Which one, A or B?
For me, cas A hobbyists will happily use the latest Java LTS. And in case B
support DID end in a sense Guillaume meant it.
Thanks
T
On Thu, Jun 1, 2023 at 12:39 PM Elliotte Rusty Harold <el...@ibiblio.org>
wrote:
> On Thu, Jun 1, 2023 at 6:28 AM Guillaume Nodet <gn...@apache.org> wrote:
> >
> > JDK 8 active support ended 15 months ago, so I think that's definitely
> fine
> > to require a newer version.
>
> This is a common misconception. JDK 8 is fully supported by multiple
> companies including Azul. It also seems supported by Oracle:
>
> "For Java SE 8, Oracle will continue to release new updates on its
> public websites for personal/individual users or for non-production,
> development/testing purposes. However, commercial/business use of
> those public releases in production is restricted and requires a
> commercial license."
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Thu, Jun 1, 2023 at 6:28 AM Guillaume Nodet <gn...@apache.org> wrote:
>
> JDK 8 active support ended 15 months ago, so I think that's definitely fine
> to require a newer version.
This is a common misconception. JDK 8 is fully supported by multiple
companies including Azul. It also seems supported by Oracle:
"For Java SE 8, Oracle will continue to release new updates on its
public websites for personal/individual users or for non-production,
development/testing purposes. However, commercial/business use of
those public releases in production is restricted and requires a
commercial license."
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Sounds like a plan to me we have to adopt the new JDK release schedule
somehow anyway, we cant stick on java 8 now it is EOL and java 11 soon so
today only java 17 is a fair option for users.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le jeu. 1 juin 2023 à 08:28, Guillaume Nodet <gn...@apache.org> a écrit :
> JDK 8 active support ended 15 months ago, so I think that's definitely fine
> to require a newer version. I don't think we should wait and support JDK 8
> until 2030 and then switch from JDK 8 to what, JDK 24 ? That's really not a
> good plan imho and that's what maintenance branches are used for. The JDK
> release cycle has changed and the whole java ecosystem is adapting to this
> faster release cycle.
>
> So I think we should:
> * maintain a 3.x branch with JDK 8 and provide bug fixes
> * set up 4.x branches to require at least the oldest actively supported
> JDK at the time the first micro version is released (so that would be 17 by
> the time 4.0.0 comes out) and 21 by the end of 2026 (maybe 4.2.0 ?)
> JDK 17 can still target JDK 8 for compilation, so that should cover most
> needs.
>
> If needed, we could even automatically download a JRE 17 at first usage
> (using [1] but we'd have to check for upgrades, etc...) and continue the
> work for discovering toolchains [2], etc... to help users. We could also
> make JDK toolchains much easier to use by modifying the project model and
> adding specific support for it. That would allow selecting the toolchains
> very early in the build, thus allowing toolchain based jdk activation, and
> would make the configuration much simpler. Though I have a feeling that
> all this is not really necessary...
>
> Guillaume
>
> [1] https://foojay.io/
> [2] https://github.com/apache/maven-toolchains-plugin/pulls
>
> Le mer. 31 mai 2023 à 21:17, Michael Osipov <mi...@apache.org> a écrit
> :
>
> > I also would like to point out that OpenJDK 8 support will surpass 11 by
> > 2030: https://endoflife.date/java
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Guillaume Nodet <gn...@apache.org>.
JDK 8 active support ended 15 months ago, so I think that's definitely fine
to require a newer version. I don't think we should wait and support JDK 8
until 2030 and then switch from JDK 8 to what, JDK 24 ? That's really not a
good plan imho and that's what maintenance branches are used for. The JDK
release cycle has changed and the whole java ecosystem is adapting to this
faster release cycle.
So I think we should:
* maintain a 3.x branch with JDK 8 and provide bug fixes
* set up 4.x branches to require at least the oldest actively supported
JDK at the time the first micro version is released (so that would be 17 by
the time 4.0.0 comes out) and 21 by the end of 2026 (maybe 4.2.0 ?)
JDK 17 can still target JDK 8 for compilation, so that should cover most
needs.
If needed, we could even automatically download a JRE 17 at first usage
(using [1] but we'd have to check for upgrades, etc...) and continue the
work for discovering toolchains [2], etc... to help users. We could also
make JDK toolchains much easier to use by modifying the project model and
adding specific support for it. That would allow selecting the toolchains
very early in the build, thus allowing toolchain based jdk activation, and
would make the configuration much simpler. Though I have a feeling that
all this is not really necessary...
Guillaume
[1] https://foojay.io/
[2] https://github.com/apache/maven-toolchains-plugin/pulls
Le mer. 31 mai 2023 à 21:17, Michael Osipov <mi...@apache.org> a écrit :
> I also would like to point out that OpenJDK 8 support will surpass 11 by
> 2030: https://endoflife.date/java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Michael Osipov <mi...@apache.org>.
I also would like to point out that OpenJDK 8 support will surpass 11 by 2030: https://endoflife.date/java
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Niels Basjes <Ni...@basjes.nl>.
Hi all,
From my perspective having Java 17 as the minimal runtime for maven itself
is fine.
I have several projects that need to produce Java 8 binaries and I have
been running all my builds with Java 17 for quite some time now.
The toolchains setup works fine for all use cases I have seen so far.
Some of the effects I have noticed:
- I can run these builds with Maven running on Java 17 and then build the
various modules with any JDK (8,11,17) I need for the specific module.
- I can run a each IT in a different JDK to ensure the needed compatibility
(JPMS and such). In this test project I also have a Multi JDK module where
I then run the same IT on each of the configured JDKs.
- There is no need for doing the matrix builds (i.e. re run the entire
build with different JDK versions) as I see in many projects
I have a minimalistic test project in which I have experimented with all of
this a while ago.
https://github.com/nielsbasjes/ToolChainsInCiBuilds
This also shows how to build a project like this on both Github and Gitlab.
Niels Basjes
On Wed, May 31, 2023 at 5:27 PM Christoph Läubrich <ma...@laeubi-soft.de>
wrote:
> That one needs java to *RUN* maven is an implementation detail for me
> and the actual java version do not matter.
>
> At best maven would ship with whatever JVM is required, or has a
> launcher that downloads one or ... e.g. for Eclipse IDE (and other
> software as well) one simply downloads a package (maybe with installer)
> that is specific for a platform, so the same could work for maven, so
> simply ship a "maven-runtime-jvm" with it...
>
> Then there is java used for *COMPILE* and with the -release flags today
> this does not matter much either and the maven-compiler-plugin should
> offer whatever suffice to find/use the best to compile.
>
> Then there might be java used to *RUN/TEST* an application where one
> might want to test several ones or a specific one, but this is then best
> configured separately from RUN maven or COMPILE code jdks...
>
> Of course it is *CONVENIENT* to use the same java for each of the cases,
> but its not a requirement, and maybe one should just make it more
> convenient to use different JVMs for the different cases ... So if I
> configure my test to run on java 8, maven should simply either find or
> download a suitable JVM (maybe from maven central), if I have very
> special requirements on the actual JVM vendor or version one can still
> configure it explicitly, but I would assume that for > 99% it is simply
> irrelevant if its Adpotium, OpenJDK, Oracle, Azul, ... whatever, all
> that counts is it is a Java 1.8 so I can say I have tested it with (one)
> Java 1.8 compliant JVM! And i should not need any setup (beside
> downloading maven).
>
> To some extend, maven can even ship with a JDK8, 11, 17 and 21 out of
> the box!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Best regards / Met vriendelijke groeten,
Niels Basjes
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
That one needs java to *RUN* maven is an implementation detail for me
and the actual java version do not matter.
At best maven would ship with whatever JVM is required, or has a
launcher that downloads one or ... e.g. for Eclipse IDE (and other
software as well) one simply downloads a package (maybe with installer)
that is specific for a platform, so the same could work for maven, so
simply ship a "maven-runtime-jvm" with it...
Then there is java used for *COMPILE* and with the -release flags today
this does not matter much either and the maven-compiler-plugin should
offer whatever suffice to find/use the best to compile.
Then there might be java used to *RUN/TEST* an application where one
might want to test several ones or a specific one, but this is then best
configured separately from RUN maven or COMPILE code jdks...
Of course it is *CONVENIENT* to use the same java for each of the cases,
but its not a requirement, and maybe one should just make it more
convenient to use different JVMs for the different cases ... So if I
configure my test to run on java 8, maven should simply either find or
download a suitable JVM (maybe from maven central), if I have very
special requirements on the actual JVM vendor or version one can still
configure it explicitly, but I would assume that for > 99% it is simply
irrelevant if its Adpotium, OpenJDK, Oracle, Azul, ... whatever, all
that counts is it is a Java 1.8 so I can say I have tested it with (one)
Java 1.8 compliant JVM! And i should not need any setup (beside
downloading maven).
To some extend, maven can even ship with a JDK8, 11, 17 and 21 out of
the box!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Nikita Skvortsov <ni...@jetbrains.com.INVALID>.
These are JDKs used as "Module JDK".
These are JDKs that compile the source code or run the tests (as the
default option). Regardless of the language level setting.
So the first line reads like this:
"Among IntelliJ Ultimate users with Maven projects, 49.1% have at least one
module that is compiled using JDK8"
--
Nikita Skvortsov
Software Developer
JetBrains
http://www.jetbrains.com
The Drive to Develop
ср, 31 мая 2023 г. в 16:03, Tamás Cservenák <ta...@cservenak.net>:
> Thank you!
> But I have a problem understanding this info....
> AFAIK, IDEA embeds Java "that runs on".
> So what is this, targeted platforms? (like maven.compiler.release?)
> Or JDKs registered in IDE used for projects?
>
> Thanks
> T
>
> On Wed, May 31, 2023 at 4:00 PM Nikita Skvortsov
> <ni...@jetbrains.com.invalid> wrote:
>
> > > sure, it would be nice to see those numbers... :)
> >
> > Here we go.
> > The numbers below are for users who have Maven projects.
> > Please note that the same user can report multiple JDKs, so numbers do
> not
> > add up to 100.
> >
> > For IntelliJ Ultimate, the Top 5 JDK versions are:
> > 8 - 49.1%
> > 17 - 37.4%
> > 11 - 27.2%
> > 20 - 10.5%
> > 19 - 9.7%
> >
> > For IntelliJ Community, the Top 5 JDK versions are:
> > 17 - 31.8%
> > 8 - 31.8%
> > 11 - 24.6%
> > 20 - 20.1%
> > 19 - 10.8%
> >
> > Let me know if you are interested in other data or have any other
> questions
> > about Maven integration in IntelliJ IDEA
> > Best regards,
> > --
> > Nikita Skvortsov
> > Software Developer
> > JetBrains
> > http://www.jetbrains.com
> > The Drive to Develop
> >
> >
> > ср, 31 мая 2023 г. в 14:32, Tamás Cservenák <ta...@cservenak.net>:
> >
> > > Howdy Nikita,
> > >
> > > sure, it would be nice to see those numbers... :)
> > >
> > > Thanks
> > > Tamas
> > >
> > > On Wed, May 31, 2023 at 2:25 PM Nikita Skvortsov
> > > <ni...@jetbrains.com.invalid> wrote:
> > >
> > > > > Do we have some download stats (not a poll) - maybe on sdkman or
> some
> > > jdk
> > > > > vendors side?
> > > >
> > > > Dear Maven team,
> > > >
> > > > Would it help you to make the decision if you have usage statistics
> of
> > > JDK
> > > > 17 among IntelliJ IDEA Maven users?
> > > >
> > > > --
> > > > Nikita Skvortsov
> > > > Software Developer
> > > > JetBrains
> > > > http://www.jetbrains.com
> > > > The Drive to Develop
> > > >
> > > >
> > > > ср, 31 мая 2023 г. в 11:43, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >:
> > > >
> > > > > Do we have some download stats (not a poll) - maybe on sdkman or
> some
> > > jdk
> > > > > vendors side?
> > > > > Recently I saw (with customers I'm working on) the java 17 adoption
> > > being
> > > > > quite large and since people stucked to 3.9 will be covered for
> java
> > 8
> > > I
> > > > > think it could be sane to switch *master* if we can validate with
> > > actual
> > > > > figures (with little bias) that java 17 is >= 50% (being said the
> > > forward
> > > > > way is it will only increase).
> > > > >
> > > > > Side note: I'm not sure toolchain workaround is of any help there
> > since
> > > > the
> > > > > main case will likely stay "use the contextual one and I don't have
> > > > others
> > > > > to offer you".
> > > > >
> > > > > So overall, if we can find some convergence that java 17 is getting
> > > > widely
> > > > > adopted I would be to switch now fo rmaven 4 without any toolchain
> > > hack.
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > <
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > >
> > > > >
> > > > >
> > > > > Le mer. 31 mai 2023 à 11:21, Michael Osipov <mi...@apache.org>
> 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.
> > > > > >
> > > > > > M
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Tamás Cservenák <ta...@cservenak.net>.
Thank you!
But I have a problem understanding this info....
AFAIK, IDEA embeds Java "that runs on".
So what is this, targeted platforms? (like maven.compiler.release?)
Or JDKs registered in IDE used for projects?
Thanks
T
On Wed, May 31, 2023 at 4:00 PM Nikita Skvortsov
<ni...@jetbrains.com.invalid> wrote:
> > sure, it would be nice to see those numbers... :)
>
> Here we go.
> The numbers below are for users who have Maven projects.
> Please note that the same user can report multiple JDKs, so numbers do not
> add up to 100.
>
> For IntelliJ Ultimate, the Top 5 JDK versions are:
> 8 - 49.1%
> 17 - 37.4%
> 11 - 27.2%
> 20 - 10.5%
> 19 - 9.7%
>
> For IntelliJ Community, the Top 5 JDK versions are:
> 17 - 31.8%
> 8 - 31.8%
> 11 - 24.6%
> 20 - 20.1%
> 19 - 10.8%
>
> Let me know if you are interested in other data or have any other questions
> about Maven integration in IntelliJ IDEA
> Best regards,
> --
> Nikita Skvortsov
> Software Developer
> JetBrains
> http://www.jetbrains.com
> The Drive to Develop
>
>
> ср, 31 мая 2023 г. в 14:32, Tamás Cservenák <ta...@cservenak.net>:
>
> > Howdy Nikita,
> >
> > sure, it would be nice to see those numbers... :)
> >
> > Thanks
> > Tamas
> >
> > On Wed, May 31, 2023 at 2:25 PM Nikita Skvortsov
> > <ni...@jetbrains.com.invalid> wrote:
> >
> > > > Do we have some download stats (not a poll) - maybe on sdkman or some
> > jdk
> > > > vendors side?
> > >
> > > Dear Maven team,
> > >
> > > Would it help you to make the decision if you have usage statistics of
> > JDK
> > > 17 among IntelliJ IDEA Maven users?
> > >
> > > --
> > > Nikita Skvortsov
> > > Software Developer
> > > JetBrains
> > > http://www.jetbrains.com
> > > The Drive to Develop
> > >
> > >
> > > ср, 31 мая 2023 г. в 11:43, Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> > >
> > > > Do we have some download stats (not a poll) - maybe on sdkman or some
> > jdk
> > > > vendors side?
> > > > Recently I saw (with customers I'm working on) the java 17 adoption
> > being
> > > > quite large and since people stucked to 3.9 will be covered for java
> 8
> > I
> > > > think it could be sane to switch *master* if we can validate with
> > actual
> > > > figures (with little bias) that java 17 is >= 50% (being said the
> > forward
> > > > way is it will only increase).
> > > >
> > > > Side note: I'm not sure toolchain workaround is of any help there
> since
> > > the
> > > > main case will likely stay "use the contextual one and I don't have
> > > others
> > > > to offer you".
> > > >
> > > > So overall, if we can find some convergence that java 17 is getting
> > > widely
> > > > adopted I would be to switch now fo rmaven 4 without any toolchain
> > hack.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le mer. 31 mai 2023 à 11:21, Michael Osipov <mi...@apache.org> 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.
> > > > >
> > > > > M
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Nikita Skvortsov <ni...@jetbrains.com.INVALID>.
> sure, it would be nice to see those numbers... :)
Here we go.
The numbers below are for users who have Maven projects.
Please note that the same user can report multiple JDKs, so numbers do not
add up to 100.
For IntelliJ Ultimate, the Top 5 JDK versions are:
8 - 49.1%
17 - 37.4%
11 - 27.2%
20 - 10.5%
19 - 9.7%
For IntelliJ Community, the Top 5 JDK versions are:
17 - 31.8%
8 - 31.8%
11 - 24.6%
20 - 20.1%
19 - 10.8%
Let me know if you are interested in other data or have any other questions
about Maven integration in IntelliJ IDEA
Best regards,
--
Nikita Skvortsov
Software Developer
JetBrains
http://www.jetbrains.com
The Drive to Develop
ср, 31 мая 2023 г. в 14:32, Tamás Cservenák <ta...@cservenak.net>:
> Howdy Nikita,
>
> sure, it would be nice to see those numbers... :)
>
> Thanks
> Tamas
>
> On Wed, May 31, 2023 at 2:25 PM Nikita Skvortsov
> <ni...@jetbrains.com.invalid> wrote:
>
> > > Do we have some download stats (not a poll) - maybe on sdkman or some
> jdk
> > > vendors side?
> >
> > Dear Maven team,
> >
> > Would it help you to make the decision if you have usage statistics of
> JDK
> > 17 among IntelliJ IDEA Maven users?
> >
> > --
> > Nikita Skvortsov
> > Software Developer
> > JetBrains
> > http://www.jetbrains.com
> > The Drive to Develop
> >
> >
> > ср, 31 мая 2023 г. в 11:43, Romain Manni-Bucau <rm...@gmail.com>:
> >
> > > Do we have some download stats (not a poll) - maybe on sdkman or some
> jdk
> > > vendors side?
> > > Recently I saw (with customers I'm working on) the java 17 adoption
> being
> > > quite large and since people stucked to 3.9 will be covered for java 8
> I
> > > think it could be sane to switch *master* if we can validate with
> actual
> > > figures (with little bias) that java 17 is >= 50% (being said the
> forward
> > > way is it will only increase).
> > >
> > > Side note: I'm not sure toolchain workaround is of any help there since
> > the
> > > main case will likely stay "use the contextual one and I don't have
> > others
> > > to offer you".
> > >
> > > So overall, if we can find some convergence that java 17 is getting
> > widely
> > > adopted I would be to switch now fo rmaven 4 without any toolchain
> hack.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mer. 31 mai 2023 à 11:21, Michael Osipov <mi...@apache.org> 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.
> > > >
> > > > M
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Tamás Cservenák <ta...@cservenak.net>.
Howdy Nikita,
sure, it would be nice to see those numbers... :)
Thanks
Tamas
On Wed, May 31, 2023 at 2:25 PM Nikita Skvortsov
<ni...@jetbrains.com.invalid> wrote:
> > Do we have some download stats (not a poll) - maybe on sdkman or some jdk
> > vendors side?
>
> Dear Maven team,
>
> Would it help you to make the decision if you have usage statistics of JDK
> 17 among IntelliJ IDEA Maven users?
>
> --
> Nikita Skvortsov
> Software Developer
> JetBrains
> http://www.jetbrains.com
> The Drive to Develop
>
>
> ср, 31 мая 2023 г. в 11:43, Romain Manni-Bucau <rm...@gmail.com>:
>
> > Do we have some download stats (not a poll) - maybe on sdkman or some jdk
> > vendors side?
> > Recently I saw (with customers I'm working on) the java 17 adoption being
> > quite large and since people stucked to 3.9 will be covered for java 8 I
> > think it could be sane to switch *master* if we can validate with actual
> > figures (with little bias) that java 17 is >= 50% (being said the forward
> > way is it will only increase).
> >
> > Side note: I'm not sure toolchain workaround is of any help there since
> the
> > main case will likely stay "use the contextual one and I don't have
> others
> > to offer you".
> >
> > So overall, if we can find some convergence that java 17 is getting
> widely
> > adopted I would be to switch now fo rmaven 4 without any toolchain hack.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 31 mai 2023 à 11:21, Michael Osipov <mi...@apache.org> 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.
> > >
> > > M
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Nikita Skvortsov <ni...@jetbrains.com.INVALID>.
> Do we have some download stats (not a poll) - maybe on sdkman or some jdk
> vendors side?
Dear Maven team,
Would it help you to make the decision if you have usage statistics of JDK
17 among IntelliJ IDEA Maven users?
--
Nikita Skvortsov
Software Developer
JetBrains
http://www.jetbrains.com
The Drive to Develop
ср, 31 мая 2023 г. в 11:43, Romain Manni-Bucau <rm...@gmail.com>:
> Do we have some download stats (not a poll) - maybe on sdkman or some jdk
> vendors side?
> Recently I saw (with customers I'm working on) the java 17 adoption being
> quite large and since people stucked to 3.9 will be covered for java 8 I
> think it could be sane to switch *master* if we can validate with actual
> figures (with little bias) that java 17 is >= 50% (being said the forward
> way is it will only increase).
>
> Side note: I'm not sure toolchain workaround is of any help there since the
> main case will likely stay "use the contextual one and I don't have others
> to offer you".
>
> So overall, if we can find some convergence that java 17 is getting widely
> adopted I would be to switch now fo rmaven 4 without any toolchain hack.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 31 mai 2023 à 11:21, Michael Osipov <mi...@apache.org> 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.
> >
> > M
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Do we have some download stats (not a poll) - maybe on sdkman or some jdk
vendors side?
Recently I saw (with customers I'm working on) the java 17 adoption being
quite large and since people stucked to 3.9 will be covered for java 8 I
think it could be sane to switch *master* if we can validate with actual
figures (with little bias) that java 17 is >= 50% (being said the forward
way is it will only increase).
Side note: I'm not sure toolchain workaround is of any help there since the
main case will likely stay "use the contextual one and I don't have others
to offer you".
So overall, if we can find some convergence that java 17 is getting widely
adopted I would be to switch now fo rmaven 4 without any toolchain hack.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 31 mai 2023 à 11:21, Michael Osipov <mi...@apache.org> 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.
>
> M
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Mark Derricutt <ma...@talios.com>.
On 31/05/2023 at 9:21:43 PM, Michael Osipov <mi...@apache.org> wrote:
> 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.
Yep - unless 4.x can introduce some hook for extensions to modify the POM
model before becoming immutable, I don’t see us moving beyond for a long
time (or anyone else now using our tiles-maven-plugin - which I’ve
unfortunately not really had a chance to dive into seeing if/how we could
rework it to support M4).
Mark
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Tamás Cservenák <ta...@cservenak.net>.
On Wed, May 31, 2023 at 11:22 AM Michael Osipov <mi...@apache.org> wrote:
> 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.
>
That's fine, it's their decision to do so.
T
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Jeremy Landis <je...@hotmail.com>.
+1 on java 17. Stats matter but can tell you we are 90% jdk 17 on builds already, don't use toolchains. It's unnecessary. A lot of it is education to development staff that Devops must push and enable teams. Maven could help drive that here...
As to comment on 3.8 vs 3.9. We already dropped 3.8 in mass. We allowed both until docker containers were updated. Once done we blocked 3.8 outright for 3.9.1 or better. Expect same with maven 4. And further any plugins out of 100s we use, if not there we will fork them.
With spring forcing 17 far too soon and spring boot still stating the intend to drop all old support in November, developers are being forced.
So back to maven, why struggle with old coding patterns when java offers so many enhancements that are otherwise missed?
And stats matter. What's the pull numbers from sonatype show? Growth pattern at all yet? I'd say once the tipping point is seen, move. And keep in mind big companies hide their full usage so it's hard-to-get real stats.
And finally, I see no point to those that choose to stay on legacy. I bet in their cases libraries are not maintained either but that shouldn't be everyone's problem. Provide a clear path and cater more towards those that care.
We have 20 year old java products working on jdk 20 now too...so it's not a difficult ask. Just need guidance on how...
Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Guillaume Nodet <gn...@apache.org>
Sent: Wednesday, May 31, 2023 6:37:12 AM
To: Maven Developers List <de...@maven.apache.org>
Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0
Le mer. 31 mai 2023 à 12:28, Michael Osipov <mi...@apache.org> a écrit :
> On 2023/05/31 10:03:34 Guillaume Nodet wrote:
> > Le mer. 31 mai 2023 à 11:21, Michael Osipov <mi...@apache.org> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Henning Schmiedehausen <he...@schmiedehausen.org>.
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 <gn...@apache.org> wrote:
> Le mer. 31 mai 2023 à 12:28, Michael Osipov <mi...@apache.org> a écrit
> :
>
> > On 2023/05/31 10:03:34 Guillaume Nodet wrote:
> > > Le mer. 31 mai 2023 à 11:21, Michael Osipov <mi...@apache.org> 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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Tamás Cservenák <ta...@cservenak.net>.
On Wed, May 31, 2023 at 1:59 PM Elliotte Rusty Harold <el...@ibiblio.org>
wrote:
> That's not really true. Short of a complete fork, new versions can't
> go out without effort from PMC members. Users cannot effectively
> self-serve here.
>
That's not what Guillaume said. Nobody mentioned "self serve".
Simply put, any interested party can provide PRs against 3.8 or 3.9
branches, and ultimately can ask any of the PMCs to perform a release. Game
is free for all, that's all.
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Wed, May 31, 2023 at 10:37 AM Guillaume Nodet <gn...@apache.org> wrote:
>
> 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.
That's not really true. Short of a complete fork, new versions can't
go out without effort from PMC members. Users cannot effectively
self-serve here.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Guillaume Nodet <gn...@apache.org>.
Le mer. 31 mai 2023 à 12:28, Michael Osipov <mi...@apache.org> a écrit :
> On 2023/05/31 10:03:34 Guillaume Nodet wrote:
> > Le mer. 31 mai 2023 à 11:21, Michael Osipov <mi...@apache.org> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Michael Osipov <mi...@apache.org>.
On 2023/05/31 10:03:34 Guillaume Nodet wrote:
> Le mer. 31 mai 2023 à 11:21, Michael Osipov <mi...@apache.org> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Michael Osipov <mi...@apache.org>.
Am 2023-06-06 um 11:26 schrieb Jean-Baptiste Onofré:
> Hi,
>
> I agree with Guillaume here. It's actually an easy update path.
For who? For you? Do you speak for others as well?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
I agree with Guillaume here. It's actually an easy update path.
Regards
JB
On Wed, May 31, 2023 at 12:03 PM Guillaume Nodet <gn...@apache.org> wrote:
>
> Le mer. 31 mai 2023 à 11:21, Michael Osipov <mi...@apache.org> 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.
>
>
> >
> > M
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Guillaume Nodet <gn...@apache.org>.
Le mer. 31 mai 2023 à 11:21, Michael Osipov <mi...@apache.org> 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.
>
> M
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Michael Osipov <mi...@apache.org>.
> 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.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Think whatever version we release we must meet the most common version for
project starting when release is around, as of today - and even in a year -
it will not be 21 but 17 AFAIK so 17 looks natural if we intend to have a
4.0.0 < 2 years....else 21 is very relevant.
Anything else goes legacy on what is already there and does not help much
to decide IMHO.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 31 mai 2023 à 14:38, Tamás Cservenák <ta...@cservenak.net> a écrit :
> Good question! :D
>
>
> On Wed, May 31, 2023 at 2:34 PM Delany <de...@gmail.com> wrote:
>
> > Excuse my ignorance but what do customer requirements have to do with the
> > build tool's required JDK?
> > Delany
> >
> >
> > On Wed, 31 May 2023 at 13:57, Elliotte Rusty Harold <el...@ibiblio.org>
> > wrote:
> >
> > > On Wed, May 31, 2023 at 8:30 AM Guillaume Nodet <gn...@apache.org>
> > wrote:
> > >
> > > > I think with those improvements, requiring JDK 17 for master should
> be
> > > > doable. Any concerns of suggestions ?
> > >
> > > Hard no from me. JDK 8 is still very much in use, and is my day-to-day
> > > VM. I switch to 11 when I have to, and I don't anticipate switching to
> > > 17 for years unless I decide to write another book.
> > >
> > > When I left Google and GCP about a year ago, we still had customer
> > > requirements for quite old versions. From the public docs it looks
> > > like they still support Java 8 and sometimes Java 7.
> > >
> > > I know of multiple companies where the migration to Java 11 is still
> > > in progress. Some companies are also sticking to Java 8 for likely the
> > > remainder of my career. JPMS in Java 9 caused a lot of problems for
> > > weakly supported libraries and many devs can't or won't upgrade past
> > > Java 8 for that reason.
> > >
> > > Slow and steady wins the race. Java 8 is a perfectly fine VM, and
> > > Maven really doesn't need anything more right now. I think we'll get
> > > to Java 11 eventually. but that's still a few years down the road and
> > > there's a lot of cleanup work to be done first. Just today I sent a PR
> > > to replace some utility methods we haven't needed since Java *1.4*.
> > > When there's some improvement we really can't make without updating to
> > > Java 11 is when we should consider switching. So far I don't see any
> > > critical need for it though.
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elharo@ibiblio.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Tamás Cservenák <ta...@cservenak.net>.
Good question! :D
On Wed, May 31, 2023 at 2:34 PM Delany <de...@gmail.com> wrote:
> Excuse my ignorance but what do customer requirements have to do with the
> build tool's required JDK?
> Delany
>
>
> On Wed, 31 May 2023 at 13:57, Elliotte Rusty Harold <el...@ibiblio.org>
> wrote:
>
> > On Wed, May 31, 2023 at 8:30 AM Guillaume Nodet <gn...@apache.org>
> wrote:
> >
> > > I think with those improvements, requiring JDK 17 for master should be
> > > doable. Any concerns of suggestions ?
> >
> > Hard no from me. JDK 8 is still very much in use, and is my day-to-day
> > VM. I switch to 11 when I have to, and I don't anticipate switching to
> > 17 for years unless I decide to write another book.
> >
> > When I left Google and GCP about a year ago, we still had customer
> > requirements for quite old versions. From the public docs it looks
> > like they still support Java 8 and sometimes Java 7.
> >
> > I know of multiple companies where the migration to Java 11 is still
> > in progress. Some companies are also sticking to Java 8 for likely the
> > remainder of my career. JPMS in Java 9 caused a lot of problems for
> > weakly supported libraries and many devs can't or won't upgrade past
> > Java 8 for that reason.
> >
> > Slow and steady wins the race. Java 8 is a perfectly fine VM, and
> > Maven really doesn't need anything more right now. I think we'll get
> > to Java 11 eventually. but that's still a few years down the road and
> > there's a lot of cleanup work to be done first. Just today I sent a PR
> > to replace some utility methods we haven't needed since Java *1.4*.
> > When there's some improvement we really can't make without updating to
> > Java 11 is when we should consider switching. So far I don't see any
> > critical need for it though.
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Delany <de...@gmail.com>.
Excuse my ignorance but what do customer requirements have to do with the
build tool's required JDK?
Delany
On Wed, 31 May 2023 at 13:57, Elliotte Rusty Harold <el...@ibiblio.org>
wrote:
> On Wed, May 31, 2023 at 8:30 AM Guillaume Nodet <gn...@apache.org> wrote:
>
> > I think with those improvements, requiring JDK 17 for master should be
> > doable. Any concerns of suggestions ?
>
> Hard no from me. JDK 8 is still very much in use, and is my day-to-day
> VM. I switch to 11 when I have to, and I don't anticipate switching to
> 17 for years unless I decide to write another book.
>
> When I left Google and GCP about a year ago, we still had customer
> requirements for quite old versions. From the public docs it looks
> like they still support Java 8 and sometimes Java 7.
>
> I know of multiple companies where the migration to Java 11 is still
> in progress. Some companies are also sticking to Java 8 for likely the
> remainder of my career. JPMS in Java 9 caused a lot of problems for
> weakly supported libraries and many devs can't or won't upgrade past
> Java 8 for that reason.
>
> Slow and steady wins the race. Java 8 is a perfectly fine VM, and
> Maven really doesn't need anything more right now. I think we'll get
> to Java 11 eventually. but that's still a few years down the road and
> there's a lot of cleanup work to be done first. Just today I sent a PR
> to replace some utility methods we haven't needed since Java *1.4*.
> When there's some improvement we really can't make without updating to
> Java 11 is when we should consider switching. So far I don't see any
> critical need for it though.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Wed, May 31, 2023 at 8:30 AM Guillaume Nodet <gn...@apache.org> wrote:
> I think with those improvements, requiring JDK 17 for master should be
> doable. Any concerns of suggestions ?
Hard no from me. JDK 8 is still very much in use, and is my day-to-day
VM. I switch to 11 when I have to, and I don't anticipate switching to
17 for years unless I decide to write another book.
When I left Google and GCP about a year ago, we still had customer
requirements for quite old versions. From the public docs it looks
like they still support Java 8 and sometimes Java 7.
I know of multiple companies where the migration to Java 11 is still
in progress. Some companies are also sticking to Java 8 for likely the
remainder of my career. JPMS in Java 9 caused a lot of problems for
weakly supported libraries and many devs can't or won't upgrade past
Java 8 for that reason.
Slow and steady wins the race. Java 8 is a perfectly fine VM, and
Maven really doesn't need anything more right now. I think we'll get
to Java 11 eventually. but that's still a few years down the road and
there's a lot of cleanup work to be done first. Just today I sent a PR
to replace some utility methods we haven't needed since Java *1.4*.
When there's some improvement we really can't make without updating to
Java 11 is when we should consider switching. So far I don't see any
critical need for it though.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Gary Gregory <ga...@gmail.com>.
(Non-binding chatter) I'm ok with Java 17 but since M4 feels like it's not
around the corner, why not go for Java 21-EA and possibly learn even more
cool tech. Surely Java 21 which is an LTS version will be released as GA
before M4.
Gary
On Wed, May 31, 2023, 04:30 Guillaume Nodet <gn...@apache.org> wrote:
> I'd like to resume this discussion about switching master to require JDK
> 17.
>
> These past days, I've been working on improving the usage of toolchains
> (first inside maven, but now completely in the maven-toolchains-plugin)
> with [1]. If we want to go further, we could simplify the selection by
> modifying the POM somehow to add a specific section, but I suspect most
> people will just use the release flag on the compiler to target bytecode.
> The only downside I see, beyond the additional configuration (though the
> goal is that users don't really have to generate/maintain the toolchains)
> is that the selection of the toolchain is done during the build, so that
> JDK profile based activation can not be used. Note that the use of
> environment variables is also another way to work around, for example in
> github [2].
>
> I think with those improvements, requiring JDK 17 for master should be
> doable. Any concerns of suggestions ?
>
> Cheers,
> Guillaume
>
> [1] https://github.com/apache/maven-toolchains-plugin/pull/14
> [2]
>
> https://github.com/B3Partners/kadaster-gds2/blob/b0cd5c392bc1f48dec11c83c828254a868264467/.github/ubuntu-toolchains.xml
>
> Le mar. 19 juil. 2022 à 18:25, Karl Heinz Marbaise <kh...@gmx.de> a
> écrit :
>
> > Hi to all,
> >
> > what do you think about using JDK17 as minimum requirement for running
> > the future Apache Maven 4.0.0 ?
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Manfred Moser <ma...@simpligility.ca>.
+1
Totally also agree with upping to Java 17.
Working mostly on Trino these days and we have been on 17 for quite a
while and are getting ready to go to 21 soon after it hits. In my
opinion Maven should do the same. There should be no reason not to
support and also default to the latest LTS.
Ultimately users who are good with using old JDK should also be good
with using an old build tool and an old IDE and so on..
And of course they also want to use old dependencies with many nice
security issues... so lets enable them to stop this by making the usage
of old stuff even more painful.
Manfred
On 2023-05-31 03:00, Tamás Cservenák wrote:
> +1 for the move to Java 17 with Maven 4 (am actually for "move to latest
> current Java LTS")
>
> As anyone can see, all the major (OSS) projects did or are in the middle of
> pushing for Java 17.
> In September we have Java 21. The Java release cadence has changed, and it
> did not change yesterday, but a long time ago, so users should live with it.
>
> T
>
> On Wed, May 31, 2023 at 10:30 AM Guillaume Nodet <gn...@apache.org> wrote:
>
>> I'd like to resume this discussion about switching master to require JDK
>> 17.
>>
>> These past days, I've been working on improving the usage of toolchains
>> (first inside maven, but now completely in the maven-toolchains-plugin)
>> with [1]. If we want to go further, we could simplify the selection by
>> modifying the POM somehow to add a specific section, but I suspect most
>> people will just use the release flag on the compiler to target bytecode.
>> The only downside I see, beyond the additional configuration (though the
>> goal is that users don't really have to generate/maintain the toolchains)
>> is that the selection of the toolchain is done during the build, so that
>> JDK profile based activation can not be used. Note that the use of
>> environment variables is also another way to work around, for example in
>> github [2].
>>
>> I think with those improvements, requiring JDK 17 for master should be
>> doable. Any concerns of suggestions ?
>>
>> Cheers,
>> Guillaume
>>
>> [1] https://github.com/apache/maven-toolchains-plugin/pull/14
>> [2]
>>
>> https://github.com/B3Partners/kadaster-gds2/blob/b0cd5c392bc1f48dec11c83c828254a868264467/.github/ubuntu-toolchains.xml
>>
>> Le mar. 19 juil. 2022 à 18:25, Karl Heinz Marbaise <kh...@gmx.de> a
>> écrit :
>>
>>> Hi to all,
>>>
>>> what do you think about using JDK17 as minimum requirement for running
>>> the future Apache Maven 4.0.0 ?
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
Posted by Tamás Cservenák <ta...@cservenak.net>.
+1 for the move to Java 17 with Maven 4 (am actually for "move to latest
current Java LTS")
As anyone can see, all the major (OSS) projects did or are in the middle of
pushing for Java 17.
In September we have Java 21. The Java release cadence has changed, and it
did not change yesterday, but a long time ago, so users should live with it.
T
On Wed, May 31, 2023 at 10:30 AM Guillaume Nodet <gn...@apache.org> wrote:
> I'd like to resume this discussion about switching master to require JDK
> 17.
>
> These past days, I've been working on improving the usage of toolchains
> (first inside maven, but now completely in the maven-toolchains-plugin)
> with [1]. If we want to go further, we could simplify the selection by
> modifying the POM somehow to add a specific section, but I suspect most
> people will just use the release flag on the compiler to target bytecode.
> The only downside I see, beyond the additional configuration (though the
> goal is that users don't really have to generate/maintain the toolchains)
> is that the selection of the toolchain is done during the build, so that
> JDK profile based activation can not be used. Note that the use of
> environment variables is also another way to work around, for example in
> github [2].
>
> I think with those improvements, requiring JDK 17 for master should be
> doable. Any concerns of suggestions ?
>
> Cheers,
> Guillaume
>
> [1] https://github.com/apache/maven-toolchains-plugin/pull/14
> [2]
>
> https://github.com/B3Partners/kadaster-gds2/blob/b0cd5c392bc1f48dec11c83c828254a868264467/.github/ubuntu-toolchains.xml
>
> Le mar. 19 juil. 2022 à 18:25, Karl Heinz Marbaise <kh...@gmx.de> a
> écrit :
>
> > Hi to all,
> >
> > what do you think about using JDK17 as minimum requirement for running
> > the future Apache Maven 4.0.0 ?
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>