commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ola Berg <ola.b...@arkitema.se>
Subject Re: [lang] ToStringBuilder
Date Sat, 07 Sep 2002 19:50:48 GMT
Stephen says:

>This [using the StringBuffer transparently] seems sensible, although I don\'t know myself
how it would improve
>performance. But if you have a use case where it does, then this should go
>in.

Heavily aggregated objects, perhaps in multiple levels, toString() recursively generates a
lot of String + String + String operations. Doing the toString by passing the same StringBuffer
around avoids this. This is a performance hit in systems where toString() is used much (such
as in heavily logged systems). 

(What I\'m really saying is that java.lang.Object should have a:

public StringBuffer appendStringRepresentation( StringBuffer) 

...and that the Object public String toString() should look like:

public String toString(){
    return this.appendStringRepresentation( new StringBuffer()).toString();
}

...and that this ToString utility should make up for this.
)

>[lang] cannot assume get and set naming conventions.

True. But if something in BeanUtils provides this functionality, I suggest that it shares
interface or API-pattern or mechanism or blood-line with the String representation facility
that [lang] eventually will have (this or some other).

/O

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message