The fix looks good to me.
Thanks,
Alexandr.
On 12/19/2016 10:29 PM, Sergey Bylokhov wrote:
19 дек. 2016 г., в 22:28, Sergey Bylokhov > написал(а):
Hello.
Please review an updated version of the fix.
- The comments are
> 19 дек. 2016 г., в 22:28, Sergey Bylokhov
> написал(а):
>
> 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
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
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
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
On 10/25/2016 5:41 PM, Sergey Bylokhov wrote:
On 20.10.16 10:04, Semyon Sadetsky wrote:
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
On 20.10.16 10:04, Semyon Sadetsky wrote:
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
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
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
On 10/17/2016 9:53 PM, Sergey Bylokhov 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
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
On 10/17/2016 9:23 PM, Sergey Bylokhov wrote:
On 17.10.16 21:14, Semyon Sadetsky wrote:
Then this explanation should be added to the javadoc deprecation note
because currently it states that those constants can be replaced with
the new ones. But actually they are related to different APIs and
On 17.10.16 21:14, Semyon Sadetsky wrote:
Then this explanation should be added to the javadoc deprecation note
because currently it states that those constants can be replaced with
the new ones. But actually they are related to different APIs and cannot
simply substitute each other.
It can be
On 10/17/2016 7:35 PM, Sergey Bylokhov wrote:
On 17.10.16 19:01, Semyon Sadetsky wrote:
How it could be safe? both are a different constants which should be
used in pair with different methods?
Then why do you add in java doc for those constants:
@deprecated It is recommended that
On 17.10.16 19:01, Semyon Sadetsky wrote:
How it could be safe? both are a different constants which should be
used in pair with different methods?
Then why do you add in java doc for those constants:
@deprecated It is recommended that *_DOWN_MASK be used instead
This recommendation was
On 17.10.2016 18:37, Sergey Bylokhov wrote:
On 17.10.16 17:39, Semyon Sadetsky wrote:
On 17.10.2016 17:19, Sergey Bylokhov wrote:
On 17.10.16 15:16, Semyon Sadetsky wrote:
>>> We can replace old constants by the new one in the whole jdk,
but I
>>> updated only the code in
On 17.10.16 17:39, Semyon Sadetsky wrote:
On 17.10.2016 17:19, Sergey Bylokhov wrote:
On 17.10.16 15:16, Semyon Sadetsky wrote:
>>> 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
On 17.10.2016 17:19, Sergey Bylokhov wrote:
On 17.10.16 15:16, Semyon Sadetsky wrote:
>>> 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
On 17.10.16 15:16, Semyon Sadetsky wrote:
>>> 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
On 10/7/2016 4:21 PM, Sergey Bylokhov wrote:
On 07.10.16 10:06, Semyon Sadetsky wrote:
Hi Sergey,
After applying the patch I found 72 usages of the Event class. Why they
are not replaced?
By the same reason why InputEvent.getModifiers() was not replaced by
InputEvent.getModifiersEx():
Looks good.
On 10/7/16 4:21 PM, Sergey Bylokhov wrote:
On 07.10.16 10:06, Semyon Sadetsky wrote:
Hi Sergey,
After applying the patch I found 72 usages of the Event class. Why they
are not replaced?
By the same reason why InputEvent.getModifiers() was not replaced by
On 07.10.16 10:06, Semyon Sadetsky wrote:
Hi Sergey,
After applying the patch I found 72 usages of the Event class. Why they
are not replaced?
By the same reason why InputEvent.getModifiers() was not replaced by
InputEvent.getModifiersEx():
>>> We can replace old constants by the new
Hi Sergey,
After applying the patch I found 72 usages of the Event class. Why they
are not replaced?
--Semyon
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
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
Looks good.
Erik
On Sep 30, 2016, at 8:45 AM, Sergey Bylokhov 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
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,
The jconsole change looks fine. I’m including serviceability-dev and bcc
core-libs-dev as serviceability-dev is the right mailing list for jconsole
change.
Mandy
> On Sep 30, 2016, at 8:45 AM, Sergey Bylokhov
> wrote:
>
> Hello.
>
> Please review the fix for
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
28 matches
Mail list logo