Finding Bugs Is Easy

daveho writes "My advisor and I are working on a tool to automatically find bugs in Java programs. One of the interesting results of our work is that we've found hundreds of real bugs in production code using extremely simple techniques. We believe that automated tools, if used more widely, could prevent a lot of bugs from making it in to production systems."

Comments

Looks really kewl.

[DeadSea]

I just downloaded this and started playing around with it on my Java utilities.

At first I was frustrated that it needs a jar file. On my hard drive my code is just sitting in directories. So I made a jar file out of my code just for this program.

Then I was frustrated that the GUI wouldn't show me the source, but then I realized that I had compiled without debugging information in my classes (no line numbers and such). I recompiled and remade the jar file and it started showing me the source.

Most of the errors that it finds in my stuff aren't really errors. I get a lot of complaint about "should be declared package" when package is the default and I don't specify a modifier. I also get errors about ignored exceptions for things like this:
} catch (IOException x){
// This can't happen.
// The input and output streams were constructed
// on memory structures that don't actually use IO.
}

I think it may have found a few bugs though. Its complaining about at least one thing not being threadsafe. Also complaining about an inner class being static when it probably shouldn't be.

Now I want an Ant task for this so that I can make sure it runs on my code every time I compile. It is sort of like extended compiler warnings. Pretty helpful.

Bugs in Java code? Inconceivable!

[wowbagger]

Bugs in Java code? Inconceivable!

I thought it was impossible to write bugs in Java - nature's most perfect language! After all, all the Java bigo^H^H^H^Hzealot^H^H^H^H^H^Hexperts have always said that all software problems would vanish if we would just use their perfect language.

(/me removes tongue from cheek)

I just hope that the myriad and varied Java bigots out there will take this to heed: No language can prevent you from making mistakes.

(NOTE: I most emphatically do NOT assert that a language cannot make certain classes of errors more difficult to make!)

(NOTE 2: I also do not assert that all people who use Java, or promote the use of Java are bigots.)

There is no substitute for experience, careful design, and methodical testing.

Reading UGH

[Henry V .009]

I'm reading the UNIX haters guide that got posted recently, and I just wanted to post this:

There are two schools of debugging thought. One is the "debugger as physician" school, which was popularized in early ITS and Lisp systems. In these environments, the debugger is always present in the running program and when the program crashes, the debugger/physician can diagnose the problem and make the program well again.

Unix follows the older "debugging as autopsy" model. In Unix, a broken program dies, leaving a core file, that is like a dead body in more ways than one. A Unix debugger then comes along and determines the cause of death. Interestingly enough, Unix programs tend to die from curable diseases, accidents, and negligence, just as people do.

The obvious solution...

[Lendrick]

Please note that FindBugs is alpha-quality software. You may find bugs in it, and the features and source code may change significantly in future releases.

...is to run it on itself.

Re:...and?

[michaelggreer]

Javac and Jikes will tell you where it can't compile. This is higher level stuff like "such-and-such should be final" and "you have implemented equals but not hashcode." Code will run, and probably run fine, with these, but they may lead to subtle bugs difficult to track down. Compile-time or formatting bugs are easy to find. Bugs that express themselves in non-obvious ways are what we need more tools for.

In answer to another post, of course good design and good coding are best. This tool does not seek to replace thought, but push us towards proper coding

FindBugs?

[Copperhead]

What kind of name is "FindBugs"? What self-respecting Open Source project would ever name itself after what it actually does? That's so wrong!

They need to pick a name like "||gazm", "JizMop", or "Mozilla" like all the other cool OS projects. I'm sure they'll learn their lesson soon.

Re:FindBugs?

[pmz]

"||gazm"

What a perfect name for a logic-based language or boolean calculator!

Been there, done that

[Tal Cohen]

While working in IBM Research, we were developing a tool to do just that; I do believe it was significantly richer than this one. The first versions were aimed specifically at J2EE, and searched for really 'high-level' bugs -- anything from bad patterns to violations of the J2EE spec. The initial results of this effort are already included in WebSphere Studio Application Developer 5.0, as part of the Verifiers. More powerful versions will appear in future releases of WSAD.

Jlint

[mmynsted]

OK.

Why not contribute to the existing, GPL, OpenSource, Java Lint? Why start a new project?

http://artho.com/jlint/

--MM

Initial values of variables

[fforw]

Even though Java is *supposed* to initialize to null, there is no real guarantee that this will actually happen.

wrong. The JavaTM Virtual Machine Specification - Second Edition says the following :

2.5.1 Initial Values of Variables

Every variable in a program must have a value before it is used:

• Each class variable, instance variable, and array component is initialized with a default value when it is created:
• For type byte, the default value is zero, that is, the value of (byte)0.
• For type short, the default value is zero, that is, the value of (short)0.
• For type int, the default value is zero, that is, 0.
• For type long, the default value is zero, that is, 0L.
• For type float, the default value is positive zero, that is, 0.0f.
• For type double, the default value is positive zero, that is, 0.0.
• For type char, the default value is the null character, that is, '\u0000'.
• For type boolean, the default value is false.
• For all reference types (2.4.6), the default value is null (2.3).
• Each method parameter (2.5) is initialized to the corresponding argument value provided by the invoker of the method.
• Each constructor parameter (2.5) is initialized to the corresponding argument value provided by an object creation expression or explicit constructor invocation.
• An exception-handler parameter (2.16.2) is initialized to the thrown object representing the exception (2.16.3).
• A local variable must be explicitly given a value, by either initialization or assignment, before it is used.