JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK
Alan.Bateman at oracle.com
Mon May 12 10:42:54 UTC 2014
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
More information about the core-libs-dev