java.util.stream.Stream: API for user-extensible intermediate operations

Brian Goetz brian.goetz at oracle.com
Thu Jun 29 13:11:51 UTC 2023


Please be mindful of the request Viktor made: for feedback on the 
approach and the API concepts.  It should be pretty clear that low-level 
details like "unsupportedCombiner" are many levels down below "approach 
and concepts".  (And, you know the rule: when you bikeshed on a 
low-level detail when asked for high-level comments, you've forfeited 
the right to have further opinions about the concepts.)

In any case, I think your high-level comments seem to be: you prefer a 
direction where, rather than creating new possibly-stateful, 
possibly-not-parallel ops, instead beef up Collector and let people 
start a new stream.

On 6/29/2023 8:13 AM, forax at univ-mlv.fr wrote:
>
>
>     >The idea of unsupportedCombiner() seems out of place, like a
>     patch to be able to clobble different things together. I'm not
>     sure to understand why it's needed for a Gatherer, and why it is
>     not needed for Collectors ?
>
>     Nothing prevents us from treating a `null` combiner the same way.
>     My primary reason for making it a dedicated thing was to be able
>     to differentiate a possible bug (user passing in a null reference
>     inadvertently) from explicitly stating that a combiner does not
>     exist from this operation.
>
>     /unsupportedCombiner()/ as an artifact can be completely hidden if
>     desired, as /Gatherer.of()/ can have permutations without
>     specifying a combiner, and the /default method/ of
>     Gatherer.combiner() could return /unsupportedCombiner()/. I opted
>     not to do this initially, because I felt like being explicit about
>     not having a combiner means that it is a concious decision by the
>     implementor of the Gatherer.
>
>
> My question is more, why do we need this unsupportedCombiner on a 
> Gatherer and not on a Collector ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230629/0b4fa00f/attachment.htm>


More information about the core-libs-dev mailing list