ConcurrentHashMap/ConcurrentMap/Map.compute

[Doug Lea]

On 12/07/12 02:18, David Holmes wrote:

>> Right. The idea is that ALL of these would have the same disclaimer as the
>> new lambda-friendly ones I listed:
>>
>> *
>> * <p>The default implementation makes no guarantees about
>> * synchronization or atomicity properties of this method. Any
>> * class overriding this method must specify its concurrency
>> * properties.
>> *
>
> Which means that ConcurrentMap has to re-abstract all the new methods as their
> default implementations are invalid for maps that people expect atomic
> operations from.

Yes/no. There is some risk in doing this in the way
I posted for both the four existing ConcurrentMap and four
added functional-form methods:
A concrete concurrent class will no longer be
forced by a compiler to override to provide atomicity.
And there is of course no way we can do it for them.
But users will naturally expect otherwise.
This is why I've been fleshing these all out,
so people could help decide if this is the best move.
I'm still thinking barely-yes, but am a little nervous
about it.

-Doug