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
