10 ms·

Features of Project Loom incorporated in JDK 21

222 points by philonoist 3y ago

spullara 3y ago
Basically you ignore a bunch of the work done for async, callbaks, etc and go back to making a new "thread" and handling a request.
- gonzo41 3y ago
  I got off the java train at 8. 21 seems like a good place to get back on.
  - gbear605 3y ago
    There’s been a lot of good improvements since 8 for sure. Nothing individually mind blowing, but together they make the language a lot more agile and enjoyable to work with: - Records (immutable objects, basically named tuples) - Switch expressions - Pattern matching and record patterns (coming in Java 21) - Text blocks (multiline strings) - “var” for variable creation instead of the full type name - Virtual threads and other Project Loom enhancements - Improved tooling, including jshell, a REPL built into the JDK
- jmaker 3y ago
  It’s a different paradigm than asynchrony and reactive streams. It’s not like you could just ignore anything. And with thread pinning you still should control what you’re doing.
- spinningslate 3y ago
  or you watch and learn, understand the strengths and weaknesses, and then make an informed decision. async/await is no panacea. Quoting the Loom overview[0]: "Project Loom's mission is to make it easier to write, debug, profile and maintain concurrent applications meeting today's requirements. Threads, provided by Java from its first day, are a natural and convenient concurrency construct (putting aside the separate question of communication among threads) which is being supplanted by less convenient abstractions because their current implementation as OS kernel threads is insufficient for meeting modern demands, and wasteful in computing resources that are particularly valuable in the cloud. Project Loom will introduce fibers as lightweight, efficient threads managed by the Java Virtual Machine, that let developers use the same simple abstraction but with better performance and lower footprint. We want to make concurrency simple(r) again! A fiber is made of two components — a continuation and a scheduler. As Java already has an excellent scheduler in the form of ForkJoinPool, fibers will be implemented by adding continuations to the JVM. -- [0]: https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html
  - Nullabillity 3y ago
    > putting aside the separate question of communication among threads But that's.. 99% of the problem. If you haven't solved that then you haven't solved anything. Solving that is the point of Future systems, the m:n scheduling is just a nice cherry on top.
    - pron 3y ago
      These features become orthogonal when the right primitives are there, and so there's no need for a "system" (other than the language/platform itself). Some of the communication problem is already addressed by other Loom features (https://openjdk.org/jeps/453 https://openjdk.org/jeps/453), and others will be addressed by future ones (like channels).
      - avodonosov 3y ago
        BlockingQueue is a kind of channel already, what are you thinking to add? And to the main point, of course, Java has plenty of thread comrunioation possibilities, Loom just makes threads cheaper.
        pron 3y ago
        > BlockingQueue is a kind of channel already, what are you thinking to add? The main difference between a channel and a BlockingQueue is that a channel can be closed, i.e. it allows one or both sides to signal the other that they're done producing/consuming. > And to the main point, of course, Java has plenty of thread comrunioation possibilities, Loom just makes threads cheaper. Definitely.
    - ye-olde-sysrq 3y ago
      99% of which problem, though? IMO the whole point of Loom, and what I'm looking forward to, is code that looks like this: fooer.onCompletion(() -> System.out.println("yay")); fooer.onError(e -> System.out.println("o no")); fooer.foo(); // foo is some long operation can once again simply be: try { foo() S.o.p("yay"); } catch(Exception e) { S.o.p("o no"); } just like any college kid would've written 20 years ago in their CS 101 class in the chapter on exceptions. Many multi-threaded programs today don't even have a "communication among threads" problem. - they avoid it by simply not communicating between threads. They precompute work splits and then farm it out, and then gather up all the results. Consider HTTP servers or RPC handlers. A request is farmed out to them, they do a bunch of IO stuff to answer it, and then release their thread back to a pool. That's a huge use-case that gets materially improved right there. Look at what goroutines did for go programming.
- geodel 3y ago
  Ignoring bad technologies is great thing. Nothing wrong with that.
