Le dim. 24 juil. 2022 à 08:54, Romain Manni-Bucau <rmannibu...@gmail.com> a
écrit :
> Le sam. 23 juil. 2022 à 21:05, Enno Thieleke <enno.thiel...@holisticon.de>
> a écrit :
>
> > Fwiw:
> >
> > Romain, I think you're exaggerating. The answer is, like in most cases:
> > "it depends".
> >
> > Most people, we're most likely talking 95-99% here, will happily use JDK
> > 17 with Maven 4.
> >
>
> I would lower the figure - keep in mind 95-99% of people also uses libs and
> are affected by what I described - but agree "most" would see it...at the
> cost of configuring toolchain and even just the test/compiler version in
> the pom which breaks our convention over config core design IMHO.
>
> So until we change our design to isolate all our core code and mojo run
> from contextual java version (most mojo are not toolchain friendly, this
> requires a mojo executor evolution to make the ecosystem functional), and
> likely means we can:
>
> 1. Have background jvm runners (reusable) to avoid the cold perf pitfall of
> toolchain
>
Aren't you just describing mvnd ? mvnd is compiled to native already.
> 2. Toolchain functional for all mojo without any mojo change
> 3. A global property to limit the configuration for all mojo
>
> I dont think it would work well in practise.
>
> I also dont want to exclude 50% of users (8+11) just cause we think we
> would maybe gain from that - there is very few valid reason in terms of
> compilation to do that on our side.
>
> Side note: technically, if reached, it means we can make mvn a native
> binary with graalvm and run mojo in java runner so java wouldnt be a real
> constraint for us/users but this has high impacts in terms of design and
> code update requirements.
>
>
> > Some people might need to compile for lower sources and targets, but
> > running tests for those builds in JDK 17 instead of, let's say 11, _will
> > suffice in most cases_.
> >
> > Yes, there will be edge cases where people will be forced to use
> different
> > JDKs at least for tests, some even for builds. But that's possible, so
> they
> > won't get left behind.
> >
> > Regarding mvnd: It's not a silver bullet. It never was and it never will
> > be. Whenever a build spawns new JVMs (for tests or other tasks), it
> doesn't
> > benefit from mvnd anymore (in as much as it would without spawning new
> > JVMs).
> >
> > To not use the latest (LTS) JDK in order to "better" support the 1-5% of
> > the Maven users, who're still using obsolete JVMs (I'm obviously
> referring
> > to Karl's assumption, which I agree with), would be a kick in the teeth
> of
> > all Maven developers, who finally want to embrace the present (not even
> the
> > future).
> >
> > Long story short, +1 for JDK 17 as minimum for Maven 4.
> >
> > Kind regards,
> > Enno
> >
> > ________________________________
> > From: Romain Manni-Bucau <rmannibu...@gmail.com>
> > Sent: Saturday, July 23, 2022 6:55 PM
> > To: Maven Developers List <dev@maven.apache.org>
> > Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0
> >
> > Le sam. 23 juil. 2022 à 17:25, Benjamin Marwell <bmarw...@apache.org> a
> > écrit :
> >
> > > No, 2 JDKs are not required by default. Only if you use --release={<17}
> > and
> > > don't trust running tests on 17 are the same as running tests on 8.
> > > Yes, there are changes (certificates, XML libs, rhino, etc).
> > >
> >
> > As explained it means you dont write a single test or dont care of the
> test
> > results so yes it needs 2 jdk.
> >
> >
> >
> > > So, for most projects that's probably not needed. For those who think
> it
> > is
> > > needed, I don't have a lot of pity. But it will be a requirement for
> > quite
> > > a few commercial projects, like Containers (JavaEE, as they will need
> to
> > be
> > > Java 8 as long as 2030ish due to extended support contracts).
> > >
> > > That said, I'm still thinking Java 17 will be a sane default.
> > >
> > >
> > > On Sat, 23 Jul 2022, 10:50 Delany, <delany.middle...@gmail.com> wrote:
> > >
> > > > Using mvnd with toolchains doesn't improve the situation, in fact
> > > > toolchains seem to invalidate any benefit of using mvnd.
> > > > Even if this was resolved, is it fair to require mvnd?
> > > > Delany
> > > >
> > > >
> > > > On Sat, 23 Jul 2022 at 10:17, Mark Derricutt <m...@talios.com>
> wrote:
> > > >
> > > > > Is that due to cold starting the JVM each time?
> > > > >
> > > > > I wonder if mvnd supports toolchains effectively? Or if that could
> > be
> > > an
> > > > > avenue to try.
> > > > > --
> > > > > "Great artists are extremely selfish and arrogant things" — Steven
> > > > Wilson,
> > > > > Porcupine Tree
> > > > >
> > > > > On 23/07/2022 at 8:13:23 PM, Delany <delany.middle...@gmail.com>
> > > wrote:
> > > > >
> > > > > > I tried toolchains but dropped it because of the exorbitant
> > > performance
> > > > > > costs.
> > > > > > A multi-module build that normally built in 3:50 took 10:34, and
> > > that's
> > > > > > with toolchaining only maven-compiler-plugin.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
--
------------------------
Guillaume Nodet
