ConcurrentHashMap/ConcurrentMap/Map.compute

[Brian Goetz]

Let's back up.  I don't understand the premise of the question.

CM already has methods putIfAbsent and friends, which are currently 
abstract in CM, and will remain abstract in CM even though Map will 
acquire them with non-atomic defaults.  No problem so far.

CM will now acquire some NEW methods, taking lambdas.  Like:

   computeIfAbsent(K, K->V)

The following default implementation *is* atomic because putIfAbsent is 
already atomic in CM:

   computeIfAbsent(K key, K->V fn) {
     if (!containsKey(key))
       putIfAbsent(key, fn.apply(key));
   }

What it doesn't do is guarantee that the generating function is called 
exactly once, or that the result of that generating function is not 
discarded.

The better version implemented by CHM will have better properties -- 
that the function is called exactly once and the result is never 
discarded.  But I don't see where the non-atomicity comes from?

> So, to re-ask:
>
>> Should the cases of existing ConcurrentMap methods and the new
>> function-accepting methods work differently? Suppose
>> someone calls computeIfAbsent on a JDK7-compliant
>> (but non-JDK) ConcurrentMap that doesn't have an explicit
>> override. They would get the non-atomic version. And this is
>> considered OK according to the the specs as I wrote them.
>> But still surprising to at least some users.