From sergey.bylokhov at oracle.com  Mon Apr  3 13:58:38 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 3 Apr 2017 16:58:38 +0300
Subject: <AWT Dev> [9] Review Request: 8177672 DataFlavor.imageFlavor is
 null when the java.desktop module is not resolved
In-Reply-To: <DB3EAB77-3619-474B-B8F8-F51D1F258EFB@oracle.com>
References: <F443E130-493A-4912-A520-9544D5C65D27@oracle.com>
 <21b07f18-3887-9024-0a8e-c115e1e872c3@oracle.com>
 <DB3EAB77-3619-474B-B8F8-F51D1F258EFB@oracle.com>
Message-ID: <E99EEABA-B703-4526-84D0-D9D9E8E1798B@oracle.com>

>> 
>> "Return null if java.awt.Image is not visible, the java.desktop module is not loaded, or the java.desktop module is not in the run-time image."
> 
> This is better.
> 
> Sergey - the ?not readable? part is no longer applicable as reflective access to module is readable by default [1].  We should go through the existing javadoc e.g. MXBean [2] and clean up - that?s a separate issue that we will follow up.

Ok, webrev was updated:
http://cr.openjdk.java.net/~serb/8177672/webrev.01

> 
> Mandy 
> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#ReflectionWithoutReadability <http://openjdk.java.net/projects/jigsaw/spec/issues/#ReflectionWithoutReadability>
> [2] http://download.java.net/java/jdk9/docs/api/javax/management/MXBean.html <http://download.java.net/java/jdk9/docs/api/javax/management/MXBean.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170403/1fa403db/attachment.html>

From Alan.Bateman at oracle.com  Mon Apr  3 14:03:21 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 3 Apr 2017 15:03:21 +0100
Subject: <AWT Dev> [9] Review Request: 8177672 DataFlavor.imageFlavor is
 null when the java.desktop module is not resolved
In-Reply-To: <E99EEABA-B703-4526-84D0-D9D9E8E1798B@oracle.com>
References: <F443E130-493A-4912-A520-9544D5C65D27@oracle.com>
 <21b07f18-3887-9024-0a8e-c115e1e872c3@oracle.com>
 <DB3EAB77-3619-474B-B8F8-F51D1F258EFB@oracle.com>
 <E99EEABA-B703-4526-84D0-D9D9E8E1798B@oracle.com>
Message-ID: <c0358aba-69a6-02ca-3830-521784c1e3fc@oracle.com>



On 03/04/2017 14:58, Sergey Bylokhov wrote:
>>>
>>> "Return null if java.awt.Image is not visible, the java.desktop 
>>> module is not loaded, or the java.desktop module is not in the 
>>> run-time image."
>>
>> This is better.
>>
>> Sergey - the ?not readable? part is no longer applicable as 
>> reflective access to module is readable by default [1].  We should go 
>> through the existing javadoc e.g. MXBean [2] and clean up - that?s a 
>> separate issue that we will follow up.
>
> Ok, webrev was updated:
> http://cr.openjdk.java.net/~serb/8177672/webrev.01 
> <http://cr.openjdk.java.net/%7Eserb/8177672/webrev.01>
>
Looks good to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170403/e6c6833c/attachment-0001.html>

From mandy.chung at oracle.com  Mon Apr  3 14:58:26 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 3 Apr 2017 07:58:26 -0700
Subject: <AWT Dev> [9] Review Request: 8177672 DataFlavor.imageFlavor is
	null when the java.desktop module is not resolved
In-Reply-To: <E99EEABA-B703-4526-84D0-D9D9E8E1798B@oracle.com>
References: <F443E130-493A-4912-A520-9544D5C65D27@oracle.com>
 <21b07f18-3887-9024-0a8e-c115e1e872c3@oracle.com>
 <DB3EAB77-3619-474B-B8F8-F51D1F258EFB@oracle.com>
 <E99EEABA-B703-4526-84D0-D9D9E8E1798B@oracle.com>
Message-ID: <2F9B3FD6-2724-448D-9807-455CA1655B10@oracle.com>


> On Apr 3, 2017, at 6:58 AM, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
> 
>>> 
>>> "Return null if java.awt.Image is not visible, the java.desktop module is not loaded, or the java.desktop module is not in the run-time image."
>> 
>> This is better.
>> 
>> Sergey - the ?not readable? part is no longer applicable as reflective access to module is readable by default [1].  We should go through the existing javadoc e.g. MXBean [2] and clean up - that?s a separate issue that we will follow up.
> 
> Ok, webrev was updated:
> http://cr.openjdk.java.net/~serb/8177672/webrev.01 <http://cr.openjdk.java.net/~serb/8177672/webrev.01>

Looks good.

Mandy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170403/ff8e90d6/attachment.html>

From alexandr.scherbatiy at oracle.com  Tue Apr  4 10:59:56 2017
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Tue, 4 Apr 2017 13:59:56 +0300
Subject: <AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests
 can be improved
In-Reply-To: <44942D18-F153-45A7-B22D-946A52D008BA@oracle.com>
References: <694CFD15-FB7F-4104-905C-54D076D6B33A@oracle.com>
 <41f85a5d-314d-e092-11fd-8537c6d25582@oracle.com>
 <44942D18-F153-45A7-B22D-946A52D008BA@oracle.com>
Message-ID: <03b43451-ba30-0e3c-33ce-7f8b4e0d8b41@oracle.com>

On 3/30/2017 10:27 PM, Sergey Bylokhov wrote:
>> sun.java2d.win.uiScaleX/Y is only applicable to windows which is 
>> likely why the test had
>> @requires (os.family == "windows") even if it was not the right name. 
>> Now you are running unconditionally with those properties on all 
>> platforms which seems to be a waste of time.
> Yes, if we know that uiScaleX/Y are windows specific then 2 modes out 
> of 5 is noop. But I do not like to exclude them, instead I would like 
> to fuzz the tests by supported/unsupported properties, in the same way 
> as 2d-tests are executed using different supported/unsupprted 
> "sun.java2d.XXX" pipelines.
   The test can be separated on two tests: one is Windows specific and 
another is general.

   Thanks,
   Alexandr.
>
>>
>> On 03/30/2017 12:11 PM, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk9.
>>>
>>> Initially I found a typo in the HiDPIRobotMouseClick.java. It contains the ?Dsun.java2d.win.uiScale? option, which should be Dsun.java2d.uiScale or Dsun.java2d.win.uiScaleX/Y.
>>> But when I verified the fix, the test fails if executed w/o any options (my system has 125% DPI).
>>>
>>> So I decided to update it and related HiDPIRobotScreenCaptureTest to validated more modes.
>>>
>>> - Default(w/o options), useful if the system has some default scale.
>>> - scale = 1 is useful when the tests are executed on HiDPI systems.
>>>
>>> I am not sure why these tests sets the Windows L&F because it uses only awt Frame.
>>> I?ll file a separate bug for HiDPIRobotMouseClick.java + 125% DPI.
>>>
>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8177841
>>> Webrev can be found at:http://cr.openjdk.java.net/~serb/8177841/webrev.00
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170404/919cf110/attachment.html>

From semyon.sadetsky at oracle.com  Wed Apr  5 18:25:58 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 5 Apr 2017 11:25:58 -0700
Subject: <AWT Dev> [9] Review request for 8159451: [TEST_BUG]
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java
Message-ID: <a0fe536e-911f-5a18-2e11-51c6ed8ef458@oracle.com>

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8159451

webrev: http://cr.openjdk.java.net/~ssadetsky/8159451/webrev.00/

The timeout is increased.

--Semyon


From philip.race at oracle.com  Wed Apr  5 21:21:11 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 5 Apr 2017 14:21:11 -0700
Subject: <AWT Dev> [9] Review request for 8159451: [TEST_BUG]
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java
In-Reply-To: <a0fe536e-911f-5a18-2e11-51c6ed8ef458@oracle.com>
References: <a0fe536e-911f-5a18-2e11-51c6ed8ef458@oracle.com>
Message-ID: <12e16da4-d106-a527-0fda-3e249029bae7@oracle.com>

No objection per se, but thinking aloud ..
The default jtreg timeout is 2 minutes .. you are upping to 4 minutes.
Can the test be made more efficient, or is that a realistic time based
on what it tests ?

-phil.

On 04/05/2017 11:25 AM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8159451
>
> webrev: http://cr.openjdk.java.net/~ssadetsky/8159451/webrev.00/
>
> The timeout is increased.
>
> --Semyon
>


From yuri.nesterenko at oracle.com  Thu Apr  6 08:32:36 2017
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Thu, 6 Apr 2017 11:32:36 +0300
Subject: <AWT Dev> [9] Review request for 8159451: [TEST_BUG]
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java
In-Reply-To: <12e16da4-d106-a527-0fda-3e249029bae7@oracle.com>
References: <a0fe536e-911f-5a18-2e11-51c6ed8ef458@oracle.com>
 <12e16da4-d106-a527-0fda-3e249029bae7@oracle.com>
Message-ID: <c5f32bae-a7f4-d473-a766-74ab03308501@oracle.com>

Phil,

it's more or less realistic, yes.
It paints various controls, many of them, clicks several times,
than repeats everything again for embedded frame.
On some platforms if you do it too fast,
you just cannot be sure the control is ready to receive a click.

And, my +1 here.

-yan

On 04/06/2017 12:21 AM, Phil Race wrote:
> No objection per se, but thinking aloud ..
> The default jtreg timeout is 2 minutes .. you are upping to 4 minutes.
> Can the test be made more efficient, or is that a realistic time based
> on what it tests ?
>
> -phil.
>
> On 04/05/2017 11:25 AM, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8159451
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8159451/webrev.00/
>>
>> The timeout is increased.
>>
>> --Semyon
>>
>


From semyon.sadetsky at oracle.com  Thu Apr  6 15:49:33 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 6 Apr 2017 08:49:33 -0700
Subject: <AWT Dev> [9] Review request for 8164473: [TEST_BUG] Series of
 modal/focus tests fail always on Unity
Message-ID: <74979096-8ca5-85e2-2cae-044233b31a51@oracle.com>

Hello,

Please review fix for JDK9:

bug:https://bugs.openjdk.java.net/browse/JDK-8164473

webrev: http://cr.openjdk.java.net/~ssadetsky/8164473/webrev.00/

Stability of ModalExcludedWindowClickTest was improved. The rest tests 
mentioned in the bug are stably pass after JDK-8161910 is fixed.

Tested on dual-screen Ubuntu 16.04.

--Semyon


From sergey.bylokhov at oracle.com  Thu Apr  6 16:12:11 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 6 Apr 2017 19:12:11 +0300
Subject: <AWT Dev> [9] Review request for 8164473: [TEST_BUG] Series of
 modal/focus tests fail always on Unity
In-Reply-To: <74979096-8ca5-85e2-2cae-044233b31a51@oracle.com>
References: <74979096-8ca5-85e2-2cae-044233b31a51@oracle.com>
Message-ID: <1A6FFC2F-6D88-429E-98F7-A783F949FC7D@oracle.com>

Hi, Semyon.
I have a few comments:
 - Looks like Applet machinery and html file are unnecessary in the test since it has the main method anyway.
 - "waitTillShown" is not used anymore?
 - The check for ?Mtoolkit? can be removed, this toolkit was removed in jdk7.
 - It will be good to change invokeLater to invokeAndWait, so you will get an exception(if any) immediately.



> 
> bug:https://bugs.openjdk.java.net/browse/JDK-8164473
> 
> webrev: http://cr.openjdk.java.net/~ssadetsky/8164473/webrev.00/
> 
> Stability of ModalExcludedWindowClickTest was improved. The rest tests mentioned in the bug are stably pass after JDK-8161910 is fixed.
> 
> Tested on dual-screen Ubuntu 16.04.
> 
> --Semyon
> 


From sergey.bylokhov at oracle.com  Thu Apr  6 17:57:15 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 6 Apr 2017 20:57:15 +0300
Subject: <AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests
 can be improved
In-Reply-To: <03b43451-ba30-0e3c-33ce-7f8b4e0d8b41@oracle.com>
References: <694CFD15-FB7F-4104-905C-54D076D6B33A@oracle.com>
 <41f85a5d-314d-e092-11fd-8537c6d25582@oracle.com>
 <44942D18-F153-45A7-B22D-946A52D008BA@oracle.com>
 <03b43451-ba30-0e3c-33ce-7f8b4e0d8b41@oracle.com>
Message-ID: <9704F228-F6CD-4DF9-9DA5-02EC124EF1C6@oracle.com>

Here is an updated version:
http://cr.openjdk.java.net/~serb/8177841/webrev.01/ <http://cr.openjdk.java.net/~serb/8177841/webrev.01/>
It will save 5 sec per test, so probably the simpler .00 version can be reevaluated.

> 
> On 3/30/2017 10:27 PM, Sergey Bylokhov wrote:
>>> sun.java2d.win.uiScaleX/Y is only applicable to windows which is likely why the test had 
>>> @requires (os.family == "windows") even if it was not the right name.
>>> 
>>> Now you are running unconditionally with those properties on all platforms which
>>> seems to be a waste of time.
>> Yes, if we know that uiScaleX/Y are windows specific then 2 modes out of 5 is noop. But I do not like to exclude them, instead I would like to fuzz the tests by supported/unsupported properties, in the same way as 2d-tests are executed using different supported/unsupprted "sun.java2d.XXX" pipelines.
>   The test can be separated on two tests: one is Windows specific and another is general.
> 
>   Thanks,
>   Alexandr.
>> 
>>> 
>>> On 03/30/2017 12:11 PM, Sergey Bylokhov wrote:
>>>> Hello,
>>>> Please review the fix for jdk9.
>>>> 
>>>> Initially I found a typo in the HiDPIRobotMouseClick.java. It contains the ?Dsun.java2d.win.uiScale? option, which should be Dsun.java2d.uiScale or Dsun.java2d.win.uiScaleX/Y.
>>>> But when I verified the fix, the test fails if executed w/o any options (my system has 125% DPI).
>>>> 
>>>> So I decided to update it and related HiDPIRobotScreenCaptureTest to validated more modes.
>>>> 
>>>> - Default(w/o options), useful if the system has some default scale.
>>>> - scale = 1 is useful when the tests are executed on HiDPI systems.
>>>> 
>>>> I am not sure why these tests sets the Windows L&F because it uses only awt Frame.  
>>>> I?ll file a separate bug for HiDPIRobotMouseClick.java + 125% DPI.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177841 <https://bugs.openjdk.java.net/browse/JDK-8177841>
>>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8177841/webrev.00 <http://cr.openjdk.java.net/%7Eserb/8177841/webrev.00>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170406/b0ff0009/attachment.html>

From philip.race at oracle.com  Thu Apr  6 18:07:02 2017
From: philip.race at oracle.com (Phil Race)
Date: Thu, 6 Apr 2017 11:07:02 -0700
Subject: <AWT Dev> [9] Review request for 8159451: [TEST_BUG]
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java
In-Reply-To: <c5f32bae-a7f4-d473-a766-74ab03308501@oracle.com>
References: <a0fe536e-911f-5a18-2e11-51c6ed8ef458@oracle.com>
 <12e16da4-d106-a527-0fda-3e249029bae7@oracle.com>
 <c5f32bae-a7f4-d473-a766-74ab03308501@oracle.com>
Message-ID: <6d0dd6eb-02ba-7e32-1956-3be0082a30ff@oracle.com>


Ok +1 from me then.

-phil.

On 04/06/2017 01:32 AM, Yuri Nesterenko wrote:
> Phil,
>
> it's more or less realistic, yes.
> It paints various controls, many of them, clicks several times,
> than repeats everything again for embedded frame.
> On some platforms if you do it too fast,
> you just cannot be sure the control is ready to receive a click.
>
> And, my +1 here.
>
> -yan
>
> On 04/06/2017 12:21 AM, Phil Race wrote:
>> No objection per se, but thinking aloud ..
>> The default jtreg timeout is 2 minutes .. you are upping to 4 minutes.
>> Can the test be made more efficient, or is that a realistic time based
>> on what it tests ?
>>
>> -phil.
>>
>> On 04/05/2017 11:25 AM, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8159451
>>>
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8159451/webrev.00/
>>>
>>> The timeout is increased.
>>>
>>> --Semyon
>>>
>>
>


From sergey.bylokhov at oracle.com  Thu Apr  6 18:34:25 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 6 Apr 2017 21:34:25 +0300
Subject: <AWT Dev> [9] Review request for 8159451: [TEST_BUG]
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java
In-Reply-To: <c5f32bae-a7f4-d473-a766-74ab03308501@oracle.com>
References: <a0fe536e-911f-5a18-2e11-51c6ed8ef458@oracle.com>
 <12e16da4-d106-a527-0fda-3e249029bae7@oracle.com>
 <c5f32bae-a7f4-d473-a766-74ab03308501@oracle.com>
Message-ID: <A25D585D-17E7-42DE-9CF8-C9C31614D334@oracle.com>


> 6 ???. 2017 ?., ? 11:32, Yuri Nesterenko <yuri.nesterenko at oracle.com> ???????(?):
> 
> Phil,
> 
> it's more or less realistic, yes.
> It paints various controls, many of them, clicks several times,
> than repeats everything again for embedded frame.
> On some platforms if you do it too fast,
> you just cannot be sure the control is ready to receive a click.

But isn?t 500 ms is a quite big value for the robot autodelay?

> 
> And, my +1 here.
> 
> -yan
> 
> On 04/06/2017 12:21 AM, Phil Race wrote:
>> No objection per se, but thinking aloud ..
>> The default jtreg timeout is 2 minutes .. you are upping to 4 minutes.
>> Can the test be made more efficient, or is that a realistic time based
>> on what it tests ?
>> 
>> -phil.
>> 
>> On 04/05/2017 11:25 AM, Semyon Sadetsky wrote:
>>> Hello,
>>> 
>>> Please review fix for JDK9:
>>> 
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8159451
>>> 
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8159451/webrev.00/
>>> 
>>> The timeout is increased.
>>> 
>>> --Semyon
>>> 
>> 
> 


From semyon.sadetsky at oracle.com  Thu Apr  6 19:46:56 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 6 Apr 2017 12:46:56 -0700
Subject: <AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests
 can be improved
In-Reply-To: <9704F228-F6CD-4DF9-9DA5-02EC124EF1C6@oracle.com>
References: <694CFD15-FB7F-4104-905C-54D076D6B33A@oracle.com>
 <41f85a5d-314d-e092-11fd-8537c6d25582@oracle.com>
 <44942D18-F153-45A7-B22D-946A52D008BA@oracle.com>
 <03b43451-ba30-0e3c-33ce-7f8b4e0d8b41@oracle.com>
 <9704F228-F6CD-4DF9-9DA5-02EC124EF1C6@oracle.com>
Message-ID: <03b9c673-59db-6550-ce72-8b7599df9908@oracle.com>

Sergey, could you replace CountDownLatch::await() call with its limited 
wait time analog. If the test fails it blocks execution for 2 minutes in 
the current version.

--Semyon


On 04/06/2017 10:57 AM, Sergey Bylokhov wrote:
> Here is an updated version:
> http://cr.openjdk.java.net/~serb/8177841/webrev.01/ 
> <http://cr.openjdk.java.net/%7Eserb/8177841/webrev.01/>
> It will save 5 sec per test, so probably the simpler .00 version can 
> be reevaluated.
>
>>
>> On 3/30/2017 10:27 PM, Sergey Bylokhov wrote:
>>>> sun.java2d.win.uiScaleX/Y is only applicable to windows which is 
>>>> likely why the test had
>>>> @requires (os.family == "windows") even if it was not the right 
>>>> name. Now you are running unconditionally with those properties on 
>>>> all platforms which seems to be a waste of time.
>>> Yes, if we know that uiScaleX/Y are windows specific then 2 modes 
>>> out of 5 is noop. But I do not like to exclude them, instead I would 
>>> like to fuzz the tests by supported/unsupported properties, in the 
>>> same way as 2d-tests are executed using different 
>>> supported/unsupprted "sun.java2d.XXX" pipelines.
>>   The test can be separated on two tests: one is Windows specific and 
>> another is general.
>>
>>   Thanks,
>>   Alexandr.
>>>
>>>>
>>>> On 03/30/2017 12:11 PM, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk9.
>>>>>
>>>>> Initially I found a typo in the HiDPIRobotMouseClick.java. It contains the ?Dsun.java2d.win.uiScale? option, which should be Dsun.java2d.uiScale or Dsun.java2d.win.uiScaleX/Y.
>>>>> But when I verified the fix, the test fails if executed w/o any options (my system has 125% DPI).
>>>>>
>>>>> So I decided to update it and related HiDPIRobotScreenCaptureTest to validated more modes.
>>>>>
>>>>> - Default(w/o options), useful if the system has some default scale.
>>>>> - scale = 1 is useful when the tests are executed on HiDPI systems.
>>>>>
>>>>> I am not sure why these tests sets the Windows L&F because it uses only awt Frame.
>>>>> I?ll file a separate bug for HiDPIRobotMouseClick.java + 125% DPI.
>>>>>
>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8177841
>>>>> Webrev can be found at:http://cr.openjdk.java.net/~serb/8177841/webrev.00
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170406/419bbb91/attachment.html>

From sergey.bylokhov at oracle.com  Thu Apr  6 20:09:35 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 6 Apr 2017 23:09:35 +0300
Subject: <AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests
 can be improved
In-Reply-To: <03b9c673-59db-6550-ce72-8b7599df9908@oracle.com>
References: <694CFD15-FB7F-4104-905C-54D076D6B33A@oracle.com>
 <41f85a5d-314d-e092-11fd-8537c6d25582@oracle.com>
 <44942D18-F153-45A7-B22D-946A52D008BA@oracle.com>
 <03b43451-ba30-0e3c-33ce-7f8b4e0d8b41@oracle.com>
 <9704F228-F6CD-4DF9-9DA5-02EC124EF1C6@oracle.com>
 <03b9c673-59db-6550-ce72-8b7599df9908@oracle.com>
