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

David Holmes david.holmes at oracle.com
Thu Jun 20 04:51:30 UTC 2013

Hi Mike,

On 20/06/2013 10: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/

In Map if we get to line 1030 we retry the loop, but we don't re-read the currently mapped value even though the comment indicates it has changed. I don't quite grok this.

Also watch for spacing: if(oldValue -> if (oldValue

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).

I seem to recall this being discussed before but can't find relevant emails ...

You would need to revise specs regarding throwing, or not, of CME.

David

Mike

More information about the core-libs-dev mailing list