structured.TaskScope or TaskScope
or concurrent.structured.TaskScope or java.util.concurrent.structured.TaskScope It all depends on how you import it. > On Mar 24, 2026, at 11:12 AM, Pavel Rappo <[email protected]> wrote: > > Out of curiosity, please provide two examples: one for FQN and the > other for non-FQN use. > >> On Tue, Mar 24, 2026 at 1:38 PM 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
