Jlint
What does this program print?

class LongVal {
    public static void main(String[] s) {
        long l = 0x1l;
        System.out.format(“%x”, l);
   }
}

When you run it, it prints 1, not 11 – why? Let’s use a tool to detect the problem. The antic tool (that’s part of JLint) finds it:

$antic –java LongVal.java
LongVal.java:3:26: May be ‘l’ is used instead of ‘1’ at the end of integer constant

The programmer, possibly by mistake, typed ‘l’ (English letter l) instead of ‘1’ (number one)!

   long l = 0x1l; 

To avoid this problem, it’s best to use ‘L’ (upper case letter L) as the suffix for long constants instead of ‘l’ (lower case letter l).

Antic is part of the Jlint tool that’s meant to find problems related to C syntax. There are quite a few coding problems that are common to languages that use C-like syntax. The problem we saw now is just one such problem. Jlint ferrets out Java inconsistencies and bugs. It’s not a very sophisticated tool and if you don’t have experience using static analysis tools, JLint is a good tool to start with. Antic works on Java source files and Jlint works on Java class file builds. It’s a command-line tool and easy-to-use. It’s available at http://jlint.sourceforge.net.

FindBugs
What does this program print?

class NaNTest {
     public static void main(String[] s) {
       double d = getVal();
       if(d == Double.NaN)
            System.out.println(“d is NaN”);
       }
       private static double getVal() {
                return Double.NaN;
       }
}

You might be surprised to find that it doesn’t print anything! What went wrong? The FindBugs tool detects the problem and warns us about it (see Figure 1).

The bug is that the condition (NaN == NaN) evaluates to false! In the condition (d == Double.NaN), this code checks to see if a floating-point value is equal to the special “Not A Number” value. The IEEE 754 floating-point standard provides the special semantics of NaN: no value is equal to NaN, including NaN itself. So, the check (d == Double.NaN) always evaluates to false. The correct check to use is the condition check Double.isNaN(x).

The FindBugs tool detects this problem and aptly names it “Doomed test for equality to NaN”.

The FindBugs tool is excellent. It detects correctness problems, multithreading issues, performance problems, and bad practices. It has less false positives and warns of only critical or important problems that are likely to be actual defects in code. If you’re pressed for time and want to look at only important problems, this tool will suit you. It runs on Java class/jar files, so no Java source files are needed to use it, and it runs in a nice standalone GUI. You can download it at http://findbugs.sourceforge.net/.

PMD
What’s wrong with the program in Listing 1? If you try to run it (as shown in Figure 2) you’ll get a NullPointerException!

What could have gone wrong? PMD detects it and warns of the problem:

$ pmd Test.java text design
Test.java:3  Overridable method ‘foo’ called during object construction

The bug in this program is that the constructor of the Base class calls an overridden method. Constructors don’t support runtime polymorphism since derived objects aren’t constructed when the base class constructor executes; the virtual method foo is called from the base class constructor. Since foo is overridden, the overridden foo calls the toString method from i, which isn’t initialized yet (note that i gets initialized only after the Derived constructor has completed executing). Because of this, the program terminates with a NullPointerException. For this reason, it’s not a recommended programming practice to call overridable methods from constructors.

The PMD tool checks for problems such as possible bugs, design rule violations, duplicates, suboptimal or dead code, suggestions for migration to newer JDK versions, J2EE, JavaBeans, JSP, and JUnit rules. It works on Java source files and can be used from the command line. Plug-ins for popular IDEs like Eclipse, JBuilder, and JCreator are also available. You can download it from http://pmd.sourceforge.net/.

QJ-Pro
What’s wrong with the program in Listing 2?

It’s likely that the program will hang after running successfully for few times as shown in Figure 3; in other words, this program can lead to a “deadlocked condition” (the program actually hints at this: the name of the class is Deadlock!).

The QJ-Pro tool detects it as shown in Figure 4.

The bug in this code is that the code acquires two locks in opposite order; after that a sleep/wait method is called – this condition will usually result in a deadlock.

Locks are the basic Java synchronization mechanism. Using locks ensures exclusive ownership for a thread while executing a critical section. Incorrect use of synchronization can lead to deadlocks.

A big problem with deadlocks (as with most multithreading problems) is that deadlocks are “non-deterministic” – they need not reproduce consistently, and so it’s difficult to detect, reproduce, and fix problems related to deadlocks.

Acquiring multiple locks is prone to deadlock, particularly if not done in the same order or if the sleep()/wait() in the Thread is called after acquiring locks. In this program, foo and bar acquire locks in opposite order and call sleep(). Hence deadlock occurs.