Re: [12] Review Request: 8214918 Unify GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() across the platforms

Hi Sergey,   The changes look fine to me.   Thanks, Krishna Subject: [12] Review Request: 8214918 Unify GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() across the platforms Date: Thu, 6 Dec 2018 09:26:06 -0800 From: Sergey Bylokhov HYPERLINK "mailto:sergey.bylok

[13] RFR: JDK-8215910: Typo in AWT InvocationEvent Method Documentation

Hi All, Please review a trivial doc fix for JDK-8215910. Webrev: http://cr.openjdk.java.net/~kaddepalli/8215910/webrev00/ Thanks, Krishna

Re: [13] RFR: JDK-8215910: Typo in AWT InvocationEvent Method Documentation

t; But the bug hasn't been fixed yet: > > - 230 * @param listener The {@code Runnable}Runnable whose > + 230 * @param listener The {@code Runnable} Runnable whose > > The second “Runnable” is not needed at all. > > Regards, > Alexey > >

Re: [13] RFR: JDK-8215910: Typo in AWT InvocationEvent Method Documentation

Thank you Alexey. I understood that the second Runnable was not needed, hence I made changes. So, I believe you are endorsing webrev01 right? Thanks Krishna -Original Message- From: Alexey Ivanov Sent: Thursday, January 3, 2019 3:14 PM To: Krishna Addepalli ; awt-dev Subject: Re

Re: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash

+1 Thanks, Krishna From: Shashidhara Veerabhadraiah Sent: Thursday, January 3, 2019 3:06 PM To: awt-dev@openjdk.java.net; swing-...@openjdk.java.net Subject: [13] JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to crash Hi All, Please review a fix for the

[12]RFR: JDK-8215921: There is no change when select different Foreground and Background by mouse.

Hi All, Please review a fix for JDK-8215921: https://bugs.openjdk.java.net/browse/JDK-8215921, Webrev: http://cr.openjdk.java.net/~kaddepalli/8215921/webrev00/ This is a regression, which involves other similar bugs HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8215942"JDK-8215942,

Re: [12] Review request for JDK-8215280: Double click on titlebar not working for Frame with extended state set to MAXIMIZED_BOTH

+1 -Original Message- From: Sergey Bylokhov Sent: Tuesday, January 15, 2019 7:19 AM To: Manajit Halder Cc: awt-dev@openjdk.java.net Subject: Re: [12] Review request for JDK-8215280: Double click on titlebar not working for Frame with extended state set to MAXIMIZED_BOTH Looks fine.

Re: [12]RFR: JDK-8215921: There is no change when select different Foreground and Background by mouse.

net/~kaddepalli/8215921/webrev01/> Thanks, Krishna > On 16-Jan-2019, at 12:50 AM, Sergey Bylokhov > wrote: > > Hi, Krishna. > > On 15/01/2019 08:52, Krishna Addepalli wrote: >> While fixing JDK-8014503 <https://bugs.openjdk.java.net/browse/JDK-8014503>, >>

Re: [12]RFR: JDK-8215921: There is no change when select different Foreground and Background by mouse.

item is selected again. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8215921/webrev02 <http://cr.openjdk.java.net/~kaddepalli/8215921/webrev02> Thanks, Krishna > On 17-Jan-2019, at 1:30 AM, Sergey Bylokhov > wrote: > > > On 16/01/2019 09:59, Kr

Re: [12]RFR: JDK-8215921: There is no change when select different Foreground and Background by mouse.

. Thanks, Krishna From: <> Krishna Addepalli Sent: Thursday, January 17, 2019 8:34 PM To: Sergey Bylokhov Cc: awt-dev@openjdk.java.net Subject: Re: [12]RFR: JDK-8215921: There is no change when select different Foreground and Background by mouse. Hi Sergey, The test case was lead

Re: [12]RFR: JDK-8215921: There is no change when select different Foreground and Background by mouse.

and found that it >> runs on all 3 platforms without any problems. >> I have also tested all the regressions that were raised, and all of them >> passed. In addition, I ran all the awt/Choice jtreg tests, and found no new >> failures. >> Thanks, >> Kris

Re: [12]RFR: JDK-8215921: There is no change when select different Foreground and Background by mouse.

he same element in the list. >>> >>> On 23/01/2019 09:33, Phil Race wrote: >>>> This looks OK so long as you can confirm that you re-tested all related >>>> tests, not >>>> just your regression test after making the source code update ... >&g

Re: [12]RFR: JDK-8215921: There is no change when select different Foreground and Background by mouse.

mTest.html 8192929 > windows-all,linux-all > from ProblemList > > Regards > Prasanta > On 29-Jan-19 1:37 AM, Sergey Bylokhov wrote: >> Looks fine. >> >> On 28/01/2019 09:03, Krishna Addepalli wrote: >>> Hi Sergey, >>> >>> I correct

