The final keyword in Java

That last sentence is where most interview follow-ups live. final looks like the simplest keyword in Java, yet it touches the compiler (constant folding), the memory model (safe publication of final fields), the JIT (inlining), lambdas (effectively final) and API design (String is final for a reason). Interviewers use it to separate candidates who know the rule from candidates who know what the rule buys you.

For this lesson, we'll focus on final variables, fields, parameters, methods and classes, effectively final and lambdas, the Java Memory Model guarantee for final fields, final references versus immutable objects, compile-time constants and the cross-jar inlining trap, and the classic final vs finally vs finalize question.

01Picture it first: a name tag glued to a locker

Think of a final variable as a name tag glued to one locker. You can't peel it off and stick it on a different locker. But the locker still opens: anyone can put things in or take things out. If you want the contents fixed too, you need a locker that has no door, which is what an immutable object is.

The diagram below shows the difference with a list of tags on an invoice.

Fig. 1

A final reference named tags is locked to one ArrayList on the heap: reassigning it to a new list is a compile error, but calling add on the list succeeds and the list grows from one element to two; a second panel shows an unmodifiable List.of list where add throws UnsupportedOperationException

Notice two things. final protects the arrow, not the box at the end of it. And making the box unchangeable is a property of the object's class (List.of, String, records with immutable components), not of the variable that points to it.

02Under the hood: final variables, fields and parameters

final class Invoice {
    private final String id;                              // blank final: assigned in the constructor
    private final List<String> tags = new ArrayList<>();

    Invoice(String id) { this.id = id; }

    void update(final String note) {
        tags.add(note);               // 1
        tags = new ArrayList<>();     // 2
        note = note.trim();           // 3
        final int max;
        max = 5;                      // 4
    }
}

Lines 2 and 3 fail; 1 and 4 compile. Line 1 mutates the list, which final allows. Line 2 reassigns a final field. Line 3 reassigns a final parameter. Line 4 is a blank final local: declared without a value and assigned exactly once later, which is legal.

The compiler enforces this with definite assignment analysis (JLS chapter 16). A blank final field must be assigned exactly once on every path through every constructor, and never read before that:

final class Payment {
    private final String status;

    Payment(boolean captured) {
        if (captured) status = "CAPTURED";
        else          status = "PENDING";   // both branches assign: compiles
        // a third assignment here would fail: "variable status might already have been assigned"
    }
}

Notice three things:

• final on a local or parameter is purely a compile-time check. The bytecode has no trace of it: a final local and a normal local produce identical class files, apart from a final local with a constant initialiser, which javac inlines.
• final on a field is recorded in the class file (ACC_FINAL) and has runtime meaning, which we'll see in the memory model section.
• Final parameters are a style choice. Some teams mark every parameter final; I prefer a linter rule against reassigning parameters, which gives the same safety without the noise.

Effectively final and lambdas

Since Java 8, a local variable that's never reassigned after initialisation is effectively final, and you can capture it in a lambda or anonymous class without writing final:

int retries = 3;                                    // effectively final
Runnable job = () -> System.out.println("retries=" + retries);
job.run();                                          // prints: retries=3
// retries++;   // would make it not effectively final: the lambda line stops compiling
//              // "local variables referenced from a lambda expression must be final or effectively final"

Why the rule? A lambda may run later, on another thread, after the method has returned and its stack frame is gone. So Java captures a copy of the value, passed as a constructor argument to the generated lambda class or as an extra argument to the synthetic lambda method. If the variable could change afterwards, the copy and the original would silently disagree. Forcing it to be effectively final makes the copy indistinguishable from the original.

03The memory model guarantee for final fields

Here's the part that makes final fields more than documentation. Normally, if one thread creates an object and publishes the reference without synchronization (a data race), another thread can see the reference before it sees the field writes made in the constructor. The JIT and the CPU are allowed to reorder those writes.

Final fields are the exception (JLS 17.5). When a constructor finishes, there is a conceptual freeze of its final fields. Any thread that obtains a reference to the object after that, even through a racy path, is guaranteed to see the final fields' constructed values, and everything reachable through them as of the freeze.

final class Money {
    private final long minorUnits;     // final: always visible once the reference is
    private final String currency;     // final: same guarantee
    private String note;               // not final: another thread may see null

    Money(long minorUnits, String currency, String note) {
        this.minorUnits = minorUnits;
        this.currency = currency;
        this.note = note;
    }
}

static Money lastPrice;                // shared, not volatile: a data race on purpose

// Thread A
lastPrice = new Money(49_900, "INR", "festive sale");

// Thread B
Money m = lastPrice;
if (m != null) {
    long amt = m.minorUnits;   // guaranteed 49900
    String cur = m.currency;   // guaranteed "INR"
    String n = m.note;         // may be null on weakly ordered hardware
}

The diagram traces that handoff from the constructing thread to the reading thread.

Fig. 2

Thread A writes the final fields, a store-store barrier freezes them at the end of the constructor, and the reference is published through a racy static field, after which Thread B reads the reference and is guaranteed to see the frozen final fields while the non-final note may still be null

