filterKeys / filterValues

[Michael Nascimento]

On Thu, Apr 18, 2013 at 4:45 PM, Brian Goetz <brian.goetz at oracle.com> 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 =
>   docs.stream().groupBy(Doc::getAuthor) // MapStream<Author, List<Doc>>
>                .mapValues(v -> v.stream().map(Doc::pageCount).sum());
>
> Doing this as a reduce is just as simple and actually far more efficient
> (and more flexible too).
>
> Map<Author, Integer> totalPagesByAuthor =
>    docs.stream().collect(groupingBy(Doc::getAuthor),
>                                     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 :-)

Regards,
Michael