ConcurrentHashMap/ConcurrentMap/Map.compute

[Brian Goetz]

I'm fine with this.  The existing Map API doesn't say anything about 
atomicity anywhere.  The new putIfAbsent on Map wouldn't promise 
atomicity either; it is no worse than writing

   if (map.containsKey(k))
     map.remove(k)

which we do all the time when we want to do putIfAbsent against 
non-thread-safe maps.  And the maps that promise atomicity can do better 
while using the same client idioms.

The best example of why we want these on Map is computeIfAbsent.  I 
could imagine that Guava never would have bothered with Multimap if 
computeIfAbsent were more convenient.

On 12/5/2012 4:33 PM, Doug Lea wrote:
> On 12/05/12 16:25, Mike Duigou wrote:
>> The problem is that you can't write an atomic putIfAbsent default
>> method in terms of the existing Map API. Thus far we've only
>> contemplated defaults that can match any atomicity expectations
>> provided by the non-default methods.
>>
>
> 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.
>       *
>
> For CHM and related classes, you need each of the original
> four ConcurrentMap methods, and the four new functional ones
> because without them there's no way to get atomicity
> in these contexts.
> But some people like them for the sake of encapsulating
> common forms under standard names even if not atomic.
> I don't have a strong opinion about it, which is why I asked.
>
> -Doug
>