filterKeys / filterValues

Michael Nascimento misterm at
Thu Apr 18 12:52:26 PDT 2013

On Thu, Apr 18, 2013 at 4:45 PM, Brian Goetz <brian.goetz at> wrote:
> Theoretically.  We abandoned it in part because the marginal costs and
> marginal benefits were not aligned; we'd have to be convinced that something
> has changed on one side or the other.
> For what its worth, we gathered a lot of uses cases for MapStream and found
> that the vast majority were better served by what has now become Collector.
> For example, the most commonly suggested use case was tabulations like:
> Map<Author, Integer> totalPagesByAuthor =
> // MapStream<Author, List<Doc>>
>                .mapValues(v ->;
> Doing this as a reduce is just as simple and actually far more efficient
> (and more flexible too).
> Map<Author, Integer> totalPagesByAuthor =
>                                     sumBy(Doc::getPageCount)));
> When we saw that what seemed like 90% of the use cases were better served by
> better combinators for reduction, the return-on-complexity took a nose dive.
> Some of the remaining use cases are acceptably served by streams of
> Map.Entry (though this is clearly a slippery slope since once you stray off
> the happy path it gets hostile fast.)
> So given the substantial incremental cost in complexity and code size, we're
> still looking for killer use cases that would justify this.

Thanks for the explanation. When I finish my migration work, I will
categorize and quantify all my uses of entrySet().parallelStream() in
order to produce use cases :-)


More information about the lambda-dev mailing list