<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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);">
>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.</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: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Would you mind clariying <i>exactly</i> what you mean here—<b>what</b> happens-before completion/exception?</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: 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>
<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>
<hr style="display: inline-block; width: 98%;">
<div id="divRplyFwdMsg">
<div style="direction: ltr; font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<b>From:</b> Jige Yu <yujige@gmail.com><br>
<b>Sent:</b> Tuesday, 8 July 2025 04:26<br>
<b>To:</b> Viktor Klang <viktor.klang@oracle.com><br>
<b>Cc:</b> core-libs-dev@openjdk.org <core-libs-dev@openjdk.org><br>
<b>Subject:</b> [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees</div>
<div style="direction: ltr;"> </div>
</div>
<div style="direction: ltr;">Thanks for the quick reply, Viktor!</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">On Mon, Jul 7, 2025 at 2:35 AM Viktor Klang <<a href="mailto:viktor.klang@oracle.com" id="OWA03733348-faf5-1f9c-7469-0fc114618627" class="OWAAutoLink">viktor.klang@oracle.com</a>> wrote:</div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);">
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Jige,</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; 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="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; 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>
</blockquote>
<div style="direction: ltr;"><br>
</div>
<p class="elementToProof" style="direction: ltr;">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 style="direction: ltr;">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>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);">
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; 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>
</blockquote>
<div style="direction: ltr;"><br>
</div>
<p style="direction: ltr;">Yeah. I agree that hooking into <code>onClose()</code> could provide a more reliable mechanism for cleanup.</p>
<p style="direction: ltr;">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 style="direction: ltr;">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>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);">
<div id="x_m_3888783633770680312Signature">
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Cheers,<br>
√</div>
<div style="direction: ltr; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b><br>
</b></div>
<div style="direction: ltr; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b>Viktor Klang</b></div>
<div style="direction: ltr; 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="x_m_3888783633770680312appendonsend"></div>
<hr style="direction: ltr; display: inline-block; width: 98%;">
<div id="x_m_3888783633770680312divRplyFwdMsg">
<div style="direction: ltr; font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<b>From:</b> core-libs-dev <<a href="mailto:core-libs-dev-retn@openjdk.org" id="OWA9a0f1614-0d0e-45ff-bf44-ac9d53989e80" class="OWAAutoLink">core-libs-dev-retn@openjdk.org</a>> on behalf of Jige Yu <<a href="mailto:yujige@gmail.com" id="OWA665e320d-1bba-87cf-926a-de0761f52291" class="OWAAutoLink">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" id="OWA9e722186-0c4f-3c81-ee03-46462c9ec9bf" class="OWAAutoLink">
core-libs-dev@openjdk.org</a> <<a href="mailto:core-libs-dev@openjdk.org" id="OWA4899b1d3-1eb1-020f-c1ea-a1e4f2797e52" class="OWAAutoLink">core-libs-dev@openjdk.org</a>><br>
<b>Subject:</b> Question about mapConcurrent() Behavior and Happens-Before Guarantees</div>
<div style="direction: ltr;"> </div>
</div>
<p style="direction: ltr;">Hi JDK Core Devs,</p>
<p style="direction: ltr;">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 style="direction: ltr;">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 style="direction: ltr;">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 style="direction: ltr;">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 style="direction: ltr;">This brings me to my core questions:</p>
<ol start="1" style="direction: ltr;">
<li>
<p role="presentation" style="direction: ltr;">Is providing a happens-before guarantee upon an unchecked exception a design goal for
<code>mapConcurrent()</code>?</p>
</li><li>
<p role="presentation" style="direction: ltr;">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 style="direction: ltr;">Thank you for your time and insights.</p>
<p style="direction: ltr;">Best regards,</p>
<p style="direction: ltr;">Ben Yu</p>
</blockquote>
</body>
</html>