Feedback on Structured Concurrency (JEP 525, 6th Preview)

[Alan Bateman]

On 13/10/2025 05:22, Jige Yu wrote:
> :
>
> And this is the direction I'd hope the Loom team can more seriously 
> entertain: put a strong constraint on the API's imperative power, run 
> a thought experiment to see if the functional variant could offer 
> sufficient flexibility under the constraint.
>
I can't tell from your mails if you have read the JEP or not. We've 
tried to make it clear in every JEP that the goal is not to create the 
definitive structured concurrency API. This is an on-ramp API intended 
to "promote a style of concurrent programming that can eliminate common 
risks from cancellation and shutdown".  Its sweet spot is in fan-out 
scenarios. Its deliberately imperative and kept as simple as possible.  
There will be other APIs. For example, we would like to bring channels 
based and other fan-in scenarios into the fold. We would like to 
eventually expose a lower level APIs for building other structured APIs 
outside of the JDK.

On mapConcurrent. We've been around and around the topic of bringing it 
into the "structured fold".  From your back and forth with Viktor on 
core-libs-dev then I think you understand the issues.  When JEP 485 was 
preparing to make the gatherers API permanent it had to be decided if 
mapConcurrent should be pulled out. The conclusion was that it was 
useful enough as is, and we will look at improving or replacing it in 
the future. So yes, we of course want this, it's just not in the first API.

-Alan