On Mon, Aug 16, 2010 at 9:34 PM, Simon Pepping <spepp...@leverkruid.eu>wrote:
> > I noted that the problems reported here are harder to fix. They often > touch upon design issues. yes, which is one reason I have not (yet) attempted to fix them, as fixes will require greater attention to intended semantics, and, it is not unlikely that fixes may introduce their own problems; e.g., simply producing an error-less run of junit does not guarantee the absence of a regression; i have not personally had enough time to review the level of testing performed by the current junit tests, so i am somewhat reluctant to launch into a potentially destablizing set of wide spread fixes; my preference is that authors or owners of code reporting errors take on the task themselves over time; for my part, i will be monitoring new code i contribute to ensure it doesn't increase the error count reported by findbugs; > See my efforts on the warnings for clone, > yes, and btw, java does not traditionally make as much use of a copy constructor per se as C++, since the intention of clone() is to satisfy that requirement; the general rule is that if a Java class implements Cloneable, then it must implement clone(), usually promoting this method to public, and should, in the general case, construct a deep copy; however, there are cases where, for optimization sake, some or all reference type fields may share a reference; nevertheless, if a designer does not explicitly intend to share some deep references, then deep copies should be made as well; if findbugs is reporting potential problems with clone() implementations, then the code should be carefully reviewed and corrected if needed; however, if the code has been reviewed and the behavior is as intended, then the findbugs report can be suppressed using the findbugs-exclude.xml file; > https://issues.apache.org/bugzilla/show_bug.cgi?id=49754. Probably, > when a codebase has no findbugs problems, it has a clean OO design. > But for a code base with a long history and many authors, that is > hardly feasible. Moreover, where would we find the time and budget to > do all this work? > well, i suppose that's one way volunteers can help out; it may be i can take intermittent stabs at fixing subsets of the reported problems over time; perhaps when i have the complex scripts feature adequately completed i can turn my attention to this; > I also noted that findbugs is too big for my simple machine. I do not > develop FOP as a profession, so I do not have a larger machine for > this purpose alone. at present, it appears to be running successfully with a 1GB max JVM heap; it does take a few minutes to complete though;
