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

Re:Looks really kewl.

[addaon]

Why don't you just write the exception

} catch(IOException x) {
assert(false);
}

I'm sure that would make the error go away.

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.

Re:Been there, done that

[YetAnotherAnonymousC]

IIRC, Oracle also has a tool like this. I think it is called "Code Coach"

Re:Looks really kewl.

[splattertrousers]

True, it might be a bug in the analysis, but checking for nulls is not a great practice. Try using the "null object" pattern. Mark Grand describes it thusly:

The Null Object pattern provides an alternative to using null to indicate the absence of an object to delegate an operation to. Using null to indicate the absence of such an object requires a test for null before each call to the other object's methods. Instead of using null, the Null Object pattern uses a reference to an object that doesn't do anything.

The null instance of whatever class your labels variable is could do the locale stuff. (Or maybe it wouldn't work in your case; it's hard to say without the context.)

Re:The real value

[Dr. Bent]

You obviously have not used _this_ tool on anything.

I was easily able to it up and running to test a 1000 class project that I've been working on for about two years now. It took all of 5 minutes from the time I read the article on slashdot to the point where I was fixing bugs that I had missed in two years of constant debugging, testing and refactoring. No scripts, no regular expressions, just point at the .jar and go.

Now, granted, they were some fairly simplistic bugs, and it's questionable whether or not they would have ever floated to the surface as an actual bug report. But they would still be in the code now if it wasn't for this tool.

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.