[External] : Re: A new build and a new structured concurrency API

[Ron Pressler]

There are other reasons as well.

In most situations, you’ll want to do things like handle exceptions and process results after the join.
Requiring it in *all* cases is, therefore, not onerous and also serves as a reminder. I should point out
that there are many possible designs here, and we opted for one that offers a balance between providing the
benefits of structured concurrency — clear cancellation and error handling policy, clear expression of the
relationship among tasks — and offering something that would be familiar to Java programmers. Some other
designs — like close doing more work — or even using things other than TwR were clever and powerful, but
were judged to be too foreign for inclusion in the JDK, and not the right tool to teach people about the
principles of structured concurrency.

We figured that requiring the call to join in all situations might be a small annoyance when writing such
code for a day or so, but the resulting code would read more like code people already see.

— Ron

> On 16 Nov 2021, at 00:58, Eric Kolotyluk <eric at kolotyluk.net> wrote:
> 
> Okay, that makes more sense and satisfies my suspicions. Thanks...
> 
> For now, I can live with it, but this would be valuable insight to add to the JEP.
> 
> Cheers, Eric
> 
> On Mon, Nov 15, 2021 at 4:53 PM Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> 
> > On 15 Nov 2021, at 23:33, Eric Kolotyluk <eric at kolotyluk.net> wrote:
> > 
> > So, what is the rationale behind explicitly requiring 'join' or 'joinUntil'? Why can't close() at the end of the try-block implicitly deal with that?
> > 
> > Cheers, Eric
> 
> 
> That’s a good question!
> The rational is to deal with a current limitation of AutoCloseable — it cannot distinguish between the case where the try block
> terminates normally or exceptionally. This means that the implicit close would either have to cancel all tasks and then wait or
> just wait, regardless of whether an exception has been thrown. If we choose the former, there can be situations where a piece
> of code would just happen to work because the tasks happened to complete before close managed to cancel them, concealing a bug.
> If we chose the latter, an exception in the owner would result in all tasks still being waited for, which could also be confusing.
> 
> Requiring an explicit join avoids these problems. If the language is changed to make AutoCloseable more flexible, this requirement
> might be removed.
> 
> — Ron