ConcurrentHashMap/ConcurrentMap/Map.compute

[Doug Lea]

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.