Message-ID: <58E1D70B-F6C2-4EB4-B953-282BCE237C88@oracle.com>

> Sergey, could you replace CountDownLatch::await() call with its limited wait time analog. If the test fails it blocks execution for 2 minutes in the current version.
> 
2 minutes is a default time out for jtreg tests, if something goes wrong like something hangs, then we wait 2 minutes and interrupt the test.
After interruption the jtreg will generate the dump for all threads which can be useful to check why the event was not generated by the robot.

> 
> On 04/06/2017 10:57 AM, Sergey Bylokhov wrote:
>> Here is an updated version:
>> http://cr.openjdk.java.net/~serb/8177841/webrev.01/ <http://cr.openjdk.java.net/%7Eserb/8177841/webrev.01/>
>> It will save 5 sec per test, so probably the simpler .00 version can be reevaluated.
>> 
>>> 
>>> On 3/30/2017 10:27 PM, Sergey Bylokhov wrote:
>>>>> sun.java2d.win.uiScaleX/Y is only applicable to windows which is likely why the test had 
>>>>> @requires (os.family == "windows") even if it was not the right name.
>>>>> 
>>>>> Now you are running unconditionally with those properties on all platforms which
>>>>> seems to be a waste of time.
>>>> Yes, if we know that uiScaleX/Y are windows specific then 2 modes out of 5 is noop. But I do not like to exclude them, instead I would like to fuzz the tests by supported/unsupported properties, in the same way as 2d-tests are executed using different supported/unsupprted "sun.java2d.XXX" pipelines.
>>>   The test can be separated on two tests: one is Windows specific and another is general.
>>> 
>>>   Thanks,
>>>   Alexandr.
>>>> 
>>>>> 
>>>>> On 03/30/2017 12:11 PM, Sergey Bylokhov wrote:
>>>>>> Hello,
>>>>>> Please review the fix for jdk9.
>>>>>> 
>>>>>> Initially I found a typo in the HiDPIRobotMouseClick.java. It contains the ?Dsun.java2d.win.uiScale? option, which should be Dsun.java2d.uiScale or Dsun.java2d.win.uiScaleX/Y.
>>>>>> But when I verified the fix, the test fails if executed w/o any options (my system has 125% DPI).
>>>>>> 
>>>>>> So I decided to update it and related HiDPIRobotScreenCaptureTest to validated more modes.
>>>>>> 
>>>>>> - Default(w/o options), useful if the system has some default scale.
>>>>>> - scale = 1 is useful when the tests are executed on HiDPI systems.
>>>>>> 
>>>>>> I am not sure why these tests sets the Windows L&F because it uses only awt Frame.  
>>>>>> I?ll file a separate bug for HiDPIRobotMouseClick.java + 125% DPI.
>>>>>> 
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177841 <https://bugs.openjdk.java.net/browse/JDK-8177841>
>>>>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8177841/webrev.00 <http://cr.openjdk.java.net/%7Eserb/8177841/webrev.00>
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170406/e31f9071/attachment-0001.html>

From semyon.sadetsky at oracle.com  Thu Apr  6 20:26:37 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 6 Apr 2017 13:26:37 -0700
Subject: <AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests
 can be improved
In-Reply-To: <58E1D70B-F6C2-4EB4-B953-282BCE237C88@oracle.com>
References: <694CFD15-FB7F-4104-905C-54D076D6B33A@oracle.com>
 <41f85a5d-314d-e092-11fd-8537c6d25582@oracle.com>
 <44942D18-F153-45A7-B22D-946A52D008BA@oracle.com>
 <03b43451-ba30-0e3c-33ce-7f8b4e0d8b41@oracle.com>
 <9704F228-F6CD-4DF9-9DA5-02EC124EF1C6@oracle.com>
 <03b9c673-59db-6550-ce72-8b7599df9908@oracle.com>
 <58E1D70B-F6C2-4EB4-B953-282BCE237C88@oracle.com>
Message-ID: <bbe34493-804b-2b4c-2707-32519a432939@oracle.com>

On 04/06/2017 01:09 PM, Sergey Bylokhov wrote:
>>
>> Sergey, could you replace CountDownLatch::await() call with its 
>> limited wait time analog. If the test fails it blocks execution for 2 
>> minutes in the current version.
>>
> 2 minutes is a default time out for jtreg tests, if something goes 
> wrong like something hangs, then we wait 2 minutes and interrupt the test.
> After interruption the jtreg will generate the dump for all threads 
> which can be useful to check why the event was not generated by the robot.
You are able to print out this useful information after timeout in the 
catch block. I would prefer to avoid any infinite waiting because if the 
listener is not triggered in several second it will unlikely be 
triggered at all. But if a number of such tests fails for some reason 
the execution time becomes so long that the test report cannot be 
obtained in a reasonable time.
>
>>
>> On 04/06/2017 10:57 AM, Sergey Bylokhov wrote:
>>> Here is an updated version:
>>> http://cr.openjdk.java.net/~serb/8177841/webrev.01/ 
>>> <http://cr.openjdk.java.net/%7Eserb/8177841/webrev.01/>
>>> It will save 5 sec per test, so probably the simpler .00 version can 
>>> be reevaluated.
>>>
>>>>
>>>> On 3/30/2017 10:27 PM, Sergey Bylokhov wrote:
>>>>>> sun.java2d.win.uiScaleX/Y is only applicable to windows which is 
>>>>>> likely why the test had
>>>>>> @requires (os.family == "windows") even if it was not the right 
>>>>>> name. Now you are running unconditionally with those properties 
>>>>>> on all platforms which seems to be a waste of time.
>>>>> Yes, if we know that uiScaleX/Y are windows specific then 2 modes 
>>>>> out of 5 is noop. But I do not like to exclude them, instead I 
>>>>> would like to fuzz the tests by supported/unsupported properties, 
>>>>> in the same way as 2d-tests are executed using different 
>>>>> supported/unsupprted "sun.java2d.XXX" pipelines.
>>>>   The test can be separated on two tests: one is Windows specific 
>>>> and another is general.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>>
>>>>>>
>>>>>> On 03/30/2017 12:11 PM, Sergey Bylokhov wrote:
>>>>>>> Hello,
>>>>>>> Please review the fix for jdk9.
>>>>>>>
>>>>>>> Initially I found a typo in the HiDPIRobotMouseClick.java. It contains the ?Dsun.java2d.win.uiScale? option, which should be Dsun.java2d.uiScale or Dsun.java2d.win.uiScaleX/Y.
>>>>>>> But when I verified the fix, the test fails if executed w/o any options (my system has 125% DPI).
>>>>>>>
>>>>>>> So I decided to update it and related HiDPIRobotScreenCaptureTest to validated more modes.
>>>>>>>
>>>>>>> - Default(w/o options), useful if the system has some default scale.
>>>>>>> - scale = 1 is useful when the tests are executed on HiDPI systems.
>>>>>>>
>>>>>>> I am not sure why these tests sets the Windows L&F because it uses only awt Frame.
>>>>>>> I?ll file a separate bug for HiDPIRobotMouseClick.java + 125% DPI.
>>>>>>>
>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8177841
>>>>>>> Webrev can be found at:http://cr.openjdk.java.net/~serb/8177841/webrev.00
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170406/1e94c622/attachment.html>

From semyon.sadetsky at oracle.com  Fri Apr  7 00:51:33 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 6 Apr 2017 17:51:33 -0700
Subject: <AWT Dev> [9] Review request for 8164469: [TEST_BUG] Unity,
 java/awt/MouseInfo/JContainerMousePositionTest.java
Message-ID: <66ec0bc3-82c7-6fe1-b67c-04eca0ca84eb@oracle.com>

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8164469

webrev: http://cr.openjdk.java.net/~ssadetsky/8164469/webrev.00/

The patch fixes test coordinate calculations relatively to frame screen 
position which do not take into account frame insets.

--Semyon


From yuri.nesterenko at oracle.com  Fri Apr  7 08:43:02 2017
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Fri, 7 Apr 2017 11:43:02 +0300
Subject: <AWT Dev> [9] Review request for 8164469: [TEST_BUG] Unity,
 java/awt/MouseInfo/JContainerMousePositionTest.java
In-Reply-To: <66ec0bc3-82c7-6fe1-b67c-04eca0ca84eb@oracle.com>
References: <66ec0bc3-82c7-6fe1-b67c-04eca0ca84eb@oracle.com>
Message-ID: <b5759b66-4936-4f29-d758-8073ca1ca320@oracle.com>

I tried it with b159 on Unity a dozen times in a loop: works OK

So +1

-yan

On 04/07/2017 03:51 AM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8164469
>
> webrev: http://cr.openjdk.java.net/~ssadetsky/8164469/webrev.00/
>
> The patch fixes test coordinate calculations relatively to frame screen
> position which do not take into account frame insets.
>
> --Semyon
>


From sergey.bylokhov at oracle.com  Fri Apr  7 11:42:17 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 7 Apr 2017 14:42:17 +0300
Subject: <AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests
 can be improved
In-Reply-To: <bbe34493-804b-2b4c-2707-32519a432939@oracle.com>
References: <694CFD15-FB7F-4104-905C-54D076D6B33A@oracle.com>
 <41f85a5d-314d-e092-11fd-8537c6d25582@oracle.com>
 <44942D18-F153-45A7-B22D-946A52D008BA@oracle.com>
 <03b43451-ba30-0e3c-33ce-7f8b4e0d8b41@oracle.com>
 <9704F228-F6CD-4DF9-9DA5-02EC124EF1C6@oracle.com>
 <03b9c673-59db-6550-ce72-8b7599df9908@oracle.com>
 <58E1D70B-F6C2-4EB4-B953-282BCE237C88@oracle.com>
 <bbe34493-804b-2b4c-2707-32519a432939@oracle.com>
Message-ID: <1D6419F2-4F6E-42ED-AB49-735D62031359@oracle.com>


> 6 ???. 2017 ?., ? 23:26, Semyon Sadetsky <semyon.sadetsky at oracle.com> ???????(?):
> 
> On 04/06/2017 01:09 PM, Sergey Bylokhov wrote:
>>> Sergey, could you replace CountDownLatch::await() call with its limited wait time analog. If the test fails it blocks execution for 2 minutes in the current version.
>>> 
>> 2 minutes is a default time out for jtreg tests, if something goes wrong like something hangs, then we wait 2 minutes and interrupt the test.
>> After interruption the jtreg will generate the dump for all threads which can be useful to check why the event was not generated by the robot.
> You are able to print out this useful information after timeout in the catch block.

We already have a mechanism which kills the tests after timeout, we also have a default timeout of 2 minutes.
I am not sure how to get dump of all threads from the catch block.

> I would prefer to avoid any infinite waiting because if the listener is not triggered in several second it will unlikely be triggered at all. But if a number of such tests fails for some reason the execution time becomes so long that the test report cannot be obtained in a reasonable time.
>> 
>>> 
>>> On 04/06/2017 10:57 AM, Sergey Bylokhov wrote:
>>>> Here is an updated version:
>>>> http://cr.openjdk.java.net/~serb/8177841/webrev.01/ <http://cr.openjdk.java.net/%7Eserb/8177841/webrev.01/>
>>>> It will save 5 sec per test, so probably the simpler .00 version can be reevaluated.
>>>> 
>>>>> 
>>>>> On 3/30/2017 10:27 PM, Sergey Bylokhov wrote:
>>>>>>> sun.java2d.win.uiScaleX/Y is only applicable to windows which is likely why the test had 
>>>>>>> @requires (os.family == "windows") even if it was not the right name.
>>>>>>> 
>>>>>>> Now you are running unconditionally with those properties on all platforms which
>>>>>>> seems to be a waste of time.
>>>>>> Yes, if we know that uiScaleX/Y are windows specific then 2 modes out of 5 is noop. But I do not like to exclude them, instead I would like to fuzz the tests by supported/unsupported properties, in the same way as 2d-tests are executed using different supported/unsupprted "sun.java2d.XXX" pipelines.
>>>>>   The test can be separated on two tests: one is Windows specific and another is general.
>>>>> 
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>> 
>>>>>>> 
>>>>>>> On 03/30/2017 12:11 PM, Sergey Bylokhov wrote:
>>>>>>>> Hello,
>>>>>>>> Please review the fix for jdk9.
>>>>>>>> 
>>>>>>>> Initially I found a typo in the HiDPIRobotMouseClick.java. It contains the ?Dsun.java2d.win.uiScale? option, which should be Dsun.java2d.uiScale or Dsun.java2d.win.uiScaleX/Y.
>>>>>>>> But when I verified the fix, the test fails if executed w/o any options (my system has 125% DPI).
>>>>>>>> 
>>>>>>>> So I decided to update it and related HiDPIRobotScreenCaptureTest to validated more modes.
>>>>>>>> 
>>>>>>>> - Default(w/o options), useful if the system has some default scale.
>>>>>>>> - scale = 1 is useful when the tests are executed on HiDPI systems.
>>>>>>>> 
>>>>>>>> I am not sure why these tests sets the Windows L&F because it uses only awt Frame.  
>>>>>>>> I?ll file a separate bug for HiDPIRobotMouseClick.java + 125% DPI.
>>>>>>>> 
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177841 <https://bugs.openjdk.java.net/browse/JDK-8177841>
>>>>>>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8177841/webrev.00 <http://cr.openjdk.java.net/%7Eserb/8177841/webrev.00>
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170407/cec90388/attachment-0001.html>

From sergey.bylokhov at oracle.com  Fri Apr  7 12:11:06 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 7 Apr 2017 15:11:06 +0300
Subject: <AWT Dev> [9] Review request for 8164469: [TEST_BUG] Unity,
 java/awt/MouseInfo/JContainerMousePositionTest.java
In-Reply-To: <b5759b66-4936-4f29-d758-8073ca1ca320@oracle.com>
References: <66ec0bc3-82c7-6fe1-b67c-04eca0ca84eb@oracle.com>
 <b5759b66-4936-4f29-d758-8073ca1ca320@oracle.com>
Message-ID: <5F929E3C-32B9-40E8-96C2-67E56E1C27C0@oracle.com>


> I tried it with b159 on Unity a dozen times in a loop: works OK
> 
> So +1

Looks fine.

> 
> -yan
> 
> On 04/07/2017 03:51 AM, Semyon Sadetsky wrote:
>> Hello,
>> 
>> Please review fix for JDK9:
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8164469
>> 
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8164469/webrev.00/
>> 
>> The patch fixes test coordinate calculations relatively to frame screen
>> position which do not take into account frame insets.
>> 
>> --Semyon
>> 
> 


From semyon.sadetsky at oracle.com  Fri Apr  7 14:59:54 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 7 Apr 2017 07:59:54 -0700
Subject: <AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests
 can be improved
In-Reply-To: <1D6419F2-4F6E-42ED-AB49-735D62031359@oracle.com>
References: <694CFD15-FB7F-4104-905C-54D076D6B33A@oracle.com>
 <41f85a5d-314d-e092-11fd-8537c6d25582@oracle.com>
 <44942D18-F153-45A7-B22D-946A52D008BA@oracle.com>
 <03b43451-ba30-0e3c-33ce-7f8b4e0d8b41@oracle.com>
 <9704F228-F6CD-4DF9-9DA5-02EC124EF1C6@oracle.com>
 <03b9c673-59db-6550-ce72-8b7599df9908@oracle.com>
 <58E1D70B-F6C2-4EB4-B953-282BCE237C88@oracle.com>
 <bbe34493-804b-2b4c-2707-32519a432939@oracle.com>
 <1D6419F2-4F6E-42ED-AB49-735D62031359@oracle.com>
Message-ID: <783f239a-b57d-d7f3-e243-96ffb15dd1b0@oracle.com>

On 04/07/2017 04:42 AM, Sergey Bylokhov wrote:

>
>> 6 ???. 2017 ?., ? 23:26, Semyon Sadetsky <semyon.sadetsky at oracle.com 
>> <mailto:semyon.sadetsky at oracle.com>> ???????(?):
>>
>> On 04/06/2017 01:09 PM, Sergey Bylokhov wrote:
>>>>
>>>> Sergey, could you replace CountDownLatch::await() call with its 
>>>> limited wait time analog. If the test fails it blocks execution for 
>>>> 2 minutes in the current version.
>>>>
>>> 2 minutes is a default time out for jtreg tests, if something goes 
>>> wrong like something hangs, then we wait 2 minutes and interrupt the 
>>> test.
>>> After interruption the jtreg will generate the dump for all threads 
>>> which can be useful to check why the event was not generated by the 
>>> robot.
>> You are able to print out this useful information after timeout in 
>> the catch block.
>
> We already have a mechanism which kills the tests after timeout, we 
> also have a default timeout of 2 minutes.
> I am not sure how to get dump of all threads from the catch block.
But shouldn't the time frame when a mouse click may come be limited? 
Will it be correct when the click triggered after 2 minutes delay makes 
the test passed anyway?
>
>> I would prefer to avoid any infinite waiting because if the listener 
>> is not triggered in several second it will unlikely be triggered at 
>> all. But if a number of such tests fails for some reason the 
>> execution time becomes so long that the test report cannot be 
>> obtained in a reasonable time.
>>>
>>>>
>>>> On 04/06/2017 10:57 AM, Sergey Bylokhov wrote:
>>>>> Here is an updated version:
>>>>> http://cr.openjdk.java.net/~serb/8177841/webrev.01/ 
>>>>> <http://cr.openjdk.java.net/%7Eserb/8177841/webrev.01/>
>>>>> It will save 5 sec per test, so probably the simpler .00 version 
>>>>> can be reevaluated.
>>>>>
>>>>>>
>>>>>> On 3/30/2017 10:27 PM, Sergey Bylokhov wrote:
>>>>>>>> sun.java2d.win.uiScaleX/Y is only applicable to windows which 
>>>>>>>> is likely why the test had
>>>>>>>> @requires (os.family == "windows") even if it was not the right 
>>>>>>>> name. Now you are running unconditionally with those properties 
>>>>>>>> on all platforms which seems to be a waste of time.
>>>>>>> Yes, if we know that uiScaleX/Y are windows specific then 2 
>>>>>>> modes out of 5 is noop. But I do not like to exclude them, 
>>>>>>> instead I would like to fuzz the tests by supported/unsupported 
>>>>>>> properties, in the same way as 2d-tests are executed using 
>>>>>>> different supported/unsupprted "sun.java2d.XXX" pipelines.
>>>>>>   The test can be separated on two tests: one is Windows specific 
>>>>>> and another is general.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>>
>>>>>>>>
>>>>>>>> On 03/30/2017 12:11 PM, Sergey Bylokhov wrote:
>>>>>>>>> Hello,
>>>>>>>>> Please review the fix for jdk9.
>>>>>>>>>
>>>>>>>>> Initially I found a typo in the HiDPIRobotMouseClick.java. It contains the ?Dsun.java2d.win.uiScale? option, which should be Dsun.java2d.uiScale or Dsun.java2d.win.uiScaleX/Y.
>>>>>>>>> But when I verified the fix, the test fails if executed w/o any options (my system has 125% DPI).
>>>>>>>>>
>>>>>>>>> So I decided to update it and related HiDPIRobotScreenCaptureTest to validated more modes.
>>>>>>>>>
>>>>>>>>> - Default(w/o options), useful if the system has some default scale.
>>>>>>>>> - scale = 1 is useful when the tests are executed on HiDPI systems.
>>>>>>>>>
>>>>>>>>> I am not sure why these tests sets the Windows L&F because it uses only awt Frame.
>>>>>>>>> I?ll file a separate bug for HiDPIRobotMouseClick.java + 125% DPI.
>>>>>>>>>
>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8177841
>>>>>>>>> Webrev can be found at:http://cr.openjdk.java.net/~serb/8177841/webrev.00
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170407/7a72f406/attachment.html>

From sergey.bylokhov at oracle.com  Fri Apr  7 17:42:59 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 7 Apr 2017 20:42:59 +0300
Subject: <AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests
 can be improved
In-Reply-To: <783f239a-b57d-d7f3-e243-96ffb15dd1b0@oracle.com>
References: <694CFD15-FB7F-4104-905C-54D076D6B33A@oracle.com>
 <41f85a5d-314d-e092-11fd-8537c6d25582@oracle.com>
 <44942D18-F153-45A7-B22D-946A52D008BA@oracle.com>
 <03b43451-ba30-0e3c-33ce-7f8b4e0d8b41@oracle.com>
 <9704F228-F6CD-4DF9-9DA5-02EC124EF1C6@oracle.com>
 <03b9c673-59db-6550-ce72-8b7599df9908@oracle.com>
 <58E1D70B-F6C2-4EB4-B953-282BCE237C88@oracle.com>
 <bbe34493-804b-2b4c-2707-32519a432939@oracle.com>
 <1D6419F2-4F6E-42ED-AB49-735D62031359@oracle.com>
 <783f239a-b57d-d7f3-e243-96ffb15dd1b0@oracle.com>
Message-ID: <05895DD4-DE43-4BF2-998B-372EBD94FDBF@oracle.com>

>> 
>> We already have a mechanism which kills the tests after timeout, we also have a default timeout of 2 minutes.
>> I am not sure how to get dump of all threads from the catch block.
> But shouldn't the time frame when a mouse click may come be limited? Will it be correct when the click triggered after 2 minutes delay makes the test passed anyway?

If timeout will occur and the test still was not complete, then it will be killed, all frames will be closed, the dump of all threads will be generated. So the test cannot pass after timeout.

