map and null values

[Peter Levart]

On 01/03/2013 04:46 PM, Brian Goetz wrote:
> Another way of saying this is: this is easy for non-concurrent maps, 
> but basically impossible for concurrent maps.  Since these methods are 
> being ported down from ConcurrentMap to Map, bending over backwards to 
> accomodate uses that won't work anyway in their intended domain is a 
> complete waste of energy.

The methods: remove(key, value), replace(key, oldValue, newValue), 
replace(key, value) & putIfAbsent(key, value) are perfectly usable also 
in non-concurrent and non-atomic domain, since they provide an 
opportunity for optimization in various implementations. Currently there 
is no way to achieve their semantics on plain Map (like j.u.HashMap) 
without doing two lookups.

That's also true for computeIfAbsent and friends but the benefit is 
questionable, since another lookup might be faster then the construction 
of a lambda object.

Regards, Peter

>
> On 1/3/2013 10:40 AM, Doug Lea wrote:
>> On 01/03/13 09:57, Peter Levart wrote:
>>>
>>> And if there is a way to provide a single default
>>> implementation in j.u.Map that satisfies both ConcurrentMap 
>>> implementations that
>>> don't allow nulls and plain Map implementations that allow nulls, 
>>> why not
>>> provide it?
>>>
>>
>> Feel free to try. The main constraint is that, to apply to
>> possibly-concurrent maps, the  four new function-accepting
>> methods must be expressed only in terms of putIfAbsent,
>> replace, and/or two-argument remove. While I haven't tried
>> to prove this, I believe that all ways of doing it encounter
>> the null ambiguity.
>>
>> -Doug
>>
>>
>>