MichaelMoser123 3y ago
Other than cooperative threading: they are also adding a more versatile switch statement, with some form of pattern matching https://openjdk.org/jeps/441 https://openjdk.org/jeps/441 But it still falls short of deconstruction patterns of Scala, though that is something that they want to do in the future (see 'Future Work' section) i think that Scala is driving a lot of progress: (for example java adopted streams, probably inspired by Scala)
dveeden2 3y ago
Info on what Project Loom is: https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html
- brabel 3y ago
  This was just the proposal, lots of things have changed since then! To know what Loom is about, read the official Java Magazine post about it (2021 though, not sure how much has changed and not been updated): https://blogs.oracle.com/javamagazine/post/going-inside-javas-project-loom-and-virtual-threads https://blogs.oracle.com/javamagazine/post/going-inside-java... Or just the current JEP: https://openjdk.org/jeps/425 https://openjdk.org/jeps/425 More resources on the Project page: https://wiki.openjdk.org/display/loom https://wiki.openjdk.org/display/loom
  - carimura 3y ago
    Correction: That's the first preview, here's the latest JEP on Virtual Threads: https://openjdk.org/jeps/444 https://openjdk.org/jeps/444
    - brabel 3y ago
      Could you get the Project Page (https://wiki.openjdk.org/display/loom https://wiki.openjdk.org/display/loom) to update the link to the JEP? It was listing the one I posted above just now...
- carimura 3y ago
  We aggregate/organize content from the Java team here: https://inside.java/tag/loom https://inside.java/tag/loom
zackees 3y ago
Aka green threads.
- jmaker 3y ago
  JDK 1.1 Green threads were quite different than the new Loom fibers.
  - brabel 3y ago
    The current specifications explicitly avoid calling Virtual Threads fibers exactly to avoid confusion with older implementations of the idea.
deutschepost 3y ago
At first I misread and wondered what Project Loon[1] could possibly contribute to JDK 21. [1]https://en.m.wikipedia.org/wiki/Loon_LLC https://en.m.wikipedia.org/wiki/Loon_LLC
- ale42 3y ago
  Balloon factory classes ;-)
tomaytotomato 3y ago
Nice, Project Loom is often summarised as just incorporating the main feature of Virtual Threads however it will also add a whole bunch of other features or improvements for doing tasks concurrently and not having to worry about blocking IO or race conditions like you would have in the past. Some useful code examples are here to play around with https://github.com/nipafx/loom-lab https://github.com/nipafx/loom-lab
- no_wizard 3y ago
  I never really "took" to Java, but are all projects this boilerplate / nested? `src/main/java/dev/nipafx/lab/loom/disk` for example seems like alot of directory for just getting some source files organized.
  - chaosite 3y ago
    Yes, they all are. First you have `src/main/java` (compare `src/test/kotlin`), and then the package is encoded as nested directories, and Java has a convention of using the domain name as the root of your packages. So, if your company domain is "sun.com", all your packages start with "com.sun", and then you have more specifiers under that. But all IDEs and github condense empty directories together, so it's not that bothersome.
    - ackfoobar 3y ago
      > But all IDEs and github condense empty directories together, so it's not that bothersome. Yes in most tools that's quite transparent. Every once in a while I use the GitHub mobile app (which is not doing that), I'm reminded how bothersome it is.
  - desertlounger 3y ago
    src/main/java is a convention that started with Maven; it's simple to change in the project build file (pom.xml). Otherwise, it's due to the fact that a package namespace in Java must correspond to a directory tree.
misja111 3y ago
Does anybody know what this will mean for the already existing green threads implementations in e.g. Kotlin and Scala Cats? Will these benefit from project Loom, or are they somehow incompatible?
- nvm0n2 3y ago
  Language-level coroutines derive no direct benefit from Loom but it also doesn't hurt them. The benefit is you can just stop using those language features, or if you already have them in wide use, you can just wrap all your code in runBlocking{} and virtual threads. Also, no work is needed to start using virtual threads because they're a library/runtime feature not something a language has to support. One of the benefits of being a JVM language - free upgrades. Exception: GUI code. Kotlin Coroutines is deeply integrated into Jetpack Compose. In theory parts of the framework are thread safe but it's not well documented and all the examples / tutorials want you to learn coroutines.
  - valenterry 3y ago
    > The benefit is you can just stop using those language features Not at all. This is like saying "now the runtime supports plus and and minus natively, so you don't have to use a math-library anymore". Libraries Like ZIO, Cats Effect or Arrow-KT offer a vast amount of functionality that you still have to rebuild with Loom. Just the foundations are different.
