[concurrency-interest] jsr166y.forkjoin API comments

Osvaldo Pinali Doederlein osvaldo at visionnaire.com.br
Fri Jan 25 10:05:00 EST 2008

Kasper Nielsen escreveu:
> Doug Lea wrote:
>> 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?
> Sure, go for it. I think once ParallelMap and ParallelBigArray arrives 
> it would make sense.
Having a subpackage of collections would look weird, first because it's 
different from tradition: today, common collections are in java.util 
(together with lots of other non-collection stuff), and all concurrent 
collections are in java.util.concurrent (together with with lots of 
other non-collection stuff). Not that I think that List and Locale 
belong in the same package; java.util is a messy bag of unrelated 
utilites, but that's a design that comes from JDK 1.0 - including the 
first general collections like Vector. But in a second argument, for 
more specialized packages like j.u.c and forkjoin, I think it makes 
sense to co-locate special collections with the APIs that are used 
together with them. Packages should reflect the tight coupling between 
these APIs.

Notice that that tight coupling appears in the /interfaces/, not only in 
the implementations. For one thing, the Parallel*Array* classes are 
shock-full of methods that expose Ops.* interfaces in their signatures. 
This is very different, for example, from java.util.concurrent.atomic. 
The Atomic* objects are used massively in the /implementation/ of 
classes from the entire JSR166 APIs, but they do not appear as 
arguments, return values or super-types of anything. I think the same is 
true (or at least mostly true) for java.util.concurrent.lock.


Osvaldo Pinali Doederlein                   Visionnaire Informática S/A
osvaldo at visionnaire.com.br                http://www.visionnaire.com.br
Arquiteto de Tecnologia                          +55 (41) 337-1000 #223

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20080125/e6c73024/attachment.html 

More information about the Concurrency-interest mailing list