RFR: JDK-8205461 Create Collector which merges results of two other collectors

[Brian Goetz]

On 6/21/2018 12:33 AM, Tagir Valeev wrote:
> Please review and sponsor:
>
> https://bugs.openjdk.java.net/browse/JDK-8205461
> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r1/
>
> See also previous discussion thread at [1]. It seems that we did not reach
> the final conclusion about the collector name, so in this review it's still
> named as "pairing" (proposed by me). Other name proposals:

None of the names so far are great.  The essential challenge in naming 
here is that this Collector does two (or maybe three) things: duplicate 
the stream into two identical streams ("tee"), sends each element to the 
two collectors ("collecting"), and then combines the results 
("finishing").  So all the one-word names (pairing, teeing, unzipping, 
biMapping) only emphasize one half of the operation, and names that 
capture the full workflow accurately (teeingAndCollectingAndThen) are 
unwieldy.

Of the three phases, teeing is the most important and least obvious, so 
I think something that includes that in the name is going to be 
helpful.  Perhaps "teeingAndThen" is more evocative and not totally 
unwieldy.

Names along the lines of "merging" may incorrectly give the idea that 
the merge is happening elementwise, rather than duplicating the streams, 
collecting, and merging the results.

> By the way looking into CollectorsTest.java I found some minor things to
> cleanup:
> 1. `.map(mapper::apply)` and `.flatMap(mapper::apply)` can be replaced with
> simple `.map(mapper)` and `.flatMap(mapper)` respectively
Does IntelliJ have an inspection for eliminating such locutions?
> 2. In many methods redundant `throws ReflectiveOperationException` is
> declared while exception is never thrown
For test code where a significant fraction of test cases are going to 
throw something, we often do this, since its easier to just uniformly 
tag such methods rather than thinking about which test methods actually 
throw the exception and which don't.  So I think this is harmless 
(though cleaning it up is harmless too.)


You may want to optimize the EnumSet mechanics for the case where 
neither collector has interesting characteristics.