[OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font

[Phil Race]

Joe,

We will get an integration going soon, so you won't have to wait too long.
Its more important to be consistent in that we get the client code in 
the client forest.
We already had to deal with a merge problem due to changes to client 
code made in dev.
So from now on if you have changes to client code, the client team's 
polite request is
you make them in the client forest after appropriate review.

-phil.

On 2/6/2014 9:54 AM, Joe Darcy wrote:
> On 02/06/2014 12:48 AM, Alan Bateman wrote:
>> On 05/02/2014 23:55, Phil Race wrote:
>>> Joe,
>>>
>>> This help is very much appreciated but can you please re-generate
>>> your webrev against jdk9/client and I'll review it then.
>>> If this is a problem for you then instead I can take your final 
>>> patch and
>>> commit into the client forest on your behalf.
>>> Let me know which you prefer.
>> All of these cleanups have (so far anyway) been pushed to jdk9/dev 
>> but there is clearly confusion as to where changes to 
>> AWT/Swing/2D/other code should be pushed. I hijacked one of Joe's 
>> recent reviews to restart that discussion:
>>
>> http://mail.openjdk.java.net/pipermail/2d-dev/2014-January/004181.html
>>
>> but I didn't see any replies except from Joe.
>>
>> -Alan.
>
> For the files involved in this review, when I checked late last night, 
> the unmodified versions of the files were  identical in the dev and 
> client forests.
>
> I've been using the results of an (unfortunately Oracle-internal only) 
> CI job run against the dev forest to track how we are doing on 
> warnings. Since December 2013, progress has been steady, with ~800 
> warnings being removed from client code.
>
> My preference is to push this fix into dev and the for the maintainers 
> of the client forest to sync it down. Unless there is a prompt and 
> regular integration of client into dev, I don't want to first push 
> these cleanup fixes to the client forest since there won't be prompt 
> registration of the reduced warnings and because it would complicate 
> efforts to fix all the warnings in a category and then enable checks 
> in the build.
>
> The goal here is not just to eliminate the warnings, but to eliminate 
> them and make sure they cannot come back :-)
>
> -Joe