On Mar 24, 2026, at 9:45 AM, David Alayachew
<[email protected]> wrote:
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
