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 level 9.
A whole category of String related optimizations unlocks simply by
recompiling something with --release 11 or later. Running on a more
modern JVM without the bytecode level bump, won't help in that case.
There are also hundreds of behind the scenes optimizations which are
unlocked for free just by using new API. For example stream.transferTo()
is going to be not only more convenient and less error prone, but also
likely more efficient than the dozens of stream copy variations which
show up in projects (why? because it takes into account what exact
streams/channels etc are involved). If you see a new method in the JDK:
there is probably a reason why it was introduced.
That being said: in discussions like this, focusing on individual
features is often not helpful. Since the next post will be likely about
"I don't care about 1-10% faster/more memory efficient String
concatenation in my CI build since at my current gig we get CI for free
due to the geothermal power plant in the backyard".
From a birds eye view projects fall into two categories:
a) short living projects which die on JDK X within the lifespan of JDK
X. This is a completely valid strategy since it is often known that
something is going to be rewritten from scratch, not needed anymore or
replaced at some point in future.
b) long living projects which will have to upgrade, since projects
don't exist in a vacuum. The environment moves on, JDK X compatible
dependencies which still get security updates will disappear at some
point etc etc.
I would assume that it is not controversial to call maven a long living
project. So this discussion here should be about: when is the best time
to bump the JDK version - I would argue that maven 4 is pretty good timing!
If you want maven on JDK 8 till 2030+, I would be curious about two things:
- why can't you use maven 3.x?
- what exactly *should* happen after 2030+? Should maven die (is mvn
category a) after all?)? Should there be a jump from 8 to JDK 3x and the
community should deal with all the piled up problems all at once? Why is
delaying this event the better strategy when compared to incremental
steps? What is the JDK 8 exit strategy?
best regards,
-mbien
