Do final fields receive default values, and how does that interact with the requirement that a final field must be assigned exactly once?

## Recap: defaults vs. assignment Every field is **default-initialized** when the object's memory is zeroed: numeric→0, boolean→false, char→'', reference→null. Separately, the compiler may *also* require you to assign a value. For ordinary fields, assignment is optional (the default stands). For **final** fields, assignment is mandatory and constrained. ## What `final` means on a field Declaring a field `final` means it can be assigned **exactly once** and never changed afterward. A `final` field with no initializer is called a **blank final** — 'blank' because its value is deferred to the constructor (for instance fields) or a static initializer (for static fields). ## The compiler rules (definite assignment, extended) The same **definite-assignment analysis** that governs local variables is extended for finals to also check **definite *un*assignment** (it isn't assigned more than once): - A blank final **instance** field must be definitely assigned by the end of **every** constructor that doesn't delegate via `this(...)`, on **every** path. Miss one path → 'variable might not have been initialized'. - It must be assigned **at most once** — assigning twice, or assigning then reassigning, is a compile error. - A blank final **static** field must be assigned exactly once in a **static initializer block** (or at declaration). So even though the JVM transiently sets the final field to its type default, you can never *rely* on that default: the compiler won't let the field remain unset. Example: ```java class C { final int n; // blank final C(boolean b) { if (b) n = 1; // compile error: n might not be initialized } // (the b==false path leaves n unassigned) } ``` Fix by assigning on all paths or at declaration. ## Why the default still 'exists' During object construction the timeline is: (1) memory zeroed to defaults, (2) field initializers/instance blocks run, (3) constructor body runs and must assign the blank final. There is a real window where the final field holds its default. This matters if construction is buggy. ## The Java Memory Model angle The Java Memory Model gives `final` fields a special guarantee: if an object is **properly constructed** (its reference does not 'escape' — become visible to other threads — before the constructor finishes), then any thread that sees the object is guaranteed to see the correctly assigned `final` field values, with no synchronization. But if `this` leaks during construction (e.g., you register `this` with a listener inside the constructor), another thread can observe the final field still holding its **default** value. This is exactly why the transient default state is a correctness hazard and why 'don't let this escape during construction' is a rule. ## Summary Finals do get a default transiently, but you must explicitly assign them exactly once before construction completes; the default is never their resting value, and leaking the object mid-construction can expose that default to other threads.