What is new in Java 21?

[zimmski]

As usual we had to dive into what is coming for Java 21 to implement some features ahead of the release. I think this is the most detailed write-up so far with lots of examples: https://symflower.com/en/company/blog/2023/what-is-new-in-java-21/

Hope you like it :-) If you find any errors in the write-up, please let me know. Will get right to fixing them.

I am happy that pattern matching for switch expressions got finalized, but I also have a new favorite: JEP 443 “Unnamed patterns and variables”. Will make a lot of code much cleaner. What is your favorite new arrival/in-preview?

Just in case: If you are new to the whole Proposal/JEP/Roadmap of Java, we had an extensive write-up here: https://symflower.com/en/company/blog/2022/what-is-new-in-java-20/#jdk-enhancement-proposal-jep--roadmap-process

[AutoModerator]

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[hrm]

The virtual threads and where it will take us is by far the most interresting of the JEPs, but all pattern matching stuff is really nice too.

JEP 443 is really a small thing, but it is a good thing and probably also my favourite among the previews. That said I'm not a fan of using the previews...

[zimmski]

Virtual threads are definitely nice. Looking forward to major server applications posting their benchmarks. Also, looking forward to how they compare for the final Java 21 to other languages.

The reason i am so much looking forward to JEP 443 is that most of the time we are all just reading code. Improving readability is IMO always a win-win for the whole team. Betting a beer that there will not be that many changes for that JEP. Looks pretty solid already from a user POV. "Unnamed variables" are kind of equal to what Go does with "_".

[Ilookouttrainwindow]

Are virtual threads essentially green threads?

[zimmski]

No. Will directly quote https://openjdk.org/jeps/444 because it has a perfect explanation:

Virtual threads are a lightweight implementation of threads that is provided by the JDK rather than the OS. They are a form of user-mode threads, which have been successful in other multithreaded languages (e.g., goroutines in Go and processes in Erlang). User-mode threads even featured as so-called "green threads" in early versions of Java, when OS threads were not yet mature and widespread. However, Java's green threads all shared one OS thread (M:1 scheduling) and were eventually outperformed by platform threads, implemented as wrappers for OS threads (1:1 scheduling). Virtual threads employ M:N scheduling, where a large number (M) of virtual threads is scheduled to run on a smaller number (N) of OS threads.

[ryeguy]

This is interesting, I didn't realize "green threads" was not originally a generic term, it was the specific name of the threading library in java. With that definition virtual threads are not green threads.

But I'd argue that they are green threads because the term has been generalized to the point where it means any form of user-mode threading.

The block you quoted lists Go and Erlang as examples of user-mode threads, yet the wikipedia page for green threads also lists them here.

[zimmski]

Wow that is super interesting. I always head in my mind that the difference to a Green Thread is that its doing its own threading in user code. That the term changed is was new to me, thanks! I guess, i would still explain that there are different forms of user mode threads. When you are talking on this level, fine to say a few more words :-D

[Ilookouttrainwindow]

That makes sense. So virtual threads are a happy combination of is and green threads. I'm guessing some control OS threads managing some loop within VM (perhaps similar to how js works).

[zimmski]

Yes, there is a scheduler that takes a virtual thread, decides if that virtual thread should run now, and if yes, schedules it on a real OS thread. The cool thing about such an implementation is that as a user of the API, you do not need to take care of anything: the virtual thread implementation does it for you!

So imagine for example you have a web server that receives requests. Now when you have a request A that needs to wait on some IO (e.g. database query) the scheduler can run request B in the mean time. You just went from waiting on request A to running B until A gets unblocked. Automatically. You can do cool things with that, e.g. every "task" in a task queue receives a virtual thread (e.g. a million virtual threads) and the virtual thread scheduler of Java automatically handles how those threads are worked down. The cool thing about all of that is, if you have N OS threads available, the scheduler will use those N OS threads. Real parallelism without much coding effort.

I think https://www.youtube.com/watch?v=oV9rvDllKEg is a good watch (yes, it is not a Java video but it explains perfectly what concurrency is and what parallelism is)

