Tabulators -- a catalog (original) (raw)

Brian Goetz brian.goetz at oracle.com
Fri Dec 28 12:29:26 PST 2012

The framework ensures that instances of the mutable objects are not shared while the operation is in place, so this collapses to the same old non-interference requirement as we place on mutable sources like ArrayList.

There are lots of things in Java where the only efficient way to do something is mutation. String concat is an example. We could do a functional reduce with String::concat, but it would suck:

strings.reduce("", String::concat) // O(n^2) !

We can do a mutable reduce, safely, with:

strings.reduce(StringBuilder::new, StringBuilder::add, StringBuilder::add)

and get much nicer behavior.

Encouraging users to use parallel forEach loops is far more likely to result in races/inefficiency than mutable reduction!

And in this particular case, string concatenation must respect order (String.concat is associative but not commutative) making parallel forEach the wrong tool. This is naturally a reduction.

On 12/28/2012 3:14 PM, Doug Lea wrote:

On 12/27/12 21:23, Brian Goetz wrote:

Here's a catalog of the currently implemented Tabulators. Sorry for the protracted grumpiness about Reducers/Tabulators, but even if I ignore my other reservations, MutableReduce remains the which-one-doesn't-belong here-winner. Between all the concerns about making racy/concurrent mutability too easy to do by mistake, and the fact that the implementations should be at least as easy for users to code directly using seq/par forEach loops, I don't see the story behind this? -Doug

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