Kelly,
There are two ways to use findbugs. It would be good to have a batch
run of findbugs per build with the goal of publishing metrics.
Separately, developers should be encouraged to run findbugs however
works best for them, to get their findbug count down.
-- Jon
On May 13, 2008, at 5:39 PM, Kelly O'Hair wrote:
David Herron wrote:
As the Quality group lead - I would be happy to have more quality
metrics like findbugs results to publish on the site. If we did
publish those results I'd want to tie it to an effort to find
community members to reduce the number of findbugs warnings. And,
um, it would be nice to have a parallel community effort to reduce
the number of compiler warnings ;-)
Another thing which would be useful is support for easily running a
comparison of findbugs results between two builds. One way this
could be used is to screen submissions of new code.. you'd have
findbugs results for the trunk, and you'd have findbugs results for
an individuals workspace, and you could compare them and see if the
developer is introducing new warnings and/or removing warnings.
But .. ah.. a 12 hr time to generate a set of findbugs results
doesn't sound scalable for this purpose..? Asking RE to produce
findbugs results for each promoted build might help but would that
skew their machine resource requirements?
Kelly, you asked about having findbugs as a build requirement. I
think it's not fitting as a hard build requirement. But I do think
there should be a findbugs build target and having findbugs in your
environment would be a requirement for that target but otherwise
not required.
But using the findbugs GUI or findbugs plugins (NetBeans/Eclipse)
is a much better user experience than the command line.
The textual output of findbugs is not something that is easy to
understand and connect up to the source, the html output is better
with the links and better source information.
The findbugs errors are usually a bit more complicated than your
typical javac error, not exactly sure how to describe it.
It's the GUI interfaces and the IDE's in particular that seem to
be the best findbugs analysis experience, in my opinion.
-kto
- David Herron
Jonathan Gibbons wrote:
Kelly,
I think that running findbugs on different segments of JDK and
publishing histograms of the results on the OpenJDK Quality pages
would be a fine idea, but unless we can get engineers to sign up
to reducing bugs found by findbugs, the histograms would be
somewhat boring.
-- Jon
On May 13, 2008, at 4:37 PM, Kelly O'Hair wrote:
I'm currently looking at how we could possible include a run of
findbugs
in the build process, but my conclusion right now is that we
cannot do it
by default, it takes way to long to run findbugs over everything.
(>12hrs).
But I could add some minor support to the Makefiles to allow
someone to
run findbugs on specific classes/packages, using a command line
like this:
findbugs -textui -maxHeap 1024 -javahome /YOUR/jdk1.6.0 -
sortByClass \
-onlyAnalyze "IMPORT_SPEC" -html -output report.html \
CLASSES_DIRECTORY_OR_JAR
For example, after I have built the jdk, you could run findbugs
over just
the java.lang.* classes:
findbugs -textui -maxHeap 1024 -javahome /opt/java/jdk1.6.0 -
sortByClass \
-onlyAnalyze "java.lang.*" -html -output report.html \
build/solaris-i586/classes
Ideally you want a fully populated classes directory or jar file so
that it can analyze all the classes properly.
(Note: using java.lang.* does not include the classes in the
nested packages).
But people could just run the findbugs GUI and do the same thing,
or better
yet, run the findbugs modules in the NetBeans IDE or Eclipse IDE.
So I'm at a loss as to whether I should include anything in the
makefiles
for this at all. Maybe I was premature in adding findbugs as a
build dependence
on the jdk and it should just be removed?
Any ideas out there? Or comments?
-kto