Re: [13] RFR JDK-8217464: Remove resolved client bugs from the ProblemList.txt

+1 Krishna > On 30-Jan-2019, at 3:56 PM, Prasanta Sadhukhan > wrote: > > Hi All, > > Please review an updation of ProblemList to remove/update resolved client > bugs from ProblemList > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217464 > webrev: http://cr.openjdk.java.net/~psadhukhan/8

Re: [12] JDK-8061359: [macosx] Checkbox toggles on Space press but does not spoken by Voice Over

Hi Shashi, I presume you meant this fix to be reviewed for 13. Could you re-upload the patch with latest code? I tried importing the patch, but it fails to apply on the latest code. Here is the output I get: applying http://cr.openjdk.java.net/~sveerabhadra/8061359/webrev.00/jdk11-dev-client-1.

Re: [12] JDK-8061359: [macosx] Checkbox toggles on Space press but does not spoken by Voice Over

Sorry, please ignore my previous mail. My mail client synced up mails (after re-formatting) and showed this as a new mail. Sorry for the confusion. Thanks, Krishna > On 31-Jan-2019, at 12:30 PM, Krishna Addepalli > wrote: > > Hi Shashi, > I presume you meant this fix to be

Re: [13] Review request for JDK-8207938: At step6, Click Add button, case failed automatically.

Looks fine. Thanks, Krishna From: Manajit Halder Sent: Tuesday, February 5, 2019 3:22 PM To: awt-dev@openjdk.java.net Subject: [13] Review request for JDK-8207938: At step6, Click Add button, case failed automatically. Hi All, Please review the fix for JDK13. Bug: https://b

Re: [13] Review Request: 8219504 Test for JDK-8211435 can be run on all platforms

+1 Krishna -Original Message- From: Sergey Bylokhov Sent: Thursday, February 21, 2019 8:01 AM To: awt-dev@openjdk.java.net Subject: [13] Review Request: 8219504 Test for JDK-8211435 can be run on all platforms Hello. Please review the fix for jdk 13. Bug: https://bugs.openjdk.java.ne

Re: [9] Review request for JDK-8156460 [macosx] Test case javax/swing/JPopupMenu/6827786/bug6827786.java fails

Hi Sergey Malenkov, Thank you for pointing this out. This issue is also reported in JDK-8218917. I’m looking into the issue. Thanks, Krishna > On 01-Mar-2019, at 2:45 AM, Sergey Bylokhov > wrote: > > Hi, Sergey. > > Do you have bugid for this issue? > > On 28/02/2019 09:35, Sergey Malenkov

[13] JDK-8218917: KeyEvent.getModifiers() returns inconsistent values for ALT keys

Hi All, Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8218917 With webrev: http://cr.openjdk.java.net/~kaddepalli/8218917/webrev00/ The problem is that once right alt

Re: [13] JDK-8218917: KeyEvent.getModifiers() returns inconsistent values for ALT keys

fX_k&m=vpGiD5G2K4wQZbNL-H0ffHAEDEWj-433rJ1a-9zAeyE&s=P2SNOGSmKVcDyQuWHUuP9hs5wxjrqkdwtrOMGqv-tZg&e= > > Unfortunately I cannot create an automated test, because the Robot > have no ability to press a key in the required location (left or > right). > > > > On We

Re: [13] JDK-8218917: KeyEvent.getModifiers() returns inconsistent values for ALT keys

Hi Sergey Malenkov, > 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet In my personal experience, I did not find any instance, wherein a shortcut had left and right alt in it. Although it is not impossible, it seems weird to define such shortcuts. It would be helpful if

Re: [13] JDK-8218917: KeyEvent.getModifiers() returns inconsistent values for ALT keys

;>>> But we will get the same result if we will use the AltGr mask only. >>>> >>>>> It is not backward compatible to use AltGr instead of right Alt in >>>>> both cases. Instead of 'Alt+key' you will get 'AltGr+key'

Re: [13] JDK-8218917: KeyEvent.getModifiers() returns inconsistent values for ALT keys

event for the right Alt. > > http://bugs.openjdk.java.net/browse/JDK-8151136 > According to the issue above AltGr support was backported to 9. > > > On Wed, Mar 20, 2019 at 2:18 PM Krishna Addepalli > wrote: >> >> Hi Sergey Malenkov, >> >> We ca

Re: [13] JDK-8218917: KeyEvent.getModifiers() returns inconsistent values for ALT keys

Hi Sergey Malenkov, Any chance that you can agree on my proposal? If you are okay I can raise a new bug for addressing your concern, and fixing the current problem at hand? Thanks, Krishna > On 26-Mar-2019, at 4:26 PM, Krishna Addepalli > wrote: > > Hi Sergey Malenkov, > &

