Hi,
greatly summarized.
Thank you for that.
Kind regards
Karl Heinz Marbaise
On 24.05.25 19:21, Michael Bien wrote:
On 5/24/25 15:33, Elliotte Rusty Harold wrote:
On Sat, May 24, 2025 at 1:16 PM Tamás Cservenák <ta...@cservenak.net> wrote:
... aaand because some company/ies does/do that,
we as an open source project/forget need/must stick to it?
The claim that we must move our JDK version forward because Java
8/11/17 is not supported is fallacious. It is based on a false
premise.
If you want to upgrade the minimum Java version, you need a better
reason than that. I haven't yet heard a reason strong enough to
convince me. Others have other opinions.
I would be curious what the strategy would have been if maven 4 would have
decided to stay on JDK 8.
Wait till 2030 and then throw maven away and build something new? Do one big
jump from 8 to 2x
and hope the community would accept it? Hope that vendors would keep supporting
some slightly newer
JDK versions beyond 2030 to get a few extra years out of it?
If vendors would not stop supporting JDKs, maven would have 7 JDK versions to
support in 2030 - this is
quite a test matrix (not to mention the wasted resources).
Trying to keep the delta between 'min' and 'current' constant sounds like the
pragmatic approach for
projects which plan to stick around. In fact many did and introduced some easy
to remember, forward
looking rule like "our latest major version supports 2 LTS + current".
The crazy part about this discussion to me is that maven already has a solution
for this.
Maven 3 exists, runs on JDK 8 and is supported as long as the community wants
to support it.
Maven 4 could even do a RC more and be JDK 25+ without influencing anyone on
JDK 8.
So basically, all we did so far was "waste of resources"
as Java 8 is there to stay, at least until 2030, right?
IMHO, yes. I would much rather people invested their time into fixing
Maven bugs and improving the health of the codebase rather than
continuously migrating code from one Java version to the next.
Bugfixes and refactoring are luckily not mutually exclusive and are just
regular project maintenance
tasks.
The cumulative time spent writing JDK version discussion mails is probably
already more than the
review of a fictional global JDK 17->21 migration PR would take. (that is
another reason why many
projects came up with an easy to remember min-version rule rather than having
to repeat this
kind of threads every few years)
There is also no time pressure behind language level cleanups. They can (and
often should) happen
incrementally, as needed, without disrupting any other tasks. The point in time
when the min
requirements are bumped is only the starting point which unlocks more cleanup
options - the rest
follows organically.
That's
life with a volunteer project though. Developers are going to do what
they find fun rather than delivering user value.
no fun allowed while producing value ;)
I could flip the argument and say that trying to reduce aspects which are
generally perceived as not-fun,
probably creates value for everyone over the long term, including users. Esp in
open source projects
which rely on motivated developers spending some of their free time (or
carefully negotiated work-time)
helping to maintain it.
what lucky situation to be in when developers perceive modern APIs / language
idioms / cleaner code as
more fun :)
(btw: is it ok to use vote threads for discussions?)
best regards,
-mbien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org