ConcurrentHashMap/ConcurrentMap/Map.compute

[Remi Forax]

On 12/07/2012 02:46 PM, Brian Goetz wrote:
> 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.

yes, it's better than providing a semantics that will stab users in the 
back.

Rémi

>
> 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
>>