Heap space issue

[findbugsproject]

Heap space issue

[GoogleCodeExporter]

Would it help if we also reduced the size of the classpath. Currently we are 
including 156 jars which might cause a few of the issues.

Original comment by [email protected] on 14 Mar 2011 at 9:02

[GoogleCodeExporter]

Just try tuning off effort=max. We've put a lot of work into tuning the normal 
effort so that it finds almost all of the errors you find using effort=max, and 
we haven't put a lot of work into tuning the time and space requirements for 
max.

Reducing the number of classes on the classpath might help. There isn't a lot 
we can do without access to the files you are analyzing. Is it an open source 
project?

Original comment by [email protected] on 14 Mar 2011 at 9:13

• Changed state: NeedInfo

[GoogleCodeExporter]

Unfortunately I work for a company, so the code is not open source. A coworker 
found an instance where findbugs was not catching a proper close resource bug. 
I then read more about the effort variable. I can provide you with any kind of 
debugging information, but no source code. I have 2 exams on Thursday, but I 
would be free over spring break to examine the findbugs source code to see 
where is the issue occurring. I was wondering though, if I wanted to 
contribute, how would I go about contributing through google code. 

On a side note, I was wondering if a new rule can be created because I found an 
annoying issue that I see occurring a lot in code. I noticed that in junit test 
code, for an assert method, they usually do assert(expected, actual) instead of 
assert(actual, expected) and was wondering if a very low priority rule can be 
created for this kind of instance.

Thanks again for all your help!

Original comment by [email protected] on 16 Mar 2011 at 8:07

[GoogleCodeExporter]

Sorry, for the side note, I meant to say instead of doing 
assertEquals(expected, actual) they do assertEquals(actual, expected)

Original comment by [email protected] on 16 Mar 2011 at 8:14

[GoogleCodeExporter]

I actually fixed it now by splitting up the jar into two separate files and 
running both, one after the other. It found one more violation which is good. 
Thanks again for your help.

Original comment by [email protected] on 23 Mar 2011 at 9:24

[GoogleCodeExporter]

Original comment by iloveeclipse on 23 Nov 2011 at 10:01

• Changed state: WontFix