Why is the combiner of the Collector interface not consistent with the overloaded collect method?

Question

There is an overload method, collect(), in interface Stream<T> with the following signature:

<R> R collect(Supplier<R> supplier,           BiConsumer<R,? super T> accumulator,           BiConsumer<R,R> combiner) 

There is another version of collect(Collector<? super T,A,R> collector), which receives an object with the previous three functions. The property of the interface Collector corresponding to the combiner has the signature BinaryOperator<A> combiner().

In the latter case, the Java API 8 states that:

The combiner function may fold state from one argument into the other and return that, or may return a new result container.

Why does the former collect method not receive a BinaryOperator<R> too?

Answer 1

The "inline" (3-arg) version of collect is designed for when you already have these functions "lying around". For example:

ArrayList<Foo> list = stream.collect(ArrayList::new,                                       ArrayList::add,                                      ArrayList::addAll); 

Or

BitSet bitset = stream.collect(BitSet::new,                                 BitSet::set,                                BitSet::or); 

While these are just motivating examples, our explorations with similar existing builder classes was that the signatures of the existing combiner candidates were more suited to conversion to BiConsumer than to BinaryOperator. Offering the "flexibility" you ask for would make this overload far less useful in the very cases it was designed to support -- which is when you've already got the functions lying around, and you don't want to have to make (or learn about making) a Collector just to collect them.

Collector, on the other hand, has a far wider range of uses, and so merits the additional flexibility.