commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [lang] Reusable Builder classes
Date Tue, 30 Sep 2003 20:02:44 GMT
Possible I suppose. I guess I don't have strong views either for or against.

Any other [lang] committers have any views?


----- Original Message -----
From: "Don Forbes" <>
I find the Builder classes really helpful, but find it wasteful having to
create a new HashCodeBuilder, CompareToBuilder or EqualsBuilder for each
invocation of a hashCode, equals or compareTo method.  In some situations,
such as a sort of a large collection, these methods can end up being called
often, thus imposing a high garbage collection overhead.

I am thinking of something analogous to StringBuffer, which can be reset for
reuse by simply calling setLength(0).

How about a simple reset() method, with no parameters, that just resets the
internal state (e.g. the variable "comparison" in the case of
CompareToBuilder) to its initial value?  (Possibly also a getter to
determine whether the builder is currently in a reusable state.)

Granted, this would require the Builder to be an instance variable of the
calling object rather than a local variable, thus raising issues of thread
safety.  Unfortunately using sychronized methods has something of a bad name
for performance.  In my understanding and experience this is an unfair
reputation, and my guess is that the overhead would be amply compensated for
by the savings in garbage collection.  But short of this, provided the
caller is given the responsibility for synchronising access to the object in
a multithreading scenario, I don't see a problem.

Any thoughts?


Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
Version: 6.0.515 / Virus Database: 313 - Release Date: 2003/09/01

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message