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

Brian Goetz brian.goetz at oracle.com
Tue Aug 7 16:22:04 UTC 2018

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 

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 

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.

More information about the core-libs-dev mailing list