<div dir="ltr"><div dir="ltr">Thanks for the quick reply, Viktor!</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jul 7, 2025 at 2:35 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-912586991015303686">




<div dir="ltr">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Hi Jige,</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)">
>Initially, I thought this design choice might provide a strong happens-before guarantee. My assumption was that an application catching a
<code>RuntimeException</code> would be able to <b>observe all side effects</b> from the virtual threads, even though this practice is generally discouraged. This seemed like a potentially significant advantage, outweighing the risk of a virtual thread failing
 to respond to interruption or responding slowly.</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)">
Unless explicitly stated in the API contract, no such guarantees should be presumed to exist.</div></div></div></blockquote><div><br></div><div><p>I understand that explicit API contracts are what matters. My concern, however, is that even if the API contract explicitly states <i>no</i> happens-before guarantee upon an unchecked exception, this behavior would still be a significant deviation from established visibility standards in other JDK APIs.</p><p>For instance, both <b>parallel streams</b> and <code>Future.get()</code> provide a happens-before guarantee upon completion (or exceptional completion in the case of <code>Future.get()</code>). So users will most likely take it for granted. If <code>mapConcurrent()</code> were to <i>not</i> offer this, it would potentially be the <b>first blocking JDK API that doesn't honor happens-before</b> in such a scenario. This inconsistency would likely be surprising and potentially confusing to users who have come to expect this behavior in concurrent programming constructs within the JDK.</p></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-912586991015303686"><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)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
As for general resource-management in Stream, I have contemplated designs for Gatherer (and Collector) to be able to participate in the onClose actions, but there's a lot of ground to cover to ensure correct ordering and sufficiently-encompassing of cleanup
 action execution.</div></div></div></blockquote><div><br></div><div><p>Yeah. I agree that hooking into <code>onClose()</code> could provide a more reliable mechanism for cleanup.</p><p>My primary concern though, is the change it imposes on the call-site contract. Requiring all users of <code>mapConcurrent()</code> to adopt a <code>try-with-resources</code> syntax, while ideal for correctness, introduces a burden and is more subject to users forgetting to do so, potentially leading to resource leaks.</p><p>My previously proposed <code>collectingAndThen(toList(), list -> list.stream().gather(mapConcurrent()))</code> idea, on the other hand, avoids this call-site contract change. Being a collector, it needs to first consume the input, similar to how most <code>Collector</code>s operate. So it might be a less intrusive path to ensure proper resource handling without altering usage patterns.</p></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-912586991015303686"><div dir="ltr">
<div id="m_3888783633770680312Signature">
<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>
<div id="m_3888783633770680312appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="m_3888783633770680312divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> core-libs-dev <<a href="mailto:core-libs-dev-retn@openjdk.org" target="_blank">core-libs-dev-retn@openjdk.org</a>> on behalf of Jige Yu <<a href="mailto:yujige@gmail.com" target="_blank">yujige@gmail.com</a>><br>
<b>Sent:</b> Thursday, 3 July 2025 16:36<br>
<b>To:</b> <a href="mailto:core-libs-dev@openjdk.org" target="_blank">core-libs-dev@openjdk.org</a> <<a href="mailto:core-libs-dev@openjdk.org" target="_blank">core-libs-dev@openjdk.org</a>><br>
<b>Subject:</b> Question about mapConcurrent() Behavior and Happens-Before Guarantees</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<p>Hi JDK Core Devs,</p>
<p>I'm writing to you today with a question about the behavior of <code>mapConcurrent()</code> and its interaction with unchecked exceptions. I've been experimenting with the API and observed that
<code>mapConcurrent()</code> blocks and joins all virtual threads upon an unchecked exception before propagating it.</p>
<p>Initially, I thought this design choice might provide a strong happens-before guarantee. My assumption was that an application catching a
<code>RuntimeException</code> would be able to <b>observe all side effects</b> from the virtual threads, even though this practice is generally discouraged. This seemed like a potentially significant advantage, outweighing the risk of a virtual thread failing
 to respond to interruption or responding slowly.</p>
<p>However, I've since realized that <code>mapConcurrent()</code> cannot fully guarantee a strong happens-before relationship when an unchecked exception occurs
<i>somewhere</i> in the stream pipeline. While it can block and wait for exceptions thrown by the mapper function or downstream operations, it appears unable to intercept unchecked exceptions
<b>thrown by an upstream</b> source.</p>
<p>Consider a scenario with two input elements: if the first element starts a virtual thread, and then the second element causes an unchecked exception from the upstream
<i>before</i> reaching the <code>gather()</code> call, the virtual thread initiated by the first element would not be interrupted. This makes the "happens-before" guarantee quite nuanced in practice.</p>
<p>This brings me to my core questions:</p>
<ol start="1">
<li>
<p>Is providing a happens-before guarantee upon an unchecked exception a design goal for
<code>mapConcurrent()</code>?</p>
</li><li>
<p>If not, would it be more desirable to <i>not</i> join on virtual threads when unchecked exceptions occur? This would allow the application code to catch the exception sooner and avoid the risk of being blocked indefinitely.</p>
</li></ol>
<p>Thank you for your time and insights.</p>
<p>Best regards,</p>
<p>Ben Yu</p>
</div>
</div>
</div>

</div></blockquote></div></div>