What Compiler can tell and can't tell

[sridhar row]

Please consider the follwoing code

  public class Fiz
{
int x = 5;
 
public static void main(String[] args)
{int x;
final Fiz f1 = new Fiz();
Fiz f2 = new Fiz();
 
Fiz f3 = Fizswitch(f1,f2);
 
if(false){ //line 1
  f1=f2;//line 2
  System.out.print("sdfdsf");
}
 
System.out.println(f1.x = f3.x);
}
 
static Fiz Fizswitch(Fiz x, Fiz y){
final Fiz z =x;
z.x =6;
return z;
}
 
}  

at line 2 i get a compiler error: cannot assign a value to final variable f1
f1=f2;
^
1 error

why cant the compiler tell that the if block will not run even with a literal value of false in the if test condition? where as in the below code it can

  public class TestLocal {
public static void main(String [] args) {
int x;
boolean b = true;
boolean c = b;
if (false) { // always false
x = 7; // 
}
int y = x;//line 1
 
System.out.print(x);
}
}  

at line1 i get compiler error : variable x might not have been initialized
int y = x;
^
1 error

In the first case compiler still able to get inside the if(false) condition but in the second case compiler not able to get inside the if(fasle) condition...can somebody explain please? thanks

[Ben Souther]

The compiler can see that that block will never be run and remove it.
This technique is sometimes used to mimick C's ifdef pre-processor directives.

It may just be that it doesn't look for these conditions until after it checks for the reassignment of finals. Just like it doesn't check for failed dependencies until after it's checked for syntax errors.
[ April 09, 2008: Message edited by: Ben Souther ]

[Jim Yingst]

The compiler most likely can tell that the conditional will never be true, but it's required by the specification to act as though it might or might not be true. This only happens in an if statement, not in a while or for loop, and it's done specifically so that the compiler will not throw an exception for something like this:

public static final boolean DEBUG = false;
 
...
 
if (DEBUG) {
    System.out.println("debug info");
}

Sun's designers want this code to compile, because it was a common C idiom, and therefore they deliberately set the rules so that it would not get an unreachable code error. Basically they did this by stipulating that in an if statement, the compiler must act as though the conditional may or may not be true - even if it's obvious that one option or the other is not possible.

[Sridhar]: In the first case compiler still able to get inside the if(false) condition but in the second case compiler not able to get inside the if(fasle) condition...can somebody explain please? thanks

In both cases, the compiler considers both (a) what happens if the condition is false, and (b) what happens if it is true. As long as code is reachable by one of those two possibilities, then it's not considered unreachable. But if there's a possibility that a variable might be used without having been assigned first, that's an error.

[Sandip Sarkar]

Hi,

The compiler doesnt make sure if the condition is true or not. Its for the JVM to decide. JAVAC is only for checks and what is possible and not.

In JAVA we have final references and not final objects. Hence you can change the value of the variable "x" but you cannot make the final fiz1 object refernce to point to any other object fiz2. Hence the compiler error. The reference fiz1 is final and can only point to the object it points. We cannot change the reference.

Thanks,
Sandy

[Jim Yingst]

[Sandip]: The compiler doesnt make sure if the condition is true or not. Its for the JVM to decide. JAVAC is only for checks and what is possible and not.

But the compiler can and does check this sort of thing in other situations:

while (false) {
    System.out.println("Hi");
}

The compiler complains about an unreachable statement here. It's only for an if statement that the compiler doesn't check the condition. The reason for this was given in my last post.
[ April 10, 2008: Message edited by: Jim Yingst ]

[sridhar row]

In both cases, the compiler considers both (a) what happens if the condition is false, and (b) what happens if it is true. As long as code is reachable by one of those two possibilities, then it's not considered unreachable.

Thanks Jim and Ben, from what i have understood from the above explanation i still have a doubt. In the below case is x = 7; still reachable? if it is reachable why not assign value 7 to variable x?

But if there's a possibility that a variable might be used without having been assigned first, that's an error.

here the variable is used without being assigned in line 1 not inside the if condition.

int x;
if (false) { // always false
x = 7; // reachable??
}
int y = x;//line 1
[ April 10, 2008: Message edited by: sridhar row ]

[Jim Yingst]

The line x = 7 is considered reachable, yes. However in this case that just means it may be reached. Since it's inside an if statement, it also may not be reached. That means the compiler considers that it's possible that the line won't run, and therefore the variable x might not be initialized. That's why it gives an error message.