Remark on the StructuredTaskScope API of Java 25

[David Alayachew]

> If the API allowed Subtask::get to be used
> before join then it would be very fragile as it
> would be like a "wait-less"  Future::get. It
> might work sometimes, but if a subtask were
> slow then Subtask::get would throw ISE.

Can you explain this in more detail? I don't understand what you are saying
here.

On Wed, Sep 24, 2025 at 1:52 PM Alan Bateman <alan.bateman at oracle.com>
wrote:

>
>
> On 24/09/2025 16:37, Remi Forax wrote:
>
> :
>
> And now two remarks,
>  - is there a way to remove the limitation that the main thread (the one that have created the STS) can not access to SubTask.get(),
>    because there is at least a case where i know that the task is finished before join() is called (see below).
>
>
> This restriction is there to ensure that the API is used as intended.
> Subtasks are forked individually and then joined as a unit. If the API
> allowed Subtask::get to be used before join then it would be very fragile
> as it would be like a "wait-less"  Future::get. It might work sometimes,
> but if a subtask were slow then Subtask::get would throw ISE.
>
>  - is there a way to get a joiner that returns the list of subtask in the order if their completeness, not in the order of onFork() ?
>
>
> A Joiner can collect in its onComplete method so that will give you
> completion order. That said, I suspect you might be asking something
> different. Are you thinking about APIs such as CompletionService where you
> get a wakeup as subtasks complete rather join as a unit?
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20250924/b6b3e21c/attachment.htm>