ConcurrentHashMap/ConcurrentMap/Map.compute (original) (raw)

Brian Goetz brian.goetz at oracle.com
Wed Dec 5 13:46:21 PST 2012

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

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

More information about the lambda-libs-spec-experts mailing list