Simplifying sequential() / parallel()
brian.goetz at oracle.com
Fri Mar 22 09:59:08 PDT 2013
To add to this: while it may be possible for careful people to get away
with mutative tricks in flatMappers, I am not inclined to distort the
API at all to cater to that. We've done so much work to enable things
to be expressible in a safe functional style, it would be a shame to
make a U-turn and re-embrace statefulness.
We all know people will cheat, regardless of warnings. But the moral
hazard of catering to such cheating is huge, as it only leads to more
and more dangerous cheating. The primary reason to ban mutable capture
was not simply "mutation is bad", but that the 99% use case for mutable
capture -- accumulators -- had a better, safer, clearer, more
parallelizable solution in reduce.
So I am all for making streams work best when you follow the "no
stateful lambdas" rule, and have it *merely work* if you can ensure,
that for all time now and in the future, that you control the entire
pipeline and will never try to use parallelism. But I'm not even sure
we want to commit to saying that much.
On 3/22/2013 11:56 AM, Doug Lea wrote:
> On 03/22/13 10:07, Joe Bowbeer wrote:
>> Stateful programming has its issues but that ship has already sailed
>> (in Java).
> Although it is worth bearing in mind that most stream functionality
> wrt Collections exploits the fact that operations within
> traversals are already known to avoid some of the worst unexpected
> side-effects -- mutating a collection while you are traversing.
> Which normally leads to ConcurrentModificationException for
> iterators. A variant of this is preserved when applicable
> in Spliterator implementations. People learn quickly to avoid them.
> (That's the subject of some of the specs Paul Sandoz has been
> adding, which can't be nailed down very well in general because
> they are quality-of-implementation issues, but he is trying anyway :-)
> Anyway, as the chief advocate for cool mutative algorithmics
> in this group, I'm still in favor of saying they don't belong
> in any stream op not called forEach.
More information about the lambda-libs-spec-experts