Tim Peierls tim at
Sun Sep 23 06:54:25 PDT 2012

On Sun, Sep 23, 2012 at 9:12 AM, Doug Lea <dl at> wrote:

>     The main downside is that findAny is forced to lie (reporting absent)
>> if a null item matches predicate.
>> Doesn't bother me.
> It encounters the same antipattern seen when you
> need to establish that a Map key has no mapping:
>  if (map.get(k) == null)     // don't know if there is a mapping
>     if (!map.containsKey(k)) // so recheck

Too bad Map.get doesn't return Optional<V> ! :-)

Map is a done deal, though. We're talking about weirdness that can arise
when you tolerate null elements in streams. I don't want to bend over
backwards for such usage.

> Which might not seem so terrible in particular cases where
> you are prepared to cope with mappings to null.

People shouldn't be mapping to null in the first place, any more than they
should be mapping to NaN.

> But the issues make it impossible to write some generic
> Map utilities because the need to recheck forces non-atomicity.
> For findAny etc, the issue is even harder:
>   if (!...findAny(...).isPresent())
>     // somehow recheck?
> And the need for recheck is even less obvious.

So unobvious that I still don't see it. As long as you aren't treating null
as an acceptable value in Streams or as the contents of an Optional, why do
you need to re-check?


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