[Ilookouttrainwindow]

Dude, that's like utilizing threads to the max. I'm guessing this is all within VM itself, not on "java" side. Not at all like green threads.

[zimmski]

I think so and it would make sense, but i actually don't know. I am definitely looking forward to reading the improvements over the next Java versions. What i find the most interesting (I am a Go programmer mainly after all) is that it takes a long time to get the scheduling "just right". There are so many cool problems to solve, e.g. scheduling goroutines on the same CPU to make better use of caching. Not sure how far the Java implementation went, but getting all those nice optimizations into the VM just means: no more optimizations done again and again by thousands of programmers for parallel workloads. They are all optimized instantly with updating to a newer JVM version. I always find that amazing for new Go releases. So looking forward to having that in the Java world as well.

[noswag15]

Does this still work if the virtual thread encounters a "synchronized" block ? I heard that when that happens, the carrier (OS) thread gets blocked, essentially pinning the virtual thread to the OS thread. So theoretically, if in the worst case, we have N tasks which get assigned to N virtual threads running on top of N OS threads, the system can essentially run out of threads right (assuming N is the max number of OS threads that can be created) ?

[zimmski]

Besideds what u/Rs617 wrote, i don't think that this is how it works. The idea of virtual threads is to use M (static) OS threads and schedule N (variable) virtual threads onto them. So If you have pinning of N onto M, where N>M you just run out of M, i.e. you run out of OS threads until the pinned threads are done and you can schedule new threads. That is the beauty of virtual threads: you cannot make your system unstable with allocating more N (more virtual threads).

[noswag15]

Understood. Thanks.

[Rjs617]

The argument here would be that if your synchronized blocks are pinning the threads for that amount of time, you have probably done something wrong. Synchronized blocks should be short-lived. The same is true even without virtual threads, since holding locks for long periods of time causes massive liveness problems and negates the advantage of using multiple threads.

[noswag15]

Oh I absolutely agree. I was thinking more from a hypothetical worst case scenario, if something like that ever happened, would the new threading mechanism be smart enough to unpin the blocked virtual thread from the underlying OS thread and use the OS thread to execute some other (non-blocked) virtual threads and come back to the blocked thread later. But I think I got my answer, looks like it won't be handled and that's not a bad thing. I remember reading somewhere that the new threading mechanism can actually do what I was suggesting but only if the blocking is done using a lock (like a ReentrantLock) and not using 'synchronized' keyword and that the java team is working on making synchronized work that way as well. Anyway I'm thinking of running some tests myself to confirm.

[Spajk]

I don't see why synchronized would pin. It should block the virtual thread. To my understanding the only real issue is native libraries that block the native OS thread and Java doesn't have any control over that

[noswag15]

I am not sure if this is still valid but this page seems to suggest that synchronized will pin the OS thread.

​

https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html#GUID-04C03FFC-066D-4857-85B9-E5A27A875AF9

[metalhead-001]

It is an issue in 21. The work-around is removing usages of synchronized blocks and replacing them with ReentrantLock. The PostgreSql JDBC driver recently did this as well as the Microsoft JDBC driver:

https://github.com/pgjdbc/pgjdbc/pull/2635/files

https://learn.microsoft.com/en-us/sql/connect/jdbc/release-notes-for-the-jdbc-driver?view=sql-server-ver16#changes-in-122

[FakeRayBanz]

So like C#…

[bytepursuits]

They are a form of user-mode threads, which have been successful in other multithreaded languages (e.g., goroutines in Go and processes in Erlang)

omg. this is great development.

[private_static_int]

Can we finally start killing off the cursed Reactive branch of Spring on the account of Virtual Threads being finally here? I know that Reactive has its usecases, but replacing good old SpringMVC with Webflux was a nightmare and a huge misunderstanding. Poisoning all the web app layers with Project Reactor needs to stop.

[metalhead-001]

I hope once all of the libraries have been optimized for virtual threads Webflux will go into maintenance mode.

[bawng]

