RFR : JDK-8001642 : Add Optional<T>, OptionalDouble, OptionalInt, OptionalLong

Brian Goetz brian.goetz at oracle.com
Sun Mar 10 16:22:02 PDT 2013

I've posted a survey for the EG at:


where people can express their preference between:
  - Leave things as they are (Optional-bearing methods for findXxx and 
  - Add, as Doug suggests, non-optional versions of these too.

Implementation / spec complexity is a non-issue here -- the 
implementations are trivial.  The sole issue is whether the API is 
better with one version or with both.

The password has been communicated directly to the EG; contact me if you 
didn't get it.

Usual survey rules: enter your name with your response, all results will 
be made public after the survey closes.  I'll set a closing time of 6PM 
PT Wednesday of this week.

On 3/6/2013 7:09 AM, Doug Lea wrote:
> (Restricting to lambda-libs list...)
> On 03/06/13 04:47, Remi Forax wrote:
>> Ok, let be nuclear on this,
>> There is no good reason to introduce Optional<T> in java.util.
> We agree about most of the rationale for not using Optional.
> But there are still people who say they want it.
> I don't think it is productive at this point to
> argue about features supporting an Optional-laden
> programming style. But we never seem to hit closure
> about features supporting an Optional-free style.
> So I'd like to re-propose a simple compromise.
> In the same way that there are Optional and
> basis-returning versions of reduce:
>   T reduce(T identity, BinaryOperator<T> reducer);
>   Optional<T> reduce(BinaryOperator<T> reducer);
> (Where the basis-returning one can in turn be used to
> avoid Optional-returning min(), etc). We should do the
> same at least for find, or  more in keeping with current
> API, findFirst and findAny:
>   T findFirst(Predicate<? super T> predicate, T ifNone);
>   T findAny(Predicate<? super T> predicate, T ifNone);
> People wanting to avoid Optional can then then
> get all of the derived versions (allMatch, plain
> findAny, etc) easily enough.
> Surprisingly enough, that's the only missing
> feature that would otherwise enable a completely
> Optional-free usage style of the Stream API.
> We have both proposed variants of this several times,
> but they don't seem to go anywhere. It would be nice
> to have a calm final discussion about why we would NOT
> do such an apparently sensible thing!
> -Doug

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