Optional.orElse vs orElseGet — Eager vs Lazy Defaults

Both orElse and orElseGet return a default when the Optional is empty, but they differ in when the default is computed.

`orElse(value)`

• Takes a value directly
• Java evaluates the argument before the method call — the default is always computed
• Even when the Optional is present, the default expression runs
• Use for constants, singletons, literals

`orElseGet(supplier)`

• Takes a Supplier
• The supplier is only invoked when the Optional is empty
• If present, the supplier is never called
• Use for expensive defaults: method calls, I/O, allocation, side effects

Why the difference matters

Java is strict-evaluated: when you write foo(bar()), bar() always runs first, even if foo ignores its argument. So optional.orElse(slowFetch()) runs slowFetch() on every call — even when the Optional is present.

With optional.orElseGet(() -> slowFetch()), the lambda is deferred; Optional only calls it on the empty branch.

The classic bug — caching defeated

// WRONG: DB called every time, even on cache hit
User u = userCache.find(email).orElse(loadFromDatabase(email));

// RIGHT: DB called only on cache miss
User u = userCache.find(email).orElseGet(() -> loadFromDatabase(email));

Under load, the wrong version makes the cache pointless — you pay the slow path on every request.

When each is appropriate

`orElse` for:

• Constants: orElse("Unknown"), orElse(0)
• Singletons: orElse(EMPTY_LIST), orElse(GUEST_USER)
• Pre-computed values already in memory

`orElseGet` for:

• DB or network calls: orElseGet(() -> repo.findGuest())
• Env lookups: orElseGet(() -> System.getenv("DEFAULT"))
• Allocations: orElseGet(() -> new User())
• Anything with side effects: logging, metrics

Same pattern for `orElseThrow`

• Argless orElseThrow() (Java 10+) throws NoSuchElementException — no Supplier
• orElseThrow(() -> new UserNotFoundException(email)) lazily constructs the exception
• Important when exception construction is expensive (stack traces, message formatting)

The pattern generalizes — lazy vs eager APIs

• Map.computeIfAbsent(key, Function) — lazy
• SLF4J: logger.info("x={}", supplier) — lazy formatting (only formats if level enabled)
• Stream.generate(Supplier) — lazy production
• Anywhere you see overloads taking T vs Supplier, the Supplier is for expensive computations

Pitfalls

• "It just builds an object" — small per-call cost adds up under load
• Side effect in `orElse` arg — logs/metrics fire even when value is present (silent bug)
• Reflexively using `orElseGet` — orElseGet(() -> "Unknown") is uglier than orElse("Unknown")
• Reflexively using `orElse` — perf cost is real for non-trivial defaults

Recommendation: Use `orElse` for constants and singletons — it reads cleaner and there's no cost. Use `orElseGet` for any default that involves a method call, I/O, allocation, or side effect — the lazy supplier saves you from doing the work on the present branch. The classic perf bug is optional.orElse(repo.findGuest()) — DB called every time, defeating any caching. Same logic applies to `orElseThrow(Supplier)` for expensive exception construction. The principle generalizes: anywhere you see two overloads (T vs Supplier), the Supplier version is for cases where the computation isn't free — logging, default loading, fallback computation. Pick based on the actual cost of computing the default, not on which method name is shorter.