BiCollector

[Brian Goetz]

> Well, I don't see the need to pack the two results into a Map.Entry 
> (or any similar) container as a drawback. 

 From an "integrity of the JDK APIs" perspective, it is unquestionably a 
drawback.  These items are not a Key and an associated Value in a Map; 
it's merely pretending that Map.Entry really means "Pair".  There's a 
reason we don't have a Pair class in the JDK (and no, let's not reopen 
that now); using something else as a Pair proxy that is supposed to have 
specific semantics is worse. (It's fine to do this in your own code, but 
not in the JDK. Different standards for code that has different audiences.)

Tagir's proposed sidestepping is nice, and it will also play nicely with 
records, because then you can say:

      record NameAndCount(String name, int count);

      stream.collect(pairing(collectName, collectCount, NameAndCount::new));

and get a more properly abstract result out.  And its more in the spirit 
of existing Collectors.  If you want to use Map.Entry as an 
_implementation detail_, that's fine.

I can support this form.

> I also don't see a larger abstraction like BiStream as a natural fit 
> for a similar thing. 

I think the BiStream connection is mostly tangential.  We tried hard to 
support streams of (K,V) pairs when we did streams, as Paul can attest, 
but it was a huge complexity-inflater and dropping this out paid an 
enormous simplification payoff.

With records, having streams of tuples will be simpler to represent, but 
no more performant; it will take until we get to value types and 
specialized generics to get the performance we want out of this.