How does making a method `final` interact with the template-method pattern and JIT optimization, and what subtle pitfalls exist when finalizing methods in an inheritable class?

## The template-method pattern The **template method** is a design pattern where a base class defines the *skeleton* of an algorithm in one method, deferring some steps to subclasses. The skeleton calls **hook methods** (abstract or overridable) that subclasses implement. Example: a `Game.play()` method that does `initialize(); startPlay(); endPlay();` where the three steps are overridable but the *order and the surrounding logic* are fixed. The skeleton method is the natural place for `final`: you want the *structure* locked so no subclass can change the sequence, error handling, or invariants — but you want the *steps* open. So: ```java public abstract class Game { public final void play() { // skeleton: FINAL, cannot be reordered initialize(); startPlay(); endPlay(); } protected abstract void initialize(); // hooks: open for override protected abstract void startPlay(); protected abstract void endPlay(); } ``` This is *defensive design*: the final skeleton enforces the contract; the open hooks provide flexibility. It's the precise scenario where finalizing a *method* (not the whole class) is correct. ## Interaction with the JIT A virtual (overridable) method call in Java is, in principle, **polymorphic**: the JVM must look up the actual implementation based on the receiver's runtime type (a *vtable* dispatch). A `final` method has exactly **one** possible implementation, so the JIT can perform **devirtualization** — resolve the target statically — and then **inline** the body directly into the caller, eliminating the call overhead and enabling further optimizations. The subtlety for a principal: **modern HotSpot already does this for non-final methods speculatively.** Using *class-hierarchy analysis* and profiling, the JIT observes that a call site is *monomorphic* (only one implementation seen so far) and inlines it with a guard / deoptimization fallback. If a second implementation later loads, it **deoptimizes** and recompiles. So `final` gives a *guaranteed* monomorphic target (no guard, no deopt risk), but the practical performance delta over the JIT's speculative inlining is usually small. **Conclusion:** use final for *design/correctness*, not as a primary performance lever — the JIT mostly closes the gap. ## Pitfall 1 — calling overridable methods from constructors This is the most dangerous interaction. During construction, the superclass constructor runs **before** the subclass's field initializers and constructor body. If the superclass constructor calls an *overridable* method, the **subclass's override executes against an uninitialized subclass** — its fields are still default (`null`/`0`): ```java class Base { Base() { init(); } void init() {} } class Sub extends Base { private String name = "set"; @Override void init() { System.out.println(name); } // prints null! } ``` `name` prints `null` because `init()` runs from `Base()`'s constructor *before* `name = "set"` executes. The fix: make methods called from constructors `final` or `private` (both non-overridable) so the constructor always calls the known, safe implementation. This is *Effective Java* Item 19's "constructors must not invoke overridable methods." ## Pitfall 2 — finalizing is a breaking change If a method was previously *open* and existing subclasses (yours or third parties') override it, adding `final` is a **source- and behavior-breaking change**: their overrides no longer compile / no longer take effect. For a published library this breaks downstream code. Finalization decisions on a public API must be made *before* release, because relaxing (removing final) later is safe but tightening (adding final) is not. ## Pitfall 3 — redundant final - `private` methods are **not** inherited and thus **not overridable** — they're effectively final already; marking them `final` is redundant noise. (A same-signature method in a subclass is a *new* method, not an override.) - Methods in a `final` class are likewise un-overridable; marking them final is redundant. - `static` methods can be *hidden* but not *overridden*; `final` on a static method only prevents hiding, a rarely needed nuance. ## Pitfall 4 — over-finalizing Locking a method removes a legitimate extension seam. In frameworks, users often need to override behavior you didn't anticipate; an over-zealous final can force ugly workarounds (reflection, copy-paste). Balance: finalize what is genuinely invariant (security, the template skeleton), leave true hooks open, and consider `sealed` hierarchies when you want a *controlled* set of extensions rather than a binary open/closed. ## How to derive the answer Start from *what final guarantees*: one implementation, no override. Apply it to the template method (lock the skeleton, open the hooks). Recognize the JIT already exploits monomorphism, so final is mainly correctness. Then enumerate where a single guaranteed implementation matters or surprises: constructors (overridable calls see uninitialized state → finalize them), API evolution (finalizing later breaks subclasses), and redundancy (private/final-class methods).