filterKeys / filterValues

Brian Goetz brian.goetz at
Thu Apr 18 12:45:51 PDT 2013

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 

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 =,

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.

On 4/18/2013 3:19 PM, Michael Nascimento wrote:
> Is MapStream theoretically possible in Java SE 9?
> Regards,
> Michael
> On Thu, Apr 18, 2013 at 4:14 PM, Brian Goetz <brian.goetz at> wrote:
>> Follow this one through.  What would it return?  If we had that, what else
>> would we be committing to have?
>> I think the end of that road is MapStream, which we spent a lot of time
>> exploring and eventually retreated from.
>> On 4/18/2013 2:42 PM, Michael Nascimento wrote:
>>> Hi guys,
>>> Have methods such as filterKeys(Predicate<? super K>) /
>>> filterValues(Predicate<? super V>) been considered for Maps?
>>> Regards,
>>> Michael

More information about the lambda-dev mailing list