Take the following Java code snippet:
.... else if (true){ //hard-coded as true ///launch methodA } else { ///launch methodA (same code as in the ` else if ` statement) } ....
What I was wondering is how the compiler deals with this. Wouldn't it be logical for the compiler to remove the else if(true)
statement altogether in order to not have to perform a check, even though it is hard-coded as true. Specifically in Eclipse, how is the code above interpreted?
Or what about in the following scenario:
.... else if (true){ //hard-coded as true ///launch methodA } else { ///launch methodBB } ....
Wouldn't it be logical in this case for the compiler to remove the else
statement? Because while running, the else
statement is unreachable.
In general, "else if" style can be faster because in the series of ifs, every condition is checked one after the other; in an "else if" chain, once one condition is matched, the rest are bypassed.
Use two if statements if both if statement conditions could be true at the same time. In this example, both conditions can be true. You can pass and do great at the same time. Use an if/else statement if the two conditions are mutually exclusive meaning if one condition is true the other condition must be false.
A condition still returns a Boolean output. An “else if” block leads to a further level of nesting. In case the “if” condition is false, then the “else if” condition is evaluated in a sequential manner till a match is found. In case all conditions fail, then the action defined in the “else” clause is executed.
The if-else statement is used to execute both the true part and the false part of a given condition. If the condition is true, the if block code is executed and if the condition is false, the else block code is executed.
Unreachable statements are forbidden in Java and must trigger compilation errors. The JLS defines what is an unreachable statements: https://docs.oracle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.21
It is too long to be entirely quoted here, but here is an extract (emphasis mine):
if (false) { x=3; }
does not result in a compile-time error. An optimizing compiler may realize that the statement x=3; will never be executed and may choose to omit the code for that statement from the generated class file, but the statement x=3; is not regarded as "unreachable" in the technical sense specified here.
The rationale for this differing treatment is to allow programmers to define "flag variables" such as:
static final boolean DEBUG = false;
and then write code such as:
if (DEBUG) { x=3; }
The idea is that it should be possible to change the value of DEBUG from false to true or from true to false and then compile the code correctly with no other changes to the program text.
So the answer will depend on the compiler you use and its optimization options.
The compiler optmizes it at compile time:
public class Test { public static void main(String[] args) { if(true) { System.out.println("Hello"); } else { System.out.println("Boom"); } }
Gives me (with my Java 1.8.0_45
):
Compiled from "Test.java" public class Test { publicTest(); Code: 0: aload_0 1: invokespecial #1 // Method java/lang/Object."<init>":()V 4: return public static void main(java.lang.String[]); Code: 0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream; 3: ldc #3 // String Hello 5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 8: return }
The code just prints Hello
. Boom
is not even considered.
All recent Java compilers eliminate dead code at compile time.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With