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

[Viktor Klang]

Let me just weigh in by saying that these kinds of conversations are not ideal if the goal is to make change happen—as mentioned previously, real-world feedback is what we've found (over decades) to be the most important kind of feedback to make change happen.

For the current incarnation of Structured Concurrency, Alan and I have exhausted the design space several times over with tons of different prototypes, including functional combinators (composition of N-ary concurrent ANDs and ORs).

Not only is the current Structured Concurrency APIs not envisioned to be the complete solution, also I believe it to be important to tease apart questions—are we having a discussion about API design and its trade-offs in general, or are we discussing user-observed problems with a specific API design in particular?

The reason for separating those two is that the former is rather open-ended and its outcomes are rather limited in terms of impact, but the latter can lead to improvements for a large number of Java developers out there.

To clarify, I don't want to sound dismissive, I want to make sure that everyone's time and effort is invested wisely.

Adding some additional details around Gatherers.mapConcurrent(…)—one of the main reasons that it currently does not participate in Structured Concurrency is because it is a continuous window of concurrent work-in-progress with no "singular join", i.e. it produces results and starts new work whenever possible. This is further "complicated" by requiring that the results are produced on the calling thread to fit in with the evaluation model of the reference implementation of java.util.stream.Stream.

As Alan said previously, we'd like for mapConcurrent to better integrate with Structured Concurrency, and we're considering the options there.

As a personal anecdote, I had many situations in the evolution of this API where a solution would "intuitively" look better but it made something crucial either impossible or too easy to get wrong without noticing.

Cheers,
√


Viktor Klang
Software Architect, Java Platform Group
Oracle

Confidential – Oracle Internal
________________________________
From: loom-dev <loom-dev-retn at openjdk.org> on behalf of Alan Bateman <alan.bateman at oracle.com>
Sent: Monday, 13 October 2025 08:38
To: Jige Yu <yujige at gmail.com>
Cc: loom-dev at openjdk.org <loom-dev at openjdk.org>
Subject: Re: Feedback on Structured Concurrency (JEP 525, 6th Preview)

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20251013/a9e948d0/attachment-0001.htm>