map and null values

[Peter Levart]

On 01/03/2013 04:40 PM, 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
>
>
I think I did that. Here's also a webrev diff to current tip of lambda repo:

http://dl.dropbox.com/u/101777488/jdk8-lambda/Map/webrev/index.html

I proposed a simple change to remove(key, value) and replace(key, 
oldValue, newValue) that doesn't throw NPE when there are null values 
already in Map (semantically equivalent to current default versions of 
those methods for maps that don't ever hold null values). And those two 
methods are already implemented as atomic operations in every 
ConcurrentMap implementation.

The other change was to compute() and merge() default methods. And was 
related to correctness, since this code for example:

         Map<Integer, String> map = new ConcurrentHashMap<>();
         map.compute(1, (k, v) -> "x");

...throws NPE and there's no null values used in it.


Regards, Peter