RFR: 8003246: Add Supplier to ThreadLocal

Chris Hegarty chris.hegarty at oracle.com
Thu Dec 6 17:36:26 UTC 2012


Thank you Akhil, this looks much better.

I'm not completely comfortable with, "The initial value of the variable 
is provided by calling the {@code intialValue} method." Similarly, " The 
initial value of the variable is determined by invoking the {@code get} 
method on the {@code Supplier."

Should these statements defer to the text in initialValue? Or maybe just 
leave out the additional text in the no-args constructor, and have 
withInitial() just describe its implementation? My concern is with the 
omission of the behavior of set(), and the term 'initial value' could be 
misinterpreted.

Anyway, I'm relatively happy with this, let's see what others think.

-Chris.

On 12/06/2012 05:01 PM, Akhil Arora wrote:
> On 12/06/2012 03:32 AM, Doug Lea wrote:
>>
>> These seem like really good reasons to implement as you
>> suggested in last post, with a static factory that uses a non-public
>> *final* subclass that wires initialValue to supplier call,
>> and not otherwise modifying the ThreadLocal class.
>> It has the added benefit of, by not touching ThreadLocal,
>> guaranteeing that it is time/space-neutral for other existing
>> uses. Which also means that any future time/space improvements
>> in ThreadLocal will not need to be constrained by this change.
>>
>> Jim/Akhil, could you please redo it this way?
>
> redone - http://cr.openjdk.java.net/~akhil/8003246.1/webrev/
>
> Thanks



More information about the core-libs-dev mailing list