>> 
>>> I would prefer to avoid any infinite waiting because if the listener is not triggered in several second it will unlikely be triggered at all. But if a number of such tests fails for some reason the execution time becomes so long that the test report cannot be obtained in a reasonable time.
>>>> 
>>>>> 
>>>>> On 04/06/2017 10:57 AM, Sergey Bylokhov wrote:
>>>>>> Here is an updated version:
>>>>>> http://cr.openjdk.java.net/~serb/8177841/webrev.01/ <http://cr.openjdk.java.net/%7Eserb/8177841/webrev.01/>
>>>>>> It will save 5 sec per test, so probably the simpler .00 version can be reevaluated.
>>>>>> 
>>>>>>> 
>>>>>>> On 3/30/2017 10:27 PM, Sergey Bylokhov wrote:
>>>>>>>>> sun.java2d.win.uiScaleX/Y is only applicable to windows which is likely why the test had 
>>>>>>>>> @requires (os.family == "windows") even if it was not the right name.
>>>>>>>>> 
>>>>>>>>> Now you are running unconditionally with those properties on all platforms which
>>>>>>>>> seems to be a waste of time.
>>>>>>>> Yes, if we know that uiScaleX/Y are windows specific then 2 modes out of 5 is noop. But I do not like to exclude them, instead I would like to fuzz the tests by supported/unsupported properties, in the same way as 2d-tests are executed using different supported/unsupprted "sun.java2d.XXX" pipelines.
>>>>>>>   The test can be separated on two tests: one is Windows specific and another is general.
>>>>>>> 
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 03/30/2017 12:11 PM, Sergey Bylokhov wrote:
>>>>>>>>>> Hello,
>>>>>>>>>> Please review the fix for jdk9.
>>>>>>>>>> 
>>>>>>>>>> Initially I found a typo in the HiDPIRobotMouseClick.java. It contains the ?Dsun.java2d.win.uiScale? option, which should be Dsun.java2d.uiScale or Dsun.java2d.win.uiScaleX/Y.
>>>>>>>>>> But when I verified the fix, the test fails if executed w/o any options (my system has 125% DPI).
>>>>>>>>>> 
>>>>>>>>>> So I decided to update it and related HiDPIRobotScreenCaptureTest to validated more modes.
>>>>>>>>>> 
>>>>>>>>>> - Default(w/o options), useful if the system has some default scale.
>>>>>>>>>> - scale = 1 is useful when the tests are executed on HiDPI systems.
>>>>>>>>>> 
>>>>>>>>>> I am not sure why these tests sets the Windows L&F because it uses only awt Frame.  
>>>>>>>>>> I?ll file a separate bug for HiDPIRobotMouseClick.java + 125% DPI.
>>>>>>>>>> 
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177841 <https://bugs.openjdk.java.net/browse/JDK-8177841>
>>>>>>>>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8177841/webrev.00 <http://cr.openjdk.java.net/%7Eserb/8177841/webrev.00>
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170407/9e5b7ed4/attachment-0001.html>

From semyon.sadetsky at oracle.com  Fri Apr  7 21:48:44 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 7 Apr 2017 14:48:44 -0700
Subject: <AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests
 can be improved
In-Reply-To: <05895DD4-DE43-4BF2-998B-372EBD94FDBF@oracle.com>
References: <694CFD15-FB7F-4104-905C-54D076D6B33A@oracle.com>
 <41f85a5d-314d-e092-11fd-8537c6d25582@oracle.com>
 <44942D18-F153-45A7-B22D-946A52D008BA@oracle.com>
 <03b43451-ba30-0e3c-33ce-7f8b4e0d8b41@oracle.com>
 <9704F228-F6CD-4DF9-9DA5-02EC124EF1C6@oracle.com>
 <03b9c673-59db-6550-ce72-8b7599df9908@oracle.com>
 <58E1D70B-F6C2-4EB4-B953-282BCE237C88@oracle.com>
 <bbe34493-804b-2b4c-2707-32519a432939@oracle.com>
 <1D6419F2-4F6E-42ED-AB49-735D62031359@oracle.com>
 <783f239a-b57d-d7f3-e243-96ffb15dd1b0@oracle.com>
 <05895DD4-DE43-4BF2-998B-372EBD94FDBF@oracle.com>
Message-ID: <eb76e346-faf7-6e1f-e642-48dbb3197411@oracle.com>

On 04/07/2017 10:42 AM, Sergey Bylokhov wrote:

>>>
>>> We already have a mechanism which kills the tests after timeout, we 
>>> also have a default timeout of 2 minutes.
>>> I am not sure how to get dump of all threads from the catch block.
>> But shouldn't the time frame when a mouse click may come be limited? 
>> Will it be correct when the click triggered after 2 minutes delay 
>> makes the test passed anyway?
>
> If timeout will occur and the test still was not complete, then it 
> will be killed, all frames will be closed, the dump of all threads 
> will be generated. So the test cannot pass after timeout.
I meant when the listener is triggered right before the 2 minutes 
timeout, for example in 1 minute 59 seconds. In the current logic the 
test passes in this case and no dumps were generated for any thread. But 
actually this means an issue because event shouldn't be delayed for that 
amount of time or this event is not generated by the test.
>
>>>
>>>> I would prefer to avoid any infinite waiting because if the 
>>>> listener is not triggered in several second it will unlikely be 
>>>> triggered at all. But if a number of such tests fails for some 
>>>> reason the execution time becomes so long that the test report 
>>>> cannot be obtained in a reasonable time.
>>>>>
>>>>>>
>>>>>> On 04/06/2017 10:57 AM, Sergey Bylokhov wrote:
>>>>>>> Here is an updated version:
>>>>>>> http://cr.openjdk.java.net/~serb/8177841/webrev.01/ 
>>>>>>> <http://cr.openjdk.java.net/%7Eserb/8177841/webrev.01/>
>>>>>>> It will save 5 sec per test, so probably the simpler .00 version 
>>>>>>> can be reevaluated.
>>>>>>>
>>>>>>>>
>>>>>>>> On 3/30/2017 10:27 PM, Sergey Bylokhov wrote:
>>>>>>>>>> sun.java2d.win.uiScaleX/Y is only applicable to windows which 
>>>>>>>>>> is likely why the test had
>>>>>>>>>> @requires (os.family == "windows") even if it was not the 
>>>>>>>>>> right name. Now you are running unconditionally with those 
>>>>>>>>>> properties on all platforms which seems to be a waste of time.
>>>>>>>>> Yes, if we know that uiScaleX/Y are windows specific then 2 
>>>>>>>>> modes out of 5 is noop. But I do not like to exclude them, 
>>>>>>>>> instead I would like to fuzz the tests by 
>>>>>>>>> supported/unsupported properties, in the same way as 2d-tests 
>>>>>>>>> are executed using different supported/unsupprted 
>>>>>>>>> "sun.java2d.XXX" pipelines.
>>>>>>>>   The test can be separated on two tests: one is Windows 
>>>>>>>> specific and another is general.
>>>>>>>>
>>>>>>>>   Thanks,
>>>>>>>>   Alexandr.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 03/30/2017 12:11 PM, Sergey Bylokhov wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>> Please review the fix for jdk9.
>>>>>>>>>>>
>>>>>>>>>>> Initially I found a typo in the HiDPIRobotMouseClick.java. It contains the ?Dsun.java2d.win.uiScale? option, which should be Dsun.java2d.uiScale or Dsun.java2d.win.uiScaleX/Y.
>>>>>>>>>>> But when I verified the fix, the test fails if executed w/o any options (my system has 125% DPI).
>>>>>>>>>>>
>>>>>>>>>>> So I decided to update it and related HiDPIRobotScreenCaptureTest to validated more modes.
>>>>>>>>>>>
>>>>>>>>>>> - Default(w/o options), useful if the system has some default scale.
>>>>>>>>>>> - scale = 1 is useful when the tests are executed on HiDPI systems.
>>>>>>>>>>>
>>>>>>>>>>> I am not sure why these tests sets the Windows L&F because it uses only awt Frame.
>>>>>>>>>>> I?ll file a separate bug for HiDPIRobotMouseClick.java + 125% DPI.
>>>>>>>>>>>
>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8177841
>>>>>>>>>>> Webrev can be found at:http://cr.openjdk.java.net/~serb/8177841/webrev.00
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170407/8928dd68/attachment.html>

From sergey.bylokhov at oracle.com  Mon Apr 10 13:15:19 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 10 Apr 2017 16:15:19 +0300
Subject: <AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests
 can be improved
In-Reply-To: <eb76e346-faf7-6e1f-e642-48dbb3197411@oracle.com>
References: <694CFD15-FB7F-4104-905C-54D076D6B33A@oracle.com>
 <41f85a5d-314d-e092-11fd-8537c6d25582@oracle.com>
 <44942D18-F153-45A7-B22D-946A52D008BA@oracle.com>
 <03b43451-ba30-0e3c-33ce-7f8b4e0d8b41@oracle.com>
 <9704F228-F6CD-4DF9-9DA5-02EC124EF1C6@oracle.com>
 <03b9c673-59db-6550-ce72-8b7599df9908@oracle.com>
 <58E1D70B-F6C2-4EB4-B953-282BCE237C88@oracle.com>
 <bbe34493-804b-2b4c-2707-32519a432939@oracle.com>
 <1D6419F2-4F6E-42ED-AB49-735D62031359@oracle.com>
 <783f239a-b57d-d7f3-e243-96ffb15dd1b0@oracle.com>
 <05895DD4-DE43-4BF2-998B-372EBD94FDBF@oracle.com>
 <eb76e346-faf7-6e1f-e642-48dbb3197411@oracle.com>
Message-ID: <6FC79B5C-CC21-4B20-8F3E-CB97AD7DC005@oracle.com>

>>>> 
>>>> We already have a mechanism which kills the tests after timeout, we also have a default timeout of 2 minutes.
>>>> I am not sure how to get dump of all threads from the catch block.
>>> But shouldn't the time frame when a mouse click may come be limited? Will it be correct when the click triggered after 2 minutes delay makes the test passed anyway?
>> 
>> If timeout will occur and the test still was not complete, then it will be killed, all frames will be closed, the dump of all threads will be generated. So the test cannot pass after timeout.
> I meant when the listener is triggered right before the 2 minutes timeout, for example in 1 minute 59 seconds. In the current logic the test passes in this case and no dumps were generated for any thread. But actually this means an issue because event shouldn't be delayed for that amount of time or this event is not generated by the test. 

If the test will complete successfully before timeout then it will validate the functionality which it was targeted for. The slowness can be from the slow/embedded system, or if the system was overloaded by some other tasks. If the test will fails on such systems by the timeout then the user will be able to tweak it via jtreg parameter.


>> 
>>>> 
>>>>> I would prefer to avoid any infinite waiting because if the listener is not triggered in several second it will unlikely be triggered at all. But if a number of such tests fails for some reason the execution time becomes so long that the test report cannot be obtained in a reasonable time.
>>>>>> 
>>>>>>> 
>>>>>>> On 04/06/2017 10:57 AM, Sergey Bylokhov wrote:
>>>>>>>> Here is an updated version:
>>>>>>>> http://cr.openjdk.java.net/~serb/8177841/webrev.01/ <http://cr.openjdk.java.net/%7Eserb/8177841/webrev.01/>
>>>>>>>> It will save 5 sec per test, so probably the simpler .00 version can be reevaluated.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 3/30/2017 10:27 PM, Sergey Bylokhov wrote:
>>>>>>>>>>> sun.java2d.win.uiScaleX/Y is only applicable to windows which is likely why the test had 
>>>>>>>>>>> @requires (os.family == "windows") even if it was not the right name.
>>>>>>>>>>> 
>>>>>>>>>>> Now you are running unconditionally with those properties on all platforms which
>>>>>>>>>>> seems to be a waste of time.
>>>>>>>>>> Yes, if we know that uiScaleX/Y are windows specific then 2 modes out of 5 is noop. But I do not like to exclude them, instead I would like to fuzz the tests by supported/unsupported properties, in the same way as 2d-tests are executed using different supported/unsupprted "sun.java2d.XXX" pipelines.
>>>>>>>>>   The test can be separated on two tests: one is Windows specific and another is general.
>>>>>>>>> 
>>>>>>>>>   Thanks,
>>>>>>>>>   Alexandr.
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 03/30/2017 12:11 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>> Please review the fix for jdk9.
>>>>>>>>>>>> 
>>>>>>>>>>>> Initially I found a typo in the HiDPIRobotMouseClick.java. It contains the ?Dsun.java2d.win.uiScale? option, which should be Dsun.java2d.uiScale or Dsun.java2d.win.uiScaleX/Y.
>>>>>>>>>>>> But when I verified the fix, the test fails if executed w/o any options (my system has 125% DPI).
>>>>>>>>>>>> 
>>>>>>>>>>>> So I decided to update it and related HiDPIRobotScreenCaptureTest to validated more modes.
>>>>>>>>>>>> 
>>>>>>>>>>>> - Default(w/o options), useful if the system has some default scale.
>>>>>>>>>>>> - scale = 1 is useful when the tests are executed on HiDPI systems.
>>>>>>>>>>>> 
>>>>>>>>>>>> I am not sure why these tests sets the Windows L&F because it uses only awt Frame.  
>>>>>>>>>>>> I?ll file a separate bug for HiDPIRobotMouseClick.java + 125% DPI.
>>>>>>>>>>>> 
>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177841 <https://bugs.openjdk.java.net/browse/JDK-8177841>
>>>>>>>>>>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8177841/webrev.00 <http://cr.openjdk.java.net/%7Eserb/8177841/webrev.00>
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170410/fa362a40/attachment-0001.html>

From semyon.sadetsky at oracle.com  Mon Apr 10 15:18:01 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 10 Apr 2017 08:18:01 -0700
Subject: <AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests
 can be improved
In-Reply-To: <6FC79B5C-CC21-4B20-8F3E-CB97AD7DC005@oracle.com>
References: <694CFD15-FB7F-4104-905C-54D076D6B33A@oracle.com>
 <41f85a5d-314d-e092-11fd-8537c6d25582@oracle.com>
 <44942D18-F153-45A7-B22D-946A52D008BA@oracle.com>
 <03b43451-ba30-0e3c-33ce-7f8b4e0d8b41@oracle.com>
 <9704F228-F6CD-4DF9-9DA5-02EC124EF1C6@oracle.com>
 <03b9c673-59db-6550-ce72-8b7599df9908@oracle.com>
 <58E1D70B-F6C2-4EB4-B953-282BCE237C88@oracle.com>
 <bbe34493-804b-2b4c-2707-32519a432939@oracle.com>
 <1D6419F2-4F6E-42ED-AB49-735D62031359@oracle.com>
 <783f239a-b57d-d7f3-e243-96ffb15dd1b0@oracle.com>
 <05895DD4-DE43-4BF2-998B-372EBD94FDBF@oracle.com>
 <eb76e346-faf7-6e1f-e642-48dbb3197411@oracle.com>
 <6FC79B5C-CC21-4B20-8F3E-CB97AD7DC005@oracle.com>
Message-ID: <e3fc5279-f09e-cfb6-255a-44ce1252b740@oracle.com>

On 04/10/2017 06:15 AM, Sergey Bylokhov wrote:

>>>>>
>>>>> We already have a mechanism which kills the tests after timeout, 
>>>>> we also have a default timeout of 2 minutes.
>>>>> I am not sure how to get dump of all threads from the catch block.
>>>> But shouldn't the time frame when a mouse click may come be 
>>>> limited? Will it be correct when the click triggered after 2 
>>>> minutes delay makes the test passed anyway?
>>>
>>> If timeout will occur and the test still was not complete, then it 
>>> will be killed, all frames will be closed, the dump of all threads 
>>> will be generated. So the test cannot pass after timeout.
>> I meant when the listener is triggered right before the 2 minutes 
>> timeout, for example in 1 minute 59 seconds. In the current logic the 
>> test passes in this case and no dumps were generated for any thread. 
>> But actually this means an issue because event shouldn't be delayed 
>> for that amount of time or this event is not generated by the test.
>
> If the test will complete successfully before timeout then it will 
> validate the functionality which it was targeted for. The slowness can 
> be from the slow/embedded system, or if the system was overloaded by 
> some other tasks. If the test will fails on such systems by the 
> timeout then the user will be able to tweak it via jtreg parameter.
Anyway 2 minutes seems a very unusual waiting time for the event at any 
circumstances.  Usually, in the client-libs tests after an action is 
triggered, we wait for silence in all event queues plus a small period 
of several hundreds milliseconds. Why in this particular test such huge 
waiting is necessary?
>
>
>>>
>>>>>
>>>>>> I would prefer to avoid any infinite waiting because if the 
>>>>>> listener is not triggered in several second it will unlikely be 
>>>>>> triggered at all. But if a number of such tests fails for some 
>>>>>> reason the execution time becomes so long that the test report 
>>>>>> cannot be obtained in a reasonable time.
>>>>>>>
>>>>>>>>
>>>>>>>> On 04/06/2017 10:57 AM, Sergey Bylokhov wrote:
>>>>>>>>> Here is an updated version:
>>>>>>>>> http://cr.openjdk.java.net/~serb/8177841/webrev.01/ 
>>>>>>>>> <http://cr.openjdk.java.net/%7Eserb/8177841/webrev.01/>
>>>>>>>>> It will save 5 sec per test, so probably the simpler .00 
>>>>>>>>> version can be reevaluated.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 3/30/2017 10:27 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>> sun.java2d.win.uiScaleX/Y is only applicable to windows 
>>>>>>>>>>>> which is likely why the test had
>>>>>>>>>>>> @requires (os.family == "windows") even if it was not the 
>>>>>>>>>>>> right name. Now you are running unconditionally with those 
>>>>>>>>>>>> properties on all platforms which seems to be a waste of time.
>>>>>>>>>>> Yes, if we know that uiScaleX/Y are windows specific then 2 
>>>>>>>>>>> modes out of 5 is noop. But I do not like to exclude them, 
>>>>>>>>>>> instead I would like to fuzz the tests by 
>>>>>>>>>>> supported/unsupported properties, in the same way as 
>>>>>>>>>>> 2d-tests are executed using different supported/unsupprted 
>>>>>>>>>>> "sun.java2d.XXX" pipelines.
>>>>>>>>>>   The test can be separated on two tests: one is Windows 
>>>>>>>>>> specific and another is general.
>>>>>>>>>>
>>>>>>>>>>   Thanks,
>>>>>>>>>>   Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 03/30/2017 12:11 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>> Please review the fix for jdk9.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Initially I found a typo in the HiDPIRobotMouseClick.java. It contains the ?Dsun.java2d.win.uiScale? option, which should be Dsun.java2d.uiScale or Dsun.java2d.win.uiScaleX/Y.
>>>>>>>>>>>>> But when I verified the fix, the test fails if executed w/o any options (my system has 125% DPI).
>>>>>>>>>>>>>
>>>>>>>>>>>>> So I decided to update it and related HiDPIRobotScreenCaptureTest to validated more modes.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Default(w/o options), useful if the system has some default scale.
>>>>>>>>>>>>> - scale = 1 is useful when the tests are executed on HiDPI systems.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am not sure why these tests sets the Windows L&F because it uses only awt Frame.
>>>>>>>>>>>>> I?ll file a separate bug for HiDPIRobotMouseClick.java + 125% DPI.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8177841
>>>>>>>>>>>>> Webrev can be found at:http://cr.openjdk.java.net/~serb/8177841/webrev.00
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170410/07c637dc/attachment.html>

From semyon.sadetsky at oracle.com  Mon Apr 10 22:15:41 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 10 Apr 2017 15:15:41 -0700
Subject: <AWT Dev> [9] Review request for 8142540: [TEST_BUG] Test
 sun/awt/dnd/8024061/bug8024061.java fails on ubuntu
Message-ID: <0b213e43-df67-066b-4481-417ae4b5fb15@oracle.com>

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8142540

webrev: http://cr.openjdk.java.net/~ssadetsky/8142540/webrev.00/

Starting Ubuntu 15 windows got zero width borders. Initial mouse click 
point missed the panel to drag.

--Semyon


From sergey.bylokhov at oracle.com  Tue Apr 11 04:20:57 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 11 Apr 2017 07:20:57 +0300
Subject: <AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests
 can be improved
In-Reply-To: <e3fc5279-f09e-cfb6-255a-44ce1252b740@oracle.com>
References: <694CFD15-FB7F-4104-905C-54D076D6B33A@oracle.com>
 <41f85a5d-314d-e092-11fd-8537c6d25582@oracle.com>
 <44942D18-F153-45A7-B22D-946A52D008BA@oracle.com>
 <03b43451-ba30-0e3c-33ce-7f8b4e0d8b41@oracle.com>
 <9704F228-F6CD-4DF9-9DA5-02EC124EF1C6@oracle.com>
 <03b9c673-59db-6550-ce72-8b7599df9908@oracle.com>
 <58E1D70B-F6C2-4EB4-B953-282BCE237C88@oracle.com>
 <bbe34493-804b-2b4c-2707-32519a432939@oracle.com>
 <1D6419F2-4F6E-42ED-AB49-735D62031359@oracle.com>
 <783f239a-b57d-d7f3-e243-96ffb15dd1b0@oracle.com>
 <05895DD4-DE43-4BF2-998B-372EBD94FDBF@oracle.com>
 <eb76e346-faf7-6e1f-e642-48dbb3197411@oracle.com>
 <6FC79B5C-CC21-4B20-8F3E-CB97AD7DC005@oracle.com>
 <e3fc5279-f09e-cfb6-255a-44ce1252b740@oracle.com>
Message-ID: <0A82DDBC-7810-456D-B74A-1AFE8CE21D4C@oracle.com>


