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.

Jlint

[mmynsted]

OK.

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

http://artho.com/jlint/

--MM