Virtual threads are going to be great, but they're still limited (still starved the pool when used with 'synchronized' blocks), and they aren't the structured concurrency power houses like kotlin coroutines, but its an invaluable tool that will only continue to accelerate as the ecosystem moves to adopt them.<p>Expect a lot of libraries to start release versions that are java 21 baseline because of this feature alone. We're in for a little bit of dependency hell for the short while. Thankfully, devs have been exposed to a mostly final loom for a year, so my hope is that at least the big projects are well on their way to quick adoptions.<p>Unlike the 8->11 migration which largely brought pain, the 8->21 release brings with it a ton of value that i think will encourage most shops to actually pull the trigger and finally abandon 8.
Java getting better pattern matching is a great change. Id really like more of the functional features to make it into Java.<p>I would love if Java pattern matching could at least get to the level of ruby pattern matching. Ruby pattern matching will allow you to deconstruct arrays and hashes to get pretty complicated patterns, which is really powerful. Right now it seems like Java might have that with a lambda in the pattern, but its not going to be as elegant as ruby where:<p>case {name: 'John', friends: [{name: 'Jane'}, {name: 'Rajesh'}]}
in name:, friends: [{name: first_friend}, *]
"matched: #{first_friend}"
else
"not matched"
end
#=> "matched: Jane"<p>But the big change here is virtual threads which should be a game changer.
We have 2.1 million LOC in Java and we're moving to Java 21 (from 17) in two weeks when we branch for release.<p>We have a hundreds of third party dependencies across the code base, a lot of the big ones (Hibernate, Spring, a lot of Apache). We write a big web application and maintain a big legacy desktop application in Swing.<p>We run a dedicated nightly CI job that is on the latest Java release to get early warning for any incompatibilities. After the painful migration from 8 to 9 so many years ago it has been smooth sailing.<p>In all those version upgrades over all those years and dozens of on premise installations with big customers we have never had a regression or a problem that was caused by the runtime itself.
(1) It's a bit of a bad smell (which he points out) that records aren't being used much at all in the Java stdlib, I wrote something that built out stubs for the 17 and 18 stdlibs and that stood out like a sore thumb. I do like using records though.<p>(2) I've looked at other ways to extend the collections API and related things, see<p><a href="https://github.com/paulhoule/pidove">https://github.com/paulhoule/pidove</a><p>and I think the sequenced collections could have been done better.<p>(3) Virtual Threads are kinda cool but overrated. Real Threads in Java are already one of the wonders of the web and perform really well for most applications. The cases where Virtual Threads are really a win will be unusual but probably important for somebody. It's a good thing it sticks to the threads API as well as it did because I know in the next five years I'm going to find some case where somebody used Virtual Threads because they thought it was cool and I'll have to switch to Real Threads but won't have a hard time doing so.
The examples having to word wrap in a tiny text box look even more absurd and unreadable when the page is only using 1/3rd of the screen.<p>What is with this awful formatting? <a href="https://i.imgur.com/nQmt7Qo.png" rel="nofollow noreferrer">https://i.imgur.com/nQmt7Qo.png</a>
> Miscellaneous new methods -- meh<p>Dunno, several of these are tangible QoL boosts:<p>Math.clamp(), List.reversed(), List.addFirst(), List.addLast(), Character.isEmoji()
If you're viewing that website on a desktop, I strongly suggest removing max-width: 90ch from the body css. Instead of 50% white space, it goes full width and makes the table substantially more readable (particularly the code samples).
Can anyone explain this comment: "In the past, a thread pool didn't just throttle the incoming requests but also the concurrent resources that your app consumed. If you now accept many more incoming requests, you may need other ways to manage resource consumption."
In the code example for virtual threads, I have no idea what will happen in parallel.<p>How do I reason about the order in which the calls change the state of the world?
I love pattern matching, but without a proper support for variant types it won't be as useful as it could.<p>I'm aware of `permits` clause, but it's not good enough.
I am looking for assembly implemented JVMs (x86_64/risc-v/etc), that to remove SDK pressure and give stable auditability of machine code.<p>Do those exist?
It sounds like it has some neat new features. But I'll never know because I'm never again going to use another Oracle thing. There's not a thing they could make that's good enough for me to agree to one of their EULAs and install it. Their behavior in that area is just staggeringly bad.
> Over 10,000 bug fixes<p>Most of which were likely introduced during new feature development in recent releases. To suggest that this on its own somehow manifests a more stable jdk compared to some ancient, battle tested version of the jdk is debatable.<p>I find it rather concerning that so many bugs exist to begin with. Why are these not caught sooner?<p>Has the whole world gone crazy? Am I the only one around here who gives a shit about quality? Mark it zero!