Optional, and the Habit It Is Trying to Break

Change what the method promises.

Optional<Student> findByRoll(int roll) { ... }

Now the signature says what is true. There might be a student. There might not. The caller cannot get at the value without dealing with both cases, because there is no name() method on an Optional.

findByRoll(999).name();   // does not compile

That failure is the entire point. The mistake moved from run time to compile time.

Making one:

Optional.of(student)          // I have a value. Throws NPE if it is null
Optional.ofNullable(maybe)    // might be null, sort it out for me
Optional.empty()              // definitely nothing

of throwing on null looks unhelpful and is deliberate. Optional.of(x) is you telling Java there is a value. If there is not, you were wrong, and finding out immediately beats carrying an empty Optional you thought was full.

Opening it, and the wrong way first:

if (result.isPresent()) {
    use(result.get());
}

That works and it is a waste. You have swapped != null for isPresent() and kept every problem: two branches to write, and the possibility of skipping the check and calling get() anyway.

The right way is to not open it at all. Say what should happen and let the Optional apply it:

map and filter are the ones that change how the code reads. They are the same two methods from streams, doing the same job on a container that holds nothing or one thing.

The four levels of indentation collapse:

String city = findByRoll(101)
    .map(Student::address)
    .map(Address::city)
    .map(City::name)
    .orElse("unknown");

One expression. If anything in the chain is empty, everything after it is skipped and orElse supplies the answer. There is no if, and there is nothing to forget.

Answer from memory before opening the explanation. Then compare your rule with the answer and revisit the example if they differ.

1. `orElse` and `orElseGet` return the same value. What is different?

   Show the answer

   When the fallback is built.

   orElse(expensive()) is an ordinary method call, so its argument is worked out before orElse starts. The fallback is built every time, including when the Optional has a value and the fallback is thrown away unused.

   orElseGet(this::expensive) takes a Supplier. Nothing is built until orElseGet decides it needs one, which it only does when the Optional is empty.

   You can watch it. Put a print inside the fallback, call both on an Optional that has a value, and only orElse prints.

   For a constant like orElse("unknown") it makes no difference. For anything that hits a database, reads a file or allocates, it is the difference between doing the work and not doing it.

2. What is wrong with `if (result.isPresent()) { use(result.get()); }`?

   Show the answer

   It is a null check with more typing.

   You have replaced if (x != null) with if (x.isPresent()) and gained nothing at all. The forgetting is still possible: nothing stops the next person calling get() without the if, and that throws.

   Optional is worth having when you never open it. Say what should happen instead: map, filter, orElse, orElseGet, ifPresent, orElseThrow. Each of those handles the empty case as part of asking.

   If you find yourself writing isPresent followed by get, there is nearly always a single method that does the same job and cannot be got wrong.

3. Why should `Optional` not be used for a field or a method parameter?

   Show the answer

   Because it was designed for one job: a return type saying "there might be nothing here".

   As a field it costs you an extra object per instance for no benefit, and it does not serialise. A field that might be absent is already expressible: the field is null, and inside your own class you control that.

   As a parameter it makes the caller worse off. Now they have to wrap their value on the way in, and there are three cases to handle instead of two: a value, an empty Optional, and a null Optional. Two overloads say the same thing more clearly.

   Coming back the other way it earns its place, because the caller cannot ignore it without deciding to.

Write each solution in VS Code, predict its result, and then run the checks. Reading an example does not replace implementing it.

4 exercises95 pointsabout 95 minutes

findUser(id).orElse(loadDefaultUserFromDatabase());

import java.util.*;

public class Fallback {
    static String expensive() {
        System.out.println("  ** expensive() ran **");
        return "fallback";
    }

    public static void main(String[] args) {
        Optional<String> present = Optional.of("real");
        Optional<String> empty   = Optional.empty();

        // TODO: orElse and orElseGet on the PRESENT one. Predict the prints first.
        // TODO: the same two on the EMPTY one.
        // TODO: put both in a loop of 1000 and time them
        // TODO: say when orElse is the better choice anyway
    }
}

import java.util.*;

public class Flatten {
    record City(String name) { }
    record Address(City city) { }
    record Student(String name, Address address) { }

    static Optional<Student> findByRoll(int roll) {
        if (roll == 101) return Optional.of(new Student("Aditya", new Address(new City("Pune"))));
        if (roll == 102) return Optional.of(new Student("Rohit", null));
        return Optional.empty();
    }

    public static void main(String[] args) {
        // TODO: get the city name for roll 101, using isPresent and get. Count the ifs.
        // TODO: the same thing with map and orElse. Count the lines.
        // TODO: try roll 102, where the address is null. What breaks, and how do you fix it?
        // TODO: try roll 999. Predict before running.
    }
}

import java.util.*;

public class Misuse {
    // TODO: each of these is a bad use. Work out why, then write the better version.

    // 1. a field
    static class Account { Optional<String> nickname; }

    // 2. a parameter
    static void greet(Optional<String> name) { }

    // 3. a null Optional
    static Optional<String> lookup() { return null; }

    // 4. isPresent then get
    static String describe(Optional<String> o) {
        if (o.isPresent()) return o.get().toUpperCase();
        return "none";
    }

    public static void main(String[] args) {
        // TODO: show what goes wrong with number 3 at the call site
        // TODO: rewrite number 4 as a single expression
        // TODO: try Optional.of(null) and read the exception
    }
}

import java.util.*;
import java.util.stream.*;

public class Both {
    static Optional<String> lookup(int id) {
        return id % 3 == 0 ? Optional.empty() : Optional.of("value" + id);
    }

    public static void main(String[] args) {
        List<Integer> ids = List.of(1, 2, 3, 4, 5, 6, 7);

        // TODO: map each id through lookup. What type do you have now?
        // TODO: get a List<String> of only the ones that were found,
        //       WITHOUT writing isPresent anywhere
        // TODO: do the same again a different way
        // TODO: count how many were missing
        // TODO: find the first one that was found, and give a default if none were
    }
}