Runing findbugs

[Peter B. Kessler]

It's possible that it got folded into -Wformat on recent gcc's.
That's fine for the platforms (and bits of source) we compile
with gcc, but it would be nice if we could check all our code.

			... peter

Kelly O'Hair wrote:
> Jeez, I can't even spell running right... :^{
> 
> The pscan site seems to be dead:
>   http://www.striker.ottawa.on.ca/~aland/pscan/
> Anybody know what the new public site is for pscan?
> 
> ---
> 
> As to when to run findbugs, my conclusion is that the only time you
> can run it is after the entire jdk is built, otherwise findbugs cannot
> do the proper analysis. So even though you only want to analyze one
> package, you need all the classes it uses, which is more work to figure
> out than just running findbugs after the classes directory is fully
> populated. The performance of findbugs seems to be really slow, it
> starts out ok, 30-50% cpu usage, but slowly crawls up to 900Mb in
> process size and starts getting down to 2-4% cpu usage (using prstat).
> I suspect I need to use a machine with more RAM. Or a DTrace expert
> to inspect the process and find out what it's doing. ;^)
> 
> pscan could probably be run anytime I assume, although with hotspot
> that may be after makeDeps is run?
> 
> I really like the idea of these kind of scanners being run regularly,
> and all the time if possible, but not if they take 12+ hours. :^(
> 
> -kto
> 
> 
> Peter B. Kessler wrote:
>> If you've figured out where to run such a checker, can we run
>> pscan on our native sources?  Last time I checked, it took 3
>> seconds to run on a local copy of HotSpot (and found some things
>> that I fixed).  I did try it on all the native code in the JDK,
>> but I forget how long it took.  It wasn't long, though.  It would
>> be great to have a place to keep a list of such checkers.
>>
>>             ... peter
>>
>> 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
>>>
>>>
>>>
>>