I am the founder and CEO of Data Geekery GmbH, located in Zurich, Switzerland. With our company, we have been selling database products and services around Java and SQL since 2013. Ever since my Master's studies at EPFL in 2006, I have been fascinated by the interaction of Java and SQL. Most of this experience I have obtained in the Swiss E-Banking field through various variants (JDBC, Hibernate, mostly with Oracle). I am happy to share this knowledge at various conferences, JUGs, in-house presentations and on our blog. Lukas is a DZone MVB and is not an employee of DZone and has posted 255 posts at DZone. You can read more from them at their website. View Full User Profile

On Java 8's Introduction of Optional

  • submit to reddit

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:


“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


-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:

Published at DZone with permission of Lukas Eder, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


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

[...] you're allowed to make fun of the developer who wrote that code :)

Yes, of course. That's why I said "paranoid" :-)

[...] but in some cases you can have Optional return something if it's empty with orElse(T).

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.

List<@NonNull String> strings = ...

Danno Ferrin replied on Fri, 2013/04/19 - 4:33pm

It works better with lambdas, and compile time code inspections:

@NotNull Optional<T> optT = ...
optT.ifPresent(t -> doSomething(t));

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.