[concurrency-interest] Concurrency Wrappers

Curt at Tripos Curt at Tripos <ccox@tripos.com>
Wed, 25 Jun 03 12:45:48 -0500


Daniel,
 
>     As it is very easy to do something similar
> using dynamic proxies (i.e.
> regarding a known set of interfaces), I don't
> think it should be part of
> this library.

I assert that "easy to implement" isn't a
strong enough argument to keep functionality out of
a utility.  java.lang.ThreadLocal is one example.

If it is generally useful, then there is
no sense in a large percentage of users writing their
own implementations, or finding someone elses.
In my experience, these would be generally useful.

Also, I didn't mean to limit the wrappers to just
those two.  They should be included, however, since
they are the simplest and most generically useful.
I would also argue for the inclusion of methods to
construct wrappers that apply different concurrency
mechanisms to different methods.

> Otherwise it's very difficult to
> know how to implement such
> methods using plain Java, because if you don't
> know the exact interfaces,
> you can't easily (i.e. without heavy reflection
> usage + byte-code
> generation) define the appropriate proxies. In
> the collections case the
> interfaces are known at compile-time, so it isn't
> a problem.

If factory methods for wrappers are put in place now,
any users will get a speed bump (without changing a single 
line of code), if and when the
reflection + byte-code-generation route is implemented.
Witness the evolution of ThreadLocal's implementation.

Thanks,
Curt