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