<Swing Dev> <AWT Dev> [9] Review Request: 8143077 Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK

[Alexandr Scherbatiy]

The fix looks good to me.

Thanks,
Alexandr.

On 12/19/2016 10:29 PM, Sergey Bylokhov wrote:
>
>> 19 дек. 2016 г., в 22:28, Sergey Bylokhov <Sergey.Bylokhov at oracle.com 
>> <mailto:Sergey.Bylokhov at oracle.com>> написал(а):
>>
>> Hello.
>> Please review an updated version of the fix.
>>  - The comments are updated.
>> Two additional public api are deprecated:
>>  - KeyEvent.getKeyModifiersText()
>>  - AWTEvent(Event event)
>>
>> Note that I have to add @SuppressWarnings("deprecation») in places 
>> where the old API is used, because the option which ignores this 
>> warning was removed from the makefile. We will need to fix all of 
>> them one by one in jdk10, I’ll file a CR for this.
>
> Ouch the link is:
> http://cr.openjdk.java.net/~serb/8143077/webrev.04/ 
> <http://cr.openjdk.java.net/%7Eserb/8143077/webrev.04/>
>
>>
>>> On 10/26/2016 6:43 PM, Sergey Bylokhov wrote:
>>>> On 25.10.16 18:46, Semyon Sadetsky wrote:
>>>>>> I wonder why he should decide that the old code can be "simply
>>>>>> replaced" by the new one? I suppose that at least he should read the
>>>>>> specification of the new extended API. There is no notion that this
>>>>>> api is replaced by the new one, there is a recommendation that 
>>>>>> the new
>>>>>> one should be used instead.
>>>>> After reading such recommendation it's hard to conclude that one 
>>>>> "should
>>>>> read the specification of the new extended API". Even "@see" tag
>>>>> pointing to the extended API is not provided (I'm not even mentioning
>>>>> the warning that the extended API may be nonequivalent replacement is
>>>>> absent). I read this recommendation as it is: replace one constant 
>>>>> with
>>>>> another, no side effects expected.
>>>>
>>>> Good to know that you don't read the specification of the methods 
>>>> before using. So what is your proposal? Should I add a notion that 
>>>> these extendent constants contains different int values, and if the 
>>>> user depends from them in some way then he should not replace the 
>>>> old one to the new one? Or what @see reference should be added from 
>>>> some fields to another?
>>> The proposal is the same to notify user that he/she should not only 
>>> replace the constant but start to use another API. It's up to you 
>>> how to formulate this. If I did this in minimalistic way I would write:
>>>
>>> @deprecated It is recommended that SHIFT_DOWN_MASK and {@link 
>>> getModifiersEx()} be used instead.
>>>>
>>>>>>
>>>>>>>> We already have a notions that these "extended modifier constant"
>>>>>>>> should be used in the constructor of InputEvent and moreover in 
>>>>>>>> spec
>>>>>>>> of getModifiersEx() we have an additional examples how to use this
>>>>>>>> constants. This is why we will have a reference from old 
>>>>>>>> constans to
>>>>>>>> the new, and from getModifiers() to the getModifiersEx();
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170118/68efc1e4/attachment.html>