<div dir="ltr"><div class="gmail_default" style="font-family:monospace">> 
The current situation seems kinda clunky with</div><div class="gmail_default" style="font-family:monospace">> using one stream to
      collect futures, and yet</div><div class="gmail_default" style="font-family:monospace">> another stream to collect results. Maybe
      one</div><div class="gmail_default" style="font-family:monospace">> of the Java architects hates such boilerplate,</div><div class="gmail_default" style="font-family:monospace">> and will come
      up with an elegant way to</div><div class="gmail_default" style="font-family:monospace">> reduce/remove such boilerplate. <br></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I can sympathize, but I think it is clearer this way. It's obvious from a glance that all the work of scope forking occurs before performing a join. And a join occurs before any of the tasks have get called on them.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I struggle to see a way to join that into one stream while maintaining that clarity.<br></div><div class="gmail_default" style="font-family:monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 27, 2023 at 12:37 PM Eric Kolotyluk <<a href="mailto:eric@kolotyluk.net">eric@kolotyluk.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div>
    <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>On 2023-10-27 7:39 a.m., Mark Reinhold
      wrote:<br>
    </div>
    <blockquote type="cite">
      <pre><a href="https://openjdk.org/jeps/462" target="_blank">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>
  </div>

</blockquote></div>