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
[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
>> 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
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:
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
> 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
Howdy,
Note: This is a seventh (alpha-4 was scrubbed) preview release of Resolver
2.0.0, that would allow any downstream consumers to try it out and adapt.
The supplier is aligned with Maven 4.0.0-alpha-12.
For configuration changes, see
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
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
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).
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
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
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
@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
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
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
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
19 matches
Mail list logo
