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
.foreach–option.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 Someandcase 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.
| Reference: | The Optional Type API from our JCG partner Bozhidar Bozhanov at the Bozho’s tech blog blog. |
