<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>