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

Semyon Sadetsky semyon.sadetsky at oracle.com
Wed Oct 26 16:06:40 UTC 2016

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();

More information about the awt-dev mailing list