Structured Concurrency yet again

[Ron Pressler]

> On 10 May 2023, at 12:34, Alan Bateman <alan.bateman at oracle.com> wrote:
>> I would prefer to provide an API easier to use. I believe that having a method join() that takes a function that takes a stream is easier to use correctly.
> We were down that road before when the prototype was based on ES. 

Exactly. Since we tried quite a few things and STS is expected to start Preview, I think we should let actual problems people encounter with the API inform its evolution (as was the case with ditching Future as fork’s return type), especially because SC is not quite mainstream yet. I think STS is a good API to preview because I find it to strike a nice balance between simplicity and flexibility; it’s neither too high-level nor too low-level. So I think it can teach us about how people may use SC in the field while actually being useful to them.

We have ideas for other structured-concurrency APIs (e.g. stream-based) that could be provided in addition to STS to make some common cases even more pleasant, so it’s quite possible that STS will not be the last word the JDK says on the subject of structured concurrency.

— Ron