- pjmlp 3y ago
  Like any guest language, it is up to them to eventually adopt platform features, or not.
- ceronman 3y ago
  I don't know about Scala, but there are benefits for Kotlin indeed. For example a special dispatcher could be made to schedule each coroutine on a single virtual thread. This would be very handy for coroutines that suspend on IO, and it would be a better alternative to Dispatchers.IO which currently uses a threadpool like strategy. Also it's possible that debugging and profiling is improved given that each virtual thread has its own stack. And you can still take advantage of all the nice things in Kotlin for structured concurrency, flows, etc. On the other hand, Kotlin already committed to a colored function approach, and it will likely remain. Java on the other hand, will not need that, which is nice.
mgaunard 3y ago
[flagged]
- Rebelgecko 3y ago
  Yes, it's a fairly popular language
- misja111 3y ago
  You wouldn't say so if you only read HN
- re-thc 3y ago
  Companies do
- kaba0 3y ago
  As it is continuously in the top 3 most popular languages, yes.
  - mgaunard 3y ago
    Well it's currently 4th and on a trend down.
    - kaba0 3y ago
      Source?
      - mgaunard 3y ago
        the TIOBE index
        kaba0 3y ago
        That’s the worst possible answer to my question - unless you believe that visual basic is ahead of javascript, as TIOBE once proudly showed. Honestly, just forget about it entirely, random.org reordering a list of PLs would be more accurate than that. If you are interested, here is a ranking that has some relevance to the real world: https://redmonk.com/sogrady/2023/05/16/language-rankings-1-23/ https://redmonk.com/sogrady/2023/05/16/language-rankings-1-2...
nvm0n2 3y ago
A good step forward and nice that it's in the next (Oracle) LTS version. But is it too late? NodeJS started cleaning up by pushing async-for-all over a decade ago. Then Go came along and did the same thing but with a simple statically typed language. The Java world developed async server frameworks + GraalVM native image in response and now will be able to incrementally phase them out, but Java lost significant ground server-side because it took so long to identify and respond to these moves by competitors. The question is now whether Java will regain some of that lost ground, or whether people came for the async but stay for the "isomorphism" (same language in both browser and server) / AOT compilation model. My gut says it's not too late for them and devs do engage in a kind of continuous rolling evaluation of platforms. Once Java 21 launches people might start to re-evaluate Java vs Node and once Loom is fully supported in native images, you might start to see people re-evaluate Java vs Go at least. Where by "Java vs" I really mean "JVM languages vs" like with Kotlin, Scala and Clojure as well. Or maybe even Loom will be compatible with GraalJS and then you can do fully blocking programming with Node-style efficiency but on the JVM.
- pmontra 3y ago
  There are companies that use Java and will keep using Java no matter what. A 10+ years old Java is fine for them. An example: all the incumbent financial sector.
  - nvm0n2 3y ago
    Yes, but there's little growth to be had there. I think the Java guys don't want to be the new COBOL, they'd like new apps to be written in Java too.
    - rbanffy 3y ago
      Java and, to a lesser degree, C#, seem to have joined COBOL in the list of “forever languages”. Unless financial institutions trust LLMs to rewrite them in newer languages (and finds that cost-effective), there is no way that humongous corpus of business-critical software will ever be ported.
    - 3y ago
