Why not put it all in a package concurrency.structured then those that want the fully qualified names can basically do so, and those that don’t can use static imports.
> On Mar 24, 2026, at 8:29 AM, Eric Kolotyluk <[email protected]> wrote: > > I am fine with just "TaskScope" - that's an improvement. > > Cheers, Eric > >> On 2026-03-24 12:24 AM, Remi Forax wrote: >> I agree with Eric, STS name is too long. >> >> Unlike Eric, Ì think that "TaskScope" is fine. >> >> It's API uses the principles of structured concurrency, but it does not have >> to be in the name. >> >> It's a scope for tasks (subtasks), so "TaskScope" seems good. >> >> regards, >> Rémi >> >> ----- Original Message ----- >>> From: "Eric Kolotyluk" <[email protected]> >>> To: "loom-dev" <[email protected]> >>> Sent: Saturday, March 21, 2026 6:02:30 PM >>> Subject: [External] : Re: Structured Concurrency to re-preview in JDK 27 >>> 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
