Should mapConcurrent() respect time order instead of input order?

[Jige Yu]

It seems like for most people, input order isn't that important for
concurrent work, and concurrent results being in non-deterministic order is
often expected.

If mapConcurrent() just respect output encounter order:

It'll be able to achieve *higher throughput* if an early task is slow, For
example, with concurrency=2, and if the first task takes 10 minutes to run,
mapConcurrent() would only be able to process 2 tasks within the first 10
minutes; whereas with encounter order, the first task being slow doesn't
block the 3rd - 100th elements from being processed and output.

mapConcurrent() can be used to implement useful concurrent semantics, for
example to *support race* semantics. Imagine if I need to send request to
10 candidate backends and take whichever that succeeds first, I'd be able
to do:

backends.stream()
    .gather(mapConcurrent(
        backend -> {
          try {
            return backend.fetchOrder();
           } catch (RpcException e) {
             return null; // failed to fetch but not fatal
           }
        })
        .filter(Objects::notNull)
        .findFirst(); // first success then cancel the rest


Cheers,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250601/ad1e5d31/attachment-0001.htm>