stream() / parallelStream() methods
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:
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
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