From krishna.addepalli at oracle.com  Tue Aug  1 09:13:42 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 1 Aug 2017 02:13:42 -0700 (PDT)
Subject: <AWT Dev> [10][JDK-8027154] [TESTBUG] Test
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
In-Reply-To: <29b8eb86-4938-42b3-949a-774e884cfb53@default>
References: <29b8eb86-4938-42b3-949a-774e884cfb53@default>
Message-ID: <894adede-5c40-4d7a-9fa2-afbe923da74f@default>

Hi Sergey,

?

Based on our conversation, could you provide your review comments for the fix?

?

Pasting the mail exchange below for reference:

?

?

The intent of the test is not modified by my changes. By having the second frame register a mouse move callback, it is made more explicit - when the mouse position should be queried, and what is the expected position it should contain. Also, since Frame2 has observed a mouse move, consequently, Frame1 should not report any mouse position.

?

?

-----Original Message-----

From: Sergey Bylokhov

Sent: Tuesday, August 1, 2017 2:13 AM

To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>

Cc: Ambarish Rapte <HYPERLINK "mailto:ambarish.rapte at oracle.com"ambarish.rapte at oracle.com>; Ajit Ghaisas <HYPERLINK "mailto:ajit.ghaisas at oracle.com"ajit.ghaisas at oracle.com>; Prem Balakrishnan <HYPERLINK "mailto:prem.balakrishnan at oracle.com"prem.balakrishnan at oracle.com>; Praveen Srivastava <HYPERLINK "mailto:praveen.s.srivastava at oracle.com"praveen.s.srivastava at oracle.com>; Prasanta Sadhukhan (HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"prasanta.sadhukhan at oracle.com) <HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"prasanta.sadhukhan at oracle.com>

Subject: Re: awt-dev Digest, Vol 123, Issue 9

?

You can modify the test as you wish to make it stable, just make sure that initial use case is covered.

?

On 27.07.2017 4:29, Krishna Addepalli wrote:

> Hi Sergey,

> 

> I have tested the modified test that you provided on Windows and Linux. 

> It was working fine on Windows without the sleep, but on Linux, the 

> behavior is a bit random. If I removed the sleep, it is crashing 

> always, but occasionally it crashed even for a 2 second sleep time.

> 

> I think, it is better not to rely on sleep, and instead, let frame2 

> have a mouse move callback registered, and then perform the required 

> checks, which guarantees a deterministic behavior, and also holds the 

> spirit of the intended test.

> 

> Could you review the patch that I submitted and let me know?

> 

> Thanks,

> 

> Krishna

> 

> *From:* Krishna Addepalli

> *Sent:* Tuesday, July 25, 2017 8:41 PM

> *To:* Sergey Bylokhov <HYPERLINK "mailto:sergey.bylokhov at oracle.com"sergey.bylokhov at oracle.com>

> *Cc:* Ambarish Rapte <HYPERLINK "mailto:ambarish.rapte at oracle.com"ambarish.rapte at oracle.com>; Ajit Ghaisas 

> <HYPERLINK "mailto:ajit.ghaisas at oracle.com"ajit.ghaisas at oracle.com>; Prem Balakrishnan 

> <HYPERLINK "mailto:prem.balakrishnan at oracle.com"prem.balakrishnan at oracle.com>; Praveen Srivastava 

> <HYPERLINK "mailto:praveen.s.srivastava at oracle.com"praveen.s.srivastava at oracle.com>

> *Subject:* RE: awt-dev Digest, Vol 123, Issue 9

> 

> Hi Sergey,

> 

> Thanks for your clarifications. That explains the reasons for

> Util.waitForIdle() not working in earlier versions.

> 

> So to summarize, the intent of the test is to create a new frame 

> (?Popup

> Frame?) for the MouseMove callback, and then have the new frame report 

> the expected mouse position, while the underlying frame should report 

> that mouse position is null, since it is no longer the active frame.

> 

> I have one more question:

> 

> In your code, you are sleeping for 2 seconds, after making the frame2 

> visible. Is this necessary? I have seen that, once we set frame2 

> visible, the mouse position can be immediately queried without the 

> need to wait. Is it done to make sure that the test works on older builds?

> 

> Out of curiosity, I wanted to know if you could see the same 

> failure(?Exception in thread "AWT-EventQueue-2"

> java.lang.RuntimeException: Not implemented?)that was reported in the 

> original bug?

> 

> Thanks,

> 

> Krishna

> 

> *From:* Sergey Bylokhov

> *Sent:* Tuesday, July 25, 2017 7:04 AM

> *To:* Krishna Addepalli <krishna.addepalli at oracle.com 

> <mailto:krishna.addepalli at oracle.com>>

> *Cc:* Ambarish Rapte <ambarish.rapte at oracle.com 

> <mailto:ambarish.rapte at oracle.com>>; Ajit Ghaisas 

> <HYPERLINK "mailto:ajit.ghaisas at oracle.com%20%3cmailto:ajit.ghaisas at oracle.com"ajit.ghaisas at oracle.com <mailto:ajit.ghaisas at oracle.com>>; Prem 

> Balakrishnan <prem.balakrishnan at oracle.com 

> <mailto:prem.balakrishnan at oracle.com>>; Praveen Srivastava 

> <praveen.s.srivastava at oracle.com 

> <mailto:praveen.s.srivastava at oracle.com>>

> *Subject:* Re: awt-dev Digest, Vol 123, Issue 9

> 

> Hi, Krishna.

> Here is my observation.

> When 8012026 bug was fixed the robot.waitForIdle() does not work 

> properly, but the test uses Util.waitForIdle(). When the robot was 

> fixed the implementation of Util.waitForIdle() was reworked.

> So if you use the old jdk and a new utils+test you will need to add 

> some delays.

> Another issue is for coordinates. When this bug was fixed we do not 

> get a mouse move event for the first mouseMove(149,149). But this bug 

> was fixed on osx long time ago.

> 

> I have attached an updated version of the test which fails on b109 and 

> pass on 110. For the current version of jdk delays/sleeps are not 

> necessary since waitForIdle should work.

> The steps which are tested:

>?? - Show frame1

>?? - Move the mouse over frame1

>?? - Show frame2 under the mouse

>?? - Check the mouse position reported by frame2

>?? - Check the mouse position reported by frame1

> 

> ----- HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com

> <mailto:krishna.addepalli at oracle.com>

> wrote:

>> 

> 

>> 

> 

>> 

> 

> Hi Sergey,

> 

> Any comments/concerns on the observations I sent?

> 

> Thanks,

> 

> Krishna

> 

>> 

> 

> *From:*Krishna Addepalli

>> *Sent:* Wednesday, July 19, 2017 3:40 PM

>> *To:* Sergey Bylokhov <sergey.bylokhov at oracle.com

> <mailto:sergey.bylokhov at oracle.com>>

>> *Cc:* Praveen Srivastava (HYPERLINK "mailto:praveen.s.srivastava at oracle.com"praveen.s.srivastava at oracle.com

> <mailto:praveen.s.srivastava at oracle.com>)

> <praveen.s.srivastava at oracle.com

> <mailto:praveen.s.srivastava at oracle.com>>; Prem Kumar Balakrishnan 

> (HYPERLINK "mailto:prem.balakrishnan at oracle.com"prem.balakrishnan at oracle.com <mailto:prem.balakrishnan at oracle.com>)

> <HYPERLINK "mailto:prem.balakrishnan at oracle.com%20%3cmailto:prem.balakrishnan at oracle.com"prem.balakrishnan at oracle.com <mailto:prem.balakrishnan at oracle.com>>;

> Ambarish Rajeshwar Rapte (HYPERLINK "mailto:ambarish.rapte at oracle.com"ambarish.rapte at oracle.com

> <mailto:ambarish.rapte at oracle.com>) <ambarish.rapte at oracle.com 

> <mailto:ambarish.rapte at oracle.com>>; Ajit Haribhau Ghaisas 

> (HYPERLINK "mailto:ajit.ghaisas at oracle.com"ajit.ghaisas at oracle.com <mailto:ajit.ghaisas at oracle.com>) 

> <HYPERLINK "mailto:ajit.ghaisas at oracle.com%20%3cmailto:ajit.ghaisas at oracle.com"ajit.ghaisas at oracle.com <mailto:ajit.ghaisas at oracle.com>>

>> *Subject:* RE: awt-dev Digest, Vol 123, Issue 9

> 

> Hi Sergey,

> 

> I have tried to reproduce the failure of the test in Mac, by 

> installing the jdk_1.8.0_b84 

> (http://jre.us.oracle.com/java/re/jdk/8/promoted/all/b84/bundles/macos

> x-x86_64

> ) that was mentioned in the parent bug (8012026).

> 

> Below are my observations:

> 

> *OS*

> 

> ??????????? 

> 

> *Test Type*

> 

> ??????????? 

> 

> *Result*

> 

> ??????????? 

> 

> *Remarks*

> 

> Mac

> 

> ??????????? 

> 

> Original Test

> 

> ??????????? 

> 

> Failure (Mouse position should be null)

> 

> ??????????? 

> 

> 1.It is not the expected failure though. It is supposed to fail with 

> "NotImpementedError".

> 

> 2.Also, looks like the "r.waitForIdle()" is not properly working, 

> which is why? the check for mouse position seems to be going through.

> 

> Mac

> 

> ??????????? 

> 

> Modified Test

> 

> (Added a delay between the two mouse move events)

> 

> ??????????? 

> 

> Failure (Wrong position reported. Should be [30,30] but was [29,29]

> 

> ??????????? 

> 

> 1.This is because, the logic of the test seems wrong.

> 

> 2.Since a delay was added between mouse events, this is allowing the 

> events to be processed in sequential order.

> 

> Mac

> 

> ??????????? 

> 

> Proposed Fix

> 

> ??????????? 

> 

> Pass

> 

> ??????????? 

> 

> Mac

> 

> ??????????? 

> 

> Applet attached with Bug 8012026

> 

> ??????????? 

> 

> Pass

> 

> ??????????? 

> 

> There is no failure ("NotImplementedError") observed in this case as well.

> 

> Windows/Linux

> 

> ??????????? 

> 

> Original Test

> 

> ??????????? 

> 

> Failure (Wrong position reported. Should be [30,30] but was [29,29]

> 

> ??????????? 

> 

> This is because, the logic of the test seems wrong.

> 

> Windows/Linus

> 

> ??????????? 

> 

> Proposed Fix

> 

> ??????????? 

> 

> Pass

> 

> ??????????? 

> 

> Based on the above, I have some comments about the test:

> 

> 1.The test in current form, does not logically make sense, since 

> either the mouse position check should be [29,29], or frame2 should 

> register a mouse callback, in which case the check makes sense.

> 

> 2.The original failure mentioned in the bug is not reproducible.

> 

> 3.Since the original failure is reported with applet, should the test 

> also have to be based on applet?

> 

> 4.Since the original bug is reported for mac, is the test intended to 

> run on Linux/Windows?

> 

> 5.Robot.waitForIdle() does not seem to work properly on Mac.

> 

> Could you suggest the course of action from here?

> 

> Thanks,

> 

> Krishna

> 

> -----Original Message-----

> 

> From: HYPERLINK "mailto:awt-dev-request at openjdk.java.net"awt-dev-request at openjdk.java.net 

> <mailto:awt-dev-request at openjdk.java.net>

> [mailto:awt-dev-request at openjdk.java.net]

> 

> Sent: Tuesday, July 18, 2017 5:30 PM

> 

> To: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>

> 

> Subject: awt-dev Digest, Vol 123, Issue 9

> 

> Send awt-dev mailing list submissions to

> 

> HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>

> 

> To subscribe or unsubscribe via the World Wide Web, visit

> 

> http://mail.openjdk.java.net/mailman/listinfo/awt-dev

> 

> or, via email, send a message with subject or body 'help' to

> 

> HYPERLINK "mailto:awt-dev-request at openjdk.java.net"awt-dev-request at openjdk.java.net

> <mailto:awt-dev-request at openjdk.java.net>

> 

> You can reach the person managing the list at

> 

> HYPERLINK "mailto:awt-dev-owner at openjdk.java.net"awt-dev-owner at openjdk.java.net <mailto:awt-dev-owner at openjdk.java.net>

> 

> When replying, please edit your Subject line so it is more specific 

> than

> "Re: Contents of awt-dev digest..."

> 

> Today's Topics:

> 

>???? 1. Re:? [10][JDK-8027154] [TESTBUG] Test

> 

>??????? 

> java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java

> 

>??????? fails (Sergey Bylokhov)

> 

> ----------------------------------------------------------------------

> 

?

Thanks,

Krishna

?

From: Sergey Bylokhov 
Sent: Tuesday, July 18, 2017 6:11 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>
Cc: awt-dev at openjdk.java.net; Ajit Ghaisas <ajit.ghaisas at oracle.com>; Praveen Srivastava <praveen.s.srivastava at oracle.com>
Subject: Re: [10][JDK-8027154] [TESTBUG] Test java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails

?

Hi, Krishna.
Can you please confirm that the initial bug JDK-8012026 can be reproduced by the updated test?
The updated test should fail before JDK-8012026 was fixed, and works after.

----- HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com wrote: 
> 

Hi All, 

Please review the fix for test bug:

Bug : JDK-8027154? HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8027154"<https://bugs.openjdk.java.net/browse/JDK-8027154>

JDK 10 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/Krishna/8027154/webrev00/"http://cr.openjdk.java.net/~pkbalakr/Krishna/8027154/webrev00/

Summary:

The test intends to check the mouse move on Frame2, which is drawn in the MouseMove callback for Frame1. 
> 

However, the code wrongly asserts for the expected mouse position on Frame2, which was just created. 
> 

Also, Frame2 has no callback registered for MouseMove, which is leading to different behaviors on different platforms.

On Windows and Linux, the assertion is thrown for Mouse Position whereas on Mac, a NullPointerException is thrown.
> 

After moving the code into the callback for Frame2, the test passes on all the platforms.
> 

Thanks,

Krishna
> 


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

From shashidhara.veerabhadraiah at oracle.com  Tue Aug  1 12:23:48 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 1 Aug 2017 05:23:48 -0700 (PDT)
Subject: <AWT Dev> [OpenJDK 2D-Dev] [10] JDK-8169044: The tray icon
 color is not green
In-Reply-To: <77d63925-9ab8-1c78-f586-20d7e171c254@oracle.com>
References: <37f1e6ba-6d3d-4f11-a4b8-15be341a7d35@default>
 <77d63925-9ab8-1c78-f586-20d7e171c254@oracle.com>
Message-ID: <29f6aec3-17f4-4225-ae61-74668fdc16f4@default>

Yes Jim. Per the current code base, it is defaulted to default screen.

To have the same tray icon being represented on multiple task bars would require updates to XSystemTrayPeer.java to replicate the message being sent to X11 to add a new tray icon for a particular screen(Currently it is done only for the default screen). The current X11 tray system uses XEMBED protocol to add system tray icons. 
Currently the screen is set to 0 which I think would refer to default screen and hence it adds tray icons only to the default screen. The X11 property '_NET_SYSTEM_TRAY_S[SCREEN_NUMBER]' allows access to the system tray of screen 'SCREEN_ NUMBER '. So we may need to use such mechanism to add the tray icon onto different screens. This may be different for windows and mac but will have a similar mechanism.

Thanks and regards,
Shashi

-----Original Message-----
From: Jim Graham 
Sent: Tuesday, August 1, 2017 2:14 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] [10] JDK-8169044: The tray icon color is not green

Will the tray icon canvas always be on the default screen?  I believe the latest MacOS and Win10 both allow menu bars and task bars on all monitors.  Linux may not be far behind...

			...jim

On 7/30/17 11:59 PM, Shashidhara Veerabhadraiah wrote:
> Hi, Kindly review a fix for JDK-8169044 where the non hi dpi icon was 
> picked among the icon set of hi dpi and a non hi dpi icons for a hi dpi display screen.
> 
> Issue: The non hi dpi icon is red in color (and hi dpi icon is green 
> in color) and was getting picked up among the set for a hi dpi display screen as shown below in the picture:
> 
> Solution and fix: The icon's buffered images are not subjected to the 
> scaling because of the hi dpi screen. Hence, the default non hi dpi 
> icon was getting picked up for rendering the tray icon. Now the source 
> code modified to apply necessary transformations to the bufferedimages to get the default icon based on the default display screen. Below is the output after the fix:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8169044
> 
> Webrev: http://cr.openjdk.java.net/~pkbalakr/shashi/8169044/webrev.00/
> 
> Thanks and regards,
> 
> Shashi
> 

From sergey.bylokhov at oracle.com  Tue Aug  1 20:48:12 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 1 Aug 2017 13:48:12 -0700 (PDT)
Subject: <AWT Dev> [10][JDK-8027154] [TESTBUG] Test
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
Message-ID: <2dd44065-7793-4556-925a-238d5910ab68@default>

Ok, looks fine. 
Thank you for clarification. 

----- krishna.addepalli at oracle.com wrote: 
> 
> 
> 

Hi Sergey, 



Based on our conversation, could you provide your review comments for the fix? 



Pasting the mail exchange below for reference: 





The intent of the test is not modified by my changes. By having the second frame register a mouse move callback, it is made more explicit - when the mouse position should be queried, and what is the expected position it should contain. Also, since Frame2 has observed a mouse move, consequently, Frame1 should not report any mouse position. 





-----Original Message----- 

From: Sergey Bylokhov 

Sent: Tuesday, August 1, 2017 2:13 AM 

To: Krishna Addepalli < krishna.addepalli at oracle.com > 

Cc: Ambarish Rapte < ambarish.rapte at oracle.com >; Ajit Ghaisas < ajit.ghaisas at oracle.com >; Prem Balakrishnan < prem.balakrishnan at oracle.com >; Praveen Srivastava < praveen.s.srivastava at oracle.com >; Prasanta Sadhukhan ( prasanta.sadhukhan at oracle.com ) < prasanta.sadhukhan at oracle.com > 

Subject: Re: awt-dev Digest, Vol 123, Issue 9 



You can modify the test as you wish to make it stable, just make sure that initial use case is covered. 



On 27.07.2017 4:29, Krishna Addepalli wrote: 

> Hi Sergey, 

> 

> I have tested the modified test that you provided on Windows and Linux. 

> It was working fine on Windows without the sleep, but on Linux, the 

> behavior is a bit random. If I removed the sleep, it is crashing 

> always, but occasionally it crashed even for a 2 second sleep time. 

> 

> I think, it is better not to rely on sleep, and instead, let frame2 

> have a mouse move callback registered, and then perform the required 

> checks, which guarantees a deterministic behavior, and also holds the 

> spirit of the intended test. 

> 

> Could you review the patch that I submitted and let me know? 

> 

> Thanks, 

> 

> Krishna 

> 

> *From:* Krishna Addepalli 

> *Sent:* Tuesday, July 25, 2017 8:41 PM 

> *To:* Sergey Bylokhov < sergey.bylokhov at oracle.com > 

> *Cc:* Ambarish Rapte < ambarish.rapte at oracle.com >; Ajit Ghaisas 

> < ajit.ghaisas at oracle.com >; Prem Balakrishnan 

> < prem.balakrishnan at oracle.com >; Praveen Srivastava 

> < praveen.s.srivastava at oracle.com > 

> *Subject:* RE: awt-dev Digest, Vol 123, Issue 9 

> 

> Hi Sergey, 

> 

> Thanks for your clarifications. That explains the reasons for 

> Util.waitForIdle() not working in earlier versions. 

> 

> So to summarize, the intent of the test is to create a new frame 

> (?Popup 

> Frame?) for the MouseMove callback, and then have the new frame report 

> the expected mouse position, while the underlying frame should report 

> that mouse position is null, since it is no longer the active frame. 

> 

> I have one more question: 

> 

> In your code, you are sleeping for 2 seconds, after making the frame2 

> visible. Is this necessary? I have seen that, once we set frame2 

> visible, the mouse position can be immediately queried without the 

> need to wait. Is it done to make sure that the test works on older builds? 

> 

> Out of curiosity, I wanted to know if you could see the same 

> failure(?Exception in thread "AWT-EventQueue-2" 

> java.lang.RuntimeException: Not implemented?)that was reported in the 

> original bug? 

> 

> Thanks, 

> 

> Krishna 

> 

> *From:* Sergey Bylokhov 

> *Sent:* Tuesday, July 25, 2017 7:04 AM 

> *To:* Krishna Addepalli <krishna.addepalli at oracle.com 

> < mailto:krishna.addepalli at oracle.com >> 

> *Cc:* Ambarish Rapte <ambarish.rapte at oracle.com 

> < mailto:ambarish.rapte at oracle.com >>; Ajit Ghaisas 

> < ajit.ghaisas at oracle.com <mailto:ajit.ghaisas at oracle.com >>; Prem 

> Balakrishnan <prem.balakrishnan at oracle.com 

> < mailto:prem.balakrishnan at oracle.com >>; Praveen Srivastava 

> <praveen.s.srivastava at oracle.com 

> < mailto:praveen.s.srivastava at oracle.com >> 

> *Subject:* Re: awt-dev Digest, Vol 123, Issue 9 

> 

> Hi, Krishna. 

> Here is my observation. 

> When 8012026 bug was fixed the robot.waitForIdle() does not work 

> properly, but the test uses Util.waitForIdle(). When the robot was 

> fixed the implementation of Util.waitForIdle() was reworked. 

> So if you use the old jdk and a new utils+test you will need to add 

> some delays. 

> Another issue is for coordinates. When this bug was fixed we do not 

> get a mouse move event for the first mouseMove(149,149). But this bug 

> was fixed on osx long time ago. 

> 

> I have attached an updated version of the test which fails on b109 and 

> pass on 110. For the current version of jdk delays/sleeps are not 

> necessary since waitForIdle should work. 

> The steps which are tested: 

> - Show frame1 

> - Move the mouse over frame1 

> - Show frame2 under the mouse 

> - Check the mouse position reported by frame2 

> - Check the mouse position reported by frame1 

> 

> ----- krishna.addepalli at oracle.com 

> < mailto:krishna.addepalli at oracle.com > 

> wrote: 

>> 

> 

>> 

> 

>> 

> 

> Hi Sergey, 

> 

> Any comments/concerns on the observations I sent? 

> 

> Thanks, 

> 

> Krishna 

> 

>> 

> 

> *From:*Krishna Addepalli 

>> *Sent:* Wednesday, July 19, 2017 3:40 PM 

>> *To:* Sergey Bylokhov <sergey.bylokhov at oracle.com 

> < mailto:sergey.bylokhov at oracle.com >> 

>> *Cc:* Praveen Srivastava ( praveen.s.srivastava at oracle.com 

> < mailto:praveen.s.srivastava at oracle.com >) 

> <praveen.s.srivastava at oracle.com 

> < mailto:praveen.s.srivastava at oracle.com >>; Prem Kumar Balakrishnan 

> ( prem.balakrishnan at oracle.com < mailto:prem.balakrishnan at oracle.com >) 

> < prem.balakrishnan at oracle.com <mailto:prem.balakrishnan at oracle.com >>; 

> Ambarish Rajeshwar Rapte ( ambarish.rapte at oracle.com 

> < mailto:ambarish.rapte at oracle.com >) <ambarish.rapte at oracle.com 

> < mailto:ambarish.rapte at oracle.com >>; Ajit Haribhau Ghaisas 

> ( ajit.ghaisas at oracle.com < mailto:ajit.ghaisas at oracle.com >) 

> < ajit.ghaisas at oracle.com <mailto:ajit.ghaisas at oracle.com >> 

>> *Subject:* RE: awt-dev Digest, Vol 123, Issue 9 

> 

> Hi Sergey, 

> 

> I have tried to reproduce the failure of the test in Mac, by 

> installing the jdk_1.8.0_b84 

> ( http://jre.us.oracle.com/java/re/jdk/8/promoted/all/b84/bundles/macos 

> x-x86_64 

> ) that was mentioned in the parent bug (8012026). 

> 

> Below are my observations: 

> 

> *OS* 

> 

> 

> 

> *Test Type* 

> 

> 

> 

> *Result* 

> 

> 

> 

> *Remarks* 

> 

> Mac 

> 

> 

> 

> Original Test 

> 

> 

> 

> Failure (Mouse position should be null) 

> 

> 

> 

> 1.It is not the expected failure though. It is supposed to fail with 

> "NotImpementedError". 

> 

> 2.Also, looks like the "r.waitForIdle()" is not properly working, 

> which is why the check for mouse position seems to be going through. 

> 

> Mac 

> 

> 

> 

> Modified Test 

> 

> (Added a delay between the two mouse move events) 

> 

> 

> 

> Failure (Wrong position reported. Should be [30,30] but was [29,29] 

> 

> 

> 

> 1.This is because, the logic of the test seems wrong. 

> 

> 2.Since a delay was added between mouse events, this is allowing the 

> events to be processed in sequential order. 

> 

> Mac 

> 

> 

> 

> Proposed Fix 

> 

> 

> 

> Pass 

> 

> 

> 

> Mac 

> 

> 

> 

> Applet attached with Bug 8012026 

> 

> 

> 

> Pass 

> 

> 

> 

> There is no failure ("NotImplementedError") observed in this case as well. 

> 

> Windows/Linux 

> 

> 

> 

> Original Test 

> 

> 

> 

> Failure (Wrong position reported. Should be [30,30] but was [29,29] 

> 

> 

> 

> This is because, the logic of the test seems wrong. 

> 

> Windows/Linus 

> 

> 

> 

> Proposed Fix 

> 

> 

> 

> Pass 

> 

> 

> 

> Based on the above, I have some comments about the test: 

> 

> 1.The test in current form, does not logically make sense, since 

> either the mouse position check should be [29,29], or frame2 should 

> register a mouse callback, in which case the check makes sense. 

> 

> 2.The original failure mentioned in the bug is not reproducible. 

> 

> 3.Since the original failure is reported with applet, should the test 

> also have to be based on applet? 

> 

> 4.Since the original bug is reported for mac, is the test intended to 

> run on Linux/Windows? 

> 

> 5.Robot.waitForIdle() does not seem to work properly on Mac. 

> 

> Could you suggest the course of action from here? 

> 

> Thanks, 

> 

> Krishna 

> 

> -----Original Message----- 

> 

> From: awt-dev-request at openjdk.java.net 

> < mailto:awt-dev-request at openjdk.java.net > 

> [ mailto:awt-dev-request at openjdk.java.net ] 

> 

> Sent: Tuesday, July 18, 2017 5:30 PM 

> 

> To: awt-dev at openjdk.java.net < mailto:awt-dev at openjdk.java.net > 

> 

> Subject: awt-dev Digest, Vol 123, Issue 9 

> 

> Send awt-dev mailing list submissions to 

> 

> awt-dev at openjdk.java.net < mailto:awt-dev at openjdk.java.net > 

> 

> To subscribe or unsubscribe via the World Wide Web, visit 

> 

> http://mail.openjdk.java.net/mailman/listinfo/awt-dev 

> 

> or, via email, send a message with subject or body 'help' to 

> 

> awt-dev-request at openjdk.java.net 

> < mailto:awt-dev-request at openjdk.java.net > 

> 

> You can reach the person managing the list at 

> 

> awt-dev-owner at openjdk.java.net < mailto:awt-dev-owner at openjdk.java.net > 

> 

> When replying, please edit your Subject line so it is more specific 

> than 

> "Re: Contents of awt-dev digest..." 

> 

> Today's Topics: 

> 

> 1. Re: [10][JDK-8027154] [TESTBUG] Test 

> 

> 

> java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java 

> 

> fails (Sergey Bylokhov) 

> 

> ---------------------------------------------------------------------- 

> 



Thanks, 

Krishna 



> 

From: Sergey Bylokhov 
> Sent: Tuesday, July 18, 2017 6:11 AM 
> To: Krishna Addepalli <krishna.addepalli at oracle.com> 
> Cc: awt-dev at openjdk.java.net; Ajit Ghaisas <ajit.ghaisas at oracle.com>; Praveen Srivastava <praveen.s.srivastava at oracle.com> 
> Subject: Re: [10][JDK-8027154] [TESTBUG] Test java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails 




Hi, Krishna. 
> Can you please confirm that the initial bug JDK-8012026 can be reproduced by the updated test? 
> The updated test should fail before JDK-8012026 was fixed, and works after. 
> 
> ----- krishna.addepalli at oracle.com wrote: 
> > 


Hi All, 



Please review the fix for test bug: 

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

JDK 10 Webrev: http://cr.openjdk.java.net/~pkbalakr/Krishna/8027154/webrev00/ 

Summary: 

The test intends to check the mouse move on Frame2, which is drawn in the MouseMove callback for Frame1. 
> > 

However, the code wrongly asserts for the expected mouse position on Frame2, which was just created. 
> > 

Also, Frame2 has no callback registered for MouseMove, which is leading to different behaviors on different platforms. 

On Windows and Linux, the assertion is thrown for Mouse Position whereas on Mac, a NullPointerException is thrown. 
> > 

After moving the code into the callback for Frame2, the test passes on all the platforms. 
> > 

Thanks, 

Krishna 
> > 


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

From sergey.bylokhov at oracle.com  Tue Aug  1 21:15:19 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 1 Aug 2017 14:15:19 -0700 (PDT)
Subject: <AWT Dev> [OpenJDK 2D-Dev] [10] JDK-8169044: The tray icon
 color is not green
Message-ID: <ce61a4cb-7050-4395-86d8-905a5412568c@default>

Hi, Shashi.
As far as I understand the "width/height" in the IconCanvas is a size of the TrayIcon in pixels. So on the normal screen it is should be 24(TRAY_ICON_WIDTH) pixels and on a HiDPI screen it should be 24*ScreenScale. The IconCanvas.width/height fields should reflect this size.

I am not sure but it looks like the current fix changes the "size" of the frame just for rendering(so we select HiDPI image) but did not change the size of the frame. So we draw the HiDPI image to non-HiDPI embedded frame.

----- shashidhara.veerabhadraiah at oracle.com wrote:

> Yes Jim. Per the current code base, it is defaulted to default
> screen.
> 
> To have the same tray icon being represented on multiple task bars
> would require updates to XSystemTrayPeer.java to replicate the message
> being sent to X11 to add a new tray icon for a particular
> screen(Currently it is done only for the default screen). The current
> X11 tray system uses XEMBED protocol to add system tray icons. 
> Currently the screen is set to 0 which I think would refer to default
> screen and hence it adds tray icons only to the default screen. The
> X11 property '_NET_SYSTEM_TRAY_S[SCREEN_NUMBER]' allows access to the
> system tray of screen 'SCREEN_ NUMBER '. So we may need to use such
> mechanism to add the tray icon onto different screens. This may be
> different for windows and mac but will have a similar mechanism.
> 
> Thanks and regards,
> Shashi
> 
> -----Original Message-----
> From: Jim Graham 
> Sent: Tuesday, August 1, 2017 2:14 AM
> To: Shashidhara Veerabhadraiah
> <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net;
> 2d-dev <2d-dev at openjdk.java.net>
> Subject: Re: [OpenJDK 2D-Dev] [10] JDK-8169044: The tray icon color is
> not green
> 
> Will the tray icon canvas always be on the default screen?  I believe
> the latest MacOS and Win10 both allow menu bars and task bars on all
> monitors.  Linux may not be far behind...
> 
> 			...jim
> 
> On 7/30/17 11:59 PM, Shashidhara Veerabhadraiah wrote:
> > Hi, Kindly review a fix for JDK-8169044 where the non hi dpi icon
> was 
> > picked among the icon set of hi dpi and a non hi dpi icons for a hi
> dpi display screen.
> > 
> > Issue: The non hi dpi icon is red in color (and hi dpi icon is green
> 
> > in color) and was getting picked up among the set for a hi dpi
> display screen as shown below in the picture:
> > 
> > Solution and fix: The icon's buffered images are not subjected to
> the 
> > scaling because of the hi dpi screen. Hence, the default non hi dpi
> 
> > icon was getting picked up for rendering the tray icon. Now the
> source 
> > code modified to apply necessary transformations to the
> bufferedimages to get the default icon based on the default display
> screen. Below is the output after the fix:
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8169044
> > 
> > Webrev:
> http://cr.openjdk.java.net/~pkbalakr/shashi/8169044/webrev.00/
> > 
> > Thanks and regards,
> > 
> > Shashi
> >

From alexander.zvegintsev at oracle.com  Wed Aug  2 05:34:56 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 2 Aug 2017 11:04:56 +0530
Subject: <AWT Dev> [10] Review request for 8178448: MenuBar item handler
	fired twice
Message-ID: <3a5d6cd7-a8e5-ad40-a727-fc3a7ddd8463@oracle.com>

Hi all,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/10/8178448/00/

for the issue

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

This Mac specific issue happens if setDefaultMenuBar() is called after 
setJMenuBar() with same instance of JMenuBar.

JFrame.setJMenuBar(mb);
Desktop.getDesktop().setDefaultMenuBar(mb);

-- 
Thanks,
Alexander.

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

From goetz.lindenmaier at sap.com  Wed Aug  2 09:12:34 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 2 Aug 2017 09:12:34 +0000
Subject: <AWT Dev> RFR(M): 8185500: [TESTBUG] Add keywords headful/printer
 in java/awt and javax tests.
Message-ID: <aa3a2c3e4834483a96736c24f480081d@sap.com>

Hi,

I looked at all the remaining tests failing in our test environment, and I
think I have now identified the last set of headful tests that lack the
@key headful tag.

Also, I identified a row of tests that require a printer. For these I introduced
the new keyword 'printer' and marked them accordingly.

A few tests threw NullPointerException in the finalizer if run headless,
I fixed that, too.

Please review this change:
http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.01/index.html

Thanks and best regards,
  Goetz.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170802/b8134162/attachment.html>

From dmitry.markov at oracle.com  Wed Aug  2 14:26:34 2017
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Wed, 2 Aug 2017 15:26:34 +0100
Subject: <AWT Dev> [10] Review request for 8177414: Missing key events on
 Mac Os
Message-ID: <85C456B4-01D1-4F54-933D-3E9228E358CA@oracle.com>

Hello,

Could you review a fix for jdk10, please?

   bug: https://bugs.openjdk.java.net/browse/JDK-8177414
   webrev: http://cr.openjdk.java.net/~dmarkov/8177414/webrev.00/

Problem description:
On OSX KEY_TYPED and KEY_PRESSED events might be lost if the input method such as ?British?, ?US International? is set. That is caused by the current implementation of keyDown() method (see AWTView.m) which is responsible for transmitting native KEY_PRESSED events to java layer. If the flag willBeHandledByComplexInputMethod is set, the method stops sending the events to the java layer. However in some cases we may not have InputMethod object and KEY_PRESSED events will be incorrectly dropped.

Fix:
In keyDown() we have to check InputMethod object and drop key events only when non-null InputMethod is present.

Testing:
I ran corresponding JCK and regression tests and did not observe any new failures.

Thanks,
Dmitry

From Sergey.Bylokhov at oracle.com  Wed Aug  2 15:42:58 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 2 Aug 2017 08:42:58 -0700
Subject: <AWT Dev> [10] Review request for 8178448: MenuBar item handler
 fired twice
In-Reply-To: <3a5d6cd7-a8e5-ad40-a727-fc3a7ddd8463@oracle.com>
References: <3a5d6cd7-a8e5-ad40-a727-fc3a7ddd8463@oracle.com>
Message-ID: <a9b66a31-e72d-6d2f-7989-a4acbad9811e@oracle.com>

Hi, Alex.
Is it possible to create a test for this issue? It will be similar to 
ActionListenerCalledTwiceTest

On 01.08.2017 22:34, Alexander Zvegintsev wrote:
> Hi all,
> 
> please review the fix
> 
> http://cr.openjdk.java.net/~azvegint/jdk/10/8178448/00/
> 
> for the issue
> 
> https://bugs.openjdk.java.net/browse/JDK-8178448
> 
> This Mac specific issue happens if setDefaultMenuBar() is called after 
> setJMenuBar() with same instance of JMenuBar.
> 
> JFrame.setJMenuBar(mb);
> Desktop.getDesktop().setDefaultMenuBar(mb);
> 
> -- 
> Thanks,
> Alexander.
> 


-- 
Best regards, Sergey.

From alexander.zvegintsev at oracle.com  Thu Aug  3 06:28:10 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 3 Aug 2017 11:58:10 +0530
Subject: <AWT Dev> [10] Review request for 8178448: MenuBar item handler
 fired twice
In-Reply-To: <a9b66a31-e72d-6d2f-7989-a4acbad9811e@oracle.com>
References: <3a5d6cd7-a8e5-ad40-a727-fc3a7ddd8463@oracle.com>
 <a9b66a31-e72d-6d2f-7989-a4acbad9811e@oracle.com>
Message-ID: <caf3e07a-181b-c629-00b9-60022b36e6b9@oracle.com>

Hi Sergey,

http://cr.openjdk.java.net/~azvegint/jdk/10/8178448/01/

I've updated the test.

The JFrame needs to be iconified because it is stealing the keyboard 
focus, so accelerators for menu items will not be triggered.


Thanks,
Alexander.

On 02/08/2017 21:12, Sergey Bylokhov wrote:
> Hi, Alex.
> Is it possible to create a test for this issue? It will be similar to 
> ActionListenerCalledTwiceTest
>
> On 01.08.2017 22:34, Alexander Zvegintsev wrote:
>> Hi all,
>>
>> please review the fix
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/10/8178448/00/
>>
>> for the issue
>>
>> https://bugs.openjdk.java.net/browse/JDK-8178448
>>
>> This Mac specific issue happens if setDefaultMenuBar() is called 
>> after setJMenuBar() with same instance of JMenuBar.
>>
>> JFrame.setJMenuBar(mb);
>> Desktop.getDesktop().setDefaultMenuBar(mb);
>>
>> -- 
>> Thanks,
>> Alexander.
>>
>
>


From manajit.halder at oracle.com  Thu Aug  3 13:27:26 2017
From: manajit.halder at oracle.com (Manajit Halder)
Date: Thu, 3 Aug 2017 18:57:26 +0530
Subject: <AWT Dev> <AWT dev>[10] Review request for JDK-8136999:
 [macosx] NSException and NPE in a crash test
In-Reply-To: <660631e0-ec50-48bb-942c-1e2d13744a6b@default>
References: <660631e0-ec50-48bb-942c-1e2d13744a6b@default>
Message-ID: <4FC2D595-6BD1-4768-8465-8CCAB438CCAA@oracle.com>

Hi Sergey,

Added the test case from the previous iteration of the fix. Please review the webrev:
http://cr.openjdk.java.net/~mhalder/8136999/webrev.01/ <http://cr.openjdk.java.net/~mhalder/8136999/webrev.01/>

Regards,
Manajit

> On 26-Jul-2017, at 10:32 PM, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
> 
> Hi, Manajit.
> Can you please add a test from the previous iteration of the fix:
> http://cr.openjdk.java.net/~alexsch/8136999/webrev.00 <http://cr.openjdk.java.net/~alexsch/8136999/webrev.00>
> 
> ----- manajit.halder at oracle.com <mailto:manajit.halder at oracle.com> wrote: 
> > 
> > Hi All,
> > 
> > 
> > Kindly review the fix for JDK10.
> > 
> > Bug: 
> > https://bugs.openjdk.java.net/browse/JDK-8136999 <https://bugs.openjdk.java.net/browse/JDK-8136999>
> > 
> > Webrev:
> > http://cr.openjdk.java.net/~mhalder/8136999/webrev.00/ <http://cr.openjdk.java.net/~mhalder/8136999/webrev.00/>
> > 
> > Fix:
> > The flushEvent method is not required as mentioned in the previous review mail (http://mail.openjdk.java.net/pipermail/awt-dev/2015-October/010201.html). <http://mail.openjdk.java.net/pipermail/awt-dev/2015-October/010201.html).> 
> > flushEvent related functionalities were modified while fixing issue JDK-8006634 <https://bugs.openjdk.java.net/browse/JDK-8006634>  and hence deleted flushEvent method. 
> > 
> > Regards,
> > Manajit

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

From Sergey.Bylokhov at oracle.com  Thu Aug  3 22:50:55 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 3 Aug 2017 15:50:55 -0700
Subject: <AWT Dev> [10] Review request for 8178448: MenuBar item handler
 fired twice
In-Reply-To: <caf3e07a-181b-c629-00b9-60022b36e6b9@oracle.com>
References: <3a5d6cd7-a8e5-ad40-a727-fc3a7ddd8463@oracle.com>
 <a9b66a31-e72d-6d2f-7989-a4acbad9811e@oracle.com>
 <caf3e07a-181b-c629-00b9-60022b36e6b9@oracle.com>
Message-ID: <d5b39430-4e1c-82d1-5f53-430ce4f8bf9b@oracle.com>

Looks fine.

On 02.08.2017 23:28, Alexander Zvegintsev wrote:
> Hi Sergey,
> 
> http://cr.openjdk.java.net/~azvegint/jdk/10/8178448/01/
> 
> I've updated the test.
> 
> The JFrame needs to be iconified because it is stealing the keyboard 
> focus, so accelerators for menu items will not be triggered.
> 
> 
> Thanks,
> Alexander.
> 
> On 02/08/2017 21:12, Sergey Bylokhov wrote:
>> Hi, Alex.
>> Is it possible to create a test for this issue? It will be similar to 
>> ActionListenerCalledTwiceTest
>>
>> On 01.08.2017 22:34, Alexander Zvegintsev wrote:
>>> Hi all,
>>>
>>> please review the fix
>>>
>>> http://cr.openjdk.java.net/~azvegint/jdk/10/8178448/00/
>>>
>>> for the issue
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8178448
>>>
>>> This Mac specific issue happens if setDefaultMenuBar() is called 
>>> after setJMenuBar() with same instance of JMenuBar.
>>>
>>> JFrame.setJMenuBar(mb);
>>> Desktop.getDesktop().setDefaultMenuBar(mb);
>>>
>>> -- 
>>> Thanks,
>>> Alexander.
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Aug  3 23:11:58 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 3 Aug 2017 16:11:58 -0700
Subject: <AWT Dev> <AWT dev>[10] Review request for JDK-8136999:
 [macosx] NSException and NPE in a crash test
In-Reply-To: <4FC2D595-6BD1-4768-8465-8CCAB438CCAA@oracle.com>
References: <660631e0-ec50-48bb-942c-1e2d13744a6b@default>
 <4FC2D595-6BD1-4768-8465-8CCAB438CCAA@oracle.com>
Message-ID: <cc70b05a-d843-04b5-e854-29e7f45b26e6@oracle.com>

Looks fine.

On 03.08.2017 6:27, Manajit Halder wrote:
> Hi Sergey,
> 
> Added the test case from the previous iteration of the fix. Please 
> review the webrev:
> http://cr.openjdk.java.net/~mhalder/8136999/webrev.01/
> 
> Regards,
> Manajit
> 
>> On 26-Jul-2017, at 10:32 PM, Sergey Bylokhov 
>> <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>> wrote:
>>
>> Hi, Manajit.
>> Can you please add a test from the previous iteration of the fix:
>> http://cr.openjdk.java.net/~alexsch/8136999/webrev.00
>>
>> -----manajit.halder at oracle.com <mailto:manajit.halder at oracle.com>wrote:
>> >
>> >Hi All,
>> >
>> >
>> >Kindly review the fix for JDK10.
>> >
>> >Bug:
>> >https://bugs.openjdk.java.net/browse/JDK-8136999
>> >
>> >Webrev:
>> >http://cr.openjdk.java.net/~mhalder/8136999/webrev.00/
>> >
>> >Fix:
>> >The flushEvent method is not required as mentioned in the previous 
>> review mail 
>> (http://mail.openjdk.java.net/pipermail/awt-dev/2015-October/010201.html).
>> >flushEvent related functionalities were modified while fixing issue 
>> JDK-8006634 <https://bugs.openjdk.java.net/browse/JDK-8006634>  
>> and hence deleted flushEvent method.
>> >
>> >Regards,
>> >Manajit
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Aug  4 00:07:02 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 3 Aug 2017 17:07:02 -0700
Subject: <AWT Dev> [10] Review request for 8177414: Missing key events
 on Mac Os
In-Reply-To: <85C456B4-01D1-4F54-933D-3E9228E358CA@oracle.com>
References: <85C456B4-01D1-4F54-933D-3E9228E358CA@oracle.com>
Message-ID: <971fc640-26fe-4897-9d27-49a04a86b846@oracle.com>

Looks fine.

On 02.08.2017 7:26, Dmitry Markov wrote:
> Hello,
> 
> Could you review a fix for jdk10, please?
> 
>     bug: https://bugs.openjdk.java.net/browse/JDK-8177414
>     webrev: http://cr.openjdk.java.net/~dmarkov/8177414/webrev.00/
> 
> Problem description:
> On OSX KEY_TYPED and KEY_PRESSED events might be lost if the input method such as ?British?, ?US International? is set. That is caused by the current implementation of keyDown() method (see AWTView.m) which is responsible for transmitting native KEY_PRESSED events to java layer. If the flag willBeHandledByComplexInputMethod is set, the method stops sending the events to the java layer. However in some cases we may not have InputMethod object and KEY_PRESSED events will be incorrectly dropped.
> 
> Fix:
> In keyDown() we have to check InputMethod object and drop key events only when non-null InputMethod is present.
> 
> Testing:
> I ran corresponding JCK and regression tests and did not observe any new failures.
> 
> Thanks,
> Dmitry
> 


-- 
Best regards, Sergey.

From manajit.halder at oracle.com  Fri Aug  4 11:40:48 2017
From: manajit.halder at oracle.com (Manajit Halder)
Date: Fri, 4 Aug 2017 17:10:48 +0530
Subject: <AWT Dev> <AWT dev>[10] Review request for JDK-8165863:[macosx]
 stack overflow in
 java/awt/Component/SetEnabledPerformance/SetEnabledPerformance.java
Message-ID: <BEEEF592-DFC8-4676-9659-7C24AE13610B@oracle.com>

Hi All,

Kindly review the fix for JDK10.

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

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

Root cause:
The problem was due to default JVM stack size, which was not enough for the creation of 10001 JButtons.

Fix:
Increased the JVM stack size to 2048k for this test case using JVM flag -Xss.

Regards,
Manajit

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

From goetz.lindenmaier at sap.com  Fri Aug  4 11:53:10 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 4 Aug 2017 11:53:10 +0000
Subject: <AWT Dev> RFR(M): 8185500: [TESTBUG] Add keywords
 headful/printer in java/awt and javax tests.
In-Reply-To: <aa3a2c3e4834483a96736c24f480081d@sap.com>
References: <aa3a2c3e4834483a96736c24f480081d@sap.com>
Message-ID: <44c26375532f4ae8b5f28e6865e807b3@sap.com>

Hi,

I added another approx. 20 tests which are headful but are run only on mac.
http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.01/

Best regards,
  Goetz.

> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Mittwoch, 2. August 2017 11:13
> To: awt-dev at openjdk.java.net
> Subject: RFR(M): 8185500: [TESTBUG] Add keywords headful/printer in
> java/awt and javax tests.
> 
> Hi,
> 
> I looked at all the remaining tests failing in our test environment, and I
> think I have now identified the last set of headful tests that lack the
> @key headful tag.
> 
> Also, I identified a row of tests that require a printer. For these I introduce
> the new keyword 'printer' and marked them accordingly.
> 
> A few tests threw NullPointerException in the finalizer if run headless,
> I fixed that, too.
> 
> Please review this change:
> 
> http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.01/index.html
> 
> Thanks and best regards,
>   Goetz.


From Sergey.Bylokhov at oracle.com  Fri Aug  4 13:55:41 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 4 Aug 2017 06:55:41 -0700
Subject: <AWT Dev> <AWT dev>[10] Review request for JDK-8165863:[macosx]
 stack overflow in
 java/awt/Component/SetEnabledPerformance/SetEnabledPerformance.java
In-Reply-To: <BEEEF592-DFC8-4676-9659-7C24AE13610B@oracle.com>
References: <BEEEF592-DFC8-4676-9659-7C24AE13610B@oracle.com>
Message-ID: <25615de5-99e5-d6d3-5e24-95f6a7c3bda9@oracle.com>

Hi, Manajit.
The code in the test and the code in the JButton does not have any 
recursion and use only loops. All buttons itself are stored in the heap 
not on the stack. Can you please clarify, where in our code the default 
size of the stack is too small?

On 04.08.2017 4:40, Manajit Halder wrote:
> Hi All,
> 
> Kindly review the fix for JDK10.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8165863
> 
> Webrev:
> http://cr.openjdk.java.net/~mhalder/8165863/webrev.00/
> 
> Root cause:
> The problem was due to default JVM stack size, which was not enough for 
> the creation of 10001 JButtons.
> 
> Fix:
> Increased the JVM stack size to 2048k for this test case using JVM flag 
> -Xss.
> 
> Regards,
> Manajit
> 


-- 
Best regards, Sergey.

From dmitry.markov at oracle.com  Fri Aug  4 13:58:55 2017
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Fri, 4 Aug 2017 14:58:55 +0100
Subject: <AWT Dev> [10] Review request for 8177414: Missing key events
 on Mac Os
In-Reply-To: <971fc640-26fe-4897-9d27-49a04a86b846@oracle.com>
References: <85C456B4-01D1-4F54-933D-3E9228E358CA@oracle.com>
 <971fc640-26fe-4897-9d27-49a04a86b846@oracle.com>
Message-ID: <BF5CE8FC-037C-4868-8CAC-7BED7CC55757@oracle.com>

Thank you, Sergey!

Looking for the second +1 from someone else.

Thanks,
Dmitry
> On 4 Aug 2017, at 01:07, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
> 
> Looks fine.
> 
> On 02.08.2017 7:26, Dmitry Markov wrote:
>> Hello,
>> Could you review a fix for jdk10, please?
>>    bug: https://bugs.openjdk.java.net/browse/JDK-8177414
>>    webrev: http://cr.openjdk.java.net/~dmarkov/8177414/webrev.00/
>> Problem description:
>> On OSX KEY_TYPED and KEY_PRESSED events might be lost if the input method such as ?British?, ?US International? is set. That is caused by the current implementation of keyDown() method (see AWTView.m) which is responsible for transmitting native KEY_PRESSED events to java layer. If the flag willBeHandledByComplexInputMethod is set, the method stops sending the events to the java layer. However in some cases we may not have InputMethod object and KEY_PRESSED events will be incorrectly dropped.
>> Fix:
>> In keyDown() we have to check InputMethod object and drop key events only when non-null InputMethod is present.
>> Testing:
>> I ran corresponding JCK and regression tests and did not observe any new failures.
>> Thanks,
>> Dmitry
> 
> 
> -- 
> Best regards, Sergey.


From philip.race at oracle.com  Fri Aug  4 14:00:29 2017
From: philip.race at oracle.com (Philip Race)
Date: Fri, 04 Aug 2017 07:00:29 -0700
Subject: <AWT Dev> [10] Review request for 8177414: Missing key events
 on Mac Os
In-Reply-To: <BF5CE8FC-037C-4868-8CAC-7BED7CC55757@oracle.com>
References: <85C456B4-01D1-4F54-933D-3E9228E358CA@oracle.com>
 <971fc640-26fe-4897-9d27-49a04a86b846@oracle.com>
 <BF5CE8FC-037C-4868-8CAC-7BED7CC55757@oracle.com>
Message-ID: <59847DFD.4020109@oracle.com>

Approved.

-phil.

On 8/4/17, 6:58 AM, Dmitry Markov wrote:
> Thank you, Sergey!
>
> Looking for the second +1 from someone else.
>
> Thanks,
> Dmitry
>> On 4 Aug 2017, at 01:07, Sergey Bylokhov<sergey.bylokhov at oracle.com>  wrote:
>>
>> Looks fine.
>>
>> On 02.08.2017 7:26, Dmitry Markov wrote:
>>> Hello,
>>> Could you review a fix for jdk10, please?
>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8177414
>>>     webrev: http://cr.openjdk.java.net/~dmarkov/8177414/webrev.00/
>>> Problem description:
>>> On OSX KEY_TYPED and KEY_PRESSED events might be lost if the input method such as ?British?, ?US International? is set. That is caused by the current implementation of keyDown() method (see AWTView.m) which is responsible for transmitting native KEY_PRESSED events to java layer. If the flag willBeHandledByComplexInputMethod is set, the method stops sending the events to the java layer. However in some cases we may not have InputMethod object and KEY_PRESSED events will be incorrectly dropped.
>>> Fix:
>>> In keyDown() we have to check InputMethod object and drop key events only when non-null InputMethod is present.
>>> Testing:
>>> I ran corresponding JCK and regression tests and did not observe any new failures.
>>> Thanks,
>>> Dmitry
>>
>> -- 
>> Best regards, Sergey.

From philip.race at oracle.com  Fri Aug  4 14:12:10 2017
From: philip.race at oracle.com (Philip Race)
Date: Fri, 04 Aug 2017 07:12:10 -0700
Subject: <AWT Dev> <AWT dev>[10] Review request for JDK-8165863:[macosx]
 stack overflow in
 java/awt/Component/SetEnabledPerformance/SetEnabledPerformance.java
In-Reply-To: <25615de5-99e5-d6d3-5e24-95f6a7c3bda9@oracle.com>
References: <BEEEF592-DFC8-4676-9659-7C24AE13610B@oracle.com>
 <25615de5-99e5-d6d3-5e24-95f6a7c3bda9@oracle.com>
Message-ID: <598480BA.7000907@oracle.com>

I don't know why but we do have recursion here :
     at 
java.awt.AWTEventMulticaster.componentMoved(java.desktop at 9ea/AWTEventMulticaster.java:177)
     at 
java.awt.AWTEventMulticaster.componentMoved(java.desktop at 9ea/AWTEventMulticaster.java:177)
     at 
java.awt.AWTEventMulticaster.componentMoved(java.desktop at 9ea/AWTEventMulticaster.java:177)
STATUS:Failed.`main' threw exception: java.lang.StackOverflowError

At the first line of this method :
     /**
      * Handles the componentMoved event by invoking the
      * componentMoved methods on listener-a and listener-b.
      * @param e the component event
      */
     public void componentMoved(ComponentEvent e) {
         ((ComponentListener)a).componentMoved(e);
         ((ComponentListener)b).componentMoved(e);
     }

That recursion surely should not be happening and I then don't know what 
breaks the recursion.
Maybe it isn't broken. May be the test gets to dispose() before then - 
once the stack size
is increased.

Whatever the cause the proposed fix seems to be missing the real problem.

-phil.

On 8/4/17, 6:55 AM, Sergey Bylokhov wrote:
> Hi, Manajit.
> The code in the test and the code in the JButton does not have any 
> recursion and use only loops. All buttons itself are stored in the 
> heap not on the stack. Can you please clarify, where in our code the 
> default size of the stack is too small?
>
> On 04.08.2017 4:40, Manajit Halder wrote:
>> Hi All,
>>
>> Kindly review the fix for JDK10.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8165863
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mhalder/8165863/webrev.00/
>>
>> Root cause:
>> The problem was due to default JVM stack size, which was not enough 
>> for the creation of 10001 JButtons.
>>
>> Fix:
>> Increased the JVM stack size to 2048k for this test case using JVM 
>> flag -Xss.
>>
>> Regards,
>> Manajit
>>
>
>

From dmitry.markov at oracle.com  Fri Aug  4 14:15:28 2017
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Fri, 4 Aug 2017 15:15:28 +0100
Subject: <AWT Dev> [10] Review request for 8177414: Missing key events
 on Mac Os
In-Reply-To: <59847DFD.4020109@oracle.com>
References: <85C456B4-01D1-4F54-933D-3E9228E358CA@oracle.com>
 <971fc640-26fe-4897-9d27-49a04a86b846@oracle.com>
 <BF5CE8FC-037C-4868-8CAC-7BED7CC55757@oracle.com>
 <59847DFD.4020109@oracle.com>
Message-ID: <43924BF2-A39A-4EE2-B519-EEE71056DFAD@oracle.com>

Thank you very much, Phil!

Regards,
Dmitry
> On 4 Aug 2017, at 15:00, Philip Race <philip.race at oracle.com> wrote:
> 
> Approved.
> 
> -phil.
> 
> On 8/4/17, 6:58 AM, Dmitry Markov wrote:
>> Thank you, Sergey!
>> 
>> Looking for the second +1 from someone else.
>> 
>> Thanks,
>> Dmitry
>>> On 4 Aug 2017, at 01:07, Sergey Bylokhov<sergey.bylokhov at oracle.com>  wrote:
>>> 
>>> Looks fine.
>>> 
>>> On 02.08.2017 7:26, Dmitry Markov wrote:
>>>> Hello,
>>>> Could you review a fix for jdk10, please?
>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8177414
>>>>    webrev: http://cr.openjdk.java.net/~dmarkov/8177414/webrev.00/
>>>> Problem description:
>>>> On OSX KEY_TYPED and KEY_PRESSED events might be lost if the input method such as ?British?, ?US International? is set. That is caused by the current implementation of keyDown() method (see AWTView.m) which is responsible for transmitting native KEY_PRESSED events to java layer. If the flag willBeHandledByComplexInputMethod is set, the method stops sending the events to the java layer. However in some cases we may not have InputMethod object and KEY_PRESSED events will be incorrectly dropped.
>>>> Fix:
>>>> In keyDown() we have to check InputMethod object and drop key events only when non-null InputMethod is present.
>>>> Testing:
>>>> I ran corresponding JCK and regression tests and did not observe any new failures.
>>>> Thanks,
>>>> Dmitry
>>> 
>>> -- 
>>> Best regards, Sergey.


From shashidhara.veerabhadraiah at oracle.com  Tue Aug  8 11:48:26 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 8 Aug 2017 04:48:26 -0700 (PDT)
Subject: <AWT Dev> [OpenJDK 2D-Dev] [10] JDK-8169044: The tray icon
 color is not green
In-Reply-To: <ce61a4cb-7050-4395-86d8-905a5412568c@default>
References: <ce61a4cb-7050-4395-86d8-905a5412568c@default>
Message-ID: <fed37de4-3ac7-441c-b066-9ca83f0abc15@default>

Hi Sergey, I have updated the Webrev. Please review this:
http://cr.openjdk.java.net/~pkbalakr/shashi/8169044/webrev.01/

I have made the code updates uniform in the file to take the 'scaled' size of the icon instead of the 'hardcoded' size earlier. 
Another point is that am not able to find the source code for the XConfigureEvent(which captures the window configuration attributes of the tray icon window in this case) and hence am not sure about the configuration of the XWindow configuration response (of the tray icon) is scaled or not. If it is not scaled it may require updates for the metacity window manager specific code to adjust the window configuration of the tray icon(because metacity WM provides rectangular window instead of a square window).

Thanks and regards,
Shashi

-----Original Message-----
From: Sergey Bylokhov 
Sent: Wednesday, August 2, 2017 2:45 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: awt-dev at openjdk.java.net; 2d-dev at openjdk.java.net; Jim Graham <james.graham at oracle.com>
Subject: Re: [OpenJDK 2D-Dev] [10] JDK-8169044: The tray icon color is not green

Hi, Shashi.
As far as I understand the "width/height" in the IconCanvas is a size of the TrayIcon in pixels. So on the normal screen it is should be 24(TRAY_ICON_WIDTH) pixels and on a HiDPI screen it should be 24*ScreenScale. The IconCanvas.width/height fields should reflect this size.

I am not sure but it looks like the current fix changes the "size" of the frame just for rendering(so we select HiDPI image) but did not change the size of the frame. So we draw the HiDPI image to non-HiDPI embedded frame.

-----  HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" shashidhara.veerabhadraiah at oracle.com wrote:

> Yes Jim. Per the current code base, it is defaulted to default screen.
> 
> To have the same tray icon being represented on multiple task bars 
> would require updates to XSystemTrayPeer.java to replicate the message 
> being sent to X11 to add a new tray icon for a particular 
> screen(Currently it is done only for the default screen). The current
> X11 tray system uses XEMBED protocol to add system tray icons. 
> Currently the screen is set to 0 which I think would refer to default 
> screen and hence it adds tray icons only to the default screen. The
> X11 property '_NET_SYSTEM_TRAY_S[SCREEN_NUMBER]' allows access to the 
> system tray of screen 'SCREEN_ NUMBER '. So we may need to use such 
> mechanism to add the tray icon onto different screens. This may be 
> different for windows and mac but will have a similar mechanism.
> 
> Thanks and regards,
> Shashi
> 
> -----Original Message-----
> From: Jim Graham
> Sent: Tuesday, August 1, 2017 2:14 AM
> To: Shashidhara Veerabhadraiah
> < HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com" shashidhara.veerabhadraiah at oracle.com>;  HYPERLINK "mailto:awt-dev at openjdk.java.net" awt-dev at openjdk.java.net; 
> 2d-dev < HYPERLINK "mailto:2d-dev at openjdk.java.net" 2d-dev at openjdk.java.net>
> Subject: Re: [OpenJDK 2D-Dev] [10] JDK-8169044: The tray icon color is 
> not green
> 
> Will the tray icon canvas always be on the default screen?  I believe 
> the latest MacOS and Win10 both allow menu bars and task bars on all 
> monitors.  Linux may not be far behind...
> 
> 			...jim
> 
> On 7/30/17 11:59 PM, Shashidhara Veerabhadraiah wrote:
> > Hi, Kindly review a fix for JDK-8169044 where the non hi dpi icon
> was
> > picked among the icon set of hi dpi and a non hi dpi icons for a hi
> dpi display screen.
> > 
> > Issue: The non hi dpi icon is red in color (and hi dpi icon is green
> 
> > in color) and was getting picked up among the set for a hi dpi
> display screen as shown below in the picture:
> > 
> > Solution and fix: The icon's buffered images are not subjected to
> the
> > scaling because of the hi dpi screen. Hence, the default non hi dpi
> 
> > icon was getting picked up for rendering the tray icon. Now the
> source
> > code modified to apply necessary transformations to the
> bufferedimages to get the default icon based on the default display 
> screen. Below is the output after the fix:
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8169044
> > 
> > Webrev:
> http://cr.openjdk.java.net/~pkbalakr/shashi/8169044/webrev.00/
> > 
> > Thanks and regards,
> > 
> > Shashi
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170808/17791f84/attachment.html>

From krishna.addepalli at oracle.com  Tue Aug  8 12:12:26 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 8 Aug 2017 05:12:26 -0700 (PDT)
Subject: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File) memory
 leak on "C:\" file reference
Message-ID: <180c578d-8f9d-40aa-8e14-0f88b39f734f@default>

Hi All,

 

Please review the fix for bug: 

 

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

 

JDK 10 Webrev : http://cr.openjdk.java.net/~pkbalakr/Krishna/8175015/webrev00/

 

Summary:

The bug reports about memory leak by repeatedly querying FileSystemView, if "C:\" is a root drive.

 

The problem is internally, Win32ShellFolderManager2.java, the function "isFileSystemRoot" is called, which lists the contents of all the root drives, in addition to including them. It also includes the hidden files. For each file present, it is wrapped with a "Win32ShellFolder2" object. So, for each query, it will list the files in the drives, and throws them away, which is leading to both memory consumption as well as slow performance. 

 

The fix is to use "Win32ShellFolder2.listRoots()", which is both fast and consumes less memory, since the number of drives on most systems will not exceed 5/10, whereas there can be a large number of files in the root directory. 

 

Thanks,

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

From sergey.bylokhov at oracle.com  Tue Aug  8 22:30:44 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 8 Aug 2017 15:30:44 -0700 (PDT)
Subject: <AWT Dev> <AWT dev>[10] Review request for JDK-8136999:
 [macosx] NSException and NPE in a crash test
Message-ID: <8e2d8984-24f6-4dc5-9621-e368921a9591@default>

Hi, Manajit.
I just recognize that this test is a updated version of the closed test. But it works differently. The updated test passed to quickly.
  
----- Sergey.Bylokhov at oracle.com wrote:

> Looks fine.
> 
> On 03.08.2017 6:27, Manajit Halder wrote:
> > Hi Sergey,
> > 
> > Added the test case from the previous iteration of the fix. Please 
> > review the webrev:
> > http://cr.openjdk.java.net/~mhalder/8136999/webrev.01/
> > 
> > Regards,
> > Manajit
> > 
> >> On 26-Jul-2017, at 10:32 PM, Sergey Bylokhov 
> >> <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>>
> wrote:
> >>
> >> Hi, Manajit.
> >> Can you please add a test from the previous iteration of the fix:
> >> http://cr.openjdk.java.net/~alexsch/8136999/webrev.00
> >>
> >> -----manajit.halder at oracle.com
> <mailto:manajit.halder at oracle.com>wrote:
> >> >
> >> >Hi All,
> >> >
> >> >
> >> >Kindly review the fix for JDK10.
> >> >
> >> >Bug:
> >> >https://bugs.openjdk.java.net/browse/JDK-8136999
> >> >
> >> >Webrev:
> >> >http://cr.openjdk.java.net/~mhalder/8136999/webrev.00/
> >> >
> >> >Fix:
> >> >The flushEvent method is not required as mentioned in the previous
> 
> >> review mail 
> >>
> (http://mail.openjdk.java.net/pipermail/awt-dev/2015-October/010201.html).
> >> >flushEvent related functionalities were modified while fixing
> issue 
> >> JDK-8006634 <https://bugs.openjdk.java.net/browse/JDK-8006634>  
> >> and hence deleted flushEvent method.
> >> >
> >> >Regards,
> >> >Manajit
> > 
> 
> 
> -- 
> Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Aug  8 23:45:33 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 8 Aug 2017 16:45:33 -0700
Subject: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File) memory
 leak on "C:\" file reference
In-Reply-To: <180c578d-8f9d-40aa-8e14-0f88b39f734f@default>
References: <180c578d-8f9d-40aa-8e14-0f88b39f734f@default>
Message-ID: <b0a640eb-d31f-9e0c-f022-c5ad8da71326@oracle.com>

Hi, Krishna.> The problem is internally, Win32ShellFolderManager2.java, 
the function
> ?isFileSystemRoot? is called, which lists the contents of all the root 
> drives, in addition to including them. It also includes the hidden 
> files. For each file present, it is wrapped with a ?Win32ShellFolder2? 
> object. So, for each query, it will list the files in the drives, and 
> throws them away, which is leading to both memory consumption as well as 
> slow performance.

If for each query we list the files in the drive and *throws* all of 
them away, then why(and where) we have a memory leak and as a result OOM.


-- 
Best regards, Sergey.

From sergey.bylokhov at oracle.com  Wed Aug  9 01:49:18 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 8 Aug 2017 18:49:18 -0700 (PDT)
Subject: <AWT Dev> [10] Review Request: 8153871 [macosx] Low-level error on
 OS X 10.11 with DnD in Swing
Message-ID: <8b1d605e-182c-46d4-bc01-5323fef4c24e@default>

Hello,
Please review the fix for jdk10.

Bug: https://bugs.openjdk.java.net/browse/JDK-8153871
Webrev can be found at: http://cr.openjdk.java.net/~serb/8153871/webrev.00

We get a native error when we tries to initialize the "NSGraphicsContext" to pass it to the NSEvent. But according the specification [1] NSEvent.context is deprecated, and the method mouseEventWithType() which we use to construct the NSEvent highlights [2] that the context parameter is unused and the nil should be passed.
In the fix we pass nil as suggested.

Note that the test still fail time to time because of [3]

[1] https://developer.apple.com/documentation/appkit/nsevent/1524291-context?language=objc
[2] https://developer.apple.com/documentation/appkit/nsevent/1532495-mouseeventwithtype?language=objc
[3] https://bugs.openjdk.java.net/browse/JDK-8186002


-- 
Best regards, Sergey.

From krishna.addepalli at oracle.com  Wed Aug  9 06:05:29 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 8 Aug 2017 23:05:29 -0700 (PDT)
Subject: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File) memory
 leak on "C:\" file reference
In-Reply-To: <b0a640eb-d31f-9e0c-f022-c5ad8da71326@oracle.com>
References: <180c578d-8f9d-40aa-8e14-0f88b39f734f@default>
 <b0a640eb-d31f-9e0c-f022-c5ad8da71326@oracle.com>
Message-ID: <15046c29-33c6-4cfe-8a0d-e62a1cf49604@default>

Hi Sergey,

AFAIK, "Win32ShellFolder2.listDrives()" returns an array of File objects. Now, once the function "isFileSystemRoot" is exited, the Array will get destroyed, but the object references will be cleaned up by GC, whenever it runs. The problem is if we repeatedly call "isFileSystemRoot" function, it will keep creating those objects, and might overwhelm the memory, before GC gets a chance to run. I have even seen that in some cases, the available memory increases, which indicates that GC has performed some cleanup. 
Pasting below an excerpt of the log of memory consumption as mentioned in the bug:

6.4 % (3175/50000) [Memory Used: 15,872 kb Free=1,030 kb Max: 15,872 kb] 
6.5 % (3225/50000) [Memory Used: 15,872 kb Free=796 kb Max: 15,872 kb] 
6.6 % (3275/50000) [Memory Used: 15,872 kb Free=2,185 kb Max: 15,872 kb] 
6.7 % (3325/50000) [Memory Used: 15,872 kb Free=1,940 kb Max: 15,872 kb] 
6.8 % (3375/50000) [Memory Used: 15,872 kb Free=1,661 kb Max: 15,872 kb]

In line 1, the free memory is 1030kb, which reduces to 796kb, but in line 3, it increases to 2185 kb, which indicates that GC had a chance to cleanup some memory. After that, it is again reducing. You can see that this kind of pattern repeats a few times, but eventually, the memory runs out.

Thanks,
Krishna

-----Original Message-----
From: Sergey Bylokhov 
Sent: Wednesday, August 9, 2017 5:16 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File) memory leak on "C:\" file reference

Hi, Krishna.> The problem is internally, Win32ShellFolderManager2.java, the function
> "isFileSystemRoot" is called, which lists the contents of all the root 
> drives, in addition to including them. It also includes the hidden 
> files. For each file present, it is wrapped with a "Win32ShellFolder2"
> object. So, for each query, it will list the files in the drives, and 
> throws them away, which is leading to both memory consumption as well 
> as slow performance.

If for each query we list the files in the drive and *throws* all of them away, then why(and where) we have a memory leak and as a result OOM.


-- 
Best regards, Sergey.

From goetz.lindenmaier at sap.com  Wed Aug  9 10:56:38 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 9 Aug 2017 10:56:38 +0000
Subject: <AWT Dev> [ping] RFR(M): 8185500: [TESTBUG] Add keywords
 headful/printer in java/awt and javax tests.
Message-ID: <08985b53ac8a47fab7561d01ec44b442@sap.com>

Hi,

I added more headful tests that are only run on windows.  I also added 
some @requires os=windows where obvious.
I would appreciate a review!
http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.01/

Best regards,
  Goetz.

> -----Original Message-----
> From: awt-dev [mailto:awt-dev-bounces at openjdk.java.net] On Behalf Of
> Lindenmaier, Goetz
> Sent: Freitag, 4. August 2017 13:53
> To: awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> RFR(M): 8185500: [TESTBUG] Add keywords
> headful/printer in java/awt and javax tests.
> 
> Hi,
> 
> I added another approx. 20 tests which are headful but are run only on mac.
> http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.01/
> 
> Best regards,
>   Goetz.
> 
> > -----Original Message-----
> > From: Lindenmaier, Goetz
> > Sent: Mittwoch, 2. August 2017 11:13
> > To: awt-dev at openjdk.java.net
> > Subject: RFR(M): 8185500: [TESTBUG] Add keywords headful/printer in
> > java/awt and javax tests.
> >
> > Hi,
> >
> > I looked at all the remaining tests failing in our test environment, and I
> > think I have now identified the last set of headful tests that lack the
> > @key headful tag.
> >
> > Also, I identified a row of tests that require a printer. For these I introduce
> > the new keyword 'printer' and marked them accordingly.
> >
> > A few tests threw NullPointerException in the finalizer if run headless,
> > I fixed that, too.
> >
> > Please review this change:
> >
> > http://cr.openjdk.java.net/~goetz/wr17/8185500-
> headlessKey/webrev.01/index.html
> >
> > Thanks and best regards,
> >   Goetz.


From alexander.zvegintsev at oracle.com  Thu Aug 10 09:15:01 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 10 Aug 2017 14:45:01 +0530
Subject: <AWT Dev> [10] Review Request: 8153871 [macosx] Low-level error
 on OS X 10.11 with DnD in Swing
In-Reply-To: <8b1d605e-182c-46d4-bc01-5323fef4c24e@default>
References: <8b1d605e-182c-46d4-bc01-5323fef4c24e@default>
Message-ID: <ee90a912-91b2-29bd-3a99-b70efe1b201e@oracle.com>

Looks fine

Thanks,
Alexander.

On 09/08/2017 07:19, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk10.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8153871
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8153871/webrev.00
>
> We get a native error when we tries to initialize the "NSGraphicsContext" to pass it to the NSEvent. But according the specification [1] NSEvent.context is deprecated, and the method mouseEventWithType() which we use to construct the NSEvent highlights [2] that the context parameter is unused and the nil should be passed.
> In the fix we pass nil as suggested.
>
> Note that the test still fail time to time because of [3]
>
> [1] https://developer.apple.com/documentation/appkit/nsevent/1524291-context?language=objc
> [2] https://developer.apple.com/documentation/appkit/nsevent/1532495-mouseeventwithtype?language=objc
> [3] https://bugs.openjdk.java.net/browse/JDK-8186002
>
>


From sergey.bylokhov at oracle.com  Fri Aug 11 02:51:50 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 10 Aug 2017 19:51:50 -0700 (PDT)
Subject: <AWT Dev> [ping] RFR(M): 8185500: [TESTBUG] Add keywords
 headful/printer in java/awt and javax tests.
Message-ID: <bfefa85c-984d-4d50-8209-3bc705ad7a41@default>

Thank you for the fix.
Looks fine.


----- goetz.lindenmaier at sap.com wrote:

> Hi,
> 
> I added more headful tests that are only run on windows.  I also added
> 
> some @requires os=windows where obvious.
> I would appreciate a review!
> http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.01/
> 
> Best regards,
>   Goetz.
> 
> > -----Original Message-----
> > From: awt-dev [mailto:awt-dev-bounces at openjdk.java.net] On Behalf
> Of
> > Lindenmaier, Goetz
> > Sent: Freitag, 4. August 2017 13:53
> > To: awt-dev at openjdk.java.net
> > Subject: Re: <AWT Dev> RFR(M): 8185500: [TESTBUG] Add keywords
> > headful/printer in java/awt and javax tests.
> > 
> > Hi,
> > 
> > I added another approx. 20 tests which are headful but are run only
> on mac.
> >
> http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.01/
> > 
> > Best regards,
> >   Goetz.
> > 
> > > -----Original Message-----
> > > From: Lindenmaier, Goetz
> > > Sent: Mittwoch, 2. August 2017 11:13
> > > To: awt-dev at openjdk.java.net
> > > Subject: RFR(M): 8185500: [TESTBUG] Add keywords headful/printer
> in
> > > java/awt and javax tests.
> > >
> > > Hi,
> > >
> > > I looked at all the remaining tests failing in our test
> environment, and I
> > > think I have now identified the last set of headful tests that
> lack the
> > > @key headful tag.
> > >
> > > Also, I identified a row of tests that require a printer. For
> these I introduce

> > > the new keyword 'printer' and marked them accordingly.
> > >
> > > A few tests threw NullPointerException in the finalizer if run
> headless,
> > > I fixed that, too.
> > >
> > > Please review this change:
> > >
> > > http://cr.openjdk.java.net/~goetz/wr17/8185500-
> > headlessKey/webrev.01/index.html
> > >
> > > Thanks and best regards,
> > >   Goetz.

From goetz.lindenmaier at sap.com  Fri Aug 11 06:57:47 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 11 Aug 2017 06:57:47 +0000
Subject: <AWT Dev> [ping] RFR(M): 8185500: [TESTBUG] Add keywords
 headful/printer in java/awt and javax tests.
In-Reply-To: <bfefa85c-984d-4d50-8209-3bc705ad7a41@default>
References: <bfefa85c-984d-4d50-8209-3bc705ad7a41@default>
Message-ID: <7001c2b626124353b9496c9de53bfde0@sap.com>

Thanks Sergey!

If I have the second review, can I push it to jdk10/jdk10?
That's where we run these tests.

Best regards,
  Goetz.

> -----Original Message-----
> From: Sergey Bylokhov [mailto:sergey.bylokhov at oracle.com]
> Sent: Freitag, 11. August 2017 04:52
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [ping] RFR(M): 8185500: [TESTBUG] Add keywords
> headful/printer in java/awt and javax tests.
> 
> Thank you for the fix.
> Looks fine.
> 
> 
> ----- goetz.lindenmaier at sap.com wrote:
> 
> > Hi,
> >
> > I added more headful tests that are only run on windows.  I also added
> >
> > some @requires os=windows where obvious.
> > I would appreciate a review!
> > http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.01/
> >
> > Best regards,
> >   Goetz.
> >
> > > -----Original Message-----
> > > From: awt-dev [mailto:awt-dev-bounces at openjdk.java.net] On Behalf
> > Of
> > > Lindenmaier, Goetz
> > > Sent: Freitag, 4. August 2017 13:53
> > > To: awt-dev at openjdk.java.net
> > > Subject: Re: <AWT Dev> RFR(M): 8185500: [TESTBUG] Add keywords
> > > headful/printer in java/awt and javax tests.
> > >
> > > Hi,
> > >
> > > I added another approx. 20 tests which are headful but are run only
> > on mac.
> > >
> > http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.01/
> > >
> > > Best regards,
> > >   Goetz.
> > >
> > > > -----Original Message-----
> > > > From: Lindenmaier, Goetz
> > > > Sent: Mittwoch, 2. August 2017 11:13
> > > > To: awt-dev at openjdk.java.net
> > > > Subject: RFR(M): 8185500: [TESTBUG] Add keywords headful/printer
> > in
> > > > java/awt and javax tests.
> > > >
> > > > Hi,
> > > >
> > > > I looked at all the remaining tests failing in our test
> > environment, and I
> > > > think I have now identified the last set of headful tests that
> > lack the
> > > > @key headful tag.
> > > >
> > > > Also, I identified a row of tests that require a printer. For
> > these I introduce

> > > > the new keyword 'printer' and marked them accordingly.
> > > >
> > > > A few tests threw NullPointerException in the finalizer if run
> > headless,
> > > > I fixed that, too.
> > > >
> > > > Please review this change:
> > > >
> > > > http://cr.openjdk.java.net/~goetz/wr17/8185500-
> > > headlessKey/webrev.01/index.html
> > > >
> > > > Thanks and best regards,
> > > >   Goetz.

From matthias.baesken at sap.com  Fri Aug 11 07:28:40 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 11 Aug 2017 07:28:40 +0000
Subject: <AWT Dev> AWT Dev> [ping] RFR(M): 8185500: [TESTBUG] Add
	keywords
Message-ID: <a0bf9b867ab445a4891c14b528a02cb5@sap.com>



?  I added more headful tests that are only run on windows.  I also added

?  some @requires os=windows where obvious.

?  I would appreciate a review!

?  http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.01/


Hi G?tz, not a reviewer  but I noticed  a few  of the files need  Copyright  year update  , for example

test/java/awt/hidpi/properties/HiDPIPropertiesWindowsTest.java

test/java/awt/im/6396526/IMLookAndFeel.java

test/java/awt/print/PrinterJob/ExceptionTest.java

test/java/awt/print/PrinterJob/ImagePrinting/NullClipARGB.java

test/java/awt/print/PrinterJob/PrintTextPane.java

test/javax/swing/JInternalFrame/6288609/TestJInternalFrameDispose.java

test/javax/swing/JInternalFrame/8075314/bug8075314.java

test/javax/swing/JInternalFrame/8145060/TestJInternalFrameMinimize.java

test/javax/swing/JMenuItem/ClickMenuTestManual/ClickMenuTestManual.java

test/javax/swing/text/html/Test4783068.java



Does that one need   tag  printer as well ?

test/java/awt/print/PrinterJob/Margins.java


This  test  got a  very  long line in the  "summary"  of the tagging section, maybe better use 2 lines :

test/javax/print/PrintSE/PrintSE.sh


Otherwise looks ok to me .

Best regards, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170811/8aa3ba10/attachment.html>

From goetz.lindenmaier at sap.com  Fri Aug 11 11:57:34 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 11 Aug 2017 11:57:34 +0000
Subject: <AWT Dev> AWT Dev> [ping] RFR(M): 8185500: [TESTBUG] Add
	keywords
In-Reply-To: <a0bf9b867ab445a4891c14b528a02cb5@sap.com>
References: <a0bf9b867ab445a4891c14b528a02cb5@sap.com>
Message-ID: <d5285b485b0f41eaa341d64142a92357@sap.com>

Hi Matthias,

thanks for looking at this change.

I fixed the copyrights, (I actually had a bug skipping 2015, --> 2015, 2017, in my script).
I also adapted the "summary" and double checked jtreg is parsing this correctly.
(I was not sure with the line break and # comments.)

The test test/java/awt/print/PrinterJob/Margins.java
Just opens a window "No printer found" and terminates as 'passed'
if the printer is missing. So I would prefer to skip the
'printer' key from that test.

New webrev:

http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.02/



Best regards,

  Goetz.




From: Baesken, Matthias
Sent: Freitag, 11. August 2017 09:29
To: awt-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Subject: re : AWT Dev> [ping] RFR(M): 8185500: [TESTBUG] Add keywords



?  I added more headful tests that are only run on windows.  I also added

?  some @requires os=windows where obvious.

?  I would appreciate a review!

?  http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.01/


Hi G?tz, not a reviewer  but I noticed  a few  of the files need  Copyright  year update  , for example

test/java/awt/hidpi/properties/HiDPIPropertiesWindowsTest.java

test/java/awt/im/6396526/IMLookAndFeel.java

test/java/awt/print/PrinterJob/ExceptionTest.java

test/java/awt/print/PrinterJob/ImagePrinting/NullClipARGB.java

test/java/awt/print/PrinterJob/PrintTextPane.java

test/javax/swing/JInternalFrame/6288609/TestJInternalFrameDispose.java

test/javax/swing/JInternalFrame/8075314/bug8075314.java

test/javax/swing/JInternalFrame/8145060/TestJInternalFrameMinimize.java

test/javax/swing/JMenuItem/ClickMenuTestManual/ClickMenuTestManual.java

test/javax/swing/text/html/Test4783068.java



Does that one need   tag  printer as well ?

test/java/awt/print/PrinterJob/Margins.java


This  test  got a  very  long line in the  "summary"  of the tagging section, maybe better use 2 lines :

test/javax/print/PrintSE/PrintSE.sh


Otherwise looks ok to me .

Best regards, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170811/ab755baf/attachment-0001.html>

From prasanta.sadhukhan at oracle.com  Mon Aug 14 06:00:20 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 14 Aug 2017 11:30:20 +0530
Subject: <AWT Dev> [10] RFR JDK-8088132:[Swing,
 singleThread] ClassCastException in nested event loop when showing
 multiple message dialogs in SwingNode
Message-ID: <97e15491-ee19-7c1d-c813-2bfe006f57b2@oracle.com>

Hi All,

Please review this fix
http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/
for an fx issue
https://bugs.openjdk.java.net/browse/JDK-8088132

More info in JBS.

Regards
Prasanta

From goetz.lindenmaier at sap.com  Mon Aug 14 09:37:40 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 14 Aug 2017 09:37:40 +0000
Subject: <AWT Dev> AWT Dev> [ping] RFR(M): 8185500: [TESTBUG]
	Add	keywords
In-Reply-To: <d5285b485b0f41eaa341d64142a92357@sap.com>
References: <a0bf9b867ab445a4891c14b528a02cb5@sap.com>
 <d5285b485b0f41eaa341d64142a92357@sap.com>
Message-ID: <6c631c419bc644208d4f1810fd5c9095@sap.com>

Hi,

I uploaded an incremental patch:
http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.02/diffs-incremental.patch

and removed the changes to 
test/javax/swing/JTextArea/8148555/JTextAreaEmojiTest.java
because that was in the meantime annotated as headful in the client repo.

Best regards,
  Goetz.

> -----Original Message-----
> From: awt-dev [mailto:awt-dev-bounces at openjdk.java.net] On Behalf Of
> Lindenmaier, Goetz
> Sent: Freitag, 11. August 2017 13:58
> To: Baesken, Matthias <matthias.baesken at sap.com>; awt-
> dev at openjdk.java.net
> Subject: Re: <AWT Dev> AWT Dev> [ping] RFR(M): 8185500: [TESTBUG] Add
> keywords
> 
> Hi Matthias,
> 
> 
> 
> thanks for looking at this change.
> 
> 
> 
> I fixed the copyrights, (I actually had a bug skipping 2015, --> 2015, 2017, in my
> script).
> 
> I also adapted the "summary" and double checked jtreg is parsing this
> correctly.
> 
> (I was not sure with the line break and # comments.)
> 
> 
> 
> The test test/java/awt/print/PrinterJob/Margins.java
> 
> Just opens a window "No printer found" and terminates as 'passed'
> 
> if the printer is missing. So I would prefer to skip the
> 
> 'printer' key from that test.
> 
> 
> 
> New webrev:
> 
> http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.02/
> 
> 
> 
> Best regards,
> 
>   Goetz.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> From: Baesken, Matthias
> Sent: Freitag, 11. August 2017 09:29
> To: awt-dev at openjdk.java.net; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>
> Subject: re : AWT Dev> [ping] RFR(M): 8185500: [TESTBUG] Add keywords
> 
> 
> 
> 
> 
> *  I added more headful tests that are only run on windows.  I also added
> 
> *  some @requires os=windows where obvious.
> 
> *  I would appreciate a review!
> 
> *  http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.01/
> <http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.01/>
> 
> 
> 
> 
> 
> Hi G?tz, not a reviewer  but I noticed  a few  of the files need  Copyright  year
> update  , for example
> 
> 
> 
> test/java/awt/hidpi/properties/HiDPIPropertiesWindowsTest.java
> 
> 
> 
> test/java/awt/im/6396526/IMLookAndFeel.java
> 
> 
> 
> test/java/awt/print/PrinterJob/ExceptionTest.java
> 
> 
> 
> test/java/awt/print/PrinterJob/ImagePrinting/NullClipARGB.java
> 
> 
> 
> test/java/awt/print/PrinterJob/PrintTextPane.java
> 
> 
> 
> test/javax/swing/JInternalFrame/6288609/TestJInternalFrameDispose.java
> 
> 
> 
> test/javax/swing/JInternalFrame/8075314/bug8075314.java
> 
> 
> 
> test/javax/swing/JInternalFrame/8145060/TestJInternalFrameMinimize.java
> 
> 
> 
> test/javax/swing/JMenuItem/ClickMenuTestManual/ClickMenuTestManual.jav
> a
> 
> 
> 
> test/javax/swing/text/html/Test4783068.java
> 
> 
> 
> 
> 
> 
> 
> Does that one need   tag  printer as well ?
> 
> 
> 
> test/java/awt/print/PrinterJob/Margins.java
> 
> 
> 
> 
> 
> This  test  got a  very  long line in the  "summary"  of the tagging section,
> maybe better use 2 lines :
> 
> 
> 
> test/javax/print/PrintSE/PrintSE.sh
> 
> 
> 
> 
> 
> Otherwise looks ok to me .
> 
> 
> 
> Best regards, Matthias


From matthias.baesken at sap.com  Mon Aug 14 11:36:11 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 14 Aug 2017 11:36:11 +0000
Subject: <AWT Dev> AWT Dev> [ping] RFR(M): 8185500: [TESTBUG]
	Add	keywords
In-Reply-To: <6c631c419bc644208d4f1810fd5c9095@sap.com>
References: <a0bf9b867ab445a4891c14b528a02cb5@sap.com>
 <d5285b485b0f41eaa341d64142a92357@sap.com>
 <6c631c419bc644208d4f1810fd5c9095@sap.com>
Message-ID: <4c573e33992a4a9385d290c654167c0b@sap.com>

Hi Goetz, not a Reviewer  but looks good except this diff :


--- a/test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java	Fri Jul 28 14:06:28 2017 +0200
+++ b/test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java	Mon Aug 14 11:23:42 2017 +0200
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it


Seems to me an old copyright year info 2012,2013  appeared  for some reason .

Best regards, Matthias



-----Original Message-----
From: Lindenmaier, Goetz 
Sent: Montag, 14. August 2017 11:38
To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Baesken, Matthias <matthias.baesken at sap.com>; awt-dev at openjdk.java.net
Subject: RE: <AWT Dev> AWT Dev> [ping] RFR(M): 8185500: [TESTBUG] Add keywords

Hi,

I uploaded an incremental patch:
http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.02/diffs-incremental.patch

and removed the changes to 
test/javax/swing/JTextArea/8148555/JTextAreaEmojiTest.java
because that was in the meantime annotated as headful in the client repo.

Best regards,
  Goetz.

> -----Original Message-----
> From: awt-dev [mailto:awt-dev-bounces at openjdk.java.net] On Behalf Of
> Lindenmaier, Goetz
> Sent: Freitag, 11. August 2017 13:58
> To: Baesken, Matthias <matthias.baesken at sap.com>; awt-
> dev at openjdk.java.net
> Subject: Re: <AWT Dev> AWT Dev> [ping] RFR(M): 8185500: [TESTBUG] Add
> keywords
> 
> Hi Matthias,
> 
> 
> 
> thanks for looking at this change.
> 
> 
> 
> I fixed the copyrights, (I actually had a bug skipping 2015, --> 2015, 2017, in my
> script).
> 
> I also adapted the "summary" and double checked jtreg is parsing this
> correctly.
> 
> (I was not sure with the line break and # comments.)
> 
> 
> 
> The test test/java/awt/print/PrinterJob/Margins.java
> 
> Just opens a window "No printer found" and terminates as 'passed'
> 
> if the printer is missing. So I would prefer to skip the
> 
> 'printer' key from that test.
> 
> 
> 
> New webrev:
> 
> http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.02/
> 
> 
> 
> Best regards,
> 
>   Goetz.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> From: Baesken, Matthias
> Sent: Freitag, 11. August 2017 09:29
> To: awt-dev at openjdk.java.net; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>
> Subject: re : AWT Dev> [ping] RFR(M): 8185500: [TESTBUG] Add keywords
> 
> 
> 
> 
> 
> *  I added more headful tests that are only run on windows.  I also added
> 
> *  some @requires os=windows where obvious.
> 
> *  I would appreciate a review!
> 
> *  http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.01/
> <http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.01/>
> 
> 
> 
> 
> 
> Hi G?tz, not a reviewer  but I noticed  a few  of the files need  Copyright  year
> update  , for example
> 
> 
> 
> test/java/awt/hidpi/properties/HiDPIPropertiesWindowsTest.java
> 
> 
> 
> test/java/awt/im/6396526/IMLookAndFeel.java
> 
> 
> 
> test/java/awt/print/PrinterJob/ExceptionTest.java
> 
> 
> 
> test/java/awt/print/PrinterJob/ImagePrinting/NullClipARGB.java
> 
> 
> 
> test/java/awt/print/PrinterJob/PrintTextPane.java
> 
> 
> 
> test/javax/swing/JInternalFrame/6288609/TestJInternalFrameDispose.java
> 
> 
> 
> test/javax/swing/JInternalFrame/8075314/bug8075314.java
> 
> 
> 
> test/javax/swing/JInternalFrame/8145060/TestJInternalFrameMinimize.java
> 
> 
> 
> test/javax/swing/JMenuItem/ClickMenuTestManual/ClickMenuTestManual.jav
> a
> 
> 
> 
> test/javax/swing/text/html/Test4783068.java
> 
> 
> 
> 
> 
> 
> 
> Does that one need   tag  printer as well ?
> 
> 
> 
> test/java/awt/print/PrinterJob/Margins.java
> 
> 
> 
> 
> 
> This  test  got a  very  long line in the  "summary"  of the tagging section,
> maybe better use 2 lines :
> 
> 
> 
> test/javax/print/PrintSE/PrintSE.sh
> 
> 
> 
> 
> 
> Otherwise looks ok to me .
> 
> 
> 
> Best regards, Matthias


From goetz.lindenmaier at sap.com  Mon Aug 14 11:59:18 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 14 Aug 2017 11:59:18 +0000
Subject: <AWT Dev> AWT Dev> [ping] RFR(M): 8185500: [TESTBUG]
	Add	keywords
In-Reply-To: <4c573e33992a4a9385d290c654167c0b@sap.com>
References: <a0bf9b867ab445a4891c14b528a02cb5@sap.com>
 <d5285b485b0f41eaa341d64142a92357@sap.com>
 <6c631c419bc644208d4f1810fd5c9095@sap.com>
 <4c573e33992a4a9385d290c654167c0b@sap.com>
Message-ID: <07b1725a55d44a9992aac72ffecd7c52@sap.com>

It was changed in client to 2017, I reverted it to avoid merge conflicts.

Best regards,
  Goetz.

> -----Original Message-----
> From: Baesken, Matthias
> Sent: Montag, 14. August 2017 13:36
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; awt-
> dev at openjdk.java.net
> Subject: RE: <AWT Dev> AWT Dev> [ping] RFR(M): 8185500: [TESTBUG] Add
> keywords
> 
> Hi Goetz, not a Reviewer  but looks good except this diff :
> 
> 
> ---
> a/test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalled
> TwiceTest.java	Fri Jul 28 14:06:28 2017 +0200
> +++
> b/test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalled
> TwiceTest.java	Mon Aug 14 11:23:42 2017 +0200
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> 
> 
> Seems to me an old copyright year info 2012,2013  appeared  for some reason .
> 
> Best regards, Matthias
> 
> 
> 
> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Montag, 14. August 2017 11:38
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Baesken, Matthias
> <matthias.baesken at sap.com>; awt-dev at openjdk.java.net
> Subject: RE: <AWT Dev> AWT Dev> [ping] RFR(M): 8185500: [TESTBUG] Add
> keywords
> 
> Hi,
> 
> I uploaded an incremental patch:
> http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.02/diffs-
> incremental.patch
> 
> and removed the changes to
> test/javax/swing/JTextArea/8148555/JTextAreaEmojiTest.java
> because that was in the meantime annotated as headful in the client repo.
> 
> Best regards,
>   Goetz.
> 
> > -----Original Message-----
> > From: awt-dev [mailto:awt-dev-bounces at openjdk.java.net] On Behalf Of
> > Lindenmaier, Goetz
> > Sent: Freitag, 11. August 2017 13:58
> > To: Baesken, Matthias <matthias.baesken at sap.com>; awt-
> > dev at openjdk.java.net
> > Subject: Re: <AWT Dev> AWT Dev> [ping] RFR(M): 8185500: [TESTBUG] Add
> > keywords
> >
> > Hi Matthias,
> >
> >
> >
> > thanks for looking at this change.
> >
> >
> >
> > I fixed the copyrights, (I actually had a bug skipping 2015, --> 2015, 2017, in
> my
> > script).
> >
> > I also adapted the "summary" and double checked jtreg is parsing this
> > correctly.
> >
> > (I was not sure with the line break and # comments.)
> >
> >
> >
> > The test test/java/awt/print/PrinterJob/Margins.java
> >
> > Just opens a window "No printer found" and terminates as 'passed'
> >
> > if the printer is missing. So I would prefer to skip the
> >
> > 'printer' key from that test.
> >
> >
> >
> > New webrev:
> >
> > http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.02/
> >
> >
> >
> > Best regards,
> >
> >   Goetz.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > From: Baesken, Matthias
> > Sent: Freitag, 11. August 2017 09:29
> > To: awt-dev at openjdk.java.net; Lindenmaier, Goetz
> > <goetz.lindenmaier at sap.com>
> > Subject: re : AWT Dev> [ping] RFR(M): 8185500: [TESTBUG] Add keywords
> >
> >
> >
> >
> >
> > *  I added more headful tests that are only run on windows.  I also added
> >
> > *  some @requires os=windows where obvious.
> >
> > *  I would appreciate a review!
> >
> > *  http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.01/
> > <http://cr.openjdk.java.net/~goetz/wr17/8185500-headlessKey/webrev.01/>
> >
> >
> >
> >
> >
> > Hi G?tz, not a reviewer  but I noticed  a few  of the files need  Copyright  year
> > update  , for example
> >
> >
> >
> > test/java/awt/hidpi/properties/HiDPIPropertiesWindowsTest.java
> >
> >
> >
> > test/java/awt/im/6396526/IMLookAndFeel.java
> >
> >
> >
> > test/java/awt/print/PrinterJob/ExceptionTest.java
> >
> >
> >
> > test/java/awt/print/PrinterJob/ImagePrinting/NullClipARGB.java
> >
> >
> >
> > test/java/awt/print/PrinterJob/PrintTextPane.java
> >
> >
> >
> > test/javax/swing/JInternalFrame/6288609/TestJInternalFrameDispose.java
> >
> >
> >
> > test/javax/swing/JInternalFrame/8075314/bug8075314.java
> >
> >
> >
> > test/javax/swing/JInternalFrame/8145060/TestJInternalFrameMinimize.java
> >
> >
> >
> >
> test/javax/swing/JMenuItem/ClickMenuTestManual/ClickMenuTestManual.jav
> > a
> >
> >
> >
> > test/javax/swing/text/html/Test4783068.java
> >
> >
> >
> >
> >
> >
> >
> > Does that one need   tag  printer as well ?
> >
> >
> >
> > test/java/awt/print/PrinterJob/Margins.java
> >
> >
> >
> >
> >
> > This  test  got a  very  long line in the  "summary"  of the tagging section,
> > maybe better use 2 lines :
> >
> >
> >
> > test/javax/print/PrintSE/PrintSE.sh
> >
> >
> >
> >
> >
> > Otherwise looks ok to me .
> >
> >
> >
> > Best regards, Matthias


From sergey.bylokhov at oracle.com  Mon Aug 14 16:37:37 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 14 Aug 2017 09:37:37 -0700 (PDT)
Subject: <AWT Dev> [10] RFR JDK-8088132:[Swing,
 singleThread] ClassCastException in nested event loop when showing
 multiple message dialogs in SwingNode
Message-ID: <d95551ee-89e0-439c-9a7b-90ef9beb82d1@default>

Hi, Prasanta, Kevin.

I have two notes.
 - Does this option is really supported? If it is supported we should evaluate all usage of EventDispatchThread because in this mode the dispatch thread is not EDT. For example I am not sure that we can skip the code which expects EventDispatchThread.
 - We have the similar pattern: "EventQueue.isDispatchThread() -> cast(EventDispatchThread)" in some other places like in DefaultKeyboardFocusManager.

----- prasanta.sadhukhan at oracle.com wrote:

> Hi All,
> 
> Please review this fix
> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/
> for an fx issue
> https://bugs.openjdk.java.net/browse/JDK-8088132
> 
> More info in JBS.
> 
> Regards
> Prasanta

From prasanta.sadhukhan at oracle.com  Wed Aug 16 10:33:29 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 16 Aug 2017 16:03:29 +0530
Subject: <AWT Dev> [10] RFR JDK-8088132:[Swing,
 singleThread] ClassCastException in nested event loop when showing
 multiple message dialogs in SwingNode
In-Reply-To: <d95551ee-89e0-439c-9a7b-90ef9beb82d1@default>
References: <d95551ee-89e0-439c-9a7b-90ef9beb82d1@default>
Message-ID: <23734583-9a2e-be4a-a18c-fd1d08a8d23c@oracle.com>

Hi Sergey,

AFAIK, FX singleThread feature is supported but experimental feature.
I have modified webrev to include DefaultKeyboardFocusManager too
http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.01/

I do not think there is any problem in skipping code which works with 
EDT as for example, in SequencedEvent#dispatch() it says

Dispatches the nested event after all previous nested events have 
beendispatched or disposed

Now, since here FX App thread itself is the dispatch thread, we can be 
sure the events are dispatched in sequence and dispose is checked below 
after EDT.

I have tested with couple of singleThread testcase without any issue.

Regards
Prasanta
On 8/14/2017 10:07 PM, Sergey Bylokhov wrote:
> Hi, Prasanta, Kevin.
>
> I have two notes.
>   - Does this option is really supported? If it is supported we should evaluate all usage of EventDispatchThread because in this mode the dispatch thread is not EDT. For example I am not sure that we can skip the code which expects EventDispatchThread.
>   - We have the similar pattern: "EventQueue.isDispatchThread() -> cast(EventDispatchThread)" in some other places like in DefaultKeyboardFocusManager.
>
> ----- prasanta.sadhukhan at oracle.com wrote:
>
>> Hi All,
>>
>> Please review this fix
>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/
>> for an fx issue
>> https://bugs.openjdk.java.net/browse/JDK-8088132
>>
>> More info in JBS.
>>
>> Regards
>> Prasanta

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

From philip.race at oracle.com  Wed Aug 16 18:09:25 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 16 Aug 2017 11:09:25 -0700
Subject: <AWT Dev> RFR: 8186259: IOExceptionIfEncodedURLTest.sh versus
 IOExceptionIfEncodedURLTest.java
Message-ID: <8340ec1d-7ca4-a20e-264a-cb7fd2a2cebe@oracle.com>

http://cr.openjdk.java.net/~prr/8186259/

I'll take any reviewer on this which just fixes the JTREG test so that 
jtreg does not blow up.

-phil.

From philip.race at oracle.com  Wed Aug 16 18:11:26 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 16 Aug 2017 11:11:26 -0700
Subject: <AWT Dev> RFR: 8186259: IOExceptionIfEncodedURLTest.sh versus
 IOExceptionIfEncodedURLTest.java
In-Reply-To: <8340ec1d-7ca4-a20e-264a-cb7fd2a2cebe@oracle.com>
References: <8340ec1d-7ca4-a20e-264a-cb7fd2a2cebe@oracle.com>
Message-ID: <19e2026b-0617-4cc8-f78d-d27bb782ac18@oracle.com>

fixing joe's email address.

-phil.

On 08/16/2017 11:09 AM, Phil Race wrote:
> http://cr.openjdk.java.net/~prr/8186259/
>
> I'll take any reviewer on this which just fixes the JTREG test so that 
> jtreg does not blow up.
>
> -phil.


From tim.bell at oracle.com  Wed Aug 16 18:18:51 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 16 Aug 2017 11:18:51 -0700
Subject: <AWT Dev> RFR: 8186259: IOExceptionIfEncodedURLTest.sh versus
 IOExceptionIfEncodedURLTest.java
In-Reply-To: <19e2026b-0617-4cc8-f78d-d27bb782ac18@oracle.com>
References: <8340ec1d-7ca4-a20e-264a-cb7fd2a2cebe@oracle.com>
 <19e2026b-0617-4cc8-f78d-d27bb782ac18@oracle.com>
Message-ID: <59948C8B.6030402@oracle.com>

Phil:


> On 08/16/2017 11:09 AM, Phil Race wrote:
>> http://cr.openjdk.java.net/~prr/8186259/
>>
>> I'll take any reviewer on this which just fixes the JTREG test so that
>> jtreg does not blow up.

Looks good.  Approved.

Tim



From joe.darcy at oracle.com  Wed Aug 16 19:33:10 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 16 Aug 2017 12:33:10 -0700
Subject: <AWT Dev> RFR: 8186259: IOExceptionIfEncodedURLTest.sh versus
 IOExceptionIfEncodedURLTest.java
In-Reply-To: <59948C8B.6030402@oracle.com>
References: <8340ec1d-7ca4-a20e-264a-cb7fd2a2cebe@oracle.com>
 <19e2026b-0617-4cc8-f78d-d27bb782ac18@oracle.com>
 <59948C8B.6030402@oracle.com>
Message-ID: <b9f8c163-dc1f-995c-0c8c-f9aa69b8d694@oracle.com>

For the purposes of getting the test suite passing again, this looks 
fine. (Longer term, replacing the shell with the process builder API is 
probably preferable.)

Cheers,

-Joe


On 8/16/2017 11:18 AM, Tim Bell wrote:
> Phil:
>
>
>> On 08/16/2017 11:09 AM, Phil Race wrote:
>>> http://cr.openjdk.java.net/~prr/8186259/
>>>
>>> I'll take any reviewer on this which just fixes the JTREG test so that
>>> jtreg does not blow up.
>
> Looks good.  Approved.
>
> Tim
>
>


From anton.litvinov at oracle.com  Thu Aug 17 12:20:06 2017
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Thu, 17 Aug 2017 13:20:06 +0100
Subject: <AWT Dev> [10] Review request for 8166772: Touch keyboard is not
 shown for text components on a screen touch
Message-ID: <31947159-e6df-e8cc-5316-a7c1191d52b4@oracle.com>

Hello,

Could you please review the following fix for the bug.

Bug: https://bugs.openjdk.java.net/browse/JDK-8166772
Webrev: http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.00

The bug is the fact that, when a user touches any Swing or AWT text 
component, for example "JTextField", "JTextArea", "TextField", 
"TextArea", by means of a touch screen on a host with MS Windows 
10/8.1/8 OS, the system touch keyboard is not shown automatically. 
Please find a detailed description of the bug, screenshots depicting the 
touch keyboard and a compilable test case with Swing/AWT text components 
in JBS bug record. Also a summary of the done research of the issue with 
a description of identified approaches for its resolution are reported 
in my last comment in the bug record.

THE FIX:
On a very abstract level the fix functioning can be presented by the 
next 3 stages:

Stage 1.
The fix adds support of "WM_TOUCH" system window messages to AWT native 
peer windows through C++ class "AwtComponent". It "processes" "WM_TOUCH" 
message and marks "java.awt.event.MouseEvent", which is created as a 
result of handling of the further coming "WM_LBUTTONDOWN", 
"WM_LBUTTONUP" messages sent by the system in substitution for this 
"WM_TOUCH" message, by the new private field flag 
"MouseEvent.causedByTouchEvent".

Stage 2.
Then on Java level the fix handles "MouseEvent", "FocusEvent" received 
only by the instances of "java.awt.TextComponent", 
"javax.swing.text.TextComponent" in "WToolkit.showOrHideTouchKeyboard()" 
called from "Component.dispatchEventImpl()" and shows or hides the touch 
keyboard on "MouseEvent.MOUSE_RELEASED" and "FocusEvent.FOCUS_LOST" 
events by calling corresponding native methods of "WToolkit" class.

Stage 3.
Showing of the touch keyboard is implemented in C++ class "AwtToolkit" 
and is done by launching the system application "TabTip.exe" which 
implements the system touch keyboard. This approach is described in the 
bug record.

FEATURES OF THE FIX:
1. By default all native and Java parts of the fix do not function at 
all - the fix is disabled. To enable the fix the application should be 
run with "-Dawt.touchKeyboardAutoShowIsEnabled=true" option. Handling of 
this new property is implemented in "sun.awt.SunToolkit" class.

2. Native parts of the fix functions only on MS Window 8 or later.

3. The fix implements automatic showing of the touch keyboard for the 
following 2 use cases:
     a.  The user touches the text components using the touch screen.
     b.  The user does mouse clicks on the text components, while no any 
keyboard is attached to the host.

FIX LOGICAL STRUCTURE BY SOURCE CODE:
1. Core of the fix:
     Native code:  awt_Toolkit.[h/cpp], awt_Component.[h/cpp], 
awt_MouseEvent.[h/cpp], awt.h
     Java:  SunToolkit.java, WToolkit.java, Component.java, 
MouseEvent.java, AWTAccessor.java

2. Changes in all remaining Java files are connected with retaining of 
the flag value "MouseEvent.causedByTouchEvent" during creation of the 
new instances of "MouseEvent" class based on the original "MouseEvent" 
instances.

Work of the fix was verified both in the environment with the real touch 
screen device and in the environment with the emulated touch screen.

Thank you,
Anton

From sergey.bylokhov at oracle.com  Thu Aug 17 18:56:26 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 17 Aug 2017 11:56:26 -0700 (PDT)
Subject: <AWT Dev> [10] Review Request: 8186263 The SunDropTargetEvent
 sometimes is not dispatched
Message-ID: <be5c7413-cdbb-41a5-90d0-1a6b85c6fd0d@default>

Hello,
Please review one more fix for DnD in jdk10.

Bug: https://bugs.openjdk.java.net/browse/JDK-8186263
Webrev can be found at: http://cr.openjdk.java.net/~serb/8186263/webrev.00

The SunDropTargetEventEach is a special kind of MouseEvent and each SunDropTargetEvent should be dispatched, because this event stop the ToolkitThreadBlockedHandler.

 - The nested event loop is started before SunDropTargetEvent is created. See SunDropTargetContextPeer.postDropTargetEvent()
 - The SunDropTargetEvent is posted with assumption that when it will be dispatched it will stop the nested event loop. See SunDropTargetContextPeer.unregisterEvent().

SunDropTargetEvent is a subclass of MouseEvent. The dispatch of MouseEvent may be skipped if this event will be coalesced or if the target component will be disposed.

The coalescing of the SunDropTargetEvent was fixed in JDK-7177144, but it is still possible to lose the SunDropTargetEvent if the target component wlll be disposed after the event was posted, but before dispatch. This can cause a hang in DnD machinery. 

After the fix we will stop the nested loop even if the SunDropTargetEventEach is removed from the EventQueue.

The test was modified to reproduce the bug more often on macOS and Linux.
Note that the test still fail time to time on macOS because of [1].

[1] https://bugs.openjdk.java.net/browse/JDK-8186002

From philip.race at oracle.com  Thu Aug 17 19:56:22 2017
From: philip.race at oracle.com (Phil Race)
Date: Thu, 17 Aug 2017 12:56:22 -0700
Subject: <AWT Dev> [10] Review Request: 8186263 The SunDropTargetEvent
 sometimes is not dispatched
In-Reply-To: <be5c7413-cdbb-41a5-90d0-1a6b85c6fd0d@default>
References: <be5c7413-cdbb-41a5-90d0-1a6b85c6fd0d@default>
Message-ID: <678de770-d598-6551-f6df-b0528d38c83a@oracle.com>

Looks OK to me.

-phil.

On 08/17/2017 11:56 AM, Sergey Bylokhov wrote:
> Hello,
> Please review one more fix for DnD in jdk10.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8186263
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8186263/webrev.00
>
> The SunDropTargetEventEach is a special kind of MouseEvent and each SunDropTargetEvent should be dispatched, because this event stop the ToolkitThreadBlockedHandler.
>
>   - The nested event loop is started before SunDropTargetEvent is created. See SunDropTargetContextPeer.postDropTargetEvent()
>   - The SunDropTargetEvent is posted with assumption that when it will be dispatched it will stop the nested event loop. See SunDropTargetContextPeer.unregisterEvent().
>
> SunDropTargetEvent is a subclass of MouseEvent. The dispatch of MouseEvent may be skipped if this event will be coalesced or if the target component will be disposed.
>
> The coalescing of the SunDropTargetEvent was fixed in JDK-7177144, but it is still possible to lose the SunDropTargetEvent if the target component wlll be disposed after the event was posted, but before dispatch. This can cause a hang in DnD machinery.
>
> After the fix we will stop the nested loop even if the SunDropTargetEventEach is removed from the EventQueue.
>
> The test was modified to reproduce the bug more often on macOS and Linux.
> Note that the test still fail time to time on macOS because of [1].
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8186002


From sergey.bylokhov at oracle.com  Fri Aug 18 23:24:52 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 18 Aug 2017 16:24:52 -0700 (PDT)
Subject: <AWT Dev> [OpenJDK 2D-Dev] [10] JDK-8169044: The tray icon
 color is not green
Message-ID: <7b6ab1d3-1e2a-42d9-ba8d-33c4fe0aff8a@default>

Hi, Shashi. 
The config event is auto-generated during the build: 
/support/gensrc/java.desktop/sun/awt/X11/XConfigureEvent.java 
Can you please check that the size which we get from the native is properly scaled, also make sure that the native size is not "leaked" outside of the peer(for example via getBounds() method), or atleast it will be expected by the caller. 

----- shashidhara.veerabhadraiah at oracle.com wrote: 
> RE: [OpenJDK 2D-Dev] [10] JDK-8169044: The tray icon color is not green 


Hi Sergey, I have updated the Webrev. Please review this: 

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



I have made the code updates uniform in the file to take the ' scaled ' size of the icon instead of the ' hardcoded ' size earlier. 

Another point is that am not able to find the source code for the XConfigureEvent( which captures the window configuration attributes of the tray icon window in this case ) and hence am not sure about the configuration of the XWindow configuratio n response ( of the tray icon ) is scaled or not. If it i s not scaled it may require updates for the metacity window manager specific code to adjust the window configuration of the tray icon ( because metacity WM provides rectangular window instead of a square w in dow ) . 

Thanks and regards, 

Shashi 



-----Original Message----- 
> From: Sergey Bylokhov 
> Sent: Wednesday, August 2, 2017 2:45 AM 
> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com> 
> Cc: awt-dev at openjdk.java.net; 2d-dev at openjdk.java.net; Jim Graham <james.graham at oracle.com> 
> Subject: Re: [OpenJDK 2D-Dev] [10] JDK-8169044: The tray ic on color is not green 

Hi, Shashi. 

As far as I understand the "width/height" in the IconCanvas is a size of the TrayIcon in pixels. So on the normal screen it is should be 24(TRAY_ICON_WIDTH) pixels and on a HiDPI screen it should be 24*ScreenScale. The IconCanvas.width/height fields shoul d reflect this size. 

I am not sure but it looks like the current fix changes the "size" of the frame just for rendering(so we select HiDPI image) but did not change the size of the frame. So we draw the HiDPI image to non-HiDPI embedded frame. 

----- shash idhara.veerabhadraiah at oracle.com wrote: 

> Yes Jim. Per the current code base, it is defaulted to default screen. 

> 

> To have the same tray icon being represented on multiple task bars 

> would require updates to XSystemTrayPeer.java to replicate the mess age 

> being sent to X11 to add a new tray icon for a particular 

> screen(Currently it is done only for the default screen). The current 

> X11 tray system uses XEMBED protocol to add system tray icons. 

> Currently the screen is set to 0 which I think wou ld refer to default 

> screen and hence it adds tray icons only to the default screen. The 

> X11 property '_NET_SYSTEM_TRAY_S[SCREEN_NUMBER]' allows access to the 

> system tray of screen 'SCREEN_ NUMBER '. So we may need to use such 

> mechanism to add the tray icon onto different screens. This may be 

> different for windows and mac but will have a similar mechanism. 

> 

> Thanks and regards, 

> Shashi 

> 

> -----Original Message----- 

> From: Jim Graham 

> Sent: Tuesday, August 1, 2017 2: 14 AM 

> To: Shashidhara Veerabhadraiah 

> < shashidhara.veerabhadraiah at oracle.com >; awt-dev at openjdk.java.net ; 

> 2d-dev < 2d-dev at openjdk.java.net > 

> Subject: Re: [OpenJDK 2D-Dev] [10] JDK-8169044: The tray icon color is 

> not green 

> 

> Will the tray icon ca nvas always be on the default screen? I believe 

> the latest MacOS and Win10 both allow menu bars and task bars on all 

> monitors. Linux may not be far behind... 

> 

> ...jim 

> 

> On 7/30/17 11:59 PM, Shashidhara Veerabhadraiah wrote: 

> > Hi, Kindly review a fix for JDK-8169044 where the non hi dpi icon 

> was 

> > picked among the icon set of hi dpi and a non hi dpi icons for a hi 

> dpi display screen. 

> > 

> > Issue: The non hi dpi icon is red in color (and hi dpi icon is green 

> 

> > in color) and was getting picked up among the set for a hi dpi 

> display screen as shown below in the picture: 

> > 

> > Solution and fix: The icon's buffered images are not subjected to 

> the 

> > scaling because of the hi dpi screen. Hence, the default non hi dpi 

> 

> > icon was getting picked up for rendering the tray icon. Now the 

> source 

> > code modified to apply necessary transformations to the 

> bufferedimages to get the default icon based on the default display 

> screen. Below is the output aft er the fix: 

> > 

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

> > 

> > Webrev: 

> http://cr.openjdk.java.net/~pkbalakr/shashi/8169044/webrev.00/ 

> > 

> > Thanks and regards, 

> > 

> > Shashi 

> > 

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

From sergey.bylokhov at oracle.com  Sat Aug 19 02:04:50 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 18 Aug 2017 19:04:50 -0700 (PDT)
Subject: <AWT Dev> [10] Review Request: 8186474 WColor class is superseded
 by the SystemColor and should be removed
Message-ID: <af2973e8-b08c-40fe-8754-cc6083c04bb4@default>

Hello,
Please review the simple cleanup for jdk10.

Long time ago AWT used WColor class to access the native colors, but since then we integrated a public API via SystemColor class.
So WColor class became obsolete and can be removed.

Bug: https://bugs.openjdk.java.net/browse/JDK-8186474
Webrev can be found at: http://cr.openjdk.java.net/~serb/8186474/webrev.01

From alexander.zvegintsev at oracle.com  Tue Aug 22 08:10:18 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 22 Aug 2017 13:40:18 +0530
Subject: <AWT Dev> [10] Review Request: 8186474 WColor class is
 superseded by the SystemColor and should be removed
In-Reply-To: <af2973e8-b08c-40fe-8754-cc6083c04bb4@default>
References: <af2973e8-b08c-40fe-8754-cc6083c04bb4@default>
Message-ID: <68f85c10-a31b-bff3-aad0-43ae0168ef85@oracle.com>

Looks fine

Thanks,
Alexander.

On 19/08/2017 07:34, Sergey Bylokhov wrote:
> Hello,
> Please review the simple cleanup for jdk10.
>
> Long time ago AWT used WColor class to access the native colors, but since then we integrated a public API via SystemColor class.
> So WColor class became obsolete and can be removed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8186474
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8186474/webrev.01


From shashidhara.veerabhadraiah at oracle.com  Tue Aug 22 08:57:00 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 22 Aug 2017 01:57:00 -0700 (PDT)
Subject: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to
 use extended key code characters as ? ? ?.
Message-ID: <01021b84-6fef-44b2-92e8-175494399da6@default>

Hi All, Please review fix for the enhancement wherein the robot key press of non-ascii were interpreted as question marks.

 

Issue: The robot key press events was handling only the ascii inputs and ignored the other Unicode inputs. Either it was throwing illegal argument exception in windows or does nothing on the mac for those Unicode inputs.

 

Solution and fix: The platform specific api's was unable handle the non-ascii inputs. I have modified the api's to accept the non-ascii inputs and correspondingly send the message to the window to print the non-ascii characters as well. Below is the picture of how the non-ascii inputs are considered and printed onto the window.



The solution spans across windows and mac platform and still in search of a solution for the Linux platform. The solution implements key scanning only upon existing valid ascii key was not found and assumes it as Unicode key and sends the event to event queue to be processed as Unicode keys. Different formats are being used by different platform implementation of Unicode. For ex., per the below Unicode list, in the case of windows and mac, the key input can take decimal values whereas on Linux it can only take the Code values.

On Linux, I was able to get the KeySym of Unicode keys but was unable to fake the key event as there was no mechanism available for the same(which sends the key event to window). Please let me know if there is any such mechanism available to simulate Unicode key events on Linux platform. Hence I think to raise a bug for the Linux platform and close this JDK-8148344 bug.



 

Enhancement id: https://bugs.openjdk.java.net/browse/JDK-8148344

Webrev: http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/

 

Thanks and regards,

Shashi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170822/35280b83/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4356 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170822/35280b83/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 82017 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170822/35280b83/image004-0001.jpg>

From sergey.bylokhov at oracle.com  Tue Aug 22 15:04:19 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 22 Aug 2017 08:04:19 -0700 (PDT)
Subject: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able
 to use extended key code characters as ? ? ?.
Message-ID: <491be8e5-ac14-484f-80aa-ab4a70b4f374@default>

Hi, Shashi. 
Can you check how this Robot API will work when the application will have a shortcut for such key? Will such shortcuts will work after this fix? 

----- shashidhara.veerabhadraiah at oracle.com wrote: 
> 
> 
> 

Hi All, Please review fix for the enhancement wherein the robot key press of non-ascii were interpreted as question marks. 



Issue: The robot key press events was handling only the ascii inputs and ignored the other Unicode inputs. Either it was throwing illegal argument exception in windows or does nothing on the mac for those Unicode inputs. 



Solution and fix: The platform specific api?s was unable handle the non-ascii inputs. I have modified the api?s to accept the non-ascii inputs and correspondingly send the message to the window to print the non-ascii characters as well. Below is the picture of how the non-ascii inputs are considered and printed onto the window. 



The solution spans across windows and mac platform and still in search of a solution for the Linux platform. The solution implements key scanning only upon existing valid ascii key was not found and assumes it as Unicode key and sends the event to event queue to be processed as Unicode keys. Different formats are being used by different platform implementation of Unicode. For ex., per the below Unicode list, in the case of windows and mac, the key input can take decimal values whereas on Linux it can only take the Code values. 

On Linux, I was able to get the KeySym of Unicode keys but was unable to fake the key event as there was no mechanism available for the same(which sends the key event to window). Please let me know if there is any such mechanism available to simulate Unicode key events on Linux platform. Hence I think to raise a bug for the Linux platform and close this JDK-8148344 bug. 





Enhancement id: https://bugs.openjdk.java.net/browse/JDK-8148344 

Webrev: http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/ 



Thanks and regards, 

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

From semyon.sadetsky at oracle.com  Tue Aug 22 16:33:29 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 22 Aug 2017 09:33:29 -0700
Subject: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able
 to use extended key code characters as ? ? ?.
In-Reply-To: <01021b84-6fef-44b2-92e8-175494399da6@default>
References: <01021b84-6fef-44b2-92e8-175494399da6@default>
Message-ID: <25677acd-23ee-bbeb-2baf-08cf36821a88@oracle.com>

Hi,

Are you sure that keyPress/keyRelease should emulate UTF8 symbols? 
Physical keyboard cannot produces so many keycodes with a single 
press/release.

--Semyon


On 08/22/2017 01:57 AM, Shashidhara Veerabhadraiah wrote:
>
> Hi All, Please review fix for the /_enhancement_/ wherein the robot 
> key press of non-ascii were interpreted as question marks.
>
> Issue: The robot key press events was handling only the ascii inputs 
> and ignored the other Unicode inputs. Either it was throwing illegal 
> argument exception in windows or does nothing on the mac for those 
> Unicode inputs.
>
> Solution and fix: The platform specific api?s was unable handle the 
> non-ascii inputs. I have modified the api?s to accept the non-ascii 
> inputs and correspondingly send the message to the window to print the 
> non-ascii characters as well. Below is the picture of how the 
> non-ascii inputs are considered and printed onto the window.
>
> The solution spans across windows and mac platform and still in search 
> of a solution for the Linux platform. The solution implements key 
> scanning only upon existing valid ascii key was /_not_/ found and 
> assumes it as Unicode key and sends the event to event queue to be 
> processed as Unicode keys. Different formats are being used by 
> different platform implementation of Unicode. For ex., per the below 
> Unicode list, in the case of windows and mac, the key input can take 
> decimal values whereas on Linux it can only take the Code values.
>
> On Linux, I was able to get the KeySym of Unicode keys but was unable 
> to fake the key event as there was no mechanism available for the 
> same(which sends the key event to window). Please let me know if there 
> is any such mechanism available to simulate Unicode key events on 
> Linux platform. Hence I think to raise a bug for the Linux platform 
> and close this JDK-8148344 bug.
>
> Enhancement id: https://bugs.openjdk.java.net/browse/JDK-8148344
>
> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/8148344/webrev.00/>
>
> Thanks and regards,
>
> Shashi
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170822/a9e6a6eb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4356 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170822/a9e6a6eb/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 82017 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170822/a9e6a6eb/image004-0001.jpg>

From shashidhara.veerabhadraiah at oracle.com  Tue Aug 22 18:30:34 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 22 Aug 2017 11:30:34 -0700 (PDT)
Subject: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able
 to use extended key code characters as ? ? ?.
In-Reply-To: <25677acd-23ee-bbeb-2baf-08cf36821a88@oracle.com>
References: <01021b84-6fef-44b2-92e8-175494399da6@default>
 <25677acd-23ee-bbeb-2baf-08cf36821a88@oracle.com>
Message-ID: <965a5ae6-11d3-4575-811a-3780f3404445@default>

Hi, Why not if the platform offers a way to simulate Unicode keyboard events? Here the platform api offers to accept decimal values or code values as input though a real keyboard may not be able to generate the same and converts it into a displayable Unicode char.

 

Thanks and regards,

shashi

 

From: Semyon Sadetsky 
Sent: Tuesday, August 22, 2017 10:03 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

Hi,

Are you sure that keyPress/keyRelease should emulate UTF8 symbols? Physical keyboard cannot produces so many keycodes with a single press/release.

--Semyon

 

On 08/22/2017 01:57 AM, Shashidhara Veerabhadraiah wrote:

Hi All, Please review fix for the enhancement wherein the robot key press of non-ascii were interpreted as question marks.

 

Issue: The robot key press events was handling only the ascii inputs and ignored the other Unicode inputs. Either it was throwing illegal argument exception in windows or does nothing on the mac for those Unicode inputs.

 

Solution and fix: The platform specific api's was unable handle the non-ascii inputs. I have modified the api's to accept the non-ascii inputs and correspondingly send the message to the window to print the non-ascii characters as well. Below is the picture of how the non-ascii inputs are considered and printed onto the window.



The solution spans across windows and mac platform and still in search of a solution for the Linux platform. The solution implements key scanning only upon existing valid ascii key was not found and assumes it as Unicode key and sends the event to event queue to be processed as Unicode keys. Different formats are being used by different platform implementation of Unicode. For ex., per the below Unicode list, in the case of windows and mac, the key input can take decimal values whereas on Linux it can only take the Code values.

On Linux, I was able to get the KeySym of Unicode keys but was unable to fake the key event as there was no mechanism available for the same(which sends the key event to window). Please let me know if there is any such mechanism available to simulate Unicode key events on Linux platform. Hence I think to raise a bug for the Linux platform and close this JDK-8148344 bug.



 

Enhancement id: https://bugs.openjdk.java.net/browse/JDK-8148344

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8148344/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/

 

Thanks and regards,

Shashi

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170822/9b0d63b0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4356 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170822/9b0d63b0/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 81096 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170822/9b0d63b0/image003-0001.jpg>

From semyon.sadetsky at oracle.com  Tue Aug 22 18:57:34 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 22 Aug 2017 11:57:34 -0700
Subject: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able
 to use extended key code characters as ? ? ?.
In-Reply-To: <965a5ae6-11d3-4575-811a-3780f3404445@default>
References: <01021b84-6fef-44b2-92e8-175494399da6@default>
 <25677acd-23ee-bbeb-2baf-08cf36821a88@oracle.com>
 <965a5ae6-11d3-4575-811a-3780f3404445@default>
Message-ID: <7c788be9-c937-a7d9-d16c-2b2c6b0ac0c3@oracle.com>

Because press/release keycodes are not the same as characters. Character 
is produced from keycode or sequence of keycodes according to the 
selected kayboard layout.

--Semyon


On 08/22/2017 11:30 AM, Shashidhara Veerabhadraiah wrote:
>
> Hi, Why not if the platform offers a way to simulate Unicode keyboard 
> events? Here the platform api offers to accept decimal values or code 
> values as input though a real keyboard may not be able to generate the 
> same and converts it into a displayable Unicode char.
>
> Thanks and regards,
>
> shashi
>
> *From:*Semyon Sadetsky
> *Sent:* Tuesday, August 22, 2017 10:03 PM
> *To:* Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should 
> be able to use extended key code characters as ? ? ?.
>
> Hi,
>
> Are you sure that keyPress/keyRelease should emulate UTF8 symbols? 
> Physical keyboard cannot produces so many keycodes with a single 
> press/release.
>
> --Semyon
>
> On 08/22/2017 01:57 AM, Shashidhara Veerabhadraiah wrote:
>
>     Hi All, Please review fix for the /_enhancement_/ wherein the
>     robot key press of non-ascii were interpreted as question marks.
>
>     Issue: The robot key press events was handling only the ascii
>     inputs and ignored the other Unicode inputs. Either it was
>     throwing illegal argument exception in windows or does nothing on
>     the mac for those Unicode inputs.
>
>     Solution and fix: The platform specific api?s was unable handle
>     the non-ascii inputs. I have modified the api?s to accept the
>     non-ascii inputs and correspondingly send the message to the
>     window to print the non-ascii characters as well. Below is the
>     picture of how the non-ascii inputs are considered and printed
>     onto the window.
>
>     The solution spans across windows and mac platform and still in
>     search of a solution for the Linux platform. The solution
>     implements key scanning only upon existing valid ascii key was
>     /_not_/ found and assumes it as Unicode key and sends the event to
>     event queue to be processed as Unicode keys. Different formats are
>     being used by different platform implementation of Unicode. For
>     ex., per the below Unicode list, in the case of windows and mac,
>     the key input can take decimal values whereas on Linux it can only
>     take the Code values.
>
>     On Linux, I was able to get the KeySym of Unicode keys but was
>     unable to fake the key event as there was no mechanism available
>     for the same(which sends the key event to window). Please let me
>     know if there is any such mechanism available to simulate Unicode
>     key events on Linux platform. Hence I think to raise a bug for the
>     Linux platform and close this JDK-8148344 bug.
>
>     Enhancement id: https://bugs.openjdk.java.net/browse/JDK-8148344
>
>     Webrev:
>     http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/
>     <http://cr.openjdk.java.net/%7Esveerabhadra/8148344/webrev.00/>
>
>     Thanks and regards,
>
>     Shashi
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170822/842c203a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4356 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170822/842c203a/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 81096 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170822/842c203a/image003-0001.jpg>

From sergey.bylokhov at oracle.com  Tue Aug 22 21:39:06 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 22 Aug 2017 14:39:06 -0700 (PDT)
Subject: <AWT Dev> [10] Review Request: 8186617 The
 "com.sun.awt.AWTUtilities" class can be dropped in favour of public API
Message-ID: <2002d410-26a0-4160-9d4f-8c67d1902293@default>

Hello,
Please review the fix for jdk10.

Bug: https://bugs.openjdk.java.net/browse/JDK-8186617
Webrev can be found at: http://cr.openjdk.java.net/~serb/8186617/webrev.00


The client code has a "com.sun.awt.AWTUtilities" class which at some point(jdk6u10) in the past was used as a kind of "public" API.

In jdk9 this class is inaccessible and all its functionality was already provided by the public API, so this class can be removed.

AWTUtilities.isTranslucencySupported()/AWTUtilities.isWindowShapingSupported()
    -> GraphicsDevice.isWindowTranslucencySupported()

AWTUtilities.setWindowOpacity()/AWTUtilities.getWindowOpacity()
    -> Window.setOpacity/getOpacity

AWTUtilities.getWindowShape()/AWTUtilities.setWindowShape()
    -> Window.setShape()/getShape()

AWTUtilities.setWindowOpaque/AWTUtilities.isWindowOpaque
    -> setBackground()/isOpaque()

AWTUtilities.isTranslucencyCapable
    -> GraphicsConfiguration.isTranslucencyCapable()

AWTUtilities.setComponentMixingCutoutShape
    -> Component.setMixingCutoutShape()

CSR will be created after technical review. 

From shashidhara.veerabhadraiah at oracle.com  Wed Aug 23 04:32:48 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 22 Aug 2017 21:32:48 -0700 (PDT)
Subject: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able
 to use extended key code characters as ? ? ?.
In-Reply-To: <7c788be9-c937-a7d9-d16c-2b2c6b0ac0c3@oracle.com>
References: <01021b84-6fef-44b2-92e8-175494399da6@default>
 <25677acd-23ee-bbeb-2baf-08cf36821a88@oracle.com>
 <965a5ae6-11d3-4575-811a-3780f3404445@default>
 <7c788be9-c937-a7d9-d16c-2b2c6b0ac0c3@oracle.com>
Message-ID: <a138fcd7-3f22-4110-b8a7-4464d8ca42d8@default>

Hi Semyon, As I see the case there are multiple paths to display characters onto a window, either by physical keyboard, soft keyboard or simulating a key event. I think the simulating a key event provides a superset of the keys that can be simulated whereas other methods provides only a subset of this superset.

This superset is enabled via the platform provided api which was designed to handle or produce the superset of key events. We simulate the key events via the Java Robot. Now this robot does not honor the non-ascii chars because of the very implementation. After this change that barrier is opened up to provide access to other languages as well. One can input decimal values of non-ascii chars thro' robot and get them displayed on to the window.

 

Thanks and regards,

Shashi

 

From: Semyon Sadetsky 
Sent: Wednesday, August 23, 2017 12:28 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

Because press/release keycodes are not the same as characters. Character is produced from keycode or sequence of keycodes according to the selected kayboard layout.

--Semyon

 

On 08/22/2017 11:30 AM, Shashidhara Veerabhadraiah wrote:

Hi, Why not if the platform offers a way to simulate Unicode keyboard events? Here the platform api offers to accept decimal values or code values as input though a real keyboard may not be able to generate the same and converts it into a displayable Unicode char.

 

Thanks and regards,

shashi

 

From: Semyon Sadetsky 
Sent: Tuesday, August 22, 2017 10:03 PM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

 

Hi,

Are you sure that keyPress/keyRelease should emulate UTF8 symbols? Physical keyboard cannot produces so many keycodes with a single press/release.

--Semyon

 

On 08/22/2017 01:57 AM, Shashidhara Veerabhadraiah wrote:

Hi All, Please review fix for the enhancement wherein the robot key press of non-ascii were interpreted as question marks.

 

Issue: The robot key press events was handling only the ascii inputs and ignored the other Unicode inputs. Either it was throwing illegal argument exception in windows or does nothing on the mac for those Unicode inputs.

 

Solution and fix: The platform specific api's was unable handle the non-ascii inputs. I have modified the api's to accept the non-ascii inputs and correspondingly send the message to the window to print the non-ascii characters as well. Below is the picture of how the non-ascii inputs are considered and printed onto the window.



The solution spans across windows and mac platform and still in search of a solution for the Linux platform. The solution implements key scanning only upon existing valid ascii key was not found and assumes it as Unicode key and sends the event to event queue to be processed as Unicode keys. Different formats are being used by different platform implementation of Unicode. For ex., per the below Unicode list, in the case of windows and mac, the key input can take decimal values whereas on Linux it can only take the Code values.

On Linux, I was able to get the KeySym of Unicode keys but was unable to fake the key event as there was no mechanism available for the same(which sends the key event to window). Please let me know if there is any such mechanism available to simulate Unicode key events on Linux platform. Hence I think to raise a bug for the Linux platform and close this JDK-8148344 bug.



 

Enhancement id: https://bugs.openjdk.java.net/browse/JDK-8148344

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8148344/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/

 

Thanks and regards,

Shashi

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170822/4a42a851/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4356 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170822/4a42a851/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 81009 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170822/4a42a851/image003-0001.jpg>

From prasanta.sadhukhan at oracle.com  Wed Aug 23 08:39:38 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 23 Aug 2017 14:09:38 +0530
Subject: <AWT Dev> [10] RFR JDK-8088132:[Swing,
 singleThread] ClassCastException in nested event loop when showing
 multiple message dialogs in SwingNode
In-Reply-To: <23734583-9a2e-be4a-a18c-fd1d08a8d23c@oracle.com>
References: <d95551ee-89e0-439c-9a7b-90ef9beb82d1@default>
 <23734583-9a2e-be4a-a18c-fd1d08a8d23c@oracle.com>
Message-ID: <26f687c6-4ae7-81dc-31f8-72c1516f72db@oracle.com>

Any feedback on this?

Regards
Prasanta
On 8/16/2017 4:03 PM, Prasanta Sadhukhan wrote:
>
> Hi Sergey,
>
> AFAIK, FX singleThread feature is supported but experimental feature.
> I have modified webrev to include DefaultKeyboardFocusManager too
> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.01/
>
> I do not think there is any problem in skipping code which works with 
> EDT as for example, in SequencedEvent#dispatch() it says
> Dispatches the nested event after all previous nested events have 
> beendispatched or disposed
> Now, since here FX App thread itself is the dispatch thread, we can be 
> sure the events are dispatched in sequence and dispose is checked 
> below after EDT.
>
> I have tested with couple of singleThread testcase without any issue.
>
> Regards
> Prasanta
> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote:
>> Hi, Prasanta, Kevin.
>>
>> I have two notes.
>>   - Does this option is really supported? If it is supported we should evaluate all usage of EventDispatchThread because in this mode the dispatch thread is not EDT. For example I am not sure that we can skip the code which expects EventDispatchThread.
>>   - We have the similar pattern: "EventQueue.isDispatchThread() -> cast(EventDispatchThread)" in some other places like in DefaultKeyboardFocusManager.
>>
>> -----prasanta.sadhukhan at oracle.com  wrote:
>>
>>> Hi All,
>>>
>>> Please review this fix
>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/
>>> for an fx issue
>>> https://bugs.openjdk.java.net/browse/JDK-8088132
>>>
>>> More info in JBS.
>>>
>>> Regards
>>> Prasanta
>

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

From semyon.sadetsky at oracle.com  Wed Aug 23 15:01:29 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 23 Aug 2017 08:01:29 -0700
Subject: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able
 to use extended key code characters as ? ? ?.
In-Reply-To: <a138fcd7-3f22-4110-b8a7-4464d8ca42d8@default>
References: <01021b84-6fef-44b2-92e8-175494399da6@default>
 <25677acd-23ee-bbeb-2baf-08cf36821a88@oracle.com>
 <965a5ae6-11d3-4575-811a-3780f3404445@default>
 <7c788be9-c937-a7d9-d16c-2b2c6b0ac0c3@oracle.com>
 <a138fcd7-3f22-4110-b8a7-4464d8ca42d8@default>
Message-ID: <f775ff57-f8c5-c457-c89e-cf98c82767ad@oracle.com>

On 08/22/2017 09:32 PM, Shashidhara Veerabhadraiah wrote:

> Hi Semyon, As I see the case there are multiple paths to display 
> characters onto a window, either by physical keyboard, soft keyboard 
> or simulating a key event. I think the simulating a key event provides 
> a superset of the keys that can be simulated whereas other methods 
> provides only a subset of this superset.
>
> This superset is enabled via the platform provided api which was 
> designed to handle or produce the superset of key events. We simulate 
> the key events via the Java Robot. Now this robot does not honor the 
> non-ascii chars because of the very implementation. After this change 
> that barrier is opened up to provide access to other languages as 
> well. One can input decimal values of non-ascii chars thro? robot and 
> get them displayed on to the window.
>
It is enabled by some platforms. I am not sure that this is equivalent 
to the normal user interaction to the GUI. Since this is not a true 
emulation and it cannot be uses for testing because in that case the 
event sequence would be different from the real one.

--Semyon
>
> Thanks and regards,
>
> Shashi
>
> *From:*Semyon Sadetsky
> *Sent:* Wednesday, August 23, 2017 12:28 AM
> *To:* Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should 
> be able to use extended key code characters as ? ? ?.
>
> Because press/release keycodes are not the same as characters. 
> Character is produced from keycode or sequence of keycodes according 
> to the selected kayboard layout.
>
> --Semyon
>
> On 08/22/2017 11:30 AM, Shashidhara Veerabhadraiah wrote:
>
>     Hi, Why not if the platform offers a way to simulate Unicode
>     keyboard events? Here the platform api offers to accept decimal
>     values or code values as input though a real keyboard may not be
>     able to generate the same and converts it into a displayable
>     Unicode char.
>
>     Thanks and regards,
>
>     shashi
>
>     *From:*Semyon Sadetsky
>     *Sent:* Tuesday, August 22, 2017 10:03 PM
>     *To:* Shashidhara Veerabhadraiah
>     <shashidhara.veerabhadraiah at oracle.com>
>     <mailto:shashidhara.veerabhadraiah at oracle.com>;
>     awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>     *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress
>     should be able to use extended key code characters as ? ? ?.
>
>     Hi,
>
>     Are you sure that keyPress/keyRelease should emulate UTF8 symbols?
>     Physical keyboard cannot produces so many keycodes with a single
>     press/release.
>
>     --Semyon
>
>     On 08/22/2017 01:57 AM, Shashidhara Veerabhadraiah wrote:
>
>         Hi All, Please review fix for the /_enhancement_/ wherein the
>         robot key press of non-ascii were interpreted as question marks.
>
>         Issue: The robot key press events was handling only the ascii
>         inputs and ignored the other Unicode inputs. Either it was
>         throwing illegal argument exception in windows or does nothing
>         on the mac for those Unicode inputs.
>
>         Solution and fix: The platform specific api?s was unable
>         handle the non-ascii inputs. I have modified the api?s to
>         accept the non-ascii inputs and correspondingly send the
>         message to the window to print the non-ascii characters as
>         well. Below is the picture of how the non-ascii inputs are
>         considered and printed onto the window.
>
>         The solution spans across windows and mac platform and still
>         in search of a solution for the Linux platform. The solution
>         implements key scanning only upon existing valid ascii key was
>         /_not_/ found and assumes it as Unicode key and sends the
>         event to event queue to be processed as Unicode keys.
>         Different formats are being used by different platform
>         implementation of Unicode. For ex., per the below Unicode
>         list, in the case of windows and mac, the key input can take
>         decimal values whereas on Linux it can only take the Code values.
>
>         On Linux, I was able to get the KeySym of Unicode keys but was
>         unable to fake the key event as there was no mechanism
>         available for the same(which sends the key event to window).
>         Please let me know if there is any such mechanism available to
>         simulate Unicode key events on Linux platform. Hence I think
>         to raise a bug for the Linux platform and close this
>         JDK-8148344 bug.
>
>         Enhancement id: https://bugs.openjdk.java.net/browse/JDK-8148344
>
>         Webrev:
>         http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/
>         <http://cr.openjdk.java.net/%7Esveerabhadra/8148344/webrev.00/>
>
>         Thanks and regards,
>
>         Shashi
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170823/ee3c539b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4356 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170823/ee3c539b/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 81009 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170823/ee3c539b/image003-0001.jpg>

From Sergey.Bylokhov at oracle.com  Wed Aug 23 16:01:07 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 23 Aug 2017 09:01:07 -0700
Subject: <AWT Dev> [10] RFR JDK-8088132:[Swing,
 singleThread] ClassCastException in nested event loop when showing
 multiple message dialogs in SwingNode
In-Reply-To: <23734583-9a2e-be4a-a18c-fd1d08a8d23c@oracle.com>
References: <d95551ee-89e0-439c-9a7b-90ef9beb82d1@default>
 <23734583-9a2e-be4a-a18c-fd1d08a8d23c@oracle.com>
Message-ID: <ea94aa34-02fc-4dc4-01b6-182b6839797c@oracle.com>

Hi, Prasanta.

On 16.08.2017 3:33, Prasanta Sadhukhan wrote:
> Now, since here FX App thread itself is the dispatch thread, we can be 
> sure the events are dispatched in sequence and dispose is checked below 
> after EDT.

Why we can sure about this? If the SequencedEvents were created in one 
order but dispatch() for each were called in other order then the 
sequenced will not be preserved?

> 
> I have tested with couple of singleThread testcase without any issue.
> 
> Regards
> Prasanta
> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote:
>> Hi, Prasanta, Kevin.
>>
>> I have two notes.
>>   - Does this option is really supported? If it is supported we should evaluate all usage of EventDispatchThread because in this mode the dispatch thread is not EDT. For example I am not sure that we can skip the code which expects EventDispatchThread.
>>   - We have the similar pattern: "EventQueue.isDispatchThread() -> cast(EventDispatchThread)" in some other places like in DefaultKeyboardFocusManager.
>>
>> -----prasanta.sadhukhan at oracle.com  wrote:
>>
>>> Hi All,
>>>
>>> Please review this fix
>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/
>>> for an fx issue
>>> https://bugs.openjdk.java.net/browse/JDK-8088132
>>>
>>> More info in JBS.
>>>
>>> Regards
>>> Prasanta
> 


-- 
Best regards, Sergey.

From krishna.addepalli at oracle.com  Thu Aug 24 09:49:37 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 24 Aug 2017 02:49:37 -0700 (PDT)
Subject: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File) memory
 leak on "C:\" file reference
In-Reply-To: <b0a640eb-d31f-9e0c-f022-c5ad8da71326@oracle.com>
References: <180c578d-8f9d-40aa-8e14-0f88b39f734f@default>
 <b0a640eb-d31f-9e0c-f022-c5ad8da71326@oracle.com>
Message-ID: <ca162d83-bd7c-40ef-a361-bd3235f0cc4b@default>

Hi Sergey,

The root cause for the OOM exception is due to mismatched thread priority. When folders are listed, each folder/file is associated with a COM object, that is wrapped by the Java ShellFolder object. Now, when the ShellFolder object needs to be deleted, the underlying COM object should be released in ComThread, whose priority is normal. Whereas, the java2D.Disposer thread runs at highest priority, but it is unable to clean up the piled up objects, which eventually leads to this exception.

I have added a fix for this as well, and created a new webrev as below:

http://cr.openjdk.java.net/~pkbalakr/Krishna/8175015/webrev01/

Thanks,
Krishna

-----Original Message-----
From: Sergey Bylokhov 
Sent: Wednesday, August 9, 2017 5:16 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File) memory leak on "C:\" file reference

Hi, Krishna.> The problem is internally, Win32ShellFolderManager2.java, the function
> "isFileSystemRoot" is called, which lists the contents of all the root 
> drives, in addition to including them. It also includes the hidden 
> files. For each file present, it is wrapped with a "Win32ShellFolder2"
> object. So, for each query, it will list the files in the drives, and 
> throws them away, which is leading to both memory consumption as well 
> as slow performance.

If for each query we list the files in the drive and *throws* all of them away, then why(and where) we have a memory leak and as a result OOM.


-- 
Best regards, Sergey.

From manajit.halder at oracle.com  Thu Aug 24 10:01:27 2017
From: manajit.halder at oracle.com (Manajit Halder)
Date: Thu, 24 Aug 2017 15:31:27 +0530
Subject: <AWT Dev> <AWT dev>[10] Review request for JDK-8177326: [macosx]
 mouse event goes to button in
 java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java
Message-ID: <9B02E738-E313-49F7-9550-C7AE1D3851A4@oracle.com>

Hi All,

Kindly review the fix for JDK10.

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

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

Issue: 
[macosx] mouse event goes to button in java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java.

Cause: 
Problem in the test case. Initial observation was that the test case used to pass for the first time and fail second time onwards. On further debugging it was observed that the test case used to pass every time if the initial mouse move in the test actually happened. The test used to fail every second or further times because after the first execution using jtreg the mouse used to remain at the same location. 
 
Fix: 
The mouse is moved at the beginning of the test to make sure the initial mouse move on the label always happens.

Note:
BUTTON1_MASK is deprecated and hence is replaced with BUTTON1_DOWN_MASK.

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

From prasanta.sadhukhan at oracle.com  Mon Aug 28 08:53:50 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 28 Aug 2017 14:23:50 +0530
Subject: <AWT Dev> [10] RFR JDK-8088132:[Swing,
 singleThread] ClassCastException in nested event loop when showing
 multiple message dialogs in SwingNode
In-Reply-To: <ea94aa34-02fc-4dc4-01b6-182b6839797c@oracle.com>
References: <d95551ee-89e0-439c-9a7b-90ef9beb82d1@default>
 <23734583-9a2e-be4a-a18c-fd1d08a8d23c@oracle.com>
 <ea94aa34-02fc-4dc4-01b6-182b6839797c@oracle.com>
Message-ID: <7452f5e1-a764-37e9-d757-2600afc964bb@oracle.com>

I have incorporated the logic to make sure the events are dispatched in 
sequence, ie if the event is not first in sequence, then it will made to 
wait till it is the first event or till it is disposed.

Modified webrev
http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/

Regards
Prasanta
On 8/23/2017 9:31 PM, Sergey Bylokhov wrote:
> Hi, Prasanta.
>
> On 16.08.2017 3:33, Prasanta Sadhukhan wrote:
>> Now, since here FX App thread itself is the dispatch thread, we can 
>> be sure the events are dispatched in sequence and dispose is checked 
>> below after EDT.
>
> Why we can sure about this? If the SequencedEvents were created in one 
> order but dispatch() for each were called in other order then the 
> sequenced will not be preserved?
>
>>
>> I have tested with couple of singleThread testcase without any issue.
>>
>> Regards
>> Prasanta
>> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote:
>>> Hi, Prasanta, Kevin.
>>>
>>> I have two notes.
>>> ? - Does this option is really supported? If it is supported we 
>>> should evaluate all usage of EventDispatchThread because in this 
>>> mode the dispatch thread is not EDT. For example I am not sure that 
>>> we can skip the code which expects EventDispatchThread.
>>> ? - We have the similar pattern: "EventQueue.isDispatchThread() -> 
>>> cast(EventDispatchThread)" in some other places like in 
>>> DefaultKeyboardFocusManager.
>>>
>>> -----prasanta.sadhukhan at oracle.com? wrote:
>>>
>>>> Hi All,
>>>>
>>>> Please review this fix
>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/
>>>> for an fx issue
>>>> https://bugs.openjdk.java.net/browse/JDK-8088132
>>>>
>>>> More info in JBS.
>>>>
>>>> Regards
>>>> Prasanta
>>
>
>


From sergey.bylokhov at oracle.com  Tue Aug 29 00:47:09 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 28 Aug 2017 17:47:09 -0700 (PDT)
Subject: <AWT Dev> <AWT dev>[10] Review request for JDK-8177326:
 [macosx] mouse event goes to button in
 java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java
Message-ID: <6eeab1c1-7827-42a1-999e-f14c5edfbe72@default>

Hi, Manajit. 
Need of additional movement of a mouse means that we did not get all necessary events when the window occurred under the mouse. This test was created for JDK-7154048 which fixed similar issues: 
http://mail.openjdk.java.net/pipermail/awt-dev/2012-April/002613.html 
"1) The window does not receive the mouse entered event when it is created under the mouse" 

I run this test twice on jdk 8 GA and it is passed, so it seems we have a regression in jdk8/9. I suggest to investigate what is the root issue, and change the test so it will always fail for the first run (we can run twice when the mouse inside/ouside label). 

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

> Kindly review the fix for JDK10. 
> 

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

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

> Issue: 
> [macosx] mouse event goes to button in java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java. 
> 

> Cause: 
> Problem in the test case. Initial observation was that the test case used to pass for the first time and fail second time onwards. On further debugging it was observed that the test case used to pass every time if the initial mouse move in the test actually happened. The test used to fail every second or further times because after the first execution using jtreg the mouse used to remain at the same location. 



> Fix: 
> The mouse is moved at the beginning of the test to make sure the initial mouse move on the label always happens. 
> 

> Note: 
> BUTTON1_MASK is deprecated and hence is replaced with BUTTON1_DOWN_MASK. 
> 

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

From sergey.bylokhov at oracle.com  Tue Aug 29 00:49:22 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 28 Aug 2017 17:49:22 -0700 (PDT)
Subject: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File) memory
 leak on "C:\" file reference
Message-ID: <f232792e-8bb7-4c89-8549-344b2cdb4ec3@default>

Hi, Krishna.
Did you check other priorities like Thread.MAX_PRIORITY-1/2/3?  

----- krishna.addepalli at oracle.com wrote:

> Hi Sergey,
> 
> The root cause for the OOM exception is due to mismatched thread
> priority. When folders are listed, each folder/file is associated with
> a COM object, that is wrapped by the Java ShellFolder object. Now,
> when the ShellFolder object needs to be deleted, the underlying COM
> object should be released in ComThread, whose priority is normal.
> Whereas, the java2D.Disposer thread runs at highest priority, but it
> is unable to clean up the piled up objects, which eventually leads to
> this exception.
> 
> I have added a fix for this as well, and created a new webrev as
> below:
> 
> http://cr.openjdk.java.net/~pkbalakr/Krishna/8175015/webrev01/
> 
> Thanks,
> Krishna
> 
> -----Original Message-----
> From: Sergey Bylokhov 
> Sent: Wednesday, August 9, 2017 5:16 AM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
> awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File)
> memory leak on "C:\" file reference
> 
> Hi, Krishna.> The problem is internally,
> Win32ShellFolderManager2.java, the function
> > "isFileSystemRoot" is called, which lists the contents of all the
> root 
> > drives, in addition to including them. It also includes the hidden 
> > files. For each file present, it is wrapped with a
> "Win32ShellFolder2"
> > object. So, for each query, it will list the files in the drives,
> and 
> > throws them away, which is leading to both memory consumption as
> well 
> > as slow performance.
> 
> If for each query we list the files in the drive and *throws* all of
> them away, then why(and where) we have a memory leak and as a result
> OOM.
> 
> 
> -- 
> Best regards, Sergey.

From krishna.addepalli at oracle.com  Tue Aug 29 04:51:48 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Mon, 28 Aug 2017 21:51:48 -0700 (PDT)
Subject: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File) memory
 leak on "C:\" file reference
In-Reply-To: <f232792e-8bb7-4c89-8549-344b2cdb4ec3@default>
References: <f232792e-8bb7-4c89-8549-344b2cdb4ec3@default>
Message-ID: <2908c5f8-c7b9-4453-b488-6741f279c02f@default>

Hi Sergey,

I checked with Thread.MAX_PRIORITY - 1, and found that it still leads to OOM exception, although it takes longer to get to that condition.

Thanks,
Krishna

-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, August 29, 2017 6:19 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File) memory leak on "C:\" file reference

Hi, Krishna.
Did you check other priorities like Thread.MAX_PRIORITY-1/2/3?  

----- krishna.addepalli at oracle.com wrote:

> Hi Sergey,
> 
> The root cause for the OOM exception is due to mismatched thread 
> priority. When folders are listed, each folder/file is associated with 
> a COM object, that is wrapped by the Java ShellFolder object. Now, 
> when the ShellFolder object needs to be deleted, the underlying COM 
> object should be released in ComThread, whose priority is normal.
> Whereas, the java2D.Disposer thread runs at highest priority, but it 
> is unable to clean up the piled up objects, which eventually leads to 
> this exception.
> 
> I have added a fix for this as well, and created a new webrev as
> below:
> 
> http://cr.openjdk.java.net/~pkbalakr/Krishna/8175015/webrev01/
> 
> Thanks,
> Krishna
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Wednesday, August 9, 2017 5:16 AM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
> awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File) 
> memory leak on "C:\" file reference
> 
> Hi, Krishna.> The problem is internally, 
> Win32ShellFolderManager2.java, the function
> > "isFileSystemRoot" is called, which lists the contents of all the
> root
> > drives, in addition to including them. It also includes the hidden 
> > files. For each file present, it is wrapped with a
> "Win32ShellFolder2"
> > object. So, for each query, it will list the files in the drives,
> and
> > throws them away, which is leading to both memory consumption as
> well
> > as slow performance.
> 
> If for each query we list the files in the drive and *throws* all of 
> them away, then why(and where) we have a memory leak and as a result 
> OOM.
> 
> 
> --
> Best regards, Sergey.

From shashidhara.veerabhadraiah at oracle.com  Tue Aug 29 07:07:08 2017
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 29 Aug 2017 00:07:08 -0700 (PDT)
Subject: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able
 to use extended key code characters as ? ? ?.
In-Reply-To: <491be8e5-ac14-484f-80aa-ab4a70b4f374@default>
References: <491be8e5-ac14-484f-80aa-ab4a70b4f374@default>
Message-ID: <9ac25a6f-a6f6-463e-9ed4-6e366e4efa9c@default>

Hi Sergey, I was only able to add short cut keys in the Microsoft word but not as a system wide short cut key. There was no mechanism that I could find to add a short cut key for a Unicode char!! Can you please tell me the steps to do the same if you are aware of?

?

Thanks and regards,

shashi

?

From: Sergey Bylokhov 
Sent: Tuesday, August 22, 2017 8:34 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

?

Hi, Shashi.
Can you check how this Robot API will work when the application will have a shortcut for such key? Will such shortcuts will work after this fix? 

----- HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com wrote: 
> 

> 

> 

Hi All, Please review fix for the enhancement wherein the robot key press of non-ascii were interpreted as question marks.

?

Issue: The robot key press events was handling only the ascii inputs and ignored the other Unicode inputs. Either it was throwing illegal argument exception in windows or does nothing on the mac for those Unicode inputs.

?

Solution and fix: The platform specific api?s was unable handle the non-ascii inputs. I have modified the api?s to accept the non-ascii inputs and correspondingly send the message to the window to print the non-ascii characters as well. Below is the picture of how the non-ascii inputs are considered and printed onto the window.



The solution spans across windows and mac platform and still in search of a solution for the Linux platform. The solution implements key scanning only upon existing valid ascii key was not found and assumes it as Unicode key and sends the event to event queue to be processed as Unicode keys. Different formats are being used by different platform implementation of Unicode. For ex., per the below Unicode list, in the case of windows and mac, the key input can take decimal values whereas on Linux it can only take the Code values.

On Linux, I was able to get the KeySym of Unicode keys but was unable to fake the key event as there was no mechanism available for the same(which sends the key event to window). Please let me know if there is any such mechanism available to simulate Unicode key events on Linux platform. Hence I think to raise a bug for the Linux platform and close this JDK-8148344 bug.



?

Enhancement id: https://bugs.openjdk.java.net/browse/JDK-8148344

Webrev: http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/

?

Thanks and regards,

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

From sergey.bylokhov at oracle.com  Tue Aug 29 21:03:21 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 29 Aug 2017 14:03:21 -0700 (PDT)
Subject: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able
 to use extended key code characters as ? ? ?.
Message-ID: <8ddfdf09-9752-4193-ba8b-6a3f4db5f42d@default>

Hi, Shashi. 

This is part of this fix, to figure out how it will work for external applications. As you said this functionally can be useful for an onscreen keyboards, which virtually can have any possible keys, but we should check how the applications will react on such keys: 
- Will the application get some kind of keyPress/Release? 
- Will the application get some keyCode for such event? 
- Is it possible to get autorepeat for such keys?(between press/release) 

Depending from the answers above we can enhance existed robot API or provide a new one: 
like Robot.keyType(char)/etc 

----- shashidhara.veerabhadraiah at oracle.com wrote: 
> 
> 
> 

Hi Sergey, I was only able to add short cut keys in the Microsoft word but not as a system wide short cut key. There was no mechanism that I could find to add a short cut key for a Unicode char!! Can you please tell me the steps to do the same if you are aware of? 



Thanks and regards, 

shashi 



> 

From: Sergey Bylokhov 
> Sent: Tuesday, August 22, 2017 8:34 PM 
> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com> 
> Cc: awt-dev at openjdk.java.net 
> Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. 




Hi, Shashi. 
> Can you check how this Robot API will work when the application will have a shortcut for such key? Will such shortcuts will work after this fix? 
> 
> ----- shashidhara.veerabhadraiah at oracle.com wrote: 
> > 


> 

> 

Hi All, Please review fix for the enhancement wherein the robot key press of non-ascii were interpreted as question marks. 



Issue: The robot key press events was handling only the ascii inputs and ignored the other Unicode inputs. Either it was throwing illegal argument exception in windows or does nothing on the mac for those Unicode inputs. 



Solution and fix: The platform specific api?s was unable handle the non-ascii inputs. I have modified the api?s to accept the non-ascii inputs and correspondingly send the message to the window to print the non-ascii characters as well. Below is the picture of how the non-ascii inputs are considered and printed onto the window. 



The solution spans across windows and mac platform and still in search of a solution for the Linux platform. The solution implements key scanning only upon existing valid ascii key was not found and assumes it as Unicode key and sends the event to event queue to be processed as Unicode keys. Different formats are being used by different platform implementation of Unicode. For ex., per the below Unicode list, in the case of windows and mac, the key input can take decimal values whereas on Linux it can only take the Code values. 

On Linux, I was able to get the KeySym of Unicode keys but was unable to fake the key event as there was no mechanism available for the same(which sends the key event to window). Please let me know if there is any such mechanism available to simulate Unicode key events on Linux platform. Hence I think to raise a bug for the Linux platform and close this JDK-8148344 bug. 





Enhancement id: https://bugs.openjdk.java.net/browse/JDK-8148344 

Webrev: http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/ 



Thanks and regards, 

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

From sergey.bylokhov at oracle.com  Wed Aug 30 06:11:56 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 29 Aug 2017 23:11:56 -0700 (PDT)
Subject: <AWT Dev> [10] RFR JDK-8088132:[Swing,
 singleThread] ClassCastException in nested event loop when showing
 multiple message dialogs in SwingNode
Message-ID: <bc568398-c4e4-41de-be9a-b2f3c57832fb@default>

Hi, Prasanta.
Can you please provide some description on how the SecondaryLoop will work when it will run on Appkit thread? Is it possible to get a deadlock here, since appkit will be blocked?

> sequence, ie if the event is not first in sequence, then it will made
> to 
> wait till it is the first event or till it is disposed.

Note that the new code (unlike lines 139-150) also waits 1 second, so we can get a situation when only one event will be dispatched per second, which is not we want to do. 
I am not sure how often we create SequencedEvent but creating one thread per dispatch look inefficient.


> 
> Modified webrev
> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/
> 
> Regards
> Prasanta
> On 8/23/2017 9:31 PM, Sergey Bylokhov wrote:
> > Hi, Prasanta.
> >
> > On 16.08.2017 3:33, Prasanta Sadhukhan wrote:
> >> Now, since here FX App thread itself is the dispatch thread, we can
> 
> >> be sure the events are dispatched in sequence and dispose is
> checked 
> >> below after EDT.
> >
> > Why we can sure about this? If the SequencedEvents were created in
> one 
> > order but dispatch() for each were called in other order then the 
> > sequenced will not be preserved?
> >
> >>
> >> I have tested with couple of singleThread testcase without any
> issue.
> >>
> >> Regards
> >> Prasanta
> >> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote:
> >>> Hi, Prasanta, Kevin.
> >>>
> >>> I have two notes.
> >>> ? - Does this option is really supported? If it is supported we 
> >>> should evaluate all usage of EventDispatchThread because in this 
> >>> mode the dispatch thread is not EDT. For example I am not sure
> that 
> >>> we can skip the code which expects EventDispatchThread.
> >>> ? - We have the similar pattern: "EventQueue.isDispatchThread() ->
> 
> >>> cast(EventDispatchThread)" in some other places like in 
> >>> DefaultKeyboardFocusManager.
> >>>
> >>> -----prasanta.sadhukhan at oracle.com? wrote:
> >>>
> >>>> Hi All,
> >>>>
> >>>> Please review this fix
> >>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/
> >>>> for an fx issue
> >>>> https://bugs.openjdk.java.net/browse/JDK-8088132
> >>>>
> >>>> More info in JBS.
> >>>>
> >>>> Regards
> >>>> Prasanta
> >>
> >
> >

From sergey.bylokhov at oracle.com  Wed Aug 30 06:12:51 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 29 Aug 2017 23:12:51 -0700 (PDT)
Subject: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File) memory
 leak on "C:\" file reference
Message-ID: <37184ddd-82b1-4c75-b6e9-6a08cac78a6c@default>

Ok, looks fine.

----- krishna.addepalli at oracle.com wrote:

> Hi Sergey,
> 
> I checked with Thread.MAX_PRIORITY - 1, and found that it still leads
> to OOM exception, although it takes longer to get to that condition.
> 
> Thanks,
> Krishna
> 
> -----Original Message-----
> From: Sergey Bylokhov 
> Sent: Tuesday, August 29, 2017 6:19 AM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>
> Cc: awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File)
> memory leak on "C:\" file reference
> 
> Hi, Krishna.
> Did you check other priorities like Thread.MAX_PRIORITY-1/2/3?  
> 
> ----- krishna.addepalli at oracle.com wrote:
> 
> > Hi Sergey,
> > 
> > The root cause for the OOM exception is due to mismatched thread 
> > priority. When folders are listed, each folder/file is associated
> with 
> > a COM object, that is wrapped by the Java ShellFolder object. Now, 
> > when the ShellFolder object needs to be deleted, the underlying COM
> 
> > object should be released in ComThread, whose priority is normal.
> > Whereas, the java2D.Disposer thread runs at highest priority, but it
> 
> > is unable to clean up the piled up objects, which eventually leads
> to 
> > this exception.
> > 
> > I have added a fix for this as well, and created a new webrev as
> > below:
> > 
> > http://cr.openjdk.java.net/~pkbalakr/Krishna/8175015/webrev01/
> > 
> > Thanks,
> > Krishna
> > 
> > -----Original Message-----
> > From: Sergey Bylokhov
> > Sent: Wednesday, August 9, 2017 5:16 AM
> > To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
> > awt-dev at openjdk.java.net
> > Subject: Re: <AWT Dev> [10][JDK-8175015]
> FileSystemView.isDrive(File) 
> > memory leak on "C:\" file reference
> > 
> > Hi, Krishna.> The problem is internally, 
> > Win32ShellFolderManager2.java, the function
> > > "isFileSystemRoot" is called, which lists the contents of all the
> > root
> > > drives, in addition to including them. It also includes the hidden
> 
> > > files. For each file present, it is wrapped with a
> > "Win32ShellFolder2"
> > > object. So, for each query, it will list the files in the drives,
> > and
> > > throws them away, which is leading to both memory consumption as
> > well
> > > as slow performance.
> > 
> > If for each query we list the files in the drive and *throws* all of
> 
> > them away, then why(and where) we have a memory leak and as a result
> 
> > OOM.
> > 
> > 
> > --
> > Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Wed Aug 30 08:30:13 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 30 Aug 2017 14:00:13 +0530
Subject: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File) memory
 leak on "C:\" file reference
In-Reply-To: <37184ddd-82b1-4c75-b6e9-6a08cac78a6c@default>
References: <37184ddd-82b1-4c75-b6e9-6a08cac78a6c@default>
Message-ID: <9c2133bd-18d5-6d34-8daf-c0dbec55814a@oracle.com>

One thing, if sf.isFileSystem() is true and sf.parent is NULL, then in 
previous case, it falls through but with this fix, it returns false. Can 
you clarify?

Regards
Prasanta
On 8/30/2017 11:42 AM, Sergey Bylokhov wrote:
> Ok, looks fine.
>
> ----- krishna.addepalli at oracle.com wrote:
>
>> Hi Sergey,
>>
>> I checked with Thread.MAX_PRIORITY - 1, and found that it still leads
>> to OOM exception, although it takes longer to get to that condition.
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Tuesday, August 29, 2017 6:19 AM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>
>> Cc: awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File)
>> memory leak on "C:\" file reference
>>
>> Hi, Krishna.
>> Did you check other priorities like Thread.MAX_PRIORITY-1/2/3?
>>
>> ----- krishna.addepalli at oracle.com wrote:
>>
>>> Hi Sergey,
>>>
>>> The root cause for the OOM exception is due to mismatched thread
>>> priority. When folders are listed, each folder/file is associated
>> with
>>> a COM object, that is wrapped by the Java ShellFolder object. Now,
>>> when the ShellFolder object needs to be deleted, the underlying COM
>>> object should be released in ComThread, whose priority is normal.
>>> Whereas, the java2D.Disposer thread runs at highest priority, but it
>>> is unable to clean up the piled up objects, which eventually leads
>> to
>>> this exception.
>>>
>>> I have added a fix for this as well, and created a new webrev as
>>> below:
>>>
>>> http://cr.openjdk.java.net/~pkbalakr/Krishna/8175015/webrev01/
>>>
>>> Thanks,
>>> Krishna
>>>
>>> -----Original Message-----
>>> From: Sergey Bylokhov
>>> Sent: Wednesday, August 9, 2017 5:16 AM
>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>> awt-dev at openjdk.java.net
>>> Subject: Re: <AWT Dev> [10][JDK-8175015]
>> FileSystemView.isDrive(File)
>>> memory leak on "C:\" file reference
>>>
>>> Hi, Krishna.> The problem is internally,
>>> Win32ShellFolderManager2.java, the function
>>>> "isFileSystemRoot" is called, which lists the contents of all the
>>> root
>>>> drives, in addition to including them. It also includes the hidden
>>>> files. For each file present, it is wrapped with a
>>> "Win32ShellFolder2"
>>>> object. So, for each query, it will list the files in the drives,
>>> and
>>>> throws them away, which is leading to both memory consumption as
>>> well
>>>> as slow performance.
>>> If for each query we list the files in the drive and *throws* all of
>>> them away, then why(and where) we have a memory leak and as a result
>>> OOM.
>>>
>>>
>>> --
>>> Best regards, Sergey.

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

From krishna.addepalli at oracle.com  Wed Aug 30 09:11:34 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 30 Aug 2017 02:11:34 -0700 (PDT)
Subject: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File) memory
 leak on "C:\" file reference
In-Reply-To: <9c2133bd-18d5-6d34-8daf-c0dbec55814a@oracle.com>
References: <37184ddd-82b1-4c75-b6e9-6a08cac78a6c@default>
 <9c2133bd-18d5-6d34-8daf-c0dbec55814a@oracle.com>
Message-ID: <85afb6f9-7c61-433b-b5b5-1a9487a8d470@default>

Hi Prasanta,

?

Even in the previous case, it falls through and returns false. The same behavior is maintained with the current code as well.

?

Thanks,

Krishna

?

From: Prasanta Sadhukhan 
Sent: Wednesday, August 30, 2017 2:00 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File) memory leak on "C:\" file reference

?

One thing, if sf.isFileSystem() is true and sf.parent is NULL, then in previous case, it falls through but with this fix, it returns false. Can you clarify?

Regards
Prasanta

On 8/30/2017 11:42 AM, Sergey Bylokhov wrote:

Ok, looks fine.
?
----- HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com wrote:
?

Hi Sergey,
?
I checked with Thread.MAX_PRIORITY - 1, and found that it still leads
to OOM exception, although it takes longer to get to that condition.
?
Thanks,
Krishna
?
-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, August 29, 2017 6:19 AM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File)
memory leak on "C:\" file reference
?
Hi, Krishna.
Did you check other priorities like Thread.MAX_PRIORITY-1/2/3?? 
?
----- HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com wrote:
?

Hi Sergey,
?
The root cause for the OOM exception is due to mismatched thread 
priority. When folders are listed, each folder/file is associated

with 

a COM object, that is wrapped by the Java ShellFolder object. Now, 
when the ShellFolder object needs to be deleted, the underlying COM

?

object should be released in ComThread, whose priority is normal.
Whereas, the java2D.Disposer thread runs at highest priority, but it

?

is unable to clean up the piled up objects, which eventually leads

to 

this exception.
?
I have added a fix for this as well, and created a new webrev as
below:
?
http://cr.openjdk.java.net/~pkbalakr/Krishna/8175015/webrev01/
?
Thanks,
Krishna
?
-----Original Message-----
From: Sergey Bylokhov
Sent: Wednesday, August 9, 2017 5:16 AM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; 
HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10][JDK-8175015]

FileSystemView.isDrive(File) 

memory leak on "C:\" file reference
?
Hi, Krishna.> The problem is internally, 
Win32ShellFolderManager2.java, the function

"isFileSystemRoot" is called, which lists the contents of all the

root

drives, in addition to including them. It also includes the hidden

?

files. For each file present, it is wrapped with a

"Win32ShellFolder2"

object. So, for each query, it will list the files in the drives,

and

throws them away, which is leading to both memory consumption as

well

as slow performance.

?
If for each query we list the files in the drive and *throws* all of

?

them away, then why(and where) we have a memory leak and as a result

?

OOM.
?
?
--
Best regards, Sergey.

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

From prasanta.sadhukhan at oracle.com  Wed Aug 30 10:45:44 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 30 Aug 2017 16:15:44 +0530
Subject: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File) memory
 leak on "C:\" file reference
In-Reply-To: <85afb6f9-7c61-433b-b5b5-1a9487a8d470@default>
References: <37184ddd-82b1-4c75-b6e9-6a08cac78a6c@default>
 <9c2133bd-18d5-6d34-8daf-c0dbec55814a@oracle.com>
 <85afb6f9-7c61-433b-b5b5-1a9487a8d470@default>
Message-ID: <aea5c275-2194-e59d-92bd-145a9ad2b5d4@oracle.com>

ok..looks fine.

Regards
Prasanta
On 8/30/2017 2:41 PM, Krishna Addepalli wrote:
>
> Hi Prasanta,
>
> Even in the previous case, it falls through and returns false. The 
> same behavior is maintained with the current code as well.
>
> Thanks,
>
> Krishna
>
> *From:*Prasanta Sadhukhan
> *Sent:* Wednesday, August 30, 2017 2:00 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
> *Cc:* awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [10][JDK-8175015] 
> FileSystemView.isDrive(File) memory leak on "C:\" file reference
>
> One thing, if sf.isFileSystem() is true and sf.parent is NULL, then in 
> previous case, it falls through but with this fix, it returns false. 
> Can you clarify?
>
> Regards
> Prasanta
>
> On 8/30/2017 11:42 AM, Sergey Bylokhov wrote:
>
>     Ok, looks fine.
>
>       
>
>     -----krishna.addepalli at oracle.com <mailto:krishna.addepalli at oracle.com>  wrote:
>
>       
>
>         Hi Sergey,
>
>           
>
>         I checked with Thread.MAX_PRIORITY - 1, and found that it still leads
>
>         to OOM exception, although it takes longer to get to that condition.
>
>           
>
>         Thanks,
>
>         Krishna
>
>           
>
>         -----Original Message-----
>
>         From: Sergey Bylokhov
>
>         Sent: Tuesday, August 29, 2017 6:19 AM
>
>         To: Krishna Addepalli<krishna.addepalli at oracle.com>
>         <mailto:krishna.addepalli at oracle.com>
>
>         Cc:awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>
>         Subject: Re: <AWT Dev> [10][JDK-8175015] FileSystemView.isDrive(File)
>
>         memory leak on "C:\" file reference
>
>           
>
>         Hi, Krishna.
>
>         Did you check other priorities like Thread.MAX_PRIORITY-1/2/3?
>
>           
>
>         -----krishna.addepalli at oracle.com <mailto:krishna.addepalli at oracle.com>  wrote:
>
>           
>
>             Hi Sergey,
>
>               
>
>             The root cause for the OOM exception is due to mismatched thread
>
>             priority. When folders are listed, each folder/file is associated
>
>         with
>
>             a COM object, that is wrapped by the Java ShellFolder object. Now,
>
>             when the ShellFolder object needs to be deleted, the underlying COM
>
>           
>
>             object should be released in ComThread, whose priority is normal.
>
>             Whereas, the java2D.Disposer thread runs at highest priority, but it
>
>           
>
>             is unable to clean up the piled up objects, which eventually leads
>
>         to
>
>             this exception.
>
>               
>
>             I have added a fix for this as well, and created a new webrev as
>
>             below:
>
>               
>
>             http://cr.openjdk.java.net/~pkbalakr/Krishna/8175015/webrev01/
>             <http://cr.openjdk.java.net/%7Epkbalakr/Krishna/8175015/webrev01/>
>
>               
>
>             Thanks,
>
>             Krishna
>
>               
>
>             -----Original Message-----
>
>             From: Sergey Bylokhov
>
>             Sent: Wednesday, August 9, 2017 5:16 AM
>
>             To: Krishna Addepalli<krishna.addepalli at oracle.com>
>             <mailto:krishna.addepalli at oracle.com>;
>
>             awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>
>             Subject: Re: <AWT Dev> [10][JDK-8175015]
>
>         FileSystemView.isDrive(File)
>
>             memory leak on "C:\" file reference
>
>               
>
>             Hi, Krishna.> The problem is internally,
>
>             Win32ShellFolderManager2.java, the function
>
>                 "isFileSystemRoot" is called, which lists the contents of all the
>
>             root
>
>                 drives, in addition to including them. It also includes the hidden
>
>           
>
>                 files. For each file present, it is wrapped with a
>
>             "Win32ShellFolder2"
>
>                 object. So, for each query, it will list the files in the drives,
>
>             and
>
>                 throws them away, which is leading to both memory consumption as
>
>             well
>
>                 as slow performance.
>
>               
>
>             If for each query we list the files in the drive and *throws* all of
>
>           
>
>             them away, then why(and where) we have a memory leak and as a result
>
>           
>
>             OOM.
>
>               
>
>               
>
>             --
>
>             Best regards, Sergey.
>

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

From anton.litvinov at oracle.com  Wed Aug 30 18:51:32 2017
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Wed, 30 Aug 2017 19:51:32 +0100
Subject: <AWT Dev> [10] Review request for 8166772: Touch keyboard is
 not shown for text components on a screen touch
In-Reply-To: <31947159-e6df-e8cc-5316-a7c1191d52b4@oracle.com>
References: <31947159-e6df-e8cc-5316-a7c1191d52b4@oracle.com>
Message-ID: <04237368-d782-2e60-6c26-0835c2898346@oracle.com>

Hello dear reviewers,

Could anybody please look at this review request?

Thank you,
Anton

On 17/08/2017 13:20, Anton Litvinov wrote:
> Hello,
>
> Could you please review the following fix for the bug.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166772
> Webrev: http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.00
>
> The bug is the fact that, when a user touches any Swing or AWT text 
> component, for example "JTextField", "JTextArea", "TextField", 
> "TextArea", by means of a touch screen on a host with MS Windows 
> 10/8.1/8 OS, the system touch keyboard is not shown automatically. 
> Please find a detailed description of the bug, screenshots depicting 
> the touch keyboard and a compilable test case with Swing/AWT text 
> components in JBS bug record. Also a summary of the done research of 
> the issue with a description of identified approaches for its 
> resolution are reported in my last comment in the bug record.
>
> THE FIX:
> On a very abstract level the fix functioning can be presented by the 
> next 3 stages:
>
> Stage 1.
> The fix adds support of "WM_TOUCH" system window messages to AWT 
> native peer windows through C++ class "AwtComponent". It "processes" 
> "WM_TOUCH" message and marks "java.awt.event.MouseEvent", which is 
> created as a result of handling of the further coming 
> "WM_LBUTTONDOWN", "WM_LBUTTONUP" messages sent by the system in 
> substitution for this "WM_TOUCH" message, by the new private field 
> flag "MouseEvent.causedByTouchEvent".
>
> Stage 2.
> Then on Java level the fix handles "MouseEvent", "FocusEvent" received 
> only by the instances of "java.awt.TextComponent", 
> "javax.swing.text.TextComponent" in 
> "WToolkit.showOrHideTouchKeyboard()" called from 
> "Component.dispatchEventImpl()" and shows or hides the touch keyboard 
> on "MouseEvent.MOUSE_RELEASED" and "FocusEvent.FOCUS_LOST" events by 
> calling corresponding native methods of "WToolkit" class.
>
> Stage 3.
> Showing of the touch keyboard is implemented in C++ class "AwtToolkit" 
> and is done by launching the system application "TabTip.exe" which 
> implements the system touch keyboard. This approach is described in 
> the bug record.
>
> FEATURES OF THE FIX:
> 1. By default all native and Java parts of the fix do not function at 
> all - the fix is disabled. To enable the fix the application should be 
> run with "-Dawt.touchKeyboardAutoShowIsEnabled=true" option. Handling 
> of this new property is implemented in "sun.awt.SunToolkit" class.
>
> 2. Native parts of the fix functions only on MS Window 8 or later.
>
> 3. The fix implements automatic showing of the touch keyboard for the 
> following 2 use cases:
>     a.  The user touches the text components using the touch screen.
>     b.  The user does mouse clicks on the text components, while no 
> any keyboard is attached to the host.
>
> FIX LOGICAL STRUCTURE BY SOURCE CODE:
> 1. Core of the fix:
>     Native code:  awt_Toolkit.[h/cpp], awt_Component.[h/cpp], 
> awt_MouseEvent.[h/cpp], awt.h
>     Java:  SunToolkit.java, WToolkit.java, Component.java, 
> MouseEvent.java, AWTAccessor.java
>
> 2. Changes in all remaining Java files are connected with retaining of 
> the flag value "MouseEvent.causedByTouchEvent" during creation of the 
> new instances of "MouseEvent" class based on the original "MouseEvent" 
> instances.
>
> Work of the fix was verified both in the environment with the real 
> touch screen device and in the environment with the emulated touch 
> screen.
>
> Thank you,
> Anton