Hi!
In a similar vein to the built-in Collectors,
the built-in Gatherers provide solutions to common stream-related problems, but
also, they also serve as "inspiration" for developers for what is possible to
implement using Gatherers.
If someone, for performance reasons, and with a use-case which does not require
encounter-order, want to take advantage of that combination of circumstances,
it is definitely possible to implement your own Gatherer which has that
behavior.
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-r...@openjdk.org> on behalf of Jige Yu
<yuj...@gmail.com>
Sent: Sunday, 1 June 2025 21:08
To: core-libs-dev@openjdk.org <core-libs-dev@openjdk.org>
Subject: Should mapConcurrent() respect time order instead of input order?
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,
