Tim Peierls tim at
Fri Sep 14 05:51:18 PDT 2012

On Fri, Sep 14, 2012 at 8:30 AM, Remi Forax <forax at> wrote:

> It's hard to win here. One of the many reasons that we
>> are supplying parallel bulk ops for ConcurrentHashMap that
>> fall outside the main stream framework is that issue #1 does
>> not arise (CHM disallows null keys and values), which
>> streamlines many design issues.
> There is in my opinion a better design,
>   x = s.findFirst(valueIfEmpty);

The trouble with that is that I often want to do something different
depending on whether I found anything, and it is not always easy (or even
possible) to find a distinct value to use as a sentinel. Rather than write
ad hoc things like this:

    Result result = filteredResults.findFirst(NO_RESULT);
    if (result != NO_RESULT) ... use result ...

I prefer being able to write:

    Optional<Result> result = filteredResults.findFirst();
    if (result.isPresent()) ... use result.get() ...

Note that this preference is less about fluency than preventing user
errors. It's all too easy to omit the test in the first snippet above, but
if you try to use result directly in the second snippet without testing it,
you'll get a compile error.

I am sensitive to the risk of API pollution by folks who become
over-enamored of Optional, as Doug hints (e.g., Set<Optional<T>>), but the
rewards outweigh the risks, IMHO.


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