[concurrency-interest] jsr166y.forkjoin API comments

Doug Lea dl at cs.oswego.edu
Thu Jan 24 19:25:19 EST 2008

David J. Biesack wrote:
> Been working with the API more and I have a few more comments/suggestions
> assembled.

Thanks! These are great! Please keep them coming! I hope to do
another renaming etc pass sometime based on the already good
suggestions stemming from last one.

Along these lines: We've been thinking of
separating these from base FJ support and placing in new
subpackage java.util.concurrent.forkjoin.collections.
(or for now jsr166y.forkjoin.collections). Any opinions?

Some notes about some of them...

> Rather than duplicating defaultExecutor() in each Parallel*Array class,
> provide a single ForkJoinExecutor.Factory static class with a getInstance()
> method. I like to see the creation API closer to the interface. However, this
> would require an extra import per use, so I' not pushing it too hard - just
> seems to be unnecessary duplication.

This is currently our compromise between supporting factories
that allow you to just use default vs making you write an
uglier expression to specify the default global one. I suspect
we will end up doing the former someday so might want to get it
over with now, in which case the default could be pushed up
as a toplevel standalone singleton class.

> I find createFromCopy and createWithHandoff method names to be awkward; 

> ParallelDoubleArray pa; pa = ParallelDoubleArray.withCopy(myArray,
> myForkJoinExecutor); 

I agree about the problem; hopefully we'll find a nicer solution.

> Rename CommonOps.compoundOp as CommonOps.compositeOp as per the well-known
> Composite design pattern.
> Rename the withBounds/withMapping/withFilter methods to simpler bound(...),
> map(...), and filter(...).

Or I think a little better: bounding(l,h), filtering(pred), mapping(op).
I think we'll do this.

> Having used this a while, I personally don't like the liberal use of
> "withThis" this and "withThat" throughout the API;

(Well, except for your suggested use in factories above :-)

  it makes it more verbose
> without really adding much. As per Kent Beck's recommendations
> (Implementation Patterns, p. 24, Qualified Subclass Name: "Prepend one or
> more qualifiers to the superclass name to form a subclass name"), rename the
> resulting ParallelArray*WithBounds, *WithMapping, WithFilter to
> BoundedParallel*Array, MappedParallel*Array, FilteredParallel*Array. I
> realize these are not subclasses, but conceptually, they are derivations of
> Parallel*Array.
> FilteredParallelDoubleArray pa = a.filter(myIndexFilter);

Note that it should be very rare to give a name to (thus mention the
type of) to this kind of expression though.


More information about the Concurrency-interest mailing list