Hi,

On 20.07.22 10:32, Romain Manni-Bucau wrote:
Hi,

Think we have multiple topics there:

1. Which version to *build*, using jdk17 would enable to have some
advanced usage of the JDK and nice build features (IO and concurrent API
are enhanced and can benefit a build when using custom tasks but AFAIK
we don't do it much) but this has no link to 2. (run) since if you
target v8 you can't use selaed classes or even the "new" HttpClient

2. Which minimum requirement for the end user -> here we have to be
pragmatic IMHO and answer the looking simple question: is java ecosystem
v17 ready? All last pools I saw was showing that v17 and v8 were more or
less the same in terms of usage and that v11 was mainstream now so I
guess we have to still care about v8 (note I never said I like that) as
of today but if Maven 4 does not come in the ~1 or 2 years we can
probably target v11 directly without much friction for end users.


3. Do we want to enforce end users to use toolchain to build (run maven
with v17 and compile with v8 for ex) -> here I think the answer is
clearly no, toolchain is a great tool for libraries or very advanced
users but it is almost never used (in regards of the number of maven
project) so don't think it is an option to go that path as of today.

There is no need to use toolchain to run your build with JDK17 and
create code for Java 8... you can use --release 8
(<maven.compiler.release>8</maven.compiler.release>)...

No toolchain needed.

Kind regards
Karl Heinz Marbaise



So overall it means that using java 8 (or 11 if we target a 4.0.0 in >=
1 year?) is probably the sanest with current user ecosystem IMHO.

Side note: as most of the time, for me the topic is not "which features
do we get for us" but more "do we hurt in a blocking and negative way
our users or not".

Hope it makes sense.

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. 20 juil. 2022 à 07:46, Olivier Lamy <ol...@apache.org
<mailto:ol...@apache.org>> a écrit :

    On Wed, 20 Jul 2022 at 02:49, Karl Heinz Marbaise <khmarba...@gmx.de
    <mailto:khmarba...@gmx.de>> wrote:

     > Hi,
     >
     > I really mean runtime ...
     >
     > Kind regards
     > Karl Heinz Marbaise
     >
     > On 19.07.22 18:28, Tamás Cservenák wrote:
     > > Howdy,
     > >
     > > Running or building?
     > >
     > > As for building, I am all for it.
     > > For running (so the bytecode level of built Maven artifacts)
    may be "too
     > > soon" IMHO, I am unsure about this.
     >
     > Spring Framework 3.0.0 (will do so) as well as Spring Boot etc. very
     > large frameworks...
     >
     > >
     > > Hence, I'd go with enforcer to require JDK17, but use compiler
     > > release=11 for now.
     >
     > I would suggest to go that path anyway to use JDK17 and produce via
     > --release 8 (from current perspective)...
     >

    I'm not sure I understand what you want to do?
    do you mean enforcer to enforce maven core is built using jdk 17 but
    compiler using the flag --release 8?



     >
     > >
     > > Note: key component, like sisu inject does NOT support (yet) Java17
     > > bytecode.
     >
     > Hm.. that might be blocker...
     >

    jdk 11 already has a lot of interesting features. I'm not quite sure
    what
    is the killer feature in jdk 17 we really need in Maven?
    jdk 11 sounds like a nice upgrade if we want to have a large adoption of
    Maven 4.0 by the community.
    And btw nothing prevents people using jdk 17 if they want.
    But forcing users to jdk 17 and using the complicated toolchains is a
    different story.
    I feel like jdk 17 will reduce the adoption/upgrade and we will be
    there a
    long time maintaining the 3.x branch and we won't be able to migrate our
    plugins to the new 4.0 apis (and having 2 branches of plugins to
    maintain?)

    Comparing to Spring is not really accurate because there is a company
    behind it, so they have employees to maintains branches for their
    customers
    (because "you still want maintenance of spring xx with jdk 11 so hey too
    easy pay the support" :) )






     >
     > Kind regards
     > Karl Heinz Marbaise
     >
     > >
     > > T
     > >
     > > On Tue, Jul 19, 2022 at 6:25 PM Karl Heinz Marbaise
    <khmarba...@gmx.de <mailto:khmarba...@gmx.de>
     > > <mailto:khmarba...@gmx.de <mailto:khmarba...@gmx.de>>> wrote:
     > >
     > >     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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to