RFC: backport of JDK-8215756: Memory leaks in the AWT on macOS

[Simon Tooke]

I have updated the webrev, preserving the original copyright date (as 
modified by the original patch).

http://cr.openjdk.java.net/~stooke/webrevs/jdk-8215756-jdk8u/03/jdk.03/

regards,

-simon

On 2020-02-18 3:07 p.m., Simon Tooke wrote:
>
> On 2020-02-18 6:03 a.m., Andrew Hughes wrote:
>>
>> On 18/02/2020 10:44, Mario Torre wrote:
>>> On Tue, Feb 18, 2020 at 11:40 AM Andrew Hughes 
>>> <gnu.andrew at redhat.com> wrote:
>>>>> Also, I updated the copyright one one of the files.
>>>>>
>>>>> new webrev:
>>>>> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8215756-jdk8u/02/jdk.02/ 
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Simon
>>>>>
>>>>>
>>>> Why are we chnaging the copyright dates from 2018 in the original 
>>>> patch
>>>> to 2019? That would just seem to create trouble for later backports.
>
> I will create a new webrev with the old copyright date and reply to 
> this thread.
>
> The reason it was changed was that the original patch changed the 
> original copyright date to 2018, and my thinking at the time was that 
> that was "wrong"; if the date were to be changed, it should be 
> updated.  Since them I've quickly come to agree with the view that the 
> less changes the better in order to make backports as simple as possible.
>
> -simon
>
>>>>
>>>> I agree with Aleksey's comments in general about keeping as close 
>>>> to the
>>>> original change as possible. Backports are not the place to be 
>>>> creative.
>>> I think this stems from the practice of updating the copyright year in
>>> files that are touched by changes, but I agree with you we shouldn't
>>> do it in backports unless the original patch also has the change.
>>>
>>> Cheers,
>>> Mario
>>>
>> Yes, I can see the reasoning, but I've also done enough backports that
>> break just because of differing copyright headers, that I'd rather
>> minimise the chance of that if possible :)