[concurrency-interest] Structure and function

Larry Riedel larryr@saturn.sdsu.edu
10 Aug 2002 21:23:05 -0000

Doug Lea wrote:
> There have already been several instances where
> there is functionality available in JSR166, but
> not where people have looked for it.
> [...]
> The question is whether we ought to somehow make
> some of these structurally more obvious.
> [...]
> Exactly what compromises would you like to see?

As a data point, I, as a user of these APIs to build applications,
prefer to get more classes and methods for free that I can use to
do what I want, so I do not have to implement those classes and
methods in my own application and libraries.

I can imagine in theory that for someone who is trying to learn
the concepts by looking at what is offered in the JDK, it might be
nice to have a minimal, orthogonal set of structure and behavior.
But I already have concepts in my mind, and I look to the JDK
hoping to find classes which clearly map to those concepts.

I like the idea of having a minimal, orthogonal set of
fundamental interfaces, along with classes which mix and match
those interfaces to provide all kinds of useful behavior.  I can
imagine the interfaces as providing the theoretical foundation,
and the classes as examples of ways to use the foundation to do
real work, and I can use those classes to do just that.

I love to see classes in the JDK which just sit on other classes
in the JDK to make my life easier, and I love things like the
"remaining()" method in java.nio.Buffer, which is really just
the same as "limit() - position()", but helps make my own code
simpler and easier to read, and I love helper methods like a
"put(byte[] dst)", which is the same "put(dst, 0, dst.length)".

But there are some classes in the proposed java.util.concurrent
which have names I did not personally find an obvious mapping
to concepts in my head from the name of the class.  For example
it was not clear to me what Future and Executor are, but when I
started thinking about a Future as a Job and/or Task, and Executor
as a JobQueue and/or Scheduler, it seemed to make more sense.

If java.util.concurrent was a melange of obscurely named classes,
of which many seem to do almost the same thing, such that
everybody who uses it is going to have to analyze the whole thing
to discern what in the world it is, then I would agree that it
might be preferable to minimize the size of that task.  But I am
confident java.util.concurrent is not going to be such a melange.