ConcurrentHashMap/ConcurrentMap/Map.compute

Doug Lea dl at cs.oswego.edu
Fri Dec 14 08:08:52 PST 2012


On 12/14/12 10:47, David M. Lloyd wrote:

> Oh I see - the point I was missing is that computeIfAbsent is specified to
> return the *new* value if the mapping is replaced, instead of returning null as
> putIfAbsent does.
>
> Now given the precedent of putIfAbsent, why change the behavior in this case?
> Is it just because we are arguing that it was in fact a mistake?
>

For computeIfAbsent, the method must return the computed value
to you or else you won't know it. The tradeoff is that the method
cannot tell you whether you've computed it vs it was already there.
The putIfAbsent method does provide this old vs new information,
so is in principle more powerful in this restricted sense.
But it is also susceptible to mistakes when people use
the return value directly rather than checking if null.

-Doug





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