[concurrency-interest] forkjoin.ParallelArray and friends

Doug Lea dl at cs.oswego.edu
Tue Aug 28 08:06:01 EDT 2007


And one more:

ParallelArray tries to be as agnostic as possible about whether
Java will ever provide some form of syntactic closure support.

Without closures, users will need to create lots of little
classes and instances like the illustrated
     static final class IsSenior implements Predicate<Student> {
         public boolean evaluate(Student s) { return s.credits > 90; }
     }
     static final IsSenior isSenior = new IsSenior();

It would be great if IDEs helped automate this.
Maybe some of you would like to help develop such plugins
or lobby for them. It's not very different than IDE support
for little action classes and objects used in GUIs.

Even with this though, it's a bit weird to have all of
the interfaces and adaptors in Ops sitting in what
will probably eventually be java.util.concurrent.forkjoin.
They have little to do with fork/join parallelism per se.
But trying to place them elsewhere would be an uphill battle.
Where should they go? Should they all be nested in one
static-importable class, or each lifted into its own
class/interface? If lifted, do the names conflict with others
in any commonly used package out there? And so on.
Given all this, the simple expedient of keeping them as
they are seems like the surest path to making these usable.

On the other hand, if Java does end up providing closures,
then we or someone will eventually
be faced with a big retrofitting problem. If the
types are nameless types (e.g., "int(int)" rather than
"MapperFromIntToInt") then there might even be a need for
special tools to massage existing usages into the right
form.

Any advice about these issues would be welcome.

-Doug




More information about the Concurrency-interest mailing list