Hi all,
Allow me to chime in on this long-running discussion... I haven't raised
my voice yet, as I was curious for other opinions.
*My vote would be Java 17 for both building and running Maven 4.*
I certainly agree with the points brought up by Karl-Heinz and Benjamin
regarding Toolchains. If you really need it, you can use it. I would say
we shouldn't advise our users to use Toolchains by default; many code
bases will probably not need it. Think about all those in-house
developed applications alone, where the team knows perfectly well which
version of which JVM they will be using in production.
I would like to bring an additional point to the table. I think we all
agree we could use more people to contribute to Maven, preferably even
on a frequent basis. I have already seen multiple people getting scared
(and demotivated) by the fact that we have a huge code base which is
written with Java 7 and more recently Java 8. This means people can't
use language features that more recent versions of Java introduced, and
get discouraged by having to write code in what they experience as
"ancient" or even "pre-historic" versions of Java.
Attracting new contributors is not my main reason for voting Java 17 in
Maven 4, but it certainly plays a role for me.
Thanks,
Maarten
On 24/07/2022 08:54, Romain Manni-Bucau wrote:
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
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
