Java 21: The Nice, the Meh, and the Momentous

[adra]

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.

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.

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.

[pron]

Structured concurrency in JDK 21 is not only a powerful and flexible library feature, but one that is built deep into the runtime in a way that allows observability into the relationships among threads: https://openjdk.org/jeps/453

[brabel]

> Expect a lot of libraries to start release versions that are java 21 baseline because of this feature alone.

Java has had multi-version jars since 11 I think... that allows library authors to ship code that benefits from new features in newer versions of the JDK while still supporting older ones as well. Hopefully library authors can leverage that, though I'm aware something like Virtual Threads may be very difficult to design around for older versions.

[tantamounta]

With the API being nearly the same, I keep just thinking that Virtual Threads are basically identical to Platform Threads except that they use far less memory (so you can have lots more of them).

Are there any other actual differences? Better Peformance?

[skwirl]

Do you have to baseline on Java 21 if you want to add support for virtual threads? Couldn't you continue using heavyweight threads on older versions of Java? My understanding is that both use the same Thread abstraction.

[larperdoodle]

Why haven't places updated already? It's not that much work to update. Where I work we always go to the new LTS version as soon as it's supported by gradle.

Doesn't cross anyone's mind to _not_ upgrade.

[krzyk]

You forgot about 8->17 which ads really nice language features, records alone are greatest feature after lambdas.

And 21 brings patterns in switch and records.

[ecshafer]

Java getting better pattern matching is a great change. Id really like more of the functional features to make it into Java.

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:

case {name: 'John', friends: [{name: 'Jane'}, {name: 'Rajesh'}]} in name:, friends: [{name: first_friend}, *] "matched: #{first_friend}" else "not matched" end #=> "matched: Jane"

But the big change here is virtual threads which should be a game changer.

[brightball]

Simple solution: JRuby.

Virtual threads are going to make Ruby fibers work properly for JRuby so that’s going to be huge as well.

Charles Nutter gave an update in August. 45 minute mark he talks about virtual threads.

https://youtu.be/pzm6I4liJlg?si=vKVICrola4OmJIal

[munificent]

We recently added pattern matching to Dart [1], so I'm always keen to see how it compares to similar features in other languages. In case it's interesting, here's that Ruby example ported to Dart:

    print(switch ({'name': 'John', 'friends': [{'name': 'Jane'}, {'name': 'Rajesh'}]}) {
      {'friends': [{'name': var firstFriend}, ...]} => "matched: $firstFriend",
      _ => "not matched"
    });

Pretty similar! The main differences are that Dart doesn't have symbols, so the keys are string literals instead. Also, variable bindings in patterns are explicit (using "var") here to disambiguate them from named constant patterns.

[1]: https://medium.com/dartlang/announcing-dart-3-53f065a10635

[unregistereddev]

Pattern matching is a neat tool to keep in the toolbox. When it's the right tool for the job, it is really cool and is a lot cleaner than a bunch of conditional checks. However, I rarely reach for it. Maybe my use cases are unusual? I am genuinely curious how often other developers find pattern matching to be the best tool for the job.

[frou_dh]

I really like that Ruby throws NoMatchingPatternError if none of the patterns match. It's a bit like the much-acclaimed exhaustive pattern matching in static languages (though at runtime rather than compile-time, obviously) and better than just silently falling off the end, which IIRC is what Python's pattern matching does.

[aggregat]

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.

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.

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.

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.

[PaulHoule]

