hg: lambda/lambda/jdk: Summary: add ThreadLocal(Factory<T>) and compareAndSet methods

[Brian Goetz]

> This accentuates the "moral hazard" issue I mentioned.
> What is the motivation for incorporating into JDK convenience methods to
> support a technique with such a restricted range of applicability?
> On contention, this method will not only eat a lot of cycles but
> also spew a lot  of garbage. Sometimes this is a good choice anyway.
> We use it occasionally in java.util.concurrent, but never without
> exploring alternatives. I don't think that even we use it enough
> to justify writing our own lambdafied version (which anyone can
> do if they do end up using it a lot).

Here's an example: advancing a state machine; the lambda is state -> state.nextState(input).  I've done this more than once.