java.util.Optional in Java 8

[Cédric Beust ♔]

FYI, here is Brian's summary of the situation about Optional in Java 8. Hopefully, this will provide some background on why things are the way they are.

-- 

Cédric

---------- Forwarded message ----------
From: Brian Goetz <brian...@oracle.com>
Date: Tue, Oct 30, 2012 at 10:24 AM
Subject: Re: Optional require(s) NonNull
To: Roland Tepp <luo...@gmail.com>
Cc: lambd...@openjdk.java.net

> I am not so much concerned about how or where people start using it (this
> will settle eventually by best practices) as much as I am concerned that
> the Optional type in Java SDK will not deliver on the promise people who
> are familiar with the concept are expecting it to deliver:

The problem is with the expectations.  This is a classic "blind men and elephant" problem; the thing called Optional has different "essential natures" to different viewpoints, and the problem is not that each is not valid, the problem is that we're all using the same word to describe different concepts (more precisely, assuming that the goals of the JDK team are the same as the goals of the people you condescendingly refer to as "those familiar with the concept."

There is a narrow design scope of what Optional is being used for in the JDK.  The current design mostly meets that; it might be extended in small ways, but the goal is NOT to create an option monad or solve the problems that the option monad is intended to solve.  (Even if we did, the result would still likely not be satisfactory; without the rest of the class library following the same monadic API conventions, without higher-kinded generics to abstract over different kinds of monads, without linguistic support for flatmap in the form of the <- operator, without pattern matching, etc, etc, the value of turning Optional into a monad is greatly decreased.)  Given that this is not our goal here, we're stopping where it stops adding value according to our goals.  Sorry if people are upset that we're not turning Java into Scala or Haskell, but we're not.

On a purely practical note, the discussions surrounding Optional have exceeded its design budget by several orders of magnitude.  We've carefully considered the considerable input we've received, spent no small amount of time thinking about it, and have concluded that the current design center is the right one for the current time.  What is surely meant as well-intentioned input is in fact rapidly turning into a denial-of-service attack.  We could spend endless time arguing this back and forth, and there'd be no JDK 8 as a result.  I'm sure no one wants that.

So, let's keep our input on the subject to that which is within the design center of the current implementation, rather than trying to convince us to change the design center.

[Mario Fusco]

FYI, here is Brian's summary of the situation about Optional in Java 8. Hopefully, this will provide some background on why things are the way they are.

I have already seen that email but It doesn't clarify my doubts at all. I wonder how it clarifies yours.

The problem is with the expectations.  This is a classic "blind men and elephant" problem; the thing called Optional has different "essential natures" to different viewpoints, and the problem is not that each is not valid, the problem is that we're all using the same word to describe different concepts (more precisely, assuming that the goals of the JDK team are the same as the goals of the people you condescendingly refer to as "those familiar with the concept."

This is just false. The only "essential nature" of an Option is to model a value that could be potentially absent. I don't know any other shared and widely accepted viewpoint. Do you?
 

There is a narrow design scope of what Optional is being used for in the JDK.  The current design mostly meets that; it might be extended in small ways, but the goal is NOT to create an option monad or solve the problems that the option monad is intended to solve.  

Ok , so this what a Java8 Optional is NOT. But what IS it?
 

(Even if we did, the result would still likely not be satisfactory; without the rest of the class library following the same monadic API conventions, without higher-kinded generics to abstract over different kinds of monads, without linguistic support for flatmap in the form of the <- operator, without pattern matching, etc, etc, the value of turning Optional into a monad is greatly decreased.)  Given that this is not our goal here, we're stopping where it stops adding value according to our goals.  Sorry if people are upset that we're not turning Java into Scala or Haskell, but we're not.

I am not asking to turn Java into Scala. What I am asking is: either provide an acceptable Optional implementation with the features that a functional programmer expects to find in it or simply give up with it.
Moreover if the value of flatMap without the linguistic support mentioned by Brian is so greatly decreased why they added it to the Iterable interface without any objection?
 

On a purely practical note, the discussions surrounding Optional have exceeded its design budget by several orders of magnitude.  

True, but this has been caused only by the irrational choice of implementing it in a so "unconventional" way. If they developed the Optional as expected by the average functional programmer there won't be any discussion at all. There are no multiple viewpoints: an Option is an Option as widely accepted by the community of functional programmers. And saying that you are not turning Java in a functional language while you're adding lambda expression to it, is just silly.
 

We've carefully considered the considerable input we've received, spent no small amount of time thinking about it,

No, you don't.
 

and have concluded that the current design center is the right one for the current time.

No, it is not.
 

 What is surely meant as well-intentioned input is in fact rapidly turning into a denial-of-service attack.  We could spend endless time arguing this back and forth, and there'd be no JDK 8 as a result.  I'm sure no one wants that.

So, let's keep our input on the subject to that which is within the design center of the current implementation, rather than trying to convince us to change the design center.

Mail ended! Ok, so where is the explanation of what an Optional is. I still don't see any.

Mario
 

[Cédric Beust ♔]

On Thu, Nov 1, 2012 at 1:08 AM, Mario Fusco <mario...@gmail.com> wrote:

I am not asking to turn Java into Scala. What I am asking is: either provide an acceptable Optional implementation with the features that a functional programmer expects to find in it or simply give up with it.

That's a false dichotomy, there is a whole continuum between providing a fully monadic version of this type like Haskell's Maybe and a simple container that implements the null object design pattern.

At any rate, why are you replying to me? Send your email on the lambda-dev list, where Brian can see it.

-- 

Cedric

[Ricky Clarkson]

I think that list has had enough of emotional responses and it's been
made clear that we'll get what we're given in Java 8 regarding
Optional. It's not an open process, just an open mailing list.

> --
> You received this message because you are subscribed to the Google Groups
> "Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to
> javaposse+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.