First Look: FindBugs 2.0
First Look: FindBugs 2.0
Join the DZone community and get the full member experience.Join For Free
Get the Edge with a Professional Java IDE. 30-day free trial.
I have used FindBugs for years. Unfortunately, I have never really gotten into a kind of daily habit of using it. I thought of it again when Xcode 4 dropped and I started using its 'Analyze,' which, frankly, is what an analysis tool should be. No surprise that a decade in, eclipse really doesn‘t have any serious analysis that is neatly integrated into its vision of what writing code ought consist of. How to account for this? I mean, probably the most lauded and respected book about Java is Bloch‘s, which is, like Meyer‘s (its namesake), a kind of compendium, or model house of static analysis. Maybe that‘s confusing. What I am saying is Bloch walks you through all the different examples his book consists of, an analysis tool waits for you to run into them in your own ill-advised attempt to produce the code, then performs an in situ intervention. As great as Bloch is, People, we could really use some battlefield triage. Sadly, FindBugs advances the dream, the promise, even the conceptual heft of that noble mission, but not the reality.
Probably the most compelling reason to go look again was word that 2.0 attempts to face the devil of the last two dominant languages: illegal dereferences (amok pointers in C++ and NPEs in Java: metrics studies showed about equal defect densities for these, and they were top of the list of sources). If you think about it, it makes a lot of sense. The most useful part of the Analyze tool in Xcode was that it could show you where you were missing releases. (Then, the ridiculously rapidly moving Xcode/Cocoa team made that moot by dropping ARC in the next release.) I do think that being warned that you might be hanging an NPE is a very useful goal to pursue, and in many cases, is not that crazy complicated. Ironically, as soon as I installed the eclipse plugin, I ran it on one of my most recent projects and it found only one issue, a very valid way an NPE could occur. I was excited. I thought ‘wow, this is a new day in computing..‘ Then, I tried to push further into the forest, and the usual open sores calamities ensued: the trike tipped over and its wheels spun, squeaking, leaving no way to get to the center of the maze.
The eclipse plugin, for some nutty reason, very rapidly gets confused and while you can keep running FIndBugs on different projects/packages/classes, it stops updating the context that you can then examine in the FindBugs perspective. I must have batted around this 2 watt bulb for 40 minutes before deciding ‘ok, it would really be a better use of my time right now to try to teach my cat Portuguese..‘
Meanwhile, I upgraded Jenkins, pulled the latest version of all my plugins (how hilarious is it that I use something like 10x more plugins on Jenkins than I do on eclipse?), and then ran Sonar on one of my projects. I love Sonar. It‘s really useful. But it ran an old version of FindBugs I did end up spending a few hours rectifying the items it found. Mostly they were things like assigning parameters and some things about strings and statics. But one of the items that it brought up was it told me to use the interface for LinkedList rather than the class. I thought this was interesting, and changed it out for Deque, but that spat up an error. Because LinkedList actually masquerades as several things so there is no one interface (like there is with List and Map and Set), I though ‘well, maybe this is not going to work‘ and did some searching. Found a thread of this exact case where Ernest Friedman-Hill chimes in to say this is a bad suggestion, and this is one of the reasons static tools are not very useful. I was thinking that I agreed. That this is really the reason that these tools are still not mainstream yet. If you are going to make a tool that flags things, you absolutely must make some way to filter some of its suggestions, or mute them altogether (even with those in eclipse, almost every single dev I have worked with in the last 5+ years regards the validation tools completely useless). But then, a funny thing happened. I read the JavaDoc and thought ‘wait, Deque has to be good enough for what I am doing.‘ I put it back into my code and went back to the error. Turns out I was doing an .add(item, 0). I laughed when I saw it. Went to the add and hit CTRL-Space and picked addFirst(item) [actually cleaner].
It is a puzzle why static analysis has not really made it to mainstream, constant use. I find that though most people laud the Bloch book, like the Gang of Four book, if you ask them about it, few know much of what it says [and hence, cannot claim to have it handy in their minds as they go about their work]. Isn‘t that the conceptual locus of the Alexandrian Universe? Like the Roman Farmer of the late Empire, we have an ideal that almost no one really represents and frankly, most people don‘t practice in any form. Where this whole thing may flip over is with more things like ARC: where the analysis tools start to supplant the Magoo-assistance mechanisms. The tools will look at your code and write some of the code for you, rather than providing huge amounts of code to attempt to finish it or fix it up at runtime [e.g. GC in the VM].
I still hold out hope for FindBugs 2.0 as an active stalker of NPEs, just wonder how long it will take before its bugs get out of the way.
Opinions expressed by DZone contributors are their own.