[OpenJDK 2D-Dev] <AWT Dev> JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

[Paul Sandoz]

After some further reflection i have decided to not separate this out and some bits going to client and some bits going to dev, and have pushed all changes to dev. I realise this might cause some friction but believe it the right thing to do.

I remain unconvinced that the separate process for patches such as this scales and is a valuable use of our development time and resources. A merging process is surely fundamentally more efficient (and anyway has to be performed) over N developers having to use a slightly different process [*].

Call me human and flawed in my management of time :-( but higher priority things keep getting pushed to the top of my stack before getting around to following this separate process and i really don't want the code to bit rot. I suspect i am not unique in this regard.

Paul.

[*] Is it documented? I have never managed to obtain a definitive answer, nor an explicit white-list of Java package names (external yes, internal no).

On May 20, 2014, at 7:45 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:

> 
> On May 19, 2014, at 6:18 PM, Phil Race <philip.race at oracle.com> wrote:
> 
>> On 5/19/2014 12:50 AM, Alan Bateman wrote:
>>> On 19/05/2014 07:53, Paul Sandoz wrote:
>>>> If i don't have permission to push to the client repo (which might be likely) i will need to hand over the patch to yourself or Sergey to commit. And i presume this will have to be a separate issue.
>>> If you do decide to split this then it will require creating a second issue JIRA to avoid running foul of jcheck when jdk/client eventually pushes to jdk/dev. I don't know how often jdk9/client integrates into jdk9/dev but it doesn't seem to be very frequent (hg incoming suggests there is currently about a month of changes backed up in jdk9/client but there may be issues to explain this).
>>> 
>>> For this specific case then it doesn't seem worth it, it would be much less effort to just push the lot to jdk9/dev. Clearly if there were substantive changes then it would be important to push the changes to the forest where they are most likely to get tested but it hardly seems worth it here. From what I can tell then Phil or others sync up jdk9/client regularly and that might be the most efficient way to get these changes into jdk9/client.
>>> 
>> The changes should go through client for the reasons I already gave.
> 
> IIUC these were the reasons you gave in a previous email on this thread:
> 
> "I would not push hotspot changes to client either. Also lots of files
> are being updated in client and doing it this way will minimise merges ..."
> 
> I don't find either very convincing.
> 
> 
>> No new permissions are needed but it will need a unique bug id.
>> 
> 
> Ok.
> 
> 
>> FWIW integrations are intended to be bi-weekly but holidays interfered this time.
>> 
> 
> Why does it take so long?
> 
> Paul.