ConcurrentHashMap/ConcurrentMap/Map.compute

[David Holmes]

On 7/12/2012 10:58 PM, 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.

I'm not quite sure how to interpret your "barely-yes". :) But this is 
the prime motivating example I had for requiring re-abstraction. Another 
alternative would be to have ConcurrentMap redefine defaults that throw 
UnsupportedOperationException. But I don't think that is a good model to 
have. If we re-abstract then existing implementations of ConcurrentMap 
(outside the JDK) will not recompile without providing these new 
methods; and if the existing classes are used and the new methods 
invoked then they will get AbstractMethodError. That seems reasonable to me.

David

> -Doug
>