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
Hi Sergey,
For me issue and patch are quite simple so can be applied without test.
I'm just end user of jre and really annoyed by this exception clogs
application logs.
It took 15 minutes year ago to find that bug and vote for it, 15 minutes
last week to fix that using grep and vim.
To the developers of AWT,
I am building a framework, https://www.github.com/LinkTheProgrammer/SGL ,
and sometime in the future, I would like to support OpenGL contexts already
implemented in my framework (which is far from finished) with AWT.
There will eventually be an AWTDisplay
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
+1
--Semyon
On 10/11/2016 4:36 PM, Alexander Zvegintsev wrote:
+1
--
Thanks,
Alexander.
On 07.10.2016 17:07, Sergey Bylokhov wrote:
On 07.10.16 10:28, Semyon Sadetsky wrote:
Hi Sergey,
1525 queueEmpty = false;
1526 eventDispatched = false;
1527
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():
The fix looks good to me.
Thanks,
Alexandr.
On 10/17/2016 9:46 AM, Semyon Sadetsky wrote:
Looks good.
--Semyon
On 10/17/2016 5:54 AM, Ambarish Rapte wrote:
Hi,
Please review this test bug fix,
Bug: https://bugs.openjdk.java.net/browse/JDK-8167288
+1
Thanks,
Alexander.
On 10/13/16 12:12 AM, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8166897
webrev: http://cr.openjdk.java.net/~ssadetsky/8166897/webrev.00/
The setResizable() method of XDecoratedPeer class clears the frame
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
+1
-yan
On 10/12/2016 06:44 PM, Sergey Bylokhov wrote:
On 12.10.16 9:04, Ambarish Rapte wrote:
Thanks Anubhav,
Changes look fine to me.
+1
*From:*Anubhav Meena
*Sent:* Monday, October 10, 2016 5:06 PM
*To:* Ambarish Rapte
*Cc:* awt-dev@openjdk.java.net
*Subject:* Re: [9]
On 10/14/2016 4:17 PM, Sergey Bylokhov wrote:
On 05.10.16 10:40, Semyon Sadetsky wrote:
"in the way how bounds are used" what does it mean?
In current code the bounds of the graphics config are used incorrectly.
The thing is that the code produce the correct result, while the new
code
Looks good.
--Semyon
On 10/17/2016 5:54 AM, Ambarish Rapte wrote:
Hi,
Please review this test bug fix,
Bug: https://bugs.openjdk.java.net/browse/JDK-8167288
Webrev:
http://cr.openjdk.java.net/~arapte/8167288/webrev.00
19 matches
Mail list logo
