<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=koi8-r">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Jige,</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" 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 class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" 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 class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" 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 id="Signature" class="elementToProof">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Cheers,<br>
–</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b><br>
</b></div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b>Viktor Klang</b></div>
<div class="elementToProof" 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="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> core-libs-dev <core-libs-dev-retn@openjdk.org> on behalf of Jige Yu <yujige@gmail.com><br>
<b>Sent:</b> Thursday, 3 July 2025 16:36<br>
<b>To:</b> core-libs-dev@openjdk.org <core-libs-dev@openjdk.org><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>
</body>
</html>