avodonosov 3y ago
Congrats to Ron Pressler (pron at HN) and the team. Who worked on it for so long, ever since the Quasar library.
kitd 3y ago
There are some fairly major Java backend libraries that are founded almost entirely on async-type APIs. Eg, Vertx, Quarkus, Micronaut, etc. I am interested to see how a widespread move to virtual threads, which for them is somewhat existential, affects their futures (pun intended). Also what backend libs that are founded on virtual threads emerge and supplant them.
- samus 3y ago
  In principle, reactive and callback-style libraries could eventually use Virtual Threads as backend as well, but I expect for them to fall out of fashion. After all, they were introduced because the existing threading support in Java did not adequately support massively-concurrent applications. There will surely be new frameworks that will take advantage of Virtual Threads and will eventually require to run on the first Java LTS version with Virtual Threads support. Other projects might offer Virtual Threads as a backend, maybe even by default, but will continue to support traditional backends for the foreseeable future, e.g., Apache Tomcat.
- gabereiser 3y ago
  Not sure about now but a few years back the company I worked for was heavily vested in Finagle [1] using Future<T> pools. I'm sure virtual threads would only enhance this framework. Also, Spring and it's reactive webflux would probably benefit as well [2]. [1] https://twitter.github.io/finagle/ https://twitter.github.io/finagle/ [2] https://docs.spring.io/spring-framework/reference/web/webflux/reactive-spring.html https://docs.spring.io/spring-framework/reference/web/webflu...
- killingtime74 3y ago
  Quarkus is built on Vertx so once that gets upgraded two will support it. https://github.com/vert-x3/vertx-virtual-threads-incubator https://github.com/vert-x3/vertx-virtual-threads-incubator Vertx is testing it
- ye-olde-sysrq 3y ago
  I actually used Jetty for a recent project because they were one of the first to integrate support for running handlers on virtual threads.
senda 3y ago
any metrics to compare this to say streams or any other OS based parallelisation?
tomohawk 3y ago
It's great to see this, but it's not going to make me want to go back to Java from Go. In Go, everything is built with this sort of concurrency from the ground up. This makes everything fit together very nicely without the cognitive overhead and dissonance you have to work through with the Java libraries of various vintages and approaches.
- pjmlp 3y ago
  Me on the other hand, only code like 1996 if I have to.
- closeparen 3y ago
  Thread per request programming is alive and well in Java. You usually have to go out of your way for callback-oriented versions of things. This will simply make the existing naive code more scalable, and obviate the need for async style programming in new projects that are targeting scale.

222 points by philonoist 3y ago

Basically you ignore a bunch of the work done for async, callbaks, etc and go back to making a new "thread" and handling a request.

gonzo41 3y ago
I got off the java train at 8. 21 seems like a good place to get back on.
- gbear605 3y ago
  There’s been a lot of good improvements since 8 for sure. Nothing individually mind blowing, but together they make the language a lot more agile and enjoyable to work with: - Records (immutable objects, basically named tuples) - Switch expressions - Pattern matching and record patterns (coming in Java 21) - Text blocks (multiline strings) - “var” for variable creation instead of the full type name - Virtual threads and other Project Loom enhancements - Improved tooling, including jshell, a REPL built into the JDK
