final classes and methods

Written Explanation

Three meanings of final

You already know final on a variable or field: it can be assigned once. The same keyword has two more meanings in the world of inheritance:

The three share one idea: "this part is settled".

final methods

Put final in the method declaration and children can use the method but never replace it. The Oracle tutorial says that you might make a method final if its implementation should not change and is critical to the consistent state of the object.

class Account {
    private double balance;

    final void audit() {
        System.out.println("audit: balance = " + balance);
    }
}

A subclass that tries to override it fails to compile:

class CheckingAccount extends Account {
    @Override
    void audit() {
        System.out.println("skipping audit");
    }
}

Main.java:13: error: audit() in CheckingAccount cannot override audit() in Account
    void audit() {
         ^
  overridden method is final

All children share the exact audit() code. A rule that must hold for every account type, such as an audit step, is a good candidate.

A final method is still inherited and callable: checking.audit() works. Only replacing it is forbidden.

final classes

Put final before class and nobody can extend it:

final class Money {
    private final long cents;
    Money(long cents) { this.cents = cents; }
    Money plus(Money other) { return new Money(cents + other.cents); }
    long getCents() { return cents; }
}

class Euro extends Money { ... }

Main.java:11: error: cannot inherit from final Money
class Euro extends Money {
                   ^

The Java Language Specification (section 8.1.4) says it is a compile-time error if the class named in extends is final, because final classes are not allowed to have subclasses. The tutorial's example of a final class from the standard library is String. I also confirmed it by checking the class modifiers of String in a short program; they are public final.

Why immutable classes should be final

In the previous module you built an immutable Money: final fields, no setters. But immutability is a promise about this class. If it can be extended, a subclass can break the promise. Here Money is not final, and a sneaky subclass keeps its own changeable value:

class Money {
    private final long cents;
    Money(long cents) { this.cents = cents; }
    long getCents() { return cents; }
}

class SneakyMoney extends Money {
    private long override;
    SneakyMoney(long cents) { super(cents); override = cents; }
    void change(long c) { override = c; }
    @Override
    long getCents() { return override; }
}

In main, store a SneakyMoney in a variable of type Money (a subclass object may be used where the parent type is expected; the next module explains it fully), print getCents(), call change(1) on the sneaky object, and print again:

500
1

Code that received a "Money" and believed it could never change was wrong. Making Money final, or getCents() final, closes the hole. That is why immutable classes should be final, and why String is.

A constructor must not call an overridable method

Remember the construction order from Lesson 2: the parent part is built first. If a parent constructor calls a method that a child overrides, the override runs before the child's own fields are set:

class Report {
    Report() {
        System.out.println(title());
    }

    String title() { return "Report"; }
}

class SalesReport extends Report {
    private String quarter = "Q3";

    @Override
    String title() { return "Sales " + quarter; }
}

new SalesReport() prints:

Sales null

quarter was not assigned yet when the parent constructor ran, so the override saw null. The tutorial gives the same advice: methods called from constructors should generally be declared final, because a subclass could redefine them with surprising results. Two fixes: declare title() final in Report (then it prints Report), or do not call overridable methods from constructors.

Open or closed: a design decision

Inheritance is a promise to your future children, and you may not want to keep it. A common rule among Java developers is "design and document for inheritance, or else prohibit it". Reasons to leave a class open:

• It is meant as a base class and its methods are documented as extension points.

Reasons to close it with final:

• It is a value or security-critical class (Money, identifiers, passwords).
• It is immutable.
• You have not thought about how it would be extended. Closing is safe: you can remove final later without breaking any user, but you cannot add it after others have already extended the class without breaking them.

Java has further tools for fine control over who may extend a class (such as sealed classes, which appear in the language specification), but this course does not need them yet.