Exploring Coverage Analysis Views > Learning More About Coverage Results >  Nonintuitive Results for Conditions  

Nonintuitive Results for Conditions

Compilation of Java source to bytecode may not always be as one might expect. Compilers may rearrange conditions, omit ones that are unnecessary, or add ones not obvious in the source, subject to some constraints by the Java language. They often invert conditions so that a condition you expected to be reported as having been found true but not false, may be reported by JProbe as false but not true.

For example, the following source code:

if (s == null) {
    a();
} else {
    b();
}

May result in bytecode similar to:

    aload s
    ifnonnull skip
    invokevirtual a()
    goto end
skip:
    invokevirtual b()
end:

So while the source is true if s is null, the ifnonnull opcode is true if s is *not* null. JProbe cannot change how the compiler treats conditions. For more information, see A Closer Look at the Data in the Condition Detail Table.

The following table lists some other common nonintuitive results where conditions are added or completely removed:

 

Source Code

Explanation of Compiler Behavior

assert

Most compilers add one hidden condition to the line for the assert, which in turn adds two more possible outcomes to the total outcomes on the line.

class

The source construct <classname>.class is sometimes compiled into code that calls Class.forName(<classname>). To avoid repeated calls, the compiler generates code to check a hidden field to see if it has already saved the result of forName(). If it has not, it calls forName() and saves the result. Otherwise, it just uses the saved result. JProbe may include this check in its total possible condition outcomes.

debug

Some compilers may remove debug conditions. For example, the following source code may not appear in the bytecode:

private static final boolean debug = false;
...
if(debug) System.out.println("Debug");