map and null values

[Remi Forax]

On 01/03/2013 12:42 PM, Doug Lea wrote:
> On 01/03/13 05:41, Peter Levart wrote:
>> On 01/02/2013 06:01 PM, Brian Goetz wrote:
>>> Note that many existing Map implementations throw NPE when you try and
>>> put a null key or value into it anyway.
>>>
>>>
>> That's true, but the default *replace* method could do better for those
>> (3rd party) Maps that allow null values.
> To back up:
>
> 1. Everyone who has contemplated the issue sees that allowing
> null elements in Stream API methods is a questionable idea.
> Some of us think that we should bite the bullet now and
> either not permit them or always ignore them. But the consensus
> is to instead say in effect that any element operation involving
> nulls is free to do anything it likes (use them, ignore them,
> or blow up).

I was thinking the consensus was concurrent collections and new 
collection (since 1.5) doesn't accept null,
because older still allow null streams has to tolerate null element.
For Map, it means that keys or values can be null but also that methods 
that takes a lambdas like computeIfAbstent/Present can specifies that 
returning null mean nothing an not the 'null' value.
Given that, I think the default implementation should be change to allow 
null values, i.e. get() can return null even if containsKey say true.

>
> 2. Because Maps often feed and are fed by streams, and because
> parallel stream operations require concurrent maps, and because
> the required concurrent map operations cannot accept nulls
> (not because of meanness, but correctness), it is especially
> questionable to allow them. But we took the same tactic as (1):
> The added stream-support Map methods don't strictly forbid nulls,
> they just don't don't do what some people who use null values
> would like.

It's a problem of the stream implementation, not something that users 
will see.

>
> Moral: If you'd like to use new JDK8 stream/collection/map
> features, it would be a good idea to get rid of your nulls now.
> Otherwise you are at the mercy of all the particular policies
> of all the methods reachable from stream operations.
> This is not really different than the current state of affairs.
> For example, sorting collections with nulls always blows up but
> finding them via contains() usually doesn't. But the uniformity
> of the Stream API makes people realize just how fragile their
> null-containing collections and maps really were.

I agree.

>
> -Doug

Rémi