<div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hello Rémi,<br><br>> TS.join() always wait, so this is <br>> confusing because a joiner with a <br>> name that does not start with the <br>> name "await" still await.<br><br>The method name join() makes perfect sense to me -- it joins all the threads.<br><br>And more accurately, it isn't just waiting, it is joining! Remember that STS with the default semantics (STS.open()) are those that it would have if we did CompletableFuture.allOf().join().<br><br>Therefore, to base your name off of waiting instead of joining would be the wrong semantics. The method name should remain as join() and should not be called anything else. Especially not await().<br><br>> "allUntil" is a half-lie, it will correctly<br>> cancel the other subtask when one<br>> task validates the predicate but at<br>> the same time, STS.join() will returns<br>> all subtasks, not the ones until<br>> the predicate is true.<br><br>Good point.<br><br>The name allUntil() leans heavily on the naming convention in order to make sense, but reading it plainly definitely misleads you as to its actual semantics.<br><br>Plus, I think your cancelWhen() suggestion is much clearer. Shame that it must abandon the naming convention. At the end of the day, the naming convention is useful, so I'd like any rename of this to maintain that convention.<br><br>> The other issue is the naming <br>> of awaitAll(), which is the shorter <br>> name, so people will be droven to use it <br>> by default, "it's the simpler"<br><br>This isn't a very strong argument, but at the same time, I think you have a point.<br><br>There is significant value in having the default semantics be attached to the name that users might first reach for.<br><br>That said, I think noCancellationVoidResult() is a very poor replacement name.</div><div class="gmail_default" style="font-family:monospace"><br>Here is my attempt at it.<br><br>allSuccessful()<br>anySuccessful()<br>awaitAllSuccessful()<br>awaitAllDontThrow()<br>allUntil(Predicate)<br><br>I can appreciate that SC API designers trying to avoid the Optional.get() fiasco by trying to use the xxxElseThrow and xxxOrThrow naming structure.<br><br>But Optional.get() was a fiasco because of WHERE Optional was being used -- aka, as a return type of basically ANY METHOD that can say "I may not return anything!". Its UBIQUITY is what made Optional.get() a disaster -- get() implies many things in many contexts, so it was not a wise name to use.<br><br>Joiner, in comparison, is a far more constrained domain. I think we can get away with having throwing be the assumed default. After all, we have to write a giant try-with-ressources anyways. I think the programmer is in the frame of mind to expect Exceptions. And that's ignoring the fact that join() throws! And that's even FURTHER ignoring the fact that, at use-site, the developer is not calling get() when they want to join.<br><br>How do you feel about my naming suggestions instead Rémi? I don't have a good replacement for allUntil's name, and I don't want to use cancelWhen, since it throws out the naming convention. But otherwise, how do you feel about it?</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Sep 25, 2025 at 2:20 AM Remi Forax <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So currently we have those joiner defined in the JDK:<br>
  - allSucessfulOrThrow()<br>
  - anySucessfulResultOrThrow()<br>
  - awaitSucessfulOrThrow()<br>
  - awaitAll()<br>
  - allUntil(predicate)<br>
<br>
There are several issues,<br>
- TS.join() always wait, so this is confusing because a joiner with a name that does not start with the name "await" still await.<br>
  If you take a look to the doc, the prefix "await" seems to be used to convey the idea that the result of the STS.join() is null,<br>
  i.e the joiner does not stores the forked subtasks in a list. <br>
<br>
- The other issue is the naming of awaitAll(), which is the shorter name, so people will be droven to use it by default, "it's the simpler",<br>
  but unlike the other joiners, it does not cancel the other subtasks in case of failure, which is not the semantics you want by default.<br>
  The name seems to imply that because it does ends with "OrThrow", it means that there is no cancellation.<br>
<br>
- "allUntil" is a half-lie, it will correctly cancel the other subtask when one task validates the predicate but at the same time,<br>
  STS.join() will returns all subtasks, not the ones until the predicate is true.<br>
  The name "allUntil" only make sense if you see it as the concatenation of two orthogonal behaviors, "all" meaning STS.join() returns<br>
  all subtasks and "until" meaning stop when the predicate is true.<br>
<br>
I propose this renaming (in order):<br>
- allSuccessful()<br>
- anySuccessful()<br>
- sucessfulVoidResult()<br>
- noCancellationVoidResult()<br>
- cancelWhen(predicate)<br>
<br>
After that, i think we can be a little more fancy and see the fact that the implementation returns all subtasks as a separate concern,<br>
thus enable composition:<br>
- sucessful().all()<br>
- anySucessful()<br>
- sucessful()<br>
- nonCancellation()<br>
- cancelWhen(predicate).all()<br>
<br>
With all() a default method that override onFork() and result() to respectively add each subtask in a list and blindly returns that list.<br>
<br>
regards,<br>
Rémi<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div>