Optional Class

What is Optional and Why Does It Exist?

java.util.Optional<T>, introduced in Java 8, is a container that either holds a value or is empty. Its purpose is not to replace every nullable field in Java — it is specifically designed as a return type to make the possibility of absence explicit in a method's contract.

The problem it solves: when a method returns null to signal "not found", the caller has no way of knowing this from the method signature. Nothing in the type system reminds them to check. The result is NullPointerException — Java's most common runtime error — appearing far from the code that caused it.

// ❌ null return: absence invisible in the signature, NPE risk
public User findById(long id) {
    return db.find(id);  // returns null if not found — caller has no idea
}

User user = findById(123);
user.getEmail();  // 💥 NullPointerException if user was not found

// ✅ Optional: absence is part of the contract — caller MUST handle it
public Optional<User> findById(long id) {
    return Optional.ofNullable(db.find(id));
}

findById(123)
    .map(User::getEmail)
    .ifPresent(emailService::sendWelcome);  // safe — no NPE possible

Creating Optionals

// Three factory methods — choose based on what you know at call time

// Optional.of() — value is guaranteed non-null (throws NPE if null)
// Use when null would be a programming error
Optional<String> name = Optional.of("Alice");

// Optional.ofNullable() — value might be null (safe wrapping)
// Use when wrapping values from external sources (DB, APIs, legacy code)
Optional<User> user = Optional.ofNullable(db.findById(id));

// Optional.empty() — explicitly no value
// Use for early returns or as the "not found" result
public Optional<User> findByEmail(String email) {
    if (email == null || email.isBlank()) return Optional.empty();
    return Optional.ofNullable(db.findByEmail(email));
}

Extracting Values

The functional methods are always preferred over get(). Each forces you to decide what to do when the value is absent — making the absence handling explicit and deliberate.

Optional<String> opt = findUsername(id);

// ─── orElse: constant fallback — always evaluated ───
String name = opt.orElse("Anonymous");

// ─── orElseGet: lazy fallback — only called when empty ───
String name = opt.orElseGet(() -> generateGuestName());  // preferred for expensive defaults

// ─── orElseThrow: required value — throw meaningful exception ───
String name = opt.orElseThrow(() -> new UserNotFoundException(id));

// ─── ifPresent: side effect only when present ───
opt.ifPresent(emailService::send);

// ─── ifPresentOrElse (Java 9+): handle both cases ───
opt.ifPresentOrElse(
    u  -> log.info("Found: {}", u),
    () -> log.warn("User {} not found", id)
);

// ─── or (Java 9+): fallback Optional — cascading lookups ───
Optional<User> found = findInCache(id)
    .or(() -> findInDatabase(id))
    .or(() -> findInExternalService(id));

// ❌ expensiveOp() runs even when opt has a value
String result = opt.orElse(expensiveOp());

// ✅ expensiveOp() only runs when opt is empty
String result = opt.orElseGet(() -> expensiveOp());

// ❌ get() on empty Optional throws NoSuchElementException
String name = opt.get();  // RuntimeException if empty — no better than NPE

// ❌ isPresent() + get() defeats Optional's purpose
if (opt.isPresent()) {
    process(opt.get());   // same as null check — don't do this
}

// ✅ Use the functional API
opt.ifPresent(this::process);

Transforming Values: map, flatMap, filter

// map(): transform the value — returns Optional of the result
// If empty, stays empty. If mapper returns null, becomes empty.
Optional<String> email = findUser(id)
    .map(User::getName)         // Optional<String>
    .map(String::toUpperCase);  // Optional<String>

// flatMap(): mapper returns Optional — prevents Optional<Optional<T>>
class User {
    public Optional<Address> getAddress() { ... }  // already returns Optional
}

// ❌ map() gives Optional<Optional<Address>> — wrong
Optional<Optional<Address>> nested = findUser(id).map(User::getAddress);

// ✅ flatMap() flattens to Optional<Address> — correct
Optional<Address> address = findUser(id).flatMap(User::getAddress);

// Deep chain — null-safe at every step, no explicit checks
String city = findUser(id)
    .flatMap(User::getAddress)
    .flatMap(Address::getCity)
    .map(City::getName)
    .orElse("Unknown");

// filter(): keep value only if predicate passes
Optional<String> validEmail = Optional.ofNullable(input)
    .filter(s -> !s.isBlank())
    .filter(s -> s.contains("@"))
    .map(String::toLowerCase);

// stream() (Java 9+): convert to Stream of 0 or 1 elements
// Most useful to filter a stream of Optionals
List<User> found = userIds.stream()
    .map(this::findById)        // Stream<Optional<User>>
    .flatMap(Optional::stream)  // Stream<User> — empties discarded
    .toList();

Real-World Patterns

Repository pattern — the canonical use case

// Interface declares absence explicitly at the type level
public interface UserRepository {
    Optional<User> findById(Long id);
    Optional<User> findByEmail(String email);
    List<User>     findAll();          // collection: empty list, NOT Optional<List>
    List<User>     findByRole(String role);
}

