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.
> 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.
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.
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), and others will be addressed by future ones (like channels).
> 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.
"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