Hudson's FindBugs plugin reports line number "-1" for bugs. Ideas?

Question

Greetings,
I have a simple test project set up in Hudson and the project's build process (a batch file) generates a findbugs.xml file. This is processed by Hudson's FindBugs plugin but it shows the line number of the bugs as "-1" instead of their actual line number. A coworker suggested I enable debug info for the compiler. I used the -g "Generate all debugging info" option for javac but nothing seemed to change. My build command is:

javac -g -classpath C:\testWebApp1\src -d C:\testWebApp1\build C:\testWebApp1\src\*.java

The only other thing in the build.bat file is a call to the FindBug tool (text UI). Here is what the FindBugs Plugin says about the first bug:

File: GenerateHellos.java, Line: -1, Type: UUF_UNUSED_FIELD, Priority: Normal, Category: PERFORMANCE

Any ideas? Thanks a ton!

Answer 1

This is half of an answer:

You have an unused field declared in that class. FindBugs uses static analysis of byte code to find bugs; unfortunately, the byte code format does not store line numbers for class or member fields, so FindBugs can't actually report a line number. There's got to be some switch that will allow it to output more helpful information (i.e. the name of the field), but I have no idea.

Alternatively, you might try PMD, which is a lot noisier, but actually analyzes the source code and also integrates with Hudson.

---

Did a little more digging and it looks like this is probably a bug in the inspector for that bug pattern. Assuming that your FindBugs run is configured with a n appropriate source directory (i.e., using -sourcepath), the majority of the bugs found should have line numbers associated with them. To check this, open the outputted report. You should see elements like the following:

<!-- skipping a bit -->
<BugInstance type="...">
    <Class classname="com.example.MyClass">
        <!-- ... -->
    </Class>
    <!-- ... -->
    <SourceLine classname="com.example.MyClass" start="5" end="5" sourcefile="MyClass.java"/>
</BugInstance>

The key there is the <SourceLine classname="..."/>, which reports the line number that the bug was found on. For numerous other inspections, including those for unread fields and a couple of other cases where their are no line numbers in the byte code, this line is filled in correctly, but not for UUF_UNUSED_FIELD. Hence, the Hudson plugin is doing the sensible thing and reporting line = -1.

The Eclipse plugin, however, which has access to Eclipse's rich metadata about the source code is able to locate the field by matching the field name, hence, it appearing to work in Eclipse (if you delete the field in question in Eclipse you should see the bug show up on the first line of the file; other bugs show up on the line number specified in the XML report).

No fix, but hopefully that clarifies what is happening.

Answer 2

You are almost there with the -g. Findbugs is based on bytecode analysis, and depends on the debugging information that is in the class files, your coworker is right about that.

You also need to clean out any previously generated class files, as the compiler is based on timestamps, and won't regenerate files that appear up-to-date.