In the course of developing for the Coconut project (the software project I do on the side), occasionally an intermittent bug that isn’t reproducible shows up. This sets off concurrency warning bells. Doing a visual inspection for concurrency issues is one option, but not very appealing. Other than the continuous burden of review cycles for the lifetime of the project and the danger of missing something, the problem also seems like a well defined, regular task that programs are meant for.
I tried out Lint4j and Jlint, but they weren’t quite what I was looking for. They seem to focus on problems that affect a small scope (e.g. bad programming stye, stupid mistakes, and concurrency problems that are tipped off by the use of the synchronized keyword) rather than the large scale cross-system check I was hoping for.
I also tried out Java Pathfinder, software written by NASA and subsequently released as open source. The examples I read regarded concurrency problems, and the product itself was described as an entire VM that simulates all possible states. I was excited to try this one out and had high hopes. Alas, pointing this product at my main() threw an immediate exception (an invalid constant while calling a createInstruction(), IIRC). The examples included in the package seemed fairly tame in basic concept, too, although some were quite lengthy. It only went open in 2005, so given some time it’ll mature, or at least I’ll be able to usefully search about my problems.
I guess I’m asking for too much: a program to verify that my servlet app is thread-safe, despite any number of HTTP requests and interleaving of operations. Combined with the number of library dependencies being used, it’s not surprising that the tools are either too narrow in scope or have problem with some unexpected condition.
I’ll still look at integrating these tools, as well as some software metric calculations. They’re quite valuable, though it would have been better to involve the checks earlier in the project rather than getting a whole bunch of problems/warnings by putting it in now. For now, however, I’ll have to go with runtime verification the old fashioned way, using HttpUnit and lots of threads.
I did encounter this paper on static code checking, though. I’ll have to read that in more depth later.