Re: [13] RFR JDK-8222097: ProblemList tests that are failing recurringly and intermittently in PIT

Hi Prasanta, As per my experience, the Mixing related tests are failing because of the first test which passes and probably doesn’t clean up some state which makes others fail. Is it possible to have one bug for the head, and remove the rest of them from the problem list, just to keep it manag

Re: [13] RFR JDK-8222097: ProblemList tests that are failing recurringly and intermittently in PIT

should test all these > tests pass. > > I need all these in ProblemList as in PIT all those tests fail on windows > recurringly, > > Regards > Prasanta > On 08-Apr-19 12:08 PM, Krishna Addepalli wrote: >> Hi Prasanta, >> >> As per my experienc

Re: [13] RFR JDK-8222097: ProblemList tests that are failing recurringly and intermittently in PIT

Hmm! looks ok -Krishna > On 09-Apr-2019, at 10:11 AM, Prasanta Sadhukhan > wrote: > > I dont think we can AFAIK. > Regards > Prasanta > On 08-Apr-19 4:01 PM, Krishna Addepalli wrote: >> I understand that, but my question is if we can replace all those lines in &g

Re: [13] JDK-8218917: KeyEvent.getModifiers() returns inconsistent values for ALT keys

nconvenience. Thanks, Krishna > On 08-Apr-2019, at 10:33 AM, Krishna Addepalli > wrote: > > Hi Sergey Malenkov, > > Any chance that you can agree on my proposal? > If you are okay I can raise a new bug for addressing your concern, and fixing > the current problem at hand

Re: [13] JDK-8218917: KeyEvent.getModifiers() returns inconsistent values for ALT keys

Thanks for the review Sergey! Need one more reviewer. > On 11-Apr-2019, at 7:40 AM, Sergey Bylokhov > wrote: > > On 10/04/2019 07:51, Krishna Addepalli wrote: >> Hi Sergey Bylokhov/Phil/Prasanta/Jay, >> Could you review the fix for this issue? Here

