RFR: JDK-8205461 Create Collector which merges results of two other collectors (original) (raw)

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 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.

More information about the core-libs-dev mailing list