RFR: 8003246: Add Supplier to ThreadLocal (original) (raw)

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/viewbug.do?bugid=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