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

Doug Lea dl at cs.oswego.edu
Fri Dec 7 06:10:57 PST 2012

On 12/07/12 08:55, Remi Forax wrote:

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, this is/was my intent.

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

Which works out OK for the CM methods.

I'm comforted to see that people now implicitly share my anxiety about the new function-accepting methods. But that doesn't get me closer to a resolution :-) 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.

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