On Tue, Jun 19, 2018 at 6:06 AM, David Lloyd <david.ll...@redhat.com> wrote:
> It may be confusing (to some, I guess) but it is consistent: the > ThreadLocal subclass author has absolute control over how the value is > presented to the user. Adding compute() or many of the other > suggested variants will break that guarantee, which seems like kind of > a big deal to me. > > Yeah, that's a good point I didn't consider. Any new method tends to expose presence/absence and evade subclass' checking. OTOH I think the same has happened with default methods added to existing interfaces, including Map, and I don't recall complaints about the failure of encapsulation. In this way, again ThreadLocal.compute would be very much like Map.compute. > What about introducing a different thread local API that has more > modern behavior? Maybe a new subclass of ThreadLocal? > > The hard part is coming up with a good name. ThreadLocalNowWithExtraMappiness ? If we create a new class, we can consider giving get() non-mutating behavior consistent with Map.
