[concurrency-interest] Re: Custom Locks

Doug Lea dl@cs.oswego.edu
Fri, 21 Nov 2003 08:02:41 -0500

Hi Luis,

The main packaging issue here is that JDK library classes must be more
conservative in allowing for future re-implementations than do most
other kinds of classes. (As a case in point, the java.lang.ThreadLocal
class has been gutted and redone twice now.) The java.util.concurrent
classes differ from dl.util.concurrent classes in minimizing exposure
so that, for example, if someone someday discovers a better way to
structure internal lock queue nodes, it can be put into place. As I
mentioned, we should be able to separately expose some of these
mechanics so that they remain separately available, but even that
probably won't turn out to be as "friendly" as you'd like.

The main consequence of these policies is that copy/paste/hack
variants of JDK classes are rampant out there. This seems to be
the lesser of the two evils though.