One aspect of virtual threads that has gone somewhat unappreciated so far is that if you (ab)use some internal APIs you can probably implement the testing technique used by FoundationDB.
For those who don't know, FoundationDB is a horizontally scalable transactional (KV) database used by Apple for their cloud services. It's famous primarily for its testing approach in which they can run the entire set of microservices in a simulator that can both inject faults, but also completely control the scheduling of work. In this way they make the system entirely deterministic, and can then pseudo-randomize simulations to uncover race conditions and the like.
To do this they created a custom DSL on top of C++ called Flow which is compiled to coroutines.
Flow and what it enables is considered (by them at least) to be a key competitive advantage over other database engines.
With Loom the JVM now happens to support the very same thing, just not officially. That's because the JVM makes file and network IO fully "pluggable", virtual threads can be supplied with a custom scheduler, and classloaders can be used to run multiple programs within the same JVM (with some caveats). So if you wanted to make a deterministic simulation of your microservice based system then you could do that now.
The above would be a rather advanced project for intrepid developers only, but it'd be interesting to see someone explore that at some point.
Excellent! With virtual threads, all the blocking code I wrote is efficient now :)
Less-joking: I'm so excited for this to start getting adoption. For a pre-release/preview feature, Loom already has SO much traction, with most major frameworks already having support for running app/user code on virtual threads and one notable project (Helidon Nima) replacing netty with their own solution based on blocking IO and virtual threads. Now I want to see the community run with it.
I've always thought async IO was just plain gross.
Python's implementation is so yucky that after using it for one project I decided that I'd rather DIY it with multiprocessing than use async again. (I don't have any more constructive feedback than that, my apologies, it was a while ago so I don't remember the specifics but what has lasted is the sour taste of the sum of all the problems we had with it - perhaps notably that only about 2 people on my dev team of 5 actually understood the async paradigm).
netty did it fine. I've built multiple projects on top of netty and it's fine. I like event-based-async more than async-await-based-async. But it's still a headache and notably I really rather missed the kinds of guarantees you can get (in blocking code) by wrapping the block in try-catch-finally (to e.g. guarantee resources get freed or that two counters, say a requests-in and a requests-out, are guaranteed to match up).
But dang am I excited to not do that anymore. I have one specific project that I'm planning to port from async to blocking+virtualthreads that I expect to greatly simplify the code. It has a lot of requests it makes back and forth (it has to manually resolve DNS queries among other things) so there's good chunks of 50-200 ms where I have to either yield (and has gross async code that yields and resumes all the heck over the place) or block the thread for human-noticeable chunks of time (also very gross of course!).
Funny I think async in Python is a lot of fun for side projects but my experience is that if I hand my Python systems off to other people they usually have trouble deploying them and invariably can’t maintain them.
Whereas my Java projects live on long after I am gone from the project.
Personally I love aiohttp web servers, particularly when using web sockets and brokering events from message queues and stuff like that. Not to mention doing cool stuff with coroutines and hacking the event queue (like what do you do if your GUI framework also has an event queue?) If YOShInOn (my smart RSS reader + intelligent agent) were going to become open source though I might just need to switch to Flask which would be less fun.
Fully agree on Helidon Nima and blocking IO. Zero hope that Spring framework crapola will not smother already massively simplified thing with convenient abstractions on top it.
Can you explain why you're excited about with virtual threads? I get that they improve throughput in extremely high pressure apps, but the JVM's current threading isn't exactly a slouch. Java's used in HFT shops, and more generally in fintech where performance matters.
Sadly, no-one has managed to package it yet, but we should get something in the next couple of days. Since 21 is an "LTS" release, major Linux distributions will provide a runtime pretty soon. Ubuntu backports them to old releases too.
Just to be clear, all of these sites offer builds of Oracle software (the OpenJDK JDK), developed by Oracle and licensed by Oracle. When you file an issue that's in the JDK, those companies forward it to us, Oracle engineers, to fix.
Oracle is responsible for 95+% of every single commit going to OpenJDK, which has the exact same license and situation as the goddamn linux kernel, GPL2. Do you also sweat a lot about accidentally installing red hat linux? If not, you have zero reason to worry.
How is amazon compiling and repackaging the exact same thing somehow different?
Yeah the lack of anyone packaging this up was kinda weird to me. I understand these are done on someone else's dime, and no one owes me a free lunch though.
I don't really pay a lot of attention to Java releases but I was actually excited about this one. No one ran a build process last night in anticipation?
As much as I want to clown a little on the language for taking so long to do string templates, congratulations on getting virtual threads shipped, I can't imagine the effort that must've took to implement into something as hairy and complex as the JVM!
I have a genuine question about Loom / virtual threads / etc.
In languages with async-await syntax, I like that it is explicit what is sync and what is async. I also like how the "bind" points within an async expression make it clear where the syncronization happens. It seems to me that Java 21 makes all of this implicit, which is a step backward in this respect.
Similar to how types enforce valid usage (a foundational idea in Java), I feel that an Async<T> should not be implicitly a T.
Finally virtual threads I can use in production with generational ZGC! I've been using Kotlin coroutines for a while now, and want to see how that evolves with JVM now supporting virtual threads out of box.
Oracle managed to create one of the least ergonomic string interpolation syntaxes of any language I've ever seen. Using backslashes is truly a terrible move
C# $"{x} plus {y} equals {x + y}"
Visual Basic $"{x} plus {y} equals {x + y}"
Python f"{x} plus {y} equals {x + y}"
Scala s"$x plus $y equals ${x + y}"
Groovy "$x plus $y equals ${x + y}"
Kotlin "$x plus $y equals ${x + y}"
JavaScript `${x} plus ${y} equals ${x + y}`
Ruby "#{x} plus #{y} equals #{x + y}"
Swift "\(x) plus \(y) equals \(x + y)"
Is any of those actually better? You have a non-existing better suggestion that works in the same cases they outline in the JEP?
I think the following is the main part to keep in mind:
> For Java, we would like to have a string composition feature that achieves the clarity of interpolation but achieves a safer result out-of-the-box, perhaps trading off a small amount of convenience to gain a large amount of safety.
May I introduce to Swift? They even decided on that without any backwards compatibility limitations. It really is not bad, does it really matter if it’s a $ or a \ ?
Would be cool if oracle worked on their presentation a bit. Whenever MS releases new C# features they've got a blog post showing the features off and how they can be used. Oracle just kind of dumps a bunch of JEP links
Java is developed in the open, we have had previews of the new features in the previous releases and the Java community has already written gazillion of articles about them. Today we celebrate they are finally production ready.
I know java has fallen out of favor these days. I blame the ghastly complexity of j2ee and Spring, which can't seem to say no to any academic design pattern. Also Oracle
But java is a peach for complex systems that need to scale both in terms of performance and in terms of number of people working on the system.
surprised to see all the comments about virtual threads. the real best feature of this release is record pattern matching in switch. this is a huge syntax improvement
How do people deal with old clients? The Android app I (partially) work on can't even use JDK 8 (I learned this when trying to use Double.hash() to hash a double).
Coming from C++, where I can use C++20 and still deploy to ancient devices, I'm seriously baffled how people work with Java. Is there any way to use new JDK features in an Android app that also has to deploy to Android SDK 21 (i.e. Android 5.0 from 2014!)?
I can't wait to see if/how tools like Reactor and Kotlin Coroutines adapt with Virtual Threads, and if they extend the tooling, or provide a migration path.
I've written a tonne of code on both Reactor and Coroutines, and would love something simpler, but dread the idea of migration.
If you add https://htmx.org/ into the mix, then you can build highly interactive applications, with a lot less complexity compared to building a purely data API consumed by some JavaScript frontend framework (React/Svelte/SolidJS and even ClojureScript)
Also, if you learn Clojure, you get a lot more benefits.
Shorter programs, which are easier to reason about and hence easier to maintain, etc.
[+] [-] mike_hearn|2 years ago|reply
For those who don't know, FoundationDB is a horizontally scalable transactional (KV) database used by Apple for their cloud services. It's famous primarily for its testing approach in which they can run the entire set of microservices in a simulator that can both inject faults, but also completely control the scheduling of work. In this way they make the system entirely deterministic, and can then pseudo-randomize simulations to uncover race conditions and the like.
To do this they created a custom DSL on top of C++ called Flow which is compiled to coroutines.
https://www.youtube.com/watch?v=4fFDFbi3toc
Flow and what it enables is considered (by them at least) to be a key competitive advantage over other database engines.
With Loom the JVM now happens to support the very same thing, just not officially. That's because the JVM makes file and network IO fully "pluggable", virtual threads can be supplied with a custom scheduler, and classloaders can be used to run multiple programs within the same JVM (with some caveats). So if you wanted to make a deterministic simulation of your microservice based system then you could do that now.
The above would be a rather advanced project for intrepid developers only, but it'd be interesting to see someone explore that at some point.
[+] [-] slantedview|2 years ago|reply
[+] [-] _a_a_a_|2 years ago|reply
[+] [-] ye-olde-sysrq|2 years ago|reply
Less-joking: I'm so excited for this to start getting adoption. For a pre-release/preview feature, Loom already has SO much traction, with most major frameworks already having support for running app/user code on virtual threads and one notable project (Helidon Nima) replacing netty with their own solution based on blocking IO and virtual threads. Now I want to see the community run with it.
I've always thought async IO was just plain gross.
Python's implementation is so yucky that after using it for one project I decided that I'd rather DIY it with multiprocessing than use async again. (I don't have any more constructive feedback than that, my apologies, it was a while ago so I don't remember the specifics but what has lasted is the sour taste of the sum of all the problems we had with it - perhaps notably that only about 2 people on my dev team of 5 actually understood the async paradigm).
netty did it fine. I've built multiple projects on top of netty and it's fine. I like event-based-async more than async-await-based-async. But it's still a headache and notably I really rather missed the kinds of guarantees you can get (in blocking code) by wrapping the block in try-catch-finally (to e.g. guarantee resources get freed or that two counters, say a requests-in and a requests-out, are guaranteed to match up).
But dang am I excited to not do that anymore. I have one specific project that I'm planning to port from async to blocking+virtualthreads that I expect to greatly simplify the code. It has a lot of requests it makes back and forth (it has to manually resolve DNS queries among other things) so there's good chunks of 50-200 ms where I have to either yield (and has gross async code that yields and resumes all the heck over the place) or block the thread for human-noticeable chunks of time (also very gross of course!).
[+] [-] PaulHoule|2 years ago|reply
Whereas my Java projects live on long after I am gone from the project.
Personally I love aiohttp web servers, particularly when using web sockets and brokering events from message queues and stuff like that. Not to mention doing cool stuff with coroutines and hacking the event queue (like what do you do if your GUI framework also has an event queue?) If YOShInOn (my smart RSS reader + intelligent agent) were going to become open source though I might just need to switch to Flask which would be less fun.
[+] [-] eastbound|2 years ago|reply
[+] [-] geodel|2 years ago|reply
[+] [-] davewritescode|2 years ago|reply
[+] [-] smallerfish|2 years ago|reply
[+] [-] zerr|2 years ago|reply
[+] [-] karg_kult|2 years ago|reply
[+] [-] 5e92cb50239222b|2 years ago|reply
https://adoptium.net
https://aws.amazon.com/corretto
https://www.azul.com/downloads
https://bell-sw.com/pages/downloads
Sadly, no-one has managed to package it yet, but we should get something in the next couple of days. Since 21 is an "LTS" release, major Linux distributions will provide a runtime pretty soon. Ubuntu backports them to old releases too.
[+] [-] pron|2 years ago|reply
We offer our own builds under two different licenses on our own websites (https://jdk.java.net or https://www.oracle.com/java/technologies/downloads/) but you can also download our software on the other websites linked above.
[+] [-] kaba0|2 years ago|reply
Oracle is responsible for 95+% of every single commit going to OpenJDK, which has the exact same license and situation as the goddamn linux kernel, GPL2. Do you also sweat a lot about accidentally installing red hat linux? If not, you have zero reason to worry.
How is amazon compiling and repackaging the exact same thing somehow different?
[+] [-] minedwiz|2 years ago|reply
[+] [-] nobleach|2 years ago|reply
I don't really pay a lot of attention to Java releases but I was actually excited about this one. No one ran a build process last night in anticipation?
[+] [-] geodel|2 years ago|reply
[+] [-] dang|2 years ago|reply
Java 21 makes me like Java again - https://news.ycombinator.com/item?id=37538333 - Sept 2023 (728 comments)
Java 21: First Release Candidate - https://news.ycombinator.com/item?id=37126530 - Aug 2023 (107 comments)
Java 21: What’s New? - https://news.ycombinator.com/item?id=37067491 - Aug 2023 (256 comments)
Java 21: No more public static void main - https://news.ycombinator.com/item?id=36189923 - June 2023 (77 comments)
JEP 430: String Templates (Preview) Proposed to Target Java 21 - https://news.ycombinator.com/item?id=35012862 - March 2023 (237 comments)
[+] [-] mdaniel|2 years ago|reply
[+] [-] alexvitkov|2 years ago|reply
[+] [-] jjtheblunt|2 years ago|reply
[+] [-] lambda_garden|2 years ago|reply
In languages with async-await syntax, I like that it is explicit what is sync and what is async. I also like how the "bind" points within an async expression make it clear where the syncronization happens. It seems to me that Java 21 makes all of this implicit, which is a step backward in this respect.
Similar to how types enforce valid usage (a foundational idea in Java), I feel that an Async<T> should not be implicitly a T.
Are people concerned about this at all?
Have the Java designers addressed this?
[+] [-] maxpert|2 years ago|reply
[+] [-] shortrounddev2|2 years ago|reply
[+] [-] capableweb|2 years ago|reply
I think the following is the main part to keep in mind:
> For Java, we would like to have a string composition feature that achieves the clarity of interpolation but achieves a safer result out-of-the-box, perhaps trading off a small amount of convenience to gain a large amount of safety.
[+] [-] Symbiote|2 years ago|reply
[+] [-] pjmlp|2 years ago|reply
While I don't like it, all other alternatives were kind of taken by libraries.
And who knows, since it is preview, it might still change.
[+] [-] kaba0|2 years ago|reply
[+] [-] frant-hartm|2 years ago|reply
[+] [-] anonair|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] shortrounddev2|2 years ago|reply
[+] [-] capableweb|2 years ago|reply
Each feature links to a deeper dive into it.
[+] [-] frant-hartm|2 years ago|reply
Java is developed in the open, we have had previews of the new features in the previous releases and the Java community has already written gazillion of articles about them. Today we celebrate they are finally production ready.
[+] [-] geodel|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] alex_suzuki|2 years ago|reply
I wonder how long those builds will remain available.
[+] [-] fnord77|2 years ago|reply
But java is a peach for complex systems that need to scale both in terms of performance and in terms of number of people working on the system.
[+] [-] za3faran|2 years ago|reply
[+] [-] foolfoolz|2 years ago|reply
[+] [-] aoetalks|2 years ago|reply
[+] [-] jaimehrubiks|2 years ago|reply
[+] [-] cornstalks|2 years ago|reply
Coming from C++, where I can use C++20 and still deploy to ancient devices, I'm seriously baffled how people work with Java. Is there any way to use new JDK features in an Android app that also has to deploy to Android SDK 21 (i.e. Android 5.0 from 2014!)?
[+] [-] martypitt|2 years ago|reply
I've written a tonne of code on both Reactor and Coroutines, and would love something simpler, but dread the idea of migration.
[+] [-] m8s|2 years ago|reply
[+] [-] jpgvm|2 years ago|reply
Now it's just the waiting game for Valhalla and Panama to land which will address the last of the things that make me sometimes pull my hair out.
[+] [-] java-man|2 years ago|reply
[+] [-] reaktivo|2 years ago|reply
Interested in building web applications.
[+] [-] onetom|2 years ago|reply
Here is a nice demonstration of what can you expect, if you want to build a web app:
https://youtu.be/LcpbBth7FaQ?si=PCZijF-JRmp0xxbz
If you add https://htmx.org/ into the mix, then you can build highly interactive applications, with a lot less complexity compared to building a purely data API consumed by some JavaScript frontend framework (React/Svelte/SolidJS and even ClojureScript)
Also, if you learn Clojure, you get a lot more benefits. Shorter programs, which are easier to reason about and hence easier to maintain, etc.
[+] [-] derkoe|2 years ago|reply
Newer alternatives are: https://micronaut.io/ and https://quarkus.io/
If you want to have something really simple look at Javalin: https://javalin.io/