The strange ways of compile time constants

[Steli Niculescu]

This, obviously, does not compile.

public void a (boolean b) {
int x;
if(b) x = 1;
x++;
}

This compiles:

public void a (boolean b) {
int x;
if(true) x = 1;
x++;
}

This, not so obviously, does not compile :

int x=  0;
try {
throw new RuntimeException();
x++ ;
} catch (Exception e) {}

This DOES COMPILE :

int x=  0;
try {
if(true) throw new RuntimeException();
x++ ;
} catch (Exception e) {}

Why ??!

[Seetharaman Venkatasamy]

public void a (boolean b) {
int x;
if(b) x = 1;
x++;
}

there is a possibility to b can be false, so local variable x could not be initialize before it get use.

public void a (boolean b) {
int x;
if(true) x = 1;
x++;
}

compiler make sure that x will get initialize here. so no error.

int x=  0;
try {
throw new RuntimeException();
x++ ;
} catch (Exception e) {}

here after the exception, code cannot be reached.hence error.

int x=  0;
try {
if(true) throw new RuntimeException();
x++ ;
} catch (Exception e) {}

[I am not sure]I think this is because of java compiler(javac) dont have pre-processor

[Steli Niculescu]

Yes, I'm not sure either, actually my question was only for the last code sample.
I thought the compiler is sure that the exception will be thrown and the last statement will be unreachable, but it seems that's not true.

[Lester Burnham]

It may be easy for a human being to spot that the last two code examples are identical, but it's not so easy for a compiler. You could make its analysis of which code will definitely be executed (or which won't) as complex as you want, and it will still miss opportunities for proving that some code can't be reached. It has to draw the line somewhere, and that line seems to be trying to prove the constant-ness of "if" condition values.

[Wouter Oet]

The compiler allows this to build code like this:

if(Debug.enabled) {
   Log.info("lalala");
}    

It would be very annoying to get unreachable statement errors if Debug.enabled is set to false.