On Java 8's Introduction of Optional
I had recently discovered the JDK 8′s addition of the Optional
type. The Optional type is a way to avoid NullPointerException
, as API consumers that get Optional
return values from methods are “forced” to perform “presence” checks in order to consume their actual return value. More details can be seen in the Javadoc.
A very interesting further read can be seen here in this blog post, which compares the general notion of null
and how null
is handled in Java, SML, and Ceylon:
http://blog.informatech.cr/2013/04/10/java-optional-objects
“blank” and “initial” states were already known to Turing . One could also argue that the “neutral” or “zero” state was required in the Babbage Engine, which dates back to Ada of Lovelace in the 1800′s.
On the other hand, mathematicians also prefer to distinguish “nothing” from “the empty set”, which is “a set with nothing inside”. This compares well with “NONE” and “SOME”, as illustrated by the aforementioned Informatech blog post, and as implemented by Scala, for instance.
Anyway, I’ve given Java’s Optional
some thought. I’m really not sure if I’m going to like it, even if Java 9 would eventually add some syntactic sugar to the JLS, which would resemble that of Ceylon to leverage Optional
on a language level. Since Java is so incredibly backwards-compatible (which I generally find a very good thing), none of the existing APIs will be retrofitted to return Optional
, e.g, the following isn’t going to surface the JDK 8:
public interface List<E> { Optional<E> get(int index); [...] }
Not only can we assign null
to an Optional
variable, but the absence of “Optional” doesn’t guarantee the semantics of “SOME”, as lists will still return “naked” null
values. When we mix the two ways of thinking, we will wind up with two checks, instead of one
Optional<T> optional = // [...] T nonOptional = list.get(index); // If we're paranoid, we'll double-check! if (optional != null && optional.isPresent()) { // do stuff } // Here we probably can't trust the value if (nonOptional != null) { // do stuff }
Hence…
-1 from me to Java’s solution
Further reading
Of course, this has been discussed millions of times before. So here are a couple of links:
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Robert Saulnier replied on Thu, 2013/04/18 - 7:15am
You should never need to check if an Optional reference is null. If a method returns an Optional of something, it should return an Optional, not null. If the method has nothing to return, it should return Optional.empty(). If you find a method that returns an Optional and the method returns a null, you're allowed to make fun of the developer who wrote that code :)
Also, depending on what you're doing, you might need to check if Optional has anything with isPresent(), but in some cases you can have Optional return something if it's empty with orElse(T).
And since Optional is used in the Stream API, I give it a +10.
Robert Saulnier replied on Thu, 2013/04/18 - 8:08am
Thinking as I type, methods that return Optional should probably be implicitly be marked as @NotNull (when the new annotations are added).
Lukas Eder replied on Thu, 2013/04/18 - 8:17am
in response to:
Robert Saulnier
Yes, of course. That's why I said "paranoid" :-)
That same developer that you're allowed to make fun of might write things like .orElse(new SomeHeavyObject()). The argument passed to "orElse()" is always evaluated, no matter whether you need it.But the real issue that I was trying to point out is: If you introduce "Optional" then there really should be a "NonOptional", which is guaranteed not to contain null. Ceylon has found a solution to this on a compiler-level. Java will not be able to ensure non-nullability. Even in the Streams API, you will blend Streams with Collections, and then you're back at mixing null checks with presence checks.
Also, mixing an "Optional" type with a "@NonNull" annotation seems like a lot of irregularity in the language / platform to me.
Robert Saulnier replied on Thu, 2013/04/18 - 11:38am
in response to:
Lukas Eder
If orElse() is too expensive, you can use orElseGet(Supplier):
As for streams and collections, you can always filter out nulls.
As for Optional and NonOptional, IMO we already have NonOptional, it's a regular reference. Optional returns a reference or nothing (throw an exception), while NonOptional (or just a reference) returns a reference to an object or null, not quite the same thing. If you want guaranteed non null references, that's where @NonNull comes in.
In your original example, if you want to get a non null value from a list, then it's most likely that the list shouldn't contain null refs.
Danno Ferrin replied on Fri, 2013/04/19 - 4:33pm
It works better with lambdas, and compile time code inspections: