<AWT Dev> [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation warnings in java.desktop module

[joe darcy]

On 12/10/2014 10:20 PM, Victor D'yakov wrote:
> Do we need to split it to AWT, Swing and 2D?

I would not find that helpful.

> The email is to 3 lists and its not clear who would pick up reviewing it.

I assume the people in each are would review their piece of the change.

>
> Also please use "client" forest this is our repo for pre-integration 
> testing all together with Client SQE we are following to avoid 
> regression cases.

As I explained below, since the code changes involve only copyright 
updates (in comments) and annotations (which don't affect the generated 
bytecode), there will no be functional change in the output based on 
this changeset.

Therefore, as long as a build succeeds, I don't see what difference 
client SQE testing would make in this particular case.

-Joe

>
> Victor
>
> On 10.12.2014 3:41, joe darcy wrote:
>> Hello,
>>
>> In support of JEP 212: Resolve Lint and Doclint Warnings 
>> (http://openjdk.java.net/jeps/212), which is targeted to JDK 9, 
>> please review the large but straightforward set of changes in the 
>> webrev:
>>
>>     http://cr.openjdk.java.net/~darcy/8066621.0/
>>
>> Some background of the approach being taken to address this part of 
>> JEP 212 was discussed on core-libs:
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html 
>>
>>
>> Briefly, to allow the deprecation warnings to be dealt with and that 
>> sole remaining lint warning category enabled in the build, a two-step 
>> approach is being taken. The first step is to suppress the 
>> deprecation warnings and the second step is for area-experts to 
>> examine the specific uses of deprecated APIs in their code. This 
>> webrev only attempts to cover the first step.
>>
>> The webrev is based off of the JDK 9 "dev" forest rather than the 
>> "client" forest. Since the change only involves copyright updates and 
>> adding annotations, there would be no functional modification in the 
>> changeset. Therefore, I would strongly prefer to push these changes 
>> directly to dev rather than pushing them to client and waiting for 
>> them to propagate to dev to expedite the time when the build warning 
>> can be enabled. (If a warning is not enabled in the build, new 
>> instances of the warning tend to creep into the code base.)
>>
>> Thanks,
>>
>> -Joe
>