Add MoreStream utility methods that accept future suppliers #329
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently the non-deprecated versions of
inCompletionOrder
andblockingStreamWithParallelism
require a an executor to run each transformation on, which means that that transformation will be a blocking call. This is not ideal when the actual call is itself async (i.e. hitting a method which returns aListenableFuture
already). This PR adds versions of those methods that require a future supplier, that is a method that transforms the keys into the listenable futures of the result. This method will be called by the thread that is pulling from the Stream.This is similar to earlier problematic methods that accepted an input a stream of futures. Those were deprecated because they did not enforce actual max parallelism. That is, the underlying stream supplier may kick off more futures than the parallelism intended to allow. I believe this solution avoids those issues because we only create new futures from within the buffering spliterator, which enforces the max parallelism.