+1 to Eric fixing all/most of these items! I believe you are now a committer, right?
Welcome aboard (and thanks for running this tool)! -- Tom Jordahl -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 1:22 PM To: [EMAIL PROTECTED] Subject: static analysis of axis.jar with "findbugs" utility I ran the "findbugs" static analysis utility against a copy of axis.jar. I'm attaching the resulting report, which was created with the "textui" in "sort by class" mode. It looks like there are several things that could be trivially fixed and several others which merit further investigation. Findbugs comes with an ant task and so if there's consensus about the usefulness of this report, it might make sense to add a target to the axis build file so that this can be run from time to time. Findbugs, if you don't already know, was created by David Hovemeyer and Bill Pugh (of skip list fame). The original paper describing the tool and its goals is available here: http://www.cs.umd.edu/~pugh/java/bugs/docs/findbugsPaper.pdf. The site for findbugs is here: http://www.cs.umd.edu/~pugh/java/bugs/ And here's a report for axis. I recommend trying it out yourselves with the GUI -- that includes slightly more verbose descriptions of the patterns that findbugs considers to be problematic. Eric PS -- I'd be most concerned about the classes that have problems with the equals/hashCode contract, as those can result in serious and difficult to reproduce runtime failures. Also, there are places where Axis is using the "double checked locking" idiom for lazy initialization -- this is known to not work in Java and should be fixed as soon as possible. See http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html for information about why this is so. Apart from that, it's up to the committers (of which I am not one) to decide what other errors are worth fixing. The several unread/unused instance variables are probably easy, low-hanging fruit.... <<byClass.txt>>
