Optional Class in Java: What It Is and Why You Need It - Quiz

Optional<T> is a container class from the java.util package that is always in exactly one of two states: it either holds a single value of type T (the reference inside is never null) or it is empty. The class was introduced in Java 8, alongside lambda expressions. It is declared final and is immutable: you cannot put a different value into an existing container, and any "modification" produces a new object. Its whole point is to state a possibly missing value explicitly in the type system instead of hiding it behind null — a method declared to return Optional<String> warns through its very signature that there may be no result.

The constructors of Optional are declared private, so the line new Optional<>("text") simply does not compile. That is deliberate: factory methods can hand back one shared instance for the empty state and can guarantee that a non-empty container never wraps null. Instances come from three static methods: Optional.empty() — an empty container, Optional.of(value) — a container for a value you know is not null, and Optional.ofNullable(value) — a container with the value, or an empty one if the argument is null.

The difference is how they react to null. Optional.of(value) wraps the value and throws a NullPointerException immediately if the argument is null. Optional.ofNullable(value) never throws: a non-null argument produces a non-empty container, and a null argument produces Optional.empty(). The rule of thumb: use of() when null is unacceptable and means a bug that must be caught right away; use ofNullable() when null is a legitimate outcome — data from a third-party API, a database or a cache. Wrapping a call in Optional.of() "just in case", without being sure about the argument, achieves nothing: you have merely moved the NullPointerException one line up.

The signature Chapter getChapter(int number) says nothing about whether a missing chapter produces null or an exception — the contract lives in the documentation, and a forgotten check turns into a NullPointerException on the user's machine. The signature Optional<Chapter> getChapter(int number) declares the possible absence right in the return type: Optional<Chapter> has no getSummary() method, so the calling code cannot reach the value by accident and has to unwrap the container deliberately. The scenario the class was designed for is a method return type. For fields and parameters Optional is used far less often: it does not implement Serializable, it allocates an extra object per field and it gets in the way of frameworks that map fields onto database columns; for an optional parameter an overloaded method is simpler.

No. The Optional reference itself can be null if somebody assigns null to it instead of Optional.empty(). On top of that, calling get() on an empty container throws a NoSuchElementException — essentially the same crash wearing a different name — and Optional.of(null) throws a NullPointerException at the point of creation. Optional does not remove errors automatically: it turns a missing value from an implicit assumption into an explicit part of the type. Hence the practical rules: a method returning Optional never returns null; for an empty collection return Collections.emptyList() rather than Optional<List<String>>; and compare containers with equals(), not ==.