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 I'm getting java.lang.UnsupportedClassVersionError when I try to run FindBugs When I click the "Find Bugs!" button, I get a NoSuchMethodError or VerifyError FindBugs is running out of memory, or is taking a long time to finish What is the "auxiliary classpath"? Why should I specify it? The Eclipse plugin doesn't load I'm getting a lot of false "OS" and "ODR" warnings The Eclipse plugin loads, but doesn't work correctly Where is the Maven plugin for FindBugs? 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 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: Make sure the "FindBugs Problem" checkbox is enabled. ## 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.xmla> 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