In HotSpot, this guarantee is implemented with a store-store barrier at the end of a constructor that wrote a final field, which is free on x86 and a cheap fence on ARM. This is why immutable objects with all-final fields (String, Integer, LocalDate, records) are thread-safe even when published carelessly.

The guarantee has one condition: don't let this escape the constructor. If the constructor registers this with a listener or stores it in a static field before it finishes, another thread can see the object before the freeze, and final fields may still read as 0 or null.

04Real world: compile-time constants and the inlining trap

// in shared-lib.jar
public class ApiVersions {
    public static final String CURRENT = "v1";       // later changed to "v2"
    public static final int TIMEOUT_MS = 2000;       // later changed to 5000
}

// in your service, compiled against the old jar
System.out.println(ApiVersions.CURRENT + " " + ApiVersions.TIMEOUT_MS);
// prints: v1 2000  (even with the new jar on the classpath)

It still prints v1 2000. A field that is final, of a primitive type or String, and initialised with a constant expression is a constant variable (JLS 4.12.4). javac doesn't emit a getstatic for it; it copies the value into the caller's constant pool. Here it even folded the concatenation, and javap -c on the client shows a single ldc "v1 2000". The diagram shows how the old value survives the jar swap.

Fig. 3

Compile time: the client is compiled against shared-lib v1 and javac copies the literal v1 into the client's class file. Runtime: shared-lib v2 is on the classpath with CURRENT equal to v2, but the client never reads the field and still prints v1

Inlining also explains a few other facts: switch case labels must be constant expressions, annotation values must be constants, and reading a constant variable doesn't initialise its class (no getstatic, no trigger). static final Integer X = 5 or static final List<String> L = List.of() are not constant variables, because the type isn't primitive or String.

05Advanced: final methods, final classes and the edge cases

Final methods and final classes

A final method can't be overridden. Use it in a class designed for extension when a method holds an invariant subclasses must not change, like the template method in an abstract PaymentProcessor whose process() always validates, then charges, then records. Private methods can't be overridden anyway, so final adds nothing there; on a static method, final stops subclasses from hiding it.

A final class can't be extended. String, Integer, LocalDate and every record are final. For String, it's essential: the class caches its hash code, is shared through the string pool, is used as a HashMap key and in security checks such as file paths and class names. A subclass could override equals or hashCode, or add mutable state, and break all of that. If you want a class to be immutable, making it final (or giving it only private constructors) is part of the recipe. Java 17 added a middle ground: sealed classes list exactly which subclasses are allowed (see Sealed classes and interfaces).

final vs finally vs finalize

They share letters and nothing else:

finally runs on normal completion, on an exception and on return, but not if the JVM halts (System.exit, Runtime.halt, a crash or a killed process). A return inside finally overrides the try's result and swallows any exception:

static int code() {
    try { throw new IllegalStateException("boom"); }
    finally { return 42; }           // the exception disappears
}
System.out.println(code());          // prints: 42

finalize() was a bad idea from the start: no guarantee it ever runs, no ordering, it can resurrect objects, it slows down GC, and it's a security hole (finalizer attacks on partially constructed objects). For resources, use try-with-resources; for a safety net, use java.lang.ref.Cleaner. You can run Java 18+ with --finalization=disabled to check whether your code still depends on finalizers.

Final isn't absolute: reflection

Deep reflection can still change a non-static final instance field: field.setAccessible(true); field.set(obj, newValue) works on ordinary classes. It fails for static final fields, record fields and hidden classes. And if the field is a constant variable, code that reads it was inlined at compile time, so the change is invisible to those reads, which is why serialization libraries that set final fields through reflection only work reliably on non-constant fields. JEP 500 ("Prepare to Make Final Mean Final") starts closing this door: on JDK 26, mutating a final field reflectively prints a warning, and a later release plans to block it unless you opt in with --enable-final-field-mutation.

A few smaller rules that come up as follow-ups:

• An interface field is implicitly public static final.
• A final local in a catch (or a multi-catch parameter, which is implicitly final) can't be reassigned.
• Try-with-resources accepts an effectively final variable since Java 9: try (conn) { ... }.
• final and abstract can't be combined on a method or class: one says "no overriding", the other says "must be overridden".

06How to say it in the interview

When I ask about final, I'm listening for four things: the reference versus object distinction, why lambdas need effectively final, the memory model guarantee for final fields, and the constant inlining trap. If you also separate final, finally and finalize cleanly and know finalize is on its way out, you've covered the whole keyword.

final var    : assign once (definite assignment), compile-time only
final field  : ACC_FINAL + JMM freeze at end of ctor (JLS 17.5)
               -> safe publication, if `this` doesn't escape
final method : no override (CHA makes perf gain ~0)
final class  : no subclass (String, Integer, records)
final ref != immutable object: final List -> add() OK
lambda capture: final / effectively final (copy of value)
constant var : final + primitive/String + constant expr
               -> inlined (ldc), change needs client recompile
finally: always runs (not on System.exit); return in finally swallows
finalize: deprecated for removal (JEP 421, Java 18) -> Cleaner, TWR