ConcurrentHashMap/ConcurrentMap/Map.compute (original) (raw)
Mike Duigou mike.duigou at oracle.com
Wed Dec 5 13:25:04 PST 2012
- Previous message: ConcurrentHashMap/ConcurrentMap/Map.compute
- Next message: ConcurrentHashMap/ConcurrentMap/Map.compute
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
The problem is that you can't write an atomic putIfAbsent default method in terms of the existing Map API. Thus far we've only contemplated defaults that can match any atomicity expectations provided by the non-default methods.
public default boolean isEmpty() { return size() != 0; }
is just fine but it's hard find mutation operations which benefit from default methods.
Mike
On Dec 5 2012, at 13:10 , Doug Lea wrote:
On 12/05/12 07:39, Doug Lea wrote:
... method Map.compute(). Three other similar methods computeIfAbsent(), computeIfPresent(), and merge() amount to special cases that are generally simpler to use and more efficient when they apply.
After a few stabs at it, I think that the only sane way to spec and default-implement it is to say that, even if your Map implementation otherwise allows null keys/values, that this method will act as if it doesn't. Since people seem not to mind this (and Brian's and Tim's responses on other thread seem to even encourage it), the set of all four are below. Please skim through and see if you still agree. Brian: We had discussed also defining and default-implementing in Map the other ConcurrentMap methods: V putIfAbsent(K key, V value); boolean remove(Object key, Object value); boolean replace(K key, V oldValue, V newValue); V replace(K key, V value); Any thoughts?
- Previous message: ConcurrentHashMap/ConcurrentMap/Map.compute
- Next message: ConcurrentHashMap/ConcurrentMap/Map.compute
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the lambda-libs-spec-experts mailing list