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
