I'm writing a Java program that requires thousands of System.out.println() statements that will be printed hundreds of millions (or billions) of times throughout the lifecycle of the program for debugging purposes:
if (GVar.runInDebugMode) System.out.println("Print debug message");
In the real world, these statements can be deactivated in order to speed up a computational heavy calculation.
If I set:
public final static boolean runInDebugMode = false;
Does the compiler re-evaluate runInDebugMode each time it comes across a statement like: if (GVar.runInDebugMode) or since it was declared as final it will be evaluated once at the beginning of the program and won't put additional strain on the CPU? In other words, would I be better off commenting out all debug statements entirely once I deploy the app or is setting runInDebugMode to false sufficient?
The scenario you have is described as "conditional compilation", i.e. the compiler that produces bytecode can optimize away the code if the constant variable is false:
"...in order to allow the if statement to be used conveniently for "conditional compilation" purposes, the actual rules differ.
As an example, the following statement results in a compile-time error:
while (false) { x=3; }
because the statement x=3; is not reachable; but the superficially similar case:
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."
Note the part in bold: it depends on the compiler but it's quite easy to verify with the javap disassembler, just run javap -v -l -p MyClass.class to view the resulting bytecode. I'm pretty sure the Oracle/OpenJDK javac does that optimization since long ago and so do most compilers. Note that GVar.runInDebugMode is a constant expression, so it benefits from this optimization.
"Conditional compilation comes with a caveat. If a set of classes that use a "flag" variable - or more precisely, any static constant variable (§4.12.4) - 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. The classes that use the flag will not see its new value, so their behavior may be surprising. In essence, a change to the value of a flag is binary compatible with pre-existing binaries (no LinkageError occurs) but not behaviorally compatible."
which basically says that you have to also re-compile the code that uses the flag, in addition to the class that defines it. This shouldn't be a problem if you build the whole code.