JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

[Paul Sandoz]

On May 12, 2014, at 12:42 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 12/05/2014 11:03, Paul Sandoz wrote:
>> 
>> It covers many areas and i have grouped the patches into such areas to aid reviewing. When commenting please including core-libs.
> The groupings are a bit odd

Yeah, definitely idiosyncratic, i tried to lump 'em in terms of areas where people could focus their expertise without creating too few or too many webrevs.


> but I looked through the -core, -io, -management and -rmi patches and don't see any issues.

Thanks!


> Nothing jumped out to suggest that the StringBuffer could be leaked to other threads. There are a few cases where additional work could be done but I assume you want to focus on s/StringBuffer/StringBuilder/g.
> 

It might be worth fixing those if they are not too disruptive.


> You might want to hear from Remi or Kumar before including asm. I mention it because there might be preference to get changes to ASM done upstream to avoid the copy in OpenJDK from diverging.
> 

Yes.


> As a general point then I don't see any reason why this can't be one change-set. Periodically it makes sense to do a coarse grain split, say core + client but shouldn't be necessary here, unless of course there is some major refactoring or other big changes in, or coming soon to, jdk9/client. A coarse grain split just reduced the need for merging when sync'ing up integration forests.
> 

Ok.


> One minor comment is that refactoring where you change the name of the local can sometimes impact the alignment of statement that span several lines. VMID.toString is the only one that I noticed here and it's no big deal.
> 

I fixed that.

Paul.