FindBugs
 
Docs and Info
FindBugs 2.0
Demo and data
Users and supporters
FindBugs blog
Fact sheet
Manual
Manual(ja/日本語)
FAQ
Bug descriptions
Mailing lists
Documents and Publications
Links
 
Downloads
 
FindBugs Swag
 
Development
Open bugs
Reporting bugs
Contributing
Dev team
API [no frames]
Change log
SF project page
Browse source
Latest code changes

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)
The solution is to upgrade to JRE 1.5.0 or later.

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)
        ...
or 
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.

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 older 3.x versions of Eclipse. Please use Eclipse version 3.6 (June 2010) 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

Make sure the Java code you trying to analyze is built properly and has no classpath or compile errors.

Make sure the project and workspace FindBugs settings are valid - in doubt, revert them to defaults.

Make sure the Error log view does not show errors.

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?

We recommend SQE: Software Quality Environment which bundles FindBugs, PMD and CheckStyle. Use the following update site: http://deadlock.netbeans.org/hudson/job/sqe/lastStableBuild/artifact/build/full-sqe-updatecenter/updates.xml

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

Send comments to findbugs@cs.umd.edu

SourceForge.net Logo