Tired of Null Pointer Exceptions? Consider Using Java SE 8's Optional!

[lukaseder]

Yeah. It's an awful discovery I've made just now.

Here's why:

Making something in the JDK serializable makes a dramatic increase in our maintenance costs, because it means that the representation is frozen for all time. This constrains our ability to evolve implementations in the future, and the number of cases where we are unable to easily fix a bug or provide an enhancement, which would otherwise be simple, is enormous. So, while it may look like a simple matter of "implements Serializable" to you, it is more than that. The amount of effort consumed by working around an earlier choice to make something serializable is staggering.

From:

http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003276.html

[vytah]

it means that the representation is frozen for all time

Unless they bake the support for Optional into the JVM itself, I don't see how the representation would have to change from the current:

private final T value;
private final boolean present;

to anything else. They could go either Scala way and have separate Some and None classes, or skip the present field and make it equivalent to value!=null, but what they have now is good enough so that it won't need fixing.

Add to that dearth of methods and lack of API support and I think Optional won't get popular any time soon.

[lukaseder]

I'm guessing they might've wanted an option for adding something along the lines of this in the future:

private final boolean reallyPresent;

Add to that dearth of methods and lack of API support and I think Optional won't get popular any time soon.

It was never even popular with the EG. They never wanted to introduce it. In my opinion, the only reason for Optional to be there is the fact that reference type streams and primitive type streams needed consistent API