(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.

(2) I've looked at other ways to extend the collections API and related things, see

https://github.com/paulhoule/pidove

and I think the sequenced collections could have been done better.

(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.

[twic]

I think the biggest impact of virtual threads is that the ecosystem will abandon asynchronous APIs. No more futures, callbacks, servers where you have to make sure not to block the thread, reactive frameworks, etc. Just nice simple imperative blocking code. Nima is the first example i've seen:

https://helidon.io/nima

We've had two production bugs in the last two weeks caused by handlers blocking the server thread in apps using an async web framework, which would simply not have happened with a synchronous server.

[papercrane]

I suspect if we had records from the start they'd be all over the stdlib, but because of backwards compatibility they'll likely only be considered for new APIs.

[zmmmmm]

I think virtual threads are huge.

The problem with regular threads is (a) multi-kb memory stack per thread and (b) consuming a file handle.

Either of those severely limits the scalability of the most "natural" parallelism constructs in Java (perhaps generally). Whole classes of application can now just be built "naturally" where previously there were whole libraries to support it (actors, rxJava, etc etc).

It make take a while for people to change their habits, but this could be quite pervasive in how it changes programming in general in all JVM languages.

[yankput]

Virtual threads are strictly better than normal threads, no? I am thinking of any reason to still use traditional threads. Is there any downside?

[Vicinity9635]

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.

What is with this awful formatting? https://i.imgur.com/nQmt7Qo.png

[BrianKamrany]

It is easier to read something that is page-sized, as opposed to taking up the full screen. Although it does look weird.

[marginalia_nu]

> Miscellaneous new methods -- meh

Dunno, several of these are tangible QoL boosts:

Math.clamp(), List.reversed(), List.addFirst(), List.addLast(), Character.isEmoji()

[winrid]

So I can reverse a list without using "streams" now? Thank heavens

[bcrosby95]

> List.reversed(), List.addFirst(), List.addLast()

These fall under sequenced collections, not "miscellaneous new methods".

[hinkley]

What's the Scala community think about this development? I would think this would affect them quite a lot.

Google is not helping.

[rr808]

Scala community always thinks they're the best tool. The size of the community is at best static though, Kotlin and re-energized Java took away most of the reasons for using it. I know in my company the teams that went the Scala route complain of huge compile times and really struggle to find people, I think we'll probably port back to Java.

[dionian]

It's great, but irrelevant since Scala is already so far ahead. I will start to care if i am ever forced to do java again. I love how much better Java is getting! Most of these things we have had in scala for a long time already, and much better versions.

[discodachshund]

The Typelevel folks on Discord are of the opinion it's not of much interest to them

[Someone1234]

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).

[munk-a]

Hilariously enough I was initially confused by this comment because the webpage rendered so readably for me - the base CSS is actually quite reasonable and because I have JS disabled by default the page never re-rendered into the thinner mode.

[pacoverdi]

I viewed it on Firefox for Android and I immediately had to jump to reader mode for the same reason.

But I tend to use reader mode on most sites anyway because it's an easy way to get rid of banners (cookies, subscription etc.)

[anonymousDan]

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."

[yCombLinks]

Yeah, if your server maxed out at 256 system threads you didn't have to worry about the fact that 1024 simultaneous calls would crash your DB. But now you're not limited by system threads

[mrkeen]

In the code example for virtual threads, I have no idea what will happen in parallel.

How do I reason about the order in which the calls change the state of the world?

[Jtsummers]

That's all sequential code, it would be run inside a single "virtual thread". Note that the async code on the right is also sequential, just structured through an async API.

[logicchains]

Does anyone know if Java virtual threads will also have channels and a select concept, like in Go?

[kaba0]

Java already has many more concurrent and parallel data structures, so while it likely won’t have a keyword, it can definitely do it already.

[aardvark179]

I think at some point yes. We certainly discussed it but it’s one of those things that takes time to really get right and performant.

[shaunxcode]

Just spit balling but you should be able to use clojure core async channels and the blocking put/take/alts functions. Would probably take a small amount of work to expose those things to Java in an idiomatic way but should be doable. Please take all of that with a giant grain of salt though!

[ivanjermakov]

I love pattern matching, but without a proper support for variant types it won't be as useful as it could.

I'm aware of `permits` clause, but it's not good enough.

[sylware]

I am looking for assembly implemented JVMs (x86_64/risc-v/etc), that to remove SDK pressure and give stable auditability of machine code.

Do those exist?

[bullen]

So it's just Thread.startVirtualThread(runnable); that's it?

Going to be interesting!

[billfruit]

Does it add stdint style names for integer types, unsigned integer types etc?

[layer8]

The size of the integer types are already fixed by the JVM specification (int is always 32 bits, etc.), and there are no unsigned integer types in Java except for char (a 16-bit unsigned integer type). Furthermore, Java does not support alias names for types. Hence it’s unclear what your question is aiming at.

[szatkus]

AFAIK Java 8 added a few methods that helps you handle integers as if they were unsigned, like `toUnsignedString`. I think it's enough for any exotic cases.

[hoistbypetard]

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.

[matt_heimer]

Then use Java without agreeing to an Oracle EULA. You can get a GPLv2 open source build from https://jdk.java.net/21/

If you don't trust the Oracle based open source builds then just wait a bit for Microsoft, Redhat, and others to release their version 21 OpenJDK builds that will be found under https://adoptium.net/marketplace/

[kaba0]

Not this bullshit again.

[baq]

  > "Hello, World!".splitWithDelimiters
  >      ("\\pP\\s\*", -1)
  >  // ["Hello", ", ", "World", "!", ""]

> Meh

My brain just melted.

[hinkley]

I'd have a lot of uses for that. But also worry about it enabling more stringly-typed code.

[waynesonfire]

> Over 10,000 bug fixes

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.

I find it rather concerning that so many bugs exist to begin with. Why are these not caught sooner?

Has the whole world gone crazy? Am I the only one around here who gives a shit about quality? Mark it zero!

[specialist]

Randomly looking at bugs fixed the last 10 weeks, it seems like a healthy mix of old and new bugs.

https://bugs.openjdk.org/browse/JDK-8316305?filter=-7&jql=pr...

Being allergic to JIRA, my JIRA-fu is weak, so there's probably an easier/faster way to report bugs fixed in v21.

Any way.

> Am I the only one around here who gives a shit about quality?

Ages ago, I was a QA/Test manager. So I appreciate your sentiment. But it seems to me that Oracle's being a FANTASTIC shepherd of Java. Definitely a huge upgrade, at the very least.

[pron]

While you're right that the number of bugs is not very meaningful and most are probably work on brand new features, but bugs in old features are always first fixed in the current version, and then only a subset of them (usually a small subset) is backported to old releases, and regressions are not common.

As to why some bugs go unnoticed for long, if you look at the bug database for reports of bugs that have been effect for a long while you'll see that these are almost always rather extreme corner cases (or, more precisely, the more utilised a mechanism is, the more extreme would be its old bugs). That's simply because full coverage is simply infeasible for software of such size (~8MLOC); you see similar bug numbers for the Linux kernel. The largest software that can be shown to be free of bugs is currently on the order of 10KLOC, so if your software is much larger than that and isn't getting many bug reports it's probably because it's not used that much.

[doodpants]

You might be the only person in the world who writes bug-free code on the first try.

[rr808]

Java has been around for nearly 30 years, I'd hope the core libraries had very few bugs by now.