Doug Lea dl at
Mon Sep 24 04:37:38 PDT 2012

On 09/22/12 08:25, Remi Forax wrote:
> On 09/22/2012 02:00 PM, Doug Lea wrote:
>> 1. Stream operations ignore null elements.
>> 2. Each operation that can return a "nothing there" result has two forms
>>    Optional<T> op(...)
>>    T op(..., T defaultValueIfNone);
> The main issue with rule 1 is that the JDK already uses meaningful null,
> by example, a class with a null classloader doesn't mean that there is no
> classloader.
>    List<Class<?>> list = ...
>    Maps<Class<?>, ClassLoader> classLoadedMap =
>      list.mapped(Class::getClassLoader).into(new HashMap<>());
> so Optional should be able to store null.

This is how all these discussions seem to go: Some existing
or potential abuse of null leads to rules allowing further
abuse. Every time I lose the straight "null means nothing there"
argument, I figure that I'm complicit in adding a few million
dollars to Hoare's billion dollar mistake.

At least in j.u.c, we pretty much fixed this (although even there
I got talked into allowing nulls in the ConcurrentMap interface,
but still disallow them in all j.u.c map implementations. Weird.)

> rule 2 is in my opinion a good compromise if by default the method that returns
> an Optional is written using the method that takes a default value as last
> parameter.

If present Optionals can be null, the world is probably better off
without them; so methods like findAny ONLY take the valueIfNone form.


More information about the lambda-libs-spec-observers mailing list