map and null values

Remi Forax forax at
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.


> 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