<!DOCTYPE html><html><head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body>

    <div class="moz-cite-prefix">On 26/09/2025 18:41, Remi Forax wrote:<br>

    </div>

    <blockquote type="cite" cite="mid:1920101532.708894.1758908500414.JavaMail.zimbra@univ-eiffel.fr">

      <pre wrap="" class="moz-quote-pre">Currently,

the interface Subtask defines 3 different states, but while the implementation needs 3 states, I believe the interface only need 2.

Currently, having 3 states punished people that are using the API correctly, i.e accessing the state when all the computations are done,

after join() is called, because for them, only two states are visible, but they still need to write a code that takes can of the state

UNINITIALIZED.

I propose that state() can only return SUCCESS or FAILURE and throw an ISE if the internal state is UNINITIALIZED given it means

that the API is not used correctly.

In the past, with the previous iteration of the design using inheritance instead of delegation, the Subtask was not sealed,

so the internal state had to be exposed, but now that only the implementation of STS can create a Subtask, the internal state UNINITIALIZED does not have to be visible.

</pre>

    </blockquote>

    Subtask has always been sealed. It has always had 3 states, nothing

    has changed, and nothing from the implementation has leaked into the

    API. So I'm a bit puzzled by your message. There is no outcome to

    report when a subtask is executing, was cancelled, or was forked

    after the scope was cancelled. The Subtask::state returns

    "UNAVAILABLE" for all these cases. It's easy to come up with

    examples where join returns a stream of subtasks in each of these

    states.<br>

    <br>

    Is your gripe with the onComplete method when writing a custom

    Joiner? That will only be called when the Subtask has completed and

    so is guaranteed to be in the SUCCESS or FAILED state?<br>

    <br>

    -Alan<br>

  </body>

</html>