On 19.10.2016 17:43, Sergey Bylokhov wrote:
On 19.10.16 9:58, Semyon Sadetsky wrote:
On 17.10.16 21:47, Semyon Sadetsky wrote:
It can be replaced if it will be used in pair with getModifiersEx().
The old getModifiers() is also deprecated. And javadoc for
getModifiersEx() describes what and how constants should be used.
Can you add link to getModifiersEx() to all those constants' specs?

I assume you mean the new _DOWN constants not the old?
I meant that deprecated message should be transparently explaining the
impact of the replacement.
The proposed specs change recommends to use a replacement which is not
equivalent to the deprecated API. And that is the reason why you don't
like to eliminate all old API usages in the JDK code as a part of the
fix, if I correctly understand you previous reply in this thread.
Since you are insisting that migrating to the new API is risky it is
worth let the user know about that risk as well.

What does it mean risky? The new API is safe, but it is not safe to just find+replace the old constants to the new one, because it will be necessary to check how they are used.
The same is necessary for the user code. Look at the spec you propose:

  63     /**
  64      * The Shift key modifier constant.
  65      *
66 * @deprecated It is recommended that SHIFT_DOWN_MASK be used instead.
  67      */
  68     @Deprecated(since = "9")
  69     public static final int SHIFT_MASK = Event.SHIFT_MASK;

After your fix developer gets deprecation warning, read your recommendation and simply replace SHIFT_MASK with SHIFT_DOWN_MASK which may cause wrong app behavior. You should add something to the spec to make developer pay attention.

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

And, please, limit the length of the changed line in VMPanel.java
to 80
chars.

On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
Thanks for the comments.
The new version:
http://cr.openjdk.java.net/~serb/8143077/webrev.01
The specification of Event class and
InputEvent.getModifiers()
are
updated.

On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
Hi Sergey,

I'm not a reviewer, but after reading the deprecation
messages in
Event.java

    * @deprecated It is recommended that {@code AWTEvent}
class
and
its
    subclasses
    *             be used instead.


I get the impression they would read better without the
redundant
"class" in the middle, like so.

    * @deprecated It is recommended that {@code AWTEvent}
and
its
subclasses
    *             be used instead.


Kind regards,
Jonathan


On 30 September 2016 at 16:45, Sergey Bylokhov
<sergey.bylok...@oracle.com
<mailto:sergey.bylok...@oracle.com>>
wrote:

    Hello.

    Please review the fix for jdk9.

    This is request to deprecate the obsolete flags inside
InputEvent.
    This constants were marked as obsolete in jdk1.4 and
were
replaced
by the new one. In jdk1.4 the documentation were update
with
notion
    that the new constants should be used. And this bug is
about
    official deprecation of them.

We can replace old constants by the new one in the whole
jdk,
but I
    updated only the code in InputEvent to make change
smaller and
    safer. So at least the new code in jdk and the code in
applications
    will start to use the new constants.

The changes in jconsole are necessary to fix deprecation
warning.

jprt build passed, no new issues were found by jck/jtreg
tests.


    Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
<https://bugs.openjdk.java.net/browse/JDK-8143077>
    Webrev can be found at:
http://cr.openjdk.java.net/~serb/8143077/webrev.00
<http://cr.openjdk.java.net/~serb/8143077/webrev.00>

    --
    Best regards, Sergey.


























Reply via email to