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

[Alan Bateman]

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 but I looked through the -core, -io, 
-management and -rmi patches and don't see any issues. 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.

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.

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.

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.

-Alan.