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