map and null values

Peter Levart peter.levart at
Thu Jan 3 06:57:17 PST 2013

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).
> 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.
> 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.
> -Doug
All well and understood for Stream API. And one nice thing about Stream 
API is, that it is clearly separated from the rest of (old) collections 
API by 2 methods on j.u.Collection: stream() & parallelStream(). So if 
your collections or maps contain null elements and you invoke any of 
those two methods, you are asking for trouble. And javadoc for those 2 
methods should warn you about that. But other added methods (on Map for 
example) are useful for themselves also in plain non-concurrent 
scenarios, especially if they get optimized implementations in say 
j.u.HashMap. 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?

Regards, Peter

More information about the lambda-dev mailing list