Why does a Java Compiler not produce an unreachable statement error for an unreachable then statement?

JavaIf StatementUnreachable CodeUnreachable Statement

Java Problem Overview

If I try to compile


The Java compiler produces an error saying Unreachable statement. But if I add another "unreachable"(according to me) break statement and make it:

    if(false) break;

It compiles. Why does it not produce an error?

Java Solutions

Solution 1 - Java

The behaviour is defined in the JLS description of unreachable statements:

> The then-statement is reachable iff the if-then statement is reachable.

So the compiler determines that the then-statement (break;) is reachable, regardless of the condition in the if.

And a bit further, emphasis mine:

> A basic for statement can complete normally iff at least one of the following is true:

>- The for statement is reachable, there is a condition expression, and the condition expression is not a constant expression (§15.28) with value true.

  • There is a reachable break statement that exits the for statement.

So the for can complete normally because the then-statement contains a break. As you noticed, it would not work if you replaced break with return.

The rationale is explained towards the end of the section. In substance, if has a special treatment to allow constructs such as:

if(DEBUG) { ... }

where DEBUG may be a compile time constant.

Solution 2 - Java

As explained in my answer to a similar question, the specific construct if(compile-time-false) is exempt from the unreachability rules as an explicit backdoor. In this case, the compiler treats your break as reachable because of that.

Solution 3 - Java

From the JLS

> An if-then statement can complete normally if at least one of the > following is true: > > The if-then statement is reachable and the condition expression is not > a constant expression whose value is true. > > The then-statement can complete normally.

So if(false) is allowed.

> This ability to "conditionally compile" has a significant impact on, > and relationship to, binary compatibility. If a set of classes > that use such a "flag" variable are compiled and conditional code is > omitted, it does not suffice later to distribute just a new version of > the class or interface that contains the definition of the flag. A > change to the value of a flag is, therefore, not binary compatible > with pre-existing binaries . (There are other reasons for > such incompatibility as well, such as the use of constants in case > labels in switch statements;)

Solution 4 - Java

Basically, unreachable code is detected by analyzing the program statically without actually running the code. While the condition will be checked at runtime. So, when this analysis takes place it does not actually look in to the condition but just check that break; is accessible(reachable) via if.

Solution 5 - Java

The core reason Java doesn't detect all unreachable statements is that it's generally impossible to answer whether the code is reachable or not. This follows from the fact that halting problem is undecidable over Turing machines.

So, it's clear that all unreachable statements cannot be detected, but why not to try evaluating conditions? Imagine now that the condition used is not just false but something like ~x == x. For example, all these statements will print true for every int x (source).

    System.out.println((x + x & 1) == 0);
    System.out.println((x + -x & 1) == 0);
    System.out.println((-x & 1) == (x & 1));
    System.out.println(((-x ^ x) & 1) == 0);
    System.out.println((x * 0x80 & 0x56) == 0);
    System.out.println((x << 1 ^ 0x1765) != 0);

The statements can be rather complicated; it takes time to resolve them. It would significantly increase build time, and after all, it will not detect all unreachable statements. Compiler was designed to take some efforts but not spend too much time for that.

The only question remained is: where to stop resolving conditions? The reasons for that don't seem to have mathematical justification and are based on usage scenario. Rationale for your particular case is given by JLS-14.21


All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestiondryairshipView Question on Stackoverflow
Solution 1 - JavaassyliasView Answer on Stackoverflow
Solution 2 - Javachrylis -cautiouslyoptimistic-View Answer on Stackoverflow
Solution 3 - JavaMohammed Aouf ZouagView Answer on Stackoverflow
Solution 4 - JavaakashView Answer on Stackoverflow
Solution 5 - JavaSergey FedorovView Answer on Stackoverflow