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.

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.

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

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