[concurrency-interest] Concurrency Wrappers
Curt at Tripos
Curt at Tripos <email@example.com>
Wed, 25 Jun 03 12:45:48 -0500
> 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.