// Service layer — each operation selects the right handler
public class UserService {

    // Required: not found = domain error
    public User getOrThrow(Long id) {
        return repo.findById(id)
            .orElseThrow(() -> new UserNotFoundException(id));
    }

    // Optional display — not found = show default
    public String getDisplayName(Long id) {
        return repo.findById(id)
            .map(User::getDisplayName)
            .orElse("Anonymous");
    }

    // Conditional action — only act if found AND has email
    public void sendWelcome(Long id) {
        repo.findById(id)
            .flatMap(User::getEmail)
            .ifPresent(emailService::sendWelcome);
    }
}

Configuration access with fallbacks

public class AppConfig {
    private final Map<String, String> props;

    public Optional<String> get(String key) {
        return Optional.ofNullable(props.get(key));
    }

    public int getInt(String key, int defaultValue) {
        return get(key).map(Integer::parseInt).orElse(defaultValue);
    }

    public String getRequired(String key) {
        return get(key).orElseThrow(
            () -> new IllegalStateException("Missing required config: " + key));
    }
}

int port   = config.getInt("server.port", 8080);
String url = config.getRequired("database.url");  // fails fast at startup

Cascading lookups with or()

// Try cache → DB → external service — first hit wins
public Optional<Product> findProduct(String sku) {
    return cache.get(sku)
        .or(() -> db.findBySku(sku))
        .or(() -> externalCatalog.lookup(sku));
}

Common Pitfalls

// ❌ Optional is not Serializable — breaks JPA, Jackson, caching
public class User {
    private Optional<String> middleName;  // never do this
}

// ✅ Nullable field, Optional only in the getter
public class User {
    private String middleName;  // null if absent

    public Optional<String> getMiddleName() {
        return Optional.ofNullable(middleName);
    }
}

// ❌ Caller must write: createUser("Bob", Optional.empty()) — ugly
public void createUser(String name, Optional<String> email) { ... }

// ✅ Overloading is cleaner
public void createUser(String name)                   { createUser(name, null); }
public void createUser(String name, String email)    { ... }

// ✅ Or Builder for many optional parameters

// ❌ Collections already represent emptiness with .isEmpty()
public Optional<List<User>> findAll() { ... }

// ✅ Return empty collection — callers don't need double unwrapping
public List<User> findAll() {
    return users != null ? users : List.of();
}

// ❌ Optional<Optional<String>> — always wrong
Optional<Optional<String>> nested = user.map(User::getEmail);  // getEmail returns Optional

// ✅ flatMap flattens the nesting
Optional<String> email = user.flatMap(User::getEmail);

Senior Topics: Optional in Production

Performance: Optional has a cost

// Optional wraps a value in an object on the heap.
// In hot paths (tight loops, high-throughput processing) this matters.

// ❌ Optional in a loop over millions of elements: millions of allocations
long count = items.stream()
    .map(item -> findPrice(item))  // findPrice returns Optional<BigDecimal>
    .filter(Optional::isPresent)
    .mapToLong(opt -> opt.get().longValue())
    .sum();

// ✅ For primitives: OptionalInt/Long/Double — no boxing overhead
OptionalInt  optInt    = OptionalInt.of(42);
OptionalLong optLong   = OptionalLong.empty();
int          value     = optInt.orElse(0);   // no Integer allocation

// ✅ In hot paths: consider returning null internally + wrapping at boundaries
private User findInternal(long id) { return cache.get(id); }  // null ok internally
public Optional<User> findById(long id) { return Optional.ofNullable(findInternal(id)); }

Optional with Spring Data JPA

// Spring Data automatically generates Optional-returning methods
public interface UserRepository extends JpaRepository<User, Long> {
    Optional<User> findByEmail(String email);
    Optional<User> findByUsernameAndActive(String username, boolean active);
}

// JpaRepository.findById() returns Optional<T> — idiomatic since Spring 5
User user = userRepository.findById(id)
    .orElseThrow(() -> new ResponseStatusException(
        HttpStatus.NOT_FOUND, "User " + id + " not found"));

Optional vs exceptions: when to use each

/*
 *  Use Optional when:
 *  - "Not found" is a NORMAL, expected outcome (user search, config lookup)
 *  - The caller decides what to do with absence
 *
 *  Use exception when:
 *  - Absence means something WENT WRONG (required config missing, data corruption)
 *  - The contract says the value must exist
 *
 *  Pattern: Optional at the repository level, exception at the service/use-case level
 */

// Repository — returns Optional (absence is normal)
public Optional<Order> findById(long id) { ... }

// Service — translates Optional to exception based on business rule
public Order getOrderForShipping(long id) {
    return orderRepo.findById(id)
        .filter(o -> o.getStatus() == PENDING)
        .orElseThrow(() -> new OrderNotShippableException(id));
}

Interview Questions