FindBugs is a program which looks for bugs in Java code. It can detect various coding "mistakes" including thread synchronization problems and misuse of API methods. It includes both Swing and command line interfaces.

The new version adds new bug detectors:

- Places where a null pointer might be dereferenced
- I/O streams that are opened, do not escape the method, and are not closed on all paths out of the method
- Methods that can return null instead of a zero-length array
- Using the == or != operators to compare String objects

Other changes in this version:

- Command line interface can save bugs as XML
- GUI can save bugs too and load bugs from XML
- An "Annotations" window in the GUI allows the user to add textual annotations to bug reports; these annotations are preserved when bugs are saved as XML
- In this release, the Japanese bug summary translations by Germano Leichsenring are really included (they were inadvertently omitted in the previous release)
- Completely rewrote the control flow graph builder, hopefully for the last time
- Simplified implementation of control flow graphs, which should reduce memory use and possibly improve performance
- Improvements to command line interface (list bug priorities, filter by priority, specify aux classpath, specify project to analyze)
- Various bug fixes and enhancements

Check out the open source FindBugs

See also: http://pmd.sourceforge.net/

It might be useful as an Eclipse plug-in. JMHO - MOD

And let us know how many did u find ..
There is no prefect bug finding mechanism in the world, although there have been a hell lot of attempts to do so. I m sure to a small extent you will be able to help developers find bugs early, but after a point you just cant.
Well if Turing machine could not do it, then how can you. Its all on best practices, combination of tools like urs, code reviews and JUnit tests we can minimize the problem. I wish u success
Happy Debugging !!!

Sean,

Doesn't it make sense to use all tools available to you? If their software can find just 10 bugs in an application, those are 10 bugs the user won't see... or bugs that won't crash your site.. or whatever they are. Any bugs you can catch are better than none.. so I hope they keep up the good work!

thats what i said at the end if u read my comments properly...
i m just telling them that its not possible to just find a bug or so by runnign a software. there are a hell lot of cases where in the bug finder will think something is a bug when it is actually not , then comes the configuration issue to configure the bug finder not to crib on some specific things etc etc etc etc .. i have used a lot of these tools and no one is good. So i m giving users point of view / a reality check to this team. And i dont think there is anything wrong in that . And i have also wished them success in my comment,. on top of that if u feel there is smething wrong with my comments- i guess there is somehting wrong with how u understand my comments. ( i guess no tool can help you on that )
Once again
Happy Debugging !!!

When discussing the merits (or lack thereof) of any method to find bugs, it is important to appreciate that no single method can find all or even most of them. Code inspections, unit testing, system testing and so forth each catch no more than 25%-50% of bugs. That's the bad news. The good news is, they all catch different bugs. You can combine a number of different approaches and deliver a system that is substantially (if never totally) bug-free.

I just ran Find Bugs over my current project. It highlighted a couple of inelegant corners and found one real bug. I ran it over another project that I'm not directly involved in, but I know we have spurious deadlock problems with, and it highlighted a dozen suspect classes that could do with closer inspection, and one problem which is definitely a threading bug.

I'm impressed. Another tool in the toolbox, another means to edge the bug catching ratio towards that magical 99.9%.

 - Peter

Hi,

I am using findbugs tool for the first time, I am not able to understand the following

  <target name="findbugs" depends="jar">
    <findbugs home="${findbugs.home}"
              output="xml"
              outputFile="bcel-fb.xml" >
      <auxClasspath path="${basedir}/lib/Regex.jar" />
      <sourcePath path="${basedir}/src/java" />
      <class location="${basedir}/bin/bcel.jar" />
    </findbugs>
  </target>

1)What is the auxClasspath tag for, is it necessary?
1.5)Why do we need a 'The early-access version of the generics-enabled javac'

(mentioned in the manual)

2)I get the error
BUILD FAILED
file:D:/deepak/buildProcess_2/_setup/docs.xml:190: Could not create task or type of type: findbugs.

Ant could not find the task or a class this task relies upon.

I have checked the alasspath for ant task. I have also placed the file jsr14adapter-1.1.jar in the lib subdirectory of your Ant installation.

any one suggest some solution.

bye,
with regards,
Deepak.

Hello Deepak, U may read the manual again. The problem is here - U have to use this node in build.xml

<taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask"/>

but before U run the build.xml, U have to copy findbugs-ant.jar from distribution of findbugs to your %ANT_HOME%/lib ...

Milan

P.S.
  everything is written in how2Use in http://findbugs.sourceforge.net

I agree with you, despite me developing a similar tool. But code reviews and user testing is fairly expensive way of finding bugs. Unit testing helps a lot, but you can still write hard to maintain code even with extensive unit tests.
So my sell is that you'd get a tool to catch as much problems (bugs, future maintenance problems...) as early as possible - as a part of your build cycle.
If you can, you'd still review some of the code, but as often as not code reviews are one of the first things to go when a deadline is in sight.

