Running Flow Analysis
To better understand the types of defects that flow analysis can expose, consider how it can be applied to two sample Java classes. For our purposes, flow analysis will be done with the BugDetective technology featured in Parasoft Jtest.

One sample class involves a class instance field that can be null (Listing 1 - TestFields class) and the second one involves the same class with a local variable that can be null (Listing 2 - TestLocal class). Both classes call a LocalHelper class. The goal is to demonstrate how flow analysis handles (1) intra-procedural calls, and (2) inter-procedural calls (a) within one class and (b) that cross class boundaries.

Both of the examples (see below) contain instance field and local variable variations of the same defects. The methods named "falsePositive" contain false positives and the methods named "truePositive" contain true positives.

To do the flow analysis, I selected the two sample classes in my IDE (Eclipse) then ran a "BugDetective" Test Configuration. This flow analysis flagged the following defects in the two files (see Table 1).

All false positives are marked in blue and all true positives are marked in red. X indicates that a flow analysis violation wasn't reported in the method and indicates that a flow analysis violation was reported in that method.

Taking a closer look at the results, notice that no false positives were flagged in these examples. Also notice that Jtest's flow analysis found the defects in the truePositive3 method to be false positives even though other technologies may report them as true errors.

Consider the following code from the TestFields class:

Object x; //NPE origin
TestFields(Object x) {
     this.x = x;
}

int truePositive3(boolean b) {
     Object y = null;
         if (x != null)
             y = new Object();
         if (y != null)
             return x.hashCode() + y.hashCode();
         else
             return x.hashCode(); //NPE
}

The instance variable x is initially initialized to null, but it gets reassigned to the value of argument x in the constructor call.

This violation wasn't flagged during flow analysis because when simulating execution paths through the code, the flow analysis technology saw a potential violation point on the path (the line marked with //NPE) but it didn't see a path from the violation origin statement (the line marked with //NPE origin) to that line without going through a constructor. This wasn't reported as a violation because the flow analysis didn't find a line where x is initialized to null. The code didn't find a path in the source code that contains the following sequence of steps:

TestFields tf = new TestFields();
tf.truePositive3(true|false);

Nor did it find a path such as this:

TestFields tf = new TestFields(null);
tf.truePositive3(true|false);

However, assume that the following method is added to the TestFields class:

void callerTruePositive3() {
       TestFields tf = new TestFields(null);
tf.truePositive3(true);

}

Flow analysis now flags this violation since it sees the violation origin and violation point, as well as a code path that leads from one to the other.

Conclusion
Flow analysis helps software development teams find critical runtime bugs without executing code. Since it tries to check whether potential problems could actually be triggered by real application paths, it reports an extremely high ratio of true positives to false positives. This means that you'll be alerted to problems that are likely to occur at runtime - but you won't need to waste time reviewing an overwhelming number of false positives. This is especially helpful if you need a fast way to zero in on critical defects in a large code base.

When flow analysis is applied as part of a comprehensive regression test suite, it helps development teams to:
• Increase team development productivity by identifying and addressing defects from the earliest phases of the development cycle - when fixing them requires minimal effort and rework.
• Achieve more with existing development resources by automatically vetting known coding issues so developers and QA can spend more time on tasks that require human intelligence.
• Build on the code base with confidence by efficiently constructing, continuously executing, and maintaining a comprehensive regression test suite that detects whether updates break existing functionality.
• Decrease time to market by building an efficient, consistent, and controlled team workflow for applying best practices that reduce testing time, testing effort, and the number of defects that reach QA.
• Reduce support costs by automatically performing negative testing on a broad range of potential user paths to uncover problems that might otherwise surface only in "real-world" usage.
• Quickly expose problems in complex, difficult-to-test systems by automatically exposing many critical bugs in software for SOA and Java EE without involving staging systems.