jmaker 3y ago
It’s a different paradigm than asynchrony and reactive streams. It’s not like you could just ignore anything. And with thread pinning you still should control what you’re doing.
spinningslate 3y ago
or you watch and learn, understand the strengths and weaknesses, and then make an informed decision. async/await is no panacea. Quoting the Loom overview[0]: "Project Loom's mission is to make it easier to write, debug, profile and maintain concurrent applications meeting today's requirements. Threads, provided by Java from its first day, are a natural and convenient concurrency construct (putting aside the separate question of communication among threads) which is being supplanted by less convenient abstractions because their current implementation as OS kernel threads is insufficient for meeting modern demands, and wasteful in computing resources that are particularly valuable in the cloud. Project Loom will introduce fibers as lightweight, efficient threads managed by the Java Virtual Machine, that let developers use the same simple abstraction but with better performance and lower footprint. We want to make concurrency simple(r) again! A fiber is made of two components — a continuation and a scheduler. As Java already has an excellent scheduler in the form of ForkJoinPool, fibers will be implemented by adding continuations to the JVM. -- [0]: https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html
- Nullabillity 3y ago
  > putting aside the separate question of communication among threads But that's.. 99% of the problem. If you haven't solved that then you haven't solved anything. Solving that is the point of Future systems, the m:n scheduling is just a nice cherry on top.
  - pron 3y ago
    These features become orthogonal when the right primitives are there, and so there's no need for a "system" (other than the language/platform itself). Some of the communication problem is already addressed by other Loom features (https://openjdk.org/jeps/453 https://openjdk.org/jeps/453), and others will be addressed by future ones (like channels).
    - avodonosov 3y ago
      BlockingQueue is a kind of channel already, what are you thinking to add? And to the main point, of course, Java has plenty of thread comrunioation possibilities, Loom just makes threads cheaper.
      - pron 3y ago
        > BlockingQueue is a kind of channel already, what are you thinking to add? The main difference between a channel and a BlockingQueue is that a channel can be closed, i.e. it allows one or both sides to signal the other that they're done producing/consuming. > And to the main point, of course, Java has plenty of thread comrunioation possibilities, Loom just makes threads cheaper. Definitely.
  - ye-olde-sysrq 3y ago
    99% of which problem, though? IMO the whole point of Loom, and what I'm looking forward to, is code that looks like this: fooer.onCompletion(() -> System.out.println("yay")); fooer.onError(e -> System.out.println("o no")); fooer.foo(); // foo is some long operation can once again simply be: try { foo() S.o.p("yay"); } catch(Exception e) { S.o.p("o no"); } just like any college kid would've written 20 years ago in their CS 101 class in the chapter on exceptions. Many multi-threaded programs today don't even have a "communication among threads" problem. - they avoid it by simply not communicating between threads. They precompute work splits and then farm it out, and then gather up all the results. Consider HTTP servers or RPC handlers. A request is farmed out to them, they do a bunch of IO stuff to answer it, and then release their thread back to a pool. That's a huge use-case that gets materially improved right there. Look at what goroutines did for go programming.
geodel 3y ago
Ignoring bad technologies is great thing. Nothing wrong with that.

MichaelMoser123 3y ago

Other than cooperative threading: they are also adding a more versatile switch statement, with some form of pattern matching https://openjdk.org/jeps/441 https://openjdk.org/jeps/441 But it still falls short of deconstruction patterns of Scala, though that is something that they want to do in the future (see 'Future Work' section) i think that Scala is driving a lot of progress: (for example java adopted streams, probably inspired by Scala)

dveeden2 3y ago

Info on what Project Loom is: https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html

brabel 3y ago
This was just the proposal, lots of things have changed since then! To know what Loom is about, read the official Java Magazine post about it (2021 though, not sure how much has changed and not been updated): https://blogs.oracle.com/javamagazine/post/going-inside-javas-project-loom-and-virtual-threads https://blogs.oracle.com/javamagazine/post/going-inside-java... Or just the current JEP: https://openjdk.org/jeps/425 https://openjdk.org/jeps/425 More resources on the Project page: https://wiki.openjdk.org/display/loom https://wiki.openjdk.org/display/loom
- carimura 3y ago
  Correction: That's the first preview, here's the latest JEP on Virtual Threads: https://openjdk.org/jeps/444 https://openjdk.org/jeps/444
  - brabel 3y ago
    Could you get the Project Page (https://wiki.openjdk.org/display/loom https://wiki.openjdk.org/display/loom) to update the link to the JEP? It was listing the one I posted above just now...
carimura 3y ago
We aggregate/organize content from the Java team here: https://inside.java/tag/loom https://inside.java/tag/loom

zackees 3y ago

Aka green threads.

jmaker 3y ago
JDK 1.1 Green threads were quite different than the new Loom fibers.
- brabel 3y ago
  The current specifications explicitly avoid calling Virtual Threads fibers exactly to avoid confusion with older implementations of the idea.

deutschepost 3y ago

At first I misread and wondered what Project Loon[1] could possibly contribute to JDK 21. [1]https://en.m.wikipedia.org/wiki/Loon_LLC https://en.m.wikipedia.org/wiki/Loon_LLC

ale42 3y ago
Balloon factory classes ;-)

tomaytotomato 3y ago

