ConcurrentHashMap/ConcurrentMap/Map.compute (original) (raw)
Brian Goetz brian.goetz at oracle.com
Fri Dec 14 08:13:28 PST 2012
- Previous message: ConcurrentHashMap/ConcurrentMap/Map.compute
- Next message: ConcurrentHashMap/ConcurrentMap/Map.compute
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
As a user, I have found the computeIfAbsent semantics more useful.
On 12/14/2012 11:08 AM, Doug Lea wrote:
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
- Previous message: ConcurrentHashMap/ConcurrentMap/Map.compute
- Next message: ConcurrentHashMap/ConcurrentMap/Map.compute
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the lambda-libs-spec-experts mailing list