A guide to Java Optional

Optional is one of those APIs that everyone uses and few people use well. Interviewers ask about it because the mistakes are so recognisable: opt.get() without a check, orElse(expensiveCall()), Optional fields on entities, Optional<List<Order>>. A good answer shows you know what it was designed for and, just as important, where it doesn't belong.

For this lesson, we'll focus on why Optional exists, how to create one, how to get the value out safely, the orElse versus orElseGet trap, the functional methods (map, flatMap, filter, or, stream and friends), the anti-patterns, primitive optionals, what an Optional costs, and how it compares with a plain null check.

01Picture it first: a gift box that might be empty

Think of Optional as a gift box with a label that says "may be empty". A raw reference is a box with no label: you reach in confidently and sometimes your hand closes on nothing (a NullPointerException). The labelled box forces a moment of thought. You can open it and use what's inside, pass it along with a transformation ("if there's a shirt, wrap it in paper"), or decide upfront what to do if it's empty ("if empty, hand over a gift card").

The important part of the analogy: you never pass an empty box as a gift. Optional is for the moment of handing back a result, not for storing things in your house or asking guests to bring boxes.

Here's how a chain of Optional operations behaves, depending on whether the box has something in it:

Fig. 1

Two lanes: on the top lane a present value flows through map, filter and then orElse returns the transformed value; on the bottom lane an empty Optional skips map and filter and orElse returns the default, and a filter that fails moves a present value down to the empty lane

02Creating and unwrapping, under the hood

There are three factory methods, and picking the right one is the first thing interviewers notice.

Optional<String> a = Optional.of("ORD-42");
Optional<String> b = Optional.ofNullable(null);
Optional<String> c = Optional.empty();
Optional<String> d = Optional.of(null);

System.out.println(a);              // ?
System.out.println(b.equals(c));    // ?

Exception in thread "main" java.lang.NullPointerException

The program dies on line 4, because Optional.of rejects null with a NullPointerException. Remove that line and you get Optional[ORD-42] and true.

Notice three things:

• Use of when a null would be a bug. The NPE happens right there, at the point of creation, rather than three methods later.
• Use ofNullable at the boundary with code that returns null, such as Map.get or a legacy DAO.
• empty() returns a shared singleton, so it costs nothing. Optional overrides equals to compare contents, which is why b.equals(c) is true.

Inside the JDK, Optional is a final class with a single field, private final T value, where null means empty. That's the whole implementation: every method is an if (value == null) check wrapped in a nice API.

get() versus orElseThrow()

opt.get() returns the value or throws NoSuchElementException("No value present"). The problem isn't what it does, it's that the name sounds harmless, so people call it without checking. Java 10 added the no-argument orElseThrow(), which does exactly the same thing with a name that admits it can fail. The javadoc now recommends it over get().

User u1 = userRepository.findById(id).get();                            // works, hides the risk
User u2 = userRepository.findById(id).orElseThrow();                     // same, honest name
User u3 = userRepository.findById(id)
        .orElseThrow(() -> new UserNotFoundException(id));               // best: a meaningful error

The third form is what I write in service code. A UserNotFoundException can map to a 404, while a NoSuchElementException from deep inside a stack trace becomes a 500 and a confused on-call engineer.

orElse versus orElseGet: the eager-evaluation trap

This is the most common Optional interview question, and also the one that causes real production bugs.

User loadFromDatabase(long id) {
    System.out.println("DB call for " + id);
    return userDao.find(id);
}

Optional<User> cached = cache.get(42L);                    // present
User u1 = cached.orElse(loadFromDatabase(42L));             // prints: DB call for 42
User u2 = cached.orElseGet(() -> loadFromDatabase(42L));    // prints nothing

orElse takes a value, and Java evaluates method arguments before the call. So loadFromDatabase(42L) runs every time, even when the cache hit makes its result useless. orElseGet takes a Supplier, and only calls it when the Optional is empty.

Fig. 2

Timeline comparison: with orElse the database call runs before orElse is entered and its result is thrown away when a value is present; with orElseGet only a lambda is created and the database call happens only on the empty path