<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Looks good... thanks.</p>
    <p>One slight area of confusion for me was, <br>
    </p>
    <pre><code><T> List<Future<T>> executeAll(List<Callable<T>> tasks)
        throws InterruptedException {
    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
          List<? extends Supplier<Future<T>>> futures = tasks.stream()
              .map(task -> asFuture(task))
              .map(scope::fork)
              .toList();
          scope.join();
          return futures.stream().map(Supplier::get).toList();
    }
}

static <T> Callable<Future<T>> asFuture(Callable<T> task) {
   return () -> {
       try {
           return CompletableFuture.completedFuture(task.call());
       } catch (Exception ex) {
           return CompletableFuture.failedFuture(ex);
       }
   };
}</code></pre>
    <p></p>
    <p>And what happens if <code>ShutdownOnSuccess</code> is called
      instead. Eventually I reasoned that the right thing should happen,
      but there should only ever be one element in the list. Does the
      scope guarantee only one result?<br>
    </p>
    <ol>
      <li>It would be slightly helpful to point this out in a note so
        that it is more obvious.</li>
      <li>What is less obvious is that with <code>ShutdownOnSuccess</code>
        what happens if one or more of the siblings throw an exception?</li>
      <ul>
        <li>I would hope that so long at least one task succeeds, this
          should not cause the overall success of the scope to fail.</li>
        <li>It would be nice to see this explained more clearly.</li>
        <li> Maybe <code>ShutdownOnSuccess</code> deserves its own
          example, discussing possible edge cases.</li>
      </ul>
    </ol>
    <p>Somehow I am remembering Scala 'for comprehensions' with
      concurrent tasks that 'yield' a result... 😉</p>
    <p>The current situation seems kinda clunky with using one stream to
      collect futures, and yet another stream to collect results. Maybe
      one of the Java architects hates such boilerplate, and will come
      up with an elegant way to reduce/remove such boilerplate.<br>
    </p>
    <p>Sincerely, Eric<br>
    </p>
    <div class="moz-cite-prefix">On 2023-10-27 7:39 a.m., Mark Reinhold
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20231027143909.0F1F464C585@eggemoggin.niobe.net">
      <pre class="moz-quote-pre" wrap=""><a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/462">https://openjdk.org/jeps/462</a>

  Summary: Simplify concurrent programming by introducing an API for
  structured concurrency. Structured concurrency treats groups of related
  tasks running in different threads as a single unit of work, thereby
  streamlining error handling and cancellation, improving reliability,
  and enhancing observability. This is a preview API.

- Mark</pre>
    </blockquote>
  </body>
</html>