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

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;

Reply via email to