tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <>
Subject Re: svn commit: r832039 - in /tomcat/trunk/java/org/apache/naming: resources/
Date Wed, 04 Nov 2009 11:08:41 GMT
2009/11/3 Mark Thomas <>:
> Filip Hanik - Dev Lists wrote:
>> On 11/02/2009 02:30 PM, Remy Maucherat wrote:
>>> On Mon, 2009-11-02 at 18:46 +0000, wrote:
>>>> Author: markt
>>>> Date: Mon Nov  2 18:46:21 2009
>>>> New Revision: 832039
>>>> URL:
>>>> Log:
>>>> StringBuffer ->  StringBuilder for o.a.naming
>>> So I did not test or anything, but is SBuilder faster than SBuffer ? Or
>>> it uses less resources ?
>> in most uses cases you'd barely see a difference. As speed locking has
>> gotten much better. (my unqualified guess is that locking is optimistic)
>> The only time you'd see a difference is if there was an actual
>> contention on the resource, which with StringBuffers is rare too.
> I'm leaning towards not porting this to 6.0.x since there is no clear
> performance issue caused by StringBuffer in 6.0.x. That said, the Javadoc for
> StringBuilder is enough to convince me that we should make the change in trunk
> as part of the general clean-up/improvement of the code for Tomcat 7.
> Mark

In my opinion, this change in no way different from any other. Though
it is not urgent, as nobody depends on it.

If anyone can find some time to review and vote for any subset of
those 50+ patches, and there will be enough votes, I will be happy to
commit it.

One benefit would be better alignment of TC 7 and TC 6 code and thus
easier backport of patches. The 6.0 -> 5.5 backports will need the
StringBuilder -> StringBuffer conversion anyway, so those are

Regarding the StringBuilder:
They have a common base class, AbstractStringBuilder, that provides
the implementation for them.  What they add on top of it are
classcasts, and synchronization.

Best regards,
Konstantin Kolinko

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

View raw message