Java Optional: Compare a Ready Fallback with a Deferred Supplier

Make the fallback visible

Define a fallback method that increments a local test counter and returns Guest. Prepare Optional.of("Practice") and Optional.empty(). Reset the counter before every comparison so earlier calls do not contaminate later observations. Record both the returned string and the counter.

Test the present-value case

Evaluate present.orElse(fallback()). The fallback method runs while Java evaluates the argument, even though Optional then returns Practice. With present.orElseGet(() -> fallback()), the supplier body is not needed and the counter stays unchanged. Both expressions return Practice; their work traces differ.

Repeat with the empty case

With an empty Optional, each version obtains Guest from the fallback method. The expected counter increment is one in each separately reset test. A four-row worksheet covering present/empty and the two methods makes the comparison clearer than a single printed value.

Keep deferred work inside the supplier

A lambda such as () -> fallback() supplies work to run if needed. Do not assume every expression passed to orElseGet is deferred. An ordinary method call used to construct its supplier argument still follows Java argument-evaluation rules. Distinguish construction of the supplier from execution of its body.

Review the intended contract

• Use an already available fallback value when that is all the code needs.
• Use a supplier when producing the fallback should wait until needed.
• Avoid database writes or other irreversible effects in the demonstration.
• Keep each test independent and inspect the counter as well as the returned text.

Connect the trace to readable code

The purpose is to explain when work happens without relying on a performance claim. Java APIs and Java 8+ functional foundations fit the Mango Engineers Java learning path. Preserve the tiny experiment with your notes so another learner can reproduce the four observations.