Finding Bugs with FindBugs

FindBugs is a static analysis tool developed and maintained by the University of Maryland. The tool can find bugs in Java code, and present a listing of issues detected to developers. The project maintains a list of bug patterns they detect when performing an analysis of a code base here.  

As an experiment to begin learning about FindBugs, I ran the tool against a recent build of Apache Felix Karaf. In figure 1 you can see the listing of issues flagged.

Figure 1: FindBugs analysis screen.

Reviewing the flagged issues, not all of them are bugs but suggestions on performance or alternative implementation practice. The remainder of issues are actual problems, luckily many of these can often be remedied in a few minutes. One such issue was a minor file descriptor leak discovered in Karaf's Main class. Resolving the issue only required closing an IO stream after use. After modifying the code, and testing to ensure nothing accidentally broke, I re-ran FindBugs; the issue list was reduced by one :) Having made a small improvement to the code base I took the time to open a minor issue under Felix Karaf issue tracker and submitted a patch. 

Using tools such as FindBugs is only one part of the process of developing software, many issues will not be caught with out proper unit and system testing, and feed back from users in the field. As a second set of eyes to help catch programming omissions and in maintaining good coding practices I feel that the time spent with FindBugs is well worth the effort.

Getting to know VisualVM

Recently I had to refactor a feature that I had introduced to the old Servicemix Kernel, now Felix Karaf project. The issue was relatively minor to resolve, however testing it would require profiling memory and CPU usage over a period of time (to avoid an eventual out of memory error).

There are multiple tools out there that would allow me to do this sort of monitoring, for this particular task I chose to try out VisualVM as it was already bundled with my JDK 1.6 install. VisualVM is a visual tool that integrates several commandline JDK tools and lightweight profiling capabilities for the Java SE platform.

To begin my refactoring task I first setup Karaf with the configuration required to reproduce the out of memory condition. No special configuration or instrumentation of Karaf itself was required for using the profiler. Starting Karaf, using JDK 1.6, I was able to attach to the running process via the VisualVM interface. Once connected to the process I could view the live heap usage, threading, permgen, and loaded classes, further I could inspect the parameters fed to the JVM at start up to confirm the environment was as I configured. To view memory and CPU usage of Karaf, I selected the profiler display tab. Adjusting the profiler settings to only monitor org.apache.felix classes, I could quickly identify the offending set of method calls that contained the source of my error (high CPU usage, and multiple instances accumulating in memory).

VisualVM displaying monitor view of Felix Karaf

Resolving the error didn't require much work except to ensure a few resources were being properly freed, and removal of an unneeded for-loop. To test out my modifications I redeployed Karaf, and began reviewing its run time characteristics via VisualVM. This time the trouble methods were not being called as often, and not creating memory leaks, while still providing the same functionality the original code was intended to provide.

As a simple profiler I can recommend VisualVM as a quick, convenient way to observe your Java applications. It will be interesting to see what features they integrate into the tool in future releases.