[10][

Hi All, Please review the fix for test bug: Bug : JDK-8027154 __ JDK 10 Webrev: http://cr.openjdk.java.net/~pkbalakr/Krishna/8027154/webrev00/

[10][JDK-8027154] [TESTBUG] Test java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails

Hi All, Please review the fix for test bug: Bug : JDK-8027154 __ JDK 10 Webrev: http://cr.openjdk.java.net/~pkbalakr/Krishna/8027154/webrev00/

[10][JDK-8075084] JOptionPane.showMessageDialog causes JScrollBar to move

Hi All, Please review the fix for bug: Bug: JDK- 8075084 https://bugs.openjdk.java.net/browse/JDK-8075084 JDK 10 Webrev : http://cr.openjdk.java.net/~psadhukhan/8075084/webrev00/ Summary: This is an interesting test case written by Drew Jetter (http://webbugs.us.oracle.com/IMWeb/

Re: [10][JDK-8027154] [TESTBUG] Test java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails

: Krishna Addepalli mailto:krishna.addepa...@oracle.com"krishna.addepa...@oracle.com> Cc: Ambarish Rapte mailto:ambarish.ra...@oracle.com"ambarish.ra...@oracle.com>; Ajit Ghaisas mailto:ajit.ghai...@oracle.com"ajit.ghai...@oracle.com>; Prem Balakrishnan mailto:prem

[10][JDK-8175015] FileSystemView.isDrive(File) memory leak on "C:\" file reference

Hi All, Please review the fix for bug: Bug: JDK- 8175015 https://bugs.openjdk.java.net/browse/JDK-8175015 JDK 10 Webrev : http://cr.openjdk.java.net/~pkbalakr/Krishna/8175015/webrev00/ Summary: The bug reports about memory leak by repeatedly querying FileSystemView, if "C:\" is a

Re: [10][JDK-8175015] FileSystemView.isDrive(File) memory leak on "C:\" file reference

is again reducing. You can see that this kind of pattern repeats a few times, but eventually, the memory runs out. Thanks, Krishna -Original Message- From: Sergey Bylokhov Sent: Wednesday, August 9, 2017 5:16 AM To: Krishna Addepalli ; awt-dev@openjdk.java.net Subject: Re: [10][JDK-8

Re: [10][JDK-8175015] FileSystemView.isDrive(File) memory leak on "C:\" file reference

://cr.openjdk.java.net/~pkbalakr/Krishna/8175015/webrev01/ Thanks, Krishna -Original Message- From: Sergey Bylokhov Sent: Wednesday, August 9, 2017 5:16 AM To: Krishna Addepalli ; awt-dev@openjdk.java.net Subject: Re: [10][JDK-8175015] FileSystemView.isDrive(File) memory leak on "C:\&

Re: [10][JDK-8175015] FileSystemView.isDrive(File) memory leak on "C:\" file reference

Hi Sergey, I checked with Thread.MAX_PRIORITY - 1, and found that it still leads to OOM exception, although it takes longer to get to that condition. Thanks, Krishna -Original Message- From: Sergey Bylokhov Sent: Tuesday, August 29, 2017 6:19 AM To: Krishna Addepalli Cc: awt-dev

Re: [10][JDK-8175015] FileSystemView.isDrive(File) memory leak on "C:\" file reference

Hi Prasanta,   Even in the previous case, it falls through and returns false. The same behavior is maintained with the current code as well.   Thanks, Krishna   From: Prasanta Sadhukhan Sent: Wednesday, August 30, 2017 2:00 PM To: Krishna Addepalli Cc: awt-dev@openjdk.java.net Subject

[11][JDK-8171000]Robot.createScreenCapture() crashes in wayland mode

Hi All, Please review a fix for JDK-8171000: https://bugs.openjdk.java.net/browse/JDK-8171000 Webrev: http://cr.openjdk.java.net/~kaddepalli/8171000/webrev00/ The crash happens since XGetImage can return NULL in case of Wayland, which doesnot permit reading screen pixels outside the own

Re: [11][JDK-8171000]Robot.createScreenCapture() crashes in wayland mode

int of use. Thanks, Krishna -Original Message- From: Sergey Bylokhov Sent: Saturday, February 3, 2018 1:27 PM To: Krishna Addepalli ; awt-dev@openjdk.java.net Subject: Re: [11][JDK-8171000]Robot.createScreenCapture() crashes in wayland mode Hi, Krishna. The change of local types declarat

[11][JDK-8152974] AWT hang occurs when sequenced events arrive out of sequence

Hi All, Please review a fix for JDK-8152974: https://bugs.openjdk.java.net/browse/JDK-8152974 Webrev: http://cr.openjdk.java.net/~kaddepalli/8152974/webrev00/ The problem is when the events arrive out of sequence, the sequenced event's dispatch loop assumes that the sequenced events ar

Re: [11][JDK-8152974] AWT hang occurs when sequenced events

it post two SequencedEvents out of order, the first waits when the second will be dispatched, why it hangs forever? On 15/02/2018 04:16, Krishna Addepalli wrote: > Hi All, > > Please review a fix for ?JDK-8152974: > https://bugs.openjdk.java.net/browse/JDK-8152974 > > Webr

Re: [11][JDK-8152974] AWT hang occurs when sequenced events

ergey Bylokhov Sent: Saturday, February 17, 2018 1:49 AM To: Krishna Addepalli ; awt-dev@openjdk.java.net; Semyon Sadetsky Subject: Re: [11][JDK-8152974] AWT hang occurs when sequenced events Hi, Krishna. On 16/02/2018 00:42, Krishna Addepalli wrote: > The SentEvent.ID value is "java.awt.e

[11][JDK-8197808] Test java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java fails on Windows

Hi All, Please review a fix for JDK-8197808: https://bugs.openjdk.java.net/browse/JDK-8197808 Webrev: http://cr.openjdk.java.net/~kaddepalli/8197808/webrev00/ The problem was that by the time Robot tries to read the color on screen, the compositing of the window is not completed, and hen

Re: [11] JDK-8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails

Hi Shashi, This test passes for me without any problems on my machine. I'm using Windows 10 build 1703 - i.e it is not Fall Creators build. Also, the intent of the test is to check that, if a frame is drawn on top of another frame, then the mouse move should be seen by the top frame and not th

Re: [11][JDK-8197808] Test java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java fails on Windows

/without my changes. As noted earlier, on Windows 10, the test passes after the fix. Thanks, Krishna -Original Message- From: Philip Race Sent: Tuesday, February 27, 2018 6:01 AM To: Sergey Bylokhov Cc: Krishna Addepalli ; awt-dev@openjdk.java.net Subject: Re: [11][JDK-8197808] Test java/awt

Re: [11] Review request for JDK-8190767: [macos] if JFrame is maximized on OS X, all new JFrames will be maximized by default

Looks fine for me as well. Thanks, Krishna Date: Tue, 6 Mar 2018 15:25:04 -0800 From: Sergey Bylokhov To: Manajit Halder Cc: awt-dev@openjdk.java.net Subject: Re: [11] Review request for JDK-8190767: [macos] if JFrame is maximized on OS X, all new JFrames will be maximized by d

Re: [11] Review Request: 8199022 New

Hi Sergey, Bug id is JDK-8197798 for java/awt/JAWT/JAWT.sh Thanks, Krishna Message: 1 Date: Wed, 7 Mar 2018 05:55:58 -0800 From: Sergey Bylokhov To: Prasanta Sadhukhan , "swing-...@openjdk.java.net" , "awt-dev@openjdk.java.net" Subject: Re: [11] Review Request: 8199022 New

Re: [11][JDK-8152974] AWT hang occurs when sequenced events

/ However, could you point me to a doc/spec which says that all the SequencedEvents have to be processed together, even if other events in the queue have arrived before? Thanks, Krishna -Original Message- From: Krishna Addepalli Sent: Saturday, February 17, 2018 7:57 AM To: Sergey

Re: [11][JDK-8152974] AWT hang occurs when sequenced events

- From: Semyon Sadetsky Sent: Thursday, March 15, 2018 9:14 PM To: Krishna Addepalli ; awt-dev@openjdk.java.net Subject: Re: [11][JDK-8152974] AWT hang occurs when sequenced events Hi Krishna, You have replaced FOCUS_LAST+2 with the FOCUS_LAST+1 which is absolutely different event. They

Re: [11][JDK-8152974] AWT hang occurs when sequenced events

reference: "edt.pumpEvents(ID, () -> !SequencedEvent.this.isFirstOrDisposed());" Thanks, Krishna -Original Message- From: Semyon Sadetsky Sent: Thursday, March 15, 2018 10:36 PM To: Krishna Addepalli ; awt-dev@openjdk.java.net Subject: Re: [11][JDK-8152974] AWT han

Re: [11][JDK-8152974] AWT hang occurs when sequenced events

: Krishna Addepalli ; awt-dev@openjdk.java.net Subject: Re: [11][JDK-8152974] AWT hang occurs when sequenced events On 03/15/2018 10:11 AM, Krishna Addepalli wrote: > If no such event is posted to the queue, it will lead to hang right? Are you sure that the root cause is that there are no s

Re: [11][JDK-8152974] AWT hang occurs when sequenced events

the newly created context. And I have also added two dummy events between two sequenced events just to make sure that, that case also works. Thanks, Krishna -Original Message- From: Semyon Sadetsky Sent: Friday, March 16, 2018 12:01 AM To: Krishna Addepalli ; awt-dev@openjdk.java.net Su

Re: [11][JDK-8152974] AWT hang occurs when sequenced events

ifies your concerns. Thanks, Krishna -Original Message- From: Semyon Sadetsky Sent: Friday, March 16, 2018 1:59 AM To: Krishna Addepalli ; awt-dev@openjdk.java.net Subject: Re: [11][JDK-8152974] AWT hang occurs when sequenced events I was wrong I see the application context in the test bu

Re: RFR: 8198649 : Switch AWT/Swing's default GTK version to 3

Hi Phil, The change looks fine for me. Thanks, Krishna -Original Message- From: Phil Race Sent: Friday, March 16, 2018 11:05 PM To: awt-dev@openjdk.java.net; swing-...@openjdk.java.net Subject: RFR: 8198649 : Switch AWT/Swing's default GTK version to 3 Bug: https://bugs.openjdk.java.

Re: [11][JDK-8152974] AWT hang occurs when sequenced events

ontext, whereas the other two are >> posted on the newly created context. And I have also added two dummy >> events between two sequenced events just to make sure that, that case >> also works. >> >> Thanks, >> Krishna >> >> -Original Messag

Re: RFR: 8200313 : java/awt/Gtk/GtkVersionTest/GtkVersionTest.java fails

Hi Phil, The changes look fine. However, since you are already making changes to the test, could you also clean up the imports? Thanks, Krishna -Original Message- From: Phil Race Sent: Tuesday, March 27, 2018 11:05 PM To: awt-dev@openjdk.java.net Subject: RFR: 8200313 : java/awt/Gtk/

Re: RFR: 8200313 : java/awt/Gtk/GtkVersionTest/GtkVersionTest.java fails

+1 -Original Message- From: Sergey Bylokhov Sent: Thursday, March 29, 2018 6:23 AM To: Phil Race ; Krishna Addepalli ; awt-dev@openjdk.java.net Subject: Re: RFR: 8200313 : java/awt/Gtk/GtkVersionTest/GtkVersionTest.java fails +1 On 28/03/2018 15:03, Phil Race wrote: > Updated web

[11]JDK-8200525: test java/awt/event/SequencedEvent/SequencedEventTest.java fails to compile

Hi All, Please review a trivial compilation fix for the bug: https://bugs.openjdk.java.net/browse/JDK-8200525 Webrev: http://cr.openjdk.java.net/~kaddepalli/8200525/webrev00/ The problem was, the test case uses some of the internal classes, which were not specified for the jtreg data sec

Re: [11] Review Request: 8187392 Deprecated methods in the peers can be removed

Hi Sergey, The changes look fine to me. Thanks, Krishna -Original Message- From: Sergey Bylokhov Sent: Wednesday, April 4, 2018 12:14 PM To: awt-dev@openjdk.java.net Subject: [11] Review Request: 8187392 Deprecated methods in the peers can be removed Hello. Please review fix for jdk1

Re: [8u-backport] Review request for 8152974 : AWT hang occurrs when sequenced events arrive out of sequence

Looks fine to me. Thanks, Krishna From: Dipak Kumar Sent: Thursday, April 5, 2018 1:57 PM To: Sergey Bylokhov ; Semyon Sadetsky ; Philip Race ; Krishna Addepalli ; awt-dev@openjdk.java.net Subject: [8u-backport] Review request for 8152974 : AWT hang occurrs when sequenced events

[11][JDK-8197810]RFR: Test java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html fails on Windows

Hi All Please review a fix for JDK-8197810: https://bugs.openjdk.java.net/browse/JDK-8197810 , Webrev: http://cr.openjdk.java.net/~kaddepalli/8197810/webrev00/ The basic problem is that, the Robot mouse move is moving to position where item 0 is located (which is already selected), and sel

Re: [11][JDK-8197810]RFR: Test java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html fails on Windows

Gentle reminder to review this. Thanks, Krishna From: Krishna Addepalli Sent: Tuesday, May 8, 2018 3:29 PM To: awt-dev@openjdk.java.net Subject: [11][JDK-8197810]RFR: Test java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html fails on Windows Hi All Please review a fix

Re: [11] Review Request: 8204118 [macos] Nonsensical self == [super init] in CFileDialog.m

Looks fine. -Original Message- From: Sergey Bylokhov Sent: Saturday, June 2, 2018 4:41 AM To: awt-dev@openjdk.java.net Subject: [11] Review Request: 8204118 [macos] Nonsensical self == [super init] in CFileDialog.m Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java

Re: [11] Review Request: 8203224 java.awt.desktop.*Event classes could not be instantiated if Desktop feature is not supported

Looks fine. > On 05-Jun-2018, at 2:49 AM, Phil Race wrote: > > +1. > > -phil. > > On 05/24/2018 09:48 PM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk11. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8203224 >> Webrev: http://cr.openjdk.java.net/~serb/8203224/webre

Re: [11] Review Request: 8189604 possible hang in sun.awt.shell.Win32ShellFolder2$KnownFolderDefinition::

Hi Sergey, The fix looks fine. However, I have couple of comments: 1. The variable "result" in Java_sun_awt_shell_Win32ShellFolder2_loadKnownFolders at line 1401 is not initialized. Although it is initialized in the following if condition, I'm not sure when it return false, and lead to a return

Re: [11] Review Request: 8189604 possible hang in sun.awt.shell.Win32ShellFolder2$KnownFolderDefinition::

Hi Sergey, The changes look fine. Thanks, Krishna -Original Message- From: Sergey Bylokhov Sent: Tuesday, June 26, 2018 11:12 AM To: Krishna Addepalli ; awt-dev@openjdk.java.net Subject: Re: [11] Review Request: 8189604 possible hang in sun.awt.shell.Win32ShellFolder2

Re: [11][JDK-8197810]RFR: Test java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html fails on Windows

, selectedIndex); } This is the reason why the test is failing. Hope this clarifies. Thanks, Krishna -Original Message- From: Sergey Bylokhov Sent: Tuesday, May 29, 2018 8:48 PM To: Krishna Addepalli ; awt-dev@openjdk.java.net Subject: Re: [11][JDK-8197810]RFR: Test j

