Why does Guava's Optional use abstract classes when Java 8's uses nulls?

Question

When Java 8 was released, I was expecting to find its implementation of Optional to be basically the same as Guava's. And from a user's perspective, they're almost identical. But Java 8's Optional uses null internally to mark an empty Optional, rather than making Optional abstract and having two implementations. Aside from Java 8's version feeling wrong (you're avoiding nulls by just hiding the fact that you're really still using them), isn't it less efficient to check if your reference is null every time you want to access it, rather than just invoke an abstract method? Maybe it's not, but I'm wondering why they chose this approach.

Answer 1

i would expect virtual method invocation lookup to be more expensive. you have to load the virtual function table, look up an offset, and then invoke the method. a null check is a single bytecode that reads from a register and not memory.

Answer 2

Perhaps the developers of Google Guava wanted to develop an idiom closer to those of the functional world:

datatype ‘a option = NONE | SOME of ‘a

In whose case you use pattern matching to check the true nature of an instance of type option.

case x of
    NONE => //address null here
  | SOME y => //do something with y here

By declaring Option as an abstract class, the Google Guava is following this approach, where Option represent the type ('a option), and the subclasses for of and absent would represent the particular instances of this type (SOME 'a and NONE).

The design of Option was thoroughly discussed in the lambda mailing list. In the words of Brian Goetz:

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.