After taking the time to read the JEP, here is my two cents...
1. Every revision of this seems to get better. I am glad it has been
incubating for so long before locking it down.
2. StructuredTaskScope seems like a long name and seems related to
ScopedValues
* Not that I mind long names
* But, when I sense a common pattern ('scope') it begs the
question as to the structure of names.
* I brought this up years ago before there were scoped values, so
it is still on my mind.
After playing around with Rust for a while, I find Project Loom
concurrency to be much easier to understand and reason about, possibly
because of such a long incubating process. Rust concurrency was
developed too rapidly and needs its own retrospective.
Using Java concurrency since before the release of 1.0, I have burned
myself many times, and learned many hard lesson. Structured Concurrency
is simply the best thing that has ever happened to Java Concurrency,
where I include the whole Loom results as well.
Having developed Akka/Scala code for many years, while it was elegant,
it was hard to reason about with all the callbacks. Java
CompletableFuture was not any better.
It is far easier, for me, to reason about 'tasks' than 'futures,' and to
write imperative code than functional code.
Still, I look forward to Java tackling some of the other good ideas from
Akka/Scala, such as Actors and Scala Streams, where Java ScopedValue is
far better than Scala implicit.
On 2026-03-18 4:44 AM, Alan Bateman wrote:
The plan for Structured Concurrency is to propose that it re-preview
in JDK 27 with some changes to improve the exception thrown by the
join method. It means adding an additional type parameter but it
doesn't impact the usability of any of the basic examples. We hope to
submit the draft JEP [1] soon.
-Alan
[1] https://openjdk.org/jeps/8373610
