At this point, we have discussed many aspects.
Please feel to vote:
User List:
https://lists.apache.org/thread/ty321ns72qc6l26bjy58d9430ofg2w5t
Dev List:
https://lists.apache.org/thread/vngchrr3owd92v9y09lyfjjhwkl5hvtn
-
To
Hi Hervé
Im not sure why there is this belief toolchain improvement is needed, this
is NOT needed and CI already bypass it so for me this is not an enabler,
more a blocker IRL.
Let's improve plugins if they dont enable executable/env config but
toolchain is just a part of the execution of so
Le lundi 26 février 2024, 13:42:19 CET Ceki Gulcu a écrit :
> Hello Bernd,
>
> I was unaware of the capabilities of the release flag. Thank you for
> explaining.
a proof that even capabilities like --release flag from JDK 9 (JEP 247 https://
openjdk.org/jeps/247) need to be promoted because it's
Le mardi 27 février 2024, 13:32:36 CET Elliotte Rusty Harold a écrit :
> Toolchains support using JDK 8 to compile even though JDK 17 is
> executing Maven, which does handle this. Unfortunately toolchains are
> poorly designed, badly documented, and not widely understood within
> the community.
Le mardi 27 février 2024, 18:33:43 CET sebb a écrit :
> On Tue, 27 Feb 2024 at 17:01, Benjamin Marwell wrote:
> > > Compiling for Java 8 with
> > > Java 17 -release 8 is not the same as compiling with javac from JDK 8.
> > > They do not produce the same byte code.
+1 that's a fact
> > > There is
> people will be able to work on solutions after anyway.
Agreed as they can maintain a fork anyway if they really need.
From: Romain Manni-Bucau
Sent: Wednesday, February 28, 2024 3:50:31 AM
To: Maven Developers List
Subject: Re: [DISCUSS] Java version for Ma
Plain standard asf votes - or under the vote manager rules as allowed by
asf if it is agreed but means another discussion.
I dont care much the details but keeping energy for this thread starts to
be more negative on the community than anything positive IMHO so hope we
close it with a decision
On Tue, Feb 27, 2024 at 8:16 PM Xeno Amess wrote:
> whose vote would count and what be the majority:)
> for example should my vote count? or not?
> or just some committers? but why just committers(or not)(as some of them
> might have less contributions even than non-committers)?
> or just pmc?
>
whose vote would count and what be the majority:)
for example should my vote count? or not?
or just some committers? but why just committers(or not)(as some of them
might have less contributions even than non-committers)?
or just pmc?
or everyone share 1 vote(wow I don't think it shall work this
On Tue, 27 Feb 2024 at 17:01, Benjamin Marwell wrote:
>
> > Compiling for Java 8 with
> > Java 17 -release 8 is not the same as compiling with javac from JDK 8.
> > They do not produce the same byte code. There is a need to compile
> > *with* JDK 8, not just compile *for* JDK 8.
>
> And when
On Tue, Feb 27, 2024 at 6:13 PM Romain Manni-Bucau
wrote:
> Not sure we'll converge guys but shouldnt we make a vote? Seems we all
> understand the impacts technically so maybe time to decide else we'll still
> be there in a year.
>
This is exactly what I try in the Eclipse community - vote,
> Compiling for Java 8 with
> Java 17 -release 8 is not the same as compiling with javac from JDK 8.
> They do not produce the same byte code. There is a need to compile
> *with* JDK 8, not just compile *for* JDK 8.
And when would that be needed?
On Tue, 27 Feb 2024, 13:33 Elliotte Rusty
Not sure we'll converge guys but shouldnt we make a vote? Seems we all
understand the impacts technically so maybe time to decide else we'll still
be there in a year.
Le mar. 27 févr. 2024 à 16:41, John Neffenger a écrit :
> On 2/26/24 11:42 AM, Basil Crow wrote:
> > We had a similar
On 2/26/24 11:42 AM, Basil Crow wrote:
We had a similar conversation in the Jenkins community, and I wrote up
our conclusions here:
We also had a similar conversation in the NetBeans community, with the
final vote to drop JDK 8 (vote result: 20 to 1.5). See here:
[VOTE][RESULT] Minimum JDK
On 2/25/2024, 2:49 PM Elliotte Rusty Harold wrote:
>> For #2, reproducible builds mean we have to be able to support what
>> customers are using and that can be anything from Java 8 - 21. It is
>> not sufficient to say Java 21 can compile to Java 8 since that does
>> not produce the same byte
On Tue, Feb 27, 2024 at 1:33 PM Elliotte Rusty Harold
wrote:
> but that only goes so far. There's a fundamental problem that
> toolchains are incompatible with a hermetic, one click build.
>
>
Why so? Could you elaborate?
T
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
>
On Mon, Feb 26, 2024 at 7:24 PM Benjamin Marwell wrote:
>
> > 1. The Java version required by the project being built. That is, the
> byte code and API level of the project.
> > 2. The Java version used to compile the project.
> > 3. The Java version used to run Maven.
> > 4. The Java version
We had a similar conversation in the Jenkins community, and I wrote up
our conclusions here:
https://www.jenkins.io/blog/2023/11/06/introducing-2-2-2-java-support-plan/
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> 1. The Java version required by the project being built. That is, the
byte code and API level of the project.
> 2. The Java version used to compile the project.
> 3. The Java version used to run Maven.
> 4. The Java version used to compile and build Maven itself.
> For #1, it is mandatory to
Hello Bernd,
I was unaware of the capabilities of the release flag. Thank you for
explaining.
--
Ceki Gülcü
Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
On 2/25/2024 1:37 AM, Bernd Eckenfels wrote:
> It has been mentioned before, but just to add, since the
I don't think that quite works. There are *four* Java versions in
play. In decreasing order of importance, they are:
1. The Java version required by the project being built. That is, the
byte code and API level of the project.
2. The Java version used to compile the project.
3. The Java version
On 24.02.24 23:42, Jorge Solórzano wrote:
Hi Maven Developers,
A lot has been told already from both sides, but please, please, let's
focus on how to improve the current status and define how and what Java
version will be required for Maven, not on trivial discussions about using
var or virtual
It has been mentioned before, but just to add, since the bytecode
level is IMHO the smallest problem:
Jorge Solórzano wrote on 25. Feb 2024 00:41 (GMT +01:00):
> you can use JDK 17 to produce Java 8 bytecode using Java 8
> features, that is the distinction I made between runtime and build time,
>
On Sat, Feb 24, 2024, 17:24 Hunter C Payne
wrote:
> Is a JDK 17 capable of building JDK 8 jars from JDK 17 source?
No, it doesn't, you can use JDK 17 to produce Java 8 bytecode using Java 8
features, that is the distinction I made between runtime and build time,
but it looks it's still not
Is a JDK 17 capable of building JDK 8 jars from JDK 17 source? If so, what
are we discussing/arguing/debating about? Seems to me that that configuration
gets you everything you want without forcing Maven 4 to not work with JVM/JRE 8.
Hunter
On Saturday, February 24, 2024 at 03:09:07 PM
On Sat, Feb 24, 2024, 16:55 Tamás Cservenák wrote:
> Jorge,
>
> Allow me one question: why would we need 3.10 for this? Could not we set
> same thing for existing 3.9.x?
>
Yes, but 3.10 can be used to better signal that is an LTS since the
beginning and will only contain critical bug fixes,
Hello,
thanks Jorge I fully support your summary.
want to bring an additional points in support for newer runtime Java: Because
Maven alone isn’t the complete ecosystem and many other tools have higher
requirements already. Fr example both Jenkins (maven-style jobs) as well as
SonarQube
Jorge,
Allow me one question: why would we need 3.10 for this? Could not we set
same thing for existing 3.9.x?
T
On Sat, Feb 24, 2024, 23:43 Jorge Solórzano wrote:
> Hi Maven Developers,
>
> A lot has been told already from both sides, but please, please, let's
> focus on how to improve
Hi Maven Developers,
A lot has been told already from both sides, but please, please, let's
focus on how to improve the current status and define how and what Java
version will be required for Maven, not on trivial discussions about using
var or virtual threads.
Most developers would love to use
> I hate var.
> > > ____________
> > > From: Tamás Cservenák
> > > Sent: Friday, February 23, 2024 9:52:08 PM
> > > To: Maven Developers List
> > > Subject: Re: [DISCUSS] Java version for Maven
> > >
> > > Howdy,
hate var.
> >
> > From: Tamás Cservenák
> > Sent: Friday, February 23, 2024 9:52:08 PM
> > To: Maven Developers List
> > Subject: Re: [DISCUSS] Java version for Maven
> >
> > Howdy,
> >
> > Some more stats based on 2
Make love not var!
T
On Fri, Feb 23, 2024 at 3:09 PM Xeno Amess wrote:
> I hate var.
>
> From: Tamás Cservenák
> Sent: Friday, February 23, 2024 9:52:08 PM
> To: Maven Developers List
> Subject: Re: [DISCUSS] Java version for Maven
>
&
I hate var.
From: Tamás Cservenák
Sent: Friday, February 23, 2024 9:52:08 PM
To: Maven Developers List
Subject: Re: [DISCUSS] Java version for Maven
Howdy,
Some more stats based on 2nd package from Brian
https://gist.github.com/cstamas
One ask for a volunteer:
We are all humans, and we all make mistakes. So I'd like to ask someone to
reproduce these results.
We should not take these for granted, as I may have missed/spoiled/broke
something.
All the data sources are in this thread (both sent by Brian).
Thanks
T
On Fri, Feb 23,
Updated with 3.8.x and 3.9.x data, reload if opened
T
On Fri, Feb 23, 2024 at 2:52 PM Tamás Cservenák wrote:
> Howdy,
>
> Some more stats based on 2nd package from Brian
>
> https://gist.github.com/cstamas/8207f8d70882090a1c63cdedc256ec56
>
> On Fri, Feb 23, 2024 at 2:08 PM Elliotte Rusty
Howdy,
Some more stats based on 2nd package from Brian
https://gist.github.com/cstamas/8207f8d70882090a1c63cdedc256ec56
On Fri, Feb 23, 2024 at 2:08 PM Elliotte Rusty Harold
wrote:
> Yes, with var you still get type checks, unlike in Python. But I have
> wasted so much time debugging Python
Yes, with var you still get type checks, unlike in Python. But I have
wasted so much time debugging Python code simply because the type of a
local variable wasn't right there in the declaration that I remain
unconvinced var was ever a good idea. I have been convinced by
experience that implicitly
Le ven. 23 févr. 2024 à 13:44, Elliotte Rusty Harold a
écrit :
> On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau
> wrote:
> >
> > @Elliotte while you are pretty right in terms of *compile* features but
> it
> > ignores the biggest criteria for any ASF project : the community. Even if
> >
On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau
wrote:
>
> @Elliotte while you are pretty right in terms of *compile* features but it
> ignores the biggest criteria for any ASF project : the community. Even if
> silly, attracting people with Java 8 is born dead today (to illustrate it
> just
On 23.02.24 01:42, Hunter C Payne wrote:
The performance benefits aren't provided by the compiler, they come from
hotspot and that's the JVM version at runtime that matters there.
this is only partially correct. Many optimizations are based on
invokedynamic which only exists post bytecode
@Elliotte while you are pretty right in terms of *compile* features but it
ignores the biggest criteria for any ASF project : the community. Even if
silly, attracting people with Java 8 is born dead today (to illustrate it
just ask somebody to no more use "var" to do a PR for ex, he will start to
On Fri, Feb 23, 2024 at 12:20 AM Robert Dean wrote:
> That being said, if retiring Java 8 and lower output support allows
> Maven to shed technical debt and deliver improvements faster, I'd get
> over my disappointment. :)
Given the amount of tech debt still in Maven from Maven 2 and earlier,
I
Personally, given that Maven that still requires XML and that the language
innovation happens these days outside of the Java language itself, the
technical debt cleanup argument doesn't carry as much weight for me. And
requiring 21 seems like a really big jump from 7-8. The performance
As an end user, having a single version of Maven that could build all
my projects (Java 8 - 21) would be preferred, even if it requires Java
21 to run. That would allow for build pipeline standardization on a
single version of Maven and simplify things for developers.
That being said, if
Given that it will still be quite a while until Maven 4 comes out and we
are probably going to stick to the same Java version for Maven 4 until
we move to 5, I would strongly suggest to go with Java 21.
There are a lot of further performance and other improvements from 17 to
21. Also from our
That feels right to me based on the data and all the discussion so far.
On Thu, Feb 22, 2024 at 3:49 PM Tamás Cservenák wrote:
> I think this starts to make reasonable picture:
>
> If you are on Java 8, use Maven 3
> If you are on Java 9+ use Maven 4 (once out).
>
> For start, Maven3 has no
I think this starts to make reasonable picture:
If you are on Java 8, use Maven 3
If you are on Java 9+ use Maven 4 (once out).
For start, Maven3 has no idea (notion) about "classpaths" vs "modulepaths"
(is not quite true stated like this, it has SOME heuristics, that is mostly
shoot-and-miss).
Brian, any Chance you could make a stacked 100% graph for every *week*
of the past two years?
We could then see where we are heading…
(or the raw numbers per week, so we could work with that).
That's probably a lot to ask, but I think it will show us how "fast"
the progression was (and will be).
We dumped 30 days because that gives a good snapshot of what's happening
right now. If we dumped for example the whole year, then it really blurs
the lines all over the place and things newer will be less prominent just
because they didn't have as much time. 30 days is how we typically bucket
> The raw numbers are a more reasonable picture.
Elliotte, this is just the begin of maven 4, and maven 4.x is not just for
current projects, but for projects in the next several years.(and I guess
nobody here wanna increasing jdk major version during a same maven major
version?)
So if we agree
This is all very interesting data for reasons that go well beyond Maven. Thanks!
My personal takeaway is that JDK 8 is a much bigger part of the market
than I would have guessed and Java 11 and Java 7 are both much less.
It looks to me like the Java world is dividing into two camps: The
"risk
Guess we interleave too much topics.
Do we agree on the starting point which is we must comply to the "default"
JDK users will get by design, ie the --release one?
If so then we should just cover +65% of the targetted JDK and use the
minimum as min requirement for end users, period.
If not then
Exactly!
When it all started, the "hurdle" to jump 8 > 11 was smaller, but
whoever jumped, was literally free after.
Today, as 11 is dead, the "hurdle" has been raised to 8 > 17, so whoever is
still waiting, is just piling up problems and more work for themselves.
T
On Thu, Feb 22, 2024 at
Actually as Trino solves a federation problem, we pull in a lot of
dependencies (over 800) and we spent a significant amount of time patching
and fixing upstream dependencies like Hadoop, Hive, Parquet etc to migrate
to JDK 17 when it was released, and lately to 21. Migration from 11 to 17
was
@Tamás Cservenák if you read carefully I never wrote
"all Java 21 projects are toy projects" ;). Eclipse is also not a topic, it
comes as a distro. Quarkus is still 17+21, trinodb is not something
primarly embedding code, it is more a standalone so more counter examples
from my understanding of
And one more remark regarding "toy projects":
You seriously mean that these numbers could be skewed by "toy projects"?
IMHO toy projects, while most probably represented here, are "lost, like
tears in the rain".
T
On Thu, Feb 22, 2024 at 10:39 AM Tamás Cservenák
wrote:
> >> lot of java 21 tody
So, my proposal would be:
* Maven build time requirement: "${current} LTS"
* Maven run time requirement: "${current - 1} LTS" (maybe ${current-2} but
i really see no point in that 3 LTS versions past 8).
Basically use Java LTS versions as stepping stones.
We could enforce this with parent POM:
>> lot of java 21 tody is still PoC or toy projects
Quarkus, TrinoDB or Eclipse are not toy projects. So they fact there ARE
"toy projects", you should not derive that "all Java 21 projects are toy
projects".
T
On Thu, Feb 22, 2024 at 10:32 AM Romain Manni-Bucau
wrote:
> [joke]this last
[joke]this last diagram looks like you are looking for piece[/]
I'm not sure the weight can be linear like that, it is not because you are
old that you will die - lot of java 21 tody is still PoC or toy projects so
should be in the weight somehow if we go this way.
Ultimately your user agent
For start I "normalized" the Java strings to a form like "Java 8" or "Java
17". This resulted in pretty much similar results as Romain PDF (Azul
report).
But then realized, we should consider this: Not every LTS existed at the
same time span (and we discuss the future here, not the past). Here is
Howdy,
Maven UA is created like this:
https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L555
I was hoping also for a list of "Apache Maven ..." lines with occurrence
count.
Now am unsure, for example
Do you have maven version and java version at the same time report? I
wonder if old maven is used with old JDK :)
On Wed, Feb 21, 2024 at 23:23 Brian Fox wrote:
> Hi everyone. I haven't caught up on this thread but Tamas pinged me to get
> some usage data from Central. Attached are the Maven
I added a piece of information: OpenJDK releases are currently pointed
to the vendor's binary address.
For example, OpenJDK17 Latest Release
(https://wiki.openjdk.org/display/JDKUpdates/JDK+17u), it points to
https://github.com/adoptium/temurin17-binaries/releases/tag/jdk-17.0.10%2B7
Tamás
Thanks for sharing!
On Wed, Feb 21, 2024 at 11:23 PM Brian Fox wrote:
> Hi everyone. I haven't caught up on this thread but Tamas pinged me to get
> some usage data from Central. Attached are the Maven versions and JDK
> Version counts as reported by User Agent by distinct IP for the last 30
>
Hi everyone. I haven't caught up on this thread but Tamas pinged me to get
some usage data from Central. Attached are the Maven versions and JDK
Version counts as reported by User Agent by distinct IP for the last 30
days:
On Wed, Feb 21, 2024 at 4:15 PM Hunter C Payne
wrote:
> I also want
I also want to stress that we care about what maven supports far more than
what it requires to build. If it needs JDK 17 to build but the jars are
compliant with Java 8, that's fine with me.
Hunter
On Wednesday, February 21, 2024 at 12:47:33 PM PST, Romain Manni-Bucau
wrote:
Hmm,
Romain,
1) please do not talk nonsense (about dropping toolchains), as this thread
is unrelated to it (and is not gonna happen)
2) your PDF... did you _read it_? Do you really expect volunteers to
support companies WHO PAY for Java8 (to some third party, like Azul) to
support their business for
Hmm, not sure im ready for a 200M vanilla build tool even if it would have
been ok legally...
Le mer. 21 févr. 2024 à 21:41, Hunter C Payne
a écrit :
> I might be wrong but I understood that shipping the JRE/JVM required a
> license and this is why most people don't ship with a JVM bundled.
I might be wrong but I understood that shipping the JRE/JVM required a license
and this is why most people don't ship with a JVM bundled. But perhaps that
has changed since the Oracle v Google/Alphabet trial.
Hunter
On Wednesday, February 21, 2024 at 12:00:54 PM PST, Benjamin Marwell
FWIW, bazel changed its runtime requirement to Java 21.
But they are shipping their own Java Runtime, so their users won't notice. [1]
I think they are the first build tool to do that.
I say this as a FYI fact only, not implying anything.
Make of it what you want.
- Ben
Am Di., 20. Feb. 2024
On Wed, Feb 21, 2024 at 7:40 AM Hervé Boutemy wrote:
>
> for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll have to
> update our plans https://maven.apache.org/developers/compatibility-plan.html
>
Not sure where this comes from. There's no one EOL date for any
version. It
n.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#executable
.
>
> From: Romain Manni-Bucau
> Sent: Wednesday, February 21, 2024 3:48:43 PM
> To: Maven Developers List
> Subject: Re: [DISCUSS] Java version for Maven
>
> Hi H
Le 2024-02-21 à 10 h 40, Xeno Amess a écrit :
I use toolchain for multi-release-jars please don't drop it or provide
another way for building multi release jars
I hope to make a proposal as a side-effect of a "Module Source
Hierarchy" proposal, when we will reach that point (after control
Hi.
I use toolchain for multi-release-jars
please don't drop it or provide another way for building multi release jars
From: Romain Manni-Bucau
Sent: Wednesday, February 21, 2024 3:48:43 PM
To: Maven Developers List
Subject: Re: [DISCUSS] Java version for Maven
Le mer. 21 févr. 2024 à 09:07, Hervé Boutemy a
écrit :
> ok, you want to contribute on decoupling JDK of Maven vs JDK of compiler
> and
> tests: perhaps we'll need to open a separate discussion to avoid hijacking
> the
> global plan, but let's have one roundtrip
>
Just to clarify: I don't want
ok, you want to contribute on decoupling JDK of Maven vs JDK of compiler and
tests: perhaps we'll need to open a separate discussion to avoid hijacking the
global plan, but let's have one roundtrip
scenario is: I use JDK 21 to run Maven, but I need JDK 8 to run my unit and
integration tests
of
I just wanted to note that it is not true that no one is using
toolchains, maybe maven devs don't do it ;-)
e.g. github java setup action supports toolchains:
https://github.com/actions/setup-java
and it was added because many users asked for it / requested it.
For me toolchains become
Hi Hervé,
+1000 on the philosophy!
On the toolchain support I still fail to see why maven has toolchain
anywhere in its code.
Look it how it is used:
* Tools are generally setup with env variables (JAVA_HOME, JAVA17_HOME,
JAVAEA_HOME or alike)
* Most plugins able to switch the JDK can switch the
for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll have to
update our plans https://maven.apache.org/developers/compatibility-plan.html
the approach I'd love to promote is "what do we require to not hurt our
diversity of users when upgrading minimum prerequisites" (and I'm
> So it IS about us, the volunteers.
> Is not about THEM, downstream users.
Not for me, for me and anything ASF is 100% about users and 0% about doers.
Anything not aligned on that should stay a personal github project for me.
> if they are stuck (due whatever policy or who knows what), they can
I think I mentioned it elsewhere but the fact that maven requires Java
to run is actually a (sometimes annoying) implementation detail, so if
maven would simply ship with a (stripped) JVM, being a native binary or
actually would probably resolve some problems in the area of java
discussions.
Its more about supporting an ancient JVM/JDK than compiling Maven on an
ancient version. So as long as Maven targets 8 or less in its build, I don't
think anyone cares (at least I don't) what the actual version of the JDK you
use in the build pipeline. Go ahead and have a source setting of
From your first paragraph I’d guess you would be on the “maven built on a
recent LTS java” side. I was wondering, given these omnipresent IDES, and
possibly from a philosophical perspective, what the arguments for “maven built
on an antique JVM” would be.
Thanks
David Jencks
> On Feb 20,
IDEs, including the 2 you named, have a configuration system for multiple
JDKs. This allows devs to build for multiple versions of the JVM. Likewise,
Maven has multiple ways to configure multiple JDKs for use by different phases
or plugins used in a given compilation setup and to target
I’ve been wondering for some time… My uninformed impression is that most
corporate development uses Eclipse or IntilliJ, which I believe run only on the
java version they come packaged with, which presumably is not usually the
target java version for the code being developed. Aside from
Romain,
you immediately revealed your WHY:
Take off your "paid dev" hat, and please try again.
We ARE an open source project.
So it IS about us, the volunteers.
Is not about THEM, downstream users.
As it was told a million times:
if they are stuck (due whatever policy or who knows what), they
> I am sure the majority of Maven users do not run Maven on the same Java
version they target with their build.
Do you use that and the following figures to do a biased conclusion?
"If people don't use the same version then we can higher the version"?
I think we need to consider two things:
*
Howdy,
I intentionally used "Maven" here, and not "Maven 4" as I am sure the
majority of Maven users do not run Maven on the same Java version they
target with their build. We do not do that either.
Some snippets from Herve (who is the ONLY one doing reproducible checks,
kudos for that) votes:
88 matches
Mail list logo
