How does definite assignment interact with final variables and blank final fields?

## Background terms - **`final` variable**: a variable that may be assigned **exactly once**. After that single assignment its value (the reference or primitive) cannot change. (For object references, the *object's* contents can still change; `final` freezes the reference, not the object.) - **Blank final**: a `final` declared with **no initializer**, e.g. `final int x;`. It starts unassigned and you assign it later — but still only once. - **Definite assignment (DA)**: the compile-time guarantee that a variable is set on every path before it is read (covered in the basic definite-assignment question). - **Definite unassignment (DU)**: the *mirror* analysis — the guarantee that a variable is **not yet assigned** on any path reaching a particular point. ## The two checks that make `final` work `final` is enforced entirely by flow analysis at compile time, using both checks: 1. **Before a read** of a final: it must be **definitely assigned** (so you never read an unset final). 2. **Before each assignment** to a `final` local or blank final: it must be **definitely unassigned** (so you never assign it twice). The second check is the one that produces the classic error *"variable x might already have been assigned"*. ```java final int x; if (cond) { x = 1; } else { x = 2; } // here x is definitely assigned AND was assigned exactly once on each path — OK System.out.println(x); ``` Each path assigns `x` exactly once, so DU holds at each assignment and DA holds at the read. This is why blank finals are powerful: the value can depend on logic. ```java final int x; x = 1; x = 2; // ERROR: x might already have been assigned (DU fails) ``` ## Blank final FIELDS For **instance** blank final fields, the rule is: the field must be definitely assigned **at the end of every constructor** that does not redirect to another `this(...)` constructor (and may instead be assigned in an instance initializer block). It must be definitely unassigned before each such assignment. ```java class C { private final int id; // blank final field C(boolean special) { if (special) id = 1; else id = 2; // every constructor path assigns id exactly once — OK } } ``` For **static** blank final fields, the field must be definitely assigned by the end of the **static initialization** of the class (static initializer blocks / inline assignment). ## Effectively final and lambdas A related concept: a local that is **never reassigned** is *effectively final* even without the keyword. Lambdas and anonymous/inner classes may capture only final or effectively-final locals. The compiler determines "effectively final" with the same single-assignment flow reasoning, so understanding DA/DU directly explains why a captured variable you reassign elsewhere causes "local variables referenced from a lambda must be final or effectively final." ## Why two analyses instead of one DA alone guarantees *initialized before use*; DU alone guarantees *not-yet-assigned*. `final` needs **both**: assigned before read **and** assigned at most once. Splitting them lets the compiler give precise, separate diagnostics ("might not have been initialized" vs. "might already have been assigned") and lets blank finals be assigned conditionally as long as exactly-once holds on every path. ## Common pitfalls - Assigning a blank final in only some branches → DA fails at later read. - Assigning a blank final in a loop body → DU fails, because a second iteration could assign it again. - Forgetting that a constructor that delegates via `this(...)` must NOT also assign the final (the delegated-to constructor already did, so DU would fail).