> 10 ???. 2017 ?., ? 18:18, Semyon Sadetsky <semyon.sadetsky at oracle.com> ???????(?):
> 
> On 04/10/2017 06:15 AM, Sergey Bylokhov wrote:
>>>>>> 
>>>>>> We already have a mechanism which kills the tests after timeout, we also have a default timeout of 2 minutes.
>>>>>> I am not sure how to get dump of all threads from the catch block.
>>>>> But shouldn't the time frame when a mouse click may come be limited? Will it be correct when the click triggered after 2 minutes delay makes the test passed anyway?
>>>> 
>>>> If timeout will occur and the test still was not complete, then it will be killed, all frames will be closed, the dump of all threads will be generated. So the test cannot pass after timeout.
>>> I meant when the listener is triggered right before the 2 minutes timeout, for example in 1 minute 59 seconds. In the current logic the test passes in this case and no dumps were generated for any thread. But actually this means an issue because event shouldn't be delayed for that amount of time or this event is not generated by the test. 
>> 
>> If the test will complete successfully before timeout then it will validate the functionality which it was targeted for. The slowness can be from the slow/embedded system, or if the system was overloaded by some other tasks. If the test will fails on such systems by the timeout then the user will be able to tweak it via jtreg parameter.
> Anyway 2 minutes seems a very unusual waiting time for the event at any circumstances.  Usually, in the client-libs tests after an action is triggered, we wait for silence in all event queues plus a small period of several hundreds milliseconds. Why in this particular test such huge waiting is necessary?

Usually we wait in the test some amount of time in the common code path, when the test is passed. This "small period of time" usually tweaked for the slow systems, so we could get a situation when the test is executed more than 2 minutes in the common case(when it is passed).  Because the ?small period of time? is different between common systems and slow/embeded systems. The approach in the current test will work instantly on the fast systems, and will wait till timeout on the slow systems. To summarize we already have timeout handling in the jtreg and should not reinvent it per test.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170411/6e4a3d26/attachment.html>

From sergey.bylokhov at oracle.com  Tue Apr 11 04:34:15 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 11 Apr 2017 07:34:15 +0300
Subject: <AWT Dev> [9] Review request for 8142540: [TEST_BUG] Test
 sun/awt/dnd/8024061/bug8024061.java fails on ubuntu
In-Reply-To: <0b213e43-df67-066b-4481-417ae4b5fb15@oracle.com>
References: <0b213e43-df67-066b-4481-417ae4b5fb15@oracle.com>
Message-ID: <417DA4E8-9B0D-4DD3-AF92-35275BA50A5C@oracle.com>

> webrev: http://cr.openjdk.java.net/~ssadetsky/8142540/webrev.00/
> 
> Starting Ubuntu 15 windows got zero width borders. Initial mouse click point missed the panel to drag.

Probably it will be better to use locations of panel1 and panel2 as an ?here? and ?there?  instead of trying to find their locations via frame+some constants?

From semyon.sadetsky at oracle.com  Tue Apr 11 15:23:59 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 11 Apr 2017 08:23:59 -0700
Subject: <AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests
 can be improved
In-Reply-To: <0A82DDBC-7810-456D-B74A-1AFE8CE21D4C@oracle.com>
References: <694CFD15-FB7F-4104-905C-54D076D6B33A@oracle.com>
 <41f85a5d-314d-e092-11fd-8537c6d25582@oracle.com>
 <44942D18-F153-45A7-B22D-946A52D008BA@oracle.com>
 <03b43451-ba30-0e3c-33ce-7f8b4e0d8b41@oracle.com>
 <9704F228-F6CD-4DF9-9DA5-02EC124EF1C6@oracle.com>
 <03b9c673-59db-6550-ce72-8b7599df9908@oracle.com>
 <58E1D70B-F6C2-4EB4-B953-282BCE237C88@oracle.com>
 <bbe34493-804b-2b4c-2707-32519a432939@oracle.com>
 <1D6419F2-4F6E-42ED-AB49-735D62031359@oracle.com>
 <783f239a-b57d-d7f3-e243-96ffb15dd1b0@oracle.com>
 <05895DD4-DE43-4BF2-998B-372EBD94FDBF@oracle.com>
 <eb76e346-faf7-6e1f-e642-48dbb3197411@oracle.com>
 <6FC79B5C-CC21-4B20-8F3E-CB97AD7DC005@oracle.com>
 <e3fc5279-f09e-cfb6-255a-44ce1252b740@oracle.com>
 <0A82DDBC-7810-456D-B74A-1AFE8CE21D4C@oracle.com>
Message-ID: <89b1147b-50b0-af4e-20c9-5f99e045d7d6@oracle.com>



On 04/10/2017 09:20 PM, Sergey Bylokhov wrote:
>
>> 10 ???. 2017 ?., ? 18:18, Semyon Sadetsky <semyon.sadetsky at oracle.com 
>> <mailto:semyon.sadetsky at oracle.com>> ???????(?):
>>
>> On 04/10/2017 06:15 AM, Sergey Bylokhov wrote:
>>
>>>>>>>
>>>>>>> We already have a mechanism which kills the tests after timeout, 
>>>>>>> we also have a default timeout of 2 minutes.
>>>>>>> I am not sure how to get dump of all threads from the catch block.
>>>>>> But shouldn't the time frame when a mouse click may come be 
>>>>>> limited? Will it be correct when the click triggered after 2 
>>>>>> minutes delay makes the test passed anyway?
>>>>>
>>>>> If timeout will occur and the test still was not complete, then it 
>>>>> will be killed, all frames will be closed, the dump of all threads 
>>>>> will be generated. So the test cannot pass after timeout.
>>>> I meant when the listener is triggered right before the 2 minutes 
>>>> timeout, for example in 1 minute 59 seconds. In the current logic 
>>>> the test passes in this case and no dumps were generated for any 
>>>> thread. But actually this means an issue because event shouldn't be 
>>>> delayed for that amount of time or this event is not generated by 
>>>> the test.
>>>
>>> If the test will complete successfully before timeout then it will 
>>> validate the functionality which it was targeted for. The slowness 
>>> can be from the slow/embedded system, or if the system was 
>>> overloaded by some other tasks. If the test will fails on such 
>>> systems by the timeout then the user will be able to tweak it via 
>>> jtreg parameter.
>> Anyway 2 minutes seems a very unusual waiting time for the event at 
>> any circumstances.  Usually, in the client-libs tests after an action 
>> is triggered, we wait for silence in all event queues plus a small 
>> period of several hundreds milliseconds. Why in this particular test 
>> such huge waiting is necessary?
>
> Usually we wait in the test some amount of time in the common code 
> path, when the test is passed. This "small period of time" usually 
> tweaked for the slow systems, so we could get a situation when the 
> test is executed more than 2 minutes in the common case(when it is 
> passed).  Because the ?small period of time? is different between 
> common systems and slow/embeded systems. The approach in the current 
> test will work instantly on the fast systems, and will wait till 
> timeout on the slow systems. To summarize we already have timeout 
> handling in the jtreg and should not reinvent it per test.
We should keep the general approach. I've never seen fixes that require 
2 minutes waiting for an event. 5 seconds waiting would be enough for 
any platform and for the most heaviest toolkit actions (in the current 
test you wait for a single mouse button click which is one of the 
lightest).
I see a lot of disadvantages of the new event waiting approach you've 
introduced. That infinite waiting relying on jtreg timeout may cause 
unreasonable increase of test execution time. Also, I suppose that the 
situation when mouse button event comes later than in 5 seconds on any 
embedded system bears an investigation and the test should fail.
It is not a load testing but an usual UI testing and this means an issue 
if UI doesn't react to mouse click for seconds (not even to mention the 
minutes...).  Imagine yourself as a user of such UI.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170411/b061b184/attachment.html>

From alexander.zvegintsev at oracle.com  Tue Apr 11 15:41:29 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 11 Apr 2017 18:41:29 +0300
Subject: <AWT Dev> =?utf-8?q?=5B9=5D_Review_request_for_8177919=3A_java=2E?=
 =?utf-8?q?awt=2EDesktop=2EsetDefaultMenuBar=E2=80=8B=28=29_should_be_spec?=
 =?utf-8?q?ified_to_throw_IllegalStateException?=
Message-ID: <397e1595-7f2d-3bca-972e-c6ac89538737@oracle.com>

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/9/8177919/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8177919

This fix removes throwing of ISE, this allows to use default menu bar 
with LaF's other than Aqua (with apple.laf.useScreenMenuBar set to true).

This became possible after JDK-8166683[0] fix.

Current documentation of Desktop.setDefaultMenuBar() has implnotes:

      * @implNote Aqua Look and Feel should be active to support this on 
Mac OS.

I leave it unchanged, since I don't want to advertise the 
apple.laf.useScreenMenuBar property.

[0] https://bugs.openjdk.java.net/browse/JDK-8166683


-- 
Thanks,
Alexander.


From sergey.bylokhov at oracle.com  Tue Apr 11 16:06:26 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 11 Apr 2017 19:06:26 +0300
Subject: <AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests
 can be improved
In-Reply-To: <89b1147b-50b0-af4e-20c9-5f99e045d7d6@oracle.com>
References: <694CFD15-FB7F-4104-905C-54D076D6B33A@oracle.com>
 <41f85a5d-314d-e092-11fd-8537c6d25582@oracle.com>
 <44942D18-F153-45A7-B22D-946A52D008BA@oracle.com>
 <03b43451-ba30-0e3c-33ce-7f8b4e0d8b41@oracle.com>
 <9704F228-F6CD-4DF9-9DA5-02EC124EF1C6@oracle.com>
 <03b9c673-59db-6550-ce72-8b7599df9908@oracle.com>
 <58E1D70B-F6C2-4EB4-B953-282BCE237C88@oracle.com>
 <bbe34493-804b-2b4c-2707-32519a432939@oracle.com>
 <1D6419F2-4F6E-42ED-AB49-735D62031359@oracle.com>
 <783f239a-b57d-d7f3-e243-96ffb15dd1b0@oracle.com>
 <05895DD4-DE43-4BF2-998B-372EBD94FDBF@oracle.com>
 <eb76e346-faf7-6e1f-e642-48dbb3197411@oracle.com>
 <6FC79B5C-CC21-4B20-8F3E-CB97AD7DC005@oracle.com>
 <e3fc5279-f09e-cfb6-255a-44ce1252b740@oracle.com>
 <0A82DDBC-7810-456D-B74A-1AFE8CE21D4C@oracle.com>
 <89b1147b-50b0-af4e-20c9-5f99e045d7d6@oracle.com>
Message-ID: <50B4CF21-43A8-4466-B10D-E15C3B9BAE20@oracle.com>

>>> Anyway 2 minutes seems a very unusual waiting time for the event at any circumstances.  Usually, in the client-libs tests after an action is triggered, we wait for silence in all event queues plus a small period of several hundreds milliseconds. Why in this particular test such huge waiting is necessary?
>> 
>> Usually we wait in the test some amount of time in the common code path, when the test is passed. This "small period of time" usually tweaked for the slow systems, so we could get a situation when the test is executed more than 2 minutes in the common case(when it is passed).  Because the ?small period of time? is different between common systems and slow/embeded systems. The approach in the current test will work instantly on the fast systems, and will wait till timeout on the slow systems. To summarize we already have timeout handling in the jtreg and should not reinvent it per test.
> We should keep the general approach. I've never seen fixes that require 2 minutes waiting for an event. 5 seconds waiting would be enough for any platform and for the most heaviest toolkit actions (in the current test you wait for a single mouse button click which is one of the lightest).  

The general approach when we wait some random time(1 or 5 or 10 seconds between an operations) assuming that it is enough of time is incorrect, it is slow down the testing. The changed code will work instantly, and in case of errors provides an additional debug information.

> I see a lot of disadvantages of the new event waiting approach you've introduced. That infinite waiting relying on jtreg timeout may cause unreasonable increase of test execution time. Also, I suppose that the situation when mouse button event comes later than in 5 seconds on any embedded system bears an investigation and the test should fail. 
> It is not a load testing but an usual UI testing and this means an issue if UI doesn't react to mouse click for seconds (not even to mention the minutes...).  Imagine yourself as a user of such UI.


From sergey.bylokhov at oracle.com  Tue Apr 11 16:53:15 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 11 Apr 2017 19:53:15 +0300
Subject: <AWT Dev>
 =?utf-8?q?=5B9=5D_Review_request_for_8177919=3A_java=2E?=
 =?utf-8?q?awt=2EDesktop=2EsetDefaultMenuBar=E2=80=8B=28=29_should_be_spec?=
 =?utf-8?q?ified_to_throw_IllegalStateException?=
In-Reply-To: <397e1595-7f2d-3bca-972e-c6ac89538737@oracle.com>
References: <397e1595-7f2d-3bca-972e-c6ac89538737@oracle.com>
Message-ID: <A7A09260-8EB6-419D-937E-54B00B2DDBDC@oracle.com>

Looks fine.

> 
> Hello,
> 
> please review the fix
> 
> http://cr.openjdk.java.net/~azvegint/jdk/9/8177919/00/
> 
> for the issue
> 
> https://bugs.openjdk.java.net/browse/JDK-8177919
> 
> This fix removes throwing of ISE, this allows to use default menu bar with LaF's other than Aqua (with apple.laf.useScreenMenuBar set to true).
> 
> This became possible after JDK-8166683[0] fix.
> 
> Current documentation of Desktop.setDefaultMenuBar() has implnotes:
> 
>     * @implNote Aqua Look and Feel should be active to support this on Mac OS.
> 
> I leave it unchanged, since I don't want to advertise the apple.laf.useScreenMenuBar property.
> 
> [0] https://bugs.openjdk.java.net/browse/JDK-8166683
> 
> 
> -- 
> Thanks,
> Alexander.
> 


From semyon.sadetsky at oracle.com  Tue Apr 11 17:04:25 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 11 Apr 2017 10:04:25 -0700
Subject: <AWT Dev>
 =?utf-8?q?=5B9=5D_Review_request_for_8177919=3A_java=2E?=
 =?utf-8?q?awt=2EDesktop=2EsetDefaultMenuBar=E2=80=8B=28=29_should_be_spec?=
 =?utf-8?q?ified_to_throw_IllegalStateException?=
In-Reply-To: <A7A09260-8EB6-419D-937E-54B00B2DDBDC@oracle.com>
References: <397e1595-7f2d-3bca-972e-c6ac89538737@oracle.com>
 <A7A09260-8EB6-419D-937E-54B00B2DDBDC@oracle.com>
Message-ID: <07e0cfc3-c805-a0eb-7008-49bf91397e25@oracle.com>

+1

--Semyon


On 04/11/2017 09:53 AM, Sergey Bylokhov wrote:
> Looks fine.
>
>> Hello,
>>
>> please review the fix
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8177919/00/
>>
>> for the issue
>>
>> https://bugs.openjdk.java.net/browse/JDK-8177919
>>
>> This fix removes throwing of ISE, this allows to use default menu bar with LaF's other than Aqua (with apple.laf.useScreenMenuBar set to true).
>>
>> This became possible after JDK-8166683[0] fix.
>>
>> Current documentation of Desktop.setDefaultMenuBar() has implnotes:
>>
>>      * @implNote Aqua Look and Feel should be active to support this on Mac OS.
>>
>> I leave it unchanged, since I don't want to advertise the apple.laf.useScreenMenuBar property.
>>
>> [0] https://bugs.openjdk.java.net/browse/JDK-8166683
>>
>>
>> -- 
>> Thanks,
>> Alexander.
>>


From philip.race at oracle.com  Tue Apr 11 18:16:07 2017
From: philip.race at oracle.com (Phil Race)
Date: Tue, 11 Apr 2017 11:16:07 -0700
Subject: <AWT Dev>
 =?utf-8?q?=5B9=5D_Review_request_for_8177919=3A_java=2E?=
 =?utf-8?q?awt=2EDesktop=2EsetDefaultMenuBar=E2=80=8B=28=29_should_be_spec?=
 =?utf-8?q?ified_to_throw_IllegalStateException?=
In-Reply-To: <397e1595-7f2d-3bca-972e-c6ac89538737@oracle.com>
References: <397e1595-7f2d-3bca-972e-c6ac89538737@oracle.com>
Message-ID: <8fdb8dfc-2431-8269-c245-f5fca42c7a6d@oracle.com>

I'd like to understand the big picture here

Q1. What does this Desktop API do on Windows and Linux ?

Q2. If someone calls this API it is pretty clear what they want.
       Why do we require that they be running Aqua when a lot of the 
requests were
        specifically about de-coupling it from Aqua?

       It is not apparent to me why they must learn about an 
undocumented option to get
       what they want. And the implNote is misleading (or wrong even) 
since there is a way
       to do it without Aqua. It is just not advertised.

       And it is *even weirder* to add that note if Mac is the only 
platform that supports this ...

-phil.

On 04/11/2017 08:41 AM, Alexander Zvegintsev wrote:
> Hello,
>
> please review the fix
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8177919/00/
>
> for the issue
>
> https://bugs.openjdk.java.net/browse/JDK-8177919
>
> This fix removes throwing of ISE, this allows to use default menu bar 
> with LaF's other than Aqua (with apple.laf.useScreenMenuBar set to true).
>
> This became possible after JDK-8166683[0] fix.
>
> Current documentation of Desktop.setDefaultMenuBar() has implnotes:
>
>      * @implNote Aqua Look and Feel should be active to support this 
> on Mac OS.
>
> I leave it unchanged, since I don't want to advertise the 
> apple.laf.useScreenMenuBar property.
>
> [0] https://bugs.openjdk.java.net/browse/JDK-8166683
>
>


From semyon.sadetsky at oracle.com  Wed Apr 12 15:10:19 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 12 Apr 2017 08:10:19 -0700
Subject: <AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests
 can be improved
In-Reply-To: <50B4CF21-43A8-4466-B10D-E15C3B9BAE20@oracle.com>
References: <694CFD15-FB7F-4104-905C-54D076D6B33A@oracle.com>
 <41f85a5d-314d-e092-11fd-8537c6d25582@oracle.com>
 <44942D18-F153-45A7-B22D-946A52D008BA@oracle.com>
 <03b43451-ba30-0e3c-33ce-7f8b4e0d8b41@oracle.com>
 <9704F228-F6CD-4DF9-9DA5-02EC124EF1C6@oracle.com>
 <03b9c673-59db-6550-ce72-8b7599df9908@oracle.com>
 <58E1D70B-F6C2-4EB4-B953-282BCE237C88@oracle.com>
 <bbe34493-804b-2b4c-2707-32519a432939@oracle.com>
 <1D6419F2-4F6E-42ED-AB49-735D62031359@oracle.com>
 <783f239a-b57d-d7f3-e243-96ffb15dd1b0@oracle.com>
 <05895DD4-DE43-4BF2-998B-372EBD94FDBF@oracle.com>
 <eb76e346-faf7-6e1f-e642-48dbb3197411@oracle.com>
 <6FC79B5C-CC21-4B20-8F3E-CB97AD7DC005@oracle.com>
 <e3fc5279-f09e-cfb6-255a-44ce1252b740@oracle.com>
 <0A82DDBC-7810-456D-B74A-1AFE8CE21D4C@oracle.com>
 <89b1147b-50b0-af4e-20c9-5f99e045d7d6@oracle.com>
 <50B4CF21-43A8-4466-B10D-E15C3B9BAE20@oracle.com>
Message-ID: <26e32256-839f-20f5-270d-2cf37d7e3bf0@oracle.com>



On 04/11/2017 09:06 AM, Sergey Bylokhov wrote:
>>>> Anyway 2 minutes seems a very unusual waiting time for the event at any circumstances.  Usually, in the client-libs tests after an action is triggered, we wait for silence in all event queues plus a small period of several hundreds milliseconds. Why in this particular test such huge waiting is necessary?
>>> Usually we wait in the test some amount of time in the common code path, when the test is passed. This "small period of time" usually tweaked for the slow systems, so we could get a situation when the test is executed more than 2 minutes in the common case(when it is passed).  Because the ?small period of time? is different between common systems and slow/embeded systems. The approach in the current test will work instantly on the fast systems, and will wait till timeout on the slow systems. To summarize we already have timeout handling in the jtreg and should not reinvent it per test.
>> We should keep the general approach. I've never seen fixes that require 2 minutes waiting for an event. 5 seconds waiting would be enough for any platform and for the most heaviest toolkit actions (in the current test you wait for a single mouse button click which is one of the lightest).
> The general approach when we wait some random time(1 or 5 or 10 seconds between an operations) assuming that it is enough of time is incorrect, it is slow down the testing. The changed code will work instantly, and in case of errors provides an additional debug information.
We use Robot::waitForIdle() which monitors queues. If the system is 
overloaded it doesn't process the queues and the Robot::waitForIdle() 
waits longer. If the queues get stuck for many seconds the 
robot.waitForIdle() throws exception and test fails.
>
>> I see a lot of disadvantages of the new event waiting approach you've introduced. That infinite waiting relying on jtreg timeout may cause unreasonable increase of test execution time. Also, I suppose that the situation when mouse button event comes later than in 5 seconds on any embedded system bears an investigation and the test should fail.
>> It is not a load testing but an usual UI testing and this means an issue if UI doesn't react to mouse click for seconds (not even to mention the minutes...).  Imagine yourself as a user of such UI.


From semyon.sadetsky at oracle.com  Wed Apr 12 19:23:55 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 12 Apr 2017 12:23:55 -0700
Subject: <AWT Dev> [9] Review request for 8142540: [TEST_BUG] Test
 sun/awt/dnd/8024061/bug8024061.java fails on ubuntu
