What is Optional, and how should it be used properly?

Optional<T> is a container object that either holds a non-null value or is empty, designed to make "this might have nothing to return" explicit in the type signature — the caller can't accidentally forget a null check the way they can with a plain reference that might be null.

Optional<User> findUser(String id) {
    User u = repository.lookup(id);
    return Optional.ofNullable(u); // empty if u was null
}

Good usage patterns:

findUser(id)
    .map(User::getEmail)                 // transform if present
    .filter(email -> email.contains("@"))
    .orElse("no-email@example.com");     // default if empty/filtered out

findUser(id).ifPresentOrElse(
    user -> sendWelcome(user),
    () -> logMissingUser(id)
);

User user = findUser(id).orElseThrow(() -> new UserNotFoundException(id));

Common misuses to avoid:

• Calling .get() directly without checking isPresent() first — this just reintroduces the same "forgot to check" risk Optional was meant to prevent; prefer orElse/orElseGet/orElseThrow/map/ifPresent instead.
• Using Optional as a field type — it's not Serializable and adds an unnecessary wrapper allocation; for fields, a null (or a documented sentinel) plus normal null-handling is the JDK team's own recommendation.
• Using Optional as a method parameter type — forces every caller to wrap a value in Optional.of(...) just to call the method; overloading or a null-accepting parameter is usually cleaner.
• Wrapping every return value reflexively — Optional is meant specifically for "may legitimately have no result" cases (a lookup that might not find anything), not as a blanket replacement for all nullable returns.

Design intent, in one line: Optional is a return-type-only tool for communicating "no result" explicitly at API boundaries — not a general-purpose null-replacement mechanism throughout a codebase.