Why is Java's reachability analysis conservative, and what kinds of obviously-dead code does it NOT reject?

## What 'conservative' means here A static analysis is **conservative** when it only reports a problem if it can *prove* it, and stays silent otherwise. Java's reachability analysis is conservative: it flags code as unreachable **only** when the JLS's reachability rules establish it with certainty. If it cannot prove unreachability, the code is considered reachable and compiles. ## Why it's only syntactic + constant-based The analysis looks at: - the **structure** of statements (what follows a `return`/`throw`/`break`/`continue`, loop shapes, etc.), and - the values of **constant expressions** (literals like `true`/`false`, `static final` constants). It does **not** evaluate ordinary runtime values. It does not track what `int x` might hold, does not simulate execution, and does not do data-flow value analysis. This is a deliberate boundary. ## Examples it does NOT reject (even though they're effectively dead) ```java int x = 5; if (x > 0) return 1; // x is non-constant to the reachability rules return 2; // 'reachable' per the rules, even if never taken ``` Here `x` is not a constant expression, so the compiler treats both branches as reachable. The `return 2` is never executed at runtime, but it is **not** an unreachable-code error. ```java boolean alwaysTrue() { return true; } if (alwaysTrue()) doA(); else doB(); // doB() considered reachable ``` The compiler doesn't know the method always returns true, so the else branch is reachable by the rules. Contrast with what it DOES reject — the structural, provable cases: ```java return 1; foo(); // ERROR (after return) while (false) { foo(); } // ERROR (constant-false loop body) while (true) {} foo(); // ERROR (after constant-true infinite loop) ``` ## Why be conservative? (the deep reason) Deciding in general whether a statement can ever execute is **undecidable** — it reduces to the **halting problem** (you'd need to know, for arbitrary code, whether execution reaches a point, which is equivalent to deciding whether programs halt). No analysis can be both correct and complete for all programs. So the language picks a **decidable, well-defined subset** of the question: a fixed set of rules over structure + constants. The benefits: - **Determinism / portability**: every conformant Java compiler computes the *same* reachability and accepts/rejects the *same* programs. A smarter, optimizer-specific analysis would make compilation results vary by compiler. - **Predictability**: developers can learn the rules and know exactly what compiles. - **No false positives that break valid programs**: being conservative means it never rejects code that *might* run. ## Reachability vs. optimization Don't confuse the *language rule* (an error) with *optimizer dead-code elimination*. The JIT or `javac` optimizer may detect that `return 2` above is never reached and remove it from the generated code — but that is an optional optimization, invisible to program semantics, and **not** a compile error. The reachability *rules* are about what the language *rejects*; optimization is about generating efficient code from accepted programs. ## Takeaway Java's reachability check is a small, decidable, spec-pinned analysis: powerful enough to catch the common structural mistakes as hard errors, deliberately limited so compilation stays deterministic and the undecidable general problem is sidestepped.