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:
bisecting - by Paul Sandoz (sounds like input is split by two parts
like
in partitioningBy, which is not the case)
tee or teeing - by Brian Goetz (IIUC from the T shape, it's
assymmetrical
operation, while our collector is symmetrical)
duplex(ing) - by Jacob Glickman (well, probably ok?)
bifurcate - by James Laskey (or bifurcating?)
replicator - by James Laskey (as in DNA)
replicating - by Peter Levart
fanout or fanningOut - Chris Hegarty (sounds cryptic to me, checked
Wikipedia [2], does not look like suitable)
distributing - by Brian Goetz (like in distributive law a(b+c) = ab+ac;
but common meaning of "distributing" is different)
tapping - by Kirk Pepperdine (I have no associations; Google images
shows
some acupuncture procedures)
split - by Kirk Pepperdine (may be confused with Spliterator)
unzipping - by John Rose
biMapping - by Zheka Kozlov (but he also suggests to change signature
which is unnecessary)
toBoth - by Peter Levart (but usually toXyz shows target container like
toArray/toList/toSet, but there's not "Both" container)
collectionToBothAndThen - by Zheka Kozlov (but too long)
collectingToBoth - by Zheka Kozlov
collectingTo - by Brian Goetz (isn't collect(collectingTo(...)) a
little
bit repititive?)
biCollecting - by Zheka Kozlov
expanding - by Paul Sandoz (doesn't sound very descriptive to me)
forking - by Victor Williams Stafusa da Silva (could be thought that
something is parallelized as forking is usually something connected to
parallel computations)
I think that it's better to concentrate not on the "splitting" part
(each
element is passed to two collectors), but on the "joining" part
(results of
two collectors are combined together). So my preference now is
"merging" or
"combining". If limiting the selection to the suggested options I'd
prefer
"duplexing" or "bifurcating" or to stay with my original version
"pairing".
Of course original Stream API author voices have more weight here,
so if
you insist on particular version, I will follow.
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
2. In many methods redundant `throws ReflectiveOperationException` is
declared while exception is never thrown
3. The `if (!Map.class.isAssignableFrom(map.getClass()))` looks
useless as
`map` is already of `Map<Boolean, D>` type, so this check is always
false
(we would never enter this method if it's true). Similarly `if
(!List.class.isAssignableFrom(value.getClass()))`
4. Deprecated `clazz.newInstance()` is used
5. Test named `testGroupubgByWithReducing` should be renamed to
`testGroupingByWithReducing`
Should I fix some or all of these issues? As separate changeset or
within
this one?
With best regards,
Tagir Valeev.
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053718.html
[2] https://en.wikipedia.org/wiki/Fan-out
