The current trunk shows no warnings during ANT compile. Please make reference to the current trunk/HEAD as 1.0 is published and history at this time.
It's a different matter with certain IDEs, e.g., Eclipse, which set their warning levels to a more sensitive level than the ANT build. Although it would be nice to eliminate such additional warnings, it is not as high priority IMO as ensuring that new compile, checkstyle, or findbugs warnings/errors do not appear during ANT builds. At the same time, warnings that do appear should not automatically be excluded without careful, manual review. G. On Mon, Feb 21, 2011 at 12:49 PM, Eric Douglas <edoug...@blockhouse.com>wrote: > 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 > --- > >
