Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of knst.kolinko@gmail.com
 designates 209.85.218.221 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=Jzh3UYg2g3ogAZ4r/Xoc+HYoj7OcAUO8GBpi+CY6mpDETIsApJ7BjmW16j01FWjWke
         7lOBkF8w7lhB2Qlof1/qv3SNBhofBIhlzb1ig4mHCzuYY1I7cQY+erfgvth0YrgTifKJ
         8yXHNShz337MMYkOoDlOlaKxY0ukAVGi1nOPY=
MIME-Version: 1.0
In-Reply-To: <4AF07237.2030200@apache.org>
References: <20091102184621.C62F7238898D@eris.apache.org>
	 <1257197441.2470.24.camel@work.remm.hd.free.fr>
	 <4AF05726.4030208@hanik.com> <4AF07237.2030200@apache.org>
Date: Wed, 4 Nov 2009 14:08:41 +0300
Message-ID: <427155180911040308y89ccc1fna6ca4035742363d0@mail.gmail.com>
Subject: Re: svn commit: r832039 - in /tomcat/trunk/java/org/apache/naming:
	HandlerRef.java ResourceRef.java ServiceRef.java StringManager.java
	resources/DirContextURLStreamHandler.java
From: Konstantin Kolinko <knst.kolinko@gmail.com>
To: Tomcat Developers List <dev@tomcat.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2009/11/3 Mark Thomas <markt@apache.org>:
> Filip Hanik - Dev Lists wrote:
>> On 11/02/2009 02:30 PM, Remy Maucherat wrote:
>>> On Mon, 2009-11-02 at 18:46 +0000, markt@apache.org wrote:
>>>
>>>> Author: markt
>>>> Date: Mon Nov =A02 18:46:21 2009
>>>> New Revision: 832039
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=3D832039&view=3Drev
>>>> Log:
>>>> StringBuffer -> =A0StringBuilder 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
unaffected.


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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org