<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">And maybe it'll help if I clarify what I was saying to <a class="gmail_plusreply" id="m_755086139635793918plusReplyChip-7" href="mailto:holo3146@gmail.com" target="_blank">@Holo The Sage Wolf</a>.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Holo is saying that they like the default joiner, but adding a timeout to it takes more code than necessary. They proposed multiple different overloads, but I suggested the following overload instead.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">StructuredTaskScope.open(UnaryOperator<StructuredTaskScope.Configuration> configOperator)</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">This uses the default joiner, but allows easy config of things like timeout or name. This is reasonable in my mind because most STS cases are "all or nothing". They don't want to change the joining behaviour, just the name or timeout. So, this is easy access to it.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Are you saying that this doesn't make sense, or there is something wrong with it? Or maybe it's not worth the weight?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 19, 2025 at 3:14 AM David Alayachew <<a href="mailto:davidalayachew@gmail.com" target="_blank">davidalayachew@gmail.com</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"><div dir="ltr"><div style="font-family:monospace">I don't understand your response to my quote <a class="gmail_plusreply" id="m_755086139635793918m_1968176150708877753plusReplyChip-5" href="mailto:Alan.Bateman@oracle.com" target="_blank">@Alan Bateman</a>.<br><br>> We held back from adding a 1-arg open method that takes a configuration<br>> function as it doubles down on the defaults.<br><br>I don't understand -- are you saying that doubling down on the defaults is a bad thing, and that's why you held back? Why would doubling down on the defaults be bad?<br><br>Or are you saying that you held back IN ORDER TO double down on the defaults? In which case, I understand what you mean by that even less.<br><br>> We are confident that the "all of nothing" case is the most important<br>> case, and this means the scope will be cancelled if any subtask fails.<br>> It is harder to get a sense as to whether subtasks produce results of<br>> the same type or different types, that is what determines if the default<br>> is allSuccessfulOrThrow [1] or awaitAllSuccessfulOrThrow [2].<br><br>The first sentence here makes sense (I even agree with you), but I don't see how it relates to the second sentence. Or how the second sentence is relevant to any part of my response.</div><div><span style="font-family:monospace"><br></span></div><div style="font-family:monospace">Did you maybe mean to respond to someone else besides me?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 19, 2025 at 1:49 AM Alan Bateman <<a href="mailto:alan.bateman@oracle.com" target="_blank">alan.bateman@oracle.com</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"><br>
<br>
On 18/12/2025 21:00, David Alayachew wrote:<br>
> :<br>
><br>
> That said, if you dislike a 0 parameter call being forced into being a <br>
> 2 paramefer call when you need to add timeout, then sure, I think <br>
> adding an overload for that static method that takes in the <br>
> configFunction is reasonable. I'd support that.<br>
><br>
The no-arg open method is the only method uses the default configuration <br>
and the "default" policy/joiner. We held back from adding a 1-arg open <br>
method that takes a configuration function as it doubles down on the <br>
defaults. We are confident that the "all of nothing" case is the most <br>
important case, and this means the scope will be cancelled if any <br>
subtask fails.  It is harder to get a sense as to whether subtasks <br>
produce results of the same type or different types, that is what <br>
determines if the default is allSuccessfulOrThrow [1] or <br>
awaitAllSuccessfulOrThrow [2].<br>
<br>
-Alan<br>
<br>
[1] <br>
<a href="https://download.java.net/java/early_access/jdk26/docs/api/java.base/java/util/concurrent/StructuredTaskScope.Joiner.html#allSuccessfulOrThrow()" rel="noreferrer" target="_blank">https://download.java.net/java/early_access/jdk26/docs/api/java.base/java/util/concurrent/StructuredTaskScope.Joiner.html#allSuccessfulOrThrow()</a><br>
[2] <br>
<a href="https://download.java.net/java/early_access/jdk26/docs/api/java.base/java/util/concurrent/StructuredTaskScope.Joiner.html#awaitAllSuccessfulOrThrow()" rel="noreferrer" target="_blank">https://download.java.net/java/early_access/jdk26/docs/api/java.base/java/util/concurrent/StructuredTaskScope.Joiner.html#awaitAllSuccessfulOrThrow()</a><br>
</blockquote></div></div>
</blockquote></div>
</div>