In-Reply-To: <417DA4E8-9B0D-4DD3-AF92-35275BA50A5C@oracle.com>
References: <0b213e43-df67-066b-4481-417ae4b5fb15@oracle.com>
 <417DA4E8-9B0D-4DD3-AF92-35275BA50A5C@oracle.com>
Message-ID: <332f462d-4fc2-c252-86aa-c570ad327aea@oracle.com>

On 04/10/2017 09:34 PM, Sergey Bylokhov wrote:

>> webrev: http://cr.openjdk.java.net/~ssadetsky/8142540/webrev.00/
>>
>> Starting Ubuntu 15 windows got zero width borders. Initial mouse click point missed the panel to drag.
> Probably it will be better to use locations of panel1 and panel2 as an ?here? and ?there?  instead of trying to find their locations via frame+some constants?
http://cr.openjdk.java.net/~ssadetsky/8142540/webrev.01/

From sergey.bylokhov at oracle.com  Wed Apr 12 21:42:58 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 13 Apr 2017 00:42:58 +0300
Subject: <AWT Dev> [9] Review request for 8142540: [TEST_BUG] Test
 sun/awt/dnd/8024061/bug8024061.java fails on ubuntu
In-Reply-To: <332f462d-4fc2-c252-86aa-c570ad327aea@oracle.com>
References: <0b213e43-df67-066b-4481-417ae4b5fb15@oracle.com>
 <417DA4E8-9B0D-4DD3-AF92-35275BA50A5C@oracle.com>
 <332f462d-4fc2-c252-86aa-c570ad327aea@oracle.com>
Message-ID: <05D0CE3B-1E52-4B80-AC59-159255F00265@oracle.com>

>>> 
>>> Starting Ubuntu 15 windows got zero width borders. Initial mouse click point missed the panel to drag.
>> Probably it will be better to use locations of panel1 and panel2 as an ?here? and ?there?  instead of trying to find their locations via frame+some constants?
> http://cr.openjdk.java.net/~ssadetsky/8142540/webrev.01/

Looks fine, thanks.

From yuri.nesterenko at oracle.com  Thu Apr 13 09:36:58 2017
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Thu, 13 Apr 2017 12:36:58 +0300
Subject: <AWT Dev> [9] Review request for 8142540: [TEST_BUG] Test
 sun/awt/dnd/8024061/bug8024061.java fails on ubuntu
In-Reply-To: <332f462d-4fc2-c252-86aa-c570ad327aea@oracle.com>
References: <0b213e43-df67-066b-4481-417ae4b5fb15@oracle.com>
 <417DA4E8-9B0D-4DD3-AF92-35275BA50A5C@oracle.com>
 <332f462d-4fc2-c252-86aa-c570ad327aea@oracle.com>
Message-ID: <1cf58989-83b0-c147-36b7-86f7776ff8f1@oracle.com>

+1

-yan

On 04/12/2017 10:23 PM, Semyon Sadetsky wrote:
> On 04/10/2017 09:34 PM, Sergey Bylokhov wrote:
>
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8142540/webrev.00/
>>>
>>> Starting Ubuntu 15 windows got zero width borders. Initial mouse
>>> click point missed the panel to drag.
>> Probably it will be better to use locations of panel1 and panel2 as an
>> ?here? and ?there?  instead of trying to find their locations via
>> frame+some constants?
> http://cr.openjdk.java.net/~ssadetsky/8142540/webrev.01/


From alexander.zvegintsev at oracle.com  Thu Apr 13 17:38:44 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 13 Apr 2017 20:38:44 +0300
Subject: <AWT Dev>
 =?utf-8?q?=5B9=5D_Review_request_for_8177919=3A_java=2E?=
 =?utf-8?q?awt=2EDesktop=2EsetDefaultMenuBar=E2=80=8B=28=29_should_be_spec?=
 =?utf-8?q?ified_to_throw_IllegalStateException?=
In-Reply-To: <8fdb8dfc-2431-8269-c245-f5fca42c7a6d@oracle.com>
References: <397e1595-7f2d-3bca-972e-c6ac89538737@oracle.com>
 <8fdb8dfc-2431-8269-c245-f5fca42c7a6d@oracle.com>
Message-ID: <3b915670-8968-0883-76c4-dc98b396170b@oracle.com>

Actually it does nothing on Windows and Linux.

Please review another version of the fix,

it enables default menubar regardless of apple.laf.useScreenMenuBar 
property

and restores an old default MenuBarUI when it is used in JFrame.

http://cr.openjdk.java.net/~azvegint/jdk/9/8177919/01/

Thanks,
Alexander.

On 11/04/2017 21:16, Phil Race wrote:
> I'd like to understand the big picture here
>
> Q1. What does this Desktop API do on Windows and Linux ?
>
> Q2. If someone calls this API it is pretty clear what they want.
>       Why do we require that they be running Aqua when a lot of the 
> requests were
>        specifically about de-coupling it from Aqua?
>
>       It is not apparent to me why they must learn about an 
> undocumented option to get
>       what they want. And the implNote is misleading (or wrong even) 
> since there is a way
>       to do it without Aqua. It is just not advertised.
>
>       And it is *even weirder* to add that note if Mac is the only 
> platform that supports this ...
>
> -phil.
>
> On 04/11/2017 08:41 AM, Alexander Zvegintsev wrote:
>> Hello,
>>
>> please review the fix
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8177919/00/
>>
>> for the issue
>>
>> https://bugs.openjdk.java.net/browse/JDK-8177919
>>
>> This fix removes throwing of ISE, this allows to use default menu bar 
>> with LaF's other than Aqua (with apple.laf.useScreenMenuBar set to 
>> true).
>>
>> This became possible after JDK-8166683[0] fix.
>>
>> Current documentation of Desktop.setDefaultMenuBar() has implnotes:
>>
>>      * @implNote Aqua Look and Feel should be active to support this 
>> on Mac OS.
>>
>> I leave it unchanged, since I don't want to advertise the 
>> apple.laf.useScreenMenuBar property.
>>
>> [0] https://bugs.openjdk.java.net/browse/JDK-8166683
>>
>>
>


From philip.race at oracle.com  Thu Apr 13 17:46:05 2017
From: philip.race at oracle.com (Phil Race)
Date: Thu, 13 Apr 2017 10:46:05 -0700
Subject: <AWT Dev>
 =?utf-8?q?=5B9=5D_Review_request_for_8177919=3A_java=2E?=
 =?utf-8?q?awt=2EDesktop=2EsetDefaultMenuBar=E2=80=8B=28=29_should_be_spec?=
 =?utf-8?q?ified_to_throw_IllegalStateException?=
In-Reply-To: <3b915670-8968-0883-76c4-dc98b396170b@oracle.com>
References: <397e1595-7f2d-3bca-972e-c6ac89538737@oracle.com>
 <8fdb8dfc-2431-8269-c245-f5fca42c7a6d@oracle.com>
 <3b915670-8968-0883-76c4-dc98b396170b@oracle.com>
Message-ID: <ce3aced6-165e-99d9-bd6f-4d97af58d071@oracle.com>

28 import java.awt.*; Could this be just "import java.awt.Container;" ? 
Other than that this seems fine with the proviso that this has been 
tested with different L&Fs .. and even with none installed. -phil.



On 04/13/2017 10:38 AM, Alexander Zvegintsev wrote:
> Actually it does nothing on Windows and Linux.
>
> Please review another version of the fix,
>
> it enables default menubar regardless of apple.laf.useScreenMenuBar 
> property
>
> and restores an old default MenuBarUI when it is used in JFrame.
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8177919/01/
>
> Thanks,
> Alexander.
>
> On 11/04/2017 21:16, Phil Race wrote:
>> I'd like to understand the big picture here
>>
>> Q1. What does this Desktop API do on Windows and Linux ?
>>
>> Q2. If someone calls this API it is pretty clear what they want.
>>       Why do we require that they be running Aqua when a lot of the 
>> requests were
>>        specifically about de-coupling it from Aqua?
>>
>>       It is not apparent to me why they must learn about an 
>> undocumented option to get
>>       what they want. And the implNote is misleading (or wrong even) 
>> since there is a way
>>       to do it without Aqua. It is just not advertised.
>>
>>       And it is *even weirder* to add that note if Mac is the only 
>> platform that supports this ...
>>
>> -phil.
>>
>> On 04/11/2017 08:41 AM, Alexander Zvegintsev wrote:
>>> Hello,
>>>
>>> please review the fix
>>>
>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8177919/00/
>>>
>>> for the issue
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8177919
>>>
>>> This fix removes throwing of ISE, this allows to use default menu 
>>> bar with LaF's other than Aqua (with apple.laf.useScreenMenuBar set 
>>> to true).
>>>
>>> This became possible after JDK-8166683[0] fix.
>>>
>>> Current documentation of Desktop.setDefaultMenuBar() has implnotes:
>>>
>>>      * @implNote Aqua Look and Feel should be active to support this 
>>> on Mac OS.
>>>
>>> I leave it unchanged, since I don't want to advertise the 
>>> apple.laf.useScreenMenuBar property.
>>>
>>> [0] https://bugs.openjdk.java.net/browse/JDK-8166683
>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170413/b4d300d1/attachment.html>

From alexander.zvegintsev at oracle.com  Thu Apr 13 18:38:35 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 13 Apr 2017 21:38:35 +0300
Subject: <AWT Dev>
 =?utf-8?q?=5B9=5D_Review_request_for_8177919=3A_java=2E?=
 =?utf-8?q?awt=2EDesktop=2EsetDefaultMenuBar=E2=80=8B=28=29_should_be_spec?=
 =?utf-8?q?ified_to_throw_IllegalStateException?=
In-Reply-To: <ce3aced6-165e-99d9-bd6f-4d97af58d071@oracle.com>
References: <397e1595-7f2d-3bca-972e-c6ac89538737@oracle.com>
 <8fdb8dfc-2431-8269-c245-f5fca42c7a6d@oracle.com>
 <3b915670-8968-0883-76c4-dc98b396170b@oracle.com>
 <ce3aced6-165e-99d9-bd6f-4d97af58d071@oracle.com>
Message-ID: <392e58f1-148b-24e0-8512-96c0c3bb87f1@oracle.com>

Sure, I've updated it in place, javax.swing.* wild card import replaced 
as well.

CCC request is also submitted.

Thanks,
Alexander.

On 13/04/2017 20:46, Phil Race wrote:
> 28 import java.awt.*; Could this be just "import java.awt.Container;" 
> ? Other than that this seems fine with the proviso that this has been 
> tested with different L&Fs .. and even with none installed. -phil.
>
>
> On 04/13/2017 10:38 AM, Alexander Zvegintsev wrote:
>> Actually it does nothing on Windows and Linux.
>>
>> Please review another version of the fix,
>>
>> it enables default menubar regardless of apple.laf.useScreenMenuBar 
>> property
>>
>> and restores an old default MenuBarUI when it is used in JFrame.
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8177919/01/
>>
>> Thanks,
>> Alexander.
>>
>> On 11/04/2017 21:16, Phil Race wrote:
>>> I'd like to understand the big picture here
>>>
>>> Q1. What does this Desktop API do on Windows and Linux ?
>>>
>>> Q2. If someone calls this API it is pretty clear what they want.
>>>       Why do we require that they be running Aqua when a lot of the 
>>> requests were
>>>        specifically about de-coupling it from Aqua?
>>>
>>>       It is not apparent to me why they must learn about an 
>>> undocumented option to get
>>>       what they want. And the implNote is misleading (or wrong even) 
>>> since there is a way
>>>       to do it without Aqua. It is just not advertised.
>>>
>>>       And it is *even weirder* to add that note if Mac is the only 
>>> platform that supports this ...
>>>
>>> -phil.
>>>
>>> On 04/11/2017 08:41 AM, Alexander Zvegintsev wrote:
>>>> Hello,
>>>>
>>>> please review the fix
>>>>
>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8177919/00/
>>>>
>>>> for the issue
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8177919
>>>>
>>>> This fix removes throwing of ISE, this allows to use default menu 
>>>> bar with LaF's other than Aqua (with apple.laf.useScreenMenuBar set 
>>>> to true).
>>>>
>>>> This became possible after JDK-8166683[0] fix.
>>>>
>>>> Current documentation of Desktop.setDefaultMenuBar() has implnotes:
>>>>
>>>>      * @implNote Aqua Look and Feel should be active to support 
>>>> this on Mac OS.
>>>>
>>>> I leave it unchanged, since I don't want to advertise the 
>>>> apple.laf.useScreenMenuBar property.
>>>>
>>>> [0] https://bugs.openjdk.java.net/browse/JDK-8166683
>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170413/b93d038e/attachment.html>

From sergey.bylokhov at oracle.com  Thu Apr 13 19:43:33 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 13 Apr 2017 12:43:33 -0700 (PDT)
Subject: <AWT Dev>
 =?utf-8?q?=5B9=5D_Review_request_for_8177919=3A_java=2E?=
 =?utf-8?q?awt=2EDesktop=2EsetDefaultMenuBar=E2=80=8B=28=29_should_be_spec?=
 =?utf-8?q?ified_to_throw_IllegalStateException?=
Message-ID: <e12f9ba5-d94c-46fe-a30d-4cc0d6c557c6@default>

Hi, Alex.
Are these changes fix the bug which we talked offline(you planned to file it separatly)?

----- alexander.zvegintsev at oracle.com wrote:

> Actually it does nothing on Windows and Linux.
> 
> Please review another version of the fix,
> 
> it enables default menubar regardless of apple.laf.useScreenMenuBar 
> property
> 
> and restores an old default MenuBarUI when it is used in JFrame.
> 
> http://cr.openjdk.java.net/~azvegint/jdk/9/8177919/01/
> 
> Thanks,
> Alexander.
> 
> On 11/04/2017 21:16, Phil Race wrote:
> > I'd like to understand the big picture here
> >
> > Q1. What does this Desktop API do on Windows and Linux ?
> >
> > Q2. If someone calls this API it is pretty clear what they want.
> >       Why do we require that they be running Aqua when a lot of the
> 
> > requests were
> >        specifically about de-coupling it from Aqua?
> >
> >       It is not apparent to me why they must learn about an 
> > undocumented option to get
> >       what they want. And the implNote is misleading (or wrong even)
> 
> > since there is a way
> >       to do it without Aqua. It is just not advertised.
> >
> >       And it is *even weirder* to add that note if Mac is the only 
> > platform that supports this ...
> >
> > -phil.
> >
> > On 04/11/2017 08:41 AM, Alexander Zvegintsev wrote:
> >> Hello,
> >>
> >> please review the fix
> >>
> >> http://cr.openjdk.java.net/~azvegint/jdk/9/8177919/00/
> >>
> >> for the issue
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8177919
> >>
> >> This fix removes throwing of ISE, this allows to use default menu
> bar 
> >> with LaF's other than Aqua (with apple.laf.useScreenMenuBar set to
> 
> >> true).
> >>
> >> This became possible after JDK-8166683[0] fix.
> >>
> >> Current documentation of Desktop.setDefaultMenuBar() has
> implnotes:
> >>
> >>      * @implNote Aqua Look and Feel should be active to support
> this 
> >> on Mac OS.
> >>
> >> I leave it unchanged, since I don't want to advertise the 
> >> apple.laf.useScreenMenuBar property.
> >>
> >> [0] https://bugs.openjdk.java.net/browse/JDK-8166683
> >>
> >>
> >

From alexander.zvegintsev at oracle.com  Thu Apr 13 20:10:14 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 13 Apr 2017 23:10:14 +0300
Subject: <AWT Dev>
 =?utf-8?q?=5B9=5D_Review_request_for_8177919=3A_java=2E?=
 =?utf-8?q?awt=2EDesktop=2EsetDefaultMenuBar=E2=80=8B=28=29_should_be_spec?=
 =?utf-8?q?ified_to_throw_IllegalStateException?=
In-Reply-To: <e12f9ba5-d94c-46fe-a30d-4cc0d6c557c6@default>
References: <e12f9ba5-d94c-46fe-a30d-4cc0d6c557c6@default>
Message-ID: <13600394-4084-dac7-3a0d-b6dfb84018e5@oracle.com>

No, it doesn't fix the issue, behavior remains as before the fix.

I've filed it yesterday:

https://bugs.openjdk.java.net/browse/JDK-8178448

Thanks,
Alexander.

On 13/04/2017 22:43, Sergey Bylokhov wrote:
> Hi, Alex.
> Are these changes fix the bug which we talked offline(you planned to file it separatly)?
>
> ----- alexander.zvegintsev at oracle.com wrote:
>
>> Actually it does nothing on Windows and Linux.
>>
>> Please review another version of the fix,
>>
>> it enables default menubar regardless of apple.laf.useScreenMenuBar
>> property
>>
>> and restores an old default MenuBarUI when it is used in JFrame.
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8177919/01/
>>
>> Thanks,
>> Alexander.
>>
>> On 11/04/2017 21:16, Phil Race wrote:
>>> I'd like to understand the big picture here
>>>
>>> Q1. What does this Desktop API do on Windows and Linux ?
>>>
>>> Q2. If someone calls this API it is pretty clear what they want.
>>>        Why do we require that they be running Aqua when a lot of the
>>> requests were
>>>         specifically about de-coupling it from Aqua?
>>>
>>>        It is not apparent to me why they must learn about an
>>> undocumented option to get
>>>        what they want. And the implNote is misleading (or wrong even)
>>> since there is a way
>>>        to do it without Aqua. It is just not advertised.
>>>
>>>        And it is *even weirder* to add that note if Mac is the only
>>> platform that supports this ...
>>>
>>> -phil.
>>>
>>> On 04/11/2017 08:41 AM, Alexander Zvegintsev wrote:
>>>> Hello,
>>>>
>>>> please review the fix
>>>>
>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8177919/00/
>>>>
>>>> for the issue
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8177919
>>>>
>>>> This fix removes throwing of ISE, this allows to use default menu
>> bar
>>>> with LaF's other than Aqua (with apple.laf.useScreenMenuBar set to
>>>> true).
>>>>
>>>> This became possible after JDK-8166683[0] fix.
>>>>
>>>> Current documentation of Desktop.setDefaultMenuBar() has
>> implnotes:
>>>>       * @implNote Aqua Look and Feel should be active to support
>> this
>>>> on Mac OS.
>>>>
>>>> I leave it unchanged, since I don't want to advertise the
>>>> apple.laf.useScreenMenuBar property.
>>>>
>>>> [0] https://bugs.openjdk.java.net/browse/JDK-8166683
>>>>
>>>>


From semyon.sadetsky at oracle.com  Thu Apr 13 21:45:13 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 13 Apr 2017 14:45:13 -0700
Subject: <AWT Dev> [10] Review request for 8132299: Test
 java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java fails on Linux
Message-ID: <c96a695d-f633-641a-3ef7-c34d7a62560e@oracle.com>

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8132299

webrev: http://cr.openjdk.java.net/~ssadetsky/8132299/webrev.00/

The issue itself is a linux/solaris specific. Alt-Gr modifier bit (1<<5) 
is not set in the KeyPress event which is sent by the closing key in the 
combination (which action should be modified). On platforms other than 
linux/solaris the ModifierRobotKeyTest.java successfully passes but 
takes a lot of time to execute.

Linux has two special keys assigned for 5th column as xmodmap command 
report:

mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

Java implementation uses Mode_switch native key for mapping to Alt-Gr. 
But Mode_switch is not processed as a modifier key by the native 
platform while ISO_Level3_Shift is processed as modifier. So, changing 
this mapping solves the problem.

Also, the ModifierRobotKeyTest.java is modified in the fix to decrease 
its execution time.

--Semyon


From semyon.sadetsky at oracle.com  Tue Apr 18 16:12:48 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 18 Apr 2017 09:12:48 -0700
Subject: <AWT Dev> [9] Review request for 8178905: Undercorated frame is not
 painted on OEL7(Gnome3).
Message-ID: <b679a00f-0b02-6b55-1280-3d99d1d52945@oracle.com>

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8178905

webrev: http://cr.openjdk.java.net/~ssadetsky/8178905/webrev.00/

When an undecorated window is initialized Gnome3 WM does not send the 
ConfigureNotify event which is must in the Linux AWT implementation to 
establish the correct frame content size.

The suggested fix introduces a check for the frame content was 
initialized upon the Expose notification and updates the content bounds 
if necessary.

--Semyon


From philip.race at oracle.com  Tue Apr 18 17:24:20 2017
From: philip.race at oracle.com (Phil Race)
Date: Tue, 18 Apr 2017 10:24:20 -0700
Subject: <AWT Dev> [9] Review request for 8178905: Undercorated frame is
 not painted on OEL7(Gnome3).
In-Reply-To: <b679a00f-0b02-6b55-1280-3d99d1d52945@oracle.com>
References: <b679a00f-0b02-6b55-1280-3d99d1d52945@oracle.com>
Message-ID: <ad4b09c1-775a-cc20-e3f1-74be77102f06@oracle.com>

Does this work if you programmatically resize the window
after initial display ?