Re configuring - one of the things my tool does is it lets you to include switch-off tags for each rule in the code, javadoc style. This makes the developer to comment on why (s)he broke a rule. Rules are there so you think before you break them :). And if you find you break a rule way to often, you'd reconsider why you included it in the first place.
(one of the reasons I prefer to do analysis on source rather than bytecode).

Regards,
Vlad

Hi Vlad Ender
   thanks for your comments. And once again i want to tell you that my comments were just a reflection of my experience with different tools. I didnt want to demoralize anyone / any team.
    I will definitely give a shot to this tool and find out how good / bad it is. Its just that i have used so many of these tools & some of them are a joke.
So ... anyway all the best

I've found a couple of unused fields that I was aware of (unfinished classes) and some Mutable static field "bugs".

Hi, just a note to the FindBugs team: I wasn't able to start FindBugs' command line interface via
   findbugs -textui [other options] my.jar
Instead of this, I always got the GUI...

When I looked into the findbugs.bat, I stumbled upon these declarations:
   set firstArg=%~1
   set secondArg=%~2

This notation is unknown to me. When I changed it to the "expected"
   set firstArg=%1
   set secondArg=%2
the command line version was evoked...

(Note: I'm on NT 4.0...)

Cheers, Carsten

Hi, I tried FindBugs on some of my own classes and indeed it drew me to some places where I have been a little sloppy. Thus, it really can help to make code better.

On the other side, I experienced some strange behaviour. I deliberately inserted two bugs into my code (FYI, both snippets are from a static method, _logger is declared static, too) which should both lead to a NullPointerException when executed:

    // FindBugs is correctly reporting a "Null pointer dereference" on this one
    Integer dummy = null;
    int dummyAsInt = dummy.intValue();

    // FindBugs is ignoring this one
    _logger = null;
    _logger.debug("Try some logging if you can...");

Any ideas why the second null pointer dereference isn't detected by FindBugs?

Thanks, Carsten

Hey, does anybody run FindBugs over FindBug`s source? Looks like there is a bug on it! :)

Just kidding... I'm shure it's a great tool. I guess they forgot any char at regexp to get variable's name. :) Or... something like that.

Anyway, good job fokes!

Please, visit www.javafree.com.br (for brazillian programmers, or, anyone from Portugal, or, anyone who speaks, better, read and understand portuguese language :) )

See ya!

Hello there,
  I have a problem with findBugs called from ANTscripts.
  I would like to find bugs in my lib.jar (no dependencies on any other libraries). My build.xml looks like that:


<project default="run">
   <taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask"/>
   <property environment="env"/>

   <target name="init" >
     <property file="findbugs.properties"/>
     <property name="save.path" value="x:/_fbResults"/>
     <mkdir dir="${save.path}"/>
   </target>
        
  <target name="findbugs">
  <property name="data.dir" value="x:\_src2validate"/>
    <findbugs home="${env.FINDBUGS_HOME}"
              output="xml" outputFile="${save.path}/${module.name}.xml">
      <sourcePath path="${data.dir}\${module.name}_src" />
      <class location="${data.dir}\${module.name}.jar" />
    </findbugs>
  </target>
  
  <target name="callFB" depends="init" description="call findbugs">
    <antcall target="findbugs">
      <param name="module.name" value="lib"/>
    </antcall>
    <!-- another one's -->
  </target>

   <target name="run" depends="init, callFB" description="main method" />
</project>

 there are lib.jar and lib_src dir (with src of lib.jar) in directory x:\_src2validate. When I run the build.xml a get this exception

  Running FindBugs...
 [findbugs] java.lang.NoSuchMethodError: java.lang.Boolean java.lang.Boolean.valueOf(boolean)
 [findbugs] void edu.umd.cs.findbugs.Project.<init>()
 [findbugs] Project.java:76
 [findbugs] void edu.umd.cs.findbugs.FindBugs$FindBugsCommandLine.<init>()
 [findbugs] FindBugs.java:320
 [findbugs] void edu.umd.cs.findbugs.FindBugs.runMain(java.lang.String[])
 [findbugs] FindBugs.java:960
 [findbugs] void edu.umd.cs.findbugs.FindBugs.main(java.lang.String[])
 [findbugs] FindBugs.java:938
 [findbugs] Exception in thread main

 ... no result is written to output dir. If I try it with any other library (*.jar) and its sources, I get the same exception.

  Is there anybody who can help me ?
  Thanx very much ...
    Milan

Heya, I'm sorry to bore U with the problem ... basic mistake I did :(
I have installed 2 j2sdk (1.3.1. (for developing) and 1.4.0 (for findBux)) ... and I forgot tu switch Java_home from 1.3.1 to 1.4.0 :(

 ... Have an Ice Day :)
     Milan