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,