Nit :  42         if(parentFrame.isTargetUndecorated() &&

"if(" -> "if (".

Also use corrected spelling when for the synopsis in the commit.

-phil.

On 04/18/2017 09:12 AM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8178905
>
> webrev: http://cr.openjdk.java.net/~ssadetsky/8178905/webrev.00/
>
> When an undecorated window is initialized Gnome3 WM does not send the 
> ConfigureNotify event which is must in the Linux AWT implementation to 
> establish the correct frame content size.
>
> The suggested fix introduces a check for the frame content was 
> initialized upon the Expose notification and updates the content 
> bounds if necessary.
>
> --Semyon
>


From semyon.sadetsky at oracle.com  Tue Apr 18 17:35:39 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 18 Apr 2017 10:35:39 -0700
Subject: <AWT Dev> [9] Review request for 8178905: Undercorated frame is
 not painted on OEL7(Gnome3).
In-Reply-To: <ad4b09c1-775a-cc20-e3f1-74be77102f06@oracle.com>
References: <b679a00f-0b02-6b55-1280-3d99d1d52945@oracle.com>
 <ad4b09c1-775a-cc20-e3f1-74be77102f06@oracle.com>
Message-ID: <0529d707-c8b6-d224-a35e-de7470f97192@oracle.com>

yes it works for programmatic resize (gnome sends ConfigureNotify in 
case of any size/location update).   It only doesn't work for 
initialization.

--Semyon

On 04/18/2017 10:24 AM, Phil Race wrote:
> Does this work if you programmatically resize the window
> after initial display ?
>
> Nit :  42         if(parentFrame.isTargetUndecorated() &&
>
> "if(" -> "if (".
>
> Also use corrected spelling when for the synopsis in the commit.
>
> -phil.
>
> On 04/18/2017 09:12 AM, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8178905
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8178905/webrev.00/
>>
>> When an undecorated window is initialized Gnome3 WM does not send the 
>> ConfigureNotify event which is must in the Linux AWT implementation 
>> to establish the correct frame content size.
>>
>> The suggested fix introduces a check for the frame content was 
>> initialized upon the Expose notification and updates the content 
>> bounds if necessary.
>>
>> --Semyon
>>
>


From philip.race at oracle.com  Tue Apr 18 18:02:57 2017
From: philip.race at oracle.com (Phil Race)
Date: Tue, 18 Apr 2017 11:02:57 -0700
Subject: <AWT Dev> [9] Review request for 8178905: Undercorated frame is
 not painted on OEL7(Gnome3).
In-Reply-To: <0529d707-c8b6-d224-a35e-de7470f97192@oracle.com>
References: <b679a00f-0b02-6b55-1280-3d99d1d52945@oracle.com>
 <ad4b09c1-775a-cc20-e3f1-74be77102f06@oracle.com>
 <0529d707-c8b6-d224-a35e-de7470f97192@oracle.com>
Message-ID: <a9d20349-970a-a214-9f47-544a6495244f@oracle.com>

In that case, ok once you fix the nit(s).

-phil.

On 04/18/2017 10:35 AM, Semyon Sadetsky wrote:
> yes it works for programmatic resize (gnome sends ConfigureNotify in 
> case of any size/location update).   It only doesn't work for 
> initialization.
>
> --Semyon
>
> On 04/18/2017 10:24 AM, Phil Race wrote:
>> Does this work if you programmatically resize the window
>> after initial display ?
>>
>> Nit :  42         if(parentFrame.isTargetUndecorated() &&
>>
>> "if(" -> "if (".
>>
>> Also use corrected spelling when for the synopsis in the commit.
>>
>> -phil.
>>
>> On 04/18/2017 09:12 AM, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8178905
>>>
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8178905/webrev.00/
>>>
>>> When an undecorated window is initialized Gnome3 WM does not send 
>>> the ConfigureNotify event which is must in the Linux AWT 
>>> implementation to establish the correct frame content size.
>>>
>>> The suggested fix introduces a check for the frame content was 
>>> initialized upon the Expose notification and updates the content 
>>> bounds if necessary.
>>>
>>> --Semyon
>>>
>>
>


From volker.simonis at gmail.com  Tue Apr 18 18:21:40 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 18 Apr 2017 20:21:40 +0200
Subject: <AWT Dev> [9] RFR(XXS): 8178911: Building of awt_Window.cpp fails
 on Windows with VS2010
Message-ID: <CA+3eh12mgiuqtgX8ugaWp4UH4FywY0rkSxBupj9306gX7ReM8w@mail.gmail.com>

Hi,

I'd kindly like to request the inclusion of the following trivial fix
into jdk9 to keep it buildable with VS2010:

http://cr.openjdk.java.net/~simonis/webrevs/2017/8178911/
https://bugs.openjdk.java.net/browse/JDK-8178911

I know that VS2010 isn't Oracle's default compiler for Windows, but
others like SAP are still using it. The fix for JDK-8175293 introduced
a struct assignment which is not supported by VS2010:

prevScaleRec = { -1, -1, -1 };

The fix is rather trivial and would keep the JDK9 sources buildable with VS2010:

prevScaleRec.scaleX = prevScaleRec.scaleY = prevScaleRec.screen = -1;

As this fix only removes some "syntactic sugar" I think it imposes no
risks at all. The benefits of being able to still build the complete
jdk 9 with VS2010 justifies in my opinion its inclusion into jdk9,
even at this stage.

Thank you and best regards,
Volker

From semyon.sadetsky at oracle.com  Tue Apr 18 19:07:10 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 18 Apr 2017 12:07:10 -0700
Subject: <AWT Dev> [9] Review request for 8081454: [TESTBUG]Some
 java/awt/Mixing tests fail in OEL 7 only
Message-ID: <75d43016-50ac-76ab-87e8-95bc60a4ef02@oracle.com>

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8081454

webrev: http://cr.openjdk.java.net/~ssadetsky/8081454/webrev.00/

A number test of issues specific for OEL 7 is fixed. Some of them are 
synchronization issues, some are related to different size of frame 
decoration on Gnome3 (mouse click occasionally falls to the minimize 
button). The rest test failures are addressed by JDK-8178905.

--Semyon


From yuri.nesterenko at oracle.com  Wed Apr 19 09:15:13 2017
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Wed, 19 Apr 2017 12:15:13 +0300
Subject: <AWT Dev> [9] Review request for 8081454: [TESTBUG]Some
 java/awt/Mixing tests fail in OEL 7 only
In-Reply-To: <75d43016-50ac-76ab-87e8-95bc60a4ef02@oracle.com>
References: <75d43016-50ac-76ab-87e8-95bc60a4ef02@oracle.com>
Message-ID: <814c2b30-4bd6-53af-a980-3fea62cc4b1e@oracle.com>

Hi Semyon,

in JComboBoxOverlapping.java, wouldn't it be better
to have some synchronization or a dumb delay after invokeAndWait?
loc2 and loc may be not ready on the main thread.
Perhaps making them volatile could help here?


Thanks,
-yan

On 04/18/2017 10:07 PM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8081454
>
> webrev: http://cr.openjdk.java.net/~ssadetsky/8081454/webrev.00/
>
> A number test of issues specific for OEL 7 is fixed. Some of them are
> synchronization issues, some are related to different size of frame
> decoration on Gnome3 (mouse click occasionally falls to the minimize
> button). The rest test failures are addressed by JDK-8178905.
>
> --Semyon
>


From sergey.bylokhov at oracle.com  Wed Apr 19 13:32:21 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Apr 2017 16:32:21 +0300
Subject: <AWT Dev> [9] RFR(XXS): 8178911: Building of awt_Window.cpp
 fails on Windows with VS2010
In-Reply-To: <CA+3eh12mgiuqtgX8ugaWp4UH4FywY0rkSxBupj9306gX7ReM8w@mail.gmail.com>
References: <CA+3eh12mgiuqtgX8ugaWp4UH4FywY0rkSxBupj9306gX7ReM8w@mail.gmail.com>
Message-ID: <21D1EDAB-64F7-4E47-A8F6-3797BCA1F05A@oracle.com>

Hi, Volker.
It seems that it was fixed already by
https://bugs.openjdk.java.net/browse/JDK-8177137 <https://bugs.openjdk.java.net/browse/JDK-8177137>
Will be available in jdk9-dev soon.

> 
> Hi,
> 
> I'd kindly like to request the inclusion of the following trivial fix
> into jdk9 to keep it buildable with VS2010:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2017/8178911/
> https://bugs.openjdk.java.net/browse/JDK-8178911
> 
> I know that VS2010 isn't Oracle's default compiler for Windows, but
> others like SAP are still using it. The fix for JDK-8175293 introduced
> a struct assignment which is not supported by VS2010:
> 
> prevScaleRec = { -1, -1, -1 };
> 
> The fix is rather trivial and would keep the JDK9 sources buildable with VS2010:
> 
> prevScaleRec.scaleX = prevScaleRec.scaleY = prevScaleRec.screen = -1;
> 
> As this fix only removes some "syntactic sugar" I think it imposes no
> risks at all. The benefits of being able to still build the complete
> jdk 9 with VS2010 justifies in my opinion its inclusion into jdk9,
> even at this stage.
> 
> Thank you and best regards,
> Volker

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170419/d6d33c11/attachment.html>

From sergey.bylokhov at oracle.com  Wed Apr 19 13:53:44 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Apr 2017 16:53:44 +0300
Subject: <AWT Dev> [9] Review request for 8178905: Undercorated frame is
 not painted on OEL7(Gnome3).
In-Reply-To: <b679a00f-0b02-6b55-1280-3d99d1d52945@oracle.com>
References: <b679a00f-0b02-6b55-1280-3d99d1d52945@oracle.com>
Message-ID: <1296F2B4-A99E-4FB8-8F73-94D618EB52BF@oracle.com>

Hi, Semyon.
A few questions:
 - Is it possible to add a test case for this bug? Since the bug was not found by sqe I assume we have no such tests.
 - Is the bug reproducible on jdk8?
 - Is it possible that parentFrame.isTargetUndecorated() may call the users code via XFramePeer->isTargetUndecorated()->Frame.isUndecorated()?
 - I suggest to create a standalone native application and send a bug report to the gnome3 team. Because next year it will be default on Ubuntu as well.


> 
> Hello,
> 
> Please review fix for JDK9:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8178905
> 
> webrev: http://cr.openjdk.java.net/~ssadetsky/8178905/webrev.00/
> 
> When an undecorated window is initialized Gnome3 WM does not send the ConfigureNotify event which is must in the Linux AWT implementation to establish the correct frame content size.
> 
> The suggested fix introduces a check for the frame content was initialized upon the Expose notification and updates the content bounds if necessary.
> 
> --Semyon
> 


From volker.simonis at gmail.com  Wed Apr 19 12:09:44 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 19 Apr 2017 14:09:44 +0200
Subject: <AWT Dev> [9] RFR(XXS): 8178911: Building of awt_Window.cpp
 fails on Windows with VS2010
In-Reply-To: <21D1EDAB-64F7-4E47-A8F6-3797BCA1F05A@oracle.com>
References: <CA+3eh12mgiuqtgX8ugaWp4UH4FywY0rkSxBupj9306gX7ReM8w@mail.gmail.com>
 <21D1EDAB-64F7-4E47-A8F6-3797BCA1F05A@oracle.com>
Message-ID: <CA+3eh11BekNYkEt9K0=JAnHcRvRpshqqBpPJ0iZ-EqFRYP9Lgg@mail.gmail.com>

Cool!
I totally forgot about the jdk9-client repository :)
I'll close the new bug as duplicate.

Thanks,
Volker


On Wed, Apr 19, 2017 at 3:32 PM, Sergey Bylokhov
<sergey.bylokhov at oracle.com> wrote:
> Hi, Volker.
> It seems that it was fixed already by
> https://bugs.openjdk.java.net/browse/JDK-8177137
> Will be available in jdk9-dev soon.
>
>
> Hi,
>
> I'd kindly like to request the inclusion of the following trivial fix
> into jdk9 to keep it buildable with VS2010:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2017/8178911/
> https://bugs.openjdk.java.net/browse/JDK-8178911
>
> I know that VS2010 isn't Oracle's default compiler for Windows, but
> others like SAP are still using it. The fix for JDK-8175293 introduced
> a struct assignment which is not supported by VS2010:
>
> prevScaleRec = { -1, -1, -1 };
>
> The fix is rather trivial and would keep the JDK9 sources buildable with
> VS2010:
>
> prevScaleRec.scaleX = prevScaleRec.scaleY = prevScaleRec.screen = -1;
>
> As this fix only removes some "syntactic sugar" I think it imposes no
> risks at all. The benefits of being able to still build the complete
> jdk 9 with VS2010 justifies in my opinion its inclusion into jdk9,
> even at this stage.
>
> Thank you and best regards,
> Volker
>
>

From sergey.bylokhov at oracle.com  Wed Apr 19 17:29:06 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Apr 2017 20:29:06 +0300
Subject: <AWT Dev> [9] Review Request: 8178971 Uncommon formatting and typos
 in java.desktop module
Message-ID: <05049645-5C53-4BDB-A25F-670A7A82E253@oracle.com>

Hello,
Please review the fix for jdk9.

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

 - Two typos were fixed in AbstractMultiResolutionImage.java(incorrect tag) and java/awt/package-info.java("con tainer"instead of "container")
 - The code formatting was fixed in "module-info.java", it seems that different iterations of modules refresh patches used a different line wrapping and code shifting(4 or 5 spaces)
 - In java sound there are a few places where we replace tabs to spaces and this caused strange alignment of constants


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170419/5711b14c/attachment.html>

From semyon.sadetsky at oracle.com  Wed Apr 19 15:08:28 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 19 Apr 2017 08:08:28 -0700
Subject: <AWT Dev> [9] Review request for 8081454: [TESTBUG]Some
 java/awt/Mixing tests fail in OEL 7 only
In-Reply-To: <814c2b30-4bd6-53af-a980-3fea62cc4b1e@oracle.com>
References: <75d43016-50ac-76ab-87e8-95bc60a4ef02@oracle.com>
 <814c2b30-4bd6-53af-a980-3fea62cc4b1e@oracle.com>
Message-ID: <0d3421cc-37ae-c9d8-fd29-985b3d97a1b3@oracle.com>

Hi Yuri,

The getLocationOnScreen() method is executed synchronously on all 
platforms. Since the invokeAndWait() version is used to query location 
there is no need in any extra waiting for the location value.

I inserted delay before the location request because the window may not 
be shown yet or its final dimensions may not be established. Window 
showing is asynchronous and can takes significant time on some platforms.

--Semyon


On 04/19/2017 02:15 AM, Yuri Nesterenko wrote:
> Hi Semyon,
>
> in JComboBoxOverlapping.java, wouldn't it be better
> to have some synchronization or a dumb delay after invokeAndWait?
> loc2 and loc may be not ready on the main thread.
> Perhaps making them volatile could help here?
>
>
> Thanks,
> -yan
>
> On 04/18/2017 10:07 PM, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8081454
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8081454/webrev.00/
>>
>> A number test of issues specific for OEL 7 is fixed. Some of them are
>> synchronization issues, some are related to different size of frame
>> decoration on Gnome3 (mouse click occasionally falls to the minimize
>> button). The rest test failures are addressed by JDK-8178905.
>>
>> --Semyon
>>
>


From semyon.sadetsky at oracle.com  Wed Apr 19 15:19:29 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 19 Apr 2017 08:19:29 -0700
Subject: <AWT Dev> [9] Review request for 8178905: Undercorated frame is
 not painted on OEL7(Gnome3).
In-Reply-To: <1296F2B4-A99E-4FB8-8F73-94D618EB52BF@oracle.com>
References: <b679a00f-0b02-6b55-1280-3d99d1d52945@oracle.com>
 <1296F2B4-A99E-4FB8-8F73-94D618EB52BF@oracle.com>
Message-ID: <5e923bda-3908-70ed-217b-acd65e32b69c@oracle.com>

Actually, a lot of SQE test falls on OEL7 because of this bug. For 
example, the one which is linked to the JIRA issue.
As it is pointed in JIRA the bug is reproducible in JDK8.
Frame.isUndecorated() is not called here because the peer field is used.

--Semyon

On 04/19/2017 06:53 AM, Sergey Bylokhov wrote:
> Hi, Semyon.
> A few questions:
>   - Is it possible to add a test case for this bug? Since the bug was not found by sqe I assume we have no such tests.
>   - Is the bug reproducible on jdk8?
>   - Is it possible that parentFrame.isTargetUndecorated() may call the users code via XFramePeer->isTargetUndecorated()->Frame.isUndecorated()?
>   - I suggest to create a standalone native application and send a bug report to the gnome3 team. Because next year it will be default on Ubuntu as well.
>
>
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8178905
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8178905/webrev.00/
>>
>> When an undecorated window is initialized Gnome3 WM does not send the ConfigureNotify event which is must in the Linux AWT implementation to establish the correct frame content size.
>>
>> The suggested fix introduces a check for the frame content was initialized upon the Expose notification and updates the content bounds if necessary.
>>
>> --Semyon
>>


From semyon.sadetsky at oracle.com  Wed Apr 19 16:02:02 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 19 Apr 2017 09:02:02 -0700
Subject: <AWT Dev> [9] Review Request: 8178971 Uncommon formatting and
 typos in java.desktop module
In-Reply-To: <05049645-5C53-4BDB-A25F-670A7A82E253@oracle.com>
References: <05049645-5C53-4BDB-A25F-670A7A82E253@oracle.com>
Message-ID: <6616cef7-9dad-876c-7184-ae98bdea3f8f@oracle.com>

On 04/19/2017 10:29 AM, Sergey Bylokhov wrote:

> Hello,
> Please review the fix for jdk9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178971
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8178971/webrev.00 
> <http://cr.openjdk.java.net/%7Eserb/8178971/webrev.00>
> Webrev which ignores spaces: 
> http://cr.openjdk.java.net/~serb/8178971/webrev_no_space.00 
> <http://cr.openjdk.java.net/%7Eserb/8178971/webrev_no_space.00>
>
>  - Two typos were fixed in AbstractMultiResolutionImage.java(incorrect 
> tag) and java/awt/package-info.java("con tainer"instead of "container")
>  - The code formatting was fixed in "module-info.java", it seems that 
> different iterations of modules refresh patches used a different line 
> wrapping and code shifting(4 or 5 spaces)
>  - In java sound there are a few places where we replace tabs to 
> spaces and this caused strange alignment of constants
Same issues can be found in so many classes of java.desktop

grep -rE 
"\\S+\\s{2,}=|\\S+=\\s{2,}\S+|^\\s{5,5}(public|private|static|final|void)" 
--include \*.java jdk/src/java.desktop | wc -l

2685 !!!

Why you decided to fix only those several?

-Semyon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170419/511477ab/attachment.html>

From sergey.bylokhov at oracle.com  Wed Apr 19 19:43:38 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Apr 2017 22:43:38 +0300
Subject: <AWT Dev> [9] Review Request: 8178971 Uncommon formatting and
 typos in java.desktop module
In-Reply-To: <6616cef7-9dad-876c-7184-ae98bdea3f8f@oracle.com>
References: <05049645-5C53-4BDB-A25F-670A7A82E253@oracle.com>
 <6616cef7-9dad-876c-7184-ae98bdea3f8f@oracle.com>
Message-ID: <3FCC3F70-C0E3-4344-8017-89A8B4D05461@oracle.com>

>> 
> Same issues can be found in so many classes of java.desktop
> 
> grep -rE "\\S+\\s{2,}=|\\S+=\\s{2,}\S+|^\\s{5,5}(public|private|static|final|void)" --include \*.java jdk/src/java.desktop | wc -l
> 
> 2685 !!!
> 
> Why you decided to fix only those several?

This change fix the problem in the public api of java sound which were produced by replacing of tabs to spaces. If you take a look to the output of your grep you will see that it find something different.


From sergey.bylokhov at oracle.com  Wed Apr 19 19:45:47 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Apr 2017 22:45:47 +0300
Subject: <AWT Dev> [9] Review request for 8178905: Undercorated frame is
 not painted on OEL7(Gnome3).
In-Reply-To: <5e923bda-3908-70ed-217b-acd65e32b69c@oracle.com>
References: <b679a00f-0b02-6b55-1280-3d99d1d52945@oracle.com>
 <1296F2B4-A99E-4FB8-8F73-94D618EB52BF@oracle.com>
 <5e923bda-3908-70ed-217b-acd65e32b69c@oracle.com>
Message-ID: <F0E77935-9F2D-47AA-AF78-56697F968F60@oracle.com>

> 
> Actually, a lot of SQE test falls on OEL7 because of this bug. For example, the one which is linked to the JIRA issue.
> As it is pointed in JIRA the bug is reproducible in JDK8.

Then it is strange that those bugs from sqe was not reported on jdk8. I have run the test from the description of this bug and tests which were reported by Yury on my Ubuntu+gnome3 and all of them passed.
Can you please try to install the latest updates on OEL7(on my system Gnome 3.18 is installed).

> Frame.isUndecorated() is not called here because the peer field is used.
> 
> --Semyon
> 
> On 04/19/2017 06:53 AM, Sergey Bylokhov wrote:
>> Hi, Semyon.
>> A few questions:
>>  - Is it possible to add a test case for this bug? Since the bug was not found by sqe I assume we have no such tests.
>>  - Is the bug reproducible on jdk8?
>>  - Is it possible that parentFrame.isTargetUndecorated() may call the users code via XFramePeer->isTargetUndecorated()->Frame.isUndecorated()?
>>  - I suggest to create a standalone native application and send a bug report to the gnome3 team. Because next year it will be default on Ubuntu as well.
>> 
>> 
>>> Hello,
>>> 
>>> Please review fix for JDK9:
>>> 
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8178905
>>> 
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8178905/webrev.00/
>>> 
>>> When an undecorated window is initialized Gnome3 WM does not send the ConfigureNotify event which is must in the Linux AWT implementation to establish the correct frame content size.
>>> 
>>> The suggested fix introduces a check for the frame content was initialized upon the Expose notification and updates the content bounds if necessary.
>>> 
>>> --Semyon
>>> 
> 


From philip.race at oracle.com  Wed Apr 19 17:00:08 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 19 Apr 2017 10:00:08 -0700
Subject: <AWT Dev> <Sound Dev> [9] Review Request: 8178971 Uncommon
 formatting and typos in java.desktop module
In-Reply-To: <05049645-5C53-4BDB-A25F-670A7A82E253@oracle.com>
References: <05049645-5C53-4BDB-A25F-670A7A82E253@oracle.com>
Message-ID: <1d8d0531-c93a-4703-9258-085e0784b045@oracle.com>

+1

-phil.

On 04/19/2017 10:29 AM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178971
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8178971/webrev.00 
> <http://cr.openjdk.java.net/%7Eserb/8178971/webrev.00>
> Webrev which ignores spaces: 
> http://cr.openjdk.java.net/~serb/8178971/webrev_no_space.00 
> <http://cr.openjdk.java.net/%7Eserb/8178971/webrev_no_space.00>
>
>  - Two typos were fixed in AbstractMultiResolutionImage.java(incorrect 
> tag) and java/awt/package-info.java("con tainer"instead of "container")
>  - The code formatting was fixed in "module-info.java", it seems that 
> different iterations of modules refresh patches used a different line 
> wrapping and code shifting(4 or 5 spaces)
>  - In java sound there are a few places where we replace tabs to 
> spaces and this caused strange alignment of constants
>
>


From semyon.sadetsky at oracle.com  Wed Apr 19 17:03:20 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 19 Apr 2017 10:03:20 -0700
Subject: <AWT Dev> [9] Review Request: 8178971 Uncommon formatting and
 typos in java.desktop module
In-Reply-To: <3FCC3F70-C0E3-4344-8017-89A8B4D05461@oracle.com>
References: <05049645-5C53-4BDB-A25F-670A7A82E253@oracle.com>
 <6616cef7-9dad-876c-7184-ae98bdea3f8f@oracle.com>
 <3FCC3F70-C0E3-4344-8017-89A8B4D05461@oracle.com>
Message-ID: <39c94d1b-2222-8adb-2666-652e5a2e265d@oracle.com>

On 04/19/2017 12:43 PM, Sergey Bylokhov wrote:

>> Same issues can be found in so many classes of java.desktop
>>
>> grep -rE "\\S+\\s{2,}=|\\S+=\\s{2,}\S+|^\\s{5,5}(public|private|static|final|void)" --include \*.java jdk/src/java.desktop | wc -l
>>
>> 2685 !!!
>>
>> Why you decided to fix only those several?
> This change fix the problem in the public api of java sound which were produced by replacing of tabs to spaces. If you take a look to the output of your grep you will see that it find something different.
>
In this grep output I see absolutely the same 5 spaces indentation 
instead of 4 spaces, multiple spaces  around "=".
The source of those formatting issues maybe the same (replacing tabs by 
spaces). And I did not get why the source is important?

 From the descripton of the bug you pretend:

"Uncommon formatting and typos in java.desktop module"

Then why only javax.sound is considered? A bug tittle issue?

But this contradicts to the webrev you've sent because it contains

src/java.desktop/share/classes/java/awt/image/AbstractMultiResolutionImage.java
src/java.desktop/share/classes/java/awt/package-info.java
src/java.desktop/share/classes/module-info.java

files which are outside javax.sound AFAIK.

Also,

src/java.desktop/share/classes/javax/swing/JComponent.java

3738         * the same functionality and it is handled in {@Component}.

should this mistake be corrected? JComponent is also a public API.

--Semyon







From semyon.sadetsky at oracle.com  Wed Apr 19 17:07:29 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 19 Apr 2017 10:07:29 -0700
Subject: <AWT Dev> [9] Review request for 8178905: Undercorated frame is
 not painted on OEL7(Gnome3).
In-Reply-To: <F0E77935-9F2D-47AA-AF78-56697F968F60@oracle.com>
References: <b679a00f-0b02-6b55-1280-3d99d1d52945@oracle.com>
 <1296F2B4-A99E-4FB8-8F73-94D618EB52BF@oracle.com>
 <5e923bda-3908-70ed-217b-acd65e32b69c@oracle.com>
 <F0E77935-9F2D-47AA-AF78-56697F968F60@oracle.com>
Message-ID: <3664d80d-e133-1bd4-55fa-90d214730e13@oracle.com>

On 04/19/2017 12:45 PM, Sergey Bylokhov wrote:

>> Actually, a lot of SQE test falls on OEL7 because of this bug. For example, the one which is linked to the JIRA issue.
>> As it is pointed in JIRA the bug is reproducible in JDK8.
> Then it is strange that those bugs from sqe was not reported on jdk8. I have run the test from the description of this bug and tests which were reported by Yury on my Ubuntu+gnome3 and all of them passed.
> Can you please try to install the latest updates on OEL7(on my system Gnome 3.18 is installed).
I have the latest OEL 7.3 installed from scratch. And I remember that I 
could not reproduce this bug on some older OEL 7 version. You need to 
test on the latest OEL 7 update.
>
>> Frame.isUndecorated() is not called here because the peer field is used.
>>
>> --Semyon
>>
>> On 04/19/2017 06:53 AM, Sergey Bylokhov wrote:
>>> Hi, Semyon.
>>> A few questions:
>>>   - Is it possible to add a test case for this bug? Since the bug was not found by sqe I assume we have no such tests.
>>>   - Is the bug reproducible on jdk8?
>>>   - Is it possible that parentFrame.isTargetUndecorated() may call the users code via XFramePeer->isTargetUndecorated()->Frame.isUndecorated()?
>>>   - I suggest to create a standalone native application and send a bug report to the gnome3 team. Because next year it will be default on Ubuntu as well.
>>>
>>>
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8178905
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8178905/webrev.00/
>>>>
>>>> When an undecorated window is initialized Gnome3 WM does not send the ConfigureNotify event which is must in the Linux AWT implementation to establish the correct frame content size.
>>>>
>>>> The suggested fix introduces a check for the frame content was initialized upon the Expose notification and updates the content bounds if necessary.
>>>>
>>>> --Semyon
>>>>


From sergey.bylokhov at oracle.com  Wed Apr 19 21:23:11 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 20 Apr 2017 00:23:11 +0300
Subject: <AWT Dev> [9] Review Request: 8178971 Uncommon formatting and
 typos in java.desktop module
In-Reply-To: <39c94d1b-2222-8adb-2666-652e5a2e265d@oracle.com>
References: <05049645-5C53-4BDB-A25F-670A7A82E253@oracle.com>
 <6616cef7-9dad-876c-7184-ae98bdea3f8f@oracle.com>
 <3FCC3F70-C0E3-4344-8017-89A8B4D05461@oracle.com>
 <39c94d1b-2222-8adb-2666-652e5a2e265d@oracle.com>
Message-ID: <D071EBAB-D7B7-4022-B052-F77AD2E2FCBF@oracle.com>

>> 
> In this grep output I see absolutely the same 5 spaces indentation instead of 4 spaces, multiple spaces  around "=".
> The source of those formatting issues maybe the same (replacing tabs by spaces). And I did not get why the source is important?

Its is unimportant because most of them are not in the public API, some of them are aligned intentionally, but if you will find something useful feel free to file it file it and fix.

> 
> From the descripton of the bug you pretend:
> 
> "Uncommon formatting and typos in java.desktop module"
> 
> Then why only javax.sound is considered? A bug tittle issue?

Did you read the text which were in the first email, which describe what things were fixed?  

> 
> But this contradicts to the webrev you've sent because it contains
> 
> src/java.desktop/share/classes/java/awt/image/AbstractMultiResolutionImage.java
> src/java.desktop/share/classes/java/awt/package-info.java
> src/java.desktop/share/classes/module-info.java
> 
> files which are outside javax.sound AFAIK.

Just reread an initial message which has 3 points.

> 
> Also,
> 
> src/java.desktop/share/classes/javax/swing/JComponent.java
> 
> 3738         * the same functionality and it is handled in {@Component}.
> 
> should this mistake be corrected? JComponent is also a public API.

Yes, it should be fixed. This line was added after I created the patch. The new version is here:
http://cr.openjdk.java.net/~serb/8178971/webrev.01

From semyon.sadetsky at oracle.com  Wed Apr 19 19:10:00 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 19 Apr 2017 12:10:00 -0700
Subject: <AWT Dev> [9] Review Request: 8178971 Uncommon formatting and
 typos in java.desktop module
In-Reply-To: <D071EBAB-D7B7-4022-B052-F77AD2E2FCBF@oracle.com>
References: <05049645-5C53-4BDB-A25F-670A7A82E253@oracle.com>
 <6616cef7-9dad-876c-7184-ae98bdea3f8f@oracle.com>
 <3FCC3F70-C0E3-4344-8017-89A8B4D05461@oracle.com>
 <39c94d1b-2222-8adb-2666-652e5a2e265d@oracle.com>
 <D071EBAB-D7B7-4022-B052-F77AD2E2FCBF@oracle.com>
Message-ID: <dfacd5e6-bd6e-4429-bc7e-4471edacc1ff@oracle.com>

On 04/19/2017 02:23 PM, Sergey Bylokhov wrote:
>> In this grep output I see absolutely the same 5 spaces indentation instead of 4 spaces, multiple spaces  around "=".
>> The source of those formatting issues maybe the same (replacing tabs by spaces). And I did not get why the source is important?
> Its is unimportant because most of them are not in the public API, some of them are aligned intentionally, but if you will find something useful feel free to file it file it and fix.
I see a lot of such formatting issues (hundreds) in public APIs. Are you 
proposing to create bugs per each of them?
Why not fix them in this bug? This is very easy and harmless.
>
>>  From the descripton of the bug you pretend:
>>
>> "Uncommon formatting and typos in java.desktop module"
>>
>> Then why only javax.sound is considered? A bug tittle issue?
> Did you read the text which were in the first email, which describe what things were fixed?
Yes, I did. But it doesn't correspond to JIRA's title and description.
>
>> But this contradicts to the webrev you've sent because it contains
>>
>> src/java.desktop/share/classes/java/awt/image/AbstractMultiResolutionImage.java
>> src/java.desktop/share/classes/java/awt/package-info.java
>> src/java.desktop/share/classes/module-info.java
>>
>> files which are outside javax.sound AFAIK.
> Just reread an initial message which has 3 points.
>
>> Also,
>>
>> src/java.desktop/share/classes/javax/swing/JComponent.java
>>
>> 3738         * the same functionality and it is handled in {@Component}.
>>
>> should this mistake be corrected? JComponent is also a public API.
> Yes, it should be fixed. This line was added after I created the patch. The new version is here:
> http://cr.openjdk.java.net/~serb/8178971/webrev.01
Thanks. Yet another one:

src/java.desktop/share/classes/javax/swing/text/html/AccessibleHTML.java

1655             * @gsee #getAccessibleChild

I suggest to grep code for javadoc keywords (@...) typos.

--Semyon





From sergey.bylokhov at oracle.com  Wed Apr 19 22:32:48 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 20 Apr 2017 01:32:48 +0300
Subject: <AWT Dev> [9] Review Request: 8178971 Uncommon formatting and
 typos in java.desktop module
In-Reply-To: <dfacd5e6-bd6e-4429-bc7e-4471edacc1ff@oracle.com>
References: <05049645-5C53-4BDB-A25F-670A7A82E253@oracle.com>
 <6616cef7-9dad-876c-7184-ae98bdea3f8f@oracle.com>
 <3FCC3F70-C0E3-4344-8017-89A8B4D05461@oracle.com>
 <39c94d1b-2222-8adb-2666-652e5a2e265d@oracle.com>
 <D071EBAB-D7B7-4022-B052-F77AD2E2FCBF@oracle.com>
 <dfacd5e6-bd6e-4429-bc7e-4471edacc1ff@oracle.com>
Message-ID: <C5CD8ADA-E002-42D5-B91F-06F545973646@oracle.com>

>> Its is unimportant because most of them are not in the public API, some of them are aligned intentionally, but if you will find something useful feel free to file it file it and fix.
> I see a lot of such formatting issues (hundreds) in public APIs. Are you proposing to create bugs per each of them?
> Why not fix them in this bug? This is very easy and harmless.

Why hundreds? In the previous email you mention 2500 issues, so feel free to file them and fix.
I fixed an issues which I found when I reread the specification of the methods and tried to find a typos in it.

>> 
>>> From the descripton of the bug you pretend:
>>> 
>>> "Uncommon formatting and typos in java.desktop module"
>>> 
>>> Then why only javax.sound is considered? A bug tittle issue?
>> Did you read the text which were in the first email, which describe what things were fixed?
> Yes, I did. But it doesn't correspond to JIRA's title and description.

I updated description of the bug.

>> 
>>> But this contradicts to the webrev you've sent because it contains
> 
> src/java.desktop/share/classes/javax/swing/text/html/AccessibleHTML.java
> 
> 1655             * @gsee #getAccessibleChild
> 
> I suggest to grep code for javadoc keywords (@...) typos.

This is not a public API.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170420/ba59566d/attachment.html>

From semyon.sadetsky at oracle.com  Wed Apr 19 20:38:30 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 19 Apr 2017 13:38:30 -0700
Subject: <AWT Dev> [9] Review Request: 8178971 Uncommon formatting and
 typos in java.desktop module
In-Reply-To: <C5CD8ADA-E002-42D5-B91F-06F545973646@oracle.com>
References: <05049645-5C53-4BDB-A25F-670A7A82E253@oracle.com>
 <6616cef7-9dad-876c-7184-ae98bdea3f8f@oracle.com>
 <3FCC3F70-C0E3-4344-8017-89A8B4D05461@oracle.com>
 <39c94d1b-2222-8adb-2666-652e5a2e265d@oracle.com>
 <D071EBAB-D7B7-4022-B052-F77AD2E2FCBF@oracle.com>
 <dfacd5e6-bd6e-4429-bc7e-4471edacc1ff@oracle.com>
 <C5CD8ADA-E002-42D5-B91F-06F545973646@oracle.com>
Message-ID: <4cfdbc5e-40b1-8a28-41b6-c15649cb7bff@oracle.com>

On 04/19/2017 03:32 PM, Sergey Bylokhov wrote:

>>> Its is unimportant because most of them are not in the public API, 
>>> some of them are aligned intentionally, but if you will find 
>>> something useful feel free to file it file it and fix.
>> I see a lot of such formatting issues (hundreds) in public APIs. Are 
>> you proposing to create bugs per each of them?
>> Why not fix them in this bug? This is very easy and harmless.
>
> Why hundreds? In the previous email you mention 2500 issues, so feel 
> free to file them and fix.
> I fixed an issues which I found when I reread the specification of the 
> methods and tried to find a typos in it.
In this situation I'd suggest to grep for similar typos in the rest 
code. It is not time consumptive.
>
>>>
>>>> From the descripton of the bug you pretend:
>>>>
>>>> "Uncommon formatting and typos in java.desktop module"
>>>>
>>>> Then why only javax.sound is considered? A bug tittle issue?
>>> Did you read the text which were in the first email, which describe 
>>> what things were fixed?
>> Yes, I did. But it doesn't correspond to JIRA's title and description.
>
> I updated description of the bug.\
When I was reading the JIRA I've decided that the purpose of the bug is 
to search and cleanup all javadoc and formatting issues in java.desktop 
module. Next time please use something like "Several typos and 
formatting issues."...
>
>>>
>>>> But this contradicts to the webrev you've sent because it contains
>>
>> src/java.desktop/share/classes/javax/swing/text/html/AccessibleHTML.java
>>
>> 1655             * @gsee #getAccessibleChild
>>
>> I suggest to grep code for javadoc keywords (@...) typos.
>
> This is not a public API.

Okay. Looks good.

--Semyon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170419/1dd9852d/attachment-0001.html>

From ambarish.rapte at oracle.com  Thu Apr 20 05:13:16 2017
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Wed, 19 Apr 2017 22:13:16 -0700 (PDT)
Subject: <AWT Dev> [10] Review request for 8132299: Test
 java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java fails on Linux
In-Reply-To: <c96a695d-f633-641a-3ef7-c34d7a62560e@oracle.com>
References: <c96a695d-f633-641a-3ef7-c34d7a62560e@oracle.com>
Message-ID: <446d830a-5b26-4ff9-a96c-9a58aa472934@default>

Hi Semyon,
	Fix looks good to me.
Regards,
Ambarish

-----Original Message-----
From: Semyon Sadetsky 
Sent: Friday, April 14, 2017 3:15 AM
To: awt-dev
Subject: <AWT Dev> [10] Review request for 8132299: Test java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java fails on Linux

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8132299

webrev: http://cr.openjdk.java.net/~ssadetsky/8132299/webrev.00/

The issue itself is a linux/solaris specific. Alt-Gr modifier bit (1<<5) is not set in the KeyPress event which is sent by the closing key in the combination (which action should be modified). On platforms other than linux/solaris the ModifierRobotKeyTest.java successfully passes but takes a lot of time to execute.

Linux has two special keys assigned for 5th column as xmodmap command
report:

mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

Java implementation uses Mode_switch native key for mapping to Alt-Gr. 
But Mode_switch is not processed as a modifier key by the native platform while ISO_Level3_Shift is processed as modifier. So, changing this mapping solves the problem.

Also, the ModifierRobotKeyTest.java is modified in the fix to decrease its execution time.

--Semyon


From yuri.nesterenko at oracle.com  Thu Apr 20 07:47:48 2017
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Thu, 20 Apr 2017 10:47:48 +0300
Subject: <AWT Dev> [9] Review request for 8081454: [TESTBUG]Some
 java/awt/Mixing tests fail in OEL 7 only
In-Reply-To: <0d3421cc-37ae-c9d8-fd29-985b3d97a1b3@oracle.com>
References: <75d43016-50ac-76ab-87e8-95bc60a4ef02@oracle.com>
 <814c2b30-4bd6-53af-a980-3fea62cc4b1e@oracle.com>
 <0d3421cc-37ae-c9d8-fd29-985b3d97a1b3@oracle.com>
Message-ID: <847a41e1-fe3b-8e62-22e0-434d4c52dabd@oracle.com>

+1, then.

-yan

On 04/19/2017 06:08 PM, Semyon Sadetsky wrote:
> Hi Yuri,
>
> The getLocationOnScreen() method is executed synchronously on all
> platforms. Since the invokeAndWait() version is used to query location
> there is no need in any extra waiting for the location value.
>
> I inserted delay before the location request because the window may not
> be shown yet or its final dimensions may not be established. Window
> showing is asynchronous and can takes significant time on some platforms.
>
> --Semyon
>
>
> On 04/19/2017 02:15 AM, Yuri Nesterenko wrote:
>> Hi Semyon,
>>
>> in JComboBoxOverlapping.java, wouldn't it be better
>> to have some synchronization or a dumb delay after invokeAndWait?
>> loc2 and loc may be not ready on the main thread.
>> Perhaps making them volatile could help here?
>>
>>
>> Thanks,
>> -yan
>>
>> On 04/18/2017 10:07 PM, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8081454
>>>
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8081454/webrev.00/
>>>
>>> A number test of issues specific for OEL 7 is fixed. Some of them are
>>> synchronization issues, some are related to different size of frame
>>> decoration on Gnome3 (mouse click occasionally falls to the minimize
>>> button). The rest test failures are addressed by JDK-8178905.
>>>
>>> --Semyon
>>>
>>
>


From sergey.bylokhov at oracle.com  Fri Apr 21 08:21:23 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 21 Apr 2017 01:21:23 -0700 (PDT)
Subject: <AWT Dev> [9] Review request for 8178905: Undercorated frame is
 not painted on OEL7(Gnome3).
Message-ID: <1369f71d-1e27-4b40-b732-ae6b7342f17d@default>

----- semyon.sadetsky at oracle.com wrote:
> I have the latest OEL 7.3 installed from scratch. And I remember that
> I 
> could not reproduce this bug on some older OEL 7 version. You need to

ok, then it looks like a regression in the OEL/RHEL 7.3 (the bug is related to the gnome3 in these distrs).
The current fix looks fine, but I suggest also to file a bug for OEL/RHEL. Since the bug affects Openjdk7/jdk8/jdk9 and probably icedtea

Mario, Can you please take a look?
Thanks.

From semyon.sadetsky at oracle.com  Fri Apr 21 16:36:25 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 21 Apr 2017 09:36:25 -0700
Subject: <AWT Dev> [9] Review request for 8159451: [TEST_BUG]
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java
In-Reply-To: <A25D585D-17E7-42DE-9CF8-C9C31614D334@oracle.com>
References: <a0fe536e-911f-5a18-2e11-51c6ed8ef458@oracle.com>
 <12e16da4-d106-a527-0fda-3e249029bae7@oracle.com>
 <c5f32bae-a7f4-d473-a766-74ab03308501@oracle.com>
 <A25D585D-17E7-42DE-9CF8-C9C31614D334@oracle.com>
Message-ID: <f313bf24-652b-242f-db85-3e35b03e1515@oracle.com>

On 04/06/2017 11:34 AM, Sergey Bylokhov wrote:
>> 6 ???. 2017 ?., ? 11:32, Yuri Nesterenko <yuri.nesterenko at oracle.com> ???????(?):
>>
>> Phil,
>>
>> it's more or less realistic, yes.
>> It paints various controls, many of them, clicks several times,
>> than repeats everything again for embedded frame.
>> On some platforms if you do it too fast,
>> you just cannot be sure the control is ready to receive a click.
> But isn?t 500 ms is a quite big value for the robot autodelay?
It may be necessary for some platforms. It would be risky to change it. 
May be the test author (Yuri) can comment.

--Semyon
>
>> And, my +1 here.
>>
>> -yan
>>
>> On 04/06/2017 12:21 AM, Phil Race wrote:
>>> No objection per se, but thinking aloud ..
>>> The default jtreg timeout is 2 minutes .. you are upping to 4 minutes.
>>> Can the test be made more efficient, or is that a realistic time based
>>> on what it tests ?
>>>
>>> -phil.
>>>
>>> On 04/05/2017 11:25 AM, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8159451
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8159451/webrev.00/
>>>>
>>>> The timeout is increased.
>>>>
>>>> --Semyon
>>>>


From philip.race at oracle.com  Wed Apr 26 18:43:15 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 26 Apr 2017 11:43:15 -0700
Subject: <AWT Dev> RFR: 8179365 : JAWT (AWT Native Interface) specification
 needs to be updated for JDK 9
Message-ID: <d2fcd503-aa7f-32b2-fee4-89f0abb58f81@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8179365
webrev: http://cr.openjdk.java.net/~prr/8179365/

the JAWT spec as currently published has not been maintained
http://docs.oracle.com/javase/8/docs/technotes/guides/awt/AWT_Native_Interface.html

and worse that location will not be published for 9.
Also the spec needs to be updated for 9 to document the EmbeddedFrame 
support.

This moves the JAWT spec into the new "spec" area specified by JEP 299 (see
the bug report for links on that) and will ensure that JAWT will be 
documented in 9.

As well as documenting the missing APIs (including some from earlier 
releases)
it "freshens" the textual parts of the document.

Since the "spec" part is essentially a regurgitation of the header files 
those
had a few updates too. And the Mac one was not previously listed.

-phil.



From semyon.sadetsky at oracle.com  Thu Apr 27 19:09:28 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 27 Apr 2017 12:09:28 -0700
Subject: <AWT Dev> [9] Review request for 8160530: [TEST-BUG] Consistent
 failure of
 java/awt/dnd/MissingEventsOnModalDialog/MissingEventsOnModalDialogTest.java
Message-ID: <bc78f61d-f859-220d-122f-026f52541e5f@oracle.com>

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8160530

webrev: http://cr.openjdk.java.net/~ssadetsky/8160530/webrev.00/

To issues are being fixed. The first, Delay was increased for the test 
stability on various platforms. The second, getting true from 
Dialog::isVisible() doesn't mean that dialog is shown on the screen and 
clickable.

Tested on Ubuntu 16.04, OEL 7.3 and Solaris 11.3 with single and dual 
screen.

--Semyon


From semyon.sadetsky at oracle.com  Thu Apr 27 19:28:39 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 27 Apr 2017 12:28:39 -0700
Subject: <AWT Dev> [9] Review request for 8159904: [TEST_BUG] Failure on
 solaris of java/awt/Window/MultiWindowApp/MultiWindowAppTest.java
Message-ID: <57579599-3d1b-290e-7ab0-7db44b74250d@oracle.com>

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8159904

webrev: http://cr.openjdk.java.net/~ssadetsky/8159904/webrev.00/

Solaris platform was added to the test exclusions because Solaris WM do 
not permit to bring a window on top programmatically.

--Semyon


From sergey.bylokhov at oracle.com  Thu Apr 27 20:25:56 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 27 Apr 2017 13:25:56 -0700 (PDT)
Subject: <AWT Dev> [9] Review request for 8159904: [TEST_BUG] Failure on
 solaris of java/awt/Window/MultiWindowApp/MultiWindowAppTest.java
Message-ID: <6fcf73a2-fc38-4ed8-8018-30b35858a5be@default>

Hi, Semyon
As far as I remember Solaris uses gnome2(metacity/compiz). Does it mean it do not work on Gnome2?

----- semyon.sadetsky at oracle.com wrote:

> Hello,
> 
> Please review fix for JDK9:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8159904
> 
> webrev: http://cr.openjdk.java.net/~ssadetsky/8159904/webrev.00/
> 
> Solaris platform was added to the test exclusions because Solaris WM
> do 
> not permit to bring a window on top programmatically.
> 
> --Semyon

From sergey.bylokhov at oracle.com  Thu Apr 27 20:27:52 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 27 Apr 2017 13:27:52 -0700 (PDT)
Subject: <AWT Dev> [9] Review request for 8160530: [TEST-BUG] Consistent
 failure of
 java/awt/dnd/MissingEventsOnModalDialog/MissingEventsOnModalDialogTest.java
Message-ID: <28a463d4-ea50-4411-bba7-02fb9b8d69d1@default>

Looks fine.

----- semyon.sadetsky at oracle.com wrote:

> Hello,
> 
> Please review fix for JDK9:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8160530
> 
> webrev: http://cr.openjdk.java.net/~ssadetsky/8160530/webrev.00/
> 
> To issues are being fixed. The first, Delay was increased for the test
> 
> stability on various platforms. The second, getting true from 
> Dialog::isVisible() doesn't mean that dialog is shown on the screen
> and 
> clickable.
> 
> Tested on Ubuntu 16.04, OEL 7.3 and Solaris 11.3 with single and dual
> 
> screen.
> 
> --Semyon

From sergey.bylokhov at oracle.com  Thu Apr 27 20:36:19 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 27 Apr 2017 13:36:19 -0700 (PDT)
Subject: <AWT Dev> RFR: 8179365 : JAWT (AWT Native Interface)
 specification needs to be updated for JDK 9
Message-ID: <c4e14395-8836-4fcd-b0e5-5cce5ae9ac2f@default>

Looks fine.

----- philip.race at oracle.com wrote:

> Bug: https://bugs.openjdk.java.net/browse/JDK-8179365
> webrev: http://cr.openjdk.java.net/~prr/8179365/
> 
> the JAWT spec as currently published has not been maintained
> http://docs.oracle.com/javase/8/docs/technotes/guides/awt/AWT_Native_Interface.html
> 
> and worse that location will not be published for 9.
> Also the spec needs to be updated for 9 to document the EmbeddedFrame
> 
> support.
> 
> This moves the JAWT spec into the new "spec" area specified by JEP 299
> (see
> the bug report for links on that) and will ensure that JAWT will be 
> documented in 9.
> 
> As well as documenting the missing APIs (including some from earlier 
> releases)
> it "freshens" the textual parts of the document.
> 
> Since the "spec" part is essentially a regurgitation of the header
> files 
> those
> had a few updates too. And the Mac one was not previously listed.
> 
> -phil.

From semyon.sadetsky at oracle.com  Thu Apr 27 20:51:32 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 27 Apr 2017 13:51:32 -0700
Subject: <AWT Dev> RFR: 8179365 : JAWT (AWT Native Interface)
 specification needs to be updated for JDK 9
In-Reply-To: <d2fcd503-aa7f-32b2-fee4-89f0abb58f81@oracle.com>
References: <d2fcd503-aa7f-32b2-fee4-89f0abb58f81@oracle.com>
Message-ID: <5e9612dd-9a92-065d-0f65-679e001875c9@oracle.com>

+1

--Semyon


On 04/26/2017 11:43 AM, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179365
> webrev: http://cr.openjdk.java.net/~prr/8179365/
>
> the JAWT spec as currently published has not been maintained
> http://docs.oracle.com/javase/8/docs/technotes/guides/awt/AWT_Native_Interface.html 
>
>
> and worse that location will not be published for 9.
> Also the spec needs to be updated for 9 to document the EmbeddedFrame 
> support.
>
> This moves the JAWT spec into the new "spec" area specified by JEP 299 
> (see
> the bug report for links on that) and will ensure that JAWT will be 
> documented in 9.
>
> As well as documenting the missing APIs (including some from earlier 
> releases)
> it "freshens" the textual parts of the document.
>
> Since the "spec" part is essentially a regurgitation of the header 
> files those
> had a few updates too. And the Mac one was not previously listed.
>
> -phil.
>
>


From yuri.nesterenko at oracle.com  Fri Apr 28 09:27:02 2017
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Fri, 28 Apr 2017 12:27:02 +0300
Subject: <AWT Dev> [9] Review request for 8160530: [TEST-BUG] Consistent
 failure of
 java/awt/dnd/MissingEventsOnModalDialog/MissingEventsOnModalDialogTest.java
In-Reply-To: <bc78f61d-f859-220d-122f-026f52541e5f@oracle.com>
References: <bc78f61d-f859-220d-122f-026f52541e5f@oracle.com>
Message-ID: <606ca20a-580f-d785-3d95-c95374ecbb32@oracle.com>

Fine with me!

-yan

On 04/27/2017 10:09 PM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8160530
>
> webrev: http://cr.openjdk.java.net/~ssadetsky/8160530/webrev.00/
>
> To issues are being fixed. The first, Delay was increased for the test
> stability on various platforms. The second, getting true from
> Dialog::isVisible() doesn't mean that dialog is shown on the screen and
> clickable.
>
> Tested on Ubuntu 16.04, OEL 7.3 and Solaris 11.3 with single and dual
> screen.
>
> --Semyon
>


From philip.race at oracle.com  Fri Apr 28 22:27:42 2017
From: philip.race at oracle.com (Philip Race)
Date: Fri, 28 Apr 2017 15:27:42 -0700
Subject: <AWT Dev> [9] Review request for 8160530: [TEST-BUG] Consistent
 failure of
 java/awt/dnd/MissingEventsOnModalDialog/MissingEventsOnModalDialogTest.java
In-Reply-To: <606ca20a-580f-d785-3d95-c95374ecbb32@oracle.com>
References: <bc78f61d-f859-220d-122f-026f52541e5f@oracle.com>
 <606ca20a-580f-d785-3d95-c95374ecbb32@oracle.com>
Message-ID: <5903C1DE.1000808@oracle.com>

+1

-phil.

On 4/28/17, 2:27 AM, Yuri Nesterenko wrote:
> Fine with me!
>
> -yan
>
> On 04/27/2017 10:09 PM, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8160530
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160530/webrev.00/
>>
>> To issues are being fixed. The first, Delay was increased for the test
>> stability on various platforms. The second, getting true from
>> Dialog::isVisible() doesn't mean that dialog is shown on the screen and
>> clickable.
>>
>> Tested on Ubuntu 16.04, OEL 7.3 and Solaris 11.3 with single and dual
>> screen.
>>
>> --Semyon
>>
>

From philip.race at oracle.com  Fri Apr 28 22:32:07 2017
From: philip.race at oracle.com (Philip Race)
Date: Fri, 28 Apr 2017 15:32:07 -0700
Subject: <AWT Dev> [9] Review request for 8159904: [TEST_BUG] Failure on
 solaris of java/awt/Window/MultiWindowApp/MultiWindowAppTest.java
In-Reply-To: <6fcf73a2-fc38-4ed8-8018-30b35858a5be@default>
References: <6fcf73a2-fc38-4ed8-8018-30b35858a5be@default>
Message-ID: <5903C2E7.50603@oracle.com>

I believe yes gnome 2 and that gnome 3 is coming
I was also bit surprised by this.

toFront() has been around forever and I've no recollections with
issues on Solaris.

  As a datapoint I can test this with a real desktop
(not xVNC) using Solaris 10 + JDK 8 next week ..

-phil.

On 4/27/17, 1:25 PM, Sergey Bylokhov wrote:
> Hi, Semyon
> As far as I remember Solaris uses gnome2(metacity/compiz). Does it mean it do not work on Gnome2?
>
> ----- semyon.sadetsky at oracle.com wrote:
>
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8159904
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8159904/webrev.00/
>>
>> Solaris platform was added to the test exclusions because Solaris WM
>> do
>> not permit to bring a window on top programmatically.
>>
>> --Semyon

From semyon.sadetsky at oracle.com  Fri Apr 28 22:50:30 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 28 Apr 2017 15:50:30 -0700
Subject: <AWT Dev> [9] Review request for 8159904: [TEST_BUG] Failure on
 solaris of java/awt/Window/MultiWindowApp/MultiWindowAppTest.java
In-Reply-To: <5903C2E7.50603@oracle.com>
References: <6fcf73a2-fc38-4ed8-8018-30b35858a5be@default>
 <5903C2E7.50603@oracle.com>
Message-ID: <aaac48f6-58ad-ea09-809f-f221644c7880@oracle.com>

Phil,

this is a jdk9 issue found on Solaris 11.3. But jdk8 should not be very 
different.

Much appreciate it if you will be able to run 
java/awt/Window/MultiWindowApp/MultiWindowAppTest.java on Solaris 10.

But I'm not sure about Solaris 10 WM Gnome version. Its behavior can be 
different.

--Semyon

On 04/28/2017 03:32 PM, Philip Race wrote:
> I believe yes gnome 2 and that gnome 3 is coming
> I was also bit surprised by this.
>
> toFront() has been around forever and I've no recollections with
> issues on Solaris.
>
>  As a datapoint I can test this with a real desktop
> (not xVNC) using Solaris 10 + JDK 8 next week ..
>
> -phil.
>
> On 4/27/17, 1:25 PM, Sergey Bylokhov wrote:
>> Hi, Semyon
>> As far as I remember Solaris uses gnome2(metacity/compiz). Does it 
>> mean it do not work on Gnome2?
>>
>> ----- semyon.sadetsky at oracle.com wrote:
>>
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8159904
>>>
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8159904/webrev.00/
>>>
>>> Solaris platform was added to the test exclusions because Solaris WM
>>> do
>>> not permit to bring a window on top programmatically.
>>>
>>> --Semyon


From philip.race at oracle.com  Fri Apr 28 23:03:09 2017
From: philip.race at oracle.com (Philip Race)
Date: Fri, 28 Apr 2017 16:03:09 -0700
Subject: <AWT Dev> [9] Review request for 8159904: [TEST_BUG] Failure on
 solaris of java/awt/Window/MultiWindowApp/MultiWindowAppTest.java
In-Reply-To: <aaac48f6-58ad-ea09-809f-f221644c7880@oracle.com>
References: <6fcf73a2-fc38-4ed8-8018-30b35858a5be@default>
 <5903C2E7.50603@oracle.com> <aaac48f6-58ad-ea09-809f-f221644c7880@oracle.com>
Message-ID: <5903CA2D.10707@oracle.com>

Yes .. it is however "a datapoint". Also there are people in the Solaris 
org.
we can ask ..

-phil.

On 4/28/17, 3:50 PM, Semyon Sadetsky wrote:
> Phil,
>
> this is a jdk9 issue found on Solaris 11.3. But jdk8 should not be 
> very different.
>
> Much appreciate it if you will be able to run 
> java/awt/Window/MultiWindowApp/MultiWindowAppTest.java on Solaris 10.
>
> But I'm not sure about Solaris 10 WM Gnome version. Its behavior can 
> be different.
>
> --Semyon
>
> On 04/28/2017 03:32 PM, Philip Race wrote:
>> I believe yes gnome 2 and that gnome 3 is coming
>> I was also bit surprised by this.
>>
>> toFront() has been around forever and I've no recollections with
>> issues on Solaris.
>>
>>  As a datapoint I can test this with a real desktop
>> (not xVNC) using Solaris 10 + JDK 8 next week ..
>>
>> -phil.
>>
>> On 4/27/17, 1:25 PM, Sergey Bylokhov wrote:
>>> Hi, Semyon
>>> As far as I remember Solaris uses gnome2(metacity/compiz). Does it 
>>> mean it do not work on Gnome2?
>>>
>>> ----- semyon.sadetsky at oracle.com wrote:
>>>
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8159904
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8159904/webrev.00/
>>>>
>>>> Solaris platform was added to the test exclusions because Solaris WM
>>>> do
>>>> not permit to bring a window on top programmatically.
>>>>
>>>> --Semyon
>

From prem.balakrishnan at oracle.com  Sat Apr 29 11:05:13 2017
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Sat, 29 Apr 2017 04:05:13 -0700 (PDT)
Subject: <AWT Dev> Review Request: JDK-8179014 JFileChooser with Windows
 look and feel crashes on win 10 + jre-8 131
Message-ID: <010ae274-791a-45e0-ad35-0bd754b20676@default>

Hi,

Please review fix for JDK 9,

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8179014 

Webrev: http://cr.openjdk.java.net/~pkbalakr/8179014/webrev.00/ 

 

Issue:

JFileChooser with Windows LAF crashes on Windows 10.

This issue is reproducible only on Windows 10 (v1703).

Creating GodMode directory is the only way we are able to reproduce this issue.

 

Cause:

IShellFolder::GetDisplayNameOf() method is used to retrieve the display name of folder/subfolder using the GUID.

This method  returns NULL for GodMode directory [i.e., folder created with name: GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}].

In previous version of windows (tested on v1511) this call returns name "GodMode".

Hence we get crash when processing the return data from the this method.

 

Why only on Windows LAF?

Unlike other LAFs in Windows LAF "useSystemExtensionHiding" is set to true.

This check avoids the call to IShellFolder::GetDisplayNameOf() method in all other LAF's.

Hence crash is not reported on other LAFs.

 

Fix:

Added missing NULL checks in native method.

This results in native method returning NULL in this case, which has already been handled on java side, hence no additional change is needed.

 

Regards,

Prem

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170429/630d2ceb/attachment-0001.html>

From kevin.rushforth at oracle.com  Sat Apr 29 12:33:29 2017
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 29 Apr 2017 05:33:29 -0700
Subject: <AWT Dev> Review Request: JDK-8179014 JFileChooser with Windows
 look and feel crashes on win 10 + jre-8 131
In-Reply-To: <010ae274-791a-45e0-ad35-0bd754b20676@default>
References: <010ae274-791a-45e0-ad35-0bd754b20676@default>
Message-ID: <59048819.4070705@oracle.com>

I'm not a "R"eviewer for AWT, but this part of the change looks wrong to me:

         case STRRET_CSTR :
+            if (pStrret->cStr != NULL) {
             return JNU_NewStringPlatform(env, reinterpret_cast<const char*>(pStrret->cStr));
+            }
         case STRRET_OFFSET :



Did you really intended that a NULL pStrret->cStr pointer should fall 
through to the next case (STRRET_OFFSET)? If so, then a comment is in 
order because this seems odd.

-- Kevin


Prem Balakrishnan wrote:
>
> Hi*,*
>
> Please review fix for JDK 9,
>
>  
>
> *Bug:* https://bugs.openjdk.java.net/browse/JDK-8179014
>
> *Webrev:* http://cr.openjdk.java.net/~pkbalakr/8179014/webrev.00/ 
> <http://cr.openjdk.java.net/%7Epkbalakr/8179014/webrev.00/>
>
>  
>
> *Issue:*
>
> JFileChooser with Windows LAF crashes on Windows 10.**
>
> This issue is reproducible only on Windows 10 (v1703).
>
> Creating GodMode directory is the only way we are able to reproduce 
> this issue.
>
>  
>
> *Cause:*
>
> IShellFolder::GetDisplayNameOf() method is used to retrieve the 
> display name of folder/subfolder using the GUID.
>
> This method  returns NULL for GodMode directory [i.e., folder created 
> with name: GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}].
>
> In previous version of windows (tested on v1511) this call returns 
> name "GodMode".
>
> Hence we get crash when processing the return data from the this method.
>
>  
>
> Why only on Windows LAF?
>
> Unlike other LAFs in Windows LAF "useSystemExtensionHiding" is set to 
> true.
>
> This check avoids the call to IShellFolder::GetDisplayNameOf() method 
> in all other LAF's.
>
> Hence crash is not reported on other LAFs.
>
>  
>
> *Fix:*
>
> Added missing NULL checks in native method.
>
> This results in native method returning NULL in this case, which has 
> already been handled on java side, hence no additional change is needed.
>
>  
>
> Regards,
>
> Prem
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170429/f2b87139/attachment.html>

