RFR: 8003246: Add Supplier to ThreadLocal
Remi Forax
forax at univ-mlv.fr
Thu Dec 6 08:23:09 UTC 2012
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
More information about the core-libs-dev
mailing list