ConcurrentHashMap/ConcurrentMap/Map.compute

[Brian Goetz]

I think David's strategy of reabstracting in ConcurrentMap makes sense. 
  CM changes the semantics of these methods compared to what's in Map. 
As it turns out, this requires no code change because the existing 
declaration in CM will act as a reabstraction.

On 12/7/2012 7:58 AM, Doug Lea wrote:
> 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
>