<Swing Dev> [OpenJDK 2D-Dev] <AWT Dev> JDK 9 RFR of JDK-8032047: Fix static lint warnings in client libraries

[Sergey Bylokhov]

Hello, Joe.
Thanks. The fix looks good.

On 17.01.2014 23:30, Joe Darcy wrote:
> Hi Sergey,
>
> On 01/17/2014 02:28 AM, Sergey Bylokhov wrote:
>> Hello, Joe.
>> Some comments:
>>  - in the SunDropTargetContextPeer.java file header changed only
>
> Reverted.
>
>>  - Incorrect modification of if statement in D3DSurfaceDataProxy.java
>
> Fixed.
>
>>  - It is not necessary to use class name in  StyledEditorKit.java and 
>> HTMLEditorKit.java, because defaultActions is a private static field 
>> and it can be accessed directly.
>
> Improved.
>
> New webrev:
>
>     http://cr.openjdk.java.net/~darcy/8032047.2
>
> Thanks for the review,
>
> -Joe
>
>>
>> On 17.01.2014 11:31, Joe Darcy wrote:
>>> Hi Petr,
>>>
>>> On 01/16/2014 11:20 PM, Petr Pchelko wrote:
>>>> Hello, Joe.
>>>>
>>>> A couple of small comments:
>>>>
>>>> AffineTransformOp.java: Could you please split a long line #241
>>>
>>> Done.
>>>
>>>>
>>>> ClipboardTransferable.java: You can safely remove the 
>>>> DataTransferer.getInstance in this place.
>>>> The DataTransferer is a singleton and it's already created by this 
>>>> time.
>>>>
>>>> SunDragSourceContextPeer.java: same here, you can safely remove the 
>>>> getInstance
>>>
>>> Changed.
>>>
>>>>
>>>> D3DDrawImage.java: you've mistyped the copyright update.
>>>
>>> Fixed.
>>>
>>>>
>>>> D3DSurfaceDataProxy.java: Why did you choose to suppress a warning 
>>>> here? the getD3DDevice is
>>>> just a getter, it does not allocate new object and has no side 
>>>> effects..
>>>
>>> Changed.
>>>
>>> Revised webrev at
>>>
>>>     http://cr.openjdk.java.net/~darcy/8032047.0/
>>>
>>> Thanks for the careful review,
>>>
>>> -Joe
>>>
>>>>
>>>> With best regards. Petr.
>>>>
>>>> On 17.01.2014, at 10:55, Joe Darcy <joe.darcy at oracle.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Please view my proposed fix for
>>>>>
>>>>>     JDK-8032047: Fix static lint warnings in client libraries
>>>>>     http://cr.openjdk.java.net/~darcy/8032047.0/
>>>>>
>>>>> Mostly this fix consisted of just replacing a variable name with 
>>>>> the class name mentioned by javac in the warning message. In a few 
>>>>> cases where the expression allocated a new object, I choose to 
>>>>> just suppress the warning since I didn't feel motivated to analyze 
>>>>> the possible side-effects of the allocation.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Joe
>>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.