Nice, Project Loom is often summarised as just incorporating the main feature of Virtual Threads however it will also add a whole bunch of other features or improvements for doing tasks concurrently and not having to worry about blocking IO or race conditions like you would have in the past. Some useful code examples are here to play around with https://github.com/nipafx/loom-lab https://github.com/nipafx/loom-lab

no_wizard 3y ago
I never really "took" to Java, but are all projects this boilerplate / nested? `src/main/java/dev/nipafx/lab/loom/disk` for example seems like alot of directory for just getting some source files organized.
- chaosite 3y ago
  Yes, they all are. First you have `src/main/java` (compare `src/test/kotlin`), and then the package is encoded as nested directories, and Java has a convention of using the domain name as the root of your packages. So, if your company domain is "sun.com", all your packages start with "com.sun", and then you have more specifiers under that. But all IDEs and github condense empty directories together, so it's not that bothersome.
  - ackfoobar 3y ago
    > But all IDEs and github condense empty directories together, so it's not that bothersome. Yes in most tools that's quite transparent. Every once in a while I use the GitHub mobile app (which is not doing that), I'm reminded how bothersome it is.
- desertlounger 3y ago
  src/main/java is a convention that started with Maven; it's simple to change in the project build file (pom.xml). Otherwise, it's due to the fact that a package namespace in Java must correspond to a directory tree.

misja111 3y ago

Does anybody know what this will mean for the already existing green threads implementations in e.g. Kotlin and Scala Cats? Will these benefit from project Loom, or are they somehow incompatible?

nvm0n2 3y ago
Language-level coroutines derive no direct benefit from Loom but it also doesn't hurt them. The benefit is you can just stop using those language features, or if you already have them in wide use, you can just wrap all your code in runBlocking{} and virtual threads. Also, no work is needed to start using virtual threads because they're a library/runtime feature not something a language has to support. One of the benefits of being a JVM language - free upgrades. Exception: GUI code. Kotlin Coroutines is deeply integrated into Jetpack Compose. In theory parts of the framework are thread safe but it's not well documented and all the examples / tutorials want you to learn coroutines.
- valenterry 3y ago
  > The benefit is you can just stop using those language features Not at all. This is like saying "now the runtime supports plus and and minus natively, so you don't have to use a math-library anymore". Libraries Like ZIO, Cats Effect or Arrow-KT offer a vast amount of functionality that you still have to rebuild with Loom. Just the foundations are different.
pjmlp 3y ago
Like any guest language, it is up to them to eventually adopt platform features, or not.
ceronman 3y ago
I don't know about Scala, but there are benefits for Kotlin indeed. For example a special dispatcher could be made to schedule each coroutine on a single virtual thread. This would be very handy for coroutines that suspend on IO, and it would be a better alternative to Dispatchers.IO which currently uses a threadpool like strategy. Also it's possible that debugging and profiling is improved given that each virtual thread has its own stack. And you can still take advantage of all the nice things in Kotlin for structured concurrency, flows, etc. On the other hand, Kotlin already committed to a colored function approach, and it will likely remain. Java on the other hand, will not need that, which is nice.

mgaunard 3y ago

[flagged]

Rebelgecko 3y ago
Yes, it's a fairly popular language
misja111 3y ago
You wouldn't say so if you only read HN
re-thc 3y ago
Companies do
kaba0 3y ago
As it is continuously in the top 3 most popular languages, yes.
- mgaunard 3y ago
  Well it's currently 4th and on a trend down.
  - kaba0 3y ago
    Source?
    - mgaunard 3y ago
      the TIOBE index
      - kaba0 3y ago
        That’s the worst possible answer to my question - unless you believe that visual basic is ahead of javascript, as TIOBE once proudly showed. Honestly, just forget about it entirely, random.org reordering a list of PLs would be more accurate than that. If you are interested, here is a ranking that has some relevance to the real world: https://redmonk.com/sogrady/2023/05/16/language-rankings-1-23/ https://redmonk.com/sogrady/2023/05/16/language-rankings-1-2...

nvm0n2 3y ago

