<div dir="ltr"><div dir="ltr"><p>Thank you for your response, Viktor. I appreciate you weighing in and clarifying the context of the design process, particularly your mention of having "exhausted the design space several times over" and the extensive prototyping, including for "functional combinators (composition of N-ary concurrent ANDs and ORs)."</p><p>I agree with you on the importance of real-world feedback and the need to tease apart API design discussions from observed user problems with a specific design. My feedback is rooted in the latter: user-observed problems with the current Structured Task Scope (STS) API's usability, specifically its complexity for the common "concurrent AND" use case.</p><p>Before diving into the specific points, I want to say that I do not intend to engage in open-ended design debates. I will not argue when it comes to value judgements. For example, if you tell me the team believe the OR use cases are critical despite I viewing them as niche, that's the difference I wanted to find and it's what I sent this email for.<br></p></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Oct 13, 2025 at 2:31 AM Viktor Klang <<a href="mailto:viktor.klang@oracle.com">viktor.klang@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"><div class="msg-2054287956530312890">
<div dir="ltr">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Let me just weigh in by saying that these kinds of conversations are not ideal if the goal is to make change happen—as mentioned previously, real-world feedback is what we've found (over decades) to be the most important kind of feedback to make change happen.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
For the current incarnation of Structured Concurrency, Alan and I have exhausted the design space several times over with tons of different prototypes, including functional combinators (composition of N-ary concurrent ANDs and ORs).</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Not only is the current Structured Concurrency APIs <i>not envisioned</i> to be the complete solution, also I believe it to be important to tease apart questions—are we having a discussion about API design and its trade-offs in general, or are we discussing
user-observed problems with a specific API design in particular?</div></div></div></blockquote><div><br></div><div><p>My primary argument is not that a better, more complete set of combinators exists, nor is it that the current design <i>should</i> support more use cases. In fact, it is the opposite.</p><p>My point is about <b>subtraction</b>—the potential to achieve a simpler, more intuitive API for the 80% use case by <b>deferring or omitting support for less common use cases</b>, such as the concurrent OR.</p><ul><li><p>Current Rationale Heard: The current, potentially complex, API is the best trade-off because it handles both ANDs and ORs after exploring all options.</p></li><li><p>My Question: Has a strategy of <i style="">doing less</i> been thoroughly explored and documented, and if so, <b>what were the specific trade-offs that compelled the inclusion of OR support, thus requiring a more complex imperative API for the AND use case?</b></p></li></ul></div><div><p>I believe the trade-off discussion I'm missing is the one that directly addresses the strawman I proposed:</p><ol start="1"><li><p>Introduce a simple, focused API for the common "concurrent AND" pattern (with reasonably overloaded arity):
</p><div class="gmail-math-block"><span class="gmail-katex-display"><span class="gmail-katex"><span class="gmail-katex-html" aria-hidden="true"><span class="gmail-base"><span class="gmail-strut" style="height:1em;vertical-align:-0.25em"></span><span class="gmail-mord gmail-text"><span class="gmail-mord">e.g., </span></span><span class="gmail-mord gmail-text"><span class="gmail-mord gmail-texttt">concurrently</span></span><span class="gmail-mopen">((</span><span class="gmail-mclose">)</span><span class="gmail-mspace" style="margin-right:0.2778em"></span><span class="gmail-mrel">→</span><span class="gmail-mspace" style="margin-right:0.2778em"></span></span><span class="gmail-base"><span class="gmail-strut" style="height:1em;vertical-align:-0.25em"></span><span class="gmail-mord gmail-text"><span class="gmail-mord">fetchArm</span></span><span class="gmail-mopen">(</span><span class="gmail-mclose">)</span><span class="gmail-mpunct">,</span><span class="gmail-mspace" style="margin-right:0.1667em"></span><span class="gmail-mopen">(</span><span class="gmail-mclose">)</span><span class="gmail-mspace" style="margin-right:0.2778em"></span><span class="gmail-mrel">→</span><span class="gmail-mspace" style="margin-right:0.2778em"></span></span><span class="gmail-base"><span class="gmail-strut" style="height:1em;vertical-align:-0.25em"></span><span class="gmail-mord gmail-text"><span class="gmail-mord">fetchLeg</span></span><span class="gmail-mopen">(</span><span class="gmail-mclose">)</span><span class="gmail-mpunct">,</span><span class="gmail-mspace" style="margin-right:0.1667em"></span><span class="gmail-mopen">(</span><span class="gmail-mord gmail-text"><span class="gmail-mord">arm, leg</span></span><span class="gmail-mclose">)</span><span class="gmail-mspace" style="margin-right:0.2778em"></span><span class="gmail-mrel">→</span><span class="gmail-mspace" style="margin-right:0.2778em"></span></span><span class="gmail-base"><span class="gmail-strut" style="height:1em;vertical-align:-0.25em"></span><span class="gmail-minner">…</span><span class="gmail-mspace" style="margin-right:0.1667em"></span><span class="gmail-mclose">)</span></span></span></span></span></div></li><li><p>Defer "concurrent OR" and other niche cases to a separate mechanism, perhaps a <b><code>mapConcurrent()</code> gatherer </b>(or sibling).</p></li></ol><p>With your earlier encouragement, I experimented with an alternative gatherer. And it seems to be able to support ORs reasonably. Maybe not the most convenient for all OR cases, but as I said, I view them as niche so a bit inconvenience is fine if it means the main SC API gets to stay simple.</p><p>If supporting the OR pattern via STS is deemed critical, it might be worth it to document the justification for paying the complexity cost in the primary API. What is the key use case or design constraint that makes it imperative to support ORs <i>within</i> the core Structured Task Scope API, instead of <i>separating</i>, deferring them?</p></div><div><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 class="msg-2054287956530312890"><div dir="ltr">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
The reason for separating those two is that the former is rather open-ended and its outcomes are rather limited in terms of impact, but the latter can lead to improvements for a large number of Java developers out there.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
To clarify, I don't want to sound dismissive, I want to make sure that everyone's time and effort is invested wisely.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Adding some additional details around Gatherers.mapConcurrent(…)—one of the main reasons that it currently does not participate in Structured Concurrency is because it is a continuous window of concurrent work-in-progress with no "singular join", i.e. it produces
results and starts new work whenever possible. This is further "complicated" by requiring that the results are produced on the calling thread to fit in with the evaluation model of the reference implementation of java.util.stream.Stream.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
As Alan said previously, we'd like for mapConcurrent to better integrate with Structured Concurrency, and we're considering the options there.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
As a personal anecdote, I had many situations in the evolution of this API where a solution would "intuitively" look better but it made something crucial either impossible or too easy to get wrong without noticing.</div>
<div id="m_-272097529576893380Signature">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Cheers,<br>
√</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<b><br>
</b></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<b>Viktor Klang</b></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Software Architect, Java Platform Group<br>
Oracle</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="text-align:left;margin-left:5pt;font-family:Calibri;font-size:10pt;color:rgb(0,0,0)">
Confidential – Oracle Internal</div>
</div>
<div id="m_-272097529576893380appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="m_-272097529576893380divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> loom-dev <<a href="mailto:loom-dev-retn@openjdk.org" target="_blank">loom-dev-retn@openjdk.org</a>> on behalf of Alan Bateman <<a href="mailto:alan.bateman@oracle.com" target="_blank">alan.bateman@oracle.com</a>><br>
<b>Sent:</b> Monday, 13 October 2025 08:38<br>
<b>To:</b> Jige Yu <<a href="mailto:yujige@gmail.com" target="_blank">yujige@gmail.com</a>><br>
<b>Cc:</b> <a href="mailto:loom-dev@openjdk.org" target="_blank">loom-dev@openjdk.org</a> <<a href="mailto:loom-dev@openjdk.org" target="_blank">loom-dev@openjdk.org</a>><br>
<b>Subject:</b> Re: Feedback on Structured Concurrency (JEP 525, 6th Preview)</font>
<div> </div>
</div>
<div><font size="2"><span style="font-size:11pt">
<div>On 13/10/2025 05:22, Jige Yu wrote:<br>
> :<br>
><br>
> And this is the direction I'd hope the Loom team can more seriously <br>
> entertain: put a strong constraint on the API's imperative power, run <br>
> a thought experiment to see if the functional variant could offer <br>
> sufficient flexibility under the constraint.<br>
><br>
I can't tell from your mails if you have read the JEP or not. We've <br>
tried to make it clear in every JEP that the goal is not to create the <br>
definitive structured concurrency API. This is an on-ramp API intended <br>
to "promote a style of concurrent programming that can eliminate common <br>
risks from cancellation and shutdown". Its sweet spot is in fan-out <br>
scenarios. Its deliberately imperative and kept as simple as possible. <br>
There will be other APIs. For example, we would like to bring channels <br>
based and other fan-in scenarios into the fold. We would like to <br>
eventually expose a lower level APIs for building other structured APIs <br>
outside of the JDK.<br>
<br>
On mapConcurrent. We've been around and around the topic of bringing it <br>
into the "structured fold". From your back and forth with Viktor on <br>
core-libs-dev then I think you understand the issues. When JEP 485 was <br>
preparing to make the gatherers API permanent it had to be decided if <br>
mapConcurrent should be pulled out. The conclusion was that it was <br>
useful enough as is, and we will look at improving or replacing it in <br>
the future. So yes, we of course want this, it's just not in the first API.<br>
<br>
-Alan<br>
</div>
</span></font></div>
</div>
</div></blockquote></div></div>