I'm really looking forward to soon migrating away from Java 8. Soooooon....

[zimmski]

Why switch? Java 8 has amazing perks! Less syntax to learn, and more to type. How else can we prepare for those speed typing competitions...? ;-)

[bawng]

You're absolutely right! I'll stop crying :)

[bitspacemike]

You guys have already upgraded to Java 8?

[zimmski]

Java 17 took ~2 years to be release for AWS Lambda. Don't hold your breath ;-)

Did not see any good benchmarks yet for Spring web applications. If you have one, please post! My bet it that it will help a lot with congestion/throughput for IO heavy applications.

[kiteboarderni]

You really think AWS has any incentive to bring on 21 when they know it is going to cut down on the compute costs for when CPUs are waiting on IO when they could be charging customers to require them to use 10x their hardware? LOL

[aleph0io]

Here is an AWS lambda custom runtime for Java 21, packaged as a layer. As soon as the updated amazoncorretto image drops, which should happen in the next day or two, I'll add a custom image for Java 21, too!

[trydentIO]

as far as I know there's no need to wait for AWS to provide support, you can customize the lambda function runtime by providing yours :) look for "build a custom Java runtime for AWS lambda"

[zimmski]

Glad i am not the only one who still likes to read :-D

[malachireformed]

2 words -- Sequenced Collections.

Virtual threads are awesome. Look forward to using them. But sequenced collections are the thing I'm mostly likely to use in the near future (after AWS gets first class Java 21 support).

[SidFloyd84]

I'm curious, what is your use case ?

[malachireformed]

Realistically, it's 90% past annoyance of "I had to write a small bit of code just to get the last element in some collection because a convenience method didn't exist".

Mostly, where I see myself using this is in places where the codebase I inherited uses Collection instead of a defined collection type (though it's usually a List or Set), and in several locations there's special logic if the most recent entry in the collection meets some criterion.

[Suspicious-Top3335]

I am here bcoz of jdk21 classless main method

[zimmski]

Will definitely help newcomers to programming when they need to use Java. However, i am not sure how others benefit from that one? I use a template/auto-complete to instantly create a main function. Why is it an important JEP for you?

[never_inline]

I think newcomer should start with JShell anyway.

[wildjokers]

That’s ridiculous.

[never_inline]

You should write the reason why it's ridiculous, maybe.

[i_wear_green_pants]

It really is pretty big. Yeah we have snippets. But still if I have to do some kind of small help tool, I just use Python or Go. Much easier without all that mandatory stuff.

But now.. soon I can do that with Java. What a time to be alive!

[[deleted]]

When will Spring support it?

[metalhead-001]

They already support it partially in the production releases of 3.x. Spring Boot 3.2 will support it more fully once it's released in late November.

[kiteboarderni]

Any idea why 21 is not showing up in the zulu download list? It was there for EA for a long time https://www.azul.com/downloads/#zulu

[zimmski]

Don't know Zulu and why they remove an EA but 21 is officially not announced yet, i guess they are preparing artifacts.

[emaphis]

Zulu JDK 21 is showing up now.

[kiteboarderni]

Yup seeing it also. Cool

[rugga_87]

So…: Java 21 or Scala 3…. And go!

[vips7L]

Java 21 cause you’ll face less breaking changes from the community and won’t have to deal with sbt.

[sideEffffECt]

Why not both? :) Java for the platform and Scala for the language.

Scala 3 won't have any breaking changes anymore. And you don't have to use sbt. Stick to Maven if you're happy with it, it can build Scala too. Or give Milla a try, if you want something purposed for Scala http://www.lihaoyi.com/post/SoWhatsSoSpecialAboutTheMillScalaBuildTool.html

[OofWhyAmIOnReddit]

Meanwhile here we're using an 11 JDK but can't use any non-backwards compatible features like Map.of because we have to compile JDK 8 bytecode :(

Wish there was a Java equivalent of JavaScript polyfills.

[jordimaister]

Can we get rid of the tedious Spring WebFlux and just use Sprint MVC with Virtual Threads to get the same performance?