A good step forward and nice that it's in the next (Oracle) LTS version. But is it too late? NodeJS started cleaning up by pushing async-for-all over a decade ago. Then Go came along and did the same thing but with a simple statically typed language. The Java world developed async server frameworks + GraalVM native image in response and now will be able to incrementally phase them out, but Java lost significant ground server-side because it took so long to identify and respond to these moves by competitors. The question is now whether Java will regain some of that lost ground, or whether people came for the async but stay for the "isomorphism" (same language in both browser and server) / AOT compilation model. My gut says it's not too late for them and devs do engage in a kind of continuous rolling evaluation of platforms. Once Java 21 launches people might start to re-evaluate Java vs Node and once Loom is fully supported in native images, you might start to see people re-evaluate Java vs Go at least. Where by "Java vs" I really mean "JVM languages vs" like with Kotlin, Scala and Clojure as well. Or maybe even Loom will be compatible with GraalJS and then you can do fully blocking programming with Node-style efficiency but on the JVM.

pmontra 3y ago
There are companies that use Java and will keep using Java no matter what. A 10+ years old Java is fine for them. An example: all the incumbent financial sector.
- nvm0n2 3y ago
  Yes, but there's little growth to be had there. I think the Java guys don't want to be the new COBOL, they'd like new apps to be written in Java too.
  - rbanffy 3y ago
    Java and, to a lesser degree, C#, seem to have joined COBOL in the list of “forever languages”. Unless financial institutions trust LLMs to rewrite them in newer languages (and finds that cost-effective), there is no way that humongous corpus of business-critical software will ever be ported.
  - 3y ago

avodonosov 3y ago

Congrats to Ron Pressler (pron at HN) and the team. Who worked on it for so long, ever since the Quasar library.

kitd 3y ago

There are some fairly major Java backend libraries that are founded almost entirely on async-type APIs. Eg, Vertx, Quarkus, Micronaut, etc. I am interested to see how a widespread move to virtual threads, which for them is somewhat existential, affects their futures (pun intended). Also what backend libs that are founded on virtual threads emerge and supplant them.

samus 3y ago
In principle, reactive and callback-style libraries could eventually use Virtual Threads as backend as well, but I expect for them to fall out of fashion. After all, they were introduced because the existing threading support in Java did not adequately support massively-concurrent applications. There will surely be new frameworks that will take advantage of Virtual Threads and will eventually require to run on the first Java LTS version with Virtual Threads support. Other projects might offer Virtual Threads as a backend, maybe even by default, but will continue to support traditional backends for the foreseeable future, e.g., Apache Tomcat.
gabereiser 3y ago
Not sure about now but a few years back the company I worked for was heavily vested in Finagle [1] using Future<T> pools. I'm sure virtual threads would only enhance this framework. Also, Spring and it's reactive webflux would probably benefit as well [2]. [1] https://twitter.github.io/finagle/ https://twitter.github.io/finagle/ [2] https://docs.spring.io/spring-framework/reference/web/webflux/reactive-spring.html https://docs.spring.io/spring-framework/reference/web/webflu...
killingtime74 3y ago
Quarkus is built on Vertx so once that gets upgraded two will support it. https://github.com/vert-x3/vertx-virtual-threads-incubator https://github.com/vert-x3/vertx-virtual-threads-incubator Vertx is testing it
ye-olde-sysrq 3y ago
I actually used Jetty for a recent project because they were one of the first to integrate support for running handlers on virtual threads.

senda 3y ago

any metrics to compare this to say streams or any other OS based parallelisation?

tomohawk 3y ago

It's great to see this, but it's not going to make me want to go back to Java from Go. In Go, everything is built with this sort of concurrency from the ground up. This makes everything fit together very nicely without the cognitive overhead and dissonance you have to work through with the Java libraries of various vintages and approaches.

pjmlp 3y ago
Me on the other hand, only code like 1996 if I have to.
closeparen 3y ago
Thread per request programming is alive and well in Java. You usually have to go out of your way for callback-oriented versions of things. This will simply make the existing naive code more scalable, and obviate the need for async style programming in new projects that are targeting scale.