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

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