[OpenJDK 2D-Dev] <AWT Dev> JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK
Alan.Bateman at oracle.com
Wed May 14 09:05:41 UTC 2014
On 14/05/2014 09:15, Paul Sandoz wrote:
>> And here what could have been a 2 line change is 25 ..
>> So I would say leave the variable names alone unless there's a compelling reason - and I don't see one.
> "buf" no longer corresponds to a buffer but to a builder, so i think it is reasonable in this case to use the canonical "sb" name.
I agree, "buf" or "buffer" looks odd when the type is changed to
> This code is under src/share/classes, so it's not clear to me what classes i can modify and push in the jdk9-dev/jdk repo or not. It's confusing! Is there a list online somewhere?
> Out of all the classes here:
> exactly which ones should be pushed to the client forest and which ones to the jdk9-dev forest? all of them, or just a sub-set?
> How long would it take for the changes to the client jdk repo to make it's way into the jdk9-dev jdk repo?
> Really what i am getting at here is i think we need to change our process of how we manage such forests; we need to consolidate.
I think Sergey and Phil are asking for the bean classes from -core patch
and all of -media to be pushed to jdk9/client.
From an approachability perspective then it's total baloney for library
changes to take different routes. On the other hand there may be
exceptions needed for areas or changes that involve manual or other
special testing before integration. There was a lengthy thread on
jdk9-dev about the integration forests and processes  where this was
discussed. I don't recall seeing a boolean result to the questions that
asked whether the client libraries require any manual testing before
integration. As things stand then what we loosely call "client
libraries" are pushed to jdk9/client, everything else is pushed to
jdk9/dev. I really hope this can be re-visited soon.
More information about the core-libs-dev