Community
Participate
Working Groups
The sysout is flagged as dead code if 'b' is made final, but not when 'b' is not final. ------------------------------------------------------------------------------- package p; class A { void foo() { boolean b = true; if(b) { return; } System.out.println("coming here");//dead code if 'b' is final } } -------------------------------------------------------------------------------
I think what you are seeing is the right behavior. If statements are handled in a special way to be compatible with JLS3. See http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.21 "... One might expect the if statement to be handled in the following manner, but these are not the rules that the Java programming language actually uses: ..." See that javac also does not complain here, though it does if the if is changed into while.
(In reply to comment #1) > I think what you are seeing is the right behavior. If statements are > handled in a special way to be compatible with JLS3. > See http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.21 That does apply to the "Unreachable code" warning, but I dont think it does to the dead code warning, which is jdt specific feature intended to raise warnings because of cases such as if (false) {} , that should not be flagged unreachable. This difference in behaviour between when b is final and otherwise arises because of special treatment of final variables. An optimized boolean constant is set on all final variables during resolution, so that a compiler can do optimizations during code gen. We use this boolean constant to figure out if only one branch of the if-else construct is going to be executed, and so in the given case, we conclude that the 'then' branch will always execute, leading upt a return statement. Hence, sysout is marked dead code. Incase when b is not final, this constant cant be used and compiler is not able to figure out that sysout is dead code. IMO, this behaviour is ok. In order to raise the warning for the non-final case, we will have to evaluate the value of b in if(b), but we never evaluate values of expressions in static analysis. (note that evaluating the null status and evaluating the value are different issues)
Will investigate if something can be done, time permitting
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
