Use of HashMap in Stream functions: is there a better way?

[Brian Goetz]

> there is something in the Stream-API that I find a little awkward:
> All of Stream's methods either return other Streams, which can be seen
> as views of the original Stream, or final types such as boolean or Optional.

Yes, we find it awkward too.  We went around and around with many 
variants and eventually settled on this as the lesser of evils.  (Even 
when MapStream was around, there was still a good argument to be made 
that it should return a Map and not a MapStream, since the 
implementation has to create a Map anyway, and forcing the user to pay 
the cost of an into(Map) to get at it seemed excessive.)

There are some things our our list to explore making this better, such as:
  - Define an interface more like Stream.Destination, as we did for 
into(), as you allude to;
  - Provide alternate entry points that allow the user to pass a Map in 
to receive the results (as well as factories for the per-key 
Collections), like into() does.

> The only thing missing for this would be a "java.util.MultiMap" - but
> isn't that long overdue anyway?

We've considered it many times.  But, each time, we look at the 
thrust-to-weight ratio (look at the total size of the Guava MultiXxx 
classes as a proxy for weight), and it never quite makes the cut.

In any case, there's no chance to add a big new feature like this into 
the 8 bucket.