RFR: 8017088 : (s) Map/HashMap.compute() incorrect with key mapping to null value

Peter Levart peter.levart at gmail.com
Thu Jun 20 08:05:49 UTC 2013

On 06/20/2013 02:22 AM, Mike Duigou wrote:
> Hello all;
> This is a fix to the Map.compute() default method and HashMap.compute() implementation to correct the handling of keys mapped to null values when the function returns null. This situation should result in the key being removed but it was not.
> http://cr.openjdk.java.net/~mduigou/JDK-8017088/0/webrev/
> I am strongly considering moving all of the current looping defaults in Map to ConcurrentMap and replacing them with implementations which throw ConcurrentModificationException rather than retrying. The current implementation of Map.compute() default comes close to breaking atomicity by adding the containsKey() check. (It doesn't because the subsequent remove() when oldValue = null can't succeed for any known ConcurrentMap implementations).

...and it is fortunate that ConcurrentMap.remove(key, null) just returns 
false and doesn't throw NPE.

Yes, that would be a good idea. Non-ConcurrentMaps can't guarantee 
deterministic behaviour when modified from multiple threads and there's 
always some danger that their internal state is corrupted in such a way 
to cause infinite looping. It's better to fail that to loop in such cases.

Regards, Peter

> Mike

More information about the core-libs-dev mailing list