If you mean to say java.util.concurrent.structured, that makes good sense to me. That package change is the missing piece to shortening the name IMO.
On Tue, Mar 24, 2026, 9:38 AM robert engels <[email protected]> wrote: > 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 >