Re: [11][JDK-8197810]RFR: Test java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html fails on Windows

ishna -Original Message- From: Sergey Bylokhov Sent: Wednesday, June 27, 2018 6:05 AM To: Krishna Addepalli ; awt-dev@openjdk.java.net Subject: Re: [11][JDK-8197810]RFR: Test java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html fails on Windows If this was done intentionally t

Re: [11][JDK-8197810]RFR: Test java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html fails on Windows

, 2018 9:27 AM To: Krishna Addepalli ; awt-dev@openjdk.java.net Subject: Re: [11][JDK-8197810]RFR: Test java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html fails on Windows On 26/06/2018 19:40, Krishna Addepalli wrote: > Hi Sergey, > > The test with my changes will run on

Re: [11][JDK-8197810]RFR: Test java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html fails on Windows

ginal Message- From: Sergey Bylokhov Sent: Wednesday, June 27, 2018 12:16 PM To: Krishna Addepalli ; awt-dev@openjdk.java.net Subject: Re: [11][JDK-8197810]RFR: Test java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html fails on Windows > Thanks for the clarification. So, this means

[12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms.

Hi All, Please review a fix for JDK-8014503: https://bugs.openjdk.java.net/browse/JDK-8014503 Webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev00/ On Windows, the default behavior has been changed to not send an ItemEvent, if the same item is selected again, whereas this was

Re: [11] Review Request: 8205588 Deprecate for removal com.sun.awt.SecurityWarning

+1 -Original Message- From: Philip Race Sent: Tuesday, July 3, 2018 12:17 AM To: Sergey Bylokhov Cc: awt-dev@openjdk.java.net Subject: Re: [11] Review Request: 8205588 Deprecate for removal com.sun.awt.SecurityWarning +1 -phil. On 6/24/18, 11:27 PM, Sergey Bylokhov wrote: > Hello. >

Re: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms.

To: Krishna Addepalli ; awt-dev@openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Hi Krishna, Below are the comments on the fix that you made. 1. Based on the getSelectedIndex(), I think the selectedIndex should

Re: [OpenJDK 2D-Dev] [11] Review Request: 8201611 Broken links in java.desktop javadoc

Looks fine -Original Message- From: Phil Race Sent: Monday, July 2, 2018 10:46 PM To: Sergey Bylokhov ; awt-dev@openjdk.java.net; 2d-dev <2d-...@openjdk.java.net> Subject: Re: [OpenJDK 2D-Dev] [11] Review Request: 8201611 Broken links in java.desktop javadoc OK, +1 -phil. On 07/02/

Re: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms.

t: Tuesday, July 3, 2018 1:15 PM To: Shashidhara Veerabhadraiah ; Krishna Addepalli ; awt-dev@openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms. Can we use existing 'skipPostMessage' member for this check instead of

Re: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms.

Hi Prasanta/Sergey, Could you review this ? @Ajit, Shashi - Thanks for your review. Thanks, Krishna From: Ajit Ghaisas Sent: Tuesday, July 3, 2018 3:31 PM To: Krishna Addepalli ; Shashidhara Veerabhadraiah ; awt-dev@openjdk.java.net Subject: RE: [12]RFR : JDK-8014503: AWT

Re: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35

Hi Phil, The changes look fine to me. Great to see the steps that need to be followed for updating png library into UPDATING.txt. I see a small typo on line 19: "handiling". Don’t need a new webrev for this. Thanks, Krishna -Original Message- From: Philip Race Sent: Friday, July 27,

Re: RFR: 8208353: Upgrade JDK 11 to libpng 1.6.35

One more thing, in the UPDATING.txt: In the first line: "TING libpng in OpenJDK". I guess it should have been "UPDATING" ... -Original Message- From: Krishna Addepalli Sent: Friday, July 27, 2018 5:46 PM To: Philip Race ; awt-dev@openjdk.java.net Subject: Re: RFR:

Re: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms.

}); } } Thanks, Krishna -Original Message- From: Sergey Bylokhov Sent: Thursday, July 5, 2018 8:10 PM To: Krishna Addepalli ; Ajit Ghaisas ; Shashidhara Veerabhadraiah ; awt-dev@openjdk.java.net Subject: Re: [12]RFR : JDK-8014503: AWT Choice implementation should be made

