From Sergey.Bylokhov at oracle.com  Sun Oct  2 13:53:59 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 2 Oct 2016 16:53:59 +0300
Subject: <AWT Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
Message-ID: <350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>

Thanks for the comments.
The new version:
http://cr.openjdk.java.net/~serb/8143077/webrev.01
The specification of Event class and InputEvent.getModifiers() are updated.

On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
> Hi Sergey,
>
> I'm not a reviewer, but after reading the deprecation messages in Event.java
>
>     * @deprecated It is recommended that {@code AWTEvent} class and its
>     subclasses
>     *             be used instead.
>
>
> I get the impression they would read better without the redundant
> "class" in the middle, like so.
>
>     * @deprecated It is recommended that {@code AWTEvent} and its subclasses
>     *             be used instead.
>
>
> Kind regards,
> Jonathan
>
>
> On 30 September 2016 at 16:45, Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>
>     Hello.
>
>     Please review the fix for jdk9.
>
>     This is request to deprecate the obsolete flags inside InputEvent.
>     This constants were marked as obsolete in jdk1.4 and were replaced
>     by the new one. In jdk1.4 the documentation were update with notion
>     that the new constants should be used. And this bug is about
>     official deprecation of them.
>
>     We can replace old constants by the new one in the whole jdk, but I
>     updated only the code in InputEvent to make change smaller and
>     safer. So at least the new code in jdk and the code in applications
>     will start to use the new constants.
>
>     The changes in jconsole are necessary to fix deprecation warning.
>
>     jprt build passed, no new issues were found by jck/jtreg tests.
>
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>     <https://bugs.openjdk.java.net/browse/JDK-8143077>
>     Webrev can be found at:
>     http://cr.openjdk.java.net/~serb/8143077/webrev.00
>     <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>
>     --
>     Best regards, Sergey.
>
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Sun Oct  2 14:52:38 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 2 Oct 2016 17:52:38 +0300
Subject: <AWT Dev> [9] Review request for 8143914: Provide Mac-specific
 fullscreen support
In-Reply-To: <70a8e894-93be-23d5-a296-2f674053ee1a@oracle.com>
References: <70a8e894-93be-23d5-a296-2f674053ee1a@oracle.com>
Message-ID: <106cd9a6-8946-f34c-4647-17a7ab053b65@oracle.com>

Hi, Alexander.
In the fix you use eawt events which are generated by the same peer. Why 
not use windowWill/DidEnterFullScreen + windowWill/DidExitFullScreen?
Why the fix is for the Frames only, there are some limitations for other 
windows, dialogs etc?

On 06.09.16 17:32, Alexander Zvegintsev wrote:
> Hello,
>
> please review the fix
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8143914/00/
>
> for the issue
>
> https://bugs.openjdk.java.net/browse/JDK-8143914
>
>
> This fix adds the green FullScreen button to a resizable frames by default.
>
> Previous maximize behavior is still accessible by holding Alt while
> clicking on the green button.
>
> setResizable is fixed because of two reasons:
>
> Window will not be able to leave fullscreen if we remove resizable from
> style bits(and even if we set it again)
>
> Window will not have the green button(maximize/zoom or fullscreen) if
> the window was initially not resizable.
>
>


-- 
Best regards, Sergey.

From alexander.zvegintsev at oracle.com  Mon Oct  3 15:05:42 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 3 Oct 2016 18:05:42 +0300
Subject: <AWT Dev> [9] Review request for 8159432: [PIT][macosx]
 StackOverflow in closed/java/awt/Dialog/DialogDeadlock/DialogDeadlockTest
In-Reply-To: <b455f732-8465-95e4-be0e-ec1221e82e97@oracle.com>
References: <b455f732-8465-95e4-be0e-ec1221e82e97@oracle.com>
Message-ID: <78721ee4-f48e-1aab-7396-092ec8588dbb@oracle.com>

looks good to me.

--
Thanks,
Alexander.

On 24.08.2016 22:18, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8159432
>
> webrev: http://cr.openjdk.java.net/~ssadetsky/8159432/webrev.00/
>
> The issue is connected to the restoring focus to the previously 
> focused window when there are a lot of focus restore requests are 
> coming very often (for example series of windows showing and hiding 
> quickly). In this case waiting for asynchronous focus causes nested 
> waiting loop, and if number of such requests is big enough the 
> StackOverflowError is thrown.
>
> To avoid this the 8139218 solution is revisited to manage the focus 
> restore synchronously only if it is possible and send a single 
> asynchronous focus request otherwise.
>
> --Semyon
>


From Alan.Burlison at oracle.com  Mon Oct  3 15:21:11 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Mon, 3 Oct 2016 16:21:11 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <936802ec-49cb-8703-0c4c-c53ba4816357@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
	<0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
	<936802ec-49cb-8703-0c4c-c53ba4816357@oracle.com>
Message-ID: <fe5e432c-7ac2-8b54-6459-fdfa4ec70f64@oracle.com>

On 30/09/2016 20:01, Phil Race wrote:

> Our helpful SQE engineer has verified that this works as well as
> previously.
> And I've done some basic testing myself on Ubuntu 16.04, so "+1"
> (meaning approved).

Thanks. Could someone sponsor this for me?

-- 
Alan Burlison
--

From semyon.sadetsky at oracle.com  Mon Oct  3 16:38:35 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 3 Oct 2016 19:38:35 +0300
Subject: <AWT Dev> <Awt Dev> [9] Review Request for 8141528: Test
 closed/java/awt/FullScreen/DisplayMode/CycleDMImage.java fails for Ubuntu
 15.10
In-Reply-To: <56656973.2030608@oracle.com>
References: <56656973.2030608@oracle.com>
Message-ID: <0d21c884-0cea-11bc-f5ef-dff9382e7bda@oracle.com>

The fix is updated http://cr.openjdk.java.net/~ssadetsky/8141528/webrev.01/

The root case of the issue is that in Unity the screen window size and 
location are get updated several times after display mode is changed, 
and bounds which are set in line 459 of X11GraphicsDevice class are 
overwritten. Since those window updates caused by display mode change 
are not predictable the solution is changed to set the correct 
full-screen size in the ConfigureNotify handler.

--Semyon


On 12/7/2015 2:11 PM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8141528
> webrev: http://cr.openjdk.java.net/~ssadetsky/8141528/webrev.00/
>
> Compiz WM requires override redirect for full-screen window to 
> preserve the full size upon display mode switching.
>
> --Semyon
>


From philip.race at oracle.com  Mon Oct  3 21:08:13 2016
From: philip.race at oracle.com (Phil Race)
Date: Mon, 3 Oct 2016 14:08:13 -0700
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <fe5e432c-7ac2-8b54-6459-fdfa4ec70f64@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
	<0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
	<936802ec-49cb-8703-0c4c-c53ba4816357@oracle.com>
	<fe5e432c-7ac2-8b54-6459-fdfa4ec70f64@oracle.com>
Message-ID: <e7afeb48-a914-43a7-9830-bd7e6f744015@oracle.com>

Do we have a 2nd reviewer yet ? I have not seen it.

-phil.

On 10/03/2016 08:21 AM, Alan Burlison wrote:
> On 30/09/2016 20:01, Phil Race wrote:
>
>> Our helpful SQE engineer has verified that this works as well as
>> previously.
>> And I've done some basic testing myself on Ubuntu 16.04, so "+1"
>> (meaning approved).
>
> Thanks. Could someone sponsor this for me?
>


From alexander.zvegintsev at oracle.com  Mon Oct  3 22:08:54 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 4 Oct 2016 01:08:54 +0300
Subject: <AWT Dev> <Awt Dev> [9] Review Request for 8141528: Test
 closed/java/awt/FullScreen/DisplayMode/CycleDMImage.java fails for Ubuntu
 15.10
In-Reply-To: <0d21c884-0cea-11bc-f5ef-dff9382e7bda@oracle.com>
References: <56656973.2030608@oracle.com>
	<0d21c884-0cea-11bc-f5ef-dff9382e7bda@oracle.com>
Message-ID: <4aad9b75-7f4e-166c-6e5c-f037fb30674e@oracle.com>

Looks fine.

--
Thanks,
Alexander.

On 10/03/2016 07:38 PM, Semyon Sadetsky wrote:
> The fix is updated 
> http://cr.openjdk.java.net/~ssadetsky/8141528/webrev.01/
>
> The root case of the issue is that in Unity the screen window size and 
> location are get updated several times after display mode is changed, 
> and bounds which are set in line 459 of X11GraphicsDevice class are 
> overwritten. Since those window updates caused by display mode change 
> are not predictable the solution is changed to set the correct 
> full-screen size in the ConfigureNotify handler.
>
> --Semyon
>
>
> On 12/7/2015 2:11 PM, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8141528
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8141528/webrev.00/
>>
>> Compiz WM requires override redirect for full-screen window to 
>> preserve the full size upon display mode switching.
>>
>> --Semyon
>>
>


From philip.race at oracle.com  Mon Oct  3 22:30:26 2016
From: philip.race at oracle.com (Phil Race)
Date: Mon, 3 Oct 2016 15:30:26 -0700
Subject: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the
 HiDPI splash screen image naming convention
In-Reply-To: <3dcccb28-fedd-4e24-8f4d-4f66d4c15f80@default>
References: <fd604cb2-cd2a-4227-91db-87e7c0184d16@default>
	<020c37cc-c9af-4790-a591-29b71b410533@default>
	<6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com>
	<57B34616.5030203@oracle.com>
	<434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default>
	<57B64223.8090304@oracle.com>
	<420cab11-7fec-4e12-a053-79ff9a1e1cd8@default>
	<16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com>
	<e89f924d-b823-413d-91eb-1983849cfd55@default>
	<9fd32539-c22b-5c81-4032-92d9263857e5@oracle.com>
	<a9f03f07-c15d-4a61-9d23-1ce363735d74@default>
	<57C0B745.3040601@oracle.com>
	<464e5282-0317-49eb-b03f-d937dc97af58@default>
	<57C83167.6080108@oracle.com>
	<f8b2254e-8ca3-4f1a-8088-6a847bec2c44@default>
	<57C9812C.1080104@oracle.com>
	<a46028af-92fc-4032-8c74-70a951be2839@default>
	<57D2DCF3.8000107@oracle.com>
	<01b1408e-76a8-4236-8286-45dd8e603b77@default>
	<57D6C6B7.6000104@oracle.com>
	<bbfcbe03-a710-488f-a691-23c2c7ba4738@default>
	<57E1A5EA.4000905@oracle.com>
	<3dcccb28-fedd-4e24-8f4d-4f66d4c15f80@default>
Message-ID: <5fddfd93-8bed-7481-21e6-cb7fc7f107c2@oracle.com>

+1

-phil.

On 09/21/2016 02:29 AM, Rajeev Chamyal wrote:
>
> Hello Phil,
>
> Please review the updated webrev.
>
> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.10/ 
> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.10/>
>
> Updates: Updated launcher.properties as suggested.
>
> Regards,
>
> Rajeev Chamyal
>
> *From:*Philip Race
> *Sent:* 21 September 2016 02:41
> *To:* Rajeev Chamyal
> *Cc:* Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov; 
> Kumar Srinivasan
> *Subject:* Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 
> Unify the HiDPI splash screen image naming convention
>
> \                  HiDPI scaled image is also supported\n\
>   94 \                  Unscaled image name i.e. image.ext should be 
> passed\n\
>   95 \                  to -splash option for all image types 
> irrespective of\n\
>  96 \                  HiDPI and Non-HiDPI. Scaled filename convention 
> should be\n\
>   97 \                  used for HiDPI images\n\
> try this :-
> HiDPI scaled images are automatically supported and used if available.
> The unscaled image filename, e.g. image.ext, should always be passed as
> the argument to the -splash option. The most appropriate scaled image
> provided will be picked up automatically.
> See the SplashScreen API documentation for more information.
>
> -phil.
>
> On 9/13/16, 12:03 AM, Rajeev Chamyal wrote:
>
>     Hello Phil,
>
>     Please review the updated webrev.
>
>     http://cr.openjdk.java.net/~rchamyal/8151787/webrev.09/
>     <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.09/>
>
>     Updates:
>
>     Updated documentation in src/java.desktop/share/classes/java/awt/SplashScreen.java
>
>     Review comments from Kumar are also updated in launcher.properties.
>
>     Regards,
>
>     Rajeev Chamyal
>
>     -----Original Message-----
>
>     From: Kumar Srinivasan
>
>     Sent: 12 September 2016 20:46
>
>     To: Rajeev Chamyal
>
>     Cc: Philip Race; Alexander Scherbatiy;awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
>
>     Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention
>
>     -\                  HiDPI and Non-HiDPI.Scaled filename convention should be\n\
>
>     +\                  HiDPI and Non-HiDPI. Scaled filename convention should be\n\
>
>     +\                  used for HiDPI images\n\
>
>     Space after .
>
>     Approved, contingent on the above fix, I don't need to see another iteration.
>
>     Thanks
>
>     Kumar
>
>     On 9/12/2016 5:25 AM, Rajeev Chamyal wrote:
>
>         Hello Kumar,
>
>         Thanks for the review.
>
>         Please review the updated webrev.
>
>         http://cr.openjdk.java.net/~rchamyal/8151787/webrev.09/
>         <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.09/>
>
>         Updates:
>
>         1) Updated launcher properties.
>
>         2) Corrected indentation in splashscreen_impl.c
>
>         Regards,
>
>         Rajeev Chamyal
>
>         -----Original Message-----
>
>         From: Kumar Srinivasan
>
>         Sent: 09 September 2016 21:32
>
>         To: Rajeev Chamyal
>
>         Cc: Philip Race; Alexander Scherbatiy;awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>;
>
>         Sergey Bylokhov
>
>         Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify
>
>         the HiDPI splash screen image naming convention
>
>         Hi Rajeev,
>
>         In launcher.properties do you need an additional line to say, one must use the filename conventions to specify resolution ?
>
>         btw: I think you have formatting/indent issues in this file:
>
>         libsplashscreen/splashscreen_impl.c
>
>         Thanks
>
>         Kumar
>
>             Hello Kumar,Phil,
>
>             Please review the update updated webrev.
>
>             http://cr.openjdk.java.net/~rchamyal/8151787/webrev.08/
>             <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.08/>
>
>             Updates in files :
>
>             src/java.base/share/classes/sun/launcher/resources/launcher.propertie
>
>             s src/java.desktop/share/classes/java/awt/SplashScreen.java
>
>             Regards,
>
>             Rajeev Chamyal
>
>             -----Original Message-----
>
>             From: Kumar Srinivasan
>
>             Sent: 02 September 2016 19:10
>
>             To: Rajeev Chamyal
>
>             Cc: Alexander Scherbatiy;awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov;
>
>             Philip Race
>
>             Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787
>
>             Unify the HiDPI splash screen image naming convention
>
>             Hi,
>
>                 Hello Kumar,
>
>                 I have further updated launcher.properties.
>
>                 http://cr.openjdk.java.net/~rchamyal/8151787/webrev.07/
>                 <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.07/>
>
>                 For documentation update I have already raise a bug.
>
>                 https://bugs.openjdk.java.net/browse/JDK-8165009
>
>             Ok.
>
>             so what about ?
>
>             http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.de
>
>             s ktop/share/classes/java/awt/SplashScreen.java
>
>             This is the SplashScreen specification, is it not ? But there seems to be no effort to clarify this specification ?
>
>             Kumar
>
>                 Regards,
>
>                 Rajeev Chamyal
>
>                 -----Original Message-----
>
>                 From: Kumar Srinivasan
>
>                 Sent: 01 September 2016 19:17
>
>                 To: Rajeev Chamyal
>
>                 Cc: Alexander Scherbatiy;awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov;
>
>                 Philip Race
>
>                 Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787
>
>                 Unify the HiDPI splash screen image naming convention
>
>                 Hello Rajeev,
>
>                 IMHO, this really belongs here:
>
>                 http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.d
>
>                 e s ktop/share/classes/java/awt/SplashScreen.java
>
>                 and here:
>
>                 https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
>
>                 If you can reduce the words in the launcher, it would be good, also please make sure the lines do not exceed 80 chars ie. the output of java -help.
>
>                 Kumar
>
>                     Hello Kumar,
>
>                     Can you please review the updated
>
>                     src/java.base/share/classes/sun/launcher/resources/launcher.propert
>
>                     i e shttp://cr.openjdk.java.net/~rchamyal/8151787/webrev.06/
>                     <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.06/>
>
>                     Regards,
>
>                     Rajeev Chamyal
>
>                     -----Original Message-----
>
>                     From: Philip Race
>
>                     Sent: 27 August 2016 03:10
>
>                     To: Rajeev Chamyal
>
>                     Cc: Alexander Scherbatiy;awt-dev at openjdk.java.net
>                     <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
>
>                     Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787
>
>                     Unify the HiDPI splash screen image naming convention
>
>                     Seems fine now.
>
>                     1) Please do a CCC for this
>
>                     2) Please file a doc. bug so docs team can update the HTML man page
>
>                     and also perhaps
>
>                     https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.h
>
>                     t
>
>                     m
>
>                     l
>
>                     -phil
>
>                     On 8/25/16, 11:49 PM, Rajeev Chamyal wrote:
>
>                         Hello Alexandr,
>
>                         Please review the updated webrev.
>
>                         http://cr.openjdk.java.net/~rchamyal/8151787/webrev.05/
>                         <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.05/>
>
>                         Regards,
>
>                         Rajeev Chamyal
>
>                         -----Original Message-----
>
>                         From: Alexandr Scherbatiy
>
>                         Sent: 25 August 2016 22:07
>
>                         To: Rajeev Chamyal; Philip Race
>
>                         Cc:awt-dev at openjdk.java.net
>                         <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
>
>                         Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>
>                         Unify the HiDPI splash screen image naming convention
>
>                         On 8/22/2016 2:13 PM, Rajeev Chamyal wrote:
>
>                             Hello Phil,
>
>                             Thanks for the review,
>
>                             Please review updated webrev.
>
>                             http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/
>                             <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.04/>
>
>                             Updated files:
>
>                             src/java.base/share/classes/sun/launcher/resources/launcher.prope
>
>                             r
>
>                             t
>
>                             i
>
>                             e s
>
>                             src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m
>
>                             src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.
>
>                             h
>
>                                   The findScaledImageName(...) method is only used in splashscreen_sys.m file. Is it possible to not declare it in splashscreen_config.h?
>
>                                  Thanks,
>
>                                  Alexandr.
>
>                             Regards,
>
>                             Rajeev Chamyal
>
>                             -----Original Message-----
>
>                             From: Phil Race
>
>                             Sent: 20 August 2016 01:47
>
>                             To: Rajeev Chamyal
>
>                             Cc:awt-dev at openjdk.java.net
>                             <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov; Alexander
>
>                             Scherbatiy
>
>                             Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>
>                             Unify the HiDPI splash screen image naming convention
>
>                             I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax.
>
>                             -phil.
>
>                             On 8/19/2016 3:41 AM, Rajeev Chamyal wrote:
>
>                                 Hello Phil,
>
>                                 Please review the updated webrev.
>
>                                 http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/
>                                 <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.03/>
>
>                                 <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.03/>
>                                 <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.03/>
>
>                                 Updated file
>
>                                 src/java.base/share/classes/sun/launcher/resources/launcher.prop
>
>                                 e
>
>                                 r
>
>                                 t
>
>                                 i
>
>                                 e
>
>                                 s
>
>                                 Added all other supported name extensions.
>
>                                 Regards,
>
>                                 Rajeev Chamyal
>
>                                 *From:*Philip Race
>
>                                 *Sent:* 19 August 2016 04:48
>
>                                 *To:* Rajeev Chamyal
>
>                                 *Cc:*awt-dev at openjdk.java.net
>                                 <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov; Alexander
>
>                                 Scherbatiy
>
>                                 *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request
>
>                                 JDK-8151787 Unify the HiDPI splash screen image naming
>
>                                 convention
>
>                                 Better, although it still does not document the supported set of
>
>                                 scale name extensions that we discussed/proposed off-line.
>
>                                 -phil.
>
>                                 On 8/18/16, 5:39 AM, Rajeev Chamyal wrote:
>
>                                            Hello Phil,
>
>                                            Thanks for the review.
>
>                                            Please review the updated webrev.
>
>                                            
>
>                                 http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/
>                                 <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.02/>
>
>                                            
>
>                                 <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.02/>
>                                 <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.02/>
>
>                                            Updated file
>
>                                 src/java.base/share/classes/sun/launcher/resources/launcher.prop
>
>                                 e
>
>                                 r
>
>                                 t
>
>                                 i
>
>                                 e
>
>                                 s
>
>                                            Regards,
>
>                                            Rajeev Chamyal
>
>                                            *From:*Phil Race
>
>                                            *Sent:* 16 August 2016 22:28
>
>                                            *To:* Alexandr Scherbatiy
>
>                                            *Cc:* Rajeev Chamyal;awt-dev at openjdk.java.net
>                                 <mailto:awt-dev at openjdk.java.net>
>
>                                            <mailto:awt-dev at openjdk.java.net>
>                                 <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
>
>                                            *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>
>                                            Unify the HiDPI splash screen image naming convention
>
>                                            On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote:
>
>                                                The fix looks good to me.
>
>                                                It would be better if a native speaker look at the
>
>                                                documentation change in the launcher.properties file.
>
>                                            That documentation seems to cover only *some* of the extensions we
>
>                                            discussed.
>
>                                            It ought to cite all of them if it does so at all. How else are
>
>                                            people supposed
>
>                                            to know what they can use ? Where else are you documenting it?
>
>                                            Perhaps the launcher "man" page should be updated too
>
>                                            find . -name java.1
>
>                                            ./src/linux/doc/man/java.1
>
>                                            ./src/linux/doc/man/ja/java.1
>
>                                            ./src/bsd/doc/man/java.1
>
>                                            ./src/bsd/doc/man/ja/java.1
>
>                                            ./src/solaris/doc/sun/man/man1/java.1
>
>                                            ./src/solaris/doc/sun/man/man1/ja/java.1
>
>                                            .. although I think there is also some HTML version maintained by
>
>                                            the pubs/docs team
>
>                                            that is not in OpenJDK - the above does not include Windows or Mac.
>
>                                            I don't know offhand what is recommended these days. We'll have to
>
>                                            find someone
>
>                                            who does more with the launcher to help point to where to do the
>
>                                            documentation.
>
>                                            And the doc does not really explain what is going on here. Reading
>
>                                            that I might
>
>                                            think I am supposed to pass -splash:image at 2x.ext if I want a
>
>                                            hi-dpi image
>
>                                            and that is not the idea at all, is it ?
>
>                                            The idea is you would still specify -splash:image.ext and the
>
>                                            *implementation*
>
>                                            will look for the most appropriate scaled image for the current
>
>                                            desktop.
>
>                                            I think we should also have a CCC cover this (somehow).
>
>                                            -phil.
>
>                                                Thanks,
>
>                                                Alexandr.
>
>                                                On 8/16/2016 8:26 AM, Rajeev Chamyal wrote:
>
>                                                    Hello Alexandr,
>
>                                                    Please review the updated webrev.
>
>                                                    
>
>                                 http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/
>                                 <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.01/>
>
>                                 <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.01/>
>                                 <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.01/>
>
>                                                    Updates :
>
>                                                    1)Updated the consition as suggested  if(*scaleFactor -
>
>                                                    (int)*scaleFactor<  0.000001)
>
>                                                    2)Includes the changes of
>
>                                 src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>
>                                                    3)+        //map the splash co-ordinates as per system scale
>
>                                                    +        splash->x /= splash->scaleFactor;
>
>                                                    +        splash->y /= splash->scaleFactor;
>
>                                                    This change is required only for windows and linux. As we
>
>                                                    use absolute system resolution for centring the splash on
>
>                                                    screen on these.
>
>                                                    i.e. if system resolution is 1920 X 1080(i.e. unscaled
>
>                                                    resolution) on windows and linux we use this for centring
>
>                                                    the splash on screen. For mac scaled resolution is used
>
>                                                    directly.
>
>                                                    Regards,
>
>                                                    Rajeev Chamyal
>
>                                                    *From:*Alexander Scherbatiy
>
>                                                    *Sent:* 11 August 2016 14:44
>
>                                                    *To:* Rajeev Chamyal;awt-dev at openjdk.java.net
>                                 <mailto:awt-dev at openjdk.java.net>
>
>                                                    <mailto:awt-dev at openjdk.java.net>
>                                 <mailto:awt-dev at openjdk.java.net>; Philip Race; Sergey
>
>                                                    Bylokhov
>
>                                                    *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request
>
>                                                    JDK-8151787 Unify the HiDPI splash screen image naming
>
>                                                    convention
>
>                                                    On 10/08/16 19:24, Alexandr Scherbatiy wrote:
>
>                                                        On 8/9/2016 11:18 AM, Rajeev Chamyal wrote:
>
>                                                            Hello All,
>
>                                                            Please review the following webrev.
>
>                                                            Bug:
>
>                                 https://bugs.openjdk.java.net/browse/JDK-8151787
>
>                                                            Webrev:
>
>                                 http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/
>                                 <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/>
>
>                                 <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/>
>                                 <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/>
>
>                                                            Issue: Currently different naming conventions are
>
>                                                            used for Hidpi image on different platforms.
>
>                                                            With this change the names will be unified across
>
>                                                            all platforms.
>
>                                                            For a unscaled image image.ext following naming
>
>                                                            convention will be followed.
>
>                                                            Unscaled name: image.ext
>
>                                                            Supported Scaled Names:
>
>                                                            If screen scale is integer number e.g. 2:
>
>                                                            image at 2x.ext
>                                 <mailto:image at 2x.ext><mailto:image at 2x.ext>
>                                 <mailto:image at 2x.ext>
>
>                                                            If screen scale is float value like 1.25:
>
>                                                            
>
>                                 image at 125pct.ext
>                                 <mailto:image at 125pct.ext><mailto:image at 125pct.ext>
>                                 <mailto:image at 125pct.ext>
>
>                                                        The fix should be reviewed on the awt-dev alias.
>
>                                                        + if(*scaleFactor - (int)*scaleFactor<
>
>                                 0.000001)
>
>                                                        Should there be so high precision there? Could only
>
>                                                        percent values be compared like
>
>                                                         if ((*scaleFactor *100) !=
>
>                                 ((int)(*scaleFactor))
>
>                                 *
>
>                                 100)
>
>                                                        +        //map the splash co-ordinates as per system scale
>
>                                                        +        splash->x /= splash->scaleFactor;
>
>                                                        +        splash->y /= splash->scaleFactor;
>
>                                                        It looks like the splash coordinates and sizes are
>
>                                                        rescaled in different places. Is it possible to do
>
>                                                        that in the same place? May be in
>
>                                                        java_awt_SplashScreen.c file getBounds() function?
>
>                                                    src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>
>                                                           *scaleFactor = getNativeScaleFactor();
>
>                                                    Could you also include the change which requires to add
>
>                                                    some default output screen name to the
>
>                                                    getNativeScaleFactor() function on Linux. There is the
>
>                                                    discussion about that:
>
>                                 http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.
>
>                                 h
>
>                                 t
>
>                                 m
>
>                                 l
>
>                                                    Thanks,
>
>                                                    Alexandr.
>
>                                                        Thanks,
>
>                                                        Alexandr.
>
>                                                            Regards,
>
>                                                            Rajeev Chamyal
>

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

From manajit.halder at oracle.com  Tue Oct  4 09:14:01 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Tue, 4 Oct 2016 14:44:01 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8165555: [macosx]
	VM crashes on second attempt to execute JCK interactive tests
	that use Robot (single JVM, agent)
In-Reply-To: <d90213a4-5713-5e2c-2a82-863445cc1780@oracle.com>
References: <73C55A8D-433F-4315-9FBF-0893E5572015@oracle.com>
	<571f1b1f-f94f-bd7c-ce55-50b2af669e4e@oracle.com>
	<E3329562-36CC-41F9-9490-8CD7B33736DD@oracle.com>
	<53d96f6e-0809-13bb-099e-396c611bdf4b@oracle.com>
	<C4D3CB16-93F1-4696-967C-EA3F439AA84D@oracle.com>
	<d90213a4-5713-5e2c-2a82-863445cc1780@oracle.com>
Message-ID: <FC6B0104-B19C-4D6C-9CF1-23F7C9887408@oracle.com>

Hi Sergey,

Thanks for the review. Changes in CRobot.m are removed and added a jtreg test case.
Please review the webrev.

http://cr.openjdk.java.net/~mhalder/8165555/webrev.03/ <http://cr.openjdk.java.net/~mhalder/8165555/webrev.03/>

Thanks,
Manajit

> On 27-Sep-2016, at 4:15 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> On 27.09.16 11:51, Manajit Halder wrote:
>> Hi Sergey,
>> 
>> Thanks for the comment. ?self.javaToMacKeyMap is retaining the reference.
>> Please review the modified code:
>> 
>> http://cr.openjdk.java.net/~mhalder/8165555/webrev.02/ <http://cr.openjdk.java.net/~mhalder/8165555/webrev.02/>
> 
> The changes in CRobot.m is unnecessary? I also suggest to write the test. Recently I have run all jck tests on my osx system and no of them were crashed, so it seems that the sequence of tests in the bug report are not stable and the new reg test will be welcome to catch such bugs always.
> 
>>> On 23-Sep-2016, at 10:24 pm, Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>> wrote:
>>> 
>>> On 21.09.16 16:01, Manajit Halder wrote:
>>>> Hi Sergey,
>>>> 
>>>> Thanks for the comment.
>>>> 
>>>> Access to "instance" is not broken. The problem is with the dictionary
>>>> variable "javaToMacKeyMap" within the "instance" reference.
>>>> The dictionary is not getting initialised for the second time when
>>>> singleton method is called for the second time. The dictionary is
>>>> getting initialised during the first time singleton method is called and
>>>> hence crash was observed. Tried adding self.javaToMacKeyMap
>>>> but doesn?t solve the problem.
>>> 
>>> I still suggest you to check "self.javaToMacKeyMap" at line 48 this
>>> should call generated setter which will retain the reference.
>>> 
>>>> 
>>>> I propose two solutions to this problem:
>>>> 
>>>> Solution 1:
>>>> Reinitialise the dictionary every-time the singleton method is called.
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mhalder/8165555/webrev.01/ <http://cr.openjdk.java.net/~mhalder/8165555/webrev.01/>
>>>> 
>>>> Drawback:
>>>> dictionary is initialised multiple times (every time singleton method is
>>>> called).
>>>> 
>>>> Solution 2:
>>>> Make the dictionary static.
>>>> Drawback:
>>>> Still dictionary need to be initialised multiple times.
>>>> No singleton method, just two static methods, one method to initialise
>>>> the dictionary and other to get the key form the dictionary.
>>>> Webrev:
>>>> Not prepared. Will be prepared if second solution accepted.
>>>> 
>>>> Test case:
>>>> There are no test cases. Problem can be reproduced by
>>>> executing following JCK test:
>>>> java -jar JCK-runtime-9/lib/jtjck.jar -mode:single -k:interactive
>>>> "api/java_awt/interactive/event/EventTests.html#EventTest0019
>>>> api/java_awt/interactive/event/EventTests.html#EventTest0013?
>>>> 
>>>> Thanks,
>>>> Manajit
>>>> 
>>>>> On 20-Sep-2016, at 4:42 am, Sergey Bylokhov
>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>>>>> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>>
>>>>> wrote:
>>>>> 
>>>>> Hi, Manajit.
>>>>> It seems that after the fix "(CRobotKeyCodeMapping *) sharedInstance"
>>>>> returns the new object per invocation, so it is not really
>>>>> sharedInstance. I am not sure I understand what is wrong in the
>>>>> current code, from the my point of view this is a correct singleton.
>>>>> It it true that the problem is in access to broken "instance" and not
>>>>> to "javaToMacKeyMap" inside the "instance"? If not then
>>>>> "javaToMacKeyMap" should be changed to "self.javaToMacKeyMap".
>>>>> Do you have a test case to reproduce the bug?
>>>>> 
>>>>> On 19.09.16 15:26, Manajit Halder wrote:
>>>>>> Hi All,
>>>>>> 
>>>>>> Kindly review the fix for JDK9.
>>>>>> 
>>>>>> Bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8165555
>>>>>> 
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~mhalder/8165555/webrev.00/
>>>>>> 
>>>>>> Issue:
>>>>>> [macosx] VM crashes on second attempt to execute JCK interactive tests
>>>>>> that use Robot (single JVM, agent)
>>>>>> 
>>>>>> Cause:
>>>>>> While executing the JCK test for the second time the robot was getting
>>>>>> initialised once again and old instance of CRobotKeyCodeMapping was not
>>>>>> available.
>>>>>> Crash was observed while trying to access invalid instance of
>>>>>> CRobotKeyCodeMapping.
>>>>>> 
>>>>>> Fix:
>>>>>> A new instance of CRobotKeyCodeMapping is created when robot is
>>>>>> initialised.
>>>>>> 
>>>>>> Regards,
>>>>>> Manajit
>>>>> 
>>>>> 
>>>>> --
>>>>> Best regards, Sergey.
>>>> 
>>> 
>>> 
>>> --
>>> Best regards, Sergey.
>> 
> 
> 
> -- 
> Best regards, Sergey.

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

From malenkov at gmail.com  Tue Oct  4 09:46:07 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Tue, 4 Oct 2016 12:46:07 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2jostnYRRT_Bj_OS=7OuL5LXQ1XaPLte7BpG3rKMt+Eag@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
	<CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>
	<413b5107-81b2-20ee-2efb-a5fa4480150f@oracle.com>
	<CANTFZ2ieCBgAVkvyXi6MY5y17-foN4tE50MOBKKV1eX9doET4g@mail.gmail.com>
	<7274b203-4648-e2b2-356c-2f70883395ea@oracle.com>
	<CANTFZ2iBRcYuwUs7dWU4ANJsu6oCDVNyVPGnqHK+_pTN-W45dA@mail.gmail.com>
	<db198cb7-bef9-8aef-deab-e56488c68c7c@oracle.com>
	<CANTFZ2gn1bzQv94EniHyjpBDDXtDEAx6WQgMmTo-zEtGcS9nLw@mail.gmail.com>
	<daa84af4-6fe3-521a-d4f8-1938e3284850@oracle.com>
	<CANTFZ2gjd4Ak5BHFk2CxOuNpoma=AbxdwrRSvnQgwYJMDJ0=Pg@mail.gmail.com>
	<cfefbc8a-b088-107d-4330-aecbb3f53120@oracle.com>
	<CANTFZ2jostnYRRT_Bj_OS=7OuL5LXQ1XaPLte7BpG3rKMt+Eag@mail.gmail.com>
Message-ID: <CANTFZ2jNT7HUZBDu7OJchY6PCUDg-dxQY3xRUuo8tc3=Sdy_Mg@mail.gmail.com>

Hi all,

Message from Mike Swingler about sensitive scrolling:
>The original issue your bug was duplicated against
> has been resolved by the HID engineering team,
> and should be available in a forthcoming beta of
> macOS 10.12.1. To get it via Software Update,
> sign up at <https://beta.apple.com>

We need to test our changes against ASAP.


-- 
Best regards,
Sergey A. Malenkov

From Alan.Burlison at oracle.com  Tue Oct  4 10:06:17 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Tue, 4 Oct 2016 11:06:17 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <e7afeb48-a914-43a7-9830-bd7e6f744015@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
	<0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
	<936802ec-49cb-8703-0c4c-c53ba4816357@oracle.com>
	<fe5e432c-7ac2-8b54-6459-fdfa4ec70f64@oracle.com>
	<e7afeb48-a914-43a7-9830-bd7e6f744015@oracle.com>
Message-ID: <a407a97d-2633-5579-5994-920f7bc2d15d@oracle.com>

On 03/10/2016 22:08, Phil Race wrote:

> Do we have a 2nd reviewer yet ? I have not seen it.

Gah you are right, I thought I'd seen a 2nd. Any takers?

-- 
Alan Burlison
--

From ambarish.rapte at oracle.com  Tue Oct  4 10:50:51 2016
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Tue, 4 Oct 2016 03:50:51 -0700 (PDT)
Subject: <AWT Dev> [9] Fix for JDK-8058950 : [TESTBUG] There is no F1
 dialog when the case loading, so we can't restore it.
In-Reply-To: <51d538c3-53a4-a41d-81f2-67be14836e6a@oracle.com>
References: <0e4e0f25-0045-4fbc-8546-60f12945669e@default>
	<75762609-344b-21c1-32cd-7b96094c4fa9@oracle.com>
	<324d8c4f-b9db-40fc-ac53-73c4ccfc7f36@default>
	<51d538c3-53a4-a41d-81f2-67be14836e6a@oracle.com>
Message-ID: <8fb89126-3950-4d85-8f9f-a812880b21bc@default>

Hi Ajit,
	The changes look fine to me.

Regards,
Ambarish

-----Original Message-----
From: Sergey Bylokhov 
Sent: Friday, September 30, 2016 5:21 PM
To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish Rapte
Subject: Re: [9] Fix for JDK-8058950 : [TESTBUG] There is no F1 dialog when the case loading,so we can't restore it.

Looks fine.

On 30.09.16 14:38, Ajit Ghaisas wrote:
> Looking at the issue(JDK-6401700) where this test was introduced, it is clear that this test should run on linux and solaris.
> I have updated the test with appropriate @requires tag.
> http://cr.openjdk.java.net/~aghaisas/8058950/webrev.01/
>
> Request you to review.
>
> Regards,
> Ajit
>
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Thursday, September 29, 2016 6:07 PM
> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish Rapte
> Subject: Re: [9] Fix for JDK-8058950 : [TESTBUG] There is no F1 dialog when the case loading,so we can't restore it.
>
> Should this test start on OSX? I think we can tweak the platforms via @req tag.
>
> On 21.09.16 21:04, Ajit Ghaisas wrote:
>> Hi,
>>
>> Bug :
>>      https://bugs.openjdk.java.net/browse/JDK-8058950
>>
>> Issue :
>>     Minimized test frame cannot be restored.
>>
>> Fix :
>>    1. The test fix is quite simple - to introduce delay between frame.setVisible(true) and frame.setExtendedState(Frame.ICONIFIED).
>>    2. I have modified test - not to use Applet. This results in multiple changes when file diff is seen.
>>
>> Webrev :
>>    http://cr.openjdk.java.net/~aghaisas/8058950/webrev.00/
>>
>> Request you to review.
>>
>> Regards,
>> Ajit
>>
>
>
> --
> Best regards, Sergey.
>


-- 
Best regards, Sergey.

From sergey.bylokhov at oracle.com  Tue Oct  4 12:56:49 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 4 Oct 2016 05:56:49 -0700 (PDT)
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8165555: [macosx]
 VM crashes on second attempt to execute JCK interactive tests that use
 Robot (single JVM, agent)
Message-ID: <903ddfa0-7d42-45f7-a287-c0d239019633@default>

Hi, Manajit. 
It looksbetter, bet it can be improved a little bit. 
- you should not skip exceptions in the run(); 
- It will be good to select the frame by mouse click before pressing the key, otherwise you can run somthing else. 
- I suggest to iterate the code in main a few times in the loop(I guess 10 iterations is ok) 
-The "frame" can be a local var inside the createRobot(), also the method can be renamed. 

----- manajit.halder at oracle.com wrote: 
> 
> Hi Sergey, 
> 

> Thanks for the review. Changes in CRobot.m are removed and added a jtreg test case. 
> Please review the webrev. 
> 

> http://cr.openjdk.java.net/~mhalder/8165555/webrev.03/ 
> 

> Thanks, 
> Manajit 
> 




> On 27-Sep-2016, at 4:15 pm, Sergey Bylokhov < Sergey.Bylokhov at oracle.com > wrote: 

> On 27.09.16 11:51, Manajit Halder wrote: 


Hi Sergey, 

Thanks for the comment. ?self.javaToMacKeyMap is retaining the reference. 
Please review the modified code: 

http://cr.openjdk.java.net/~mhalder/8165555/webrev.02/ 

The changes in CRobot.m is unnecessary? I also suggest to write the test. Recently I have run all jck tests on my osx system and no of them were crashed, so it seems that the sequence of tests in the bug report are not stable and the new reg test will be welcome to catch such bugs always. 





On 23-Sep-2016, at 10:24 pm, Sergey Bylokhov 
< Sergey.Bylokhov at oracle.com < mailto:Sergey.Bylokhov at oracle.com >> wrote: 

On 21.09.16 16:01, Manajit Halder wrote: 


Hi Sergey, 

Thanks for the comment. 

Access to "instance" is not broken. The problem is with the dictionary 
variable "javaToMacKeyMap" within the "instance" reference. 
The dictionary is not getting initialised for the second time when 
singleton method is called for the second time. The dictionary is 
getting initialised during the first time singleton method is called and 
hence crash was observed. Tried adding self.javaToMacKeyMap 
but doesn?t solve the problem. 

I still suggest you to check "self.javaToMacKeyMap" at line 48 this 
should call generated setter which will retain the reference. 




I propose two solutions to this problem: 

Solution 1: 
Reinitialise the dictionary every-time the singleton method is called. 
Webrev: 
http://cr.openjdk.java.net/~mhalder/8165555/webrev.01/ 

Drawback: 
dictionary is initialised multiple times (every time singleton method is 
called). 

Solution 2: 
Make the dictionary static. 
Drawback: 
Still dictionary need to be initialised multiple times. 
No singleton method, just two static methods, one method to initialise 
the dictionary and other to get the key form the dictionary. 
Webrev: 
Not prepared. Will be prepared if second solution accepted. 

Test case: 
There are no test cases. Problem can be reproduced by 
executing following JCK test: 
java -jar JCK-runtime-9/lib/jtjck.jar -mode:single -k:interactive 
"api/java_awt/interactive/event/EventTests.html#EventTest0019 
api/java_awt/interactive/event/EventTests.html#EventTest0013? 

Thanks, 
Manajit 



On 20-Sep-2016, at 4:42 am, Sergey Bylokhov 
< Sergey.Bylokhov at oracle.com 
< mailto:Sergey.Bylokhov at oracle.com > < mailto:Sergey.Bylokhov at oracle.com >> 
wrote: 

Hi, Manajit. 
It seems that after the fix "(CRobotKeyCodeMapping *) sharedInstance" 
returns the new object per invocation, so it is not really 
sharedInstance. I am not sure I understand what is wrong in the 
current code, from the my point of view this is a correct singleton. 
It it true that the problem is in access to broken "instance" and not 
to "javaToMacKeyMap" inside the "instance"? If not then 
"javaToMacKeyMap" should be changed to "self.javaToMacKeyMap". 
Do you have a test case to reproduce the bug? 

On 19.09.16 15:26, Manajit Halder wrote: 


Hi All, 

Kindly review the fix for JDK9. 

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

Webrev: 
http://cr.openjdk.java.net/~mhalder/8165555/webrev.00/ 

Issue: 
[macosx] VM crashes on second attempt to execute JCK interactive tests 
that use Robot (single JVM, agent) 

Cause: 
While executing the JCK test for the second time the robot was getting 
initialised once again and old instance of CRobotKeyCodeMapping was not 
available. 
Crash was observed while trying to access invalid instance of 
CRobotKeyCodeMapping. 

Fix: 
A new instance of CRobotKeyCodeMapping is created when robot is 
initialised. 

Regards, 
Manajit 


-- 
Best regards, Sergey. 



-- 
Best regards, Sergey. 



-- 
Best regards, Sergey. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161004/5b8ad558/attachment.html>

From sergey.bylokhov at oracle.com  Tue Oct  4 13:05:23 2016
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 4 Oct 2016 06:05:23 -0700 (PDT)
Subject: <AWT Dev> <Awt Dev> [9] Review Request for 8141528: Test
 closed/java/awt/FullScreen/DisplayMode/CycleDMImage.java fails for Ubuntu
 15.10
Message-ID: <a981e6a7-539d-4606-9b94-a70c3db37499@default>

Hi, Semyon.
 - It seems that DisplayMode contain the data which were not upscaled to the units instead of pixels. It seems incorrect that it is necessary to convert them here to set the correct size for the window.
 - Is it possible to eliminate check for Unity? I guess that if the size of mode and currentwindow are different then the window should be reshaped unconditionally is unity used or not.

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

> Looks fine.
> 
> --
> Thanks,
> Alexander.
> 
> On 10/03/2016 07:38 PM, Semyon Sadetsky wrote:
> > The fix is updated 
> > http://cr.openjdk.java.net/~ssadetsky/8141528/webrev.01/
> >
> > The root case of the issue is that in Unity the screen window size
> and 
> > location are get updated several times after display mode is
> changed, 
> > and bounds which are set in line 459 of X11GraphicsDevice class are
> 
> > overwritten. Since those window updates caused by display mode
> change 
> > are not predictable the solution is changed to set the correct 
> > full-screen size in the ConfigureNotify handler.
> >
> > --Semyon
> >
> >
> > On 12/7/2015 2:11 PM, Semyon Sadetsky wrote:
> >> Hello,
> >>
> >> Please review fix for JDK9:
> >>
> >> bug: https://bugs.openjdk.java.net/browse/JDK-8141528
> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8141528/webrev.00/
> >>
> >> Compiz WM requires override redirect for full-screen window to 
> >> preserve the full size upon display mode switching.
> >>
> >> --Semyon
> >>
> >

From semyon.sadetsky at oracle.com  Tue Oct  4 13:27:30 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 4 Oct 2016 16:27:30 +0300
Subject: <AWT Dev> <Awt Dev> [9] Review Request for 8141528: Test
 closed/java/awt/FullScreen/DisplayMode/CycleDMImage.java fails for Ubuntu
 15.10
In-Reply-To: <a981e6a7-539d-4606-9b94-a70c3db37499@default>
References: <a981e6a7-539d-4606-9b94-a70c3db37499@default>
Message-ID: <dbdda5bc-518e-5f32-1a32-8e4c76709dee@oracle.com>

On 10/4/2016 4:05 PM, Sergey Bylokhov wrote:

> Hi, Semyon.
>   - It seems that DisplayMode contain the data which were not upscaled to the units instead of pixels. It seems incorrect that it is necessary to convert them here to set the correct size for the window.
Not sure that it is true. Display mode is a device attribute. It should 
be the same as the one presented in the native system configuration.
>   - Is it possible to eliminate check for Unity? I guess that if the size of mode and currentwindow are different then the window should be reshaped unconditionally is unity used or not.
It is not necessary for other Linux OSes because this transitional size 
updates happen only on Unity. Since this WM behavior is undocumented I 
prefer to have an accurately addressed fix.
>
> ----- alexander.zvegintsev at oracle.com wrote:
>
>> Looks fine.
>>
>> --
>> Thanks,
>> Alexander.
>>
>> On 10/03/2016 07:38 PM, Semyon Sadetsky wrote:
>>> The fix is updated
>>> http://cr.openjdk.java.net/~ssadetsky/8141528/webrev.01/
>>>
>>> The root case of the issue is that in Unity the screen window size
>> and
>>> location are get updated several times after display mode is
>> changed,
>>> and bounds which are set in line 459 of X11GraphicsDevice class are
>>> overwritten. Since those window updates caused by display mode
>> change
>>> are not predictable the solution is changed to set the correct
>>> full-screen size in the ConfigureNotify handler.
>>>
>>> --Semyon
>>>
>>>
>>> On 12/7/2015 2:11 PM, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8141528
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8141528/webrev.00/
>>>>
>>>> Compiz WM requires override redirect for full-screen window to
>>>> preserve the full size upon display mode switching.
>>>>
>>>> --Semyon
>>>>


From malenkov at gmail.com  Tue Oct  4 15:49:44 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Tue, 4 Oct 2016 18:49:44 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2jNT7HUZBDu7OJchY6PCUDg-dxQY3xRUuo8tc3=Sdy_Mg@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
	<CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>
	<413b5107-81b2-20ee-2efb-a5fa4480150f@oracle.com>
	<CANTFZ2ieCBgAVkvyXi6MY5y17-foN4tE50MOBKKV1eX9doET4g@mail.gmail.com>
	<7274b203-4648-e2b2-356c-2f70883395ea@oracle.com>
	<CANTFZ2iBRcYuwUs7dWU4ANJsu6oCDVNyVPGnqHK+_pTN-W45dA@mail.gmail.com>
	<db198cb7-bef9-8aef-deab-e56488c68c7c@oracle.com>
	<CANTFZ2gn1bzQv94EniHyjpBDDXtDEAx6WQgMmTo-zEtGcS9nLw@mail.gmail.com>
	<daa84af4-6fe3-521a-d4f8-1938e3284850@oracle.com>
	<CANTFZ2gjd4Ak5BHFk2CxOuNpoma=AbxdwrRSvnQgwYJMDJ0=Pg@mail.gmail.com>
	<cfefbc8a-b088-107d-4330-aecbb3f53120@oracle.com>
	<CANTFZ2jostnYRRT_Bj_OS=7OuL5LXQ1XaPLte7BpG3rKMt+Eag@mail.gmail.com>
	<CANTFZ2jNT7HUZBDu7OJchY6PCUDg-dxQY3xRUuo8tc3=Sdy_Mg@mail.gmail.com>
Message-ID: <CANTFZ2hrMvh74MLUXwAUc=vqeTfCYS-RCCCJeN-ALKEmsjDOfw@mail.gmail.com>

I've got old MacBook Air 2011, 11" non-Retina display.  I installed
Sierra and reproduced the fast scrolling issue.  Now I have no idea
when it can be reproduced and when cannot.  Then I installed 10.12.1
beta (16B2333a).  Seems that the issue is not reproducible with a
system terminal anymore, but it is still reproducible with JDK.  My
first simple patch solves this issue.  Now I'm building new custom JDK
with the patch we created together. Stay tuned...

> Message from Mike Swingler about sensitive scrolling:
>>The original issue your bug was duplicated against
>> has been resolved by the HID engineering team,
>> and should be available in a forthcoming beta of
>> macOS 10.12.1. To get it via Software Update,
>> sign up at <https://beta.apple.com>
>
> We need to test our changes against ASAP.

From alexander.zvegintsev at oracle.com  Tue Oct  4 16:34:25 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 4 Oct 2016 19:34:25 +0300
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <a407a97d-2633-5579-5994-920f7bc2d15d@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
	<0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
	<936802ec-49cb-8703-0c4c-c53ba4816357@oracle.com>
	<fe5e432c-7ac2-8b54-6459-fdfa4ec70f64@oracle.com>
	<e7afeb48-a914-43a7-9830-bd7e6f744015@oracle.com>
	<a407a97d-2633-5579-5994-920f7bc2d15d@oracle.com>
Message-ID: <306947fd-6296-c196-ec65-efe61d3bb262@oracle.com>

Hello,

as I can see there is a memory leak in case when the index is greater 
than or equal to num_syms:

837 KeySym *key_syms = XGetKeyboardMapping(display, keycode, 1, &num_syms);
838 if (index >= num_syms) {
839 return NoSymbol;
840 }

key_syms is not freed.

-- 
Thanks,
Alexander.


On 10/4/16 1:06 PM, Alan Burlison wrote:
> On 03/10/2016 22:08, Phil Race wrote:
>
>> Do we have a 2nd reviewer yet ? I have not seen it.
>
> Gah you are right, I thought I'd seen a 2nd. Any takers?
>

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

From Alan.Burlison at oracle.com  Tue Oct  4 18:34:52 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Tue, 4 Oct 2016 19:34:52 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <306947fd-6296-c196-ec65-efe61d3bb262@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
	<0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
	<936802ec-49cb-8703-0c4c-c53ba4816357@oracle.com>
	<fe5e432c-7ac2-8b54-6459-fdfa4ec70f64@oracle.com>
	<e7afeb48-a914-43a7-9830-bd7e6f744015@oracle.com>
	<a407a97d-2633-5579-5994-920f7bc2d15d@oracle.com>
	<306947fd-6296-c196-ec65-efe61d3bb262@oracle.com>
Message-ID: <e3390fe6-24a7-9e32-5a09-2f35987bf9be@oracle.com>

On 04/10/16 17:34, Alexander Zvegintsev wrote:

> as I can see there is a memory leak in case when the index is greater
> than or equal to num_syms:
>
> 837 KeySym *key_syms = XGetKeyboardMapping(display, keycode, 1, &num_syms);
> 838 if (index >= num_syms) {
> 839 return NoSymbol;
> 840 }
>
> key_syms is not freed.

So there is, thanks for the catch.

-- 
Alan Burlison
--

From Sergey.Bylokhov at oracle.com  Tue Oct  4 22:53:13 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 5 Oct 2016 01:53:13 +0300
Subject: <AWT Dev> <Awt Dev> [9] Review Request for 8141528: Test
 closed/java/awt/FullScreen/DisplayMode/CycleDMImage.java fails for Ubuntu
 15.10
In-Reply-To: <dbdda5bc-518e-5f32-1a32-8e4c76709dee@oracle.com>
References: <a981e6a7-539d-4606-9b94-a70c3db37499@default>
	<dbdda5bc-518e-5f32-1a32-8e4c76709dee@oracle.com>
Message-ID: <f27bf4f9-67c2-0662-12d9-49fb653fda47@oracle.com>

On 04.10.16 16:27, Semyon Sadetsky wrote:
> On 10/4/2016 4:05 PM, Sergey Bylokhov wrote:
>
>> Hi, Semyon.
>>   - It seems that DisplayMode contain the data which were not upscaled
>> to the units instead of pixels. It seems incorrect that it is
>> necessary to convert them here to set the correct size for the window.
> Not sure that it is true. Display mode is a device attribute. It should
> be the same as the one presented in the native system configuration.

But the units in which we reports this values are important, right now 
there is no any API which reports something related to display in 
pixels(insets,bounds, and probably modes.) It seems that display modes 
are ovelooked when HiDPI was pushed. Do DisplayMode we can report pixels 
or units but the same for all platforms. So we can discass it in 
separate bug. Why in this case we cannot use the bounds of the 
graphicsCondiguration? It should be the same as dm.w/scale.

>>   - Is it possible to eliminate check for Unity? I guess that if the
>> size of mode and currentwindow are different then the window should be
>> reshaped unconditionally is unity used or not.
> It is not necessary for other Linux OSes because this transitional size
> updates happen only on Unity. Since this WM behavior is undocumented I
> prefer to have an accurately addressed fix.

Why? If the size was changed and the frame is in fullscreen then we 
should change the size of the window to screen bounds. It is better than 
have a wm specific ifs.

Do you know why the code in X11GraphicsDevice.setDisplayMode() does not 
work?:
         // update bounds of the fullscreen window
         w.setBounds(0, 0, dm.getWidth(), dm.getHeight());


>>
>> ----- alexander.zvegintsev at oracle.com wrote:
>>
>>> Looks fine.
>>>
>>> --
>>> Thanks,
>>> Alexander.
>>>
>>> On 10/03/2016 07:38 PM, Semyon Sadetsky wrote:
>>>> The fix is updated
>>>> http://cr.openjdk.java.net/~ssadetsky/8141528/webrev.01/
>>>>
>>>> The root case of the issue is that in Unity the screen window size
>>> and
>>>> location are get updated several times after display mode is
>>> changed,
>>>> and bounds which are set in line 459 of X11GraphicsDevice class are
>>>> overwritten. Since those window updates caused by display mode
>>> change
>>>> are not predictable the solution is changed to set the correct
>>>> full-screen size in the ConfigureNotify handler.
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 12/7/2015 2:11 PM, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK9:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8141528
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8141528/webrev.00/
>>>>>
>>>>> Compiz WM requires override redirect for full-screen window to
>>>>> preserve the full size upon display mode switching.
>>>>>
>>>>> --Semyon
>>>>>
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Oct  4 23:47:56 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 5 Oct 2016 02:47:56 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <f4a857cc-ebd4-8c65-fd3c-ff9adf4389f3@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
	<04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
	<911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>
	<07ce3934-96fb-dc64-99df-995e5a0ca28a@oracle.com>
	<d88f1d0b-d467-324b-6237-84eeec50046e@oracle.com>
	<38787b3b-1356-977f-ca23-c6e728d3ceda@oracle.com>
	<29f01520-99b0-7438-02a5-51cc248be29d@oracle.com>
	<f45beddd-f4be-ac91-aeee-34786853021f@oracle.com>
	<a43d3eba-5d13-48de-0f83-2efa664da2a3@oracle.com>
	<8c7239fe-51c8-c8f4-84b2-87e16295761d@oracle.com>
	<f4a857cc-ebd4-8c65-fd3c-ff9adf4389f3@oracle.com>
Message-ID: <fb98b819-4ace-170c-e128-68c6d50b167a@oracle.com>

On 29.09.16 23:40, Semyon Sadetsky wrote:
>> The usage of toolkit method here is incorrect, adding it again in this
>> patch is also incorrect. The usage of GC which you remove is correct
>> and should be preserved.
> I don't understand what you call correct and what incorrect. But "the
> usage of GC" results in unexpected behavior which may be only considered
> as incorrect by the user.
>> The problem that the popups do not work is in the way how bounds are
>> used. And this should be fixed.

Incorrect means that the popup code uses the size of the main screen 
even if the popup located on another screen. The bounds of the correct 
screen should be used instead, and this bounds can be accessed via 
Graphics config.

> "in the way how bounds are used"  what does it mean?

In current code the bounds of the graphics config are used incorrectly.


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Oct  5 00:04:52 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 5 Oct 2016 03:04:52 +0300
Subject: <AWT Dev> [9] Review request for 8159432: [PIT][macosx]
 StackOverflow in closed/java/awt/Dialog/DialogDeadlock/DialogDeadlockTest
In-Reply-To: <b455f732-8465-95e4-be0e-ec1221e82e97@oracle.com>
References: <b455f732-8465-95e4-be0e-ec1221e82e97@oracle.com>
Message-ID: <c6fe6b34-97ec-97ca-9770-5180e376c01d@oracle.com>

On 24.08.16 22:18, Semyon Sadetsky wrote:
> The issue is connected to the restoring focus to the previously focused
> window when there are a lot of focus restore requests are coming very
> often (for example series of windows showing and hiding quickly). In
> this case waiting for asynchronous focus causes nested waiting loop, and
> if number of such requests is big enough the StackOverflowError is thrown.
>
> To avoid this the 8139218 solution is revisited to manage the focus
> restore synchronously only if it is possible and send a single
> asynchronous focus request otherwise.

Can you please clarify what is the difference between:
tempLost.requestFocusInWindow() which was updated in the fix, and 
toFocus.requestFocusInWindow() which was not updated. As far as I 
understand the second case(when the toFocus==restoreFocusTo) is a 
component to which we should send ROLLBACK.

-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Wed Oct  5 07:17:50 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 5 Oct 2016 10:17:50 +0300
Subject: <AWT Dev> <Awt Dev> [9] Review Request for 8141528: Test
 closed/java/awt/FullScreen/DisplayMode/CycleDMImage.java fails for Ubuntu
 15.10
In-Reply-To: <f27bf4f9-67c2-0662-12d9-49fb653fda47@oracle.com>
References: <a981e6a7-539d-4606-9b94-a70c3db37499@default>
	<dbdda5bc-518e-5f32-1a32-8e4c76709dee@oracle.com>
	<f27bf4f9-67c2-0662-12d9-49fb653fda47@oracle.com>
Message-ID: <9f153f5b-d133-ee55-cf82-1e93f8725122@oracle.com>

On 05.10.2016 01:53, Sergey Bylokhov wrote:

> On 04.10.16 16:27, Semyon Sadetsky wrote:
>> On 10/4/2016 4:05 PM, Sergey Bylokhov wrote:
>>
>>> Hi, Semyon.
>>>   - It seems that DisplayMode contain the data which were not upscaled
>>> to the units instead of pixels. It seems incorrect that it is
>>> necessary to convert them here to set the correct size for the window.
>> Not sure that it is true. Display mode is a device attribute. It should
>> be the same as the one presented in the native system configuration.
>
> But the units in which we reports this values are important, right now 
> there is no any API which reports something related to display in 
> pixels(insets,bounds, and probably modes.) It seems that display modes 
> are ovelooked when HiDPI was pushed. Do DisplayMode we can report 
> pixels or units but the same for all platforms. So we can discass it 
> in separate bug. Why in this case we cannot use the bounds of the 
> graphicsCondiguration? It should be the same as dm.w/scale.
The DisplayMode size has been always used, I did not change that. I 
guess it is because GC.getBounds() returns RootWindow bounds but we want 
to be closer to the hardware level and avoid WM mediation.
>
>>>   - Is it possible to eliminate check for Unity? I guess that if the
>>> size of mode and currentwindow are different then the window should be
>>> reshaped unconditionally is unity used or not.
>> It is not necessary for other Linux OSes because this transitional size
>> updates happen only on Unity. Since this WM behavior is undocumented I
>> prefer to have an accurately addressed fix.
>
> Why? If the size was changed and the frame is in fullscreen then we 
> should change the size of the window to screen bounds. It is better 
> than have a wm specific ifs.
I already explained why. It is Unity specific. Such change would require 
to test all other WMs because it is about unspecified behavior. Since 
the issue only exits in Unity we don't need to do this extra work and to 
take extra risk.
>
> Do you know why the code in X11GraphicsDevice.setDisplayMode() does 
> not work?:
>         // update bounds of the fullscreen window
>         w.setBounds(0, 0, dm.getWidth(), dm.getHeight());
I explained this already. In Unity changing display mode starts a 
transitional phase during which the windows size and position are 
updated several times. So, after the line above is executed size is 
changed by WM again.
>
>
>>>
>>> ----- alexander.zvegintsev at oracle.com wrote:
>>>
>>>> Looks fine.
>>>>
>>>> -- 
>>>> Thanks,
>>>> Alexander.
>>>>
>>>> On 10/03/2016 07:38 PM, Semyon Sadetsky wrote:
>>>>> The fix is updated
>>>>> http://cr.openjdk.java.net/~ssadetsky/8141528/webrev.01/
>>>>>
>>>>> The root case of the issue is that in Unity the screen window size
>>>> and
>>>>> location are get updated several times after display mode is
>>>> changed,
>>>>> and bounds which are set in line 459 of X11GraphicsDevice class are
>>>>> overwritten. Since those window updates caused by display mode
>>>> change
>>>>> are not predictable the solution is changed to set the correct
>>>>> full-screen size in the ConfigureNotify handler.
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 12/7/2015 2:11 PM, Semyon Sadetsky wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review fix for JDK9:
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8141528
>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8141528/webrev.00/
>>>>>>
>>>>>> Compiz WM requires override redirect for full-screen window to
>>>>>> preserve the full size upon display mode switching.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>
>
>


From semyon.sadetsky at oracle.com  Wed Oct  5 07:40:09 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 5 Oct 2016 10:40:09 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <fb98b819-4ace-170c-e128-68c6d50b167a@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
	<04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
	<911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>
	<07ce3934-96fb-dc64-99df-995e5a0ca28a@oracle.com>
	<d88f1d0b-d467-324b-6237-84eeec50046e@oracle.com>
	<38787b3b-1356-977f-ca23-c6e728d3ceda@oracle.com>
	<29f01520-99b0-7438-02a5-51cc248be29d@oracle.com>
	<f45beddd-f4be-ac91-aeee-34786853021f@oracle.com>
	<a43d3eba-5d13-48de-0f83-2efa664da2a3@oracle.com>
	<8c7239fe-51c8-c8f4-84b2-87e16295761d@oracle.com>
	<f4a857cc-ebd4-8c65-fd3c-ff9adf4389f3@oracle.com>
	<fb98b819-4ace-170c-e128-68c6d50b167a@oracle.com>
Message-ID: <1baec804-931e-f85f-614d-49e79960e472@oracle.com>



On 05.10.2016 02:47, Sergey Bylokhov wrote:
> On 29.09.16 23:40, Semyon Sadetsky wrote:
>>> The usage of toolkit method here is incorrect, adding it again in this
>>> patch is also incorrect. The usage of GC which you remove is correct
>>> and should be preserved.
>> I don't understand what you call correct and what incorrect. But "the
>> usage of GC" results in unexpected behavior which may be only considered
>> as incorrect by the user.
>>> The problem that the popups do not work is in the way how bounds are
>>> used. And this should be fixed.
>
> Incorrect means that the popup code uses the size of the main screen 
> even if the popup located on another screen. The bounds of the correct 
> screen should be used instead, and this bounds can be accessed via 
> Graphics config.
>
>> "in the way how bounds are used"  what does it mean?
>
> In current code the bounds of the graphics config are used incorrectly.
The thing is that the code produce the correct result, while the new 
code caused regression. Or you are insisting that the issue should be 
closed as not a bug?


From semyon.sadetsky at oracle.com  Wed Oct  5 08:45:18 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 5 Oct 2016 11:45:18 +0300
Subject: <AWT Dev> [9] Review request for 8159432: [PIT][macosx]
 StackOverflow in closed/java/awt/Dialog/DialogDeadlock/DialogDeadlockTest
In-Reply-To: <c6fe6b34-97ec-97ca-9770-5180e376c01d@oracle.com>
References: <b455f732-8465-95e4-be0e-ec1221e82e97@oracle.com>
	<c6fe6b34-97ec-97ca-9770-5180e376c01d@oracle.com>
Message-ID: <7b6fdae7-877b-de7d-8fb8-9f9f91653dc3@oracle.com>



On 05.10.2016 03:04, Sergey Bylokhov wrote:
> On 24.08.16 22:18, Semyon Sadetsky wrote:
>> The issue is connected to the restoring focus to the previously focused
>> window when there are a lot of focus restore requests are coming very
>> often (for example series of windows showing and hiding quickly). In
>> this case waiting for asynchronous focus causes nested waiting loop, and
>> if number of such requests is big enough the StackOverflowError is 
>> thrown.
>>
>> To avoid this the 8139218 solution is revisited to manage the focus
>> restore synchronously only if it is possible and send a single
>> asynchronous focus request otherwise.
>
> Can you please clarify what is the difference between:
> tempLost.requestFocusInWindow() which was updated in the fix, and 
> toFocus.requestFocusInWindow() which was not updated. As far as I 
> understand the second case(when the toFocus==restoreFocusTo) is a 
> component to which we should send ROLLBACK.
If you look on the comment above the toFocus.requestFocusInWindow() line 
you get the case when it is called.
Actually tempLost.requestFocusInWindow() is the right place to set 
ROLLBACK. Focus is requested with ROLLBACK cause only when
tempLost==toFocus, but it is hard prove, so I'll better to add the 
condition:

http://cr.openjdk.java.net/~ssadetsky/8159432/webrev.01/


From manajit.halder at oracle.com  Wed Oct  5 09:57:47 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Wed, 5 Oct 2016 15:27:47 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8165555: [macosx]
	VM crashes on second attempt to execute JCK interactive tests
	that use Robot (single JVM, agent)
In-Reply-To: <903ddfa0-7d42-45f7-a287-c0d239019633@default>
References: <903ddfa0-7d42-45f7-a287-c0d239019633@default>
Message-ID: <BA1EC35D-574A-4054-B92E-EB3361C15849@oracle.com>

Hi Sergey,

Thanks for the comments. Please review the updated webrev.
http://cr.openjdk.java.net/~mhalder/8165555/webrev.04/ <http://cr.openjdk.java.net/~mhalder/8165555/webrev.04/>

The ?frame? can?t be a local variable as it is used in two different threads inside the function.

Thanks,
Manajit

> On 04-Oct-2016, at 6:26 pm, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
> 
> Hi, Manajit.
> It looksbetter, bet it can be improved a little bit.
>  - you should not skip exceptions in the run();
>  - It will be good to select the frame by mouse click before pressing the key, otherwise you can run somthing else.
>  - I suggest to iterate the code in main a few times in the loop(I guess 10 iterations is ok)
>  -The "frame" can be a local var inside the createRobot(), also the method can be renamed.
> 
> ----- manajit.halder at oracle.com <mailto:manajit.halder at oracle.com> wrote: 
> > 
> > Hi Sergey,
> > 
> > Thanks for the review. Changes in CRobot.m are removed and added a jtreg test case.
> > Please review the webrev.
> > 
> > http://cr.openjdk.java.net/~mhalder/8165555/webrev.03/ <http://cr.openjdk.java.net/~mhalder/8165555/webrev.03/>
> > 
> > Thanks,
> > Manajit
> > 
> > On 27-Sep-2016, at 4:15 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
> 
> > On 27.09.16 11:51, Manajit Halder wrote:
> Hi Sergey,
> 
> Thanks for the comment. ?self.javaToMacKeyMap is retaining the reference.
> Please review the modified code:
> 
> http://cr.openjdk.java.net/~mhalder/8165555/webrev.02/ <http://cr.openjdk.java.net/~mhalder/8165555/webrev.02/>
> 
> The changes in CRobot.m is unnecessary? I also suggest to write the test. Recently I have run all jck tests on my osx system and no of them were crashed, so it seems that the sequence of tests in the bug report are not stable and the new reg test will be welcome to catch such bugs always.
> 
> On 23-Sep-2016, at 10:24 pm, Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>> wrote:
> 
> On 21.09.16 16:01, Manajit Halder wrote:
> Hi Sergey,
> 
> Thanks for the comment.
> 
> Access to "instance" is not broken. The problem is with the dictionary
> variable "javaToMacKeyMap" within the "instance" reference.
> The dictionary is not getting initialised for the second time when
> singleton method is called for the second time. The dictionary is
> getting initialised during the first time singleton method is called and
> hence crash was observed. Tried adding self.javaToMacKeyMap
> but doesn?t solve the problem.
> 
> I still suggest you to check "self.javaToMacKeyMap" at line 48 this
> should call generated setter which will retain the reference.
> 
> 
> I propose two solutions to this problem:
> 
> Solution 1:
> Reinitialise the dictionary every-time the singleton method is called.
> Webrev:
> http://cr.openjdk.java.net/~mhalder/8165555/webrev.01/ <http://cr.openjdk.java.net/~mhalder/8165555/webrev.01/>
> 
> Drawback:
> dictionary is initialised multiple times (every time singleton method is
> called).
> 
> Solution 2:
> Make the dictionary static.
> Drawback:
> Still dictionary need to be initialised multiple times.
> No singleton method, just two static methods, one method to initialise
> the dictionary and other to get the key form the dictionary.
> Webrev:
> Not prepared. Will be prepared if second solution accepted.
> 
> Test case:
> There are no test cases. Problem can be reproduced by
> executing following JCK test:
> java -jar JCK-runtime-9/lib/jtjck.jar -mode:single -k:interactive
> "api/java_awt/interactive/event/EventTests.html#EventTest0019
> api/java_awt/interactive/event/EventTests.html#EventTest0013?
> 
> Thanks,
> Manajit
> 
> On 20-Sep-2016, at 4:42 am, Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>>
> wrote:
> 
> Hi, Manajit.
> It seems that after the fix "(CRobotKeyCodeMapping *) sharedInstance"
> returns the new object per invocation, so it is not really
> sharedInstance. I am not sure I understand what is wrong in the
> current code, from the my point of view this is a correct singleton.
> It it true that the problem is in access to broken "instance" and not
> to "javaToMacKeyMap" inside the "instance"? If not then
> "javaToMacKeyMap" should be changed to "self.javaToMacKeyMap".
> Do you have a test case to reproduce the bug?
> 
> On 19.09.16 15:26, Manajit Halder wrote:
> Hi All,
> 
> Kindly review the fix for JDK9.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8165555 <https://bugs.openjdk.java.net/browse/JDK-8165555>
> 
> Webrev:
> http://cr.openjdk.java.net/~mhalder/8165555/webrev.00/
> 
> Issue:
> [macosx] VM crashes on second attempt to execute JCK interactive tests
> that use Robot (single JVM, agent)
> 
> Cause:
> While executing the JCK test for the second time the robot was getting
> initialised once again and old instance of CRobotKeyCodeMapping was not
> available.
> Crash was observed while trying to access invalid instance of
> CRobotKeyCodeMapping.
> 
> Fix:
> A new instance of CRobotKeyCodeMapping is created when robot is
> initialised.
> 
> Regards,
> Manajit
> 
> 
> --
> Best regards, Sergey.
> 
> 
> 
> --
> Best regards, Sergey.
> 
> 
> 
> -- 
> Best regards, Sergey.

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

From Sergey.Bylokhov at oracle.com  Wed Oct  5 13:10:20 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 5 Oct 2016 16:10:20 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2jostnYRRT_Bj_OS=7OuL5LXQ1XaPLte7BpG3rKMt+Eag@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
	<CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>
	<413b5107-81b2-20ee-2efb-a5fa4480150f@oracle.com>
	<CANTFZ2ieCBgAVkvyXi6MY5y17-foN4tE50MOBKKV1eX9doET4g@mail.gmail.com>
	<7274b203-4648-e2b2-356c-2f70883395ea@oracle.com>
	<CANTFZ2iBRcYuwUs7dWU4ANJsu6oCDVNyVPGnqHK+_pTN-W45dA@mail.gmail.com>
	<db198cb7-bef9-8aef-deab-e56488c68c7c@oracle.com>
	<CANTFZ2gn1bzQv94EniHyjpBDDXtDEAx6WQgMmTo-zEtGcS9nLw@mail.gmail.com>
	<daa84af4-6fe3-521a-d4f8-1938e3284850@oracle.com>
	<CANTFZ2gjd4Ak5BHFk2CxOuNpoma=AbxdwrRSvnQgwYJMDJ0=Pg@mail.gmail.com>
	<cfefbc8a-b088-107d-4330-aecbb3f53120@oracle.com>
	<CANTFZ2jostnYRRT_Bj_OS=7OuL5LXQ1XaPLte7BpG3rKMt+Eag@mail.gmail.com>
Message-ID: <a8f1c685-7f3a-bcc4-43b9-ad89473c3d1f@oracle.com>

On 30.09.16 20:36, Sergey Malenkov wrote:
>>   The updated version where the brgining threshold is set to 0.5:
>>     http://cr.openjdk.java.net/~alexsch/8166591/webrev.09
>
> Thank you. Looks good.

+1

> Could you please look at the attached patch for 8u?
> I used it with our custom jdk to test the behavior.


-- 
Best regards, Sergey.

From alexandr.scherbatiy at oracle.com  Wed Oct  5 19:46:53 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Wed, 05 Oct 2016 22:46:53 +0300
Subject: <AWT Dev> [8-dev] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
Message-ID: <57F558AD.5030704@oracle.com>


   Hello,

  Could you review the backport of the fix to the JDK8u-dev:
   http://cr.openjdk.java.net/~alexsch/8166591/webrev-jdk8.00

   This is just the same fix as for the JDK 9 (see [1]). There are some 
style differences between JDK 8u-dev and JDK 9 which I needed to merge 
manually. All logic is just the same.

   [1]  http://cr.openjdk.java.net/~alexsch/8166591/webrev.09

   Thanks,
   Alexandr.

From alexandr.scherbatiy at oracle.com  Wed Oct  5 20:10:27 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Wed, 05 Oct 2016 23:10:27 +0300
Subject: <AWT Dev> [8u-dev] Review request for 8166591 [macos 10.12]
 Trackpad scrolling of text on OS X 10.12 Sierra is very fast (Trackpad,
 Retina only)
In-Reply-To: <57F558AD.5030704@oracle.com>
References: <57F558AD.5030704@oracle.com>
Message-ID: <57F55E33.4060606@oracle.com>


   Just corrected the subject to 8u-dev.

   Thanks,
   Alexandr.

05.10.2016 22:46, Alexandr Scherbatiy ?????:
>
>   Hello,
>
>  Could you review the backport of the fix to the JDK8u-dev:
>   http://cr.openjdk.java.net/~alexsch/8166591/webrev-jdk8.00
>
>   This is just the same fix as for the JDK 9 (see [1]). There are some 
> style differences between JDK 8u-dev and JDK 9 which I needed to merge 
> manually. All logic is just the same.
>
>   [1]  http://cr.openjdk.java.net/~alexsch/8166591/webrev.09
>
>   Thanks,
>   Alexandr.


From philip.race at oracle.com  Wed Oct  5 22:01:54 2016
From: philip.race at oracle.com (Phil Race)
Date: Wed, 5 Oct 2016 15:01:54 -0700
Subject: <AWT Dev> 8167126: Create a module to provide access to non-SE
	desktop APIs
Message-ID: <952dec74-97f0-9473-516a-eaadda22ae31@oracle.com>

Webrev : http://cr.openjdk.java.net/~prr/8167126/

The upcoming jigsaw changes to limit use of setAccessible [1] mean
that some work-arounds for non-SE API users will be broken.
To provide for continued access to the capability (albeit via a
different package+class name) this fix adds a jdk.desktop module.
It may be that this is temporary - fixed with a standard API either
later in this release or in a subsequent release, but we need this
in place soon.

The proposed module name - as well as some details of this change -
have already been discussed with representatives of the jigsaw team.

-phil.


From alexander.zvegintsev at oracle.com  Thu Oct  6 01:56:07 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 6 Oct 2016 04:56:07 +0300
Subject: <AWT Dev> [9] Review request for 8166594:
 Taskbar.setWindowProgressValue() spec does not specify expected visual
 behavior of setWindowProgressValue()
Message-ID: <c736beb0-2893-bcdc-1010-a186ed7ef231@oracle.com>

Hello,

please review the fix

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

for the issue

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


It also fixes two issues to conform the documentation:

setting value below 0 doesn't disable progress indication

switching from indeterminate to normal state has no effect

-- 
Thanks,
Alexander.


From alexander.zvegintsev at oracle.com  Thu Oct  6 03:08:01 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 6 Oct 2016 06:08:01 +0300
Subject: <AWT Dev> [9] Review request for 8166942: Usage of SplashScreen
 Functions hangs up FX Application
Message-ID: <c0f7f0c5-69e7-6ce7-1d57-0b99914176ff@oracle.com>

Hello,

please review the fix

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

for the issue

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

SplashEventLoop() acquires the lock[0] and then trying to call 
SplashRedrawWindow() which is trying execute some code on the main 
thread[1]. Thus if we call SplashLock() from the main thread between [0] 
and SplashRedrawWindow() calls then we are in deadlock. Main thread is 
waiting for mutex release, other thread waiting for finish of code 
execution on the main thread. It is our case [2].

The proposed solution is to acquire the lock on the main thread.

[0] 
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/5518ac2f2ead/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m#l359
[1] 
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/5518ac2f2ead/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m#l262
[2] 
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/5518ac2f2ead/src/java.desktop/share/native/libsplashscreen/java_awt_SplashScreen.c#l57

-- 
Thanks,
Alexander.


From semyon.sadetsky at oracle.com  Thu Oct  6 06:23:54 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 6 Oct 2016 09:23:54 +0300
Subject: <AWT Dev> [9] Review request for 8166594:
 Taskbar.setWindowProgressValue() spec does not specify expected visual
 behavior of setWindowProgressValue()
In-Reply-To: <c736beb0-2893-bcdc-1010-a186ed7ef231@oracle.com>
References: <c736beb0-2893-bcdc-1010-a186ed7ef231@oracle.com>
Message-ID: <a2a5db52-ed7e-718d-e8a4-c0c1d8150270@oracle.com>

Hi Alexander,

416      * Note that the behavior is undefined when multiple windows is 
grouped in the task area.

Isn't the above a some kind of simplification?

Could you reformat changed lines to make them following the 80 chars 
maximum?

--Semyon


On 06.10.2016 04:56, Alexander Zvegintsev wrote:
> Hello,
>
> please review the fix
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8166594/00/
>
> for the issue
>
> https://bugs.openjdk.java.net/browse/JDK-8166594
>
>
> It also fixes two issues to conform the documentation:
>
> setting value below 0 doesn't disable progress indication
>
> switching from indeterminate to normal state has no effect
>


From semyon.sadetsky at oracle.com  Thu Oct  6 07:02:51 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 6 Oct 2016 10:02:51 +0300
Subject: <AWT Dev> [9] Review request for 8166942: Usage of SplashScreen
 Functions hangs up FX Application
In-Reply-To: <c0f7f0c5-69e7-6ce7-1d57-0b99914176ff@oracle.com>
References: <c0f7f0c5-69e7-6ce7-1d57-0b99914176ff@oracle.com>
Message-ID: <2a7c0cfb-5304-3c49-da44-a3a24114b2ae@oracle.com>

Hi Alexander,

Is it safe to lock the mutex on one thread and unlock it on another?

--Semyon


On 06.10.2016 06:08, Alexander Zvegintsev wrote:
> Hello,
>
> please review the fix
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8166942/00/
>
> for the issue
>
> https://bugs.openjdk.java.net/browse/JDK-8166942
>
> SplashEventLoop() acquires the lock[0] and then trying to call 
> SplashRedrawWindow() which is trying execute some code on the main 
> thread[1]. Thus if we call SplashLock() from the main thread between 
> [0] and SplashRedrawWindow() calls then we are in deadlock. Main 
> thread is waiting for mutex release, other thread waiting for finish 
> of code execution on the main thread. It is our case [2].
>
> The proposed solution is to acquire the lock on the main thread.
>
> [0] 
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/5518ac2f2ead/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m#l359
> [1] 
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/5518ac2f2ead/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m#l262
> [2] 
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/5518ac2f2ead/src/java.desktop/share/native/libsplashscreen/java_awt_SplashScreen.c#l57
>


From Alan.Bateman at oracle.com  Thu Oct  6 07:24:59 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 6 Oct 2016 08:24:59 +0100
Subject: <AWT Dev> 8167126: Create a module to provide access to non-SE
	desktop APIs
In-Reply-To: <952dec74-97f0-9473-516a-eaadda22ae31@oracle.com>
References: <952dec74-97f0-9473-516a-eaadda22ae31@oracle.com>
Message-ID: <77b4a32e-07ea-f6ed-68b7-805cc009e05a@oracle.com>



On 05/10/2016 23:01, Phil Race wrote:
> Webrev : http://cr.openjdk.java.net/~prr/8167126/
>
> The upcoming jigsaw changes to limit use of setAccessible [1] mean
> that some work-arounds for non-SE API users will be broken.
> To provide for continued access to the capability (albeit via a
> different package+class name) this fix adds a jdk.desktop module.
> It may be that this is temporary - fixed with a standard API either
> later in this release or in a subsequent release, but we need this
> in place soon.
I assume this can be added to the PLATFORM_MODULES list, no need for it 
to be defined to the boot loader. Otherwise looks okay to me.

-Alan

From Alan.Burlison at oracle.com  Thu Oct  6 10:18:45 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Thu, 6 Oct 2016 11:18:45 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <e3390fe6-24a7-9e32-5a09-2f35987bf9be@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
	<0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
	<936802ec-49cb-8703-0c4c-c53ba4816357@oracle.com>
	<fe5e432c-7ac2-8b54-6459-fdfa4ec70f64@oracle.com>
	<e7afeb48-a914-43a7-9830-bd7e6f744015@oracle.com>
	<a407a97d-2633-5579-5994-920f7bc2d15d@oracle.com>
	<306947fd-6296-c196-ec65-efe61d3bb262@oracle.com>
	<e3390fe6-24a7-9e32-5a09-2f35987bf9be@oracle.com>
Message-ID: <55873462-3b77-9c7c-7958-7ecd5fca33c0@oracle.com>

On 04/10/2016 19:34, Alan Burlison wrote:

>> key_syms is not freed.
>
> So there is, thanks for the catch.

Done, webrev updated, jprt -tset hostpot rerun & clean.

-- 
Alan Burlison
--

From Sergey.Bylokhov at oracle.com  Thu Oct  6 10:50:22 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 6 Oct 2016 13:50:22 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8165555: [macosx]
 VM crashes on second attempt to execute JCK interactive tests that use
 Robot (single JVM, agent)
In-Reply-To: <BA1EC35D-574A-4054-B92E-EB3361C15849@oracle.com>
References: <903ddfa0-7d42-45f7-a287-c0d239019633@default>
	<BA1EC35D-574A-4054-B92E-EB3361C15849@oracle.com>
Message-ID: <166c32c7-971e-9bdd-e167-1277d83779ff@oracle.com>

Looks fine.

On 05.10.16 12:57, Manajit Halder wrote:
> Hi Sergey,
>
> Thanks for the comments. Please review the updated webrev.
> http://cr.openjdk.java.net/~mhalder/8165555/webrev.04/
>
> The ?frame? can?t be a local variable as it is used in two different
> threads inside the function.
>
> Thanks,
> Manajit
>
>> On 04-Oct-2016, at 6:26 pm, Sergey Bylokhov
>> <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>> wrote:
>>
>> Hi, Manajit.
>> It looksbetter, bet it can be improved a little bit.
>>  - you should not skip exceptions in the run();
>>  - It will be good to select the frame by mouse click before pressing
>> the key, otherwise you can run somthing else.
>>  - I suggest to iterate the code in main a few times in the loop(I
>> guess 10 iterations is ok)
>>  -The "frame" can be a local var inside the createRobot(), also the
>> method can be renamed.
>>
>> ----- manajit.halder at oracle.com <mailto:manajit.halder at oracle.com> wrote:
>> >
>> > Hi Sergey,
>> >
>> > Thanks for the review. Changes in CRobot.m are removed and added a
>> jtreg test case.
>> > Please review the webrev.
>> >
>> > http://cr.openjdk.java.net/~mhalder/8165555/webrev.03/
>> >
>> > Thanks,
>> > Manajit
>> >
>>
>>     > On 27-Sep-2016, at 4:15 pm, Sergey Bylokhov
>>     <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>
>>     wrote:
>>
>>     > On 27.09.16 11:51, Manajit Halder wrote:
>>
>>         Hi Sergey,
>>
>>         Thanks for the comment. ?self.javaToMacKeyMap is retaining the
>>         reference.
>>         Please review the modified code:
>>
>>         http://cr.openjdk.java.net/~mhalder/8165555/webrev.02/
>>
>>
>>     The changes in CRobot.m is unnecessary? I also suggest to write
>>     the test. Recently I have run all jck tests on my osx system and
>>     no of them were crashed, so it seems that the sequence of tests in
>>     the bug report are not stable and the new reg test will be welcome
>>     to catch such bugs always.
>>
>>             On 23-Sep-2016, at 10:24 pm, Sergey Bylokhov
>>             <Sergey.Bylokhov at oracle.com
>>             <mailto:Sergey.Bylokhov at oracle.com> <mailto:Sergey.Bylokhov at oracle.com>>
>>             wrote:
>>
>>             On 21.09.16 16:01, Manajit Halder wrote:
>>
>>                 Hi Sergey,
>>
>>                 Thanks for the comment.
>>
>>                 Access to "instance" is not broken. The problem is
>>                 with the dictionary
>>                 variable "javaToMacKeyMap" within the "instance"
>>                 reference.
>>                 The dictionary is not getting initialised for the
>>                 second time when
>>                 singleton method is called for the second time. The
>>                 dictionary is
>>                 getting initialised during the first time singleton
>>                 method is called and
>>                 hence crash was observed. Tried adding
>>                 self.javaToMacKeyMap
>>                 but doesn?t solve the problem.
>>
>>
>>             I still suggest you to check "self.javaToMacKeyMap" at
>>             line 48 this
>>             should call generated setter which will retain the reference.
>>
>>
>>                 I propose two solutions to this problem:
>>
>>                 Solution 1:
>>                 Reinitialise the dictionary every-time the singleton
>>                 method is called.
>>                 Webrev:
>>                 http://cr.openjdk.java.net/~mhalder/8165555/webrev.01/
>>
>>                 Drawback:
>>                 dictionary is initialised multiple times (every time
>>                 singleton method is
>>                 called).
>>
>>                 Solution 2:
>>                 Make the dictionary static.
>>                 Drawback:
>>                 Still dictionary need to be initialised multiple times.
>>                 No singleton method, just two static methods, one
>>                 method to initialise
>>                 the dictionary and other to get the key form the
>>                 dictionary.
>>                 Webrev:
>>                 Not prepared. Will be prepared if second solution
>>                 accepted.
>>
>>                 Test case:
>>                 There are no test cases. Problem can be reproduced by
>>                 executing following JCK test:
>>                 java -jar JCK-runtime-9/lib/jtjck.jar -mode:single
>>                 -k:interactive
>>                 "api/java_awt/interactive/event/EventTests.html#EventTest0019
>>                 api/java_awt/interactive/event/EventTests.html#EventTest0013?
>>
>>                 Thanks,
>>                 Manajit
>>
>>                     On 20-Sep-2016, at 4:42 am, Sergey Bylokhov
>>                     <Sergey.Bylokhov at oracle.com
>>                     <mailto:Sergey.Bylokhov at oracle.com>
>>                     <mailto:Sergey.Bylokhov at oracle.com>
>>                     <mailto:Sergey.Bylokhov at oracle.com>>
>>                     wrote:
>>
>>                     Hi, Manajit.
>>                     It seems that after the fix "(CRobotKeyCodeMapping
>>                     *) sharedInstance"
>>                     returns the new object per invocation, so it is
>>                     not really
>>                     sharedInstance. I am not sure I understand what is
>>                     wrong in the
>>                     current code, from the my point of view this is a
>>                     correct singleton.
>>                     It it true that the problem is in access to broken
>>                     "instance" and not
>>                     to "javaToMacKeyMap" inside the "instance"? If not
>>                     then
>>                     "javaToMacKeyMap" should be changed to
>>                     "self.javaToMacKeyMap".
>>                     Do you have a test case to reproduce the bug?
>>
>>                     On 19.09.16 15:26, Manajit Halder wrote:
>>
>>                         Hi All,
>>
>>                         Kindly review the fix for JDK9.
>>
>>                         Bug:
>>                         https://bugs.openjdk.java.net/browse/JDK-8165555
>>
>>                         Webrev:
>>                         http://cr.openjdk.java.net/~mhalder/8165555/webrev.00/
>>
>>                         Issue:
>>                         [macosx] VM crashes on second attempt to
>>                         execute JCK interactive tests
>>                         that use Robot (single JVM, agent)
>>
>>                         Cause:
>>                         While executing the JCK test for the second
>>                         time the robot was getting
>>                         initialised once again and old instance of
>>                         CRobotKeyCodeMapping was not
>>                         available.
>>                         Crash was observed while trying to access
>>                         invalid instance of
>>                         CRobotKeyCodeMapping.
>>
>>                         Fix:
>>                         A new instance of CRobotKeyCodeMapping is
>>                         created when robot is
>>                         initialised.
>>
>>                         Regards,
>>                         Manajit
>>
>>
>>
>>                     --
>>                     Best regards, Sergey.
>>
>>
>>
>>
>>             --
>>             Best regards, Sergey.
>>
>>
>>
>>
>>     --
>>     Best regards, Sergey.
>


-- 
Best regards, Sergey.

From prem.balakrishnan at oracle.com  Thu Oct  6 11:28:35 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Thu, 6 Oct 2016 04:28:35 -0700 (PDT)
Subject: <AWT Dev> Review Request JDK:-8162959 [HiDPI] screenshot artifacts
 using AWT Robot
Message-ID: <d9e5cffb-e2cb-41d8-8557-4aa994ae99c6@default>

Hi,

 

 

Please review fix for JDK 9,

 

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

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

 

I have adapted the same fix as used for JavaFX Robot 

Bug: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8162783"JDK-8162783.

Patch: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/89a5de54b7dc

 

 

New Public API " BufferedImage createScreenCapture(Rectangle screenRect, boolean isHiDPI)" is added,
Which will have a parameter to specify if HiDPI.
 
Regards,
Prem
 

 

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

From avik.niyogi at oracle.com  Thu Oct  6 12:12:04 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Thu, 6 Oct 2016 17:42:04 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8165555: [macosx]
	VM crashes on second attempt to execute JCK interactive tests
	that use Robot (single JVM, agent)
In-Reply-To: <166c32c7-971e-9bdd-e167-1277d83779ff@oracle.com>
References: <903ddfa0-7d42-45f7-a287-c0d239019633@default>
	<BA1EC35D-574A-4054-B92E-EB3361C15849@oracle.com>
	<166c32c7-971e-9bdd-e167-1277d83779ff@oracle.com>
Message-ID: <7F7E4834-ED9E-499F-9525-7C499C2F68E2@oracle.com>

Looks good to me.

> On 06-Oct-2016, at 4:20 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Looks fine.
> 
> On 05.10.16 12:57, Manajit Halder wrote:
>> Hi Sergey,
>> 
>> Thanks for the comments. Please review the updated webrev.
>> http://cr.openjdk.java.net/~mhalder/8165555/webrev.04/
>> 
>> The ?frame? can?t be a local variable as it is used in two different
>> threads inside the function.
>> 
>> Thanks,
>> Manajit
>> 
>>> On 04-Oct-2016, at 6:26 pm, Sergey Bylokhov
>>> <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>> wrote:
>>> 
>>> Hi, Manajit.
>>> It looksbetter, bet it can be improved a little bit.
>>> - you should not skip exceptions in the run();
>>> - It will be good to select the frame by mouse click before pressing
>>> the key, otherwise you can run somthing else.
>>> - I suggest to iterate the code in main a few times in the loop(I
>>> guess 10 iterations is ok)
>>> -The "frame" can be a local var inside the createRobot(), also the
>>> method can be renamed.
>>> 
>>> ----- manajit.halder at oracle.com <mailto:manajit.halder at oracle.com> wrote:
>>> >
>>> > Hi Sergey,
>>> >
>>> > Thanks for the review. Changes in CRobot.m are removed and added a
>>> jtreg test case.
>>> > Please review the webrev.
>>> >
>>> > http://cr.openjdk.java.net/~mhalder/8165555/webrev.03/
>>> >
>>> > Thanks,
>>> > Manajit
>>> >
>>> 
>>>    > On 27-Sep-2016, at 4:15 pm, Sergey Bylokhov
>>>    <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>
>>>    wrote:
>>> 
>>>    > On 27.09.16 11:51, Manajit Halder wrote:
>>> 
>>>        Hi Sergey,
>>> 
>>>        Thanks for the comment. ?self.javaToMacKeyMap is retaining the
>>>        reference.
>>>        Please review the modified code:
>>> 
>>>        http://cr.openjdk.java.net/~mhalder/8165555/webrev.02/
>>> 
>>> 
>>>    The changes in CRobot.m is unnecessary? I also suggest to write
>>>    the test. Recently I have run all jck tests on my osx system and
>>>    no of them were crashed, so it seems that the sequence of tests in
>>>    the bug report are not stable and the new reg test will be welcome
>>>    to catch such bugs always.
>>> 
>>>            On 23-Sep-2016, at 10:24 pm, Sergey Bylokhov
>>>            <Sergey.Bylokhov at oracle.com
>>>            <mailto:Sergey.Bylokhov at oracle.com> <mailto:Sergey.Bylokhov at oracle.com>>
>>>            wrote:
>>> 
>>>            On 21.09.16 16:01, Manajit Halder wrote:
>>> 
>>>                Hi Sergey,
>>> 
>>>                Thanks for the comment.
>>> 
>>>                Access to "instance" is not broken. The problem is
>>>                with the dictionary
>>>                variable "javaToMacKeyMap" within the "instance"
>>>                reference.
>>>                The dictionary is not getting initialised for the
>>>                second time when
>>>                singleton method is called for the second time. The
>>>                dictionary is
>>>                getting initialised during the first time singleton
>>>                method is called and
>>>                hence crash was observed. Tried adding
>>>                self.javaToMacKeyMap
>>>                but doesn?t solve the problem.
>>> 
>>> 
>>>            I still suggest you to check "self.javaToMacKeyMap" at
>>>            line 48 this
>>>            should call generated setter which will retain the reference.
>>> 
>>> 
>>>                I propose two solutions to this problem:
>>> 
>>>                Solution 1:
>>>                Reinitialise the dictionary every-time the singleton
>>>                method is called.
>>>                Webrev:
>>>                http://cr.openjdk.java.net/~mhalder/8165555/webrev.01/
>>> 
>>>                Drawback:
>>>                dictionary is initialised multiple times (every time
>>>                singleton method is
>>>                called).
>>> 
>>>                Solution 2:
>>>                Make the dictionary static.
>>>                Drawback:
>>>                Still dictionary need to be initialised multiple times.
>>>                No singleton method, just two static methods, one
>>>                method to initialise
>>>                the dictionary and other to get the key form the
>>>                dictionary.
>>>                Webrev:
>>>                Not prepared. Will be prepared if second solution
>>>                accepted.
>>> 
>>>                Test case:
>>>                There are no test cases. Problem can be reproduced by
>>>                executing following JCK test:
>>>                java -jar JCK-runtime-9/lib/jtjck.jar -mode:single
>>>                -k:interactive
>>>                "api/java_awt/interactive/event/EventTests.html#EventTest0019
>>>                api/java_awt/interactive/event/EventTests.html#EventTest0013?
>>> 
>>>                Thanks,
>>>                Manajit
>>> 
>>>                    On 20-Sep-2016, at 4:42 am, Sergey Bylokhov
>>>                    <Sergey.Bylokhov at oracle.com
>>>                    <mailto:Sergey.Bylokhov at oracle.com>
>>>                    <mailto:Sergey.Bylokhov at oracle.com>
>>>                    <mailto:Sergey.Bylokhov at oracle.com>>
>>>                    wrote:
>>> 
>>>                    Hi, Manajit.
>>>                    It seems that after the fix "(CRobotKeyCodeMapping
>>>                    *) sharedInstance"
>>>                    returns the new object per invocation, so it is
>>>                    not really
>>>                    sharedInstance. I am not sure I understand what is
>>>                    wrong in the
>>>                    current code, from the my point of view this is a
>>>                    correct singleton.
>>>                    It it true that the problem is in access to broken
>>>                    "instance" and not
>>>                    to "javaToMacKeyMap" inside the "instance"? If not
>>>                    then
>>>                    "javaToMacKeyMap" should be changed to
>>>                    "self.javaToMacKeyMap".
>>>                    Do you have a test case to reproduce the bug?
>>> 
>>>                    On 19.09.16 15:26, Manajit Halder wrote:
>>> 
>>>                        Hi All,
>>> 
>>>                        Kindly review the fix for JDK9.
>>> 
>>>                        Bug:
>>>                        https://bugs.openjdk.java.net/browse/JDK-8165555
>>> 
>>>                        Webrev:
>>>                        http://cr.openjdk.java.net/~mhalder/8165555/webrev.00/
>>> 
>>>                        Issue:
>>>                        [macosx] VM crashes on second attempt to
>>>                        execute JCK interactive tests
>>>                        that use Robot (single JVM, agent)
>>> 
>>>                        Cause:
>>>                        While executing the JCK test for the second
>>>                        time the robot was getting
>>>                        initialised once again and old instance of
>>>                        CRobotKeyCodeMapping was not
>>>                        available.
>>>                        Crash was observed while trying to access
>>>                        invalid instance of
>>>                        CRobotKeyCodeMapping.
>>> 
>>>                        Fix:
>>>                        A new instance of CRobotKeyCodeMapping is
>>>                        created when robot is
>>>                        initialised.
>>> 
>>>                        Regards,
>>>                        Manajit
>>> 
>>> 
>>> 
>>>                    --
>>>                    Best regards, Sergey.
>>> 
>>> 
>>> 
>>> 
>>>            --
>>>            Best regards, Sergey.
>>> 
>>> 
>>> 
>>> 
>>>    --
>>>    Best regards, Sergey.
>> 
> 
> 
> -- 
> Best regards, Sergey.


From alexander.zvegintsev at oracle.com  Thu Oct  6 12:12:17 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 6 Oct 2016 15:12:17 +0300
Subject: <AWT Dev> [9] Review request for 8166942: Usage of SplashScreen
 Functions hangs up FX Application
In-Reply-To: <2a7c0cfb-5304-3c49-da44-a3a24114b2ae@oracle.com>
References: <c0f7f0c5-69e7-6ce7-1d57-0b99914176ff@oracle.com>
	<2a7c0cfb-5304-3c49-da44-a3a24114b2ae@oracle.com>
Message-ID: <031dd82a-a5f2-3a30-5cf8-305cf4830864@oracle.com>

You are right, it it undefined behavior.


On 10/6/16 10:02 AM, Semyon Sadetsky wrote:
> Hi Alexander,
>
> Is it safe to lock the mutex on one thread and unlock it on another?
>
> --Semyon
>
>
> On 06.10.2016 06:08, Alexander Zvegintsev wrote:
>> Hello,
>>
>> please review the fix
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8166942/00/
>>
>> for the issue
>>
>> https://bugs.openjdk.java.net/browse/JDK-8166942
>>
>> SplashEventLoop() acquires the lock[0] and then trying to call 
>> SplashRedrawWindow() which is trying execute some code on the main 
>> thread[1]. Thus if we call SplashLock() from the main thread between 
>> [0] and SplashRedrawWindow() calls then we are in deadlock. Main 
>> thread is waiting for mutex release, other thread waiting for finish 
>> of code execution on the main thread. It is our case [2].
>>
>> The proposed solution is to acquire the lock on the main thread.
>>
>> [0] 
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/5518ac2f2ead/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m#l359
>> [1] 
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/5518ac2f2ead/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m#l262
>> [2] 
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/5518ac2f2ead/src/java.desktop/share/native/libsplashscreen/java_awt_SplashScreen.c#l57
>>
>

-- 
Thanks,
Alexander.


From alexander.zvegintsev at oracle.com  Thu Oct  6 12:38:37 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 6 Oct 2016 15:38:37 +0300
Subject: <AWT Dev> [9] Review request for 8166594:
 Taskbar.setWindowProgressValue() spec does not specify expected visual
 behavior of setWindowProgressValue()
In-Reply-To: <a2a5db52-ed7e-718d-e8a4-c0c1d8150270@oracle.com>
References: <c736beb0-2893-bcdc-1010-a186ed7ef231@oracle.com>
	<a2a5db52-ed7e-718d-e8a4-c0c1d8150270@oracle.com>
Message-ID: <4f22118b-4b8b-aff1-5ce8-f6b5b0216861@oracle.com>

Hi Semyon,

Yes it is, Microsoft defined some set of rules for such case[0].

However it looks redundant and too implementation-specific(which can be 
changed) for me.

Reformatted for 80 chars in place.


[0] 
https://msdn.microsoft.com/en-us/library/windows/desktop/dd391698(v=vs.85).aspx#How_the_Taskbar_Button_Chooses_the_Progress_Indicator_for_a_Group


On 10/6/16 9:23 AM, Semyon Sadetsky wrote:
> Hi Alexander,
>
> 416      * Note that the behavior is undefined when multiple windows 
> is grouped in the task area.
>
> Isn't the above a some kind of simplification?
>
> Could you reformat changed lines to make them following the 80 chars 
> maximum?
>
> --Semyon
>
>
> On 06.10.2016 04:56, Alexander Zvegintsev wrote:
>> Hello,
>>
>> please review the fix
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8166594/00/
>>
>> for the issue
>>
>> https://bugs.openjdk.java.net/browse/JDK-8166594
>>
>>
>> It also fixes two issues to conform the documentation:
>>
>> setting value below 0 doesn't disable progress indication
>>
>> switching from indeterminate to normal state has no effect
>>
>

-- 
Thanks,
Alexander.


From semyon.sadetsky at oracle.com  Thu Oct  6 15:14:17 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 6 Oct 2016 18:14:17 +0300
Subject: <AWT Dev> [9] Review request for 8166594:
 Taskbar.setWindowProgressValue() spec does not specify expected visual
 behavior of setWindowProgressValue()
In-Reply-To: <4f22118b-4b8b-aff1-5ce8-f6b5b0216861@oracle.com>
References: <c736beb0-2893-bcdc-1010-a186ed7ef231@oracle.com>
	<a2a5db52-ed7e-718d-e8a4-c0c1d8150270@oracle.com>
	<4f22118b-4b8b-aff1-5ce8-f6b5b0216861@oracle.com>
Message-ID: <8c284a97-3012-dfcb-a859-9a7759ca6eeb@oracle.com>

On 10/6/2016 3:38 PM, Alexander Zvegintsev wrote:

> Hi Semyon,
>
> Yes it is, Microsoft defined some set of rules for such case[0].
>
> However it looks redundant and too implementation-specific(which can 
> be changed) for me.
I didn't mean to specify the behavior for Windows platform. It seems 
that any desktop platform may have its own rules for this case. 
"Unspecified  behavior" just sounds a bit like a warning to me. Maybe it 
worth to write that this behavior is a platform specific, or don't 
mention the scenario at all since those rules cannot be changed by JDK 
anyway. But it is just a recommendation, the decision is up to you.
>
> Reformatted for 80 chars in place.
Thanks. Looks good then.

--Semyon
>
>
> [0] 
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd391698(v=vs.85).aspx#How_the_Taskbar_Button_Chooses_the_Progress_Indicator_for_a_Group
>
>
> On 10/6/16 9:23 AM, Semyon Sadetsky wrote:
>> Hi Alexander,
>>
>> 416      * Note that the behavior is undefined when multiple windows 
>> is grouped in the task area.
>>
>> Isn't the above a some kind of simplification?
>>
>> Could you reformat changed lines to make them following the 80 chars 
>> maximum?
>>
>> --Semyon
>>
>>
>> On 06.10.2016 04:56, Alexander Zvegintsev wrote:
>>> Hello,
>>>
>>> please review the fix
>>>
>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8166594/00/
>>>
>>> for the issue
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8166594
>>>
>>>
>>> It also fixes two issues to conform the documentation:
>>>
>>> setting value below 0 doesn't disable progress indication
>>>
>>> switching from indeterminate to normal state has no effect
>>>
>>
>


From philip.race at oracle.com  Thu Oct  6 15:58:38 2016
From: philip.race at oracle.com (Phil Race)
Date: Thu, 6 Oct 2016 08:58:38 -0700
Subject: <AWT Dev> 8167126: Create a module to provide access to non-SE
	desktop APIs
In-Reply-To: <77b4a32e-07ea-f6ed-68b7-805cc009e05a@oracle.com>
References: <952dec74-97f0-9473-516a-eaadda22ae31@oracle.com>
	<77b4a32e-07ea-f6ed-68b7-805cc009e05a@oracle.com>
Message-ID: <0feda2dd-0edc-a8df-bbf6-dc349a9f9eec@oracle.com>

Similar modules were on the BOOT list.
Can you explain what each of these lists are and the implications
of being (and not being) listed on each of them ?

-phil.

On 10/06/2016 12:24 AM, Alan Bateman wrote:
>
>
> On 05/10/2016 23:01, Phil Race wrote:
>> Webrev : http://cr.openjdk.java.net/~prr/8167126/
>>
>> The upcoming jigsaw changes to limit use of setAccessible [1] mean
>> that some work-arounds for non-SE API users will be broken.
>> To provide for continued access to the capability (albeit via a
>> different package+class name) this fix adds a jdk.desktop module.
>> It may be that this is temporary - fixed with a standard API either
>> later in this release or in a subsequent release, but we need this
>> in place soon.
> I assume this can be added to the PLATFORM_MODULES list, no need for 
> it to be defined to the boot loader. Otherwise looks okay to me.
>
> -Alan


From Alan.Bateman at oracle.com  Thu Oct  6 16:04:55 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 6 Oct 2016 17:04:55 +0100
Subject: <AWT Dev> 8167126: Create a module to provide access to non-SE
	desktop APIs
In-Reply-To: <0feda2dd-0edc-a8df-bbf6-dc349a9f9eec@oracle.com>
References: <952dec74-97f0-9473-516a-eaadda22ae31@oracle.com>
	<77b4a32e-07ea-f6ed-68b7-805cc009e05a@oracle.com>
	<0feda2dd-0edc-a8df-bbf6-dc349a9f9eec@oracle.com>
Message-ID: <99874798-2e22-5f59-e5ce-756a49036514@oracle.com>

On 06/10/2016 16:58, Phil Race wrote:

> Similar modules were on the BOOT list.
> Can you explain what each of these lists are and the implications
> of being (and not being) listed on each of them ?
>
> -phil.
The BOOT_MODULES list is the list of modules defined to the boot loader, 
the PLATFORM_MODULES list is the modules defined to the platform class 
loader. We want the list for the boot loader to be as small as possible 
as these modules are fully privileged and no way to configure them to 
have less permissions. In this case, then I don't see anything in the 
code that needs to be on the boot loader. Nothing depends on it (which 
is another consideration - if another module defined to the boot loader 
dependent on it then jdk.desktop would need to be defined to the boot 
loader). We have some blur on this in JEP 220 and JEP 261 but we might 
need to all more text to document the details.

-Alan

From philip.race at oracle.com  Thu Oct  6 16:28:56 2016
From: philip.race at oracle.com (Phil Race)
Date: Thu, 6 Oct 2016 09:28:56 -0700
Subject: <AWT Dev> 8167126: Create a module to provide access to non-SE
	desktop APIs
In-Reply-To: <99874798-2e22-5f59-e5ce-756a49036514@oracle.com>
References: <952dec74-97f0-9473-516a-eaadda22ae31@oracle.com>
	<77b4a32e-07ea-f6ed-68b7-805cc009e05a@oracle.com>
	<0feda2dd-0edc-a8df-bbf6-dc349a9f9eec@oracle.com>
	<99874798-2e22-5f59-e5ce-756a49036514@oracle.com>
Message-ID: <c6cccb57-dfe3-f4b3-e179-e607d82c94f2@oracle.com>

OK .. so long as there's no --add-modules needed for that.
Seems to work. Updated webrev :- http://cr.openjdk.java.net/~prr/8167126.1/

-phil.

On 10/06/2016 09:04 AM, Alan Bateman wrote:
> On 06/10/2016 16:58, Phil Race wrote:
>
>> Similar modules were on the BOOT list.
>> Can you explain what each of these lists are and the implications
>> of being (and not being) listed on each of them ?
>>
>> -phil.
> The BOOT_MODULES list is the list of modules defined to the boot 
> loader, the PLATFORM_MODULES list is the modules defined to the 
> platform class loader. We want the list for the boot loader to be as 
> small as possible as these modules are fully privileged and no way to 
> configure them to have less permissions. In this case, then I don't 
> see anything in the code that needs to be on the boot loader. Nothing 
> depends on it (which is another consideration - if another module 
> defined to the boot loader dependent on it then jdk.desktop would need 
> to be defined to the boot loader). We have some blur on this in JEP 
> 220 and JEP 261 but we might need to all more text to document the 
> details.
>
> -Alan


From Sergey.Bylokhov at oracle.com  Thu Oct  6 17:44:13 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 6 Oct 2016 20:44:13 +0300
Subject: <AWT Dev> [8u-dev] Review request for 8166591 [macos 10.12]
 Trackpad scrolling of text on OS X 10.12 Sierra is very fast (Trackpad,
 Retina only)
In-Reply-To: <57F55E33.4060606@oracle.com>
References: <57F558AD.5030704@oracle.com> <57F55E33.4060606@oracle.com>
Message-ID: <0062ddea-0660-84fd-9718-6c52e363c93c@oracle.com>

Looks fine.
On 05.10.16 23:10, Alexandr Scherbatiy wrote:
>
>   Just corrected the subject to 8u-dev.
>
>   Thanks,
>   Alexandr.
>
> 05.10.2016 22:46, Alexandr Scherbatiy ?????:
>>
>>   Hello,
>>
>>  Could you review the backport of the fix to the JDK8u-dev:
>>   http://cr.openjdk.java.net/~alexsch/8166591/webrev-jdk8.00
>>
>>   This is just the same fix as for the JDK 9 (see [1]). There are some
>> style differences between JDK 8u-dev and JDK 9 which I needed to merge
>> manually. All logic is just the same.
>>
>>   [1]  http://cr.openjdk.java.net/~alexsch/8166591/webrev.09
>>
>>   Thanks,
>>   Alexandr.
>


-- 
Best regards, Sergey.

From Alan.Bateman at oracle.com  Thu Oct  6 18:13:10 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 6 Oct 2016 19:13:10 +0100
Subject: <AWT Dev> 8167126: Create a module to provide access to non-SE
	desktop APIs
In-Reply-To: <c6cccb57-dfe3-f4b3-e179-e607d82c94f2@oracle.com>
References: <952dec74-97f0-9473-516a-eaadda22ae31@oracle.com>
	<77b4a32e-07ea-f6ed-68b7-805cc009e05a@oracle.com>
	<0feda2dd-0edc-a8df-bbf6-dc349a9f9eec@oracle.com>
	<99874798-2e22-5f59-e5ce-756a49036514@oracle.com>
	<c6cccb57-dfe3-f4b3-e179-e607d82c94f2@oracle.com>
Message-ID: <e5a92082-59fd-7e9e-cd7c-f8a881ea0f95@oracle.com>



On 06/10/2016 17:28, Phil Race wrote:
> OK .. so long as there's no --add-modules needed for that.
> Seems to work. Updated webrev :- 
> http://cr.openjdk.java.net/~prr/8167126.1/
No --add-modules. The updated webrev looks okay to me.

-Alan

From alexander.zvegintsev at oracle.com  Thu Oct  6 18:21:10 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 6 Oct 2016 21:21:10 +0300
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <55873462-3b77-9c7c-7958-7ecd5fca33c0@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
	<0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
	<936802ec-49cb-8703-0c4c-c53ba4816357@oracle.com>
	<fe5e432c-7ac2-8b54-6459-fdfa4ec70f64@oracle.com>
	<e7afeb48-a914-43a7-9830-bd7e6f744015@oracle.com>
	<a407a97d-2633-5579-5994-920f7bc2d15d@oracle.com>
	<306947fd-6296-c196-ec65-efe61d3bb262@oracle.com>
	<e3390fe6-24a7-9e32-5a09-2f35987bf9be@oracle.com>
	<55873462-3b77-9c7c-7958-7ecd5fca33c0@oracle.com>
Message-ID: <c3c5654c-ef95-7d03-1929-cf439bd451c3@oracle.com>

+1

P.S. It wasn't hard to find, but the webrev is updated at the first 
revision http://cr.openjdk.java.net/~alanbur/JDK-8165232

--
Thanks,
Alexander.

On 06.10.2016 13:18, Alan Burlison wrote:
> On 04/10/2016 19:34, Alan Burlison wrote:
>
>>> key_syms is not freed.
>>
>> So there is, thanks for the catch.
>
> Done, webrev updated, jprt -tset hostpot rerun & clean.
>


From philip.race at oracle.com  Thu Oct  6 18:32:16 2016
From: philip.race at oracle.com (Phil Race)
Date: Thu, 6 Oct 2016 11:32:16 -0700
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <c3c5654c-ef95-7d03-1929-cf439bd451c3@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
	<0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
	<936802ec-49cb-8703-0c4c-c53ba4816357@oracle.com>
	<fe5e432c-7ac2-8b54-6459-fdfa4ec70f64@oracle.com>
	<e7afeb48-a914-43a7-9830-bd7e6f744015@oracle.com>
	<a407a97d-2633-5579-5994-920f7bc2d15d@oracle.com>
	<306947fd-6296-c196-ec65-efe61d3bb262@oracle.com>
	<e3390fe6-24a7-9e32-5a09-2f35987bf9be@oracle.com>
	<55873462-3b77-9c7c-7958-7ecd5fca33c0@oracle.com>
	<c3c5654c-ef95-7d03-1929-cf439bd451c3@oracle.com>
Message-ID: <008a71db-3194-18cd-5288-2aec14509513@oracle.com>

+1

.. and Alan I did suggest last time that the updated webrev be a ".1" as
in place replacement loses history and context for people  who aren't
reading the email thread "live".

I'll push this for Alan since I think he asked for that help ..

-phil.


On 10/06/2016 11:21 AM, Alexander Zvegintsev wrote:
> +1
>
> P.S. It wasn't hard to find, but the webrev is updated at the first 
> revision http://cr.openjdk.java.net/~alanbur/JDK-8165232
>
> -- 
> Thanks,
> Alexander.
>
> On 06.10.2016 13:18, Alan Burlison wrote:
>> On 04/10/2016 19:34, Alan Burlison wrote:
>>
>>>> key_syms is not freed.
>>>
>>> So there is, thanks for the catch.
>>
>> Done, webrev updated, jprt -tset hostpot rerun & clean.
>>
>


From philip.race at oracle.com  Thu Oct  6 18:38:02 2016
From: philip.race at oracle.com (Phil Race)
Date: Thu, 6 Oct 2016 11:38:02 -0700
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <008a71db-3194-18cd-5288-2aec14509513@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
	<0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
	<936802ec-49cb-8703-0c4c-c53ba4816357@oracle.com>
	<fe5e432c-7ac2-8b54-6459-fdfa4ec70f64@oracle.com>
	<e7afeb48-a914-43a7-9830-bd7e6f744015@oracle.com>
	<a407a97d-2633-5579-5994-920f7bc2d15d@oracle.com>
	<306947fd-6296-c196-ec65-efe61d3bb262@oracle.com>
	<e3390fe6-24a7-9e32-5a09-2f35987bf9be@oracle.com>
	<55873462-3b77-9c7c-7958-7ecd5fca33c0@oracle.com>
	<c3c5654c-ef95-7d03-1929-cf439bd451c3@oracle.com>
	<008a71db-3194-18cd-5288-2aec14509513@oracle.com>
Message-ID: <042d3be1-de1d-f767-1d14-e8a1ee8a1907@oracle.com>

PS I am going to change the bug synopsis since otherwise we'll be committing
to the mercurial history something which is different than what we 
actually did.
I'll just truncate it to "XKeycodeToKeysym is deprecated and should be 
replaced"

Oh .. Alan see you already did exactly that :-). So we are in agreement 
there.

-phil.

On 10/06/2016 11:32 AM, Phil Race wrote:
> +1
>
> .. and Alan I did suggest last time that the updated webrev be a ".1" as
> in place replacement loses history and context for people  who aren't
> reading the email thread "live".
>
> I'll push this for Alan since I think he asked for that help ..
>
> -phil.
>
>
> On 10/06/2016 11:21 AM, Alexander Zvegintsev wrote:
>> +1
>>
>> P.S. It wasn't hard to find, but the webrev is updated at the first 
>> revision http://cr.openjdk.java.net/~alanbur/JDK-8165232
>>
>> -- 
>> Thanks,
>> Alexander.
>>
>> On 06.10.2016 13:18, Alan Burlison wrote:
>>> On 04/10/2016 19:34, Alan Burlison wrote:
>>>
>>>>> key_syms is not freed.
>>>>
>>>> So there is, thanks for the catch.
>>>
>>> Done, webrev updated, jprt -tset hostpot rerun & clean.
>>>
>>
>


From malenkov at gmail.com  Thu Oct  6 19:07:37 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Thu, 6 Oct 2016 22:07:37 +0300
Subject: <AWT Dev> [8u-dev] Review request for 8166591 [macos 10.12]
 Trackpad scrolling of text on OS X 10.12 Sierra is very fast (Trackpad,
 Retina only)
In-Reply-To: <0062ddea-0660-84fd-9718-6c52e363c93c@oracle.com>
References: <57F558AD.5030704@oracle.com> <57F55E33.4060606@oracle.com>
	<0062ddea-0660-84fd-9718-6c52e363c93c@oracle.com>
Message-ID: <CANTFZ2iFcisUMEaDkKhDDS9juxuLt8zpezxG3KR4NqsEMn2tgg@mail.gmail.com>

>>>  Could you review the backport of the fix to the JDK8u-dev:
>>>   http://cr.openjdk.java.net/~alexsch/8166591/webrev-jdk8.00
>>>
>>>   This is just the same fix as for the JDK 9 (see [1]). There are some
>>> style differences between JDK 8u-dev and JDK 9 which I needed to merge
>>> manually. All logic is just the same.
>>>
>>>   [1]  http://cr.openjdk.java.net/~alexsch/8166591/webrev.09

> Looks fine.

+1

-- 
Best regards,
Sergey A. Malenkov

From Alan.Burlison at oracle.com  Thu Oct  6 21:25:01 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Thu, 6 Oct 2016 22:25:01 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <008a71db-3194-18cd-5288-2aec14509513@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
	<0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
	<936802ec-49cb-8703-0c4c-c53ba4816357@oracle.com>
	<fe5e432c-7ac2-8b54-6459-fdfa4ec70f64@oracle.com>
	<e7afeb48-a914-43a7-9830-bd7e6f744015@oracle.com>
	<a407a97d-2633-5579-5994-920f7bc2d15d@oracle.com>
	<306947fd-6296-c196-ec65-efe61d3bb262@oracle.com>
	<e3390fe6-24a7-9e32-5a09-2f35987bf9be@oracle.com>
	<55873462-3b77-9c7c-7958-7ecd5fca33c0@oracle.com>
	<c3c5654c-ef95-7d03-1929-cf439bd451c3@oracle.com>
	<008a71db-3194-18cd-5288-2aec14509513@oracle.com>
Message-ID: <cba9cab7-6ddd-d849-f1cc-0c9a5ebd3639@oracle.com>

On 06/10/2016 19:32, Phil Race wrote:

> .. and Alan I did suggest last time that the updated webrev be a ".1" as
> in place replacement loses history and context for people  who aren't
> reading the email thread "live".

Oops, sorry you did say that and I forgot this time round - apologies.

-- 
Alan Burlison
--

From Alan.Burlison at oracle.com  Thu Oct  6 21:26:19 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Thu, 6 Oct 2016 22:26:19 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <042d3be1-de1d-f767-1d14-e8a1ee8a1907@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
	<0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
	<936802ec-49cb-8703-0c4c-c53ba4816357@oracle.com>
	<fe5e432c-7ac2-8b54-6459-fdfa4ec70f64@oracle.com>
	<e7afeb48-a914-43a7-9830-bd7e6f744015@oracle.com>
	<a407a97d-2633-5579-5994-920f7bc2d15d@oracle.com>
	<306947fd-6296-c196-ec65-efe61d3bb262@oracle.com>
	<e3390fe6-24a7-9e32-5a09-2f35987bf9be@oracle.com>
	<55873462-3b77-9c7c-7958-7ecd5fca33c0@oracle.com>
	<c3c5654c-ef95-7d03-1929-cf439bd451c3@oracle.com>
	<008a71db-3194-18cd-5288-2aec14509513@oracle.com>
	<042d3be1-de1d-f767-1d14-e8a1ee8a1907@oracle.com>
Message-ID: <68b5d82c-09f6-7f01-3fd2-8959881bce4e@oracle.com>

On 06/10/2016 19:38, Phil Race wrote:

> PS I am going to change the bug synopsis since otherwise we'll be
> committing to the mercurial history something which is different than
> what we actually did. I'll just truncate it to "XKeycodeToKeysym is
> deprecated and should be replaced"
>
> Oh .. Alan see you already did exactly that :-). So we are in
> agreement there.

Yes, seen the push - thanks :-)

I'll check with a fresh clone tomorrow but I *think* with this committed 
Java9 now builds cleanly on Solaris 12. Yay! :-)

-- 
Alan Burlison
--

From semyon.sadetsky at oracle.com  Fri Oct  7 07:06:24 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 7 Oct 2016 10:06:24 +0300
Subject: <AWT Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
Message-ID: <5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>

Hi Sergey,

After applying the patch I found 72 usages of the Event class. Why they 
are not replaced?

--Semyon


On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
> Thanks for the comments.
> The new version:
> http://cr.openjdk.java.net/~serb/8143077/webrev.01
> The specification of Event class and InputEvent.getModifiers() are 
> updated.
>
> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>> Hi Sergey,
>>
>> I'm not a reviewer, but after reading the deprecation messages in 
>> Event.java
>>
>>     * @deprecated It is recommended that {@code AWTEvent} class and its
>>     subclasses
>>     *             be used instead.
>>
>>
>> I get the impression they would read better without the redundant
>> "class" in the middle, like so.
>>
>>     * @deprecated It is recommended that {@code AWTEvent} and its 
>> subclasses
>>     *             be used instead.
>>
>>
>> Kind regards,
>> Jonathan
>>
>>
>> On 30 September 2016 at 16:45, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>>     Hello.
>>
>>     Please review the fix for jdk9.
>>
>>     This is request to deprecate the obsolete flags inside InputEvent.
>>     This constants were marked as obsolete in jdk1.4 and were replaced
>>     by the new one. In jdk1.4 the documentation were update with notion
>>     that the new constants should be used. And this bug is about
>>     official deprecation of them.
>>
>>     We can replace old constants by the new one in the whole jdk, but I
>>     updated only the code in InputEvent to make change smaller and
>>     safer. So at least the new code in jdk and the code in applications
>>     will start to use the new constants.
>>
>>     The changes in jconsole are necessary to fix deprecation warning.
>>
>>     jprt build passed, no new issues were found by jck/jtreg tests.
>>
>>
>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>>     <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>     Webrev can be found at:
>>     http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>     <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>
>>     --
>>     Best regards, Sergey.
>>
>>
>
>


From semyon.sadetsky at oracle.com  Fri Oct  7 07:28:13 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 7 Oct 2016 10:28:13 +0300
Subject: <AWT Dev> [9] Review Request: 8166673 The new implementation of
 Robot.waitForIdle() may hang
In-Reply-To: <73586e81-9035-10b8-de87-0ab220ee5395@oracle.com>
References: <73586e81-9035-10b8-de87-0ab220ee5395@oracle.com>
Message-ID: <d53fc03c-6f16-06d1-7f38-9a2d90833904@oracle.com>

Hi Sergey,

1525         queueEmpty = false;
1526         eventDispatched = false;
1527         synchronized(waitLock) {

Shouldn't lines 1525 & 1526 be moved inside the synchronized block?

--Semyon


On 9/26/2016 8:38 PM, Sergey Bylokhov wrote:
> Hello.
>
> Please review the fix for jdk9.
>
> The SunToolkit.waitForIdle() uses string literal for synchronization, 
> which means some code (intentionally or not) can hang Robot.waitForIdle.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166673
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8166673/webrev.00
>


From manajit.halder at oracle.com  Fri Oct  7 12:10:07 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Fri, 7 Oct 2016 17:40:07 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8158380: Regression:
	java/awt/List/ActionEventTest/ActionEventTest.java
Message-ID: <4367BB1F-6B9C-43E0-A6A9-0A85A101184D@oracle.com>

Hi All,

Kindly review the fix for JDK9.

Bug: 
https://bugs.openjdk.java.net/browse/JDK-8158380 <https://bugs.openjdk.java.net/browse/JDK-8158380>

Webrev: 
http://cr.openjdk.java.net/~mhalder/8158380/webrev.00/ <http://cr.openjdk.java.net/~mhalder/8158380/webrev.00/>

Issue: 
Regression: java/awt/List/ActionEventTest/ActionEventTest.java

Cause: 
ActionEvent getModifiers() method was returning wrong value in test ActionEventTest.java due to wrong modifier value.
Submenu was not activated by menmonic key press in SubMenuShowTest.java. 
In both the cases event queue was not processed completely for robot keyPress and keyRelease events.

Fix: 
In both the cases problem was solved by adding waitForIdle after robot operations (keyPress and keyRelease).

Regards,
Manajit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161007/8db28d7f/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Fri Oct  7 13:21:20 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 7 Oct 2016 16:21:20 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
Message-ID: <7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>

On 07.10.16 10:06, Semyon Sadetsky wrote:
> Hi Sergey,
>
> After applying the patch I found 72 usages of the Event class. Why they
> are not replaced?

By the same reason why InputEvent.getModifiers() was not replaced by 
InputEvent.getModifiersEx():

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


> On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
>> Thanks for the comments.
>> The new version:
>> http://cr.openjdk.java.net/~serb/8143077/webrev.01
>> The specification of Event class and InputEvent.getModifiers() are
>> updated.
>>
>> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>>> Hi Sergey,
>>>
>>> I'm not a reviewer, but after reading the deprecation messages in
>>> Event.java
>>>
>>>     * @deprecated It is recommended that {@code AWTEvent} class and its
>>>     subclasses
>>>     *             be used instead.
>>>
>>>
>>> I get the impression they would read better without the redundant
>>> "class" in the middle, like so.
>>>
>>>     * @deprecated It is recommended that {@code AWTEvent} and its
>>> subclasses
>>>     *             be used instead.
>>>
>>>
>>> Kind regards,
>>> Jonathan
>>>
>>>
>>> On 30 September 2016 at 16:45, Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>
>>>     Hello.
>>>
>>>     Please review the fix for jdk9.
>>>
>>>     This is request to deprecate the obsolete flags inside InputEvent.
>>>     This constants were marked as obsolete in jdk1.4 and were replaced
>>>     by the new one. In jdk1.4 the documentation were update with notion
>>>     that the new constants should be used. And this bug is about
>>>     official deprecation of them.
>>>
>>>     We can replace old constants by the new one in the whole jdk, but I
>>>     updated only the code in InputEvent to make change smaller and
>>>     safer. So at least the new code in jdk and the code in applications
>>>     will start to use the new constants.
>>>
>>>     The changes in jconsole are necessary to fix deprecation warning.
>>>
>>>     jprt build passed, no new issues were found by jck/jtreg tests.
>>>
>>>
>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>>>     <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>>     Webrev can be found at:
>>>     http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>>     <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>>
>>>     --
>>>     Best regards, Sergey.
>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Oct  7 14:07:29 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 7 Oct 2016 17:07:29 +0300
Subject: <AWT Dev> [9] Review Request: 8166673 The new implementation of
 Robot.waitForIdle() may hang
In-Reply-To: <d53fc03c-6f16-06d1-7f38-9a2d90833904@oracle.com>
References: <73586e81-9035-10b8-de87-0ab220ee5395@oracle.com>
	<d53fc03c-6f16-06d1-7f38-9a2d90833904@oracle.com>
Message-ID: <062faa6e-426f-3e6c-dab9-10c0d9d8211c@oracle.com>

On 07.10.16 10:28, Semyon Sadetsky wrote:
> Hi Sergey,
>
> 1525         queueEmpty = false;
> 1526         eventDispatched = false;
> 1527         synchronized(waitLock) {
>
> Shouldn't lines 1525 & 1526 be moved inside the synchronized block?

I think so, at least this will unify how we use these in dispatch event 
and at the end of waitForIdle():
http://cr.openjdk.java.net/~serb/8166673/webrev.01

> On 9/26/2016 8:38 PM, Sergey Bylokhov wrote:
>> Hello.
>>
>> Please review the fix for jdk9.
>>
>> The SunToolkit.waitForIdle() uses string literal for synchronization,
>> which means some code (intentionally or not) can hang Robot.waitForIdle.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166673
>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/8166673/webrev.00
>>
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Oct  7 14:11:01 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 7 Oct 2016 17:11:01 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8158380:
 Regression: java/awt/List/ActionEventTest/ActionEventTest.java
In-Reply-To: <4367BB1F-6B9C-43E0-A6A9-0A85A101184D@oracle.com>
References: <4367BB1F-6B9C-43E0-A6A9-0A85A101184D@oracle.com>
Message-ID: <4ae465d2-9987-4d48-00d0-603074ff0bf9@oracle.com>

Hi, Manajit.
Instead of adding these methods between operations you can call these 
after robot creation:
     Robot.setAutoDelay(int ms)
     Robot.setAutoWaitForIdle(boolean isOn)

On 07.10.16 15:10, Manajit Halder wrote:
> Hi All,
>
> Kindly review the fix for JDK9.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8158380
>
> Webrev:
> http://cr.openjdk.java.net/~mhalder/8158380/webrev.00/
>
> Issue:
> Regression: java/awt/List/ActionEventTest/ActionEventTest.java
>
> Cause:
> ActionEvent getModifiers() method was returning wrong value in test
> ActionEventTest.java due to wrong modifier value.
> Submenu was not activated by menmonic key press in SubMenuShowTest.java.
> In both the cases event queue was not processed completely for robot
> keyPress and keyRelease events.
>
> Fix:
> In both the cases problem was solved by adding waitForIdle after robot
> operations (keyPress and keyRelease).
>
> Regards,
> Manajit


-- 
Best regards, Sergey.

From anubhav.meena at oracle.com  Fri Oct  7 13:16:06 2016
From: anubhav.meena at oracle.com (Anubhav Meena)
Date: Fri, 7 Oct 2016 18:46:06 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8161473:[TEST_BUG]
	[macosx] add autodelay to
	java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java
Message-ID: <334B090B-6409-4467-AD8D-AF0EAD1935F7@oracle.com>

Hi All,

Kindly review the fix for JDK9.

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

Webrev: 
http://cr.openjdk.java.net/~rchamyal/anmeena/8161473/webrev.00/

Issue: 
[macosx] The test java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java often fails, especially on OS X.

Cause: 
Lack of minimal delay between elementary robot operations

Fix: 
Added wait for idle operation between two robot events.

Regards,
Anubhav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161007/5e23319d/attachment.html>

From Alan.Burlison at oracle.com  Fri Oct  7 18:35:02 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Fri, 7 Oct 2016 19:35:02 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <68b5d82c-09f6-7f01-3fd2-8959881bce4e@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
	<0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
	<936802ec-49cb-8703-0c4c-c53ba4816357@oracle.com>
	<fe5e432c-7ac2-8b54-6459-fdfa4ec70f64@oracle.com>
	<e7afeb48-a914-43a7-9830-bd7e6f744015@oracle.com>
	<a407a97d-2633-5579-5994-920f7bc2d15d@oracle.com>
	<306947fd-6296-c196-ec65-efe61d3bb262@oracle.com>
	<e3390fe6-24a7-9e32-5a09-2f35987bf9be@oracle.com>
	<55873462-3b77-9c7c-7958-7ecd5fca33c0@oracle.com>
	<c3c5654c-ef95-7d03-1929-cf439bd451c3@oracle.com>
	<008a71db-3194-18cd-5288-2aec14509513@oracle.com>
	<042d3be1-de1d-f767-1d14-e8a1ee8a1907@oracle.com>
	<68b5d82c-09f6-7f01-3fd2-8959881bce4e@oracle.com>
Message-ID: <602509c8-007a-8fd7-d794-77d25511c9fd@oracle.com>

On 06/10/2016 22:26, Alan Burlison wrote:

>> Oh .. Alan see you already did exactly that :-). So we are in
>> agreement there.
>
> Yes, seen the push - thanks :-)
>
> I'll check with a fresh clone tomorrow but I *think* with this committed
> Java9 now builds cleanly on Solaris 12. Yay! :-)

Hmm, I've just pulled a fresh tree from 
http://hg.openjdk.java.net/jdk9/dev and the changeset doesn't seem to be 
there...

-- 
Alan Burlison
--

From philip.race at oracle.com  Fri Oct  7 18:40:27 2016
From: philip.race at oracle.com (Philip Race)
Date: Fri, 07 Oct 2016 11:40:27 -0700
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <602509c8-007a-8fd7-d794-77d25511c9fd@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
	<0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
	<936802ec-49cb-8703-0c4c-c53ba4816357@oracle.com>
	<fe5e432c-7ac2-8b54-6459-fdfa4ec70f64@oracle.com>
	<e7afeb48-a914-43a7-9830-bd7e6f744015@oracle.com>
	<a407a97d-2633-5579-5994-920f7bc2d15d@oracle.com>
	<306947fd-6296-c196-ec65-efe61d3bb262@oracle.com>
	<e3390fe6-24a7-9e32-5a09-2f35987bf9be@oracle.com>
	<55873462-3b77-9c7c-7958-7ecd5fca33c0@oracle.com>
	<c3c5654c-ef95-7d03-1929-cf439bd451c3@oracle.com>
	<008a71db-3194-18cd-5288-2aec14509513@oracle.com>
	<042d3be1-de1d-f767-1d14-e8a1ee8a1907@oracle.com>
	<68b5d82c-09f6-7f01-3fd2-8959881bce4e@oracle.com>
	<602509c8-007a-8fd7-d794-77d25511c9fd@oracle.com>
Message-ID: <57F7EC1B.1070807@oracle.com>

You are looking at the wrong forest.
All client changes must always go to http://hg.openjdk.java.net/jdk9/client.

-phil.

On 10/7/16, 11:35 AM, Alan Burlison wrote:
> On 06/10/2016 22:26, Alan Burlison wrote:
>
>>> Oh .. Alan see you already did exactly that :-). So we are in
>>> agreement there.
>>
>> Yes, seen the push - thanks :-)
>>
>> I'll check with a fresh clone tomorrow but I *think* with this committed
>> Java9 now builds cleanly on Solaris 12. Yay! :-)
>
> Hmm, I've just pulled a fresh tree from 
> http://hg.openjdk.java.net/jdk9/dev and the changeset doesn't seem to 
> be there...
>

From Alan.Burlison at oracle.com  Fri Oct  7 21:42:34 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Fri, 7 Oct 2016 22:42:34 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <57F7EC1B.1070807@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
	<0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
	<936802ec-49cb-8703-0c4c-c53ba4816357@oracle.com>
	<fe5e432c-7ac2-8b54-6459-fdfa4ec70f64@oracle.com>
	<e7afeb48-a914-43a7-9830-bd7e6f744015@oracle.com>
	<a407a97d-2633-5579-5994-920f7bc2d15d@oracle.com>
	<306947fd-6296-c196-ec65-efe61d3bb262@oracle.com>
	<e3390fe6-24a7-9e32-5a09-2f35987bf9be@oracle.com>
	<55873462-3b77-9c7c-7958-7ecd5fca33c0@oracle.com>
	<c3c5654c-ef95-7d03-1929-cf439bd451c3@oracle.com>
	<008a71db-3194-18cd-5288-2aec14509513@oracle.com>
	<042d3be1-de1d-f767-1d14-e8a1ee8a1907@oracle.com>
	<68b5d82c-09f6-7f01-3fd2-8959881bce4e@oracle.com>
	<602509c8-007a-8fd7-d794-77d25511c9fd@oracle.com>
	<57F7EC1B.1070807@oracle.com>
Message-ID: <acb2bbe5-c5e2-805c-9380-9d0ebf13db5c@oracle.com>

On 07/10/16 19:40, Philip Race wrote:

> You are looking at the wrong forest.
> All client changes must always go to
> http://hg.openjdk.java.net/jdk9/client.

Ah, right. Will that end up in dev eventually? I haven't found anything 
so far that explains the relationships between all the repo forests...

-- 
Alan Burlison
--

From philip.race at oracle.com  Fri Oct  7 21:54:46 2016
From: philip.race at oracle.com (Philip Race)
Date: Fri, 07 Oct 2016 14:54:46 -0700
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <acb2bbe5-c5e2-805c-9380-9d0ebf13db5c@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
	<0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
	<936802ec-49cb-8703-0c4c-c53ba4816357@oracle.com>
	<fe5e432c-7ac2-8b54-6459-fdfa4ec70f64@oracle.com>
	<e7afeb48-a914-43a7-9830-bd7e6f744015@oracle.com>
	<a407a97d-2633-5579-5994-920f7bc2d15d@oracle.com>
	<306947fd-6296-c196-ec65-efe61d3bb262@oracle.com>
	<e3390fe6-24a7-9e32-5a09-2f35987bf9be@oracle.com>
	<55873462-3b77-9c7c-7958-7ecd5fca33c0@oracle.com>
	<c3c5654c-ef95-7d03-1929-cf439bd451c3@oracle.com>
	<008a71db-3194-18cd-5288-2aec14509513@oracle.com>
	<042d3be1-de1d-f767-1d14-e8a1ee8a1907@oracle.com>
	<68b5d82c-09f6-7f01-3fd2-8959881bce4e@oracle.com>
	<602509c8-007a-8fd7-d794-77d25511c9fd@oracle.com>
	<57F7EC1B.1070807@oracle.com>
	<acb2bbe5-c5e2-805c-9380-9d0ebf13db5c@oracle.com>
Message-ID: <57F819A6.7080607@oracle.com>

jdk9/jdk9 is the master from which RE builds are created
jdk9/dev is for core-libs + tools + similar
jdk9/client is for client
jdk9/hs-=* are the various hotspot ones ..

Generally you can think of "dev" as the only direct child of master.
jdk9/hs and jdk9/client are children of dev
the  hs-* ones are children of jdk9/hs

There's also a sandbox for experiments (using branches)

-phil.

On 10/7/16, 2:42 PM, Alan Burlison wrote:
> On 07/10/16 19:40, Philip Race wrote:
>
>> You are looking at the wrong forest.
>> All client changes must always go to
>> http://hg.openjdk.java.net/jdk9/client.
>
> Ah, right. Will that end up in dev eventually? I haven't found 
> anything so far that explains the relationships between all the repo 
> forests...
>

From ambarish.rapte at oracle.com  Mon Oct 10 08:31:27 2016
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Mon, 10 Oct 2016 01:31:27 -0700 (PDT)
Subject: <AWT Dev> <AWT dev>[9] Review request for
 JDK-8161473:[TEST_BUG] [macosx] add autodelay to
 java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java
In-Reply-To: <334B090B-6409-4467-AD8D-AF0EAD1935F7@oracle.com>
References: <334B090B-6409-4467-AD8D-AF0EAD1935F7@oracle.com>
Message-ID: <147d64e5-38c1-4424-bed7-774d38c9e6e3@default>

Hi Anubhav,

 

                Along with the fix, could you please add below trivial changes as well,

 

1.       Add @key headful & @bug 8161473  jtreg tags

2.       Change wild card * import to add specific package imports.

3.       Update copyright with year 2016.

 

 

Regards,

Ambarish

 

From: Anubhav Meena 
Sent: Friday, October 07, 2016 6:46 PM
To: awt-dev at openjdk.java.net
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8161473:[TEST_BUG] [macosx] add autodelay to java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java

 

Hi All,

 

Kindly review the fix for JDK9.

 

Bug: 

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

 

Webrev: 

http://cr.openjdk.java.net/~rchamyal/anmeena/8161473/webrev.00/

 

Issue: 

[macosx] The test java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java often fails, especially on OS X.

 

Cause: 

Lack of minimal delay between elementary robot operations

 

Fix: 

Added wait for idle operation between two robot events.

 

Regards,

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

From anubhav.meena at oracle.com  Mon Oct 10 11:35:51 2016
From: anubhav.meena at oracle.com (Anubhav Meena)
Date: Mon, 10 Oct 2016 17:05:51 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for
	JDK-8161473:[TEST_BUG] [macosx] add autodelay to
	java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java
In-Reply-To: <147d64e5-38c1-4424-bed7-774d38c9e6e3@default>
References: <334B090B-6409-4467-AD8D-AF0EAD1935F7@oracle.com>
	<147d64e5-38c1-4424-bed7-774d38c9e6e3@default>
Message-ID: <27223022-A599-47EE-8ED8-C3BFE962451F@oracle.com>

Hi Ambarish,

Have made the changes you suggested. Please find them here http://cr.openjdk.java.net/~rchamyal/anmeena/8161473/webrev.01/

Thanks,
Anubhav

> On Oct 10, 2016, at 2:01 PM, Ambarish Rapte <ambarish.rapte at oracle.com> wrote:
> 
> Hi Anubhav,
>  
>                 Along with the fix, could you please add below trivial changes as well,
>  
> 1.       Add @key headful & @bug 8161473  jtreg tags
> 2.       Change wild card * import to add specific package imports.
> 3.       Update copyright with year 2016.
>  
>  
> Regards,
> Ambarish
>  
> From: Anubhav Meena 
> Sent: Friday, October 07, 2016 6:46 PM
> To: awt-dev at openjdk.java.net
> Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8161473:[TEST_BUG] [macosx] add autodelay to java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java
>  
> Hi All,
>  
> Kindly review the fix for JDK9.
>  
> Bug: 
> https://bugs.openjdk.java.net/browse/JDK-8161473 <https://bugs.openjdk.java.net/browse/JDK-8161473>
>  
> Webrev: 
> http://cr.openjdk.java.net/~rchamyal/anmeena/8161473/webrev.00/ <http://cr.openjdk.java.net/~rchamyal/anmeena/8161473/webrev.00/>
>  
> Issue: 
> [macosx] The test java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java often fails, especially on OS X.
>  
> Cause: 
> Lack of minimal delay between elementary robot operations
>  
> Fix: 
> Added wait for idle operation between two robot events.
>  
> Regards,
> Anubhav

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

From manajit.halder at oracle.com  Mon Oct 10 11:41:40 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Mon, 10 Oct 2016 17:11:40 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8158380:
	Regression: java/awt/List/ActionEventTest/ActionEventTest.java
In-Reply-To: <4ae465d2-9987-4d48-00d0-603074ff0bf9@oracle.com>
References: <4367BB1F-6B9C-43E0-A6A9-0A85A101184D@oracle.com>
	<4ae465d2-9987-4d48-00d0-603074ff0bf9@oracle.com>
Message-ID: <F8C42F8C-1632-40C1-AC05-9F66D4F55584@oracle.com>

Hi Sergey,

Thank you for the review. Please review the modified webrev.
http://cr.openjdk.java.net/~mhalder/8158380/webrev.01/ <http://cr.openjdk.java.net/~mhalder/8158380/webrev.01/>

Thanks,
Manajit

> On 07-Oct-2016, at 7:41 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Manajit.
> Instead of adding these methods between operations you can call these after robot creation:
>    Robot.setAutoDelay(int ms)
>    Robot.setAutoWaitForIdle(boolean isOn)
> 
> On 07.10.16 15:10, Manajit Halder wrote:
>> Hi All,
>> 
>> Kindly review the fix for JDK9.
>> 
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8158380
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mhalder/8158380/webrev.00/
>> 
>> Issue:
>> Regression: java/awt/List/ActionEventTest/ActionEventTest.java
>> 
>> Cause:
>> ActionEvent getModifiers() method was returning wrong value in test
>> ActionEventTest.java due to wrong modifier value.
>> Submenu was not activated by menmonic key press in SubMenuShowTest.java.
>> In both the cases event queue was not processed completely for robot
>> keyPress and keyRelease events.
>> 
>> Fix:
>> In both the cases problem was solved by adding waitForIdle after robot
>> operations (keyPress and keyRelease).
>> 
>> Regards,
>> Manajit
> 
> 
> -- 
> Best regards, Sergey.

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

From Sergey.Bylokhov at oracle.com  Mon Oct 10 12:28:44 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 10 Oct 2016 15:28:44 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8158380:
 Regression: java/awt/List/ActionEventTest/ActionEventTest.java
In-Reply-To: <F8C42F8C-1632-40C1-AC05-9F66D4F55584@oracle.com>
References: <4367BB1F-6B9C-43E0-A6A9-0A85A101184D@oracle.com>
	<4ae465d2-9987-4d48-00d0-603074ff0bf9@oracle.com>
	<F8C42F8C-1632-40C1-AC05-9F66D4F55584@oracle.com>
Message-ID: <e20b06a0-d95a-8fc0-e175-37109a0486fe@oracle.com>

It seems that "Copyright (c)" is incorrectly updated in both tests.

On 10.10.16 14:41, Manajit Halder wrote:
> Hi Sergey,
>
> Thank you for the review. Please review the modified webrev.
> http://cr.openjdk.java.net/~mhalder/8158380/webrev.01/
>
> Thanks,
> Manajit
>
>> On 07-Oct-2016, at 7:41 pm, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> Hi, Manajit.
>> Instead of adding these methods between operations you can call these
>> after robot creation:
>>    Robot.setAutoDelay(int ms)
>>    Robot.setAutoWaitForIdle(boolean isOn)
>>
>> On 07.10.16 15:10, Manajit Halder wrote:
>>> Hi All,
>>>
>>> Kindly review the fix for JDK9.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8158380
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mhalder/8158380/webrev.00/
>>>
>>> Issue:
>>> Regression: java/awt/List/ActionEventTest/ActionEventTest.java
>>>
>>> Cause:
>>> ActionEvent getModifiers() method was returning wrong value in test
>>> ActionEventTest.java due to wrong modifier value.
>>> Submenu was not activated by menmonic key press in SubMenuShowTest.java.
>>> In both the cases event queue was not processed completely for robot
>>> keyPress and keyRelease events.
>>>
>>> Fix:
>>> In both the cases problem was solved by adding waitForIdle after robot
>>> operations (keyPress and keyRelease).
>>>
>>> Regards,
>>> Manajit
>>
>>
>> --
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Tue Oct 11 13:15:46 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 11 Oct 2016 16:15:46 +0300
Subject: <AWT Dev> [9] Review request for 8167486: Device.getDisplayMode()
 doesn't report refresh rate on Linux in case of dual screen
Message-ID: <d7ce05cf-6e35-bba9-317d-244fe0c11ba8@oracle.com>

Hello,

Please review fix for JDK9:

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

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

In  case Xinerama is on, the current display mode cannot be obtained by 
the old xrandr lib calls for secondary screens. The new xrandr API that 
supports Xinerama is used for this case in the proposed solution.

--Semyon


From alexander.zvegintsev at oracle.com  Tue Oct 11 13:36:13 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 11 Oct 2016 16:36:13 +0300
Subject: <AWT Dev> [9] Review Request: 8166673 The new implementation of
 Robot.waitForIdle() may hang
In-Reply-To: <062faa6e-426f-3e6c-dab9-10c0d9d8211c@oracle.com>
References: <73586e81-9035-10b8-de87-0ab220ee5395@oracle.com>
	<d53fc03c-6f16-06d1-7f38-9a2d90833904@oracle.com>
	<062faa6e-426f-3e6c-dab9-10c0d9d8211c@oracle.com>
Message-ID: <47c431f1-9b1f-7fcb-63d5-bdf2c4b7d438@oracle.com>

+1

--
Thanks,
Alexander.

On 07.10.2016 17:07, Sergey Bylokhov wrote:
> On 07.10.16 10:28, Semyon Sadetsky wrote:
>> Hi Sergey,
>>
>> 1525         queueEmpty = false;
>> 1526         eventDispatched = false;
>> 1527         synchronized(waitLock) {
>>
>> Shouldn't lines 1525 & 1526 be moved inside the synchronized block?
>
> I think so, at least this will unify how we use these in dispatch 
> event and at the end of waitForIdle():
> http://cr.openjdk.java.net/~serb/8166673/webrev.01
>
>> On 9/26/2016 8:38 PM, Sergey Bylokhov wrote:
>>> Hello.
>>>
>>> Please review the fix for jdk9.
>>>
>>> The SunToolkit.waitForIdle() uses string literal for synchronization,
>>> which means some code (intentionally or not) can hang 
>>> Robot.waitForIdle.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166673
>>> Webrev can be found at:
>>> http://cr.openjdk.java.net/~serb/8166673/webrev.00
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Tue Oct 11 13:40:57 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 11 Oct 2016 16:40:57 +0300
Subject: <AWT Dev> [9] Review request for 8167486:
 Device.getDisplayMode() doesn't report refresh rate on Linux in case of
 dual screen
In-Reply-To: <d7ce05cf-6e35-bba9-317d-244fe0c11ba8@oracle.com>
References: <d7ce05cf-6e35-bba9-317d-244fe0c11ba8@oracle.com>
Message-ID: <1be97cef-7445-c9db-861f-1381599bfbf3@oracle.com>

Should toString() method report zero HZ as unknown(os something like 
that) instead of 0? And probably "DEPTH_MULTI"also should be printed in 
some way, instead of empty line.

On 11.10.16 16:15, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8167486
>
> webrev: http://cr.openjdk.java.net/~ssadetsky/8167486/webrev.00/
>
> In  case Xinerama is on, the current display mode cannot be obtained by
> the old xrandr lib calls for secondary screens. The new xrandr API that
> supports Xinerama is used for this case in the proposed solution.
>
> --Semyon
>


-- 
Best regards, Sergey.

From alexander.zvegintsev at oracle.com  Tue Oct 11 14:00:22 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 11 Oct 2016 17:00:22 +0300
Subject: <AWT Dev> [9] Review request for 8143914: Provide Mac-specific
 fullscreen support
In-Reply-To: <106cd9a6-8946-f34c-4647-17a7ab053b65@oracle.com>
References: <70a8e894-93be-23d5-a296-2f674053ee1a@oracle.com>
	<106cd9a6-8946-f34c-4647-17a7ab053b65@oracle.com>
Message-ID: <8765afc5-cf78-537e-bf80-9bf262ea4774@oracle.com>

Hi Sergey,

Please see the updated webrev:

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

As I can observe other windows  such as native dialogs doesn't have 
fullscreen button.


On 10/2/16 5:52 PM, Sergey Bylokhov wrote:
> Hi, Alexander.
> In the fix you use eawt events which are generated by the same peer. 
> Why not use windowWill/DidEnterFullScreen + windowWill/DidExitFullScreen?
> Why the fix is for the Frames only, there are some limitations for 
> other windows, dialogs etc?
>
> On 06.09.16 17:32, Alexander Zvegintsev wrote:
>> Hello,
>>
>> please review the fix
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8143914/00/
>>
>> for the issue
>>
>> https://bugs.openjdk.java.net/browse/JDK-8143914
>>
>>
>> This fix adds the green FullScreen button to a resizable frames by 
>> default.
>>
>> Previous maximize behavior is still accessible by holding Alt while
>> clicking on the green button.
>>
>> setResizable is fixed because of two reasons:
>>
>> Window will not be able to leave fullscreen if we remove resizable from
>> style bits(and even if we set it again)
>>
>> Window will not have the green button(maximize/zoom or fullscreen) if
>> the window was initially not resizable.
>>
>>
>
>

-- 
Thanks,
Alexander.


From alexander.zvegintsev at oracle.com  Tue Oct 11 14:01:39 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 11 Oct 2016 17:01:39 +0300
Subject: <AWT Dev> [9] Review request for 8143914: Provide Mac-specific
 fullscreen support
In-Reply-To: <d873d834-2d46-9d1e-02f1-c01aeac3b100@oracle.com>
References: <70a8e894-93be-23d5-a296-2f674053ee1a@oracle.com>
	<d873d834-2d46-9d1e-02f1-c01aeac3b100@oracle.com>
Message-ID: <b9c24e62-37e5-2e10-9cf7-51460f837f75@oracle.com>

Actually I can't reproduce such behavior.


On 9/30/16 5:12 PM, Semyon Sadetsky wrote:
> The fix looks good.
>
> Do you know why JDialog maximize button doesn't work? When I click on 
> it the maximize button the dialog disappears.
>
> --Semyon
>
>
> On 9/6/2016 5:32 PM, Alexander Zvegintsev wrote:
>> Hello,
>>
>> please review the fix
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8143914/00/
>>
>> for the issue
>>
>> https://bugs.openjdk.java.net/browse/JDK-8143914
>>
>>
>> This fix adds the green FullScreen button to a resizable frames by 
>> default.
>>
>> Previous maximize behavior is still accessible by holding Alt while 
>> clicking on the green button.
>>
>> setResizable is fixed because of two reasons:
>>
>> Window will not be able to leave fullscreen if we remove resizable 
>> from style bits(and even if we set it again)
>>
>> Window will not have the green button(maximize/zoom or fullscreen) if 
>> the window was initially not resizable.
>>
>>
>

-- 
Thanks,
Alexander.


From Sergey.Bylokhov at oracle.com  Tue Oct 11 14:02:00 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 11 Oct 2016 17:02:00 +0300
Subject: <AWT Dev> [9] Review request for 8167486:
 Device.getDisplayMode() doesn't report refresh rate on Linux in case of
 dual screen
In-Reply-To: <1be97cef-7445-c9db-861f-1381599bfbf3@oracle.com>
References: <d7ce05cf-6e35-bba9-317d-244fe0c11ba8@oracle.com>
	<1be97cef-7445-c9db-861f-1381599bfbf3@oracle.com>
Message-ID: <f00d7929-4904-0a5f-3be7-1bd2570d8766@oracle.com>

It seems that this bug is a duplicate of JDK-8159953?

On 11.10.16 16:40, Sergey Bylokhov wrote:
> Should toString() method report zero HZ as unknown(os something like
> that) instead of 0? And probably "DEPTH_MULTI"also should be printed in
> some way, instead of empty line.
>
> On 11.10.16 16:15, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8167486
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8167486/webrev.00/
>>
>> In  case Xinerama is on, the current display mode cannot be obtained by
>> the old xrandr lib calls for secondary screens. The new xrandr API that
>> supports Xinerama is used for this case in the proposed solution.
>>
>> --Semyon
>>
>
>


-- 
Best regards, Sergey.

From yuri.nesterenko at oracle.com  Tue Oct 11 14:42:35 2016
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Tue, 11 Oct 2016 17:42:35 +0300
Subject: <AWT Dev> [9] Review request for 8143914: Provide Mac-specific
 fullscreen support
In-Reply-To: <b9c24e62-37e5-2e10-9cf7-51460f837f75@oracle.com>
References: <70a8e894-93be-23d5-a296-2f674053ee1a@oracle.com>
	<d873d834-2d46-9d1e-02f1-c01aeac3b100@oracle.com>
	<b9c24e62-37e5-2e10-9cf7-51460f837f75@oracle.com>
Message-ID: <c6ccb7f1-2668-cfaa-5f44-3435fb926511@oracle.com>

Try to open JFileChooser dialog in SwingSet2 (before the fix) and
click + to maximize it (I tried on 10.10 and 10.12): application is
blocked by a modal dialog, and there's no way to see it.

-yan

On 10/11/2016 05:01 PM, Alexander Zvegintsev wrote:
> Actually I can't reproduce such behavior.
>
>
> On 9/30/16 5:12 PM, Semyon Sadetsky wrote:
>> The fix looks good.
>>
>> Do you know why JDialog maximize button doesn't work? When I click on
>> it the maximize button the dialog disappears.
>>
>> --Semyon
>>
>>
>> On 9/6/2016 5:32 PM, Alexander Zvegintsev wrote:
>>> Hello,
>>>
>>> please review the fix
>>>
>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8143914/00/
>>>
>>> for the issue
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8143914
>>>
>>>
>>> This fix adds the green FullScreen button to a resizable frames by
>>> default.
>>>
>>> Previous maximize behavior is still accessible by holding Alt while
>>> clicking on the green button.
>>>
>>> setResizable is fixed because of two reasons:
>>>
>>> Window will not be able to leave fullscreen if we remove resizable
>>> from style bits(and even if we set it again)
>>>
>>> Window will not have the green button(maximize/zoom or fullscreen) if
>>> the window was initially not resizable.
>>>
>>>
>>
>


From alexander.zvegintsev at oracle.com  Tue Oct 11 16:27:11 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 11 Oct 2016 19:27:11 +0300
Subject: <AWT Dev> [9] Review request for 8143914: Provide Mac-specific
 fullscreen support
In-Reply-To: <c6ccb7f1-2668-cfaa-5f44-3435fb926511@oracle.com>
References: <70a8e894-93be-23d5-a296-2f674053ee1a@oracle.com>
	<d873d834-2d46-9d1e-02f1-c01aeac3b100@oracle.com>
	<b9c24e62-37e5-2e10-9cf7-51460f837f75@oracle.com>
	<c6ccb7f1-2668-cfaa-5f44-3435fb926511@oracle.com>
Message-ID: <58cb7101-62cd-d909-8b55-f16119076c28@oracle.com>

Now I see, it's an unrelated issue. Is there any filed bug for this issue?

I had similar one with JavaFX 
https://bugs.openjdk.java.net/browse/JDK-8160241


On 10/11/16 5:42 PM, Yuri Nesterenko wrote:
> Try to open JFileChooser dialog in SwingSet2 (before the fix) and
> click + to maximize it (I tried on 10.10 and 10.12): application is
> blocked by a modal dialog, and there's no way to see it.
>
> -yan
>
> On 10/11/2016 05:01 PM, Alexander Zvegintsev wrote:
>> Actually I can't reproduce such behavior.
>>
>>
>> On 9/30/16 5:12 PM, Semyon Sadetsky wrote:
>>> The fix looks good.
>>>
>>> Do you know why JDialog maximize button doesn't work? When I click on
>>> it the maximize button the dialog disappears.
>>>
>>> --Semyon
>>>
>>>
>>> On 9/6/2016 5:32 PM, Alexander Zvegintsev wrote:
>>>> Hello,
>>>>
>>>> please review the fix
>>>>
>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8143914/00/
>>>>
>>>> for the issue
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8143914
>>>>
>>>>
>>>> This fix adds the green FullScreen button to a resizable frames by
>>>> default.
>>>>
>>>> Previous maximize behavior is still accessible by holding Alt while
>>>> clicking on the green button.
>>>>
>>>> setResizable is fixed because of two reasons:
>>>>
>>>> Window will not be able to leave fullscreen if we remove resizable
>>>> from style bits(and even if we set it again)
>>>>
>>>> Window will not have the green button(maximize/zoom or fullscreen) if
>>>> the window was initially not resizable.
>>>>
>>>>
>>>
>>
>

-- 
Thanks,
Alexander.


From philip.race at oracle.com  Tue Oct 11 21:23:26 2016
From: philip.race at oracle.com (Philip Race)
Date: Tue, 11 Oct 2016 14:23:26 -0700
Subject: <AWT Dev> RFR: 8167523: JDK 9 build failure on MacOS due to
 unhandled cases in switch statement
Message-ID: <57FD584E.7070000@oracle.com>

The fix for 8166591: [macos 10.12] Trackpad scrolling of text on OS X 
10.12 Sierra is very fast (Trackpad, Retina only) added a switch 
statement with unhandled cases.
On later versions of the clang compiler this causes a build failure due 
to a warning

/jdk9-client/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m:92:13: 
error: 4 enumeration values not handled in switch: 'NSEventPhaseNone', 
'NSEventPhaseStationary', 'NSEventPhaseChanged'... [-Werror,-Wswitch]
     switch (phase) {
             ^
1 error generated.

Simple fix in-line below that builds with xcode 6.3 and xcode 7 :-
diff --git 
a/src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m 
b/src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m
--- a/src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m
+++ b/src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m
@@ -93,8 +93,8 @@
          case NSEventPhaseBegan: return SCROLL_PHASE_BEGAN;
          case NSEventPhaseCancelled: return SCROLL_PHASE_CANCELLED;
          case NSEventPhaseEnded: return SCROLL_PHASE_ENDED;
+ default: return SCROLL_PHASE_CONTINUED;
      }
- return SCROLL_PHASE_CONTINUED;
  }


-phil.

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

From Sergey.Bylokhov at oracle.com  Tue Oct 11 22:48:54 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 12 Oct 2016 01:48:54 +0300
Subject: <AWT Dev> RFR: 8167523: JDK 9 build failure on MacOS due to
 unhandled cases in switch statement
In-Reply-To: <57FD584E.7070000@oracle.com>
References: <57FD584E.7070000@oracle.com>
Message-ID: <43decc75-929d-90a8-8d2f-e722fb2ce9a7@oracle.com>

Looks fine.

On 12.10.16 0:23, Philip Race wrote:
> The fix for 8166591: [macos 10.12] Trackpad scrolling of text on OS X
> 10.12 Sierra is very fast (Trackpad, Retina only) added a switch
> statement with unhandled cases.
> On later versions of the clang compiler this causes a build failure due
> to a warning
>
> /jdk9-client/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m:92:13:
> error: 4 enumeration values not handled in switch: 'NSEventPhaseNone',
> 'NSEventPhaseStationary', 'NSEventPhaseChanged'... [-Werror,-Wswitch]
>     switch (phase) {
>             ^
> 1 error generated.
>
> Simple fix in-line below that builds with xcode 6.3 and xcode 7 :-
> diff --git
> a/src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m
> b/src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m
> --- a/src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m
> +++ b/src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m
> @@ -93,8 +93,8 @@
>          case NSEventPhaseBegan: return SCROLL_PHASE_BEGAN;
>          case NSEventPhaseCancelled: return SCROLL_PHASE_CANCELLED;
>          case NSEventPhaseEnded: return SCROLL_PHASE_ENDED;
> + default: return SCROLL_PHASE_CONTINUED;
>      }
> - return SCROLL_PHASE_CONTINUED;
>  }
>
>
> -phil.
>
> -


-- 
Best regards, Sergey.

From ambarish.rapte at oracle.com  Wed Oct 12 06:04:20 2016
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Tue, 11 Oct 2016 23:04:20 -0700 (PDT)
Subject: <AWT Dev> <AWT dev>[9] Review request for
 JDK-8161473:[TEST_BUG] [macosx] add autodelay to
 java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java
In-Reply-To: <27223022-A599-47EE-8ED8-C3BFE962451F@oracle.com>
References: <334B090B-6409-4467-AD8D-AF0EAD1935F7@oracle.com>
	<147d64e5-38c1-4424-bed7-774d38c9e6e3@default>
	<27223022-A599-47EE-8ED8-C3BFE962451F@oracle.com>
Message-ID: <65dbffd8-a039-4d79-8bb8-9101b555f64c@default>

Thanks Anubhav,

                Changes look fine to me.

 

Regards,

Ambarish

 

From: Anubhav Meena 
Sent: Monday, October 10, 2016 5:06 PM
To: Ambarish Rapte
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> <AWT dev>[9] Review request for JDK-8161473:[TEST_BUG] [macosx] add autodelay to java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java

 

Hi Ambarish,

 

Have made the changes you suggested. Please find them here http://cr.openjdk.java.net/~rchamyal/anmeena/8161473/webrev.01/

 

Thanks,

Anubhav

 

On Oct 10, 2016, at 2:01 PM, Ambarish Rapte <HYPERLINK "mailto:ambarish.rapte at oracle.com"ambarish.rapte at oracle.com> wrote:

 

Hi Anubhav,

 

                Along with the fix, could you please add below trivial changes as well,

 

1.       Add @key headful & @bug 8161473  jtreg tags

2.       Change wild card * import to add specific package imports.

3.       Update copyright with year 2016.

 

 

Regards,

Ambarish

 

From: Anubhav Meena 
Sent: Friday, October 07, 2016 6:46 PM
To: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8161473:[TEST_BUG] [macosx] add autodelay to java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java

 

Hi All,

 

Kindly review the fix for JDK9.

 

Bug: 

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

 

Webrev: 

http://cr.openjdk.java.net/~rchamyal/anmeena/8161473/webrev.00/

 

Issue: 

[macosx] The test java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java often fails, especially on OS X.

 

Cause: 

Lack of minimal delay between elementary robot operations

 

Fix: 

Added wait for idle operation between two robot events.

 

Regards,

Anubhav

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

From ajit.ghaisas at oracle.com  Wed Oct 12 07:10:58 2016
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Wed, 12 Oct 2016 00:10:58 -0700 (PDT)
Subject: <AWT Dev> [9] Fix for JDK-8166980 : JCK testing of
 Window.setIconImage() leads to VM crash starting approx from JDK9 b134
Message-ID: <8d22c5f0-e4e0-4326-9746-d607342fe274@default>

Hi,

 

Bug :

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

 

Issue and Fix :    

     Fix for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8147648"JDK-8147648 needs to be corrected a little.

     IconInfo::setScaledSize(int width, int height) method sets scaledWidth, scaledHeight and rawLength members of IconInfo class.

     In this method rawLength calculation does not consider passed in width and height - rather it uses class members to calculate the rawLength. This is incorrect.

    The rawLength calculation is corrected as part of this fix.

 

Webrev : 

     http://cr.openjdk.java.net/~aghaisas/8166980/webrev.0/

 

    Request you to review.

 

Regards,

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

From semyon.sadetsky at oracle.com  Wed Oct 12 07:27:51 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 12 Oct 2016 10:27:51 +0300
Subject: <AWT Dev> [9] Review request for 8167486:
 Device.getDisplayMode() doesn't report refresh rate on Linux in case of
 dual screen
In-Reply-To: <f00d7929-4904-0a5f-3be7-1bd2570d8766@oracle.com>
References: <d7ce05cf-6e35-bba9-317d-244fe0c11ba8@oracle.com>
	<1be97cef-7445-c9db-861f-1381599bfbf3@oracle.com>
	<f00d7929-4904-0a5f-3be7-1bd2570d8766@oracle.com>
Message-ID: <e4b33a27-d5e2-63b0-a4b9-ec3f4caa9e30@oracle.com>

On 10/11/2016 5:02 PM, Sergey Bylokhov wrote:

> It seems that this bug is a duplicate of JDK-8159953?
yes, I have closed it.
>
> On 11.10.16 16:40, Sergey Bylokhov wrote:
>> Should toString() method report zero HZ as unknown(os something like
>> that) instead of 0? And probably "DEPTH_MULTI"also should be printed in
>> some way, instead of empty line.
http://cr.openjdk.java.net/~ssadetsky/8167486/webrev.01/
>>
>> On 11.10.16 16:15, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8167486
>>>
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8167486/webrev.00/
>>>
>>> In  case Xinerama is on, the current display mode cannot be obtained by
>>> the old xrandr lib calls for secondary screens. The new xrandr API that
>>> supports Xinerama is used for this case in the proposed solution.
>>>
>>> --Semyon
>>>
>>
>>
>
>


From malenkov at gmail.com  Wed Oct 12 10:32:43 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Wed, 12 Oct 2016 13:32:43 +0300
Subject: <AWT Dev> RFR: 8167523: JDK 9 build failure on MacOS due to
 unhandled cases in switch statement
In-Reply-To: <43decc75-929d-90a8-8d2f-e722fb2ce9a7@oracle.com>
References: <57FD584E.7070000@oracle.com>
	<43decc75-929d-90a8-8d2f-e722fb2ce9a7@oracle.com>
Message-ID: <CANTFZ2hr2oP415aFvDug7KwApG+hmkqX53XGQ7-_5wN0VtpL2g@mail.gmail.com>

> Looks fine.
+1

Thanks!
Sergey A. Malenkov

From manajit.halder at oracle.com  Wed Oct 12 11:40:21 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Wed, 12 Oct 2016 17:10:21 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8158380:
	Regression: java/awt/List/ActionEventTest/ActionEventTest.java
In-Reply-To: <e20b06a0-d95a-8fc0-e175-37109a0486fe@oracle.com>
References: <4367BB1F-6B9C-43E0-A6A9-0A85A101184D@oracle.com>
	<4ae465d2-9987-4d48-00d0-603074ff0bf9@oracle.com>
	<F8C42F8C-1632-40C1-AC05-9F66D4F55584@oracle.com>
	<e20b06a0-d95a-8fc0-e175-37109a0486fe@oracle.com>
Message-ID: <A783D4B7-76EE-41E1-93D6-DAFD79E75D46@oracle.com>

Thanks you for your comment. Copyright is corrected in both the tests. 
Please review the modified webrev.

http://cr.openjdk.java.net/~mhalder/8158380/webrev.02/ <http://cr.openjdk.java.net/~mhalder/8158380/webrev.02/>

Thanks,
Manajit

> On 10-Oct-2016, at 5:58 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> It seems that "Copyright (c)" is incorrectly updated in both tests.
> 
> On 10.10.16 14:41, Manajit Halder wrote:
>> Hi Sergey,
>> 
>> Thank you for the review. Please review the modified webrev.
>> http://cr.openjdk.java.net/~mhalder/8158380/webrev.01/
>> 
>> Thanks,
>> Manajit
>> 
>>> On 07-Oct-2016, at 7:41 pm, Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>> 
>>> Hi, Manajit.
>>> Instead of adding these methods between operations you can call these
>>> after robot creation:
>>>   Robot.setAutoDelay(int ms)
>>>   Robot.setAutoWaitForIdle(boolean isOn)
>>> 
>>> On 07.10.16 15:10, Manajit Halder wrote:
>>>> Hi All,
>>>> 
>>>> Kindly review the fix for JDK9.
>>>> 
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8158380
>>>> 
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mhalder/8158380/webrev.00/
>>>> 
>>>> Issue:
>>>> Regression: java/awt/List/ActionEventTest/ActionEventTest.java
>>>> 
>>>> Cause:
>>>> ActionEvent getModifiers() method was returning wrong value in test
>>>> ActionEventTest.java due to wrong modifier value.
>>>> Submenu was not activated by menmonic key press in SubMenuShowTest.java.
>>>> In both the cases event queue was not processed completely for robot
>>>> keyPress and keyRelease events.
>>>> 
>>>> Fix:
>>>> In both the cases problem was solved by adding waitForIdle after robot
>>>> operations (keyPress and keyRelease).
>>>> 
>>>> Regards,
>>>> Manajit
>>> 
>>> 
>>> --
>>> Best regards, Sergey.
>> 
> 
> 
> -- 
> Best regards, Sergey.

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

From anubhav.meena at oracle.com  Wed Oct 12 12:34:47 2016
From: anubhav.meena at oracle.com (Anubhav Meena)
Date: Wed, 12 Oct 2016 18:04:47 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for
	JDK-8161473:[TEST_BUG] [macosx] add autodelay to
	java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java
In-Reply-To: <65dbffd8-a039-4d79-8bb8-9101b555f64c@default>
References: <334B090B-6409-4467-AD8D-AF0EAD1935F7@oracle.com>
	<147d64e5-38c1-4424-bed7-774d38c9e6e3@default>
	<27223022-A599-47EE-8ED8-C3BFE962451F@oracle.com>
	<65dbffd8-a039-4d79-8bb8-9101b555f64c@default>
Message-ID: <78E3AF4F-410E-4A29-A56A-61F5C290C5F5@oracle.com>

Hi Sergey,

Please review the webrev and provide your valuable feedback.

http://cr.openjdk.java.net/~rchamyal/anmeena/8161473/webrev.01/ <http://cr.openjdk.java.net/~rchamyal/anmeena/8161473/webrev.01/>

Thanks,
Anubhav

> On Oct 12, 2016, at 11:34 AM, Ambarish Rapte <ambarish.rapte at oracle.com> wrote:
> 
> Thanks Anubhav,
>                 Changes look fine to me.
>  
> Regards,
> Ambarish
>  
> From: Anubhav Meena 
> Sent: Monday, October 10, 2016 5:06 PM
> To: Ambarish Rapte
> Cc: awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> <AWT dev>[9] Review request for JDK-8161473:[TEST_BUG] [macosx] add autodelay to java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java
>  
> Hi Ambarish,
>  
> Have made the changes you suggested. Please find them here http://cr.openjdk.java.net/~rchamyal/anmeena/8161473/webrev.01/ <http://cr.openjdk.java.net/~rchamyal/anmeena/8161473/webrev.01/>
>  
> Thanks,
> Anubhav
>  
> On Oct 10, 2016, at 2:01 PM, Ambarish Rapte <ambarish.rapte at oracle.com <mailto:ambarish.rapte at oracle.com>> wrote:
>  
> Hi Anubhav,
>  
>                 Along with the fix, could you please add below trivial changes as well,
>  
> 1.       Add @key headful & @bug 8161473  jtreg tags
> 2.       Change wild card * import to add specific package imports.
> 3.       Update copyright with year 2016.
>  
>  
> Regards,
> Ambarish
>  
> From: Anubhav Meena 
> Sent: Friday, October 07, 2016 6:46 PM
> To: awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
> Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8161473:[TEST_BUG] [macosx] add autodelay to java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java
>  
> Hi All,
>  
> Kindly review the fix for JDK9.
>  
> Bug: 
> https://bugs.openjdk.java.net/browse/JDK-8161473 <https://bugs.openjdk.java.net/browse/JDK-8161473>
>  
> Webrev: 
> http://cr.openjdk.java.net/~rchamyal/anmeena/8161473/webrev.00/ <http://cr.openjdk.java.net/~rchamyal/anmeena/8161473/webrev.00/>
>  
> Issue: 
> [macosx] The test java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java often fails, especially on OS X.
>  
> Cause: 
> Lack of minimal delay between elementary robot operations
>  
> Fix: 
> Added wait for idle operation between two robot events.
>  
> Regards,
> Anubhav

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

From Sergey.Bylokhov at oracle.com  Wed Oct 12 14:41:15 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 12 Oct 2016 17:41:15 +0300
Subject: <AWT Dev> [9] Fix for JDK-8166980 : JCK testing of
 Window.setIconImage() leads to VM crash starting approx from JDK9 b134
In-Reply-To: <8d22c5f0-e4e0-4326-9746-d607342fe274@default>
References: <8d22c5f0-e4e0-4326-9746-d607342fe274@default>
Message-ID: <ee3e8205-b92c-4d29-8ec0-f729a0335442@oracle.com>

Looks fine.

On 12.10.16 10:10, Ajit Ghaisas wrote:
> Hi,
>
>
>
> Bug :
>
>      https://bugs.openjdk.java.net/browse/JDK-8166980
>
>
>
> Issue and Fix :
>
>      Fix for JDK-8147648
> <https://bugs.openjdk.java.net/browse/JDK-8147648> needs to be corrected
> a little.
>
>      IconInfo::setScaledSize(int width, int height) method sets
> scaledWidth, scaledHeight and rawLength members of IconInfo class.
>
>      In this method rawLength calculation does not consider passed in
> width and height ? rather it uses class members to calculate the
> rawLength. This is incorrect.
>
>     The rawLength calculation is corrected as part of this fix.
>
>
>
> Webrev :
>
>      http://cr.openjdk.java.net/~aghaisas/8166980/webrev.0/
>
>
>
>     Request you to review.
>
>
>
> Regards,
>
> Ajit
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Oct 12 14:42:10 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 12 Oct 2016 17:42:10 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8158380:
 Regression: java/awt/List/ActionEventTest/ActionEventTest.java
In-Reply-To: <A783D4B7-76EE-41E1-93D6-DAFD79E75D46@oracle.com>
References: <4367BB1F-6B9C-43E0-A6A9-0A85A101184D@oracle.com>
	<4ae465d2-9987-4d48-00d0-603074ff0bf9@oracle.com>
	<F8C42F8C-1632-40C1-AC05-9F66D4F55584@oracle.com>
	<e20b06a0-d95a-8fc0-e175-37109a0486fe@oracle.com>
	<A783D4B7-76EE-41E1-93D6-DAFD79E75D46@oracle.com>
Message-ID: <7985d942-59cf-aa98-aa0c-9390f4bb827d@oracle.com>

Looks fine.

On 12.10.16 14:40, Manajit Halder wrote:
> Thanks you for your comment. Copyright is corrected in both the tests.
> Please review the modified webrev.
>
> http://cr.openjdk.java.net/~mhalder/8158380/webrev.02/
>
> Thanks,
> Manajit
>
>> On 10-Oct-2016, at 5:58 pm, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> It seems that "Copyright (c)" is incorrectly updated in both tests.
>>
>> On 10.10.16 14:41, Manajit Halder wrote:
>>> Hi Sergey,
>>>
>>> Thank you for the review. Please review the modified webrev.
>>> http://cr.openjdk.java.net/~mhalder/8158380/webrev.01/
>>>
>>> Thanks,
>>> Manajit
>>>
>>>> On 07-Oct-2016, at 7:41 pm, Sergey Bylokhov
>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>
>>>> Hi, Manajit.
>>>> Instead of adding these methods between operations you can call these
>>>> after robot creation:
>>>>   Robot.setAutoDelay(int ms)
>>>>   Robot.setAutoWaitForIdle(boolean isOn)
>>>>
>>>> On 07.10.16 15:10, Manajit Halder wrote:
>>>>> Hi All,
>>>>>
>>>>> Kindly review the fix for JDK9.
>>>>>
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8158380
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mhalder/8158380/webrev.00/
>>>>>
>>>>> Issue:
>>>>> Regression: java/awt/List/ActionEventTest/ActionEventTest.java
>>>>>
>>>>> Cause:
>>>>> ActionEvent getModifiers() method was returning wrong value in test
>>>>> ActionEventTest.java due to wrong modifier value.
>>>>> Submenu was not activated by menmonic key press in
>>>>> SubMenuShowTest.java.
>>>>> In both the cases event queue was not processed completely for robot
>>>>> keyPress and keyRelease events.
>>>>>
>>>>> Fix:
>>>>> In both the cases problem was solved by adding waitForIdle after robot
>>>>> operations (keyPress and keyRelease).
>>>>>
>>>>> Regards,
>>>>> Manajit
>>>>
>>>>
>>>> --
>>>> Best regards, Sergey.
>>>
>>
>>
>> --
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Oct 12 15:44:03 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 12 Oct 2016 18:44:03 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for
 JDK-8161473:[TEST_BUG] [macosx] add autodelay to
 java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java
In-Reply-To: <65dbffd8-a039-4d79-8bb8-9101b555f64c@default>
References: <334B090B-6409-4467-AD8D-AF0EAD1935F7@oracle.com>
	<147d64e5-38c1-4424-bed7-774d38c9e6e3@default>
	<27223022-A599-47EE-8ED8-C3BFE962451F@oracle.com>
	<65dbffd8-a039-4d79-8bb8-9101b555f64c@default>
Message-ID: <ed5fb84d-2132-c841-7b86-288454535079@oracle.com>

On 12.10.16 9:04, Ambarish Rapte wrote:
> Thanks Anubhav,
>                 Changes look fine to me.

+1

> *From:*Anubhav Meena
> *Sent:* Monday, October 10, 2016 5:06 PM
> *To:* Ambarish Rapte
> *Cc:* awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> <AWT dev>[9] Review request for
> JDK-8161473:[TEST_BUG] [macosx] add autodelay to
> java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java
>
>
>
> Hi Ambarish,
>
>
>
> Have made the changes you suggested. Please find them
> here http://cr.openjdk.java.net/~rchamyal/anmeena/8161473/webrev.01/
>
>
>
> Thanks,
>
> Anubhav
>
>
>
>     On Oct 10, 2016, at 2:01 PM, Ambarish Rapte
>     <ambarish.rapte at oracle.com <mailto:ambarish.rapte at oracle.com>> wrote:
>
>
>
>     Hi Anubhav,
>
>
>
>                     Along with the fix, could you please add below
>     trivial changes as well,
>
>
>
>     1.       Add @key headful & @bug 8161473  jtreg tags
>
>     2.       Change wild card * import to add specific package imports.
>
>     3.       Update copyright with year 2016.
>
>
>
>
>
>     Regards,
>
>     Ambarish
>
>
>
>     *From:* Anubhav Meena
>     *Sent:* Friday, October 07, 2016 6:46 PM
>     *To:* awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>     *Subject:* <AWT Dev> <AWT dev>[9] Review request for
>     JDK-8161473:[TEST_BUG] [macosx] add autodelay to
>     java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java
>
>
>
>     Hi All,
>
>
>
>     Kindly review the fix for JDK9.
>
>
>
>     Bug:
>
>     _https://bugs.openjdk.java.net/browse/JDK-8161473_
>
>
>
>     Webrev:
>
>     _http://cr.openjdk.java.net/~rchamyal/anmeena/8161473/webrev.00/_
>
>
>
>     Issue:
>
>     [macosx] The test
>     java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java
>     often fails, especially on OS X.
>
>
>
>     Cause:
>
>     Lack of minimal delay between elementary robot operations
>
>
>
>     Fix:
>
>     Added wait for idle operation between two robot events.
>
>
>
>     Regards,
>
>     Anubhav
>
>
>


-- 
Best regards, Sergey.

From sergey.malenkov at jetbrains.com  Wed Oct 12 16:07:54 2016
From: sergey.malenkov at jetbrains.com (Sergey Malenkov)
Date: Wed, 12 Oct 2016 19:07:54 +0300
Subject: <AWT Dev> JDK-8098530: ArrayIndexOutOfBoundsException at
	sun.awt.X11.XEvent.getFieldsAsString
Message-ID: <CAFL4mEFyhkMUQyVnwAyMXHwcTx0JpbyyBa0AfzpWfwFzjtNZEA@mail.gmail.com>

Hi all,

Could you please consider the following changes to fix JDK-8098530?

--- src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java
(revision f0ae41314e223bf1b97c8126ac2b0d6edb5ee99d)
+++ src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java
(revision )
@@ -690,7 +690,7 @@
                 if (type == AtomicType.TYPE_ATOM) {
                     pw.println("\t\tret.append(\"" + name + " = \"
).append( XAtom.get(get_" + name + "()) ).append(\", \");");
                 } else if (name.equals("type")) {
-                    pw.println("\t\tret.append(\"type = \").append(
XlibWrapper.eventToString[get_type()] ).append(\", \");");
+                    pw.println("\t\tret.append(\"type = \").append(
XlibWrapper.getEventToString(get_type()) ).append(\", \");");
                 } else if (name.equals("window")){
                     pw.println("\t\tret.append(\"window = \" ).append(
getWindow(get_window()) ).append(\", \");");
                 } else if (type == AtomicType.TYPE_ARRAY) {

The sun.awt.X11.XlibWrapper class provides a method, which handles such
errors.
We should not access to array directly.

-- 
Best regards,
Sergey A. Malenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161012/9ef3381a/attachment.html>

From Sergey.Bylokhov at oracle.com  Wed Oct 12 17:48:18 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 12 Oct 2016 20:48:18 +0300
Subject: <AWT Dev> JDK-8098530: ArrayIndexOutOfBoundsException at
 sun.awt.X11.XEvent.getFieldsAsString
In-Reply-To: <CAFL4mEFyhkMUQyVnwAyMXHwcTx0JpbyyBa0AfzpWfwFzjtNZEA@mail.gmail.com>
References: <CAFL4mEFyhkMUQyVnwAyMXHwcTx0JpbyyBa0AfzpWfwFzjtNZEA@mail.gmail.com>
Message-ID: <3ef6895c-a04a-0b1f-b8d8-7158a089d860@oracle.com>

Is it possible to create a test for this issue?

On 12.10.16 19:07, Sergey Malenkov wrote:
> Hi all,
>
> Could you please consider the following changes to fix JDK-8098530?
>
> --- src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java
> (revision f0ae41314e223bf1b97c8126ac2b0d6edb5ee99d)
> +++ src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java
> (revision )
> @@ -690,7 +690,7 @@
>                  if (type == AtomicType.TYPE_ATOM) {
>                      pw.println("\t\tret.append(\"" + name + " = \"
> ).append( XAtom.get(get_" + name + "()) ).append(\", \");");
>                  } else if (name.equals("type")) {
> -                    pw.println("\t\tret.append(\"type = \").append(
> XlibWrapper.eventToString[get_type()] ).append(\", \");");
> +                    pw.println("\t\tret.append(\"type = \").append(
> XlibWrapper.getEventToString(get_type()) ).append(\", \");");
>                  } else if (name.equals("window")){
>                      pw.println("\t\tret.append(\"window = \" ).append(
> getWindow(get_window()) ).append(\", \");");
>                  } else if (type == AtomicType.TYPE_ARRAY) {
>
> The sun.awt.X11.XlibWrapper class provides a method, which handles such
> errors.
> We should not access to array directly.
>
> --
> Best regards,
> Sergey A. Malenkov


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Wed Oct 12 21:12:23 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 13 Oct 2016 00:12:23 +0300
Subject: <AWT Dev> [9] Review request for 8166897: Some font overlap in the
 Optionpane dialog.
Message-ID: <4cfe1fe3-9887-199a-96e2-e676b16afef6@oracle.com>

Hello,

Please review fix for JDK9:

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

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

The setResizable() method of XDecoratedPeer class clears the frame 
insets to allow them to receive the updated size. In some situations 
clearing insets during establishing the frame dimensions may break the 
new frame dimensions algorithm for Unity and the frame content 
positioning becomes wrong.

Since in this new algorithm the insets may be arbitrary updated by WM it 
doesn't necessary to clear insets to get them the new size.  The 
proposed solution is to avoid to force frame insets to zero when the 
frame is made resizable or non-resizable by user.

--Semyon


From ajit.ghaisas at oracle.com  Thu Oct 13 08:32:39 2016
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Thu, 13 Oct 2016 01:32:39 -0700 (PDT)
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8158380:
 Regression: java/awt/List/ActionEventTest/ActionEventTest.java
In-Reply-To: <7985d942-59cf-aa98-aa0c-9390f4bb827d@oracle.com>
References: <4367BB1F-6B9C-43E0-A6A9-0A85A101184D@oracle.com>
	<4ae465d2-9987-4d48-00d0-603074ff0bf9@oracle.com>
	<F8C42F8C-1632-40C1-AC05-9F66D4F55584@oracle.com>
	<e20b06a0-d95a-8fc0-e175-37109a0486fe@oracle.com>
	<A783D4B7-76EE-41E1-93D6-DAFD79E75D46@oracle.com>
	<7985d942-59cf-aa98-aa0c-9390f4bb827d@oracle.com>
Message-ID: <93e91999-e3ad-445a-a03e-e10da390f7a1@default>

The fix looks good.

Regards,
Ajit

-----Original Message-----
From: Sergey Bylokhov 
Sent: Wednesday, October 12, 2016 8:12 PM
To: Manajit Halder
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> <AWT dev>[9] Review request for JDK-8158380: Regression: java/awt/List/ActionEventTest/ActionEventTest.java

Looks fine.

On 12.10.16 14:40, Manajit Halder wrote:
> Thanks you for your comment. Copyright is corrected in both the tests.
> Please review the modified webrev.
>
> http://cr.openjdk.java.net/~mhalder/8158380/webrev.02/
>
> Thanks,
> Manajit
>
>> On 10-Oct-2016, at 5:58 pm, Sergey Bylokhov 
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> It seems that "Copyright (c)" is incorrectly updated in both tests.
>>
>> On 10.10.16 14:41, Manajit Halder wrote:
>>> Hi Sergey,
>>>
>>> Thank you for the review. Please review the modified webrev.
>>> http://cr.openjdk.java.net/~mhalder/8158380/webrev.01/
>>>
>>> Thanks,
>>> Manajit
>>>
>>>> On 07-Oct-2016, at 7:41 pm, Sergey Bylokhov 
>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>
>>>> Hi, Manajit.
>>>> Instead of adding these methods between operations you can call 
>>>> these after robot creation:
>>>>   Robot.setAutoDelay(int ms)
>>>>   Robot.setAutoWaitForIdle(boolean isOn)
>>>>
>>>> On 07.10.16 15:10, Manajit Halder wrote:
>>>>> Hi All,
>>>>>
>>>>> Kindly review the fix for JDK9.
>>>>>
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8158380
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mhalder/8158380/webrev.00/
>>>>>
>>>>> Issue:
>>>>> Regression: java/awt/List/ActionEventTest/ActionEventTest.java
>>>>>
>>>>> Cause:
>>>>> ActionEvent getModifiers() method was returning wrong value in 
>>>>> test ActionEventTest.java due to wrong modifier value.
>>>>> Submenu was not activated by menmonic key press in 
>>>>> SubMenuShowTest.java.
>>>>> In both the cases event queue was not processed completely for 
>>>>> robot keyPress and keyRelease events.
>>>>>
>>>>> Fix:
>>>>> In both the cases problem was solved by adding waitForIdle after 
>>>>> robot operations (keyPress and keyRelease).
>>>>>
>>>>> Regards,
>>>>> Manajit
>>>>
>>>>
>>>> --
>>>> Best regards, Sergey.
>>>
>>
>>
>> --
>> Best regards, Sergey.
>


--
Best regards, Sergey.

From alexandr.scherbatiy at oracle.com  Thu Oct 13 09:50:34 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 13 Oct 2016 13:50:34 +0400
Subject: <AWT Dev> Review Request JDK:-8162959 [HiDPI] screenshot
 artifacts using AWT Robot
In-Reply-To: <d9e5cffb-e2cb-41d8-8557-4aa994ae99c6@default>
References: <d9e5cffb-e2cb-41d8-8557-4aa994ae99c6@default>
Message-ID: <1cbc0e01-8da3-9c44-498b-f2725a9ded2d@oracle.com>

On 06/10/16 15:28, Prem Balakrishnan wrote:

> Hi*,*
>
> **
>
> Please review fix for JDK 9,
>
> *Bug:*https://bugs.openjdk.java.net/browse/JDK-8162959
>
> *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.00/ 
> <http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.00/>
>
> I have adapted the same fix as used for JavaFX Robot
>
> *Bug: *JDK-8162783 <https://bugs.openjdk.java.net/browse/JDK-8162783>.
>
> *Patch: *http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/89a5de54b7dc
>
> New Public API ? BufferedImage createScreenCapture(Rectangle 
> screenRect, boolean isHiDPI)?is added,
> Which will have a parameter to specify if HiDPI.
   It is better to a add public method which returns MultiResolution 
image on HiDPI display and  consists of two resoltion variants
    - base image which has size requested by a user
    - high-resolution image which creates an original screen capture

   The proposed by your algorithm can be applied to the base image.
   For more details see JDK-8020618 [macosx] java.awt.Robot makes blurry 
screen captures on Retina

   Thanks,
   Alexandr.
> Regards,
> Prem
>

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

From rajeev.chamyal at oracle.com  Thu Oct 13 09:56:10 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Thu, 13 Oct 2016 02:56:10 -0700 (PDT)
Subject: <AWT Dev> [9] Fix for JDK-8166980 : JCK testing of
 Window.setIconImage() leads to VM crash starting approx from JDK9 b134
In-Reply-To: <ee3e8205-b92c-4d29-8ec0-f729a0335442@oracle.com>
References: <8d22c5f0-e4e0-4326-9746-d607342fe274@default>
	<ee3e8205-b92c-4d29-8ec0-f729a0335442@oracle.com>
Message-ID: <9c4bc46e-4c79-4158-8337-d125dd27f33d@default>

Looks good to me.

Regards,
Rajeev Chamyal

-----Original Message-----
From: Sergey Bylokhov 
Sent: 12 October 2016 20:11
To: Ajit Ghaisas; Alexander Scherbatiy; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [9] Fix for JDK-8166980 : JCK testing of Window.setIconImage() leads to VM crash starting approx from JDK9 b134

Looks fine.

On 12.10.16 10:10, Ajit Ghaisas wrote:
> Hi,
>
>
>
> Bug :
>
>      https://bugs.openjdk.java.net/browse/JDK-8166980
>
>
>
> Issue and Fix :
>
>      Fix for JDK-8147648
> <https://bugs.openjdk.java.net/browse/JDK-8147648> needs to be 
> corrected a little.
>
>      IconInfo::setScaledSize(int width, int height) method sets 
> scaledWidth, scaledHeight and rawLength members of IconInfo class.
>
>      In this method rawLength calculation does not consider passed in 
> width and height - rather it uses class members to calculate the 
> rawLength. This is incorrect.
>
>     The rawLength calculation is corrected as part of this fix.
>
>
>
> Webrev :
>
>      http://cr.openjdk.java.net/~aghaisas/8166980/webrev.0/
>
>
>
>     Request you to review.
>
>
>
> Regards,
>
> Ajit
>


--
Best regards, Sergey.

From manajit.halder at oracle.com  Thu Oct 13 12:20:35 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Thu, 13 Oct 2016 17:50:35 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8158390: [macosx]
	Regression:
	javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java
Message-ID: <8D8375A9-60ED-4D99-97ED-7FE44D1B07BC@oracle.com>

Hi All,

Kindly review the fix for JDK9.

Bug: 
https://bugs.openjdk.java.net/browse/JDK-8158390 <https://bugs.openjdk.java.net/browse/JDK-8158390>

Webrev: 
http://cr.openjdk.java.net/~mhalder/8158390/webrev.00/ <http://cr.openjdk.java.net/~mhalder/8158390/webrev.00/>

Issue: 
[macosx] Regression: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java

Cause: 
Event queue was not processed completely for robot keyPress, keyRelease, mouseMove, mousePress and mouseRelease events.

Fix: 
Problem was solved by adding setAutoDelay and setAutoWaitForIdle(true) after robot creation.

Regards,
Manajit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161013/2c781cec/attachment.html>

From alexander.zvegintsev at oracle.com  Thu Oct 13 15:17:21 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 13 Oct 2016 18:17:21 +0300
Subject: <AWT Dev> [9] Review request for 8167565: [macosx] Maximization of
 a dialog hides it
Message-ID: <ea019b4d-9c0c-82a4-61fe-916e7e179ea4@oracle.com>

Hello,

please review the fix

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

for the issue

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

We trying to zoom to a zero size window(standardFrame has zero size). 
standardFrame initialization happens on setMaximizedBounds call.
Dialog doesn't initialize it(Frames has setMaximizedBounds() call in 
Frame.addNotify).
I prefer to fix it in the native level, if you have other thoughts 
please share it.

-- 
Thanks,
Alexander.


From semyon.sadetsky at oracle.com  Fri Oct 14 06:48:08 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 14 Oct 2016 09:48:08 +0300
Subject: <AWT Dev> [9] Review request for 8167565: [macosx] Maximization
 of a dialog hides it
In-Reply-To: <ea019b4d-9c0c-82a4-61fe-916e7e179ea4@oracle.com>
References: <ea019b4d-9c0c-82a4-61fe-916e7e179ea4@oracle.com>
Message-ID: <a60e7751-7089-4af8-f29b-4dfe68dc421c@oracle.com>

Looks good.

--Semyon


On 13.10.2016 18:17, Alexander Zvegintsev wrote:
> Hello,
>
> please review the fix
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8167565/00/
>
> for the issue
>
> https://bugs.openjdk.java.net/browse/JDK-8167565
>
> We trying to zoom to a zero size window(standardFrame has zero size). 
> standardFrame initialization happens on setMaximizedBounds call.
> Dialog doesn't initialize it(Frames has setMaximizedBounds() call in 
> Frame.addNotify).
> I prefer to fix it in the native level, if you have other thoughts 
> please share it.
>


From andrey.rusakov at oracle.com  Fri Oct 14 11:49:55 2016
From: andrey.rusakov at oracle.com (Andrey Rusakov)
Date: Fri, 14 Oct 2016 14:49:55 +0300
Subject: <AWT Dev> Review request for JDK-8165144,
	JDK-8167159 and JDK-8167155
Message-ID: <925757ed-c80d-011e-2d92-4ab2c6f2d5a5@oracle.com>

Hello, guys. Please have a look at my fixes for some test bugs:
https://bugs.openjdk.java.net/browse/JDK-8167155, 
https://bugs.openjdk.java.net/browse/JDK-8167159 and 
https://bugs.openjdk.java.net/browse/JDK-8167155

and upload them if everything is ok.
Thanks in advance.


From Sergey.Bylokhov at oracle.com  Fri Oct 14 12:33:47 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 14 Oct 2016 15:33:47 +0300
Subject: <AWT Dev> [9] Review request for 8167565: [macosx] Maximization
 of a dialog hides it
In-Reply-To: <a60e7751-7089-4af8-f29b-4dfe68dc421c@oracle.com>
References: <ea019b4d-9c0c-82a4-61fe-916e7e179ea4@oracle.com>
	<a60e7751-7089-4af8-f29b-4dfe68dc421c@oracle.com>
Message-ID: <adde17ac-8fa7-eab4-c39e-0a03157e2837@oracle.com>

+1

On 14.10.16 9:48, Semyon Sadetsky wrote:
> Looks good.
>
> --Semyon
>
>
> On 13.10.2016 18:17, Alexander Zvegintsev wrote:
>> Hello,
>>
>> please review the fix
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8167565/00/
>>
>> for the issue
>>
>> https://bugs.openjdk.java.net/browse/JDK-8167565
>>
>> We trying to zoom to a zero size window(standardFrame has zero size).
>> standardFrame initialization happens on setMaximizedBounds call.
>> Dialog doesn't initialize it(Frames has setMaximizedBounds() call in
>> Frame.addNotify).
>> I prefer to fix it in the native level, if you have other thoughts
>> please share it.
>>
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Oct 14 12:43:32 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 14 Oct 2016 15:43:32 +0300
Subject: <AWT Dev> [9] Review request for 8167486:
 Device.getDisplayMode() doesn't report refresh rate on Linux in case of
 dual screen
In-Reply-To: <e4b33a27-d5e2-63b0-a4b9-ec3f4caa9e30@oracle.com>
References: <d7ce05cf-6e35-bba9-317d-244fe0c11ba8@oracle.com>
	<1be97cef-7445-c9db-861f-1381599bfbf3@oracle.com>
	<f00d7929-4904-0a5f-3be7-1bd2570d8766@oracle.com>
	<e4b33a27-d5e2-63b0-a4b9-ec3f4caa9e30@oracle.com>
Message-ID: <81400184-016c-6423-3430-85d61a321e3f@oracle.com>

On 12.10.16 10:27, Semyon Sadetsky wrote:
>>> Should toString() method report zero HZ as unknown(os something like
>>> that) instead of 0? And probably "DEPTH_MULTI"also should be printed in
>>> some way, instead of empty line.
> http://cr.openjdk.java.net/~ssadetsky/8167486/webrev.01/

Looks fine.

>>>
>>> On 11.10.16 16:15, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8167486
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8167486/webrev.00/
>>>>
>>>> In  case Xinerama is on, the current display mode cannot be obtained by
>>>> the old xrandr lib calls for secondary screens. The new xrandr API that
>>>> supports Xinerama is used for this case in the proposed solution.
>>>>
>>>> --Semyon
>>>>
>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Oct 14 13:17:13 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 14 Oct 2016 16:17:13 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <1baec804-931e-f85f-614d-49e79960e472@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
	<04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
	<911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>
	<07ce3934-96fb-dc64-99df-995e5a0ca28a@oracle.com>
	<d88f1d0b-d467-324b-6237-84eeec50046e@oracle.com>
	<38787b3b-1356-977f-ca23-c6e728d3ceda@oracle.com>
	<29f01520-99b0-7438-02a5-51cc248be29d@oracle.com>
	<f45beddd-f4be-ac91-aeee-34786853021f@oracle.com>
	<a43d3eba-5d13-48de-0f83-2efa664da2a3@oracle.com>
	<8c7239fe-51c8-c8f4-84b2-87e16295761d@oracle.com>
	<f4a857cc-ebd4-8c65-fd3c-ff9adf4389f3@oracle.com>
	<fb98b819-4ace-170c-e128-68c6d50b167a@oracle.com>
	<1baec804-931e-f85f-614d-49e79960e472@oracle.com>
Message-ID: <8e556458-1d5d-6fab-3528-ece33f050df6@oracle.com>

On 05.10.16 10:40, Semyon Sadetsky wrote:
>>> "in the way how bounds are used"  what does it mean?
>>
>> In current code the bounds of the graphics config are used incorrectly.
> The thing is that the code produce the correct result, while the new
> code caused regression. Or you are insisting that the issue should be
> closed as not a bug?

It should not be closed as not a bug, the location of the popus should 
be recalculated based on the GC size.


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Oct 14 13:32:44 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 14 Oct 2016 16:32:44 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8158390: [macosx]
 Regression: javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java
In-Reply-To: <8D8375A9-60ED-4D99-97ED-7FE44D1B07BC@oracle.com>
References: <8D8375A9-60ED-4D99-97ED-7FE44D1B07BC@oracle.com>
Message-ID: <8ed1d3bf-0495-64f3-c650-8a2b1f95b03f@oracle.com>

Looks fine.

On 13.10.16 15:20, Manajit Halder wrote:
> Hi All,
>
> Kindly review the fix for JDK9.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8158390
>
> Webrev:
> http://cr.openjdk.java.net/~mhalder/8158390/webrev.00/
>
> Issue:
> [macosx] Regression:
> javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java
>
> Cause:
> Event queue was not processed completely for robot keyPress, keyRelease,
> mouseMove, mousePress and mouseRelease events.
>
> Fix:
> Problem was solved by adding setAutoDelay and setAutoWaitForIdle(true)
> after robot creation.
>
> Regards,
> Manajit


-- 
Best regards, Sergey.

From andrey.rusakov at oracle.com  Fri Oct 14 16:02:17 2016
From: andrey.rusakov at oracle.com (Andrey Rusakov)
Date: Fri, 14 Oct 2016 19:02:17 +0300
Subject: <AWT Dev> [9] Review request: 8167155 [PIT] failure and a test bug
 in MultiResolutionTrayIconTest.java
Message-ID: <978aecfb-eaed-d8d4-377a-8aed22fdd2b2@oracle.com>

Hello,

please review the fix

http://cr.openjdk.java.net/~arusakov/8167155/webrev.00

for the issue

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

This fix resolves issue which caused test to pass even if "fail" button was clicked and adds jtreg platform filter.

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

From andrey.rusakov at oracle.com  Fri Oct 14 16:02:21 2016
From: andrey.rusakov at oracle.com (Andrey Rusakov)
Date: Fri, 14 Oct 2016 19:02:21 +0300
Subject: <AWT Dev> [9] Review request: 8165144 [PIT][TEST_BUG] Restrict by
 linux the java/awt/image/multiresolution/MultiResolutionIcon/IconTest.java
Message-ID: <2bd256fd-0dfe-20f3-59d6-4f90f56cf51f@oracle.com>

Hello,

please review the fix

http://cr.openjdk.java.net/~arusakov/8165144/webrev.00/

for the issue

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

This fix resolves issue which caused test to pass even if "fail" button was clicked and adds jtreg platform filter.

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

From andrey.rusakov at oracle.com  Fri Oct 14 16:02:26 2016
From: andrey.rusakov at oracle.com (Andrey Rusakov)
Date: Fri, 14 Oct 2016 19:02:26 +0300
Subject: <AWT Dev> [9] Review request: 8167159 [PIT][TEST_BUG]
 java/awt/image/multiresolution/MultiResolutionIcon/MultiResIconTest.java
Message-ID: <0dbbb3a1-3b98-52ce-0461-65260e0d1586@oracle.com>

Hello,

please review the fix

http://cr.openjdk.java.net/~arusakov/8167159/webrev.00

for the issue

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

This fix resolves issue which caused test to pass even if "fail" button was clicked and adds jtreg platform filter.

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

From philip.race at oracle.com  Fri Oct 14 17:34:44 2016
From: philip.race at oracle.com (Phil Race)
Date: Fri, 14 Oct 2016 10:34:44 -0700
Subject: <AWT Dev> [9] Review request: 8167155 [PIT] failure and a test
 bug in MultiResolutionTrayIconTest.java
In-Reply-To: <978aecfb-eaed-d8d4-377a-8aed22fdd2b2@oracle.com>
References: <978aecfb-eaed-d8d4-377a-8aed22fdd2b2@oracle.com>
Message-ID: <6ad64aab-1c6c-6e3c-ce61-bd1f1dfa987a@oracle.com>

 > This fix resolves issue which caused test to pass even if "fail" 
button was clicked and adds jtreg platform filter.

But what about the issue that (as I read it) the test does actually fail ?

 > The test fails adding not blue (as requested) but red icon to a tray.

The test bug was secondary ..

-phil.

On 10/14/2016 09:02 AM, Andrey Rusakov wrote:
> Hello,
>
> please review the fix
>
> http://cr.openjdk.java.net/~arusakov/8167155/webrev.00
>
> for the issue
>
> https://bugs.openjdk.java.net/browse/JDK-8167155
>
> This fix resolves issue which caused test to pass even if "fail" button was clicked and adds jtreg platform filter.
>

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

From alexandr.scherbatiy at oracle.com  Fri Oct 14 18:24:00 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Fri, 14 Oct 2016 21:24:00 +0300
Subject: <AWT Dev> [9] Review request: 8167159 [PIT][TEST_BUG]
 java/awt/image/multiresolution/MultiResolutionIcon/MultiResIconTest.java
In-Reply-To: <0dbbb3a1-3b98-52ce-0461-65260e0d1586@oracle.com>
References: <0dbbb3a1-3b98-52ce-0461-65260e0d1586@oracle.com>
Message-ID: <6ac7a6b3-9686-e27f-9ba6-aaeff609aa6c@oracle.com>


The Windows OS is not listed in the test @requires tag but the test 
should work on Windows as well.

Thanks,
Alexandr.

On 10/14/2016 7:02 PM, Andrey Rusakov wrote:
> Hello,
>
> please review the fix
>
> http://cr.openjdk.java.net/~arusakov/8167159/webrev.00
>
> for the issue
>
> https://bugs.openjdk.java.net/browse/JDK-8167159
>
> This fix resolves issue which caused test to pass even if "fail" button was clicked and adds jtreg platform filter.

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

From ambarish.rapte at oracle.com  Mon Oct 17 02:54:32 2016
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Sun, 16 Oct 2016 19:54:32 -0700 (PDT)
Subject: <AWT Dev> Review Request for 8167288: [TEST_BUG] Consistent failure
 on Unity of WarningWindowDisposeTest.java
Message-ID: <58ceff37-6023-4693-9568-b106aa4992dc@default>

Hi,

                Please review this test bug fix,

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

                Webrev: http://cr.openjdk.java.net/~arapte/8167288/webrev.00

 

Issue:

                The test creates a child process to display a warning window.

                That child process is expected to end within 5 seconds.

                But on some slower or busy system, child process takes more time to end which causes failure.

Fix:

                Fix is to wait more time for child process to end.

Now the test will wait for maximum of 10 seconds in iteration of 2 seconds.

 

 

Regards,

Ambarish

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

From semyon.sadetsky at oracle.com  Mon Oct 17 06:46:30 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 17 Oct 2016 09:46:30 +0300
Subject: <AWT Dev> Review Request for 8167288: [TEST_BUG] Consistent
 failure on Unity of WarningWindowDisposeTest.java
In-Reply-To: <58ceff37-6023-4693-9568-b106aa4992dc@default>
References: <58ceff37-6023-4693-9568-b106aa4992dc@default>
Message-ID: <83014333-656f-8d95-484c-3f4a0cbeb330@oracle.com>

Looks good.

--Semyon


On 10/17/2016 5:54 AM, Ambarish Rapte wrote:
>
> Hi,
>
>                 Please review this test bug fix,
>
>                 Bug: https://bugs.openjdk.java.net/browse/JDK-8167288
>
>                 Webrev: 
> http://cr.openjdk.java.net/~arapte/8167288/webrev.00 
> <http://cr.openjdk.java.net/%7Earapte/8167288/webrev.00>
>
> Issue:
>
>                 The test creates a child process to display a warning 
> window.
>
>                 That child process is expected to end within 5 seconds.
>
>                 But on some slower or busy system, child process takes 
> more time to end which causes failure.
>
> Fix:
>
>                 Fix is to wait more time for child process to end.
>
> Now the test will wait for maximum of 10 seconds in iteration of 2 
> seconds.
>
> Regards,
>
> Ambarish
>

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

From semyon.sadetsky at oracle.com  Mon Oct 17 07:35:43 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 17 Oct 2016 10:35:43 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <8e556458-1d5d-6fab-3528-ece33f050df6@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
	<04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
	<911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>
	<07ce3934-96fb-dc64-99df-995e5a0ca28a@oracle.com>
	<d88f1d0b-d467-324b-6237-84eeec50046e@oracle.com>
	<38787b3b-1356-977f-ca23-c6e728d3ceda@oracle.com>
	<29f01520-99b0-7438-02a5-51cc248be29d@oracle.com>
	<f45beddd-f4be-ac91-aeee-34786853021f@oracle.com>
	<a43d3eba-5d13-48de-0f83-2efa664da2a3@oracle.com>
	<8c7239fe-51c8-c8f4-84b2-87e16295761d@oracle.com>
	<f4a857cc-ebd4-8c65-fd3c-ff9adf4389f3@oracle.com>
	<fb98b819-4ace-170c-e128-68c6d50b167a@oracle.com>
	<1baec804-931e-f85f-614d-49e79960e472@oracle.com>
	<8e556458-1d5d-6fab-3528-ece33f050df6@oracle.com>
Message-ID: <a8f9bacb-f26b-0902-334b-ca403b864b3f@oracle.com>



On 10/14/2016 4:17 PM, Sergey Bylokhov wrote:
> On 05.10.16 10:40, Semyon Sadetsky wrote:
>>>> "in the way how bounds are used"  what does it mean?
>>>
>>> In current code the bounds of the graphics config are used incorrectly.
>> The thing is that the code produce the correct result, while the new
>> code caused regression. Or you are insisting that the issue should be
>> closed as not a bug?
>
> It should not be closed as not a bug, the location of the popus should 
> be recalculated based on the GC size.
As I already explain to you it should be a separate bug. GC is assumed 
to be changed when window is moved to another screen but this doesn't 
happen on Linux. It was initially designed this way.
This current bug is a regression fix. It just reverts the way it has 
been always working.

From yuri.nesterenko at oracle.com  Mon Oct 17 07:48:13 2016
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Mon, 17 Oct 2016 10:48:13 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for
 JDK-8161473:[TEST_BUG] [macosx] add autodelay to
 java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java
In-Reply-To: <ed5fb84d-2132-c841-7b86-288454535079@oracle.com>
References: <334B090B-6409-4467-AD8D-AF0EAD1935F7@oracle.com>
	<147d64e5-38c1-4424-bed7-774d38c9e6e3@default>
	<27223022-A599-47EE-8ED8-C3BFE962451F@oracle.com>
	<65dbffd8-a039-4d79-8bb8-9101b555f64c@default>
	<ed5fb84d-2132-c841-7b86-288454535079@oracle.com>
Message-ID: <b4109259-8c1b-87ac-d1e5-cf00a79d57e3@oracle.com>

+1

-yan

On 10/12/2016 06:44 PM, Sergey Bylokhov wrote:
> On 12.10.16 9:04, Ambarish Rapte wrote:
>> Thanks Anubhav,
>>                 Changes look fine to me.
>
> +1
>
>> *From:*Anubhav Meena
>> *Sent:* Monday, October 10, 2016 5:06 PM
>> *To:* Ambarish Rapte
>> *Cc:* awt-dev at openjdk.java.net
>> *Subject:* Re: <AWT Dev> <AWT dev>[9] Review request for
>> JDK-8161473:[TEST_BUG] [macosx] add autodelay to
>> java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java
>>
>>
>>
>> Hi Ambarish,
>>
>>
>>
>> Have made the changes you suggested. Please find them
>> here http://cr.openjdk.java.net/~rchamyal/anmeena/8161473/webrev.01/
>>
>>
>>
>> Thanks,
>>
>> Anubhav
>>
>>
>>
>>     On Oct 10, 2016, at 2:01 PM, Ambarish Rapte
>>     <ambarish.rapte at oracle.com <mailto:ambarish.rapte at oracle.com>> wrote:
>>
>>
>>
>>     Hi Anubhav,
>>
>>
>>
>>                     Along with the fix, could you please add below
>>     trivial changes as well,
>>
>>
>>
>>     1.       Add @key headful & @bug 8161473  jtreg tags
>>
>>     2.       Change wild card * import to add specific package imports.
>>
>>     3.       Update copyright with year 2016.
>>
>>
>>
>>
>>
>>     Regards,
>>
>>     Ambarish
>>
>>
>>
>>     *From:* Anubhav Meena
>>     *Sent:* Friday, October 07, 2016 6:46 PM
>>     *To:* awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>>     *Subject:* <AWT Dev> <AWT dev>[9] Review request for
>>     JDK-8161473:[TEST_BUG] [macosx] add autodelay to
>>
>> java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java
>>
>>
>>
>>     Hi All,
>>
>>
>>
>>     Kindly review the fix for JDK9.
>>
>>
>>
>>     Bug:
>>
>>     _https://bugs.openjdk.java.net/browse/JDK-8161473_
>>
>>
>>
>>     Webrev:
>>
>>     _http://cr.openjdk.java.net/~rchamyal/anmeena/8161473/webrev.00/_
>>
>>
>>
>>     Issue:
>>
>>     [macosx] The test
>>
>> java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java
>>     often fails, especially on OS X.
>>
>>
>>
>>     Cause:
>>
>>     Lack of minimal delay between elementary robot operations
>>
>>
>>
>>     Fix:
>>
>>     Added wait for idle operation between two robot events.
>>
>>
>>
>>     Regards,
>>
>>     Anubhav
>>
>>
>>
>
>


From alexander.zvegintsev at oracle.com  Mon Oct 17 09:30:21 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 17 Oct 2016 12:30:21 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
Message-ID: <bdda6393-795c-b608-9409-01d6edb086ae@oracle.com>

Looks good.


On 10/7/16 4:21 PM, Sergey Bylokhov wrote:
> On 07.10.16 10:06, Semyon Sadetsky wrote:
>> Hi Sergey,
>>
>> After applying the patch I found 72 usages of the Event class. Why they
>> are not replaced?
>
> By the same reason why InputEvent.getModifiers() was not replaced by 
> InputEvent.getModifiersEx():
>
> >>>     We can replace old constants by the new one in the whole jdk, 
> but I
> >>>     updated only the code in InputEvent to make change smaller and
> >>>     safer. So at least the new code in jdk and the code in 
> applications
> >>>     will start to use the new constants.
>
>
>> On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
>>> Thanks for the comments.
>>> The new version:
>>> http://cr.openjdk.java.net/~serb/8143077/webrev.01
>>> The specification of Event class and InputEvent.getModifiers() are
>>> updated.
>>>
>>> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>>>> Hi Sergey,
>>>>
>>>> I'm not a reviewer, but after reading the deprecation messages in
>>>> Event.java
>>>>
>>>>     * @deprecated It is recommended that {@code AWTEvent} class and 
>>>> its
>>>>     subclasses
>>>>     *             be used instead.
>>>>
>>>>
>>>> I get the impression they would read better without the redundant
>>>> "class" in the middle, like so.
>>>>
>>>>     * @deprecated It is recommended that {@code AWTEvent} and its
>>>> subclasses
>>>>     *             be used instead.
>>>>
>>>>
>>>> Kind regards,
>>>> Jonathan
>>>>
>>>>
>>>> On 30 September 2016 at 16:45, Sergey Bylokhov
>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> 
>>>> wrote:
>>>>
>>>>     Hello.
>>>>
>>>>     Please review the fix for jdk9.
>>>>
>>>>     This is request to deprecate the obsolete flags inside InputEvent.
>>>>     This constants were marked as obsolete in jdk1.4 and were replaced
>>>>     by the new one. In jdk1.4 the documentation were update with 
>>>> notion
>>>>     that the new constants should be used. And this bug is about
>>>>     official deprecation of them.
>>>>
>>>>     We can replace old constants by the new one in the whole jdk, 
>>>> but I
>>>>     updated only the code in InputEvent to make change smaller and
>>>>     safer. So at least the new code in jdk and the code in 
>>>> applications
>>>>     will start to use the new constants.
>>>>
>>>>     The changes in jconsole are necessary to fix deprecation warning.
>>>>
>>>>     jprt build passed, no new issues were found by jck/jtreg tests.
>>>>
>>>>
>>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>>>>     <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>>>     Webrev can be found at:
>>>>     http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>>> <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>>>
>>>>     --
>>>>     Best regards, Sergey.
>>>>
>>>>
>>>
>>>
>>
>
>

-- 
Thanks,
Alexander.


From alexander.zvegintsev at oracle.com  Mon Oct 17 09:57:40 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 17 Oct 2016 12:57:40 +0300
Subject: <AWT Dev> [9] Review request for 8166897: Some font overlap in
 the Optionpane dialog.
In-Reply-To: <4cfe1fe3-9887-199a-96e2-e676b16afef6@oracle.com>
References: <4cfe1fe3-9887-199a-96e2-e676b16afef6@oracle.com>
Message-ID: <749da978-d206-bce8-6fc0-0b1e1fd4ef80@oracle.com>

+1

Thanks,
Alexander.

On 10/13/16 12:12 AM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8166897
>
> webrev: http://cr.openjdk.java.net/~ssadetsky/8166897/webrev.00/
>
> The setResizable() method of XDecoratedPeer class clears the frame 
> insets to allow them to receive the updated size. In some situations 
> clearing insets during establishing the frame dimensions may break the 
> new frame dimensions algorithm for Unity and the frame content 
> positioning becomes wrong.
>
> Since in this new algorithm the insets may be arbitrary updated by WM 
> it doesn't necessary to clear insets to get them the new size. The 
> proposed solution is to avoid to force frame insets to zero when the 
> frame is made resizable or non-resizable by user.
>
> --Semyon
>


From alexandr.scherbatiy at oracle.com  Mon Oct 17 11:24:50 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Mon, 17 Oct 2016 14:24:50 +0300
Subject: <AWT Dev> Review Request for 8167288: [TEST_BUG] Consistent
 failure on Unity of WarningWindowDisposeTest.java
In-Reply-To: <83014333-656f-8d95-484c-3f4a0cbeb330@oracle.com>
References: <58ceff37-6023-4693-9568-b106aa4992dc@default>
	<83014333-656f-8d95-484c-3f4a0cbeb330@oracle.com>
Message-ID: <bacbc738-a17d-0519-e5a0-4b1abff74a14@oracle.com>

The fix looks good to me.

Thanks,
Alexandr.

On 10/17/2016 9:46 AM, Semyon Sadetsky wrote:
>
> Looks good.
>
> --Semyon
>
>
> On 10/17/2016 5:54 AM, Ambarish Rapte wrote:
>>
>> Hi,
>>
>>                 Please review this test bug fix,
>>
>>                 Bug: https://bugs.openjdk.java.net/browse/JDK-8167288
>>
>>                 Webrev: 
>> http://cr.openjdk.java.net/~arapte/8167288/webrev.00 
>> <http://cr.openjdk.java.net/%7Earapte/8167288/webrev.00>
>>
>> Issue:
>>
>>                 The test creates a child process to display a warning 
>> window.
>>
>>                 That child process is expected to end within 5 seconds.
>>
>>                 But on some slower or busy system, child process 
>> takes more time to end which causes failure.
>>
>> Fix:
>>
>>                 Fix is to wait more time for child process to end.
>>
>> Now the test will wait for maximum of 10 seconds in iteration of 2 
>> seconds.
>>
>> Regards,
>>
>> Ambarish
>>
>

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

From semyon.sadetsky at oracle.com  Mon Oct 17 12:16:17 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 17 Oct 2016 15:16:17 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
Message-ID: <7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>

On 10/7/2016 4:21 PM, Sergey Bylokhov wrote:

> On 07.10.16 10:06, Semyon Sadetsky wrote:
>> Hi Sergey,
>>
>> After applying the patch I found 72 usages of the Event class. Why they
>> are not replaced?
>
> By the same reason why InputEvent.getModifiers() was not replaced by 
> InputEvent.getModifiersEx():
>
> >>>     We can replace old constants by the new one in the whole jdk, 
> but I
> >>>     updated only the code in InputEvent to make change smaller and
> >>>     safer. So at least the new code in jdk and the code in 
> applications
> >>>     will start to use the new constants.
But I didn't get why it is risky? Usually find&replace works reliably.

--Semyon
>
>
>> On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
>>> Thanks for the comments.
>>> The new version:
>>> http://cr.openjdk.java.net/~serb/8143077/webrev.01
>>> The specification of Event class and InputEvent.getModifiers() are
>>> updated.
>>>
>>> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>>>> Hi Sergey,
>>>>
>>>> I'm not a reviewer, but after reading the deprecation messages in
>>>> Event.java
>>>>
>>>>     * @deprecated It is recommended that {@code AWTEvent} class and 
>>>> its
>>>>     subclasses
>>>>     *             be used instead.
>>>>
>>>>
>>>> I get the impression they would read better without the redundant
>>>> "class" in the middle, like so.
>>>>
>>>>     * @deprecated It is recommended that {@code AWTEvent} and its
>>>> subclasses
>>>>     *             be used instead.
>>>>
>>>>
>>>> Kind regards,
>>>> Jonathan
>>>>
>>>>
>>>> On 30 September 2016 at 16:45, Sergey Bylokhov
>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> 
>>>> wrote:
>>>>
>>>>     Hello.
>>>>
>>>>     Please review the fix for jdk9.
>>>>
>>>>     This is request to deprecate the obsolete flags inside InputEvent.
>>>>     This constants were marked as obsolete in jdk1.4 and were replaced
>>>>     by the new one. In jdk1.4 the documentation were update with 
>>>> notion
>>>>     that the new constants should be used. And this bug is about
>>>>     official deprecation of them.
>>>>
>>>>     We can replace old constants by the new one in the whole jdk, 
>>>> but I
>>>>     updated only the code in InputEvent to make change smaller and
>>>>     safer. So at least the new code in jdk and the code in 
>>>> applications
>>>>     will start to use the new constants.
>>>>
>>>>     The changes in jconsole are necessary to fix deprecation warning.
>>>>
>>>>     jprt build passed, no new issues were found by jck/jtreg tests.
>>>>
>>>>
>>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>>>>     <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>>>     Webrev can be found at:
>>>>     http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>>> <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>>>
>>>>     --
>>>>     Best regards, Sergey.
>>>>
>>>>
>>>
>>>
>>
>
>


From semyon.sadetsky at oracle.com  Mon Oct 17 12:39:05 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 17 Oct 2016 15:39:05 +0300
Subject: <AWT Dev> [9] Review Request: 8166673 The new implementation of
 Robot.waitForIdle() may hang
In-Reply-To: <47c431f1-9b1f-7fcb-63d5-bdf2c4b7d438@oracle.com>
References: <73586e81-9035-10b8-de87-0ab220ee5395@oracle.com>
	<d53fc03c-6f16-06d1-7f38-9a2d90833904@oracle.com>
	<062faa6e-426f-3e6c-dab9-10c0d9d8211c@oracle.com>
	<47c431f1-9b1f-7fcb-63d5-bdf2c4b7d438@oracle.com>
Message-ID: <955f0bea-10aa-3bd3-0b2f-bc0213652e7b@oracle.com>

+1

--Semyon


On 10/11/2016 4:36 PM, Alexander Zvegintsev wrote:
> +1
>
> -- 
> Thanks,
> Alexander.
>
> On 07.10.2016 17:07, Sergey Bylokhov wrote:
>> On 07.10.16 10:28, Semyon Sadetsky wrote:
>>> Hi Sergey,
>>>
>>> 1525         queueEmpty = false;
>>> 1526         eventDispatched = false;
>>> 1527         synchronized(waitLock) {
>>>
>>> Shouldn't lines 1525 & 1526 be moved inside the synchronized block?
>>
>> I think so, at least this will unify how we use these in dispatch 
>> event and at the end of waitForIdle():
>> http://cr.openjdk.java.net/~serb/8166673/webrev.01
>>
>>> On 9/26/2016 8:38 PM, Sergey Bylokhov wrote:
>>>> Hello.
>>>>
>>>> Please review the fix for jdk9.
>>>>
>>>> The SunToolkit.waitForIdle() uses string literal for synchronization,
>>>> which means some code (intentionally or not) can hang 
>>>> Robot.waitForIdle.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166673
>>>> Webrev can be found at:
>>>> http://cr.openjdk.java.net/~serb/8166673/webrev.00
>>>>
>>>
>>
>>
>


From Sergey.Bylokhov at oracle.com  Mon Oct 17 14:19:19 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 17 Oct 2016 17:19:19 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
Message-ID: <f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>

On 17.10.16 15:16, Semyon Sadetsky wrote:
>> >>>     We can replace old constants by the new one in the whole jdk,
>> but I
>> >>>     updated only the code in InputEvent to make change smaller and
>> >>>     safer. So at least the new code in jdk and the code in
>> applications
>> >>>     will start to use the new constants.
> But I didn't get why it is risky? Usually find&replace works reliably.

Because they works differently(this is why the second getModifiersEx was 
added) and some code can rely on the behavior of getModifiers().

>>> On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
>>>> Thanks for the comments.
>>>> The new version:
>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.01
>>>> The specification of Event class and InputEvent.getModifiers() are
>>>> updated.
>>>>
>>>> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> I'm not a reviewer, but after reading the deprecation messages in
>>>>> Event.java
>>>>>
>>>>>     * @deprecated It is recommended that {@code AWTEvent} class and
>>>>> its
>>>>>     subclasses
>>>>>     *             be used instead.
>>>>>
>>>>>
>>>>> I get the impression they would read better without the redundant
>>>>> "class" in the middle, like so.
>>>>>
>>>>>     * @deprecated It is recommended that {@code AWTEvent} and its
>>>>> subclasses
>>>>>     *             be used instead.
>>>>>
>>>>>
>>>>> Kind regards,
>>>>> Jonathan
>>>>>
>>>>>
>>>>> On 30 September 2016 at 16:45, Sergey Bylokhov
>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>
>>>>> wrote:
>>>>>
>>>>>     Hello.
>>>>>
>>>>>     Please review the fix for jdk9.
>>>>>
>>>>>     This is request to deprecate the obsolete flags inside InputEvent.
>>>>>     This constants were marked as obsolete in jdk1.4 and were replaced
>>>>>     by the new one. In jdk1.4 the documentation were update with
>>>>> notion
>>>>>     that the new constants should be used. And this bug is about
>>>>>     official deprecation of them.
>>>>>
>>>>>     We can replace old constants by the new one in the whole jdk,
>>>>> but I
>>>>>     updated only the code in InputEvent to make change smaller and
>>>>>     safer. So at least the new code in jdk and the code in
>>>>> applications
>>>>>     will start to use the new constants.
>>>>>
>>>>>     The changes in jconsole are necessary to fix deprecation warning.
>>>>>
>>>>>     jprt build passed, no new issues were found by jck/jtreg tests.
>>>>>
>>>>>
>>>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>>>>>     <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>>>>     Webrev can be found at:
>>>>>     http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>>>> <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>>>>
>>>>>     --
>>>>>     Best regards, Sergey.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Mon Oct 17 14:39:03 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 17 Oct 2016 17:39:03 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
Message-ID: <f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>



On 17.10.2016 17:19, Sergey Bylokhov wrote:
> On 17.10.16 15:16, Semyon Sadetsky wrote:
>>> >>>     We can replace old constants by the new one in the whole jdk,
>>> but I
>>> >>>     updated only the code in InputEvent to make change smaller and
>>> >>>     safer. So at least the new code in jdk and the code in
>>> applications
>>> >>>     will start to use the new constants.
>> But I didn't get why it is risky? Usually find&replace works reliably.
>
> Because they works differently(this is why the second getModifiersEx 
> was added) and some code can rely on the behavior of getModifiers().
At least usages of Event.*_MASK could be safely replaced with 
InputEvent.*_DOWN_MASK.
And, please, limit the length of the changed line in VMPanel.java to 80 
chars.
>
>>>> On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
>>>>> Thanks for the comments.
>>>>> The new version:
>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.01
>>>>> The specification of Event class and InputEvent.getModifiers() are
>>>>> updated.
>>>>>
>>>>> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> I'm not a reviewer, but after reading the deprecation messages in
>>>>>> Event.java
>>>>>>
>>>>>>     * @deprecated It is recommended that {@code AWTEvent} class and
>>>>>> its
>>>>>>     subclasses
>>>>>>     *             be used instead.
>>>>>>
>>>>>>
>>>>>> I get the impression they would read better without the redundant
>>>>>> "class" in the middle, like so.
>>>>>>
>>>>>>     * @deprecated It is recommended that {@code AWTEvent} and its
>>>>>> subclasses
>>>>>>     *             be used instead.
>>>>>>
>>>>>>
>>>>>> Kind regards,
>>>>>> Jonathan
>>>>>>
>>>>>>
>>>>>> On 30 September 2016 at 16:45, Sergey Bylokhov
>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>> wrote:
>>>>>>
>>>>>>     Hello.
>>>>>>
>>>>>>     Please review the fix for jdk9.
>>>>>>
>>>>>>     This is request to deprecate the obsolete flags inside 
>>>>>> InputEvent.
>>>>>>     This constants were marked as obsolete in jdk1.4 and were 
>>>>>> replaced
>>>>>>     by the new one. In jdk1.4 the documentation were update with
>>>>>> notion
>>>>>>     that the new constants should be used. And this bug is about
>>>>>>     official deprecation of them.
>>>>>>
>>>>>>     We can replace old constants by the new one in the whole jdk,
>>>>>> but I
>>>>>>     updated only the code in InputEvent to make change smaller and
>>>>>>     safer. So at least the new code in jdk and the code in
>>>>>> applications
>>>>>>     will start to use the new constants.
>>>>>>
>>>>>>     The changes in jconsole are necessary to fix deprecation 
>>>>>> warning.
>>>>>>
>>>>>>     jprt build passed, no new issues were found by jck/jtreg tests.
>>>>>>
>>>>>>
>>>>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>>>>>     Webrev can be found at:
>>>>>>     http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>>>>> <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>>>>>
>>>>>>     --
>>>>>>     Best regards, Sergey.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Mon Oct 17 14:40:49 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 17 Oct 2016 17:40:49 +0300
Subject: <AWT Dev> JDK-8098530: ArrayIndexOutOfBoundsException at
 sun.awt.X11.XEvent.getFieldsAsString
In-Reply-To: <CAKXpgZfjpy=eNTLmGhGOwcjbvH5rh+PobUMMFfKvCkUu+-uWfA@mail.gmail.com>
References: <CAFL4mEFyhkMUQyVnwAyMXHwcTx0JpbyyBa0AfzpWfwFzjtNZEA@mail.gmail.com>
	<3ef6895c-a04a-0b1f-b8d8-7158a089d860@oracle.com>
	<CAKXpgZfjpy=eNTLmGhGOwcjbvH5rh+PobUMMFfKvCkUu+-uWfA@mail.gmail.com>
Message-ID: <8e360718-20d3-3191-07fe-913cbb80d9d5@oracle.com>

On 17.10.16 15:12, Vladislav Rassokhin wrote:
> I'm just end user of jre and really annoyed by this exception clogs
> application logs.

If you know how to reproduce this bug, then the test will be quite 
simple. An example of such tests you can find here:
http://hg.openjdk.java.net/jdk9/client/jdk/file/32d9fe67dede/test/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java

> It took 15 minutes year ago to find that bug and vote for it, 15 minutes
> last week to fix that using grep and vim.
> Unfortunately I've no spare time to learn how to create tests for
> openjdk, sign CLA and do other stuff, so asked our jdk team to send
> patch somewhere.

In your case it is not necessary to sign OCA, because JetBrains s.r.o. 
already signed it:
http://www.oracle.com/technetwork/community/oca-486395.html

> Seems openjdk contributing process is quite complicated for simple fix.
>
> Anyway I'd attach patch to issue.
>
> On Wed, Oct 12, 2016 at 8:48 PM, Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>
>     Is it possible to create a test for this issue?
>
>     On 12.10.16 19:07, Sergey Malenkov wrote:
>
>         Hi all,
>
>         Could you please consider the following changes to fix JDK-8098530?
>
>         --- src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java
>         (revision f0ae41314e223bf1b97c8126ac2b0d6edb5ee99d)
>         +++ src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java
>         (revision )
>         @@ -690,7 +690,7 @@
>                          if (type == AtomicType.TYPE_ATOM) {
>                              pw.println("\t\tret.append(\"" + name + " = \"
>         ).append( XAtom.get(get_" + name + "()) ).append(\", \");");
>                          } else if (name.equals("type")) {
>         -                    pw.println("\t\tret.append(\"type = \").append(
>         XlibWrapper.eventToString[get_type()] ).append(\", \");");
>         +                    pw.println("\t\tret.append(\"type = \").append(
>         XlibWrapper.getEventToString(get_type()) ).append(\", \");");
>                          } else if (name.equals("window")){
>                              pw.println("\t\tret.append(\"window = \"
>         ).append(
>         getWindow(get_window()) ).append(\", \");");
>                          } else if (type == AtomicType.TYPE_ARRAY) {
>
>         The sun.awt.X11.XlibWrapper class provides a method, which
>         handles such
>         errors.
>         We should not access to array directly.
>
>         --
>         Best regards,
>         Sergey A. Malenkov
>
>
>
>     --
>     Best regards, Sergey.
>
>
>
>
> --
> Vladislav Rassokhin
> Java developer (TeamCity)
> JetBrains
> https://www.jetbrains.com
> The Drive to Develop


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Oct 17 15:37:53 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 17 Oct 2016 18:37:53 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
	<f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
Message-ID: <2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>

On 17.10.16 17:39, Semyon Sadetsky wrote:
>
>
> On 17.10.2016 17:19, Sergey Bylokhov wrote:
>> On 17.10.16 15:16, Semyon Sadetsky wrote:
>>>> >>>     We can replace old constants by the new one in the whole jdk,
>>>> but I
>>>> >>>     updated only the code in InputEvent to make change smaller and
>>>> >>>     safer. So at least the new code in jdk and the code in
>>>> applications
>>>> >>>     will start to use the new constants.
>>> But I didn't get why it is risky? Usually find&replace works reliably.
>>
>> Because they works differently(this is why the second getModifiersEx
>> was added) and some code can rely on the behavior of getModifiers().
> At least usages of Event.*_MASK could be safely replaced with
> InputEvent.*_DOWN_MASK.

How it could be safe? both are a different constants which should be 
used in pair with different methods?

> And, please, limit the length of the changed line in VMPanel.java to 80
> chars.
>>
>>>>> On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
>>>>>> Thanks for the comments.
>>>>>> The new version:
>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.01
>>>>>> The specification of Event class and InputEvent.getModifiers() are
>>>>>> updated.
>>>>>>
>>>>>> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>>>>>>> Hi Sergey,
>>>>>>>
>>>>>>> I'm not a reviewer, but after reading the deprecation messages in
>>>>>>> Event.java
>>>>>>>
>>>>>>>     * @deprecated It is recommended that {@code AWTEvent} class and
>>>>>>> its
>>>>>>>     subclasses
>>>>>>>     *             be used instead.
>>>>>>>
>>>>>>>
>>>>>>> I get the impression they would read better without the redundant
>>>>>>> "class" in the middle, like so.
>>>>>>>
>>>>>>>     * @deprecated It is recommended that {@code AWTEvent} and its
>>>>>>> subclasses
>>>>>>>     *             be used instead.
>>>>>>>
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Jonathan
>>>>>>>
>>>>>>>
>>>>>>> On 30 September 2016 at 16:45, Sergey Bylokhov
>>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>     Hello.
>>>>>>>
>>>>>>>     Please review the fix for jdk9.
>>>>>>>
>>>>>>>     This is request to deprecate the obsolete flags inside
>>>>>>> InputEvent.
>>>>>>>     This constants were marked as obsolete in jdk1.4 and were
>>>>>>> replaced
>>>>>>>     by the new one. In jdk1.4 the documentation were update with
>>>>>>> notion
>>>>>>>     that the new constants should be used. And this bug is about
>>>>>>>     official deprecation of them.
>>>>>>>
>>>>>>>     We can replace old constants by the new one in the whole jdk,
>>>>>>> but I
>>>>>>>     updated only the code in InputEvent to make change smaller and
>>>>>>>     safer. So at least the new code in jdk and the code in
>>>>>>> applications
>>>>>>>     will start to use the new constants.
>>>>>>>
>>>>>>>     The changes in jconsole are necessary to fix deprecation
>>>>>>> warning.
>>>>>>>
>>>>>>>     jprt build passed, no new issues were found by jck/jtreg tests.
>>>>>>>
>>>>>>>
>>>>>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>>>>>>     Webrev can be found at:
>>>>>>>     http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>>>>>> <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>>>>>>
>>>>>>>     --
>>>>>>>     Best regards, Sergey.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Mon Oct 17 16:01:35 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 17 Oct 2016 19:01:35 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
	<f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
	<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>
Message-ID: <f64fd14a-c99f-6dae-0d99-b730c6afcf48@oracle.com>



On 17.10.2016 18:37, Sergey Bylokhov wrote:
> On 17.10.16 17:39, Semyon Sadetsky wrote:
>>
>>
>> On 17.10.2016 17:19, Sergey Bylokhov wrote:
>>> On 17.10.16 15:16, Semyon Sadetsky wrote:
>>>>> >>>     We can replace old constants by the new one in the whole jdk,
>>>>> but I
>>>>> >>>     updated only the code in InputEvent to make change smaller 
>>>>> and
>>>>> >>>     safer. So at least the new code in jdk and the code in
>>>>> applications
>>>>> >>>     will start to use the new constants.
>>>> But I didn't get why it is risky? Usually find&replace works reliably.
>>>
>>> Because they works differently(this is why the second getModifiersEx
>>> was added) and some code can rely on the behavior of getModifiers().
>> At least usages of Event.*_MASK could be safely replaced with
>> InputEvent.*_DOWN_MASK.
>
> How it could be safe? both are a different constants which should be 
> used in pair with different methods?
Then why do you add in java doc for those constants:
  @deprecated It is recommended that *_DOWN_MASK be used instead
?
>
>> And, please, limit the length of the changed line in VMPanel.java to 80
>> chars.
>>>
>>>>>> On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
>>>>>>> Thanks for the comments.
>>>>>>> The new version:
>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.01
>>>>>>> The specification of Event class and InputEvent.getModifiers() are
>>>>>>> updated.
>>>>>>>
>>>>>>> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>>>>>>>> Hi Sergey,
>>>>>>>>
>>>>>>>> I'm not a reviewer, but after reading the deprecation messages in
>>>>>>>> Event.java
>>>>>>>>
>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent} class 
>>>>>>>> and
>>>>>>>> its
>>>>>>>>     subclasses
>>>>>>>>     *             be used instead.
>>>>>>>>
>>>>>>>>
>>>>>>>> I get the impression they would read better without the redundant
>>>>>>>> "class" in the middle, like so.
>>>>>>>>
>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent} and its
>>>>>>>> subclasses
>>>>>>>>     *             be used instead.
>>>>>>>>
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Jonathan
>>>>>>>>
>>>>>>>>
>>>>>>>> On 30 September 2016 at 16:45, Sergey Bylokhov
>>>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>     Hello.
>>>>>>>>
>>>>>>>>     Please review the fix for jdk9.
>>>>>>>>
>>>>>>>>     This is request to deprecate the obsolete flags inside
>>>>>>>> InputEvent.
>>>>>>>>     This constants were marked as obsolete in jdk1.4 and were
>>>>>>>> replaced
>>>>>>>>     by the new one. In jdk1.4 the documentation were update with
>>>>>>>> notion
>>>>>>>>     that the new constants should be used. And this bug is about
>>>>>>>>     official deprecation of them.
>>>>>>>>
>>>>>>>>     We can replace old constants by the new one in the whole jdk,
>>>>>>>> but I
>>>>>>>>     updated only the code in InputEvent to make change smaller and
>>>>>>>>     safer. So at least the new code in jdk and the code in
>>>>>>>> applications
>>>>>>>>     will start to use the new constants.
>>>>>>>>
>>>>>>>>     The changes in jconsole are necessary to fix deprecation
>>>>>>>> warning.
>>>>>>>>
>>>>>>>>     jprt build passed, no new issues were found by jck/jtreg 
>>>>>>>> tests.
>>>>>>>>
>>>>>>>>
>>>>>>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>>>>>>>     Webrev can be found at:
>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>>>>>>> <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>>>>>>>
>>>>>>>>     --
>>>>>>>>     Best regards, Sergey.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Mon Oct 17 16:35:18 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 17 Oct 2016 19:35:18 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <f64fd14a-c99f-6dae-0d99-b730c6afcf48@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
	<f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
	<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>
	<f64fd14a-c99f-6dae-0d99-b730c6afcf48@oracle.com>
Message-ID: <3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com>

On 17.10.16 19:01, Semyon Sadetsky wrote:
>> How it could be safe? both are a different constants which should be
>> used in pair with different methods?
> Then why do you add in java doc for those constants:
>  @deprecated It is recommended that *_DOWN_MASK be used instead

This recommendation was there before, since these extended masks and 
getModifiersEx() were added and were replaces the old 
modifiers/getModifiers().
These are different constants which are responsible for similar, but not 
the same behavior.

>>> And, please, limit the length of the changed line in VMPanel.java to 80
>>> chars.
>>>>
>>>>>>> On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
>>>>>>>> Thanks for the comments.
>>>>>>>> The new version:
>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.01
>>>>>>>> The specification of Event class and InputEvent.getModifiers() are
>>>>>>>> updated.
>>>>>>>>
>>>>>>>> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>>>>>>>>> Hi Sergey,
>>>>>>>>>
>>>>>>>>> I'm not a reviewer, but after reading the deprecation messages in
>>>>>>>>> Event.java
>>>>>>>>>
>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent} class
>>>>>>>>> and
>>>>>>>>> its
>>>>>>>>>     subclasses
>>>>>>>>>     *             be used instead.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I get the impression they would read better without the redundant
>>>>>>>>> "class" in the middle, like so.
>>>>>>>>>
>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent} and its
>>>>>>>>> subclasses
>>>>>>>>>     *             be used instead.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Kind regards,
>>>>>>>>> Jonathan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 30 September 2016 at 16:45, Sergey Bylokhov
>>>>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>     Hello.
>>>>>>>>>
>>>>>>>>>     Please review the fix for jdk9.
>>>>>>>>>
>>>>>>>>>     This is request to deprecate the obsolete flags inside
>>>>>>>>> InputEvent.
>>>>>>>>>     This constants were marked as obsolete in jdk1.4 and were
>>>>>>>>> replaced
>>>>>>>>>     by the new one. In jdk1.4 the documentation were update with
>>>>>>>>> notion
>>>>>>>>>     that the new constants should be used. And this bug is about
>>>>>>>>>     official deprecation of them.
>>>>>>>>>
>>>>>>>>>     We can replace old constants by the new one in the whole jdk,
>>>>>>>>> but I
>>>>>>>>>     updated only the code in InputEvent to make change smaller and
>>>>>>>>>     safer. So at least the new code in jdk and the code in
>>>>>>>>> applications
>>>>>>>>>     will start to use the new constants.
>>>>>>>>>
>>>>>>>>>     The changes in jconsole are necessary to fix deprecation
>>>>>>>>> warning.
>>>>>>>>>
>>>>>>>>>     jprt build passed, no new issues were found by jck/jtreg
>>>>>>>>> tests.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>>>>>>>>     Webrev can be found at:
>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>>>>>>>> <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>>>>>>>>
>>>>>>>>>     --
>>>>>>>>>     Best regards, Sergey.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From linktheprogrammer at gmail.com  Sun Oct 16 00:44:25 2016
From: linktheprogrammer at gmail.com (Link TheProgrammer)
Date: Sat, 15 Oct 2016 20:44:25 -0400
Subject: <AWT Dev> AWT OpenGL context
Message-ID: <CAJZxDFdibty1GzpEjy8okYvgpN3Gk6wGL4ucuUwsNFEC4gBFOQ@mail.gmail.com>

To the developers of AWT,

I am building a framework, https://www.github.com/LinkTheProgrammer/SGL ,
and sometime in the future, I would like to support OpenGL contexts already
implemented in my framework (which is far from finished) with AWT.

There will eventually be an AWTDisplay implementation, but for the
meantime, I would like to know the details regarding how AWT handles
contexts created with java.awt.Window so that I might retrieve the context
for a Window.

What I need specifically is a brief explanation of how AWT initializes the
OpenGL context and the source file that this occurs. If this occurs outside
the main thread of a JAR application, I need to know which one. For
interacting with the context that AWT has created, that is already
satisfied, as the capabilities, as far as I can see, are software
abstractions, and LWJGL simply tries to get the version using GL function
calls directly (otherwise they fail). I can implement my own Graphics2D
using LWJGL bindings and the context provided by an AWT Window object in
order to properly create a canvas for AWT,  and will also be more efficient
than SunGraphics2D.

I know I am asking for a lot, and if I must, I will painstakingly look
through the "intermingled" mess that is AWT. I wouldn't be asking if AWT
was more straightforward.

Sincerely,

Andrew Porter


-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161015/521c47a2/attachment.html>

From vladislav.rassokhin at jetbrains.com  Mon Oct 17 12:12:51 2016
From: vladislav.rassokhin at jetbrains.com (Vladislav Rassokhin)
Date: Mon, 17 Oct 2016 15:12:51 +0300
Subject: <AWT Dev> JDK-8098530: ArrayIndexOutOfBoundsException at
	sun.awt.X11.XEvent.getFieldsAsString
In-Reply-To: <3ef6895c-a04a-0b1f-b8d8-7158a089d860@oracle.com>
References: <CAFL4mEFyhkMUQyVnwAyMXHwcTx0JpbyyBa0AfzpWfwFzjtNZEA@mail.gmail.com>
	<3ef6895c-a04a-0b1f-b8d8-7158a089d860@oracle.com>
Message-ID: <CAKXpgZfjpy=eNTLmGhGOwcjbvH5rh+PobUMMFfKvCkUu+-uWfA@mail.gmail.com>

Hi Sergey,

For me issue and patch are quite simple so can be applied without test.

I'm just end user of jre and really annoyed by this exception clogs
application logs.
It took 15 minutes year ago to find that bug and vote for it, 15 minutes
last week to fix that using grep and vim.
Unfortunately I've no spare time to learn how to create tests for openjdk,
sign CLA and do other stuff, so asked our jdk team to send patch somewhere.
Seems openjdk contributing process is quite complicated for simple fix.

Anyway I'd attach patch to issue.

On Wed, Oct 12, 2016 at 8:48 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com
> wrote:

> Is it possible to create a test for this issue?
>
> On 12.10.16 19:07, Sergey Malenkov wrote:
>
>> Hi all,
>>
>> Could you please consider the following changes to fix JDK-8098530?
>>
>> --- src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java
>> (revision f0ae41314e223bf1b97c8126ac2b0d6edb5ee99d)
>> +++ src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java
>> (revision )
>> @@ -690,7 +690,7 @@
>>                  if (type == AtomicType.TYPE_ATOM) {
>>                      pw.println("\t\tret.append(\"" + name + " = \"
>> ).append( XAtom.get(get_" + name + "()) ).append(\", \");");
>>                  } else if (name.equals("type")) {
>> -                    pw.println("\t\tret.append(\"type = \").append(
>> XlibWrapper.eventToString[get_type()] ).append(\", \");");
>> +                    pw.println("\t\tret.append(\"type = \").append(
>> XlibWrapper.getEventToString(get_type()) ).append(\", \");");
>>                  } else if (name.equals("window")){
>>                      pw.println("\t\tret.append(\"window = \" ).append(
>> getWindow(get_window()) ).append(\", \");");
>>                  } else if (type == AtomicType.TYPE_ARRAY) {
>>
>> The sun.awt.X11.XlibWrapper class provides a method, which handles such
>> errors.
>> We should not access to array directly.
>>
>> --
>> Best regards,
>> Sergey A. Malenkov
>>
>
>
> --
> Best regards, Sergey.
>



-- 
Vladislav Rassokhin
Java developer (TeamCity)
JetBrains
https://www.jetbrains.com
The Drive to Develop
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161017/dfa4917d/attachment.html>

From semyon.sadetsky at oracle.com  Mon Oct 17 18:14:36 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 17 Oct 2016 21:14:36 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
	<f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
	<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>
	<f64fd14a-c99f-6dae-0d99-b730c6afcf48@oracle.com>
	<3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com>
Message-ID: <b766f536-dbcd-3788-918e-5e99427f162b@oracle.com>

On 10/17/2016 7:35 PM, Sergey Bylokhov wrote:

> On 17.10.16 19:01, Semyon Sadetsky wrote:
>>> How it could be safe? both are a different constants which should be
>>> used in pair with different methods?
>> Then why do you add in java doc for those constants:
>>  @deprecated It is recommended that *_DOWN_MASK be used instead
>
> This recommendation was there before, since these extended masks and 
> getModifiersEx() were added and were replaces the old 
> modifiers/getModifiers().
> These are different constants which are responsible for similar, but 
> not the same behavior.
Then this explanation should be added to the javadoc deprecation note 
because currently it states that those constants can be replaced with 
the new ones. But actually they are related to different APIs and cannot 
simply substitute each other.
>
>>>> And, please, limit the length of the changed line in VMPanel.java 
>>>> to 80
>>>> chars.
>>>>>
>>>>>>>> On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
>>>>>>>>> Thanks for the comments.
>>>>>>>>> The new version:
>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.01
>>>>>>>>> The specification of Event class and InputEvent.getModifiers() 
>>>>>>>>> are
>>>>>>>>> updated.
>>>>>>>>>
>>>>>>>>> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>>>>>>>>>> Hi Sergey,
>>>>>>>>>>
>>>>>>>>>> I'm not a reviewer, but after reading the deprecation 
>>>>>>>>>> messages in
>>>>>>>>>> Event.java
>>>>>>>>>>
>>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent} class
>>>>>>>>>> and
>>>>>>>>>> its
>>>>>>>>>>     subclasses
>>>>>>>>>>     *             be used instead.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I get the impression they would read better without the 
>>>>>>>>>> redundant
>>>>>>>>>> "class" in the middle, like so.
>>>>>>>>>>
>>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent} and 
>>>>>>>>>> its
>>>>>>>>>> subclasses
>>>>>>>>>>     *             be used instead.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Kind regards,
>>>>>>>>>> Jonathan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 30 September 2016 at 16:45, Sergey Bylokhov
>>>>>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>     Hello.
>>>>>>>>>>
>>>>>>>>>>     Please review the fix for jdk9.
>>>>>>>>>>
>>>>>>>>>>     This is request to deprecate the obsolete flags inside
>>>>>>>>>> InputEvent.
>>>>>>>>>>     This constants were marked as obsolete in jdk1.4 and were
>>>>>>>>>> replaced
>>>>>>>>>>     by the new one. In jdk1.4 the documentation were update with
>>>>>>>>>> notion
>>>>>>>>>>     that the new constants should be used. And this bug is about
>>>>>>>>>>     official deprecation of them.
>>>>>>>>>>
>>>>>>>>>>     We can replace old constants by the new one in the whole 
>>>>>>>>>> jdk,
>>>>>>>>>> but I
>>>>>>>>>>     updated only the code in InputEvent to make change 
>>>>>>>>>> smaller and
>>>>>>>>>>     safer. So at least the new code in jdk and the code in
>>>>>>>>>> applications
>>>>>>>>>>     will start to use the new constants.
>>>>>>>>>>
>>>>>>>>>>     The changes in jconsole are necessary to fix deprecation
>>>>>>>>>> warning.
>>>>>>>>>>
>>>>>>>>>>     jprt build passed, no new issues were found by jck/jtreg
>>>>>>>>>> tests.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>>>>>>>>>     Webrev can be found at:
>>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>>>>>>>>> <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>>>>>>>>>
>>>>>>>>>>     --
>>>>>>>>>>     Best regards, Sergey.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Mon Oct 17 18:23:22 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 17 Oct 2016 21:23:22 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <b766f536-dbcd-3788-918e-5e99427f162b@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
	<f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
	<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>
	<f64fd14a-c99f-6dae-0d99-b730c6afcf48@oracle.com>
	<3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com>
	<b766f536-dbcd-3788-918e-5e99427f162b@oracle.com>
Message-ID: <0e185822-ff1b-2041-baca-d5491ce2e4b8@oracle.com>

On 17.10.16 21:14, Semyon Sadetsky wrote:
> Then this explanation should be added to the javadoc deprecation note
> because currently it states that those constants can be replaced with
> the new ones. But actually they are related to different APIs and cannot
> simply substitute each other.

It can be replaced if it will be used in pair with getModifiersEx(). The 
old getModifiers() is also deprecated. And javadoc for getModifiersEx() 
describes what and how constants should be used.

>>
>>>>> And, please, limit the length of the changed line in VMPanel.java
>>>>> to 80
>>>>> chars.
>>>>>>
>>>>>>>>> On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
>>>>>>>>>> Thanks for the comments.
>>>>>>>>>> The new version:
>>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.01
>>>>>>>>>> The specification of Event class and InputEvent.getModifiers()
>>>>>>>>>> are
>>>>>>>>>> updated.
>>>>>>>>>>
>>>>>>>>>> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>>>>>>>>>>> Hi Sergey,
>>>>>>>>>>>
>>>>>>>>>>> I'm not a reviewer, but after reading the deprecation
>>>>>>>>>>> messages in
>>>>>>>>>>> Event.java
>>>>>>>>>>>
>>>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent} class
>>>>>>>>>>> and
>>>>>>>>>>> its
>>>>>>>>>>>     subclasses
>>>>>>>>>>>     *             be used instead.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I get the impression they would read better without the
>>>>>>>>>>> redundant
>>>>>>>>>>> "class" in the middle, like so.
>>>>>>>>>>>
>>>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent} and
>>>>>>>>>>> its
>>>>>>>>>>> subclasses
>>>>>>>>>>>     *             be used instead.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Kind regards,
>>>>>>>>>>> Jonathan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 30 September 2016 at 16:45, Sergey Bylokhov
>>>>>>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>     Hello.
>>>>>>>>>>>
>>>>>>>>>>>     Please review the fix for jdk9.
>>>>>>>>>>>
>>>>>>>>>>>     This is request to deprecate the obsolete flags inside
>>>>>>>>>>> InputEvent.
>>>>>>>>>>>     This constants were marked as obsolete in jdk1.4 and were
>>>>>>>>>>> replaced
>>>>>>>>>>>     by the new one. In jdk1.4 the documentation were update with
>>>>>>>>>>> notion
>>>>>>>>>>>     that the new constants should be used. And this bug is about
>>>>>>>>>>>     official deprecation of them.
>>>>>>>>>>>
>>>>>>>>>>>     We can replace old constants by the new one in the whole
>>>>>>>>>>> jdk,
>>>>>>>>>>> but I
>>>>>>>>>>>     updated only the code in InputEvent to make change
>>>>>>>>>>> smaller and
>>>>>>>>>>>     safer. So at least the new code in jdk and the code in
>>>>>>>>>>> applications
>>>>>>>>>>>     will start to use the new constants.
>>>>>>>>>>>
>>>>>>>>>>>     The changes in jconsole are necessary to fix deprecation
>>>>>>>>>>> warning.
>>>>>>>>>>>
>>>>>>>>>>>     jprt build passed, no new issues were found by jck/jtreg
>>>>>>>>>>> tests.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>>>>>>>>>>     Webrev can be found at:
>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>>>>>>>>>> <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>>>>>>>>>>
>>>>>>>>>>>     --
>>>>>>>>>>>     Best regards, Sergey.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Mon Oct 17 18:47:35 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 17 Oct 2016 21:47:35 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <0e185822-ff1b-2041-baca-d5491ce2e4b8@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
	<f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
	<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>
	<f64fd14a-c99f-6dae-0d99-b730c6afcf48@oracle.com>
	<3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com>
	<b766f536-dbcd-3788-918e-5e99427f162b@oracle.com>
	<0e185822-ff1b-2041-baca-d5491ce2e4b8@oracle.com>
Message-ID: <aaa011cc-6fe5-e7fe-ae03-b7cc1c017c39@oracle.com>



On 10/17/2016 9:23 PM, Sergey Bylokhov wrote:
> On 17.10.16 21:14, Semyon Sadetsky wrote:
>> Then this explanation should be added to the javadoc deprecation note
>> because currently it states that those constants can be replaced with
>> the new ones. But actually they are related to different APIs and cannot
>> simply substitute each other.
>
> It can be replaced if it will be used in pair with getModifiersEx(). 
> The old getModifiers() is also deprecated. And javadoc for 
> getModifiersEx() describes what and how constants should be used.
Can you add link to getModifiersEx() to all those constants' specs?
>
>>>
>>>>>> And, please, limit the length of the changed line in VMPanel.java
>>>>>> to 80
>>>>>> chars.
>>>>>>>
>>>>>>>>>> On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
>>>>>>>>>>> Thanks for the comments.
>>>>>>>>>>> The new version:
>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.01
>>>>>>>>>>> The specification of Event class and InputEvent.getModifiers()
>>>>>>>>>>> are
>>>>>>>>>>> updated.
>>>>>>>>>>>
>>>>>>>>>>> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>>>>>>>>>>>> Hi Sergey,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not a reviewer, but after reading the deprecation
>>>>>>>>>>>> messages in
>>>>>>>>>>>> Event.java
>>>>>>>>>>>>
>>>>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent} 
>>>>>>>>>>>> class
>>>>>>>>>>>> and
>>>>>>>>>>>> its
>>>>>>>>>>>>     subclasses
>>>>>>>>>>>>     *             be used instead.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I get the impression they would read better without the
>>>>>>>>>>>> redundant
>>>>>>>>>>>> "class" in the middle, like so.
>>>>>>>>>>>>
>>>>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent} and
>>>>>>>>>>>> its
>>>>>>>>>>>> subclasses
>>>>>>>>>>>>     *             be used instead.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 30 September 2016 at 16:45, Sergey Bylokhov
>>>>>>>>>>>> <Sergey.Bylokhov at oracle.com 
>>>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>     Hello.
>>>>>>>>>>>>
>>>>>>>>>>>>     Please review the fix for jdk9.
>>>>>>>>>>>>
>>>>>>>>>>>>     This is request to deprecate the obsolete flags inside
>>>>>>>>>>>> InputEvent.
>>>>>>>>>>>>     This constants were marked as obsolete in jdk1.4 and were
>>>>>>>>>>>> replaced
>>>>>>>>>>>>     by the new one. In jdk1.4 the documentation were update 
>>>>>>>>>>>> with
>>>>>>>>>>>> notion
>>>>>>>>>>>>     that the new constants should be used. And this bug is 
>>>>>>>>>>>> about
>>>>>>>>>>>>     official deprecation of them.
>>>>>>>>>>>>
>>>>>>>>>>>>     We can replace old constants by the new one in the whole
>>>>>>>>>>>> jdk,
>>>>>>>>>>>> but I
>>>>>>>>>>>>     updated only the code in InputEvent to make change
>>>>>>>>>>>> smaller and
>>>>>>>>>>>>     safer. So at least the new code in jdk and the code in
>>>>>>>>>>>> applications
>>>>>>>>>>>>     will start to use the new constants.
>>>>>>>>>>>>
>>>>>>>>>>>>     The changes in jconsole are necessary to fix deprecation
>>>>>>>>>>>> warning.
>>>>>>>>>>>>
>>>>>>>>>>>>     jprt build passed, no new issues were found by jck/jtreg
>>>>>>>>>>>> tests.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>>>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>>>>>>>>>>>     Webrev can be found at:
>>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>>>>>>>>>>> <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>>>>>>>>>>>
>>>>>>>>>>>>     --
>>>>>>>>>>>>     Best regards, Sergey.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Mon Oct 17 18:53:01 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 17 Oct 2016 21:53:01 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <aaa011cc-6fe5-e7fe-ae03-b7cc1c017c39@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
	<f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
	<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>
	<f64fd14a-c99f-6dae-0d99-b730c6afcf48@oracle.com>
	<3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com>
	<b766f536-dbcd-3788-918e-5e99427f162b@oracle.com>
	<0e185822-ff1b-2041-baca-d5491ce2e4b8@oracle.com>
	<aaa011cc-6fe5-e7fe-ae03-b7cc1c017c39@oracle.com>
Message-ID: <5888a670-6fc3-764c-c3cf-6703744b0d27@oracle.com>

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

I assume you mean the new _DOWN constants not the old?

>>
>>>>
>>>>>>> And, please, limit the length of the changed line in VMPanel.java
>>>>>>> to 80
>>>>>>> chars.
>>>>>>>>
>>>>>>>>>>> On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>> Thanks for the comments.
>>>>>>>>>>>> The new version:
>>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.01
>>>>>>>>>>>> The specification of Event class and InputEvent.getModifiers()
>>>>>>>>>>>> are
>>>>>>>>>>>> updated.
>>>>>>>>>>>>
>>>>>>>>>>>> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>>>>>>>>>>>>> Hi Sergey,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm not a reviewer, but after reading the deprecation
>>>>>>>>>>>>> messages in
>>>>>>>>>>>>> Event.java
>>>>>>>>>>>>>
>>>>>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent}
>>>>>>>>>>>>> class
>>>>>>>>>>>>> and
>>>>>>>>>>>>> its
>>>>>>>>>>>>>     subclasses
>>>>>>>>>>>>>     *             be used instead.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I get the impression they would read better without the
>>>>>>>>>>>>> redundant
>>>>>>>>>>>>> "class" in the middle, like so.
>>>>>>>>>>>>>
>>>>>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent} and
>>>>>>>>>>>>> its
>>>>>>>>>>>>> subclasses
>>>>>>>>>>>>>     *             be used instead.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 30 September 2016 at 16:45, Sergey Bylokhov
>>>>>>>>>>>>> <Sergey.Bylokhov at oracle.com
>>>>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>     Hello.
>>>>>>>>>>>>>
>>>>>>>>>>>>>     Please review the fix for jdk9.
>>>>>>>>>>>>>
>>>>>>>>>>>>>     This is request to deprecate the obsolete flags inside
>>>>>>>>>>>>> InputEvent.
>>>>>>>>>>>>>     This constants were marked as obsolete in jdk1.4 and were
>>>>>>>>>>>>> replaced
>>>>>>>>>>>>>     by the new one. In jdk1.4 the documentation were update
>>>>>>>>>>>>> with
>>>>>>>>>>>>> notion
>>>>>>>>>>>>>     that the new constants should be used. And this bug is
>>>>>>>>>>>>> about
>>>>>>>>>>>>>     official deprecation of them.
>>>>>>>>>>>>>
>>>>>>>>>>>>>     We can replace old constants by the new one in the whole
>>>>>>>>>>>>> jdk,
>>>>>>>>>>>>> but I
>>>>>>>>>>>>>     updated only the code in InputEvent to make change
>>>>>>>>>>>>> smaller and
>>>>>>>>>>>>>     safer. So at least the new code in jdk and the code in
>>>>>>>>>>>>> applications
>>>>>>>>>>>>>     will start to use the new constants.
>>>>>>>>>>>>>
>>>>>>>>>>>>>     The changes in jconsole are necessary to fix deprecation
>>>>>>>>>>>>> warning.
>>>>>>>>>>>>>
>>>>>>>>>>>>>     jprt build passed, no new issues were found by jck/jtreg
>>>>>>>>>>>>> tests.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>>>>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>>>>>>>>>>>>     Webrev can be found at:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>>>>>>>>>>>> <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>>>>>>>>>>>>
>>>>>>>>>>>>>     --
>>>>>>>>>>>>>     Best regards, Sergey.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From alexander.zvegintsev at oracle.com  Tue Oct 18 11:13:55 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 18 Oct 2016 14:13:55 +0300
Subject: <AWT Dev> [9] Review request for 8166594:
 Taskbar.setWindowProgressValue() spec does not specify expected visual
 behavior of setWindowProgressValue()
In-Reply-To: <8c284a97-3012-dfcb-a859-9a7759ca6eeb@oracle.com>
References: <c736beb0-2893-bcdc-1010-a186ed7ef231@oracle.com>
	<a2a5db52-ed7e-718d-e8a4-c0c1d8150270@oracle.com>
	<4f22118b-4b8b-aff1-5ce8-f6b5b0216861@oracle.com>
	<8c284a97-3012-dfcb-a859-9a7759ca6eeb@oracle.com>
Message-ID: <39780e1a-8674-c8e4-08b6-7596ae8a8416@oracle.com>

Updated the "behavior is undefined" section:

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

Thanks,
Alexander.

On 10/6/16 6:14 PM, Semyon Sadetsky wrote:
> On 10/6/2016 3:38 PM, Alexander Zvegintsev wrote:
>
>> Hi Semyon,
>>
>> Yes it is, Microsoft defined some set of rules for such case[0].
>>
>> However it looks redundant and too implementation-specific(which can 
>> be changed) for me.
> I didn't mean to specify the behavior for Windows platform. It seems 
> that any desktop platform may have its own rules for this case. 
> "Unspecified  behavior" just sounds a bit like a warning to me. Maybe 
> it worth to write that this behavior is a platform specific, or don't 
> mention the scenario at all since those rules cannot be changed by JDK 
> anyway. But it is just a recommendation, the decision is up to you.
>>
>> Reformatted for 80 chars in place.
> Thanks. Looks good then.
>
> --Semyon
>>
>>
>> [0] 
>> https://msdn.microsoft.com/en-us/library/windows/desktop/dd391698(v=vs.85).aspx#How_the_Taskbar_Button_Chooses_the_Progress_Indicator_for_a_Group
>>
>>
>> On 10/6/16 9:23 AM, Semyon Sadetsky wrote:
>>> Hi Alexander,
>>>
>>> 416      * Note that the behavior is undefined when multiple windows 
>>> is grouped in the task area.
>>>
>>> Isn't the above a some kind of simplification?
>>>
>>> Could you reformat changed lines to make them following the 80 chars 
>>> maximum?
>>>
>>> --Semyon
>>>
>>>
>>> On 06.10.2016 04:56, Alexander Zvegintsev wrote:
>>>> Hello,
>>>>
>>>> please review the fix
>>>>
>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8166594/00/
>>>>
>>>> for the issue
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8166594
>>>>
>>>>
>>>> It also fixes two issues to conform the documentation:
>>>>
>>>> setting value below 0 doesn't disable progress indication
>>>>
>>>> switching from indeterminate to normal state has no effect
>>>>
>>>
>>
>


From semyon.sadetsky at oracle.com  Tue Oct 18 11:15:56 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 18 Oct 2016 14:15:56 +0300
Subject: <AWT Dev> [9] Review request for 8166594:
 Taskbar.setWindowProgressValue() spec does not specify expected visual
 behavior of setWindowProgressValue()
In-Reply-To: <39780e1a-8674-c8e4-08b6-7596ae8a8416@oracle.com>
References: <c736beb0-2893-bcdc-1010-a186ed7ef231@oracle.com>
	<a2a5db52-ed7e-718d-e8a4-c0c1d8150270@oracle.com>
	<4f22118b-4b8b-aff1-5ce8-f6b5b0216861@oracle.com>
	<8c284a97-3012-dfcb-a859-9a7759ca6eeb@oracle.com>
	<39780e1a-8674-c8e4-08b6-7596ae8a8416@oracle.com>
Message-ID: <6b24caf7-c338-99db-8426-4ffd229e1525@oracle.com>

+1

--Semyon


On 18.10.2016 14:13, Alexander Zvegintsev wrote:
> Updated the "behavior is undefined" section:
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8166594/01/
>
> Thanks,
> Alexander.
>
> On 10/6/16 6:14 PM, Semyon Sadetsky wrote:
>> On 10/6/2016 3:38 PM, Alexander Zvegintsev wrote:
>>
>>> Hi Semyon,
>>>
>>> Yes it is, Microsoft defined some set of rules for such case[0].
>>>
>>> However it looks redundant and too implementation-specific(which can 
>>> be changed) for me.
>> I didn't mean to specify the behavior for Windows platform. It seems 
>> that any desktop platform may have its own rules for this case. 
>> "Unspecified  behavior" just sounds a bit like a warning to me. Maybe 
>> it worth to write that this behavior is a platform specific, or don't 
>> mention the scenario at all since those rules cannot be changed by 
>> JDK anyway. But it is just a recommendation, the decision is up to you.
>>>
>>> Reformatted for 80 chars in place.
>> Thanks. Looks good then.
>>
>> --Semyon
>>>
>>>
>>> [0] 
>>> https://msdn.microsoft.com/en-us/library/windows/desktop/dd391698(v=vs.85).aspx#How_the_Taskbar_Button_Chooses_the_Progress_Indicator_for_a_Group
>>>
>>>
>>> On 10/6/16 9:23 AM, Semyon Sadetsky wrote:
>>>> Hi Alexander,
>>>>
>>>> 416      * Note that the behavior is undefined when multiple 
>>>> windows is grouped in the task area.
>>>>
>>>> Isn't the above a some kind of simplification?
>>>>
>>>> Could you reformat changed lines to make them following the 80 
>>>> chars maximum?
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 06.10.2016 04:56, Alexander Zvegintsev wrote:
>>>>> Hello,
>>>>>
>>>>> please review the fix
>>>>>
>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8166594/00/
>>>>>
>>>>> for the issue
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8166594
>>>>>
>>>>>
>>>>> It also fixes two issues to conform the documentation:
>>>>>
>>>>> setting value below 0 doesn't disable progress indication
>>>>>
>>>>> switching from indeterminate to normal state has no effect
>>>>>
>>>>
>>>
>>
>


From Sergey.Bylokhov at oracle.com  Tue Oct 18 11:56:41 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 18 Oct 2016 14:56:41 +0300
Subject: <AWT Dev> [9] Review request for 8166594:
 Taskbar.setWindowProgressValue() spec does not specify expected visual
 behavior of setWindowProgressValue()
In-Reply-To: <6b24caf7-c338-99db-8426-4ffd229e1525@oracle.com>
References: <c736beb0-2893-bcdc-1010-a186ed7ef231@oracle.com>
	<a2a5db52-ed7e-718d-e8a4-c0c1d8150270@oracle.com>
	<4f22118b-4b8b-aff1-5ce8-f6b5b0216861@oracle.com>
	<8c284a97-3012-dfcb-a859-9a7759ca6eeb@oracle.com>
	<39780e1a-8674-c8e4-08b6-7596ae8a8416@oracle.com>
	<6b24caf7-c338-99db-8426-4ffd229e1525@oracle.com>
Message-ID: <e10e077b-7ef4-d64e-cbe5-bdb6e8d105a6@oracle.com>

+1
I also suggest to file a bug to specify "null" behavior for the new 
methods. In some cases we already do this, in some not.

On 18.10.16 14:15, Semyon Sadetsky wrote:
> +1
>
> --Semyon
>
>
> On 18.10.2016 14:13, Alexander Zvegintsev wrote:
>> Updated the "behavior is undefined" section:
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8166594/01/
>>
>> Thanks,
>> Alexander.
>>
>> On 10/6/16 6:14 PM, Semyon Sadetsky wrote:
>>> On 10/6/2016 3:38 PM, Alexander Zvegintsev wrote:
>>>
>>>> Hi Semyon,
>>>>
>>>> Yes it is, Microsoft defined some set of rules for such case[0].
>>>>
>>>> However it looks redundant and too implementation-specific(which can
>>>> be changed) for me.
>>> I didn't mean to specify the behavior for Windows platform. It seems
>>> that any desktop platform may have its own rules for this case.
>>> "Unspecified  behavior" just sounds a bit like a warning to me. Maybe
>>> it worth to write that this behavior is a platform specific, or don't
>>> mention the scenario at all since those rules cannot be changed by
>>> JDK anyway. But it is just a recommendation, the decision is up to you.
>>>>
>>>> Reformatted for 80 chars in place.
>>> Thanks. Looks good then.
>>>
>>> --Semyon
>>>>
>>>>
>>>> [0]
>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/dd391698(v=vs.85).aspx#How_the_Taskbar_Button_Chooses_the_Progress_Indicator_for_a_Group
>>>>
>>>>
>>>>
>>>> On 10/6/16 9:23 AM, Semyon Sadetsky wrote:
>>>>> Hi Alexander,
>>>>>
>>>>> 416      * Note that the behavior is undefined when multiple
>>>>> windows is grouped in the task area.
>>>>>
>>>>> Isn't the above a some kind of simplification?
>>>>>
>>>>> Could you reformat changed lines to make them following the 80
>>>>> chars maximum?
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 06.10.2016 04:56, Alexander Zvegintsev wrote:
>>>>>> Hello,
>>>>>>
>>>>>> please review the fix
>>>>>>
>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8166594/00/
>>>>>>
>>>>>> for the issue
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8166594
>>>>>>
>>>>>>
>>>>>> It also fixes two issues to conform the documentation:
>>>>>>
>>>>>> setting value below 0 doesn't disable progress indication
>>>>>>
>>>>>> switching from indeterminate to normal state has no effect
>>>>>>
>>>>>
>>>>
>>>
>>
>


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Tue Oct 18 13:46:12 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 18 Oct 2016 16:46:12 +0300
Subject: <AWT Dev> [9] Review request for 8167652: Making a frame/dialog
 resizeble/unresizeble shifts its position on Unity.
Message-ID: <242ce147-4ff9-68c1-e5c7-278e1215fcda@oracle.com>

Hello,

Please review fix for JDK9:

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

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

In Linux, when a frame or dilalog is made resizable or non-resizable the 
window decoration need to be updated. For that purpose window is 
unmapped and mapped again and WM changes the window decoration parent. 
The re-parenting may cause WM to send intermediate "artifact events" 
which change the window location on the screen, this WM behavior is 
undocumented. To avoid window move the window shift is compensated in 
XWM.setShellResizable()/XWM.setShellNotResizable(), but Unity WM shifts 
the window position in different way. In the proposed solution the 
window shift compensation is adjusted for Unity WM.

Also in the fix all writes to the fields that store the current state of 
window dimensions are protected with the AWT lock. This is necessary to 
avoid unexpected window move or resize when the window dimensions are 
changed from the user thread concurrently while the AWT toolkit thread 
handles WM sent notifications affecting the current window state, size, 
position, insets, etc.

--Semyon


From andrey.rusakov at oracle.com  Tue Oct 18 17:28:19 2016
From: andrey.rusakov at oracle.com (Andrey Rusakov)
Date: Tue, 18 Oct 2016 20:28:19 +0300
Subject: <AWT Dev> [9] Review request: 8167155 [PIT] failure and a test
 bug in MultiResolutionTrayIconTest.java
In-Reply-To: <6ad64aab-1c6c-6e3c-ce61-bd1f1dfa987a@oracle.com>
References: <978aecfb-eaed-d8d4-377a-8aed22fdd2b2@oracle.com>
	<6ad64aab-1c6c-6e3c-ce61-bd1f1dfa987a@oracle.com>
Message-ID: <98b960da-6b40-5f42-4f75-cd1174425827@oracle.com>

Looks like there is no other test bug. Checked configurations:
latest MacOS with HiDPI, 9b140 (green rectangle is shown)
Ubuntu 16.10, same machine, booting from flash drive. But I can try with 
KDE or some other DE with HiDPI support.


14.10.2016 20:34, Phil Race ?????:
> > This fix resolves issue which caused test to pass even if "fail" 
> button was clicked and adds jtreg platform filter.
>
> But what about the issue that (as I read it) the test does actually fail ?
>
> > The test fails adding not blue (as requested) but red icon to a tray.
>
> The test bug was secondary ..
>
> -phil.
>
> On 10/14/2016 09:02 AM, Andrey Rusakov wrote:
>> Hello,
>>
>> please review the fix
>>
>> http://cr.openjdk.java.net/~arusakov/8167155/webrev.00
>>
>> for the issue
>>
>> https://bugs.openjdk.java.net/browse/JDK-8167155
>>
>> This fix resolves issue which caused test to pass even if "fail" button was clicked and adds jtreg platform filter.
>>
>

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

From philip.race at oracle.com  Tue Oct 18 17:37:33 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 18 Oct 2016 10:37:33 -0700
Subject: <AWT Dev> [9] Review request: 8167155 [PIT] failure and a test
 bug in MultiResolutionTrayIconTest.java
In-Reply-To: <98b960da-6b40-5f42-4f75-cd1174425827@oracle.com>
References: <978aecfb-eaed-d8d4-377a-8aed22fdd2b2@oracle.com>
	<6ad64aab-1c6c-6e3c-ce61-bd1f1dfa987a@oracle.com>
	<98b960da-6b40-5f42-4f75-cd1174425827@oracle.com>
Message-ID: <ea1492e7-7c65-1739-99f2-153e96c653a2@oracle.com>

I didn't mean a bug in the test. I meant it reads to me like there was a 
product bug
found by the test except the test wasn't reporting it correctly.

If you say otherwise that is fine .. but you might want to check with 
the submitter of
the bug first.

-phil.

On 10/18/2016 10:28 AM, Andrey Rusakov wrote:
>
> Looks like there is no other test bug. Checked configurations:
> latest MacOS with HiDPI, 9b140 (green rectangle is shown)
> Ubuntu 16.10, same machine, booting from flash drive. But I can try 
> with KDE or some other DE with HiDPI support.
>
>
> 14.10.2016 20:34, Phil Race ?????:
>> > This fix resolves issue which caused test to pass even if "fail" 
>> button was clicked and adds jtreg platform filter.
>>
>> But what about the issue that (as I read it) the test does actually 
>> fail ?
>>
>> > The test fails adding not blue (as requested) but red icon to a tray.
>>
>> The test bug was secondary ..
>>
>> -phil.
>>
>> On 10/14/2016 09:02 AM, Andrey Rusakov wrote:
>>> Hello,
>>>
>>> please review the fix
>>>
>>> http://cr.openjdk.java.net/~arusakov/8167155/webrev.00
>>>
>>> for the issue
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8167155
>>>
>>> This fix resolves issue which caused test to pass even if "fail" button was clicked and adds jtreg platform filter.
>>>
>>
>

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

From semyon.sadetsky at oracle.com  Wed Oct 19 06:58:11 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 19 Oct 2016 09:58:11 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <5888a670-6fc3-764c-c3cf-6703744b0d27@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
	<f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
	<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>
	<f64fd14a-c99f-6dae-0d99-b730c6afcf48@oracle.com>
	<3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com>
	<b766f536-dbcd-3788-918e-5e99427f162b@oracle.com>
	<0e185822-ff1b-2041-baca-d5491ce2e4b8@oracle.com>
	<aaa011cc-6fe5-e7fe-ae03-b7cc1c017c39@oracle.com>
	<5888a670-6fc3-764c-c3cf-6703744b0d27@oracle.com>
Message-ID: <5bda0f8a-5dfb-7356-5942-015fc27d6b07@oracle.com>

On 10/17/2016 9:53 PM, Sergey Bylokhov wrote:

> On 17.10.16 21:47, Semyon Sadetsky wrote:
>>> It can be replaced if it will be used in pair with getModifiersEx().
>>> The old getModifiers() is also deprecated. And javadoc for
>>> getModifiersEx() describes what and how constants should be used.
>> Can you add link to getModifiersEx() to all those constants' specs?
>
> I assume you mean the new _DOWN constants not the old?
I meant that deprecated message should be transparently explaining the 
impact of the replacement.
The proposed specs change recommends to use a replacement which is not 
equivalent to the deprecated API. And that is the reason why you don't 
like to eliminate all old API usages in the JDK code as a part of the 
fix, if I correctly understand you previous reply in this thread.
Since you are insisting that migrating to the new API is risky it is 
worth let the user know about that risk as well.
>
>>>
>>>>>
>>>>>>>> And, please, limit the length of the changed line in VMPanel.java
>>>>>>>> to 80
>>>>>>>> chars.
>>>>>>>>>
>>>>>>>>>>>> On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>>> Thanks for the comments.
>>>>>>>>>>>>> The new version:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.01
>>>>>>>>>>>>> The specification of Event class and 
>>>>>>>>>>>>> InputEvent.getModifiers()
>>>>>>>>>>>>> are
>>>>>>>>>>>>> updated.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>>>>>>>>>>>>>> Hi Sergey,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm not a reviewer, but after reading the deprecation
>>>>>>>>>>>>>> messages in
>>>>>>>>>>>>>> Event.java
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent}
>>>>>>>>>>>>>> class
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>     subclasses
>>>>>>>>>>>>>>     *             be used instead.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I get the impression they would read better without the
>>>>>>>>>>>>>> redundant
>>>>>>>>>>>>>> "class" in the middle, like so.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent} 
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> its
>>>>>>>>>>>>>> subclasses
>>>>>>>>>>>>>>     *             be used instead.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 30 September 2016 at 16:45, Sergey Bylokhov
>>>>>>>>>>>>>> <Sergey.Bylokhov at oracle.com
>>>>>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     Hello.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     Please review the fix for jdk9.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     This is request to deprecate the obsolete flags inside
>>>>>>>>>>>>>> InputEvent.
>>>>>>>>>>>>>>     This constants were marked as obsolete in jdk1.4 and 
>>>>>>>>>>>>>> were
>>>>>>>>>>>>>> replaced
>>>>>>>>>>>>>>     by the new one. In jdk1.4 the documentation were update
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> notion
>>>>>>>>>>>>>>     that the new constants should be used. And this bug is
>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>     official deprecation of them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     We can replace old constants by the new one in the whole
>>>>>>>>>>>>>> jdk,
>>>>>>>>>>>>>> but I
>>>>>>>>>>>>>>     updated only the code in InputEvent to make change
>>>>>>>>>>>>>> smaller and
>>>>>>>>>>>>>>     safer. So at least the new code in jdk and the code in
>>>>>>>>>>>>>> applications
>>>>>>>>>>>>>>     will start to use the new constants.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     The changes in jconsole are necessary to fix deprecation
>>>>>>>>>>>>>> warning.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     jprt build passed, no new issues were found by jck/jtreg
>>>>>>>>>>>>>> tests.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>>>>>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>>>>>>>>>>>>>     Webrev can be found at:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>>>>>>>>>>>>> <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     --
>>>>>>>>>>>>>>     Best regards, Sergey.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Wed Oct 19 14:43:39 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Oct 2016 17:43:39 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <5bda0f8a-5dfb-7356-5942-015fc27d6b07@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
	<f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
	<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>
	<f64fd14a-c99f-6dae-0d99-b730c6afcf48@oracle.com>
	<3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com>
	<b766f536-dbcd-3788-918e-5e99427f162b@oracle.com>
	<0e185822-ff1b-2041-baca-d5491ce2e4b8@oracle.com>
	<aaa011cc-6fe5-e7fe-ae03-b7cc1c017c39@oracle.com>
	<5888a670-6fc3-764c-c3cf-6703744b0d27@oracle.com>
	<5bda0f8a-5dfb-7356-5942-015fc27d6b07@oracle.com>
Message-ID: <255c4e87-b58c-1d4d-30ca-97d1d9a710d0@oracle.com>

On 19.10.16 9:58, Semyon Sadetsky wrote:
>> On 17.10.16 21:47, Semyon Sadetsky wrote:
>>>> It can be replaced if it will be used in pair with getModifiersEx().
>>>> The old getModifiers() is also deprecated. And javadoc for
>>>> getModifiersEx() describes what and how constants should be used.
>>> Can you add link to getModifiersEx() to all those constants' specs?
>>
>> I assume you mean the new _DOWN constants not the old?
> I meant that deprecated message should be transparently explaining the
> impact of the replacement.
> The proposed specs change recommends to use a replacement which is not
> equivalent to the deprecated API. And that is the reason why you don't
> like to eliminate all old API usages in the JDK code as a part of the
> fix, if I correctly understand you previous reply in this thread.
> Since you are insisting that migrating to the new API is risky it is
> worth let the user know about that risk as well.

What does it mean risky? The new API is safe, but it is not safe to just 
find+replace the old constants to the new one, because it will be 
necessary to check how they are used. We already have a notions that 
these "extended modifier constant" should be used in the constructor of 
InputEvent and moreover in spec of getModifiersEx() we have an 
additional examples how to use this constants. This is why we will have 
a reference from old constans to the new, and from getModifiers() to the 
getModifiersEx();

>>>>>>>>> And, please, limit the length of the changed line in VMPanel.java
>>>>>>>>> to 80
>>>>>>>>> chars.
>>>>>>>>>>
>>>>>>>>>>>>> On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>>>> Thanks for the comments.
>>>>>>>>>>>>>> The new version:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.01
>>>>>>>>>>>>>> The specification of Event class and
>>>>>>>>>>>>>> InputEvent.getModifiers()
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>> updated.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>>>>>>>>>>>>>>> Hi Sergey,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm not a reviewer, but after reading the deprecation
>>>>>>>>>>>>>>> messages in
>>>>>>>>>>>>>>> Event.java
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent}
>>>>>>>>>>>>>>> class
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>     subclasses
>>>>>>>>>>>>>>>     *             be used instead.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I get the impression they would read better without the
>>>>>>>>>>>>>>> redundant
>>>>>>>>>>>>>>> "class" in the middle, like so.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent}
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>> subclasses
>>>>>>>>>>>>>>>     *             be used instead.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 30 September 2016 at 16:45, Sergey Bylokhov
>>>>>>>>>>>>>>> <Sergey.Bylokhov at oracle.com
>>>>>>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     Hello.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     Please review the fix for jdk9.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     This is request to deprecate the obsolete flags inside
>>>>>>>>>>>>>>> InputEvent.
>>>>>>>>>>>>>>>     This constants were marked as obsolete in jdk1.4 and
>>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>> replaced
>>>>>>>>>>>>>>>     by the new one. In jdk1.4 the documentation were update
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> notion
>>>>>>>>>>>>>>>     that the new constants should be used. And this bug is
>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>     official deprecation of them.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     We can replace old constants by the new one in the whole
>>>>>>>>>>>>>>> jdk,
>>>>>>>>>>>>>>> but I
>>>>>>>>>>>>>>>     updated only the code in InputEvent to make change
>>>>>>>>>>>>>>> smaller and
>>>>>>>>>>>>>>>     safer. So at least the new code in jdk and the code in
>>>>>>>>>>>>>>> applications
>>>>>>>>>>>>>>>     will start to use the new constants.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     The changes in jconsole are necessary to fix deprecation
>>>>>>>>>>>>>>> warning.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     jprt build passed, no new issues were found by jck/jtreg
>>>>>>>>>>>>>>> tests.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>>>>>>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>>>>>>>>>>>>>>     Webrev can be found at:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     --
>>>>>>>>>>>>>>>     Best regards, Sergey.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Oct 19 14:56:44 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Oct 2016 17:56:44 +0300
Subject: <AWT Dev> AWT OpenGL context
In-Reply-To: <CAJZxDFdibty1GzpEjy8okYvgpN3Gk6wGL4ucuUwsNFEC4gBFOQ@mail.gmail.com>
References: <CAJZxDFdibty1GzpEjy8okYvgpN3Gk6wGL4ucuUwsNFEC4gBFOQ@mail.gmail.com>
Message-ID: <61c1ee3d-87c9-a753-ca89-1b219f6929cf@oracle.com>

Hi,

On 16.10.16 3:44, Link TheProgrammer wrote:
> To the developers of AWT,
> >
> There will eventually be an AWTDisplay implementation, but for the
> meantime, I would like to know the details regarding how AWT handles
> contexts created with java.awt.Window so that I might retrieve the
> context for a Window.
>
> What I need specifically is a brief explanation of how AWT initializes
> the OpenGL context and the source file that this occurs. If this occurs
> outside the main thread of a JAR application, I need to know which one.

This is mostly related to Java2D and you can start from the OGLContext 
class(which is created in a different implementations of 
OGLGraphicsConfig = WGLGraphicsConfig/GLXGraphicsConfig/CGLGraphicsConfig)
When Java2D uses OpenGL pipeline then the special OGLRenderQueue thread 
is created. So when you try to draw something to the window or to the 
VolatileImage the actual commands will be placed to the special buffer. 
Some time later these commands are executed in the native code(see 
OGLRenderQueue.c)
The list of commands located in  sun.java2d.pipe.BufferedOpCodes class. 
Note that each of them have a different parameters.

Note that by default OGL pipeline is enabled on OSX only.

> For interacting with the context that AWT has created, that is already
> satisfied, as the capabilities, as far as I can see, are software
> abstractions, and LWJGL simply tries to get the version using GL
> function calls directly (otherwise they fail). I can implement my own
> Graphics2D using LWJGL bindings and the context provided by an AWT
> Window object in order to properly create a canvas for AWT,  and will
> also be more efficient than SunGraphics2D.
>
> I know I am asking for a lot, and if I must, I will painstakingly look
> through the "intermingled" mess that is AWT. I wouldn't be asking if AWT
> was more straightforward.
>
> Sincerely,
>
> Andrew Porter
>
>
> --
> Sent from Gmail Mobile


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Oct 19 15:26:11 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Oct 2016 18:26:11 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <a8f9bacb-f26b-0902-334b-ca403b864b3f@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
	<04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
	<911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>
	<07ce3934-96fb-dc64-99df-995e5a0ca28a@oracle.com>
	<d88f1d0b-d467-324b-6237-84eeec50046e@oracle.com>
	<38787b3b-1356-977f-ca23-c6e728d3ceda@oracle.com>
	<29f01520-99b0-7438-02a5-51cc248be29d@oracle.com>
	<f45beddd-f4be-ac91-aeee-34786853021f@oracle.com>
	<a43d3eba-5d13-48de-0f83-2efa664da2a3@oracle.com>
	<8c7239fe-51c8-c8f4-84b2-87e16295761d@oracle.com>
	<f4a857cc-ebd4-8c65-fd3c-ff9adf4389f3@oracle.com>
	<fb98b819-4ace-170c-e128-68c6d50b167a@oracle.com>
	<1baec804-931e-f85f-614d-49e79960e472@oracle.com>
	<8e556458-1d5d-6fab-3528-ece33f050df6@oracle.com>
	<a8f9bacb-f26b-0902-334b-ca403b864b3f@oracle.com>
Message-ID: <1dd8b948-fd63-8b42-da08-b81e7e026a4a@oracle.com>

On 17.10.16 10:35, Semyon Sadetsky wrote:
>> It should not be closed as not a bug, the location of the popus should
>> be recalculated based on the GC size.
> As I already explain to you it should be a separate bug. GC is assumed
> to be changed when window is moved to another screen but this doesn't
> happen on Linux. It was initially designed this way.
> This current bug is a regression fix. It just reverts the way it has
> been always working.

The code which you tried to revert if not correct. The previous change 
was done as a fix for HiDPI support. Lots of our code depends from the 
XWindow.scaleUp/scaleDown/getScale which ware implemented on top of 
graphicsConfig. If it was not updated then this is a serious bug.

I filed a separate bug to fix Toolkit.getScreenSize() on unix.
https://bugs.openjdk.java.net/browse/JDK-816830

-- 
Best regards, Sergey.

From alexander.v.stepanov at oracle.com  Wed Oct 19 16:33:59 2016
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Wed, 19 Oct 2016 19:33:59 +0300
Subject: <AWT Dev> [9] RFR for 8159454: [TEST_BUG]
 javax/swing/ToolTipManager/7123767/bug7123767.java: number of checked
 graphics configurations should be limited
Message-ID: <3836cafd-4759-f993-1ddd-f1da66839e29@oracle.com>

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8159454/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8159454 ?

Thanks,
Alexander


From Sergey.Bylokhov at oracle.com  Wed Oct 19 16:43:18 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Oct 2016 19:43:18 +0300
Subject: <AWT Dev> [9] RFR for 8159454: [TEST_BUG]
 javax/swing/ToolTipManager/7123767/bug7123767.java: number of checked
 graphics configurations should be limited
In-Reply-To: <3836cafd-4759-f993-1ddd-f1da66839e29@oracle.com>
References: <3836cafd-4759-f993-1ddd-f1da66839e29@oracle.com>
Message-ID: <49728f31-f26b-316f-1394-a4744749a2f2@oracle.com>

Hi, Alexander
It will be good if the test always validate default GC per device.

On 19.10.16 19:33, Alexander Stepanov wrote:
> Hello,
>
> Could you please review the following fix
> http://cr.openjdk.java.net/~avstepan/8159454/webrev.00/
> for
> https://bugs.openjdk.java.net/browse/JDK-8159454 ?
>
> Thanks,
> Alexander
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Oct 19 17:38:54 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Oct 2016 20:38:54 +0300
Subject: <AWT Dev> [9] Review request for 8167652: Making a frame/dialog
 resizeble/unresizeble shifts its position on Unity.
In-Reply-To: <242ce147-4ff9-68c1-e5c7-278e1215fcda@oracle.com>
References: <242ce147-4ff9-68c1-e5c7-278e1215fcda@oracle.com>
Message-ID: <2113be8e-f17e-ef55-27f8-de3d9c525b93@oracle.com>

Hi, Semyon.
A few notes.
  - The awtLock is a lowlevel lock which should be used only when we 
access the xlib and some other native resource like opengl. We should 
not call the users code on it. In the fix the code in 
XDecoratedPeer.updateMinimumSize() will call the users code.
  - Some of the changed methods are called already under this lock, for 
example XDecoratedPeer.handlePropertyNotify(), and probably others.

On 18.10.16 16:46, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8167652
>
> webrev: http://cr.openjdk.java.net/~ssadetsky/8167652/webrev.00/
>
> In Linux, when a frame or dilalog is made resizable or non-resizable the
> window decoration need to be updated. For that purpose window is
> unmapped and mapped again and WM changes the window decoration parent.
> The re-parenting may cause WM to send intermediate "artifact events"
> which change the window location on the screen, this WM behavior is
> undocumented. To avoid window move the window shift is compensated in
> XWM.setShellResizable()/XWM.setShellNotResizable(), but Unity WM shifts
> the window position in different way. In the proposed solution the
> window shift compensation is adjusted for Unity WM.
>
> Also in the fix all writes to the fields that store the current state of
> window dimensions are protected with the AWT lock. This is necessary to
> avoid unexpected window move or resize when the window dimensions are
> changed from the user thread concurrently while the AWT toolkit thread
> handles WM sent notifications affecting the current window state, size,
> position, insets, etc.
>
> --Semyon
>


-- 
Best regards, Sergey.

From philip.race at oracle.com  Wed Oct 19 20:14:50 2016
From: philip.race at oracle.com (Philip Race)
Date: Wed, 19 Oct 2016 13:14:50 -0700
Subject: <AWT Dev> RFR:8168316: Suppress deprecation warnings for Applet
 classes in java.desktop
Message-ID: <5807D43A.10409@oracle.com>

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

When applets were deprecated it seems that due to all deprecated
warning being suppressed in java.desktop many places that should
have been updated weren't

This resolves the applet ones .. as a precursor to fixing up the other 
issues
that cause this global supression.

-phil

From Sergey.Bylokhov at oracle.com  Wed Oct 19 21:59:28 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 20 Oct 2016 00:59:28 +0300
Subject: <AWT Dev> <Swing Dev> RFR:8168316: Suppress deprecation
 warnings for Applet classes in java.desktop
In-Reply-To: <5807D43A.10409@oracle.com>
References: <5807D43A.10409@oracle.com>
Message-ID: <d985aa0d-61e0-dd24-6cab-8922a1b58743@oracle.com>

On 19.10.16 23:14, Philip Race wrote:
> This resolves the applet ones .. as a precursor to fixing up the other
> issues
> that cause this global supression.

Probably some of related code can be deprecated as well?(like 
AppletAudioClip, AppletPanel,AppletViewer 
,RepaintManager.addDirtyRegion(), AppletInitializer etc).


-- 
Best regards, Sergey.

From philip.race at oracle.com  Wed Oct 19 22:14:10 2016
From: philip.race at oracle.com (Philip Race)
Date: Wed, 19 Oct 2016 15:14:10 -0700
Subject: <AWT Dev> <Swing Dev> RFR:8168316: Suppress deprecation
 warnings for Applet classes in java.desktop
In-Reply-To: <d985aa0d-61e0-dd24-6cab-8922a1b58743@oracle.com>
References: <5807D43A.10409@oracle.com>
	<d985aa0d-61e0-dd24-6cab-8922a1b58743@oracle.com>
Message-ID: <5807F032.8060309@oracle.com>

Well maybe but this isn't about adding deprecations it is just
about of getting rid of warnings for uses of APIs that are
already deprecated.

You are welcome to file a separate bug on that ...

-phil.

On 10/19/16, 2:59 PM, Sergey Bylokhov wrote:
> On 19.10.16 23:14, Philip Race wrote:
>> This resolves the applet ones .. as a precursor to fixing up the other
>> issues
>> that cause this global supression.
>
> Probably some of related code can be deprecated as well?(like 
> AppletAudioClip, AppletPanel,AppletViewer 
> ,RepaintManager.addDirtyRegion(), AppletInitializer etc).
>
>

From semyon.sadetsky at oracle.com  Thu Oct 20 06:36:37 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 20 Oct 2016 09:36:37 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <1dd8b948-fd63-8b42-da08-b81e7e026a4a@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
	<04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
	<911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>
	<07ce3934-96fb-dc64-99df-995e5a0ca28a@oracle.com>
	<d88f1d0b-d467-324b-6237-84eeec50046e@oracle.com>
	<38787b3b-1356-977f-ca23-c6e728d3ceda@oracle.com>
	<29f01520-99b0-7438-02a5-51cc248be29d@oracle.com>
	<f45beddd-f4be-ac91-aeee-34786853021f@oracle.com>
	<a43d3eba-5d13-48de-0f83-2efa664da2a3@oracle.com>
	<8c7239fe-51c8-c8f4-84b2-87e16295761d@oracle.com>
	<f4a857cc-ebd4-8c65-fd3c-ff9adf4389f3@oracle.com>
	<fb98b819-4ace-170c-e128-68c6d50b167a@oracle.com>
	<1baec804-931e-f85f-614d-49e79960e472@oracle.com>
	<8e556458-1d5d-6fab-3528-ece33f050df6@oracle.com>
	<a8f9bacb-f26b-0902-334b-ca403b864b3f@oracle.com>
	<1dd8b948-fd63-8b42-da08-b81e7e026a4a@oracle.com>
Message-ID: <9fe33c67-0a4e-182b-b5a7-e76025d8f914@oracle.com>



On 19.10.2016 18:26, Sergey Bylokhov wrote:
> On 17.10.16 10:35, Semyon Sadetsky wrote:
>>> It should not be closed as not a bug, the location of the popus should
>>> be recalculated based on the GC size.
>> As I already explain to you it should be a separate bug. GC is assumed
>> to be changed when window is moved to another screen but this doesn't
>> happen on Linux. It was initially designed this way.
>> This current bug is a regression fix. It just reverts the way it has
>> been always working.
>
> The code which you tried to revert if not correct. The previous change 
> was done as a fix for HiDPI support. Lots of our code depends from the 
> XWindow.scaleUp/scaleDown/getScale which ware implemented on top of 
> graphicsConfig. If it was not updated then this is a serious bug.
XWindow.scaleUp/scaleDown/getScale do not depend on screen on Linux.
>
> I filed a separate bug to fix Toolkit.getScreenSize() on unix.
> https://bugs.openjdk.java.net/browse/JDK-816830
probably you meant https://bugs.openjdk.java.net/browse/JDK-8168307

I proposed to do same to investigate the problem. Does it mean that you 
approve the current fix?

But severity of this bug is rather low because it is internal problem 
that does not affect user experience. It may be deferred to the next 
major JDK release.

Also note, that the same bug was already closed as "won't fix" before: 
https://bugs.openjdk.java.net/browse/JDK-5100801

--Semyon

From semyon.sadetsky at oracle.com  Thu Oct 20 07:04:11 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 20 Oct 2016 10:04:11 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <255c4e87-b58c-1d4d-30ca-97d1d9a710d0@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
	<f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
	<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>
	<f64fd14a-c99f-6dae-0d99-b730c6afcf48@oracle.com>
	<3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com>
	<b766f536-dbcd-3788-918e-5e99427f162b@oracle.com>
	<0e185822-ff1b-2041-baca-d5491ce2e4b8@oracle.com>
	<aaa011cc-6fe5-e7fe-ae03-b7cc1c017c39@oracle.com>
	<5888a670-6fc3-764c-c3cf-6703744b0d27@oracle.com>
	<5bda0f8a-5dfb-7356-5942-015fc27d6b07@oracle.com>
	<255c4e87-b58c-1d4d-30ca-97d1d9a710d0@oracle.com>
Message-ID: <750f4ba6-5dea-7fb0-c7c1-c207d5cd2912@oracle.com>



On 19.10.2016 17:43, Sergey Bylokhov wrote:
> On 19.10.16 9:58, Semyon Sadetsky wrote:
>>> On 17.10.16 21:47, Semyon Sadetsky wrote:
>>>>> It can be replaced if it will be used in pair with getModifiersEx().
>>>>> The old getModifiers() is also deprecated. And javadoc for
>>>>> getModifiersEx() describes what and how constants should be used.
>>>> Can you add link to getModifiersEx() to all those constants' specs?
>>>
>>> I assume you mean the new _DOWN constants not the old?
>> I meant that deprecated message should be transparently explaining the
>> impact of the replacement.
>> The proposed specs change recommends to use a replacement which is not
>> equivalent to the deprecated API. And that is the reason why you don't
>> like to eliminate all old API usages in the JDK code as a part of the
>> fix, if I correctly understand you previous reply in this thread.
>> Since you are insisting that migrating to the new API is risky it is
>> worth let the user know about that risk as well.
>
> What does it mean risky? The new API is safe, but it is not safe to 
> just find+replace the old constants to the new one, because it will be 
> necessary to check how they are used. 
The same is necessary for the user code. Look at the spec you propose:

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

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

> We already have a notions that these "extended modifier constant" 
> should be used in the constructor of InputEvent and moreover in spec 
> of getModifiersEx() we have an additional examples how to use this 
> constants. This is why we will have a reference from old constans to 
> the new, and from getModifiers() to the getModifiersEx();
>
>>>>>>>>>> And, please, limit the length of the changed line in 
>>>>>>>>>> VMPanel.java
>>>>>>>>>> to 80
>>>>>>>>>> chars.
>>>>>>>>>>>
>>>>>>>>>>>>>> On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>>>>> Thanks for the comments.
>>>>>>>>>>>>>>> The new version:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.01
>>>>>>>>>>>>>>> The specification of Event class and
>>>>>>>>>>>>>>> InputEvent.getModifiers()
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>> updated.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>>>>>>>>>>>>>>>> Hi Sergey,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm not a reviewer, but after reading the deprecation
>>>>>>>>>>>>>>>> messages in
>>>>>>>>>>>>>>>> Event.java
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent}
>>>>>>>>>>>>>>>> class
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>     subclasses
>>>>>>>>>>>>>>>>     *             be used instead.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I get the impression they would read better without the
>>>>>>>>>>>>>>>> redundant
>>>>>>>>>>>>>>>> "class" in the middle, like so.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent}
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>> subclasses
>>>>>>>>>>>>>>>>     *             be used instead.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 30 September 2016 at 16:45, Sergey Bylokhov
>>>>>>>>>>>>>>>> <Sergey.Bylokhov at oracle.com
>>>>>>>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     Hello.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     Please review the fix for jdk9.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     This is request to deprecate the obsolete flags inside
>>>>>>>>>>>>>>>> InputEvent.
>>>>>>>>>>>>>>>>     This constants were marked as obsolete in jdk1.4 and
>>>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>>> replaced
>>>>>>>>>>>>>>>>     by the new one. In jdk1.4 the documentation were 
>>>>>>>>>>>>>>>> update
>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>> notion
>>>>>>>>>>>>>>>>     that the new constants should be used. And this bug is
>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>     official deprecation of them.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     We can replace old constants by the new one in the 
>>>>>>>>>>>>>>>> whole
>>>>>>>>>>>>>>>> jdk,
>>>>>>>>>>>>>>>> but I
>>>>>>>>>>>>>>>>     updated only the code in InputEvent to make change
>>>>>>>>>>>>>>>> smaller and
>>>>>>>>>>>>>>>>     safer. So at least the new code in jdk and the code in
>>>>>>>>>>>>>>>> applications
>>>>>>>>>>>>>>>>     will start to use the new constants.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     The changes in jconsole are necessary to fix 
>>>>>>>>>>>>>>>> deprecation
>>>>>>>>>>>>>>>> warning.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     jprt build passed, no new issues were found by 
>>>>>>>>>>>>>>>> jck/jtreg
>>>>>>>>>>>>>>>> tests.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>>>>>>>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>>>>>>>>>>>>>>>     Webrev can be found at:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     --
>>>>>>>>>>>>>>>>     Best regards, Sergey.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From prem.balakrishnan at oracle.com  Thu Oct 20 09:30:26 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Thu, 20 Oct 2016 02:30:26 -0700 (PDT)
Subject: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test
 java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X
Message-ID: <2e81eb8a-5043-4ebd-aa66-f12d9220547f@default>

Hi,

 

Please review the patch.

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

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

 

Compilation error: Can't find library\: ../../../regtesthelpers 

Fix: updated the library path

 

Regards,

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

From alexander.v.stepanov at oracle.com  Thu Oct 20 10:35:59 2016
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Thu, 20 Oct 2016 13:35:59 +0300
Subject: <AWT Dev> [9] RFR for 8159454: [TEST_BUG]
 javax/swing/ToolTipManager/7123767/bug7123767.java: number of checked
 graphics configurations should be limited
In-Reply-To: <49728f31-f26b-316f-1394-a4744749a2f2@oracle.com>
References: <3836cafd-4759-f993-1ddd-f1da66839e29@oracle.com>
	<49728f31-f26b-316f-1394-a4744749a2f2@oracle.com>
Message-ID: <1b4b6ae7-452d-996e-1396-08ca8c33c483@oracle.com>

Hello Sergey,

Please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8159454/webrev.01/

Thanks,
Alexander

P.S.: there is no guarantee that CONFIGS does not contain repeating GCs, 
but hopefully this is not very important.


On 10/19/2016 7:43 PM, Sergey Bylokhov wrote:
> Hi, Alexander
> It will be good if the test always validate default GC per device.
>
> On 19.10.16 19:33, Alexander Stepanov wrote:
>> Hello,
>>
>> Could you please review the following fix
>> http://cr.openjdk.java.net/~avstepan/8159454/webrev.00/
>> for
>> https://bugs.openjdk.java.net/browse/JDK-8159454 ?
>>
>> Thanks,
>> Alexander
>>
>
>


From Sergey.Bylokhov at oracle.com  Thu Oct 20 10:58:13 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 20 Oct 2016 13:58:13 +0300
Subject: <AWT Dev> [9] RFR for 8159454: [TEST_BUG]
 javax/swing/ToolTipManager/7123767/bug7123767.java: number of checked
 graphics configurations should be limited
In-Reply-To: <1b4b6ae7-452d-996e-1396-08ca8c33c483@oracle.com>
References: <3836cafd-4759-f993-1ddd-f1da66839e29@oracle.com>
	<49728f31-f26b-316f-1394-a4744749a2f2@oracle.com>
	<1b4b6ae7-452d-996e-1396-08ca8c33c483@oracle.com>
Message-ID: <b97bf4e5-e4b4-02af-4337-89c1714ac51d@oracle.com>

Loos fine.

On 20.10.16 13:35, Alexander Stepanov wrote:
> Hello Sergey,
>
> Please see the updated webrev:
> http://cr.openjdk.java.net/~avstepan/8159454/webrev.01/
>
> Thanks,
> Alexander
>
> P.S.: there is no guarantee that CONFIGS does not contain repeating GCs,
> but hopefully this is not very important.
>
>
> On 10/19/2016 7:43 PM, Sergey Bylokhov wrote:
>> Hi, Alexander
>> It will be good if the test always validate default GC per device.
>>
>> On 19.10.16 19:33, Alexander Stepanov wrote:
>>> Hello,
>>>
>>> Could you please review the following fix
>>> http://cr.openjdk.java.net/~avstepan/8159454/webrev.00/
>>> for
>>> https://bugs.openjdk.java.net/browse/JDK-8159454 ?
>>>
>>> Thanks,
>>> Alexander
>>>
>>
>>
>


-- 
Best regards, Sergey.

From alexander.v.stepanov at oracle.com  Thu Oct 20 11:04:13 2016
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Thu, 20 Oct 2016 14:04:13 +0300
Subject: <AWT Dev> [9] RFR for 8159454: [TEST_BUG]
 javax/swing/ToolTipManager/7123767/bug7123767.java: number of checked
 graphics configurations should be limited
In-Reply-To: <b97bf4e5-e4b4-02af-4337-89c1714ac51d@oracle.com>
References: <3836cafd-4759-f993-1ddd-f1da66839e29@oracle.com>
	<49728f31-f26b-316f-1394-a4744749a2f2@oracle.com>
	<1b4b6ae7-452d-996e-1396-08ca8c33c483@oracle.com>
	<b97bf4e5-e4b4-02af-4337-89c1714ac51d@oracle.com>
Message-ID: <11c8130e-66ee-2ab7-27f2-9e4d67258330@oracle.com>

Thanks!


On 10/20/2016 1:58 PM, Sergey Bylokhov wrote:
> Loos fine.
>
> On 20.10.16 13:35, Alexander Stepanov wrote:
>> Hello Sergey,
>>
>> Please see the updated webrev:
>> http://cr.openjdk.java.net/~avstepan/8159454/webrev.01/
>>
>> Thanks,
>> Alexander
>>
>> P.S.: there is no guarantee that CONFIGS does not contain repeating GCs,
>> but hopefully this is not very important.
>>
>>
>> On 10/19/2016 7:43 PM, Sergey Bylokhov wrote:
>>> Hi, Alexander
>>> It will be good if the test always validate default GC per device.
>>>
>>> On 19.10.16 19:33, Alexander Stepanov wrote:
>>>> Hello,
>>>>
>>>> Could you please review the following fix
>>>> http://cr.openjdk.java.net/~avstepan/8159454/webrev.00/
>>>> for
>>>> https://bugs.openjdk.java.net/browse/JDK-8159454 ?
>>>>
>>>> Thanks,
>>>> Alexander
>>>>
>>>
>>>
>>
>
>


From yuri.nesterenko at oracle.com  Thu Oct 20 11:06:12 2016
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Thu, 20 Oct 2016 14:06:12 +0300
Subject: <AWT Dev> [9] RFR for 8159454: [TEST_BUG]
 javax/swing/ToolTipManager/7123767/bug7123767.java: number of checked
 graphics configurations should be limited
In-Reply-To: <1b4b6ae7-452d-996e-1396-08ca8c33c483@oracle.com>
References: <3836cafd-4759-f993-1ddd-f1da66839e29@oracle.com>
	<49728f31-f26b-316f-1394-a4744749a2f2@oracle.com>
	<1b4b6ae7-452d-996e-1396-08ca8c33c483@oracle.com>
Message-ID: <4dcae476-96ae-4a3b-a563-1c80d18d87ea@oracle.com>

+1

-yan

On 10/20/2016 01:35 PM, Alexander Stepanov wrote:
> Hello Sergey,
>
> Please see the updated webrev:
> http://cr.openjdk.java.net/~avstepan/8159454/webrev.01/
>
> Thanks,
> Alexander
>
> P.S.: there is no guarantee that CONFIGS does not contain repeating GCs,
> but hopefully this is not very important.
>
>
> On 10/19/2016 7:43 PM, Sergey Bylokhov wrote:
>> Hi, Alexander
>> It will be good if the test always validate default GC per device.
>>
>> On 19.10.16 19:33, Alexander Stepanov wrote:
>>> Hello,
>>>
>>> Could you please review the following fix
>>> http://cr.openjdk.java.net/~avstepan/8159454/webrev.00/
>>> for
>>> https://bugs.openjdk.java.net/browse/JDK-8159454 ?
>>>
>>> Thanks,
>>> Alexander
>>>
>>
>>
>


From anton.tarasov at jetbrains.com  Thu Oct 20 13:17:07 2016
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Thu, 20 Oct 2016 16:17:07 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for 8154434: Open the
 request focus methods of the java.awt.Component which accept
 FocusEvent.Cause
In-Reply-To: <571F63E3.8080908@oracle.com>
References: <5715FABE.7050109@oracle.com> <571E711D.1060505@oracle.com>
	<571F1869.1040004@oracle.com> <571F63E3.8080908@oracle.com>
Message-ID: <456953aa-1dbf-419f-208f-456e675c1ac0@jetbrains.com>

Hi all,

The changes look fine to me.

On 4/26/2016 3:49 PM, Philip Race wrote:
> > In applications one may need to know the reason why focus is requested
>
> I do not mean why should apps want to *know* the cause.
>
> I am asking why apps should be able to *specify* the cause as
> proposed by this change.

Currently an app, implementing a custom Component, may not even *know* 
the cause why focus is requested to the Component. Opening the methods 
lets the app override them at least.

At the moment I don't have a real request in mind for this API. But the 
API indeed adds some more flexibility to focus management. For instance:

- An app can know from which direction focus has been traversed to a 
custom component.
- An app can block focus request by mouse click preventing window 
activation (and for example, postpone it).

Regards,
Anton.

>
> Being "symmetric" is not a sufficient reason.
>
> -phil.
>
> On 4/26/16, 12:27 AM, Semyon Sadetsky wrote:
>> On 4/25/2016 10:33 PM, Phil Race wrote:
>>> You will need to convince me of the appropriateness of opening these 
>>> methods.
>>> It seems to me that are for the focus system, not for applications.
>>>
>>> Why should an application be allowed to say "I would like component 
>>> X" to
>>> receive focus and tell it the reason is a mouse event" when in fact 
>>> it is nothing of the kind.
>> This is a continuation of the 8080395. I think it would be mostly 
>> interesting for framework developers not for applications.
>> In applications one may need to know the reason why focus is 
>> requested to the component before the focus is set to it.
>> As I heard from Anton (that was his task initially) opening the cause 
>> was requested by some client, but, unfortunately, I don't have any 
>> references.
>>
>> --Semyon
>>>
>>> I would like to hear from others if they see a valid use case and 
>>> that there are no
>>> down-sides to mis-use.
>>>
>>> -phil.
>>>
>>> On 04/19/2016 02:30 AM, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154434
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8154434/webrev.00/
>>>>
>>>> To support the new FocusEvent cause concept introduced by 
>>>> JDK-8080395 the next package-private methods of the 
>>>> java.awt.Component class are opened in the fix:
>>>>
>>>> boolean requestFocus(FocusEvent.Cause cause)  -> public void 
>>>> requestFocus(FocusEvent.Cause cause)
>>>>
>>>> boolean requestFocus(boolean temporary, FocusEvent.Cause cause) -> 
>>>> protected boolean requestFocus(boolean temporary, FocusEvent.Cause 
>>>> cause)
>>>>
>>>> boolean requestFocusInWindow(FocusEvent.Cause cause) -> public 
>>>> boolean requestFocusInWindow(FocusEvent.Cause cause)
>>>>
>>>> The methods are changed to be symmetric with the focus request 
>>>> methods of the same class which do not accept the cause parameter.
>>>> The method requestFocus(FocusEvent.Cause cause) was changed to 
>>>> return no value similarly to the requestFocus() because the 
>>>> returning boolean true cannot guarantee the focus gain.
>>>>
>>>> --Semyon
>>>>
>>>>
>>>
>>

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

From seahen123 at gmail.com  Thu Oct 20 11:10:37 2016
From: seahen123 at gmail.com (Chris)
Date: Thu, 20 Oct 2016 04:10:37 -0700
Subject: <AWT Dev> SkinJob: AWT on Android
In-Reply-To: <CAPvCkbj8nxyJ+3X0kEyp-7Pn-8ervC7snK8vSXE1zZnv_iqGcA@mail.gmail.com>
References: <CAPvCkbgxht8eX4fN4AyDDP0wUQc0NGckmG8W+fusaMKOEoOhSQ@mail.gmail.com>
	<CAPvCkbhthdxppnTVSTiWYhCjoxNsCw49BZaXTBZv7_RpgdqkJA@mail.gmail.com>
	<CAPvCkbi5_LKMzwyKz6eZe7q1SmGvq04MtnDks2U5nsQf4KtZMQ@mail.gmail.com>
	<CAPvCkbjfaXoPZkxDaKDQYk7bL+S6S8=uC=wa86g+Pvu0989rQA@mail.gmail.com>
	<CAPvCkbiL5TV9rFm+z2pms8cNF9Xe8X--hEK1SXyJCpNWysj7+Q@mail.gmail.com>
	<CAPvCkbgovww2NYKuhBNNRwH5GT1aN5VsnvnuPiUof0Kqc410qA@mail.gmail.com>
	<CAPvCkbiZO2unCwyQnjo86Xf_3Lb7sRX3ZO6NHb1RRhr_SOLFLw@mail.gmail.com>
	<CAPvCkbinBP7gWfEeXxJHVa2O59ck=JfH8M1JopEh85TziXn2UQ@mail.gmail.com>
	<CAPvCkbgTF2m-voKtSENiZgUST9D6_mEB0Jr0NmawQZFjWcyQ8A@mail.gmail.com>
	<CAPvCkbi65ZTF-O9+VRoXYSpXa0g3xZ1s5ZWonOWUQbJ=NbkCQQ@mail.gmail.com>
	<CAPvCkbhp-T1vStaKbygmhMTYYb++OxJw3y+3JAT1k1hUfWRb-A@mail.gmail.com>
	<CAPvCkbj9qr3HxAZuMaVcBot07J2koXLg4-R1-WdNN1d9oHf+wg@mail.gmail.com>
	<CAPvCkbijegAgOgj6gsnPZ-MpnRrfYbR0gSdqRqMTZpZcEXKTeQ@mail.gmail.com>
	<CAPvCkbhNPTKxs6QBi15aYzi0n68ENBfmKG0M7FHHRS-C0qP5Sw@mail.gmail.com>
	<CAPvCkbgxM9LuEMpW9ab7XxGBqQzFE_2Yo=dOGV-ZvDxDw6QzBQ@mail.gmail.com>
	<CAPvCkbid9yoWoz64PXwjvbOJ_LzhrOehT5UmCE_MgUW_5AVCJw@mail.gmail.com>
	<CAPvCkbjgBJ_MGSUFm=6G12WS15vNp-UJYmmZSsegVEXOoiOOGA@mail.gmail.com>
	<CAPvCkbge1TNwgagrAxWrMNiwkiwwccB4N+RxOan9B=aY=L8r8Q@mail.gmail.com>
	<CAPvCkbg9UN1ds3hYBUBQubC7xBKKnfRG8Yk8+PosUK140MLaVg@mail.gmail.com>
	<CAPvCkbjfuUgTaQRpfzYLNJE7iz-pN3WPDy=-kpXbix25R+C7Ww@mail.gmail.com>
	<CAPvCkbivsG0Tga735ePy04LGJTM7uzxbeGuLWD2VCZSzgrvwmQ@mail.gmail.com>
	<CAPvCkbhZs8aq9eN306uh3ejCJCaAQub_xhge2SGoQBGO1PptsA@mail.gmail.com>
	<CAPvCkbhSgKP8PUiJbOdKMc9Z26zNJo8NwZ4rJFDv-UNG7NCcrA@mail.gmail.com>
	<CAPvCkbijgC6Sv=1BBq4w2cS5VsFh8KAdr0nAjJbU7aA4AxD59g@mail.gmail.com>
	<CAPvCkbgBjJ4JuF6MuGvKetdVx=Xf3S0EYSQuAt3-fWeh_dympQ@mail.gmail.com>
	<CAPvCkbhGfkM8bK3z+qVF6vPfX8+w7pj+9Nu6qG0JEk0Q77uVGA@mail.gmail.com>
	<CAPvCkbhrKme5ZdRHyZsZjcP6J+tX2LmHXhtmyUhsDiuO=PKBOA@mail.gmail.com>
	<CAPvCkbiL4ATszPzBpEgcAECqiL6gV6GSJi3d6F95P+mtcG7nfw@mail.gmail.com>
	<CAPvCkbj_aQu_EOCPSnnHj0kiXAjMzwQ=1NXFQB6HxazpGMO24A@mail.gmail.com>
	<CAPvCkbiF9fsXtBEvQH9pb9dGawOWVUS81J2-ggKuR2eCT=uBOg@mail.gmail.com>
	<CAPvCkbi2LgcJYZEgmsRhm2DULmtL5tHFLB4G42koDK6er_Fviw@mail.gmail.com>
	<CAPvCkbjdq7ZFoY0XvObRPypFAh0uoRSYad+hAU-D3vQaQbcZFg@mail.gmail.com>
	<CAPvCkbjvu3Z7=tk6yzkLbYr1r0fP1+LQ_ozK8=fk3CWUR2eOiQ@mail.gmail.com>
	<CAPvCkbj8nxyJ+3X0kEyp-7Pn-8ervC7snK8vSXE1zZnv_iqGcA@mail.gmail.com>
Message-ID: <CAPvCkbgRv+WRKuc+gVWfccPO_OwUCU-MZASwYSE-GbYRmu0i_Q@mail.gmail.com>

Hi all,

I've started work on Project SkinJob (
https://github.com/RedstoneValley/skinjob), an Android implementation of
AWT that wraps the Android graphics APIs and is forked from OpenJDK AWT.
(Because the Android APIs are as high-level as AWT, SkinJob won't need any
native code or more than a couple dozen sun.* classes.)

If I had the right extra pair of hands, IMO we could have SkinJob ready for
public alpha in Q1 2017, maybe even Q4 2016. Anyone know where I might find
someone interested? (Although I know many AWT apps are specifically
designed for a larger screen and thus would need their GUIs redesigned from
scratch for the mobile world anyway, I bet there are also plenty for which
that isn't the case -- like browser applets, and anything built for J2ME
back when that was a thing.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161020/69cb0051/attachment.html>

From seahen123 at gmail.com  Thu Oct 20 11:32:16 2016
From: seahen123 at gmail.com (Chris)
Date: Thu, 20 Oct 2016 04:32:16 -0700
Subject: <AWT Dev> AWT cleanup?
In-Reply-To: <CAPvCkbhb3-_gBe6uyitw7Su6M2ZdXbX6egjNYgneVJT8G8cW5A@mail.gmail.com>
References: <CAPvCkbiaDe+9a301QzQjdR3ouUjCTzuku=8yj11RFgUim2M2=Q@mail.gmail.com>
	<CAPvCkbg4jYf5oU9kNEexDDA05M__iHyWbkaDr_BfwtNtRwjs+A@mail.gmail.com>
	<CAPvCkbj=baubEq9jCmNDC8H_S=a1jhmvukBTTbQduuWpj=4+mQ@mail.gmail.com>
	<CAPvCkbgYASCexYhT7kiW8jCE3oh1VsjP83fB6BrNsT7NFzRQ9g@mail.gmail.com>
	<CAPvCkbgHFH_X5DLVKPsOa0KFKk_=jvju29xJK683HvYjL8fZ_g@mail.gmail.com>
	<CAPvCkbgLeX3caU6N9BBaZ4gjmZ2Sh5nQwuVEeu1tyB4L_8PjbQ@mail.gmail.com>
	<CAPvCkbjSYOh2ZamXUKjcBL2sy-3Gzxw5epVyieqzG1WUiKMr6w@mail.gmail.com>
	<CAPvCkbgKLSatwBgSt+7bPo9QNvxOHBVzGmi4QxjKeN1QTE71_g@mail.gmail.com>
	<CAPvCkbj7=+kP0_xB3Ba7bB2bYRQSTOKps=JJG-_TaJinqRvR1Q@mail.gmail.com>
	<CAPvCkbhAC4rguXfsjoH0D_9oitBjvGMdFRJeo-JddhOM2J=EGA@mail.gmail.com>
	<CAPvCkbgwKmEfA3S+TNoCN2OzA9QigLdyj--Sit94+zbx=y+Wxw@mail.gmail.com>
	<CAPvCkbhqrVs9DtSfEBO3QO7u084tCwfwr8k-KZuqj=Q9YrSDDw@mail.gmail.com>
	<CAPvCkbhLBx+LgA=yuye-DuC7JXLpbpagEWCxqHTRfakO0ZcrLw@mail.gmail.com>
	<CAPvCkbiUcVUW-52=zC9MwKDOvN6Z7jkTeyMmk4jx+BoG6KDeGQ@mail.gmail.com>
	<CAPvCkbhdp10xvN=f9CFo5k5+MRN6Y0yPwWgJO9sSHsOUmr5qgg@mail.gmail.com>
	<CAPvCkbgVtSnu2uFf46ebK+HhyC6+E6McXCHwDdF9-CS8BUHTHA@mail.gmail.com>
	<CAPvCkbgaD94vgqC3WmaiTymSkCVWKnn3t9A9KeQkBNPMrVQh4g@mail.gmail.com>
	<CAPvCkbhyH6PuCLXbOtvpPtEmq=5KTtV5zfaK=fc0_4Jpq5mnGA@mail.gmail.com>
	<CAPvCkbi9W-ggwx7Vq0FYku9ShxGa2D8Co-bM-1_nUhHrg2BcQQ@mail.gmail.com>
	<CAPvCkbgxSV_1nJzZF+OpLh=4_pTojQzvQSvfU+7guSZkX1rqwg@mail.gmail.com>
	<CAPvCkbi8ZFPS=b7gTLk2cf_oDtB7JpqagngJW-HB6qAERFWAeA@mail.gmail.com>
	<CAPvCkbhqD1JxtPwNa-f7zH7=SX_Qer76TWKiKi+iQid0gPhgLA@mail.gmail.com>
	<CAPvCkbiKBUqi+VWf7iwfNwtbqC5EyYb7aW86YEyQFN+Hhy-Djw@mail.gmail.com>
	<CAPvCkbgJKO=rxtnmaXuQUsxA=NQpzyo=uU=gzGQN8i_6j8iKkg@mail.gmail.com>
	<CAPvCkbhoThvjLTtLbEbgHfRLrHMAUixQUPEHtToDmkymcJM9AQ@mail.gmail.com>
	<CAPvCkbiuaf1gXDXD1FRWHzuUVCBCs+4vOb2jkLnDDYy=xYSSxA@mail.gmail.com>
	<CAPvCkbgKG7HsMWS=X+_buU1Cc_4=HeNfY+bd670ym9FU=CL6WA@mail.gmail.com>
	<CAPvCkbiFOfBrG+7KfpMMXwdrOCg=UNEQvvfy2PJ_7oQ=UNUdDQ@mail.gmail.com>
	<CAPvCkbjv5vQsqCBKPUVLcfzpj3tv1hL69UAZ7zWL2BKJBjHF2g@mail.gmail.com>
	<CAPvCkbitd40NSwsNZzT6A=JZYUdXcv0CPHJfNg2=Zc0HvrC4SQ@mail.gmail.com>
	<CAPvCkbib-UkOo3qw6ymQGx0W47=t6yNSPPokjubLpecLvo_DKw@mail.gmail.com>
	<CAPvCkbjZoXjQ-=EhWYCWXNYdL0V7Y_45To4XexahptxLVpY4sw@mail.gmail.com>
	<CAPvCkbi1KLNKTRf-yqWkc68orFP8dWhzYeKsuUCoJHkXEykbxA@mail.gmail.com>
	<CAPvCkbhTkfv0cEfz-E4u2sRFntgQ03Pmp_GTnBs-sENEKMiK5w@mail.gmail.com>
	<CAPvCkbi8QiCSn+g7+S1kA81mVxEcXuXdg9LcSYHzGLJ+aW51BA@mail.gmail.com>
	<CAPvCkbjnzaarShuoMsUaqqgQTM1QML073mWSsCm-6wo5=Hc_eQ@mail.gmail.com>
	<CAPvCkbj_7xfNeNN0t4sQPE0GRLi63gs6rVWnTZnhcQPyMQeQQA@mail.gmail.com>
	<CAPvCkbhb3-_gBe6uyitw7Su6M2ZdXbX6egjNYgneVJT8G8cW5A@mail.gmail.com>
Message-ID: <CAPvCkbgHpFsoke8B8ZFEsqoDr8NNTf-fZzmeB7XRx8Z2TyCuSA@mail.gmail.com>

While working on SkinJob, I ran IntelliJ's Code Inspector tool over OpenJDK
AWT, and I found lots of room for improvement, much of which could be
automated. Unused imports and weird indentation are the order of the day.
Raw types are often used in place of generics, leading to a lot of
unnecessary explicit casts. The deprecated Vector and Hashtable are used in
a number of places where I'm pretty sure ArrayList<> and HashMap<> would
work fine and perform better. Many abstract classes have only one
implementation. Switch statements are often missing a default case, which
means methods will fail silently if a parameter value comes from the wrong
pseudo-enum. When they do have a default case, it seems to be at the top as
often as the bottom. Magic numbers that I can easily see a developer
wanting to change (e.g. the default font size of 12) are copied in many
different places. Even when named constants for things like color-channel
bit masks exist, they aren't consistently used. There also seem to be a
fair number of unused methods that aren't public or are buried in sun.*
(and thus should be safe to delete), and a few inconsistencies involving
equals and hashCode.

Is there a project underway to clean up these sorts of issues? If so, I'd
like to help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161020/40a968b8/attachment.html>

From Sergey.Bylokhov at oracle.com  Thu Oct 20 18:44:07 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 20 Oct 2016 21:44:07 +0300
Subject: <AWT Dev> <Swing Dev> RFR:8168316: Suppress deprecation
 warnings for Applet classes in java.desktop
In-Reply-To: <5807F032.8060309@oracle.com>
References: <5807D43A.10409@oracle.com>
	<d985aa0d-61e0-dd24-6cab-8922a1b58743@oracle.com>
	<5807F032.8060309@oracle.com>
Message-ID: <d096fd21-d599-d419-43e6-39f2479120c4@oracle.com>

On 20.10.16 1:14, Philip Race wrote:
> Well maybe but this isn't about adding deprecations it is just
> about of getting rid of warnings for uses of APIs that are
> already deprecated.

I though that if the code marked as deprecated is used inside deprecated 
method then this warning is not occurred, no? We can suppress all these 
warnings but later we will need to check all of them and deprecate the 
public methods which uses Applet as a parameters and return value, so 
probably we can save one step?

>
> You are welcome to file a separate bug on that ...
>
> -phil.
>
> On 10/19/16, 2:59 PM, Sergey Bylokhov wrote:
>> On 19.10.16 23:14, Philip Race wrote:
>>> This resolves the applet ones .. as a precursor to fixing up the other
>>> issues
>>> that cause this global supression.
>>
>> Probably some of related code can be deprecated as well?(like
>> AppletAudioClip, AppletPanel,AppletViewer
>> ,RepaintManager.addDirtyRegion(), AppletInitializer etc).
>>
>>


-- 
Best regards, Sergey.

From manajit.halder at oracle.com  Fri Oct 21 07:50:06 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Fri, 21 Oct 2016 13:20:06 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-7153700: [macosx] add
	support for MouseMotionListener to the TrayIcon
Message-ID: <70786B07-6B64-49B0-A41E-2177CBEECF32@oracle.com>

Hi All,

Kindly review the fix for JDK9.

Bug: 
https://bugs.openjdk.java.net/browse/JDK-7153700 <https://bugs.openjdk.java.net/browse/JDK-7153700>

Webrev: 
http://cr.openjdk.java.net/~mhalder/7153700/webrev.00/ <http://cr.openjdk.java.net/~mhalder/7153700/webrev.00/>

Issue: 
[macosx] add support for MouseMotionListener to the TrayIcon.

Fix: 
Added MouseMotionListener support for TrayIcon on Mac OS X.

Regards,
Manajit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161021/105826a4/attachment.html>

From ajit.ghaisas at oracle.com  Mon Oct 24 08:29:32 2016
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Mon, 24 Oct 2016 01:29:32 -0700 (PDT)
Subject: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test
 java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X
In-Reply-To: <2e81eb8a-5043-4ebd-aa66-f12d9220547f@default>
References: <2e81eb8a-5043-4ebd-aa66-f12d9220547f@default>
Message-ID: <2bc29816-a861-4b38-8a96-d0a87be29b56@default>

Hi Prem,

 

    I know this is compilation fix, but still few corrections can be made to the test.

 

1.       Please replace generic imports to specific class imports.

2.       First sentence of the instruction text has a typo - please correct it.

Existing  : "Use see a Frame with a button in it." 

Should be : "User sees a Frame with a button on it."

 

Regards,

Ajit

 

From: Prem Balakrishnan 
Sent: Thursday, October 20, 2016 3:00 PM
To: Alexander Scherbatiy; Rajeev Chamyal; awt-dev at openjdk.java.net
Subject: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X

 

Hi,

 

Please review the patch.

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

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

 

Compilation error: Can't find library\: ../../../regtesthelpers 

Fix: updated the library path

 

Regards,

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

From prem.balakrishnan at oracle.com  Mon Oct 24 09:46:24 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Mon, 24 Oct 2016 02:46:24 -0700 (PDT)
Subject: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test
 java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X
In-Reply-To: <2bc29816-a861-4b38-8a96-d0a87be29b56@default>
References: <2e81eb8a-5043-4ebd-aa66-f12d9220547f@default>
	<2bc29816-a861-4b38-8a96-d0a87be29b56@default>
Message-ID: <55bdc1e0-2302-4d13-8b39-933fb4005b1b@default>

Hi Ajit,

 

Thankyou for the review.

Updated patch as per review comments.

http://cr.openjdk.java.net/~pkbalakr/8168292/webrev.01/ 

 

Regards,

Prem

 

From: Ajit Ghaisas 
Sent: Monday, October 24, 2016 2:00 PM
To: Prem Balakrishnan; Alexander Scherbatiy; Rajeev Chamyal; awt-dev at openjdk.java.net
Subject: RE: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X

 

Hi Prem,

 

    I know this is compilation fix, but still few corrections can be made to the test.

 

1.       Please replace generic imports to specific class imports.

2.       First sentence of the instruction text has a typo - please correct it.

Existing  : "Use see a Frame with a button in it." 

Should be : "User sees a Frame with a button on it."

 

Regards,

Ajit

 

From: Prem Balakrishnan 
Sent: Thursday, October 20, 2016 3:00 PM
To: Alexander Scherbatiy; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X

 

Hi,

 

Please review the patch.

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

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

 

Compilation error: Can't find library\: ../../../regtesthelpers 

Fix: updated the library path

 

Regards,

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

From ajit.ghaisas at oracle.com  Mon Oct 24 10:11:47 2016
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Mon, 24 Oct 2016 03:11:47 -0700 (PDT)
Subject: <AWT Dev> Fix for JDK-8168470 : [TEST_BUG] @test missed in
 java/awt/Window/ChangeWindowResizabilty/ChangeWindowResizabiltyTest.java
Message-ID: <c321546a-e912-46bf-b5cc-9222d46c1f3b@default>

Hi,

 

   Please review a quick-fix where a missed jtreg tag has been added.

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

   Fix : http://cr.openjdk.java.net/~aghaisas/8168470/webrev.0/

 

   Request you to review.   

 

Regards,

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

From Sergey.Bylokhov at oracle.com  Mon Oct 24 15:29:22 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 24 Oct 2016 18:29:22 +0300
Subject: <AWT Dev> AWT cleanup?
In-Reply-To: <CAPvCkbgHpFsoke8B8ZFEsqoDr8NNTf-fZzmeB7XRx8Z2TyCuSA@mail.gmail.com>
References: <CAPvCkbiaDe+9a301QzQjdR3ouUjCTzuku=8yj11RFgUim2M2=Q@mail.gmail.com>
	<CAPvCkbgKG7HsMWS=X+_buU1Cc_4=HeNfY+bd670ym9FU=CL6WA@mail.gmail.com>
	<CAPvCkbiFOfBrG+7KfpMMXwdrOCg=UNEQvvfy2PJ_7oQ=UNUdDQ@mail.gmail.com>
	<CAPvCkbjv5vQsqCBKPUVLcfzpj3tv1hL69UAZ7zWL2BKJBjHF2g@mail.gmail.com>
	<CAPvCkbitd40NSwsNZzT6A=JZYUdXcv0CPHJfNg2=Zc0HvrC4SQ@mail.gmail.com>
	<CAPvCkbib-UkOo3qw6ymQGx0W47=t6yNSPPokjubLpecLvo_DKw@mail.gmail.com>
	<CAPvCkbjZoXjQ-=EhWYCWXNYdL0V7Y_45To4XexahptxLVpY4sw@mail.gmail.com>
	<CAPvCkbi1KLNKTRf-yqWkc68orFP8dWhzYeKsuUCoJHkXEykbxA@mail.gmail.com>
	<CAPvCkbhTkfv0cEfz-E4u2sRFntgQ03Pmp_GTnBs-sENEKMiK5w@mail.gmail.com>
	<CAPvCkbi8QiCSn+g7+S1kA81mVxEcXuXdg9LcSYHzGLJ+aW51BA@mail.gmail.com>
	<CAPvCkbjnzaarShuoMsUaqqgQTM1QML073mWSsCm-6wo5=Hc_eQ@mail.gmail.com>
	<CAPvCkbj_7xfNeNN0t4sQPE0GRLi63gs6rVWnTZnhcQPyMQeQQA@mail.gmail.com>
	<CAPvCkbhb3-_gBe6uyitw7Su6M2ZdXbX6egjNYgneVJT8G8cW5A@mail.gmail.com>
	<CAPvCkbgHpFsoke8B8ZFEsqoDr8NNTf-fZzmeB7XRx8Z2TyCuSA@mail.gmail.com>
Message-ID: <67c26a0c-7e3f-ffd6-d327-5a1f3b87259c@oracle.com>

Hi, Chris.
Yes there is a room for improvements and some cleanup can be done in the 
client related libraries: AWT, Java2D, Swing, JavaSound. As far as I 
know there are no any projects to cleanup the code. So usually it is 
done one by one.(small request to cleanup is filed and fixed, etc)

As an example you can see something like this:
https://bugs.openjdk.java.net/browse/JDK-8163949
http://mail.openjdk.java.net/pipermail/sound-dev/2016-August/000459.html

A few notes:
  - You should not expect that the fix will be reviewed fast enough 
because there are some more priority bugs to review. So it will be good 
if the fix will be limited by small type of issues, and will cover a 
reasonable number of files.
  - Such fixes should not change the public API of the library(classes, 
methods, fields). So you should take into account serialization for example.
  - Sometimes it is possible to tweak a public API but in this case, 
such requests should be filed and discussed separately.
  - This is a good starting point to understand how the processes work 
in OpenJDK, and later you will be able to fix some more important bugs.

On 20.10.16 14:32, Chris wrote:
> While working on SkinJob, I ran IntelliJ's Code Inspector tool over
> OpenJDK AWT, and I found lots of room for improvement, much of which
> could be automated. Unused imports and weird indentation are the order
> of the day. Raw types are often used in place of generics, leading to a
> lot of unnecessary explicit casts. The deprecated Vector and Hashtable
> are used in a number of places where I'm pretty sure ArrayList<> and
> HashMap<> would work fine and perform better. Many abstract classes have
> only one implementation. Switch statements are often missing a default
> case, which means methods will fail silently if a parameter value comes
> from the wrong pseudo-enum. When they do have a default case, it seems
> to be at the top as often as the bottom. Magic numbers that I can easily
> see a developer wanting to change (e.g. the default font size of 12) are
> copied in many different places. Even when named constants for things
> like color-channel bit masks exist, they aren't consistently used. There
> also seem to be a fair number of unused methods that aren't public or
> are buried in sun.* (and thus should be safe to delete), and a few
> inconsistencies involving equals and hashCode.
>
> Is there a project underway to clean up these sorts of issues? If so,
> I'd like to help.
>


-- 
Best regards, Sergey.

From philip.race at oracle.com  Mon Oct 24 16:08:08 2016
From: philip.race at oracle.com (Philip Race)
Date: Mon, 24 Oct 2016 09:08:08 -0700
Subject: <AWT Dev> AWT cleanup?
In-Reply-To: <67c26a0c-7e3f-ffd6-d327-5a1f3b87259c@oracle.com>
References: <CAPvCkbiaDe+9a301QzQjdR3ouUjCTzuku=8yj11RFgUim2M2=Q@mail.gmail.com>
	<CAPvCkbiFOfBrG+7KfpMMXwdrOCg=UNEQvvfy2PJ_7oQ=UNUdDQ@mail.gmail.com>
	<CAPvCkbjv5vQsqCBKPUVLcfzpj3tv1hL69UAZ7zWL2BKJBjHF2g@mail.gmail.com>
	<CAPvCkbitd40NSwsNZzT6A=JZYUdXcv0CPHJfNg2=Zc0HvrC4SQ@mail.gmail.com>
	<CAPvCkbib-UkOo3qw6ymQGx0W47=t6yNSPPokjubLpecLvo_DKw@mail.gmail.com>
	<CAPvCkbjZoXjQ-=EhWYCWXNYdL0V7Y_45To4XexahptxLVpY4sw@mail.gmail.com>
	<CAPvCkbi1KLNKTRf-yqWkc68orFP8dWhzYeKsuUCoJHkXEykbxA@mail.gmail.com>
	<CAPvCkbhTkfv0cEfz-E4u2sRFntgQ03Pmp_GTnBs-sENEKMiK5w@mail.gmail.com>
	<CAPvCkbi8QiCSn+g7+S1kA81mVxEcXuXdg9LcSYHzGLJ+aW51BA@mail.gmail.com>
	<CAPvCkbjnzaarShuoMsUaqqgQTM1QML073mWSsCm-6wo5=Hc_eQ@mail.gmail.com>
	<CAPvCkbj_7xfNeNN0t4sQPE0GRLi63gs6rVWnTZnhcQPyMQeQQA@mail.gmail.com>
	<CAPvCkbhb3-_gBe6uyitw7Su6M2ZdXbX6egjNYgneVJT8G8cW5A@mail.gmail.com>
	<CAPvCkbgHpFsoke8B8ZFEsqoDr8NNTf-fZzmeB7XRx8Z2TyCuSA@mail.gmail.com>
	<67c26a0c-7e3f-ffd6-d327-5a1f3b87259c@oracle.com>
Message-ID: <580E31E8.6040304@oracle.com>

This seems like a JDK 10 project. Not a JDK 9 one.

We are stabilising 9 now .. not making changes which can't contribute to 
that goal.

Also the methods on Vector and Hashtable are synchronized ..
so you need to make sure you replace like with like.

Intellij thinking indentation is weird may not mean its wrong ..

If code is 3rd party (probably not the case for the Java code) we don't 
mess with it.

Unused methods may not be as unused as you think ... case by case.

-phil.


On 10/24/16, 8:29 AM, Sergey Bylokhov wrote:
> Hi, Chris.
> Yes there is a room for improvements and some cleanup can be done in 
> the client related libraries: AWT, Java2D, Swing, JavaSound. As far as 
> I know there are no any projects to cleanup the code. So usually it is 
> done one by one.(small request to cleanup is filed and fixed, etc)
>
> As an example you can see something like this:
> https://bugs.openjdk.java.net/browse/JDK-8163949
> http://mail.openjdk.java.net/pipermail/sound-dev/2016-August/000459.html
>
> A few notes:
>  - You should not expect that the fix will be reviewed fast enough 
> because there are some more priority bugs to review. So it will be 
> good if the fix will be limited by small type of issues, and will 
> cover a reasonable number of files.
>  - Such fixes should not change the public API of the library(classes, 
> methods, fields). So you should take into account serialization for 
> example.
>  - Sometimes it is possible to tweak a public API but in this case, 
> such requests should be filed and discussed separately.
>  - This is a good starting point to understand how the processes work 
> in OpenJDK, and later you will be able to fix some more important bugs.
>
> On 20.10.16 14:32, Chris wrote:
>> While working on SkinJob, I ran IntelliJ's Code Inspector tool over
>> OpenJDK AWT, and I found lots of room for improvement, much of which
>> could be automated. Unused imports and weird indentation are the order
>> of the day. Raw types are often used in place of generics, leading to a
>> lot of unnecessary explicit casts. The deprecated Vector and Hashtable
>> are used in a number of places where I'm pretty sure ArrayList<> and
>> HashMap<> would work fine and perform better. Many abstract classes have
>> only one implementation. Switch statements are often missing a default
>> case, which means methods will fail silently if a parameter value comes
>> from the wrong pseudo-enum. When they do have a default case, it seems
>> to be at the top as often as the bottom. Magic numbers that I can easily
>> see a developer wanting to change (e.g. the default font size of 12) are
>> copied in many different places. Even when named constants for things
>> like color-channel bit masks exist, they aren't consistently used. There
>> also seem to be a fair number of unused methods that aren't public or
>> are buried in sun.* (and thus should be safe to delete), and a few
>> inconsistencies involving equals and hashCode.
>>
>> Is there a project underway to clean up these sorts of issues? If so,
>> I'd like to help.
>>
>
>

From ambarish.rapte at oracle.com  Tue Oct 25 06:43:05 2016
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Mon, 24 Oct 2016 23:43:05 -0700 (PDT)
Subject: <AWT Dev> Fix for JDK-8168470 : [TEST_BUG] @test missed in
 java/awt/Window/ChangeWindowResizabilty/ChangeWindowResizabiltyTest.java
In-Reply-To: <c321546a-e912-46bf-b5cc-9222d46c1f3b@default>
References: <c321546a-e912-46bf-b5cc-9222d46c1f3b@default>
Message-ID: <c3c233ee-055d-4dad-a2be-89c582717404@default>

Hi Ajit,

                The change looks good.

 

Regards,

Ambarish

 

From: Ajit Ghaisas 
Sent: Monday, October 24, 2016 3:42 PM
To: Semyon Sadetsky; Sergey Bylokhov; awt-dev at openjdk.java.net; Ambarish Rapte
Subject: Fix for JDK-8168470 : [TEST_BUG] @test missed in java/awt/Window/ChangeWindowResizabilty/ChangeWindowResizabiltyTest.java

 

Hi,

 

   Please review a quick-fix where a missed jtreg tag has been added.

 

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

   Fix : http://cr.openjdk.java.net/~aghaisas/8168470/webrev.0/

 

   Request you to review.   

 

Regards,

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

From ajit.ghaisas at oracle.com  Tue Oct 25 08:55:30 2016
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Tue, 25 Oct 2016 01:55:30 -0700 (PDT)
Subject: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test
 java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X
In-Reply-To: <55bdc1e0-2302-4d13-8b39-933fb4005b1b@default>
References: <2e81eb8a-5043-4ebd-aa66-f12d9220547f@default>
	<2bc29816-a861-4b38-8a96-d0a87be29b56@default>
	<55bdc1e0-2302-4d13-8b39-933fb4005b1b@default>
Message-ID: <1247e0ac-ddda-4ccd-bec5-0b91c77e2ea0@default>

Looks fine.

 

Regards,

Ajit

 

From: Prem Balakrishnan 
Sent: Monday, October 24, 2016 3:16 PM
To: Ajit Ghaisas; Alexander Scherbatiy; Rajeev Chamyal; awt-dev at openjdk.java.net
Subject: RE: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X

 

Hi Ajit,

 

Thankyou for the review.

Updated patch as per review comments.

http://cr.openjdk.java.net/~pkbalakr/8168292/webrev.01/ 

 

Regards,

Prem

 

From: Ajit Ghaisas 
Sent: Monday, October 24, 2016 2:00 PM
To: Prem Balakrishnan; Alexander Scherbatiy; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: RE: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X

 

Hi Prem,

 

    I know this is compilation fix, but still few corrections can be made to the test.

 

1.       Please replace generic imports to specific class imports.

2.       First sentence of the instruction text has a typo - please correct it.

Existing  : "Use see a Frame with a button in it." 

Should be : "User sees a Frame with a button on it."

 

Regards,

Ajit

 

From: Prem Balakrishnan 
Sent: Thursday, October 20, 2016 3:00 PM
To: Alexander Scherbatiy; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X

 

Hi,

 

Please review the patch.

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

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

 

Compilation error: Can't find library\: ../../../regtesthelpers 

Fix: updated the library path

 

Regards,

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

From alexandr.scherbatiy at oracle.com  Tue Oct 25 11:11:55 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Tue, 25 Oct 2016 14:11:55 +0300
Subject: <AWT Dev> [9] Review request for 8147440 HiDPI (Windows): Swing
 components have incorrect sizes after changing display resolution
In-Reply-To: <56F05A83.4020904@oracle.com>
References: <56B454D2.3000300@oracle.com> <56BB3BFF.4070506@oracle.com>
	<56F05A83.4020904@oracle.com>
Message-ID: <31b21cd4-1e7d-08f3-f66a-5acbc8c86014@oracle.com>


   Hello,

   Could you review the updated fix:
     http://cr.openjdk.java.net/~alexsch/8147440/webrev.01/
   - an undecorated frame does not set WWindowPeer.sysX/Y/W,H values so 
the fix is updated to retrieve a window bounds form the target
   - the html test file is removed

  Thanks,
Alexandr.

On 3/21/2016 11:33 PM, Alexandr Scherbatiy wrote:
>
>
> On 2/10/2016 5:32 AM, Sergey Bylokhov wrote:
>> On 05.02.16 10:52, Alexandr Scherbatiy wrote:
>>
>>>    The first approach is to rescale only frame size on native level so
>>>      newNativeWindow.size = newScale *  javaWindow.size
>>
>> What location will be in this approach?
>     The idea was to update WComponentPeer.setBounds(x,y, w, h) method 
> that it sets only size for the op=SET_BOUNDS on the native level.
>     In this case the native window location and java window location 
> will not be changed.
>     However, the relation between newNativeWindow.location and 
> javaWindow.location will use the old scale factor instead the new one.
>
>> Does the native app work in the similar way(changes the size only)?
>     Yes. The native application changes their size but leaves the 
> location the same.
>
>   Thanks,
>   Alexandr.
>
>>
>>>    This allows to leave the nativeWindow.location unchanged but the 
>>> rule
>>>      nativeWindow.location = newScale * javaWindow.location
>>>    will be broken in this case.
>>>
>>>    The proposed fix explicitly rescales javaWindow.location in
>>> WWindowPeer so
>>>    nativeWindow.location = prevScale * prevJavaWindow.location =
>>> newScale * newJavaWindow.location
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>
>>
>


From Sergey.Bylokhov at oracle.com  Tue Oct 25 14:32:10 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 25 Oct 2016 17:32:10 +0300
Subject: <AWT Dev> [9] Review request for 8147440 HiDPI (Windows): Swing
 components have incorrect sizes after changing display resolution
In-Reply-To: <31b21cd4-1e7d-08f3-f66a-5acbc8c86014@oracle.com>
References: <56B454D2.3000300@oracle.com> <56BB3BFF.4070506@oracle.com>
	<56F05A83.4020904@oracle.com>
	<31b21cd4-1e7d-08f3-f66a-5acbc8c86014@oracle.com>
Message-ID: <9c66d363-3bb4-4b14-0596-2e02678d29f8@oracle.com>

On 25.10.16 14:11, Alexandr Scherbatiy wrote:
>   Could you review the updated fix:
>     http://cr.openjdk.java.net/~alexsch/8147440/webrev.01/
>   - an undecorated frame does not set WWindowPeer.sysX/Y/W,H values so
> the fix is updated to retrieve a window bounds form the target

Why this fields is not updated for undecorated frame? We should 
carefully use target here, on what thread this callback is executed?

Can you also check the situation when on multi-monitor configuration you 
will move the window from one screen to another(both screens should have 
different scale). Is it possible that you will get updateGC -> then you 
call setBounds -> increase the size of window -> this will move the 
window to other screen->updateGC-> setBounds->decrease the size of the 
window, etc?


> On 3/21/2016 11:33 PM, Alexandr Scherbatiy wrote:
>>
>>
>> On 2/10/2016 5:32 AM, Sergey Bylokhov wrote:
>>> On 05.02.16 10:52, Alexandr Scherbatiy wrote:
>>>
>>>>    The first approach is to rescale only frame size on native level so
>>>>      newNativeWindow.size = newScale *  javaWindow.size
>>>
>>> What location will be in this approach?
>>     The idea was to update WComponentPeer.setBounds(x,y, w, h) method
>> that it sets only size for the op=SET_BOUNDS on the native level.
>>     In this case the native window location and java window location
>> will not be changed.
>>     However, the relation between newNativeWindow.location and
>> javaWindow.location will use the old scale factor instead the new one.
>>
>>> Does the native app work in the similar way(changes the size only)?
>>     Yes. The native application changes their size but leaves the
>> location the same.
>>
>>   Thanks,
>>   Alexandr.
>>
>>>
>>>>    This allows to leave the nativeWindow.location unchanged but the
>>>> rule
>>>>      nativeWindow.location = newScale * javaWindow.location
>>>>    will be broken in this case.
>>>>
>>>>    The proposed fix explicitly rescales javaWindow.location in
>>>> WWindowPeer so
>>>>    nativeWindow.location = prevScale * prevJavaWindow.location =
>>>> newScale * newJavaWindow.location
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>
>>>
>>
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Oct 25 14:41:38 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 25 Oct 2016 17:41:38 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <750f4ba6-5dea-7fb0-c7c1-c207d5cd2912@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
	<f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
	<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>
	<f64fd14a-c99f-6dae-0d99-b730c6afcf48@oracle.com>
	<3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com>
	<b766f536-dbcd-3788-918e-5e99427f162b@oracle.com>
	<0e185822-ff1b-2041-baca-d5491ce2e4b8@oracle.com>
	<aaa011cc-6fe5-e7fe-ae03-b7cc1c017c39@oracle.com>
	<5888a670-6fc3-764c-c3cf-6703744b0d27@oracle.com>
	<5bda0f8a-5dfb-7356-5942-015fc27d6b07@oracle.com>
	<255c4e87-b58c-1d4d-30ca-97d1d9a710d0@oracle.com>
	<750f4ba6-5dea-7fb0-c7c1-c207d5cd2912@oracle.com>
Message-ID: <f5659e98-9034-0b52-816b-b382c404069e@oracle.com>

On 20.10.16 10:04, Semyon Sadetsky wrote:
> The same is necessary for the user code. Look at the spec you propose:
>
>   63     /**
>   64      * The Shift key modifier constant.
>   65      *
>   66      * @deprecated It is recommended that SHIFT_DOWN_MASK be used
> instead.
>   67      */
>   68     @Deprecated(since = "9")
>   69     public static final int SHIFT_MASK = Event.SHIFT_MASK;
>
> After your fix developer gets deprecation warning, read your
> recommendation and simply replace SHIFT_MASK with SHIFT_DOWN_MASK which
> may cause wrong app behavior. You should add something to the spec to
> make developer pay attention.

I wonder why he should decide that the old code can be "simply replaced" 
by the new one? I suppose that at least he should read the specification 
of the new extended API. There is no notion that this api is replaced by 
the new one, there is a recommendation that the new one should be used 
instead.

>> We already have a notions that these "extended modifier constant"
>> should be used in the constructor of InputEvent and moreover in spec
>> of getModifiersEx() we have an additional examples how to use this
>> constants. This is why we will have a reference from old constans to
>> the new, and from getModifiers() to the getModifiersEx();
>>
>>>>>>>>>>> And, please, limit the length of the changed line in
>>>>>>>>>>> VMPanel.java
>>>>>>>>>>> to 80
>>>>>>>>>>> chars.
>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>>>>>> Thanks for the comments.
>>>>>>>>>>>>>>>> The new version:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.01
>>>>>>>>>>>>>>>> The specification of Event class and
>>>>>>>>>>>>>>>> InputEvent.getModifiers()
>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>> updated.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>>>>>>>>>>>>>>>>> Hi Sergey,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'm not a reviewer, but after reading the deprecation
>>>>>>>>>>>>>>>>> messages in
>>>>>>>>>>>>>>>>> Event.java
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent}
>>>>>>>>>>>>>>>>> class
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>     subclasses
>>>>>>>>>>>>>>>>>     *             be used instead.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I get the impression they would read better without the
>>>>>>>>>>>>>>>>> redundant
>>>>>>>>>>>>>>>>> "class" in the middle, like so.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     * @deprecated It is recommended that {@code AWTEvent}
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>> subclasses
>>>>>>>>>>>>>>>>>     *             be used instead.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 30 September 2016 at 16:45, Sergey Bylokhov
>>>>>>>>>>>>>>>>> <Sergey.Bylokhov at oracle.com
>>>>>>>>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     Hello.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     Please review the fix for jdk9.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     This is request to deprecate the obsolete flags inside
>>>>>>>>>>>>>>>>> InputEvent.
>>>>>>>>>>>>>>>>>     This constants were marked as obsolete in jdk1.4 and
>>>>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>>>> replaced
>>>>>>>>>>>>>>>>>     by the new one. In jdk1.4 the documentation were
>>>>>>>>>>>>>>>>> update
>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>> notion
>>>>>>>>>>>>>>>>>     that the new constants should be used. And this bug is
>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>     official deprecation of them.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     We can replace old constants by the new one in the
>>>>>>>>>>>>>>>>> whole
>>>>>>>>>>>>>>>>> jdk,
>>>>>>>>>>>>>>>>> but I
>>>>>>>>>>>>>>>>>     updated only the code in InputEvent to make change
>>>>>>>>>>>>>>>>> smaller and
>>>>>>>>>>>>>>>>>     safer. So at least the new code in jdk and the code in
>>>>>>>>>>>>>>>>> applications
>>>>>>>>>>>>>>>>>     will start to use the new constants.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     The changes in jconsole are necessary to fix
>>>>>>>>>>>>>>>>> deprecation
>>>>>>>>>>>>>>>>> warning.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     jprt build passed, no new issues were found by
>>>>>>>>>>>>>>>>> jck/jtreg
>>>>>>>>>>>>>>>>> tests.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
>>>>>>>>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>>>>>>>>>>>>>>>>     Webrev can be found at:
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     --
>>>>>>>>>>>>>>>>>     Best regards, Sergey.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Oct 25 15:00:27 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 25 Oct 2016 18:00:27 +0300
Subject: <AWT Dev> Fix for JDK-8168470 : [TEST_BUG] @test missed in
 java/awt/Window/ChangeWindowResizabilty/ChangeWindowResizabiltyTest.java
In-Reply-To: <c3c233ee-055d-4dad-a2be-89c582717404@default>
References: <c321546a-e912-46bf-b5cc-9222d46c1f3b@default>
	<c3c233ee-055d-4dad-a2be-89c582717404@default>
Message-ID: <4ac6dece-796f-6ed9-d865-72f61f7d0db6@oracle.com>

+1

On 25.10.16 9:43, Ambarish Rapte wrote:
> Hi Ajit,
>
>                 The change looks good.
>
>
>
> Regards,
>
> Ambarish
>
>
>
> *From:*Ajit Ghaisas
> *Sent:* Monday, October 24, 2016 3:42 PM
> *To:* Semyon Sadetsky; Sergey Bylokhov; awt-dev at openjdk.java.net;
> Ambarish Rapte
> *Subject:* Fix for JDK-8168470 : [TEST_BUG] @test missed in
> java/awt/Window/ChangeWindowResizabilty/ChangeWindowResizabiltyTest.java
>
>
>
> Hi,
>
>
>
>    Please review a quick-fix where a missed jtreg tag has been added.
>
>
>
>    Bug : https://bugs.openjdk.java.net/browse/JDK-8168470
>
>    Fix : http://cr.openjdk.java.net/~aghaisas/8168470/webrev.0/
>
>
>
>    Request you to review.
>
>
>
> Regards,
>
> Ajit
>


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Tue Oct 25 15:46:39 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 25 Oct 2016 18:46:39 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <f5659e98-9034-0b52-816b-b382c404069e@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
	<f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
	<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>
	<f64fd14a-c99f-6dae-0d99-b730c6afcf48@oracle.com>
	<3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com>
	<b766f536-dbcd-3788-918e-5e99427f162b@oracle.com>
	<0e185822-ff1b-2041-baca-d5491ce2e4b8@oracle.com>
	<aaa011cc-6fe5-e7fe-ae03-b7cc1c017c39@oracle.com>
	<5888a670-6fc3-764c-c3cf-6703744b0d27@oracle.com>
	<5bda0f8a-5dfb-7356-5942-015fc27d6b07@oracle.com>
	<255c4e87-b58c-1d4d-30ca-97d1d9a710d0@oracle.com>
	<750f4ba6-5dea-7fb0-c7c1-c207d5cd2912@oracle.com>
	<f5659e98-9034-0b52-816b-b382c404069e@oracle.com>
Message-ID: <241007aa-5fdb-d6a6-f1f8-2eb83433ea69@oracle.com>



On 10/25/2016 5:41 PM, Sergey Bylokhov wrote:
> On 20.10.16 10:04, Semyon Sadetsky wrote:
>> The same is necessary for the user code. Look at the spec you propose:
>>
>>   63     /**
>>   64      * The Shift key modifier constant.
>>   65      *
>>   66      * @deprecated It is recommended that SHIFT_DOWN_MASK be used
>> instead.
>>   67      */
>>   68     @Deprecated(since = "9")
>>   69     public static final int SHIFT_MASK = Event.SHIFT_MASK;
>>
>> After your fix developer gets deprecation warning, read your
>> recommendation and simply replace SHIFT_MASK with SHIFT_DOWN_MASK which
>> may cause wrong app behavior. You should add something to the spec to
>> make developer pay attention.
>
> I wonder why he should decide that the old code can be "simply 
> replaced" by the new one? I suppose that at least he should read the 
> specification of the new extended API. There is no notion that this 
> api is replaced by the new one, there is a recommendation that the new 
> one should be used instead.
After reading such recommendation it's hard to conclude that one "should 
read the specification of the new extended API". Even "@see" tag 
pointing to the extended API is not provided (I'm not even mentioning 
the warning that the extended API may be nonequivalent replacement is 
absent). I read this recommendation as it is: replace one constant with 
another, no side effects expected.
>
>>> We already have a notions that these "extended modifier constant"
>>> should be used in the constructor of InputEvent and moreover in spec
>>> of getModifiersEx() we have an additional examples how to use this
>>> constants. This is why we will have a reference from old constans to
>>> the new, and from getModifiers() to the getModifiersEx();
>>>
>>>>>>>>>>>> And, please, limit the length of the changed line in
>>>>>>>>>>>> VMPanel.java
>>>>>>>>>>>> to 80
>>>>>>>>>>>> chars.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 10/2/2016 4:53 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>>>>>>> Thanks for the comments.
>>>>>>>>>>>>>>>>> The new version:
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.01
>>>>>>>>>>>>>>>>> The specification of Event class and
>>>>>>>>>>>>>>>>> InputEvent.getModifiers()
>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>> updated.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 30.09.16 19:08, Jonathan Bluett-Duncan wrote:
>>>>>>>>>>>>>>>>>> Hi Sergey,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm not a reviewer, but after reading the deprecation
>>>>>>>>>>>>>>>>>> messages in
>>>>>>>>>>>>>>>>>> Event.java
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     * @deprecated It is recommended that {@code 
>>>>>>>>>>>>>>>>>> AWTEvent}
>>>>>>>>>>>>>>>>>> class
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>     subclasses
>>>>>>>>>>>>>>>>>>     *             be used instead.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I get the impression they would read better without the
>>>>>>>>>>>>>>>>>> redundant
>>>>>>>>>>>>>>>>>> "class" in the middle, like so.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     * @deprecated It is recommended that {@code 
>>>>>>>>>>>>>>>>>> AWTEvent}
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>> subclasses
>>>>>>>>>>>>>>>>>>     *             be used instead.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 30 September 2016 at 16:45, Sergey Bylokhov
>>>>>>>>>>>>>>>>>> <Sergey.Bylokhov at oracle.com
>>>>>>>>>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     Hello.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     Please review the fix for jdk9.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     This is request to deprecate the obsolete flags 
>>>>>>>>>>>>>>>>>> inside
>>>>>>>>>>>>>>>>>> InputEvent.
>>>>>>>>>>>>>>>>>>     This constants were marked as obsolete in jdk1.4 and
>>>>>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>>>>> replaced
>>>>>>>>>>>>>>>>>>     by the new one. In jdk1.4 the documentation were
>>>>>>>>>>>>>>>>>> update
>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>> notion
>>>>>>>>>>>>>>>>>>     that the new constants should be used. And this 
>>>>>>>>>>>>>>>>>> bug is
>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>     official deprecation of them.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     We can replace old constants by the new one in the
>>>>>>>>>>>>>>>>>> whole
>>>>>>>>>>>>>>>>>> jdk,
>>>>>>>>>>>>>>>>>> but I
>>>>>>>>>>>>>>>>>>     updated only the code in InputEvent to make change
>>>>>>>>>>>>>>>>>> smaller and
>>>>>>>>>>>>>>>>>>     safer. So at least the new code in jdk and the 
>>>>>>>>>>>>>>>>>> code in
>>>>>>>>>>>>>>>>>> applications
>>>>>>>>>>>>>>>>>>     will start to use the new constants.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     The changes in jconsole are necessary to fix
>>>>>>>>>>>>>>>>>> deprecation
>>>>>>>>>>>>>>>>>> warning.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     jprt build passed, no new issues were found by
>>>>>>>>>>>>>>>>>> jck/jtreg
>>>>>>>>>>>>>>>>>> tests.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     Bug: 
>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8143077
>>>>>>>>>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8143077>
>>>>>>>>>>>>>>>>>>     Webrev can be found at:
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8143077/webrev.00
>>>>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/~serb/8143077/webrev.00>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     --
>>>>>>>>>>>>>>>>>>     Best regards, Sergey.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From semyon.sadetsky at oracle.com  Tue Oct 25 15:47:20 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 25 Oct 2016 18:47:20 +0300
Subject: <AWT Dev> Fix for JDK-8168470 : [TEST_BUG] @test missed in
 java/awt/Window/ChangeWindowResizabilty/ChangeWindowResizabiltyTest.java
In-Reply-To: <4ac6dece-796f-6ed9-d865-72f61f7d0db6@oracle.com>
References: <c321546a-e912-46bf-b5cc-9222d46c1f3b@default>
	<c3c233ee-055d-4dad-a2be-89c582717404@default>
	<4ac6dece-796f-6ed9-d865-72f61f7d0db6@oracle.com>
Message-ID: <6aea4ae7-a860-e3ab-af90-2cccef00ac13@oracle.com>

+1

--Semyon


On 10/25/2016 6:00 PM, Sergey Bylokhov wrote:
> +1
>
> On 25.10.16 9:43, Ambarish Rapte wrote:
>> Hi Ajit,
>>
>>                 The change looks good.
>>
>>
>>
>> Regards,
>>
>> Ambarish
>>
>>
>>
>> *From:*Ajit Ghaisas
>> *Sent:* Monday, October 24, 2016 3:42 PM
>> *To:* Semyon Sadetsky; Sergey Bylokhov; awt-dev at openjdk.java.net;
>> Ambarish Rapte
>> *Subject:* Fix for JDK-8168470 : [TEST_BUG] @test missed in
>> java/awt/Window/ChangeWindowResizabilty/ChangeWindowResizabiltyTest.java
>>
>>
>>
>> Hi,
>>
>>
>>
>>    Please review a quick-fix where a missed jtreg tag has been added.
>>
>>
>>
>>    Bug : https://bugs.openjdk.java.net/browse/JDK-8168470
>>
>>    Fix : http://cr.openjdk.java.net/~aghaisas/8168470/webrev.0/
>>
>>
>>
>>    Request you to review.
>>
>>
>>
>> Regards,
>>
>> Ajit
>>
>
>


From alexander.zvegintsev at oracle.com  Tue Oct 25 16:25:55 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 25 Oct 2016 19:25:55 +0300
Subject: <AWT Dev> [9] Review request for 8143914: Provide Mac-specific
 fullscreen support
In-Reply-To: <8765afc5-cf78-537e-bf80-9bf262ea4774@oracle.com>
References: <70a8e894-93be-23d5-a296-2f674053ee1a@oracle.com>
	<106cd9a6-8946-f34c-4647-17a7ab053b65@oracle.com>
	<8765afc5-cf78-537e-bf80-9bf262ea4774@oracle.com>
Message-ID: <0c37edb1-59db-df64-45b4-e279ac1ab703@oracle.com>

Please see the updated webrev:

http://cr.openjdk.java.net/~azvegint/jdk/9/8143914/02/


Thanks,
Alexander.

On 10/11/16 5:00 PM, Alexander Zvegintsev wrote:
> Hi Sergey,
>
> Please see the updated webrev:
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8143914/01/
>
> As I can observe other windows  such as native dialogs doesn't have 
> fullscreen button.
>
>
> On 10/2/16 5:52 PM, Sergey Bylokhov wrote:
>> Hi, Alexander.
>> In the fix you use eawt events which are generated by the same peer. 
>> Why not use windowWill/DidEnterFullScreen + 
>> windowWill/DidExitFullScreen?
>> Why the fix is for the Frames only, there are some limitations for 
>> other windows, dialogs etc?
>>
>> On 06.09.16 17:32, Alexander Zvegintsev wrote:
>>> Hello,
>>>
>>> please review the fix
>>>
>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8143914/00/
>>>
>>> for the issue
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8143914
>>>
>>>
>>> This fix adds the green FullScreen button to a resizable frames by 
>>> default.
>>>
>>> Previous maximize behavior is still accessible by holding Alt while
>>> clicking on the green button.
>>>
>>> setResizable is fixed because of two reasons:
>>>
>>> Window will not be able to leave fullscreen if we remove resizable from
>>> style bits(and even if we set it again)
>>>
>>> Window will not have the green button(maximize/zoom or fullscreen) if
>>> the window was initially not resizable.
>>>
>>>
>>
>>
>


From Sergey.Bylokhov at oracle.com  Tue Oct 25 16:44:32 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 25 Oct 2016 19:44:32 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <9fe33c67-0a4e-182b-b5a7-e76025d8f914@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
	<04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
	<911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>
	<07ce3934-96fb-dc64-99df-995e5a0ca28a@oracle.com>
	<d88f1d0b-d467-324b-6237-84eeec50046e@oracle.com>
	<38787b3b-1356-977f-ca23-c6e728d3ceda@oracle.com>
	<29f01520-99b0-7438-02a5-51cc248be29d@oracle.com>
	<f45beddd-f4be-ac91-aeee-34786853021f@oracle.com>
	<a43d3eba-5d13-48de-0f83-2efa664da2a3@oracle.com>
	<8c7239fe-51c8-c8f4-84b2-87e16295761d@oracle.com>
	<f4a857cc-ebd4-8c65-fd3c-ff9adf4389f3@oracle.com>
	<fb98b819-4ace-170c-e128-68c6d50b167a@oracle.com>
	<1baec804-931e-f85f-614d-49e79960e472@oracle.com>
	<8e556458-1d5d-6fab-3528-ece33f050df6@oracle.com>
	<a8f9bacb-f26b-0902-334b-ca403b864b3f@oracle.com>
	<1dd8b948-fd63-8b42-da08-b81e7e026a4a@oracle.com>
	<9fe33c67-0a4e-182b-b5a7-e76025d8f914@oracle.com>
Message-ID: <70f11f35-78f4-7794-d951-31d65e4a5767@oracle.com>

On 20.10.16 9:36, Semyon Sadetsky wrote:
>> The code which you tried to revert if not correct. The previous change
>> was done as a fix for HiDPI support. Lots of our code depends from the
>> XWindow.scaleUp/scaleDown/getScale which ware implemented on top of
>> graphicsConfig. If it was not updated then this is a serious bug.
> XWindow.scaleUp/scaleDown/getScale do not depend on screen on Linux.

How it is possible since scaleXX use the graphics config of the window?

> I proposed to do same to investigate the problem. Does it mean that you
> approve the current fix?

No, this is one is a separate bug. and I already described why.

> But severity of this bug is rather low because it is internal problem
> that does not affect user experience. It may be deferred to the next
> major JDK release.
>
> Also note, that the same bug was already closed as "won't fix" before:
> https://bugs.openjdk.java.net/browse/JDK-5100801
>
> --Semyon


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Wed Oct 26 06:31:32 2016
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 26 Oct 2016 12:01:32 +0530
Subject: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test
 java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X
In-Reply-To: <1247e0ac-ddda-4ccd-bec5-0b91c77e2ea0@default>
References: <2e81eb8a-5043-4ebd-aa66-f12d9220547f@default>
	<2bc29816-a861-4b38-8a96-d0a87be29b56@default>
	<55bdc1e0-2302-4d13-8b39-933fb4005b1b@default>
	<1247e0ac-ddda-4ccd-bec5-0b91c77e2ea0@default>
Message-ID: <4d95666d-19eb-b196-581b-8b5a49268648@oracle.com>

Hi Prem,

+1 to 8168292 but one thing is that this issue is created to enable to 
work on 8168291 and was mentioned that the problem DragEventSource fails 
on osx will be addressed as part of 8168292 which I do not see being 
done in your webrev.
So, either open up 8168291 or fix it in this bug.

Regards
Prasanta
On 10/25/2016 2:25 PM, Ajit Ghaisas wrote:
>
> Looks fine.
>
> Regards,
>
> Ajit
>
> *From:* Prem Balakrishnan
> *Sent:* Monday, October 24, 2016 3:16 PM
> *To:* Ajit Ghaisas; Alexander Scherbatiy; Rajeev Chamyal; 
> awt-dev at openjdk.java.net
> *Subject:* RE: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test 
> java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X
>
> Hi Ajit,
>
> Thankyou for the review.
>
> Updated patch as per review comments.
>
> http://cr.openjdk.java.net/~pkbalakr/8168292/webrev.01/ 
> <http://cr.openjdk.java.net/%7Epkbalakr/8168292/webrev.01/>
>
> Regards,
>
> Prem
>
> *From:*Ajit Ghaisas
> *Sent:* Monday, October 24, 2016 2:00 PM
> *To:* Prem Balakrishnan; Alexander Scherbatiy; Rajeev Chamyal; 
> awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
> *Subject:* RE: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test 
> java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X
>
> Hi Prem,
>
>     I know this is compilation fix, but still few corrections can be 
> made to the test.
>
> 1.Please replace generic imports to specific class imports.
>
> 2.First sentence of the instruction text has a typo ? please correct it.
>
> Existing  : ?Use see a Frame with a button in it."
>
> Should be : ?User sees a Frame with a button on it."
>
> Regards,
>
> Ajit
>
> *From:* Prem Balakrishnan
> *Sent:* Thursday, October 20, 2016 3:00 PM
> *To:* Alexander Scherbatiy; Rajeev Chamyal; awt-dev at openjdk.java.net 
> <mailto:awt-dev at openjdk.java.net>
> *Subject:* <AWT Dev> Review Request : JDK-8168292 [TestBug]Test 
> java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X
>
> Hi,
>
> Please review the patch.
>
> *Test Bug: *https://bugs.openjdk.java.net/browse/JDK-8168292**
>
> *Webrev: *http://cr.openjdk.java.net/~pkbalakr/8168292/webrev.00/ 
> <http://cr.openjdk.java.net/%7Epkbalakr/8168292/webrev.00/>
>
> Compilation error: Can't find library\: ../../../regtesthelpers
>
> Fix: updated the library path
>
> Regards,
>
> Prem**
>

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

From avik.niyogi at oracle.com  Wed Oct 26 07:36:25 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 26 Oct 2016 13:06:25 +0530
Subject: <AWT Dev> <Swing Dev> 8138771:
	java.awt.image.AbstractMultiResolutionImage needs customized
	spec for methods of Image which it implements
In-Reply-To: <188090ae-deb1-e117-ed57-9ae13aa1043d@oracle.com>
References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com>
	<9F556132-58E4-4303-81CC-C031C5023A21@oracle.com>
	<cedc93ea-31f4-8a8f-e2c1-f2cd374e37e1@oracle.com>
	<E2EAEE2F-0CA6-4DF1-8C6A-C000E9C3320C@oracle.com>
	<50687e80-f79e-4af4-b374-f1419aa575ee@oracle.com>
	<D3BAF844-2D99-42B2-85F6-DFAC9F25EF65@oracle.com>
	<faf1670e-3512-3f08-3a8e-a0c24ea41eae@oracle.com>
	<b44f3c81-e4e2-86b3-f7cf-63140244fac1@oracle.com>
	<55BBB3BD-2673-45F1-9DF3-950DE40DC43B@oracle.com>
	<188090ae-deb1-e117-ed57-9ae13aa1043d@oracle.com>
Message-ID: <E59EA84B-5F5D-4892-A27A-E82733FEDF1C@oracle.com>

Hi All,

Please review the proposed specification for JDK9 including inputs from reviver reviews.

cr.openjdk.java.net/~aniyogi/8138771/webrev.03/ <http://cr.openjdk.java.net/~aniyogi/8138771/webrev.03/>


Thank you in advance.

With Regards,
Avik Niyogi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161026/e2496a07/attachment.html>

From semyon.sadetsky at oracle.com  Wed Oct 26 13:06:09 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 26 Oct 2016 16:06:09 +0300
Subject: <AWT Dev> [9] Review request for 8167652: Making a frame/dialog
 resizeble/unresizeble shifts its position on Unity.
In-Reply-To: <2113be8e-f17e-ef55-27f8-de3d9c525b93@oracle.com>
References: <242ce147-4ff9-68c1-e5c7-278e1215fcda@oracle.com>
	<2113be8e-f17e-ef55-27f8-de3d9c525b93@oracle.com>
Message-ID: <d862f852-68a2-94c9-49a9-6a4253570ed0@oracle.com>

Please review the updated fix: 
http://cr.openjdk.java.net/~ssadetsky/8167652/webrev.01/

- unnecessary AWT locks are removed

- client code calls are taken away from AWT lock blocks

- some design improvements are made

--Semyon


On 10/19/2016 8:38 PM, Sergey Bylokhov wrote:
> Hi, Semyon.
> A few notes.
>  - The awtLock is a lowlevel lock which should be used only when we 
> access the xlib and some other native resource like opengl. We should 
> not call the users code on it. In the fix the code in 
> XDecoratedPeer.updateMinimumSize() will call the users code.
>  - Some of the changed methods are called already under this lock, for 
> example XDecoratedPeer.handlePropertyNotify(), and probably others.
>
> On 18.10.16 16:46, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK9:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8167652
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8167652/webrev.00/
>>
>> In Linux, when a frame or dilalog is made resizable or non-resizable the
>> window decoration need to be updated. For that purpose window is
>> unmapped and mapped again and WM changes the window decoration parent.
>> The re-parenting may cause WM to send intermediate "artifact events"
>> which change the window location on the screen, this WM behavior is
>> undocumented. To avoid window move the window shift is compensated in
>> XWM.setShellResizable()/XWM.setShellNotResizable(), but Unity WM shifts
>> the window position in different way. In the proposed solution the
>> window shift compensation is adjusted for Unity WM.
>>
>> Also in the fix all writes to the fields that store the current state of
>> window dimensions are protected with the AWT lock. This is necessary to
>> avoid unexpected window move or resize when the window dimensions are
>> changed from the user thread concurrently while the AWT toolkit thread
>> handles WM sent notifications affecting the current window state, size,
>> position, insets, etc.
>>
>> --Semyon
>>
>
>


From Sergey.Bylokhov at oracle.com  Wed Oct 26 15:43:46 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 26 Oct 2016 18:43:46 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <241007aa-5fdb-d6a6-f1f8-2eb83433ea69@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<350924c3-b5bf-41ea-551b-84ad813c3c03@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
	<f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
	<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>
	<f64fd14a-c99f-6dae-0d99-b730c6afcf48@oracle.com>
	<3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com>
	<b766f536-dbcd-3788-918e-5e99427f162b@oracle.com>
	<0e185822-ff1b-2041-baca-d5491ce2e4b8@oracle.com>
	<aaa011cc-6fe5-e7fe-ae03-b7cc1c017c39@oracle.com>
	<5888a670-6fc3-764c-c3cf-6703744b0d27@oracle.com>
	<5bda0f8a-5dfb-7356-5942-015fc27d6b07@oracle.com>
	<255c4e87-b58c-1d4d-30ca-97d1d9a710d0@oracle.com>
	<750f4ba6-5dea-7fb0-c7c1-c207d5cd2912@oracle.com>
	<f5659e98-9034-0b52-816b-b382c404069e@oracle.com>
	<241007aa-5fdb-d6a6-f1f8-2eb83433ea69@oracle.com>
Message-ID: <027efb5a-666e-debe-cd03-bccb25e7a4e5@oracle.com>

On 25.10.16 18:46, Semyon Sadetsky wrote:
>> I wonder why he should decide that the old code can be "simply
>> replaced" by the new one? I suppose that at least he should read the
>> specification of the new extended API. There is no notion that this
>> api is replaced by the new one, there is a recommendation that the new
>> one should be used instead.
> After reading such recommendation it's hard to conclude that one "should
> read the specification of the new extended API". Even "@see" tag
> pointing to the extended API is not provided (I'm not even mentioning
> the warning that the extended API may be nonequivalent replacement is
> absent). I read this recommendation as it is: replace one constant with
> another, no side effects expected.

Good to know that you don't read the specification of the methods before 
using. So what is your proposal? Should I add a notion that these 
extendent constants contains different int values, and if the user 
depends from them in some way then he should not replace the old one to 
the new one? Or what @see reference should be added from some fields to 
another?

>>
>>>> We already have a notions that these "extended modifier constant"
>>>> should be used in the constructor of InputEvent and moreover in spec
>>>> of getModifiersEx() we have an additional examples how to use this
>>>> constants. This is why we will have a reference from old constans to
>>>> the new, and from getModifiers() to the getModifiersEx();



-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Wed Oct 26 16:06:40 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 26 Oct 2016 19:06:40 +0300
Subject: <AWT Dev> <Swing Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <027efb5a-666e-debe-cd03-bccb25e7a4e5@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<5b0aac47-3f61-9b5f-667f-a2eb1ec6bc35@oracle.com>
	<7b725528-e7cf-35ae-7546-beb1ff67b90b@oracle.com>
	<7d479269-f38f-1c7a-3e80-bb0e77f2c232@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
	<f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
	<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>
	<f64fd14a-c99f-6dae-0d99-b730c6afcf48@oracle.com>
	<3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com>
	<b766f536-dbcd-3788-918e-5e99427f162b@oracle.com>
	<0e185822-ff1b-2041-baca-d5491ce2e4b8@oracle.com>
	<aaa011cc-6fe5-e7fe-ae03-b7cc1c017c39@oracle.com>
	<5888a670-6fc3-764c-c3cf-6703744b0d27@oracle.com>
	<5bda0f8a-5dfb-7356-5942-015fc27d6b07@oracle.com>
	<255c4e87-b58c-1d4d-30ca-97d1d9a710d0@oracle.com>
	<750f4ba6-5dea-7fb0-c7c1-c207d5cd2912@oracle.com>
	<f5659e98-9034-0b52-816b-b382c404069e@oracle.com>
	<241007aa-5fdb-d6a6-f1f8-2eb83433ea69@oracle.com>
	<027efb5a-666e-debe-cd03-bccb25e7a4e5@oracle.com>
Message-ID: <bc006214-ac0a-ca0e-7041-f586cf7cb910@oracle.com>



On 10/26/2016 6:43 PM, Sergey Bylokhov wrote:
> On 25.10.16 18:46, Semyon Sadetsky wrote:
>>> I wonder why he should decide that the old code can be "simply
>>> replaced" by the new one? I suppose that at least he should read the
>>> specification of the new extended API. There is no notion that this
>>> api is replaced by the new one, there is a recommendation that the new
>>> one should be used instead.
>> After reading such recommendation it's hard to conclude that one "should
>> read the specification of the new extended API". Even "@see" tag
>> pointing to the extended API is not provided (I'm not even mentioning
>> the warning that the extended API may be nonequivalent replacement is
>> absent). I read this recommendation as it is: replace one constant with
>> another, no side effects expected.
>
> Good to know that you don't read the specification of the methods 
> before using. So what is your proposal? Should I add a notion that 
> these extendent constants contains different int values, and if the 
> user depends from them in some way then he should not replace the old 
> one to the new one? Or what @see reference should be added from some 
> fields to another?
The proposal is the same to notify user that he/she should not only 
replace the constant but start to use another API. It's up to you how to 
formulate this. If I did this in minimalistic way I would write:

@deprecated It is recommended that SHIFT_DOWN_MASK and {@link 
getModifiersEx()} be used instead.
>
>>>
>>>>> We already have a notions that these "extended modifier constant"
>>>>> should be used in the constructor of InputEvent and moreover in spec
>>>>> of getModifiersEx() we have an additional examples how to use this
>>>>> constants. This is why we will have a reference from old constans to
>>>>> the new, and from getModifiers() to the getModifiersEx();
>
>
>


From james.graham at oracle.com  Wed Oct 26 21:03:42 2016
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 26 Oct 2016 14:03:42 -0700
Subject: <AWT Dev> <Swing Dev> 8138771:
 java.awt.image.AbstractMultiResolutionImage needs customized spec for
 methods of Image which it implements
In-Reply-To: <E59EA84B-5F5D-4892-A27A-E82733FEDF1C@oracle.com>
References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com>
	<9F556132-58E4-4303-81CC-C031C5023A21@oracle.com>
	<cedc93ea-31f4-8a8f-e2c1-f2cd374e37e1@oracle.com>
	<E2EAEE2F-0CA6-4DF1-8C6A-C000E9C3320C@oracle.com>
	<50687e80-f79e-4af4-b374-f1419aa575ee@oracle.com>
	<D3BAF844-2D99-42B2-85F6-DFAC9F25EF65@oracle.com>
	<faf1670e-3512-3f08-3a8e-a0c24ea41eae@oracle.com>
	<b44f3c81-e4e2-86b3-f7cf-63140244fac1@oracle.com>
	<55BBB3BD-2673-45F1-9DF3-950DE40DC43B@oracle.com>
	<188090ae-deb1-e117-ed57-9ae13aa1043d@oracle.com>
	<E59EA84B-5F5D-4892-A27A-E82733FEDF1C@oracle.com>
Message-ID: <435c659c-cb24-8d49-41ba-c5e15068957f@oracle.com>

The "@return" tags should not start with "returns" in the text.

Also, in the @return for getProperty(), insert a word "the" as "the property of the base image"...

			...jim

On 10/26/16 12:36 AM, Avik Niyogi wrote:
> Hi All,
>
> Please review the proposed specification for JDK9 including inputs from reviver reviews.
>
> *cr.openjdk.java.net/~aniyogi/8138771/webrev.03/* <http://cr.openjdk.java.net/~aniyogi/8138771/webrev.03/>
>
>
> Thank you in advance.
>
> With Regards,
> Avik Niyogi

From prem.balakrishnan at oracle.com  Thu Oct 27 06:21:18 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Wed, 26 Oct 2016 23:21:18 -0700 (PDT)
Subject: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test
 java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X
In-Reply-To: <4d95666d-19eb-b196-581b-8b5a49268648@oracle.com>
References: <2e81eb8a-5043-4ebd-aa66-f12d9220547f@default>
	<2bc29816-a861-4b38-8a96-d0a87be29b56@default>
	<55bdc1e0-2302-4d13-8b39-933fb4005b1b@default>
	<1247e0ac-ddda-4ccd-bec5-0b91c77e2ea0@default>
	<4d95666d-19eb-b196-581b-8b5a49268648@oracle.com>
Message-ID: <6981fff0-2b6f-4503-bd5f-41ac07cd4a7f@default>

Hi Prasanta,

 

Thankyou for the Review.

8168291 is  duplicate of 8168292, 

The suggested fix resolves issue both on Linux and OS X platforms .

 

Regards,

Prem

 

 

From: Prasanta Sadhukhan 
Sent: Wednesday, October 26, 2016 12:02 PM
To: Ajit Ghaisas; Prem Balakrishnan; Alexander Scherbatiy; Rajeev Chamyal; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X

 

Hi Prem,

+1 to 8168292 but one thing is that this issue is created to enable to work on 8168291 and was mentioned that the problem DragEventSource fails on osx will be addressed as part of 8168292 which I do not see being done in your webrev.
So, either open up 8168291 or fix it in this bug.

Regards
Prasanta

On 10/25/2016 2:25 PM, Ajit Ghaisas wrote:

Looks fine.

 

Regards,

Ajit

 

From: Prem Balakrishnan 
Sent: Monday, October 24, 2016 3:16 PM
To: Ajit Ghaisas; Alexander Scherbatiy; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: RE: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X

 

Hi Ajit,

 

Thankyou for the review.

Updated patch as per review comments.

HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8168292/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/8168292/webrev.01/ 

 

Regards,

Prem

 

From: Ajit Ghaisas 
Sent: Monday, October 24, 2016 2:00 PM
To: Prem Balakrishnan; Alexander Scherbatiy; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: RE: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X

 

Hi Prem,

 

    I know this is compilation fix, but still few corrections can be made to the test.

 

1.       Please replace generic imports to specific class imports.

2.       First sentence of the instruction text has a typo - please correct it.

Existing  : "Use see a Frame with a button in it." 

Should be : "User sees a Frame with a button on it."

 

Regards,

Ajit

 

From: Prem Balakrishnan 
Sent: Thursday, October 20, 2016 3:00 PM
To: Alexander Scherbatiy; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X

 

Hi,

 

Please review the patch.

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

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8168292/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8168292/webrev.00/ 

 

Compilation error: Can't find library\: ../../../regtesthelpers 

Fix: updated the library path

 

Regards,

Prem

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

From prasanta.sadhukhan at oracle.com  Thu Oct 27 06:24:17 2016
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 27 Oct 2016 11:54:17 +0530
Subject: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test
 java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X
In-Reply-To: <6981fff0-2b6f-4503-bd5f-41ac07cd4a7f@default>
References: <2e81eb8a-5043-4ebd-aa66-f12d9220547f@default>
	<2bc29816-a861-4b38-8a96-d0a87be29b56@default>
	<55bdc1e0-2302-4d13-8b39-933fb4005b1b@default>
	<1247e0ac-ddda-4ccd-bec5-0b91c77e2ea0@default>
	<4d95666d-19eb-b196-581b-8b5a49268648@oracle.com>
	<6981fff0-2b6f-4503-bd5f-41ac07cd4a7f@default>
Message-ID: <ee60884a-d27e-c870-ce4b-683792d7e643@oracle.com>

Ok. I guess 8168291

is not properly worded. It should have stated compilation issue there 
also. Anyways, this is good to go.

Regards
Prasanta
On 10/27/2016 11:51 AM, Prem Balakrishnan wrote:
>
> Hi Prasanta,
>
> Thankyou for the Review.
>
> 8168291 is  duplicate of 8168292,
>
> The suggested fix resolves issue both on Linux and OS X platforms .
>
> Regards,
>
> Prem
>
> *From:*Prasanta Sadhukhan
> *Sent:* Wednesday, October 26, 2016 12:02 PM
> *To:* Ajit Ghaisas; Prem Balakrishnan; Alexander Scherbatiy; Rajeev 
> Chamyal; awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> Review Request : JDK-8168292 [TestBug]Test 
> java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X
>
> Hi Prem,
>
> +1 to 8168292 but one thing is that this issue is created to enable to 
> work on 8168291 and was mentioned that the problem DragEventSource 
> fails on osx will be addressed as part of 8168292 which I do not see 
> being done in your webrev.
> So, either open up 8168291 or fix it in this bug.
>
> Regards
> Prasanta
>
> On 10/25/2016 2:25 PM, Ajit Ghaisas wrote:
>
>     Looks fine.
>
>     Regards,
>
>     Ajit
>
>     *From:* Prem Balakrishnan
>     *Sent:* Monday, October 24, 2016 3:16 PM
>     *To:* Ajit Ghaisas; Alexander Scherbatiy; Rajeev Chamyal;
>     awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>     *Subject:* RE: <AWT Dev> Review Request : JDK-8168292
>     [TestBug]Test
>     java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X
>
>     Hi Ajit,
>
>     Thankyou for the review.
>
>     Updated patch as per review comments.
>
>     http://cr.openjdk.java.net/~pkbalakr/8168292/webrev.01/
>     <http://cr.openjdk.java.net/%7Epkbalakr/8168292/webrev.01/>
>
>     Regards,
>
>     Prem
>
>     *From:*Ajit Ghaisas
>     *Sent:* Monday, October 24, 2016 2:00 PM
>     *To:* Prem Balakrishnan; Alexander Scherbatiy; Rajeev Chamyal;
>     awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>     *Subject:* RE: <AWT Dev> Review Request : JDK-8168292
>     [TestBug]Test
>     java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X
>
>     Hi Prem,
>
>         I know this is compilation fix, but still few corrections can
>     be made to the test.
>
>     1.Please replace generic imports to specific class imports.
>
>     2.First sentence of the instruction text has a typo ? please
>     correct it.
>
>     Existing  : ?Use see a Frame with a button in it."
>
>     Should be : ?User sees a Frame with a button on it."
>
>     Regards,
>
>     Ajit
>
>     *From:* Prem Balakrishnan
>     *Sent:* Thursday, October 20, 2016 3:00 PM
>     *To:* Alexander Scherbatiy; Rajeev Chamyal;
>     awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>     *Subject:* <AWT Dev> Review Request : JDK-8168292 [TestBug]Test
>     java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X
>
>     Hi,
>
>     Please review the patch.
>
>     *Test Bug: *https://bugs.openjdk.java.net/browse/JDK-8168292**
>
>     *Webrev: *http://cr.openjdk.java.net/~pkbalakr/8168292/webrev.00/
>     <http://cr.openjdk.java.net/%7Epkbalakr/8168292/webrev.00/>
>
>     Compilation error: Can't find library\: ../../../regtesthelpers
>
>     Fix: updated the library path
>
>     Regards,
>
>     Prem
>

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

From avik.niyogi at oracle.com  Thu Oct 27 06:51:29 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Thu, 27 Oct 2016 12:21:29 +0530
Subject: <AWT Dev> <Swing Dev> 8138771:
	java.awt.image.AbstractMultiResolutionImage needs customized
	spec for methods of Image which it implements
In-Reply-To: <435c659c-cb24-8d49-41ba-c5e15068957f@oracle.com>
References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com>
	<9F556132-58E4-4303-81CC-C031C5023A21@oracle.com>
	<cedc93ea-31f4-8a8f-e2c1-f2cd374e37e1@oracle.com>
	<E2EAEE2F-0CA6-4DF1-8C6A-C000E9C3320C@oracle.com>
	<50687e80-f79e-4af4-b374-f1419aa575ee@oracle.com>
	<D3BAF844-2D99-42B2-85F6-DFAC9F25EF65@oracle.com>
	<faf1670e-3512-3f08-3a8e-a0c24ea41eae@oracle.com>
	<b44f3c81-e4e2-86b3-f7cf-63140244fac1@oracle.com>
	<55BBB3BD-2673-45F1-9DF3-950DE40DC43B@oracle.com>
	<188090ae-deb1-e117-ed57-9ae13aa1043d@oracle.com>
	<E59EA84B-5F5D-4892-A27A-E82733FEDF1C@oracle.com>
	<435c659c-cb24-8d49-41ba-c5e15068957f@oracle.com>
Message-ID: <A6204837-2E54-47AB-B011-A3D6F764BD3D@oracle.com>

Hi All,

Please review the proposed specification for JDK9 including inputs from reviewer reviews.
http://cr.openjdk.java.net/~aniyogi/8138771/webrev.04/ <http://cr.openjdk.java.net/~aniyogi/8138771/webrev.04/>
Thank you in advance.

With Regards,
Avik Niyogi

> On 27-Oct-2016, at 2:33 am, Jim Graham <james.graham at oracle.com> wrote:
> 
> The "@return" tags should not start with "returns" in the text.
> 
> Also, in the @return for getProperty(), insert a word "the" as "the property of the base image"...
> 
> 			...jim
> 
> On 10/26/16 12:36 AM, Avik Niyogi wrote:
>> Hi All,
>> 
>> Please review the proposed specification for JDK9 including inputs from reviver reviews.
>> 
>> *cr.openjdk.java.net/~aniyogi/8138771/webrev.03/* <http://cr.openjdk.java.net/~aniyogi/8138771/webrev.03/>
>> 
>> 
>> Thank you in advance.
>> 
>> With Regards,
>> Avik Niyogi

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

From ajit.ghaisas at oracle.com  Thu Oct 27 09:02:00 2016
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Thu, 27 Oct 2016 02:02:00 -0700 (PDT)
Subject: <AWT Dev> Fix for JDK-8160146 : Resolve disabled GCC warning
 'deprecated-declarations' for libawt_xawt
Message-ID: <fdbdd4d8-2ed0-4b4d-a7d3-21e2e4dbc519@default>

Hi,

 

    Fix of HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8165232"JDK-8165232 has fixed the 'deprecated' warnings from libawt_xawt.

    Now, only removing warning suppression from makefile remains. This webrev does it.

 

    http://cr.openjdk.java.net/~aghaisas/8160146/webrev.0/

 

    I have run JPRT and builds are successful.

 

    Request you to review.

 

Regards,

Ajit

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

From erik.joelsson at oracle.com  Thu Oct 27 10:00:03 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 27 Oct 2016 12:00:03 +0200
Subject: <AWT Dev> Fix for JDK-8160146 : Resolve disabled GCC warning
 'deprecated-declarations' for libawt_xawt
In-Reply-To: <fdbdd4d8-2ed0-4b4d-a7d3-21e2e4dbc519@default>
References: <fdbdd4d8-2ed0-4b4d-a7d3-21e2e4dbc519@default>
Message-ID: <7de3eaf1-f9b3-a8be-d409-620a1e0ad2b3@oracle.com>

Looks good.

/Erik


On 2016-10-27 11:02, Ajit Ghaisas wrote:
> Hi,
>
>   
>
>      Fix of HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8165232"JDK-8165232 has fixed the 'deprecated' warnings from libawt_xawt.
>
>      Now, only removing warning suppression from makefile remains. This webrev does it.
>
>   
>
>      http://cr.openjdk.java.net/~aghaisas/8160146/webrev.0/
>
>   
>
>      I have run JPRT and builds are successful.
>
>   
>
>      Request you to review.
>
>   
>
> Regards,
>
> Ajit
>
>   


From manajit.halder at oracle.com  Thu Oct 27 11:08:58 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Thu, 27 Oct 2016 16:38:58 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-7153700: [macosx]
	add support for MouseMotionListener to the TrayIcon
In-Reply-To: <70786B07-6B64-49B0-A41E-2177CBEECF32@oracle.com>
References: <70786B07-6B64-49B0-A41E-2177CBEECF32@oracle.com>
Message-ID: <F92C2CFF-45D8-490D-8AA0-7CA02330E023@oracle.com>

Hi Sergey,

Code is modified to correct a memory leak. Please review the modified webrev:
http://cr.openjdk.java.net/~mhalder/7153700/webrev.01/ <http://cr.openjdk.java.net/~mhalder/7153700/webrev.01/>

Thanks,
Manajit

> On 21-Oct-2016, at 1:20 pm, Manajit Halder <manajit.halder at oracle.com> wrote:
> 
> Hi All,
> 
> Kindly review the fix for JDK9.
> 
> Bug: 
> https://bugs.openjdk.java.net/browse/JDK-7153700 <https://bugs.openjdk.java.net/browse/JDK-7153700>
> 
> Webrev: 
> http://cr.openjdk.java.net/~mhalder/7153700/webrev.00/ <http://cr.openjdk.java.net/~mhalder/7153700/webrev.00/>
> 
> Issue: 
> [macosx] add support for MouseMotionListener to the TrayIcon.
> 
> Fix: 
> Added MouseMotionListener support for TrayIcon on Mac OS X.
> 
> Regards,
> Manajit

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

From manajit.halder at oracle.com  Thu Oct 27 11:18:58 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Thu, 27 Oct 2016 16:48:58 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8165680: [macosx]
	Enhance handling of UTF-8 characters in CDataTransfer.java
Message-ID: <68E6D05F-363B-4E08-9933-3AC8E435108C@oracle.com>

Hi All,

Kindly review the fix for JDK9.

Bug: 
https://bugs.openjdk.java.net/browse/JDK-8165680 <https://bugs.openjdk.java.net/browse/JDK-8165680>

Webrev: 
http://cr.openjdk.java.net/~mhalder/8165680/webrev.00/ <http://cr.openjdk.java.net/~mhalder/8165680/webrev.00/>

Issue: 
[macosx] Enhance handling of UTF-8 characters in CDataTransfer.java

Fix: 
Improved handling of UTF_8 characters by avoiding unnecessary lookup.

Regards,
Manajit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20161027/20c8251c/attachment.html>

From Sergey.Bylokhov at oracle.com  Thu Oct 27 11:35:48 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 27 Oct 2016 14:35:48 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-7153700: [macosx]
 add support for MouseMotionListener to the TrayIcon
In-Reply-To: <F92C2CFF-45D8-490D-8AA0-7CA02330E023@oracle.com>
References: <70786B07-6B64-49B0-A41E-2177CBEECF32@oracle.com>
	<F92C2CFF-45D8-490D-8AA0-7CA02330E023@oracle.com>
Message-ID: <f33c873d-4345-471c-edb3-7aa4c1bbcd31@oracle.com>

Hi, Manajit.

  179     if (trackingArea) {
  180         [self removeTrackingArea:trackingArea];
  181     }
I think that the code above is also not necessary(Since this code is 
executed only once). The pointer trackingArea is not initialized to nil 
so it can contains some non-nil garbage, and calling 
removeTrackingArea:trackingArea can cause a crash.

On 27.10.16 14:08, Manajit Halder wrote:
> Hi Sergey,
>
> Code is modified to correct a memory leak. Please review the modified
> webrev:
> _http://cr.openjdk.java.net/~mhalder/7153700/webrev.01/_
>
> Thanks,
> Manajit
>
>> On 21-Oct-2016, at 1:20 pm, Manajit Halder <manajit.halder at oracle.com
>> <mailto:manajit.halder at oracle.com>> wrote:
>>
>> Hi All,
>>
>> Kindly review the fix for JDK9.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-7153700
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mhalder/7153700/webrev.00/
>>
>> Issue:
>> [macosx] add support for MouseMotionListener to the TrayIcon.
>>
>> Fix:
>> Added MouseMotionListener support for TrayIcon on Mac OS X.
>>
>> Regards,
>> Manajit
>


-- 
Best regards, Sergey.

From prem.balakrishnan at oracle.com  Thu Oct 27 11:46:40 2016
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Thu, 27 Oct 2016 04:46:40 -0700 (PDT)
Subject: <AWT Dev> Review Request: 8159132 : [PIT][TEST_BUG]
 java/awt/FileDialog/FileDialogIconTest/FileDialogIconTest.java fails
Message-ID: <9863087b-fc12-4fae-a267-d0d56317e078@default>

Hi,

Please review fix for JDK 9,

 

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

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

 

It's a Test issue, pixel color fetched at wrong location.

 

Regards,

Prem

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

From alexandr.scherbatiy at oracle.com  Thu Oct 27 14:52:21 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Thu, 27 Oct 2016 17:52:21 +0300
Subject: <AWT Dev> Review Request: 8159132 : [PIT][TEST_BUG]
 java/awt/FileDialog/FileDialogIconTest/FileDialogIconTest.java fails
In-Reply-To: <9863087b-fc12-4fae-a267-d0d56317e078@default>
References: <9863087b-fc12-4fae-a267-d0d56317e078@default>
Message-ID: <5507a4c9-cea5-367f-f91b-dcde909b20aa@oracle.com>


The fix looks good to me.

Thanks,
Alexandr.

On 10/27/2016 2:46 PM, Prem Balakrishnan wrote:
>
> Hi,
>
> Please review fix for JDK 9,
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8159132
>
> Webrev: http://cr.openjdk.java.net/~pkbalakr/8159132/webrev.00/ 
> <http://cr.openjdk.java.net/%7Epkbalakr/8159132/webrev.00/>
>
> It?s a Test issue, pixel color fetched at wrong location.
>
> Regards,
>
> Prem
>

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

From ambarish.rapte at oracle.com  Thu Oct 27 15:21:58 2016
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Thu, 27 Oct 2016 08:21:58 -0700 (PDT)
Subject: <AWT Dev> Review Request For 8160766: [TEST_BUG]
	java/awt/Focus/DisposedWindow
Message-ID: <66fb880f-4c46-4e3f-a298-78d437b28547@default>

Hi All,

 

                Please review this test bug fix.

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

 

                This is small fix to add waitForIdle & delay. Webrev.00 is for reference of minimal changes.

                Webrev with minimum changes for review: http://cr.openjdk.java.net/~arapte/8160766/webrev.00/

 

                This is an applet based, so would be removing the applet.

                Final Webrev without applet: http://cr.openjdk.java.net/~arapte/8160766/webrev.01/

 

Regards,

Ambarish

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

From james.graham at oracle.com  Thu Oct 27 19:48:20 2016
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 27 Oct 2016 12:48:20 -0700
Subject: <AWT Dev> <Swing Dev> 8138771:
 java.awt.image.AbstractMultiResolutionImage needs customized spec for
 methods of Image which it implements
In-Reply-To: <A6204837-2E54-47AB-B011-A3D6F764BD3D@oracle.com>
References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com>
	<9F556132-58E4-4303-81CC-C031C5023A21@oracle.com>
	<cedc93ea-31f4-8a8f-e2c1-f2cd374e37e1@oracle.com>
	<E2EAEE2F-0CA6-4DF1-8C6A-C000E9C3320C@oracle.com>
	<50687e80-f79e-4af4-b374-f1419aa575ee@oracle.com>
	<D3BAF844-2D99-42B2-85F6-DFAC9F25EF65@oracle.com>
	<faf1670e-3512-3f08-3a8e-a0c24ea41eae@oracle.com>
	<b44f3c81-e4e2-86b3-f7cf-63140244fac1@oracle.com>
	<55BBB3BD-2673-45F1-9DF3-950DE40DC43B@oracle.com>
	<188090ae-deb1-e117-ed57-9ae13aa1043d@oracle.com>
	<E59EA84B-5F5D-4892-A27A-E82733FEDF1C@oracle.com>
	<435c659c-cb24-8d49-41ba-c5e15068957f@oracle.com>
	<A6204837-2E54-47AB-B011-A3D6F764BD3D@oracle.com>
Message-ID: <12b0de58-486b-5f0b-0bf5-9d2ea39d4d24@oracle.com>

Hi Avik,

My suggestion about adding a word "the" was not taken and a couple of other changes were made to the @return statements 
which are not optimal.  Let's reset and use the following @return statements for each of the methods (to mirror the way 
these are described in the Image base class):

getWidth() - @return the width of the base image, or -1 if the width is not yet known
getHeight() - @return the height of the base image, or -1 if the height is not yet known
getGraphics() - @return throws {@code UnsupportedOperationException}
getSource() - @return the image producer that produces the pixels for the base image
getProperty() - @return the value of the named property in the base image

(It would also be nice if the blank lines were the same in all of the doc comments.  Some comments have a couple of 
blank lines to separate the javadoc sections and others have no blank lines.  But, that doesn't affect correctness, it 
is just an easthetic issue...)

			...jim

On 10/26/16 11:51 PM, Avik Niyogi wrote:
> Hi All,
>
> Please review the proposed specification for JDK9 including inputs from reviewer reviews.
> *http://cr.openjdk.java.net/~aniyogi/8138771/webrev.04/*
> Thank you in advance.
>
> With Regards,
> Avik Niyogi
>
>> On 27-Oct-2016, at 2:33 am, Jim Graham <james.graham at oracle.com <mailto:james.graham at oracle.com>> wrote:
>>
>> The "@return" tags should not start with "returns" in the text.
>>
>> Also, in the @return for getProperty(), insert a word "the" as "the property of the base image"...
>>
>> ...jim
>>
>> On 10/26/16 12:36 AM, Avik Niyogi wrote:
>>> Hi All,
>>>
>>> Please review the proposed specification for JDK9 including inputs from reviver reviews.
>>>
>>> *cr.openjdk.java.net/~aniyogi/8138771/webrev.03/* <http://cr.openjdk.java.net/~aniyogi/8138771/webrev.03/*>
>>> <http://cr.openjdk.java.net/~aniyogi/8138771/webrev.03/>
>>>
>>>
>>> Thank you in advance.
>>>
>>> With Regards,
>>> Avik Niyogi
>

From semyon.sadetsky at oracle.com  Fri Oct 28 10:12:53 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 28 Oct 2016 13:12:53 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <70f11f35-78f4-7794-d951-31d65e4a5767@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
	<04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
	<911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>
	<07ce3934-96fb-dc64-99df-995e5a0ca28a@oracle.com>
	<d88f1d0b-d467-324b-6237-84eeec50046e@oracle.com>
	<38787b3b-1356-977f-ca23-c6e728d3ceda@oracle.com>
	<29f01520-99b0-7438-02a5-51cc248be29d@oracle.com>
	<f45beddd-f4be-ac91-aeee-34786853021f@oracle.com>
	<a43d3eba-5d13-48de-0f83-2efa664da2a3@oracle.com>
	<8c7239fe-51c8-c8f4-84b2-87e16295761d@oracle.com>
	<f4a857cc-ebd4-8c65-fd3c-ff9adf4389f3@oracle.com>
	<fb98b819-4ace-170c-e128-68c6d50b167a@oracle.com>
	<1baec804-931e-f85f-614d-49e79960e472@oracle.com>
	<8e556458-1d5d-6fab-3528-ece33f050df6@oracle.com>
	<a8f9bacb-f26b-0902-334b-ca403b864b3f@oracle.com>
	<1dd8b948-fd63-8b42-da08-b81e7e026a4a@oracle.com>
	<9fe33c67-0a4e-182b-b5a7-e76025d8f914@oracle.com>
	<70f11f35-78f4-7794-d951-31d65e4a5767@oracle.com>
Message-ID: <464a6fc9-8726-8d05-beda-42e944341b5c@oracle.com>



On 10/25/2016 7:44 PM, Sergey Bylokhov wrote:
> On 20.10.16 9:36, Semyon Sadetsky wrote:
>>> The code which you tried to revert if not correct. The previous change
>>> was done as a fix for HiDPI support. Lots of our code depends from the
>>> XWindow.scaleUp/scaleDown/getScale which ware implemented on top of
>>> graphicsConfig. If it was not updated then this is a serious bug.
>> XWindow.scaleUp/scaleDown/getScale do not depend on screen on Linux.
>
> How it is possible since scaleXX use the graphics config of the window?
Because on linux we do not support different scales only the same scale.
>
>> I proposed to do same to investigate the problem. Does it mean that you
>> approve the current fix?
>
> No, this is one is a separate bug. and I already described why.
But do you have any other concerns to the current fix?
>
>> But severity of this bug is rather low because it is internal problem
>> that does not affect user experience. It may be deferred to the next
>> major JDK release.
>>
>> Also note, that the same bug was already closed as "won't fix" before:
>> https://bugs.openjdk.java.net/browse/JDK-5100801
>>
>> --Semyon
>
>


From ajit.ghaisas at oracle.com  Mon Oct 31 06:30:32 2016
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Sun, 30 Oct 2016 23:30:32 -0700 (PDT)
Subject: <AWT Dev> Review Request: 8159132 : [PIT][TEST_BUG]
 java/awt/FileDialog/FileDialogIconTest/FileDialogIconTest.java fails
In-Reply-To: <5507a4c9-cea5-367f-f91b-dcde909b20aa@oracle.com>
References: <9863087b-fc12-4fae-a267-d0d56317e078@default>
	<5507a4c9-cea5-367f-f91b-dcde909b20aa@oracle.com>
Message-ID: <beeeb2d5-bd36-4ad5-b0ee-38d48b038b5c@default>

Fix looks good.

 

Regards,

Ajit

 

From: Alexandr Scherbatiy 
Sent: Thursday, October 27, 2016 8:22 PM
To: Prem Balakrishnan; Ajit Ghaisas; awt-dev at openjdk.java.net
Subject: Re: Review Request: 8159132 : [PIT][TEST_BUG] java/awt/FileDialog/FileDialogIconTest/FileDialogIconTest.java fails

 


The fix looks good to me.

Thanks,
Alexandr.

On 10/27/2016 2:46 PM, Prem Balakrishnan wrote:

Hi,

Please review fix for JDK 9,

 

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

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8159132/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8159132/webrev.00/ 

 

It's a Test issue, pixel color fetched at wrong location.

 

Regards,

Prem

 

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

From avik.niyogi at oracle.com  Mon Oct 31 06:53:21 2016
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Mon, 31 Oct 2016 12:23:21 +0530
Subject: <AWT Dev> <Swing Dev> 8138771:
	java.awt.image.AbstractMultiResolutionImage needs customized
	spec for methods of Image which it implements
In-Reply-To: <12b0de58-486b-5f0b-0bf5-9d2ea39d4d24@oracle.com>
References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com>
	<9F556132-58E4-4303-81CC-C031C5023A21@oracle.com>
	<cedc93ea-31f4-8a8f-e2c1-f2cd374e37e1@oracle.com>
	<E2EAEE2F-0CA6-4DF1-8C6A-C000E9C3320C@oracle.com>
	<50687e80-f79e-4af4-b374-f1419aa575ee@oracle.com>
	<D3BAF844-2D99-42B2-85F6-DFAC9F25EF65@oracle.com>
	<faf1670e-3512-3f08-3a8e-a0c24ea41eae@oracle.com>
	<b44f3c81-e4e2-86b3-f7cf-63140244fac1@oracle.com>
	<55BBB3BD-2673-45F1-9DF3-950DE40DC43B@oracle.com>
	<188090ae-deb1-e117-ed57-9ae13aa1043d@oracle.com>
	<E59EA84B-5F5D-4892-A27A-E82733FEDF1C@oracle.com>
	<435c659c-cb24-8d49-41ba-c5e15068957f@oracle.com>
	<A6204837-2E54-47AB-B011-A3D6F764BD3D@oracle.com>
	<12b0de58-486b-5f0b-0bf5-9d2ea39d4d24@oracle.com>
Message-ID: <AA86B8E7-8F2D-490E-90A9-90B7BA48F9E8@oracle.com>

Hi All,
Please review the proposed specification for JDK9 including inputs from reviewer reviews.
cr.openjdk.java.net/~aniyogi/8138771/webrev.05/ <http://cr.openjdk.java.net/~aniyogi/8138771/webrev.05/>
Thank you in advance.

With Regards,
Avik Niyogi
> On 28-Oct-2016, at 1:18 am, Jim Graham <james.graham at oracle.com> wrote:
> 
> Hi Avik,
> 
> My suggestion about adding a word "the" was not taken and a couple of other changes were made to the @return statements which are not optimal.  Let's reset and use the following @return statements for each of the methods (to mirror the way these are described in the Image base class):
> 
> getWidth() - @return the width of the base image, or -1 if the width is not yet known
> getHeight() - @return the height of the base image, or -1 if the height is not yet known
> getGraphics() - @return throws {@code UnsupportedOperationException}
> getSource() - @return the image producer that produces the pixels for the base image
> getProperty() - @return the value of the named property in the base image
> 
> (It would also be nice if the blank lines were the same in all of the doc comments.  Some comments have a couple of blank lines to separate the javadoc sections and others have no blank lines.  But, that doesn't affect correctness, it is just an easthetic issue...)
> 
> 			...jim
> 
> On 10/26/16 11:51 PM, Avik Niyogi wrote:
>> Hi All,
>> 
>> Please review the proposed specification for JDK9 including inputs from reviewer reviews.
>> *http://cr.openjdk.java.net/~aniyogi/8138771/webrev.04/*
>> Thank you in advance.
>> 
>> With Regards,
>> Avik Niyogi
>> 
>>> On 27-Oct-2016, at 2:33 am, Jim Graham <james.graham at oracle.com <mailto:james.graham at oracle.com>> wrote:
>>> 
>>> The "@return" tags should not start with "returns" in the text.
>>> 
>>> Also, in the @return for getProperty(), insert a word "the" as "the property of the base image"...
>>> 
>>> ...jim
>>> 
>>> On 10/26/16 12:36 AM, Avik Niyogi wrote:
>>>> Hi All,
>>>> 
>>>> Please review the proposed specification for JDK9 including inputs from reviver reviews.
>>>> 
>>>> *cr.openjdk.java.net/~aniyogi/8138771/webrev.03/* <http://cr.openjdk.java.net/~aniyogi/8138771/webrev.03/*>
>>>> <http://cr.openjdk.java.net/~aniyogi/8138771/webrev.03/>
>>>> 
>>>> 
>>>> Thank you in advance.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>> 

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

From james.graham at oracle.com  Mon Oct 31 18:31:39 2016
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 31 Oct 2016 11:31:39 -0700
Subject: <AWT Dev> <Swing Dev> 8138771:
 java.awt.image.AbstractMultiResolutionImage needs customized spec for
 methods of Image which it implements
In-Reply-To: <AA86B8E7-8F2D-490E-90A9-90B7BA48F9E8@oracle.com>
References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com>
	<9F556132-58E4-4303-81CC-C031C5023A21@oracle.com>
	<cedc93ea-31f4-8a8f-e2c1-f2cd374e37e1@oracle.com>
	<E2EAEE2F-0CA6-4DF1-8C6A-C000E9C3320C@oracle.com>
	<50687e80-f79e-4af4-b374-f1419aa575ee@oracle.com>
	<D3BAF844-2D99-42B2-85F6-DFAC9F25EF65@oracle.com>
	<faf1670e-3512-3f08-3a8e-a0c24ea41eae@oracle.com>
	<b44f3c81-e4e2-86b3-f7cf-63140244fac1@oracle.com>
	<55BBB3BD-2673-45F1-9DF3-950DE40DC43B@oracle.com>
	<188090ae-deb1-e117-ed57-9ae13aa1043d@oracle.com>
	<E59EA84B-5F5D-4892-A27A-E82733FEDF1C@oracle.com>
	<435c659c-cb24-8d49-41ba-c5e15068957f@oracle.com>
	<A6204837-2E54-47AB-B011-A3D6F764BD3D@oracle.com>
	<12b0de58-486b-5f0b-0bf5-9d2ea39d4d24@oracle.com>
	<AA86B8E7-8F2D-490E-90A9-90B7BA48F9E8@oracle.com>
Message-ID: <9e118bd1-946d-d4dd-f328-fa975a78c6e4@oracle.com>

Looks good.  +1

		...jim

On 10/30/16 11:53 PM, Avik Niyogi wrote:
> Hi All,
> Please review the proposed specification for JDK9 including inputs from reviewer reviews.
> *cr.openjdk.java.net/~aniyogi/8138771/webrev.05/* <http://cr.openjdk.java.net/~aniyogi/8138771/webrev.05/>
> Thank you in advance.
>
> With Regards,
> Avik Niyogi
>> On 28-Oct-2016, at 1:18 am, Jim Graham <james.graham at oracle.com <mailto:james.graham at oracle.com>> wrote:
>>
>> Hi Avik,
>>
>> My suggestion about adding a word "the" was not taken and a couple of other changes were made to the @return
>> statements which are not optimal.  Let's reset and use the following @return statements for each of the methods (to
>> mirror the way these are described in the Image base class):
>>
>> getWidth() - @return the width of the base image, or -1 if the width is not yet known
>> getHeight() - @return the height of the base image, or -1 if the height is not yet known
>> getGraphics() - @return throws {@code UnsupportedOperationException}
>> getSource() - @return the image producer that produces the pixels for the base image
>> getProperty() - @return the value of the named property in the base image
>>
>> (It would also be nice if the blank lines were the same in all of the doc comments.  Some comments have a couple of
>> blank lines to separate the javadoc sections and others have no blank lines.  But, that doesn't affect correctness, it
>> is just an easthetic issue...)
>>
>> ...jim
>>
>> On 10/26/16 11:51 PM, Avik Niyogi wrote:
>>> Hi All,
>>>
>>> Please review the proposed specification for JDK9 including inputs from reviewer reviews.
>>> *http://cr.openjdk.java.net/~aniyogi/8138771/webrev.04/*
>>> Thank you in advance.
>>>
>>> With Regards,
>>> Avik Niyogi
>>>
>>>> On 27-Oct-2016, at 2:33 am, Jim Graham <james.graham at oracle.com <mailto:james.graham at oracle.com>
>>>> <mailto:james.graham at oracle.com>> wrote:
>>>>
>>>> The "@return" tags should not start with "returns" in the text.
>>>>
>>>> Also, in the @return for getProperty(), insert a word "the" as "the property of the base image"...
>>>>
>>>> ...jim
>>>>
>>>> On 10/26/16 12:36 AM, Avik Niyogi wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review the proposed specification for JDK9 including inputs from reviver reviews.
>>>>>
>>>>> *cr.openjdk.java.net/~aniyogi/8138771/webrev.03/* <http://cr.openjdk.java.net/~aniyogi/8138771/webrev.03/*>
>>>>> <http://cr.openjdk.java.net/~aniyogi/8138771/webrev.03/*>
>>>>> <http://cr.openjdk.java.net/~aniyogi/8138771/webrev.03/>
>>>>>
>>>>>
>>>>> Thank you in advance.
>>>>>
>>>>> With Regards,
>>>>> Avik Niyogi
>>>
>