map and null values
Remi Forax
forax at univ-mlv.fr
Thu Jan 3 08:52:04 PST 2013
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.
??,
either we are able to provide sensible default methods for Map or we
should not try to add them to Map.
Rémi
>
> 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
>>
>>
>>
More information about the lambda-dev
mailing list