FindBugs FAQ

This document contains answers to frequently asked questions about FindBugs.  If you just want general information about FindBugs, have a look at the fact sheet and the manual.

Contents

1. I'm getting java.lang.UnsupportedClassVersionError when I try to run FindBugs
2. When I click the "Find Bugs!" button, I get a NoSuchMethodError or VerifyError
3. FindBugs is running out of memory, or is taking a long time to finish
4. What is the "auxiliary classpath"? Why should I specify it?
5. The Eclipse plugin doesn't load
6. I'm getting a lot of false "OS" and "ODR" warnings
7. The Eclipse plugin loads, but doesn't work correctly
8. Where is the Maven plugin for FindBugs?
9. Where is the NetBeans plugin for FindBugs?

Q1: I'm getting java.lang.UnsupportedClassVersionError when I try to run FindBugs

FindBugs requires JRE 1.5.0 or later to run.  If you use an earlier version, you will see an exception error message similar to the following:

Exception in thread "main" java.lang.UnsupportedClassVersionError:
edu/umd/cs/findbugs/gui/FindBugsFrame (Unsupported major.minor version 48.0)

Q2: When I click the "Find Bugs!" button, I get a NoSuchMethodError or VerifyError

The symptom of this bug is that when you start the FindBugs analysis, you see an exception similar to the following:

java.lang.NoSuchMethodError: org.apache.bcel.Repository.setRepository(Lorg/apache/bcel/util/Repository;)V
        at edu.umd.cs.findbugs.FindBugs.clearRepository(FindBugs.java:483)
        ...

java.lang.VerifyError: Cannot inherit from final class
	at java.lang.ClassLoader.defineClass0(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:537)
	...

The problem here is that the wrong version of the Apache BCEL library is being found.  FindBugs requires its own version of BCEL, which normally will be used automatically when you invoke the findbugs or findbugs.bat scripts used to launch FindBugs.  If an old version of BCEL is installed in a location, such as "lib/endorsed" in the JRE installation, where it overrides classes on the application classpath, FindBugs will not execute properly.  We know of several reasons this could happen

• If you install the Java(TM) Web Services Developer Pack 1.2 in the lib/endorsed directory of your Java Runtime Environment (JRE).  The file xsltc.jar contains an old version of BCEL that is incompatible with FindBugs. 
• Another possibility is that you are using the IBM JDK.  Some versions include a version of BCEL which conflicts with the one required by FindBugs.  This problem is fixed in version 1.4.1 SP1, so upgrading your JDK should allow FindBugs to run correctly.
• Some versions of the Apache Xalan XSLT processor include an old version of BCEL in xalan.jar.

In all of these cases, you should be able to run FindBugs by either removing the offending version of BCEL from your JRE, or installing a clean JRE or JDK and using that to run FindBugs.

Many thanks to Peter Meulmeester, Michael Levi, and Thomas Klaeger for providing information on this problem.

Q3: FindBugs is running out of memory, or is taking a long time to finish

In general, FindBugs requires lots of memory and a relatively fast CPU. For large applications, 512M or more of heap space may be required. By default, FindBugs allocates 256M of heap space. You can increase this using the -maxHeap n option, where n is the number of megabytes of heap space to allocate.

If you are using the GUI version of FindBugs, and have many classes to analyze, a good amount of memory is needed to generate the summary report. If the process appears to be hanging after all classes have been parsed, but before the final details have been shown, you can turn this summary report off, by specifying
-jvmArgs "-Dfindbugs.noSummary=true"
on the command line.

Version 0.6.9 of FindBugs introduced new types of analysis that improve precision, but require more memory and time to perform. In version 0.7.0 and later, you can disable these analyses by adding the -conserveSpace option to the FindBugs command line. E.g.:

   findbugs -textui -conserveSpace -xml -project myProject.fb -outputFile out.xml

Q4: What is the "auxiliary classpath"? Why should I specify it?

Many important facts about a Java class require information about the classes that it references.  For example:

• What other classes and interfaces the class inherits from
• What exceptions can be thrown by methods in external classes and interfaces

The "auxiliary classpath" is a list of Jar files, directories, and class files containing classes that are used by the code you want FindBugs to analyze, but should not themselves be analyzed by FindBugs.

If FindBugs doesn't have complete information about referenced classes, it will not be able to produce results that are as accurate as possible.  For example, having a complete repository of referenced classes allows FindBugs to prune control flow information so it can concentrate on paths through methods that are most likely to be feasible at runtime.  Also, some bug detectors (such as the suspicious reference comparison detector) rely on being able to perform type inference, which requires complete type hierarchy information.

For these reasons, we strongly recommend that you completely specify the auxiliary classpath when you run FindBugs.  You can do this by using the -auxclasspath command line option, or the "Classpath entries" list in the GUI project editor dialog.

If FindBugs cannot find a class referenced by your application, it will print out a message when the analysis completes, specifying the classes that were missing.  You should modify the auxiliary classpath to specify how to find the missing classes, and then run FindBugs again.

Q5: The Eclipse plugin doesn't load

The symptom of this problem is that Eclipse fails to load the FindBugs UI plugin with the message:

Plug-in "edu.umd.cs.findbugs.plugin.eclipse" was disabled due to missing or disabled prerequisite plug-in "org.eclipse.ui.ide"

The reason for this problem is that the Eclipse plugin distributed with FindBugs does not work with 2.x versions of Eclipse. Please use Eclipse version 3.3 (June 2007) or newer.

Q6: I'm getting a lot of false "OS" and "ODR" warnings

By default, FindBugs assumes that any method invocation can throw an unchecked runtime exception.  As a result, it may assume that an unchecked exception thrown out of the method could bypass a call to a close() method for a stream or database resource.

You can use the -workHard command line argument or the findbugs.workHard boolean analysis property to make FindBugs work harder to prune unlikely exception edges.  This generally reduces the number of false warnings, at the expense of slowing down the analysis.

Q7: The Eclipse plugin loads, but doesn't work correctly

In versions 0.0.6 and 0.0.7 of the FindBugs Eclipse plugin, which correspond to the 0.7.4 and 0.8.0 releases, bugs in the experimental SwitchFallthrough detector can prevent FindBugs from running properly within Eclipse.

To work around the problem, make sure that SwitchFallthrough is disabled in the FindBugs Properties of your project.  Right click on your project, and choose "Properties".  In the Properties dialog, choose "FindBugs", and disable the checkbox next to SwitchFallthrough.

Another common problem with the Eclipse plugin is that the FindBugs warnings do not appear in the "Problems" view.  Make sure that FindBugs warnings are enabled in the filters for this view.  The Filters menu is accessible by clicking on the icon that looks like this:

Q8: Where is the Maven plugin for FindBugs?

The Maven Plugin for FindBugs may be found here.  Please note that the Maven plugin is not maintained by the FindBugs developers, so we can't answer questions about it.

Q9: Where is the NetBeans plugin for FindBugs?

The NetBeans Plugin for FindBugs may be obtained by pointing UpdateCenter to https://sqe.dev.java.net/updatecenters/nbheaven-updatecenter.xml. (An older human-readable page is here.) This distribution apparently bundles the detectors from fb-contrib, which are not controlled by the FindBugs project. The lead FindBugs team does not vouch for the relevance, accuracy or wisdom of the warnings generated by any third-party plugin. and encourages all FindBugs users to carefully evaluate 3rd party plugins for FindBugs.

Again, please note that the NetBeans plugin is not maintained by the FindBugs developers, so we can't answer questions about it.

Send comments to findbugs@cs.umd.edu