parallelStream() methods (original) (raw)

Brian Goetz brian.goetz at oracle.com
Sat Feb 9 08:31:52 PST 2013

Here's another breach in my promise not to have an opinion about anything in the Steam API: I think "parallelStream()" is much nicer than "stream().parallel()".

I do too, but I also recognize that is mostly just taste and we could get used to either. But, let's turn the question around, because we have an inconsistent API right now with respect to stream constructors, and we should decide whether we want to choose that deliberately (which I think is fine), or go one way or the other.

We have a number of factories in Streams like:

Streams.intRange(from, to) Streams.generate(T, UnaryOperator)

We do not have explicit parallel versions of each of these; we did originally, and to prune down the API surface area, we cut them on the theory that dropping 20+ methods from the API was worth the tradeoff of the surface yuckiness and performance cost of .intRange(...).parallel(). But we did not make that choice with Collection.

We could either remove the Collection.parallelStream(), or we could add the parallel versions of all the generators, or we could do nothing and leave it as is. I think all are justifiable on API design grounds.

I kind of like the status quo, despite its inconsistency. Instead of having 2N stream construction methods, we have N+1 -- but that extra 1 covers a huge number of cases, because it is inherited by every Collection. So I can justify to myself why having that extra 1 method is worth it, and why accepting the inconsistency of going no further is acceptable.

Do others disagree? Is N+1 the practical choice here? Or should we go for the purity of N? Or the convenience and consistency of 2N? Or is there some even better N+3, for some other specially chosen cases we want to give special support to?

More information about the lambda-libs-spec-observers mailing list