On 12/06/2012 06:10 AM, David Holmes wrote:
On 6/12/2012 5:39 AM, Akhil Arora wrote:
This patch adds a constructor to ThreadLocal to supply initial values
using the new Supplier functional interface. Please review. This work
was done by Jim Gish.
http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003246
Has anyone actually established that this is a useful addition to
make? What is the acceptance criteria for adding these new mechanisms
to existing classes? Was there a CCC request for this?
We need to be very wary of unnecessary bloat.
It's a necessary bloat :)
There are two good reasons to provide a new ThreadLocal<>(() ->
initialValue),
if all goes as planned, every Supplier will share the same class so
instead of having one class by thread local that want to specify an
initialValue, we will have only 2 classes (or 3 if the ThreadLocal that
takes a Supplier is a subclass) in memory. Also, letting people to
subclass ThreadLocal is not a good idea because if in one location
someone decide to override get() to by example add a logging code (I've
seen a similar problem) then suddenly all the codes that use
ThreadLocal.get() will not be able to inline it. Given that too many
things are done using ThreadLocal in JEE container, having a way to
provide an initial value without subclassing ThreadLocal is a good idea.
David
Rémi
