So currently we have those joiner defined in the JDK: - allSucessfulOrThrow() - anySucessfulResultOrThrow() - awaitSucessfulOrThrow() - awaitAll() - allUntil(predicate)
There are several issues, - TS.join() always wait, so this is confusing because a joiner with a name that does not start with the name "await" still await. 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, i.e the joiner does not stores the forked subtasks in a list. - 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", 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. The name seems to imply that because it does ends with "OrThrow", it means that there is no cancellation. - "allUntil" is a half-lie, it will correctly cancel the other subtask when one task validates the predicate but at the same time, STS.join() will returns all subtasks, not the ones until the predicate is true. The name "allUntil" only make sense if you see it as the concatenation of two orthogonal behaviors, "all" meaning STS.join() returns all subtasks and "until" meaning stop when the predicate is true. I propose this renaming (in order): - allSuccessful() - anySuccessful() - sucessfulVoidResult() - noCancellationVoidResult() - cancelWhen(predicate) 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, thus enable composition: - sucessful().all() - anySucessful() - sucessful() - nonCancellation() - cancelWhen(predicate).all() With all() a default method that override onFork() and result() to respectively add each subtask in a list and blindly returns that list. regards, Rémi