Re: [12] Review Request: 8209340 The code which avoids synthetic accessors has become outdated

Hi Sergey, I understand that with the new jep, we no longer need to explicitly write the constructor to avoid the synthetic accessor methods generated by the compiler. AFAIK, each inner class declared results in a class file being generated rather than each default constructor. Could you clari

Re: [12] Review Request: 8209340 The code which avoids synthetic accessors has become outdated

- From: Sergey Bylokhov Sent: Tuesday, August 14, 2018 8:36 AM To: Krishna Addepalli ; awt-dev@openjdk.java.net; swing-...@openjdk.java.net Subject: Re: [12] Review Request: 8209340 The code which avoids synthetic accessors has become outdated On 13/08/2018 19:32, Krishna Addepalli

Re: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms.

t;, but my question is, should I make this change or keep the index based change, since that would keep the implementation also consistent across platforms. Thanks, Krishna -Original Message- From: Sergey Bylokhov Sent: Tuesday, August 14, 2018 7:52 AM To: Krishna Addepalli ; Aj

Re: StackOverflowError happened by TextField.setFont(...)

Hi Ichiroh, I have tried the steps you outlined, but I'm not able to reproduce the issue you are seeing. Could you try with the latest jdk12 repo? Thanks, Krishna -Original Message- From: Ichiroh Takiguchi Sent: Friday, August 24, 2018 1:42 PM To: awt-dev@openjdk.java.net Subject: St

