The Optional Type API

Java 8 introduces the Optional class. In a nutshell, instead of returning null, and then checking for null, you return an Optional instance, which can either have or not have a value set. That way you don’t fail with NullPointerException.

I won’t discuss whether the Optional type will eliminate NPEs completely (it won’t). Instead I’ll discuss things from a different perspective – API design. In addition to Java’s Optional, I’ll show guava’s Optional and scala’s Option, and compare them.

An API, as Joshua Bloch suggests, should be as small as possible, but no smaller. The conceptual weight of an API should be minimized, and if you wonder whether to include something in your API or not, then you should leave it out. An API should be easy to use, and hard to misuse, and ideally should have one (or two) main usage patterns. The Optional type is a good example of having to make all these choices.

What is the default usage of this? You get an optional type, and you want to execute some piece of code only if there is a value set. You could obviously do that by comparing to null, but you often tend to forget that and the optional types force you to realize that this value can actually be unset. The second important use-case is to be able to easily provide a default value, if none is set.

Let’s first start with the worst of the three (in my opinion) – scala’s Option. At first it seems that this class offers you a lot of functionality. But, as it is normal for scala, there are a lot of different ways to use a class and none of them is better than the rest. For me, the particularly bad decision in this case is making Option (implicitly) convertible to Iterable. For the non-scala developers, let’s assume it is an Iterable. But it can have only one or zero elements. So, in order to implement our default and most common use-case we have the following options:

  • Use imperative style if (option.nonEmpty) {option.get.doSomething()}
  • Use .foreachoption.foreach(v => v.doSomething)
  • Use a foreach loop (different from above): for (value <- option) {value.doSomething()}
  • Use a for comprehension (for...yield) (different from the two above)
  • Use pattern-matching - case Some and case None
  • Use map, fold, collect, etc - this takes the process one step further - not only you get the value, but apply some function to it

So, from the basic notion of an optional type, we have a class with dozens of methods. The conceptual weight of this API is huge. There is no obviously preferred way to handle the most common case, and in fact method preferred by many scala developers uses some form of foreach, which sounds a bit weird, when you know there is at most one value.

Now let's proceed with my 2nd place candidate - Java 8 Optional. You have only two ways to use it - the imperative check with an if-clause, and the ifPresent(function) method, where you supply a function that handles the code when there is a value. You also have a couple of overloaded methods to provide a default value (the 2nd use-case). What I don't like is the map, flatMap and filter methods there. They are useful, as the scala ones above, but they could be left out (and their usage handled separately, with almost no added verbosity), or they could be reduced to simply one function - map. It has a subtle difference with flatMap, and filtering a single element isn't the most useful thing out there, besides, you could do that with a map function.

I know that by now you are probably ready to ask (angrily) how you are going to write very concise code without the ability to fold, collect, flatMap, filter. Returning another optional type after performing an operation with the given optional type is a 3rd use-case, which is important for long methods. It is less common than the other two, so less attention should be paid to it. Ideally, one method is enough - all other sub-usacases can be handled in the map function itself.

So we get to the winner - guava Optional. It has only the imperative way of handling the first use-case (as it is developed for versions of Java that lack first-class functions). The 2nd and 3rd use-cases above have as few methods as possible (or and transform(..)). Leightweight API that can achieve pretty much the same things, in the same amount of code.

In fact, having a functional approach for the main use-case is not necessarily good - the point of having an Optional type is not to be able to work functionally with it - the point is to be made aware that the value might not be there. I'm not saying to get rid of it in scala and Java8, but then maybe .isPresent() and .get() could be reconsidered.

Bottom-line is - it is hard to design APIs. Even a simple thing as an optional type has a lot of aspects to consider in terms of primary and secondary usa-cases, and whether convenience methods are needed, or they add unnecessary complexity to the API and can instead be handled in a different (not necessarily more verbose) way.

And finally - use optional types when you can possibly return null - NPEs are easy to debug and fix, but are easy to miss and may happen at the wrong moment.

12 thoughts on “The Optional Type API”

  1. As far as I know, ‘Option’ is a monad (or is monadic)

    That’s why it must adhere to monad behavior by having fmap, map, and etc. (and for compherensions, foreach, collect are just syntactic sugar on top of these fmap/map things)

    And that’s why Scala and Java8 Options implemented that way: to enable FP style.

    Guava simplified it’s API, so probably it’s one of the reason of having it named not ‘Option’, but ‘Optional’ (just guessing).

  2. Thanks for clarifying. Yes, it is a monad, and the side-effect of that is a heavy API for a simple concept. Not necessarily bad, and it certainly fits the scala model more than that of Java.

    Both Java and guava classes are called “Optional”, so I guess it’s just a random choice 🙂 Could’ve been even “Maybe”

  3. > That way you don’t fail with NullPointerException.

    What if the method returns a null Optional?

  4. If the method implementer is stupid, you can’t go around that(unless the compiler forces Optional-returning methods to not return null). And that’s why I said in brackets in the beginning that it won’t solve NPEs completely, but it’s an improvement.

  5. Regardless, all of these pale in comparison to a language like Kotlin or Ceylon which both differentiate variables that are nullable vs. non-nullable with syntactic sugar baked into the language. I think this is the true way forward rather than a generified Optional type… There’s likely no hope to implement that in the Java language at this point so I suppose this is the best option here.

  6. As far as I see from the Javadoc – Guava’s Optional is abstract (and thus non final but can be subclassed in a myriad ways, some of which will not keep the contract) while JDK8’s one is final and thus – much more predictable in behaviour.
    Guava gives two implementations – Absent and Present that are final – but nothing prevents you from providing another one.
    Another thing to point out – Guava’s Optional is serializable, but JDK8’s one is not which is another plus for me. Allowing serializing the ambiguity of whether something is present or not is not a good idea plus it provides hidden ways of constructing such ambiguities.
    I do not know Scala to comment on that.

  7. I agree with Dmitry Ivanov that Optional actualy does not behave like iterable, it behave like Monad, that is why, map, flatMap is there.

Leave a Reply

Your email address will not be published.