From philip.race at oracle.com  Sat Apr 29 17:30:15 2017
From: philip.race at oracle.com (Phil Race)
Date: Sat, 29 Apr 2017 10:30:15 -0700
Subject: <AWT Dev> Review Request: JDK-8179014 JFileChooser with Windows
	look and feel crashes on win 10 + jre-8 131
In-Reply-To: <59048819.4070705@oracle.com>
References: <010ae274-791a-45e0-ad35-0bd754b20676@default>
 <59048819.4070705@oracle.com>
Message-ID: <75639215-30F0-4A45-B71B-7816297C419A@oracle.com>

I agree. This switch statement clearly was written in the expectation that each case executed return.

And as I said offline pls confirm that you are confident that all return paths actually handle that null which may not have been tested in practice before now. There seemed to be several code paths.

-Phil.

> On Apr 29, 2017, at 5:33 AM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> I'm not a "R"eviewer for AWT, but this part of the change looks wrong to me:
> 
>          case STRRET_CSTR :
> +            if (pStrret->cStr != NULL) {
>              return JNU_NewStringPlatform(env, reinterpret_cast<const char*>(pStrret->cStr));
> +            }
>          case STRRET_OFFSET :
> 
> 
> Did you really intended that a NULL pStrret->cStr pointer should fall through to the next case (STRRET_OFFSET)? If so, then a comment is in order because this seems odd.
> 
> -- Kevin
> 
> 
> Prem Balakrishnan wrote:
>> 
>> Hi,
>> Please review fix for JDK 9,
>>  
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179014
>> Webrev: http://cr.openjdk.java.net/~pkbalakr/8179014/webrev.00/
>>  
>> Issue:
>> JFileChooser with Windows LAF crashes on Windows 10.
>> This issue is reproducible only on Windows 10 (v1703).
>> Creating GodMode directory is the only way we are able to reproduce this issue.
>>  
>> Cause:
>> IShellFolder::GetDisplayNameOf() method is used to retrieve the display name of folder/subfolder using the GUID.
>> This method  returns NULL for GodMode directory [i.e., folder created with name: GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}].
>> In previous version of windows (tested on v1511) this call returns name ?GodMode?.
>> Hence we get crash when processing the return data from the this method.
>>  
>> Why only on Windows LAF?
>> Unlike other LAFs in Windows LAF ?useSystemExtensionHiding? is set to true.
>> This check avoids the call to IShellFolder::GetDisplayNameOf() method in all other LAF?s.
>> Hence crash is not reported on other LAFs.
>>  
>> Fix:
>> Added missing NULL checks in native method.
>> This results in native method returning NULL in this case, which has already been handled on java side, hence no additional change is needed.
>>  
>> Regards,
>> Prem
>>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170429/b054c882/attachment.html>