RFR: 8004518 & 8010122 : Default methods on Map

[Peter Levart]

Hi Mike,

It's unfortunate that getOrDefault() is specified so that it can't be 
implemented atomically in terms of existent (non-default) ConcurrentMap 
methods, so platform ConcurrentMap implementations will have atomic 
implementation and others will have to catch-up first. I hope this will 
not be a cause of any concurrency bugs.

The javadoc for computeIfPresent seems to be inconsistent:

  826      * If the value for the specified key is present and non-null,
  827      * attempts to compute a new mapping given the key and its current
  828      * mapped value.
  829      *
  830      * <p>If the function returns {@code null}, the mapping is removed (*or*
  831      **remains absent if initially absent*).  If the function itself throws an
  832      * (unchecked) exception, the exception is rethrown, and the current mapping
  833      * is left unchanged.

I think the situation described *in bold* is non-existent.


Regards, Peter


On 04/08/2013 08:07 PM, Mike Duigou wrote:
> Hello all;
>
> This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/
>
> 8004518: Add in-place operations to Map
>   forEach()
>   replaceAll()
>
> 8010122: Add atomic operations to Map
>   getOrDefault()
>   putIfAbsent()          *
>   remove(K, V)
>   replace(K, V)
>   replace(K, V, V)
>   compute()              *
>   merge()                *
>   computeIfAbsent()      *
>   computeIfPresent()     *
>
> The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key).
>
> The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity.
>
> Mike
>