I haven't looked at the trunk lately but 1.0 has a ton of warnings, at least in my compile. I don't know how much warnings have changed over the versions. I think it was originally written to compile on Java 1.4 or maybe even 1.3. 1.5 shows thousands of warnings, 1.6 shows more. Some of the warnings are quirky (raw type list?), some are just wasteful (dead code? Local variable never referenced?). If there's code which is actually incorrect logic it needs to be fixed. If there's code which is just incomplete logic, maybe setting something up for a future improvement someone wanted to add, that should be removed and placed in a separate to do list document.
-----Original Message----- From: Andreas Delmelle [mailto:andreas.delme...@telenet.be] Sent: Monday, February 21, 2011 2:29 PM To: fop-dev@xmlgraphics.apache.org Subject: Re: Solving FindBugs issues [was: Re: svn commit: r1071912 - in /xmlgraphics/fop/trunk: findbugs-exclude.xml src/java/org/apache/fop/render/pdf/PDFImageHandlerSVG.java] On 21 Feb 2011, at 19:15, Vincent Hennebert wrote: > If we solve issues raised by FindBugs by listing them in an ignore > file, is there still a point to use FindBugs at all? > > It seems to me that some of those issues deserve to be fixed. They > seem to point out genuine problems in the code. I was about to convey a similar sentiment. If we are only going to ignore potential bugs, the point of the whole exercise seems totally lost. Some of them may be OK to ignore, as Glenn pointed out, but IIUC, one of those potentially introduced bugs (that we are now ignoring) is likely of the same nature as one that Chris fixed in the very same area a while back (potentially unclosed stream, leading to a descriptor leak in the AFP renderer)... Not very encouraging. :( Mea culpa: I saw one exclusion --unconfirmed cast-- that would seem to stem from my recent refactoring in the BlockStackingLMs. Not sure why an exclusion was chosen here, but adding an assert statement in the code avoids the warning as well *and* has the benefit of being visible exactly at the spot in the code where it applies. Seemed like the more proper way to handle this. Just my 2 cents... Regards, Andreas ---