Re: OpenJdk11-28-EA JDialog hanging

Hi Laurent, Thanks for bringing this up. I have fixed a problem in this area JDK-8152974, which is about AWT hang when SequencedEvents arrive out of order. However, the fix was partial, and same problem was reported in JDK8(because of webstart), after it was backported. At that point, the fix wa

Re: StackOverflowError happened by TextField.setFont(...)

d run FontChangeTest > 2. Press "Shuffle" button to top > 3. Change Font size (TextField) "12" to "24" on right-buttom, then > press Enter/Return key >Then above exception will be happened > > Thanks, > > On 2018-08-27 12:55, Krishna Add

Re: OpenJdk11-28-EA JDialog hanging

e = new WindowEvent(this, id); > try { > @SuppressWarnings("unchecked") > Class seqClass = (Class) > Class.forName("java.awt.SequencedEvent"); > Constructor seqConst = > seqClass.getConstructor(AWTEvent.class); >

RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled

Hi All, Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681 Webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/ Please review an enhancement for supporting the logging of Java Access Bridge, so that customers/users facing problems with Accessibility can turn on/off

Re: [12] Review request for JDK-8206392: [macosx] Cycling through windows (JFrames) does not work with keyboard shortcut

Looks fine to me!   Thanks, Krishna   From: Dmitry Markov Sent: Monday, September 10, 2018 6:06 PM To: Manajit Halder Cc: awt-dev@openjdk.java.net Subject: Re: [12] Review request for JDK-8206392: [macosx] Cycling through windows (JFrames) does not work with keyboard shortcut   Hi Manaji

Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled

14, 2018 11:38 AM To: Krishna Addepalli ; awt-dev@openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled One thing, since you are passing va_list as the last parameter, shouldn't all fprintf be actually vfprintf? Regards Pra

Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled

Thanks for the comments. Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev02/ --Krishna From: Prasanta Sadhukhan Sent: Friday, September 14, 2018 3:23 PM To: Krishna Addepalli ; awt-dev@openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge

Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled

Nullptr is the recommended way in modern c++. I thought of changing the other places as well, but wanted to keep the changes minimal, so left them as is. Thanks, Krishna From: Prasanta Sadhukhan Sent: Friday, September 14, 2018 5:48 PM To: Krishna Addepalli ; awt-dev@openjdk.java.net

Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled

anta > On 14-Sep-18 8:33 PM, Krishna Addepalli wrote: >> Nullptr is the recommended way in modern c++. I thought of changing the >> other places as well, but wanted to keep the changes minimal, so left them >> as is. >> >> Thanks, >> Krishna >> >

Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled

it possibly that the > log file will be garbled because of two libraries will print in parallel? > > On 13/09/2018 12:25, Krishna Addepalli wrote: >> Hi All, >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681 >> Webrev: http://cr.openjdk.java.net/~kaddepalli/8

Re: [12]RFR : JDK-8014503: AWT Choice implementation should be made consistent across platforms.

tested it. Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev03/ <http://cr.openjdk.java.net/~kaddepalli/8014503/webrev03/> Thanks, Krishna > On 23-Aug-2018, at 4:34 PM, Sergey Bylokhov > wrote: > > Hi, Krishna. > On 20/08/2018 04:30, Krishna Ad

[12]RFR: [JDK-8074824]: Resolve disabled warnings for libawt_xawt

Hi All, Please review a fix for JDK-8074824: https://bugs.openjdk.java.net/browse/JDK-8074824 Webrev: http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/ Most of the warnings have been fixed for Linux, Mac and Windows. Thanks, Krishna

Re: [12]RFR: [JDK-8074824]: Resolve disabled warnings for libawt_xawt

question about awt_Window.cpp: > > 2150 w = static_cast((rect.right - rect.left) * scaleX / prevScaleX); > 2151 h = static_cast((rect.bottom - rect.top) * scaleY / prevScaleY); > > Are you sure that we need to use "cast" instead of ScaleUp/Down? > > On 29/09/

Re: [12]RFR: [JDK-8074824]: Resolve disabled warnings for libawt_xawt

/unix/native/common/awt/awt_Font.c.udiff.html >>> >>> <http://cr.openjdk.java.net/%7Ekaddepalli/8074824/webrev01/src/java.desktop/unix/native/common/awt/awt_Font.c.udiff.html> >>> >>> why would that not be #ifdef instead ? >>> >>>

Re: OpenJdk11-28-EA JDialog hanging

problem. Then I’ll create a backout bug and push this patch.   Thanks, Krishna   From: Laurent Bourgès Sent: Thursday, September 27, 2018 12:57 PM To: Krishna Addepalli Cc: Phil Race ; Sergey Bylokhov ; awt-dev@openjdk.java.net Subject: Re: OpenJdk11-28-EA JDialog hanging   Any

  1   2   >