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.
