From Sergey.Bylokhov at oracle.com Thu May 2 00:09:02 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 1 May 2019 17:09:02 -0700 Subject: [13] Review Request: 8223045 GraphicsEnvironment does not detect resolution changes in multiscreen systems Message-ID: <869c8794-907b-828d-eccc-30db0ac2d6a6@oracle.com> Hello. Please review the fix for JDK 13. Bug: https://bugs.openjdk.java.net/browse/JDK-8223045 Fix: http://cr.openjdk.java.net/~serb/8223045/webrev.01 This fix deletes the array which initialized on startup and contained the screen resolution data. After the fix these data calculated on-demand. Note: It is possible that the list of screens(which we still cache, see JDK-8076313[1]) can be out of sync to the real number of screens on the system, for removed screens we will request the bounds of the main screen if it fails we will request the screen bounds using X11. [1] https://bugs.openjdk.java.net/browse/JDK-8076313 -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu May 2 01:09:00 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 1 May 2019 18:09:00 -0700 Subject: RFR: 8221082 Unexpected working behavior when using AIX's dtwm/mwm In-Reply-To: References: Message-ID: <3f6bb114-4f56-b840-ae06-9b7418143f39@oracle.com> Hi, Ichiroh. On 25/04/2019 04:08, Ichiroh Takiguchi wrote: > dtwm (CDE's window manager) and mwm (motif window manager) cannot handle non focusable window properly. > (Java cannot control input focus via WM_TAKE_FOCUS) > I found the fix against dtwm/mwm on AIX platform, but it did not work on Linux's mwm. Can you please clarify why it doesn't work on Linux? It would be better to minimize platforms specific code. I guess that the problem is that the non-focused window is looking like the focused, but in fact, it is still unfocused and none of its children can be focused as well? Otherwise, I think some of the tck tests could fail. If that's correct it is unclear if this problem is important and should we as a fix inject more platform-specific code to the XPeers. Since the CDE is unsupported by AWT for a more than 10 years I think the issues are not critical. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu May 2 12:01:54 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 2 May 2019 05:01:54 -0700 Subject: [13] Review Request: 8223237 Replace use of string.equals("") with isEmpty() in java.desktop Message-ID: <199db90a-9b16-60ed-c079-aec7c8655ee4@oracle.com> Hello. Please review the fix for JDK 13. Bug: https://bugs.openjdk.java.net/browse/JDK-8223237 Fix: http://cr.openjdk.java.net/~serb/8223237/webrev.00 This change is an equivalent of JDK-8214971[1] but for the java.desktop module. - The string.equals("") replaced by the string.isEmpty() in all cases - The "".equals(string) replaced by the string.isEmpty() when string is non-null [1] https://bugs.openjdk.java.net/browse/JDK-8214971 In one case I dropped string.equals("") as unneeded: http://cr.openjdk.java.net/~serb/8223237/webrev.00/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java.udiff.html -- Best regards, Sergey. From philip.race at oracle.com Fri May 3 18:08:50 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 3 May 2019 11:08:50 -0700 Subject: RFR: 8222819: Remove setting of headless property on MacOS from launcher code. Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8222819 Webrev: http://cr.openjdk.java.net/~prr/8222819/ After fixing https://bugs.openjdk.java.net/browse/JDK-8130266 the code in the launcher which sets the java.awt.headless property on MacOS is defunct since the java.desktop module figures it out for itself. I did manual verification that this is still true by ssh'ing into a Mac system So this is a clean up fix to remove the now unnecessary launcher code. -phil. From Roger.Riggs at oracle.com Fri May 3 18:21:20 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 3 May 2019 14:21:20 -0400 Subject: RFR: 8222819: Remove setting of headless property on MacOS from launcher code. In-Reply-To: References: Message-ID: Hi Phil, Looks good, thanks for the cleanup. Roger On 05/03/2019 02:08 PM, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8222819 > Webrev: http://cr.openjdk.java.net/~prr/8222819/ > > > After fixing https://bugs.openjdk.java.net/browse/JDK-8130266 the code > in the launcher which sets the java.awt.headless property on MacOS is > defunct > since the java.desktop module figures it out for itself. > I did manual verification that this is still true by ssh'ing into a > Mac system > > So this is a clean up fix to remove the now unnecessary launcher code. > > -phil. From Sergey.Bylokhov at oracle.com Sat May 4 00:05:25 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 3 May 2019 17:05:25 -0700 Subject: RFR: 8222819: Remove setting of headless property on MacOS from launcher code. In-Reply-To: References: Message-ID: +1 On 03/05/2019 11:21, Roger Riggs wrote: > Hi Phil, > > Looks good, thanks for the cleanup. > > Roger > > > On 05/03/2019 02:08 PM, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222819 >> Webrev: http://cr.openjdk.java.net/~prr/8222819/ >> >> >> After fixing https://bugs.openjdk.java.net/browse/JDK-8130266 the code >> in the launcher which sets the java.awt.headless property on MacOS is defunct >> since the java.desktop module figures it out for itself. >> I did manual verification that this is still true by ssh'ing into a Mac system >> >> So this is a clean up fix to remove the now unnecessary launcher code. >> >> -phil. > -- Best regards, Sergey. From philip.race at oracle.com Sat May 4 05:37:53 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 03 May 2019 22:37:53 -0700 Subject: [OpenJDK 2D-Dev] [13] Review Request: 8223237 Replace use of string.equals("") with isEmpty() in java.desktop In-Reply-To: <199db90a-9b16-60ed-c079-aec7c8655ee4@oracle.com> References: <199db90a-9b16-60ed-c079-aec7c8655ee4@oracle.com> Message-ID: <5CCD2531.3000707@oracle.com> I am not sure how important this clean up is but since you've done it .. replacing "".equals(foo) wth foo.isEmpty(() isn't equivalent but the cases I saw where you did are either foo == null || [!]foo.isEmpty() eg : - if (fontName == null || "".equals(fontName)) { + if (fontName == null || fontName.isEmpty()) { or foo != null && [!]foo.isEmpty() eg: - if(text != null && !text.equals("")) { + if(text != null && !text.isEmpty()) { so these should be fine. Although for the line above since you are touching it I'd like "if(" turned into "if (" Here's another one - if(!keyword.equals("")&& !value.equals("")) { + if(!keyword.isEmpty()&& !value.isEmpty()) { With those updates, +1 -phil On 5/2/19, 5:01 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223237 > Fix: http://cr.openjdk.java.net/~serb/8223237/webrev.00 > > This change is an equivalent of JDK-8214971[1] but for the > java.desktop module. > - The string.equals("") replaced by the string.isEmpty() in all cases > - The "".equals(string) replaced by the string.isEmpty() when string > is non-null > [1] https://bugs.openjdk.java.net/browse/JDK-8214971 > > > In one case I dropped string.equals("") as unneeded: > http://cr.openjdk.java.net/~serb/8223237/webrev.00/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java.udiff.html > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon May 6 22:11:02 2019 From: philip.race at oracle.com (Phil Race) Date: Mon, 6 May 2019 15:11:02 -0700 Subject: RFR: 8212700: Change the mechanism by which JDK loads the platform-specific AWT Toolkit Message-ID: <1c8f20b7-cba3-0978-d805-4465c1e80fb2@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8212700 CSR: https://bugs.openjdk.java.net/browse/JDK-8223417 Webrev: https://cr.openjdk.java.net/~prr/8212700 Please review this bug + CSR to remove the awt.headless system property. This should be the last of the fixes to remove use of system properties set in the launcher to specify per-platform internal classes and/or behaviours of the java.desktop module. Half of the change is removing code from the launcher, and then some small changes in Toolkit.java to consult a new method in the per-platform internal PlatformGraphicsInfo.java class. However it was also necessary to update each of the platform toolkit class constructor code since they all get/set a system property to support extra mouse buttons (I don't know why this could not be shared in SunToolkit but that is another matter than this fix), and two of them access the root thread group. Previously they inherited privileges from the code in java.awt.Toolkit which instantiated them but now they need to assert the privileges directly - at to the point of use. As well as adding a simple new regression test, all the automated headless tests and many automated headful tests were run as well as basic manual testing. The CSR also covers updating the javadoc of Toolkit.getDefaultToolkit() -phil From philip.race at oracle.com Tue May 7 04:01:08 2019 From: philip.race at oracle.com (Philip Race) Date: Mon, 06 May 2019 21:01:08 -0700 Subject: RFR: 8212700: Change the mechanism by which JDK loads the platform-specific AWT Toolkit In-Reply-To: <1c8f20b7-cba3-0978-d805-4465c1e80fb2@oracle.com> References: <1c8f20b7-cba3-0978-d805-4465c1e80fb2@oracle.com> Message-ID: <5CD10304.5020300@oracle.com> On 5/6/19, 3:11 PM, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8212700 > CSR: https://bugs.openjdk.java.net/browse/JDK-8223417 > Webrev: https://cr.openjdk.java.net/~prr/8212700 > > Please review this bug + CSR to remove the awt.headless system property. That would be awt.toolkit (sorry - copy + paste from a previous bug email). -phil > > This should be the last of the fixes to remove use of system > properties set in the launcher to specify per-platform > internal classes and/or behaviours of the java.desktop module. > > Half of the change is removing code from the launcher, and > then some small changes in Toolkit.java to consult a new > method in the per-platform internal PlatformGraphicsInfo.java class. > > However it was also necessary to update each of the platform toolkit > class > constructor code since they all get/set a system property to support > extra mouse buttons (I don't know why this could not be shared in > SunToolkit but that is another matter than this fix), and two of them > access the root thread group. Previously they inherited privileges > from the code in java.awt.Toolkit which instantiated them but now > they need to assert the privileges directly - at to the point of use. > > As well as adding a simple new regression test, all the automated > headless tests and many automated headful tests were run as well > as basic manual testing. > > The CSR also covers updating the javadoc of Toolkit.getDefaultToolkit() > > -phil From Roger.Riggs at oracle.com Tue May 7 14:44:03 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 7 May 2019 10:44:03 -0400 Subject: RFR: 8212700: Change the mechanism by which JDK loads the platform-specific AWT Toolkit In-Reply-To: <5CD10304.5020300@oracle.com> References: <1c8f20b7-cba3-0978-d805-4465c1e80fb2@oracle.com> <5CD10304.5020300@oracle.com> Message-ID: <8d22cdfb-00b2-0661-5f05-7304811c72e4@oracle.com> Hi Phil, The changes look fine. Thanks for the cleanup, Roger On 05/07/2019 12:01 AM, Philip Race wrote: > > > On 5/6/19, 3:11 PM, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212700 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8223417 >> Webrev: https://cr.openjdk.java.net/~prr/8212700 >> >> Please review this bug + CSR to remove the awt.headless system property. > > That would be awt.toolkit (sorry - copy + paste from a previous bug > email). > > -phil >> >> This should be the last of the fixes to remove use of system >> properties set in the launcher to specify per-platform >> internal classes and/or behaviours of the java.desktop module. >> >> Half of the change is removing code from the launcher, and >> then some small changes in Toolkit.java to consult a new >> method in the per-platform internal PlatformGraphicsInfo.java class. >> >> However it was also necessary to update each of the platform toolkit >> class >> constructor code since they all get/set a system property to support >> extra mouse buttons (I don't know why this could not be shared in >> SunToolkit but that is another matter than this fix), and two of them >> access the root thread group. Previously they inherited privileges >> from the code in java.awt.Toolkit which instantiated them but now >> they need to assert the privileges directly - at to the point of use. >> >> As well as adding a simple new regression test, all the automated >> headless tests and many automated headful tests were run as well >> as basic manual testing. >> >> The CSR also covers updating the javadoc of Toolkit.getDefaultToolkit() >> >> -phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From takiguc at linux.vnet.ibm.com Tue May 7 17:23:06 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 08 May 2019 02:23:06 +0900 Subject: RFR: 8211826: StringIndexOutOfBoundsException happens via GetStringUTFRegion() In-Reply-To: <0343e927-118c-8ad4-ed98-f8f277550d9b@oracle.com> References: <9ef1395b22bf1ec5106f532730f1bd42@linux.vnet.ibm.com> <3b84398c-8376-d3af-5ee5-138d07ba8fe9@oracle.com> <8b86a17d1681f3d64b025bf7fd2f2df3@linux.vnet.ibm.com> <0343e927-118c-8ad4-ed98-f8f277550d9b@oracle.com> Message-ID: <2b1ab77a124a866f1da497825f0b4975@linux.vnet.ibm.com> Hello Sergey. Sorry for bad response. Could you review the fix again ? Bug: https://bugs.openjdk.java.net/browse/JDK-8211826 Change: https://cr.openjdk.java.net/~itakiguchi/8211826/webrev.03/ I applied following changes * Modified testcaes for awt_UNIXToolkit.c (become simpler) * Clean up the buffer on swing_GTKEngine.c by memset() I wrote the testcase for swing_GTKEngine.c. (It's in JDK-8211826) It's not easy to detect buffer overflow... Ichiroh Takiguchi On 2019-04-03 06:55, Sergey Bylokhov wrote: > Hi, Ichiroh. > > On 28/03/2019 06:27, Ichiroh Takiguchi wrote: >> * On swing_GTKEngine.c, maximum length size for String data is >> arranged. >> ??? -static char conversionBuffer[CONV_BUFFER_SIZE]; >> ??? +static char conversionBuffer[(CONV_BUFFER_SIZE - 1) * 3 + 1]; > > As far as I understand that this will allocate the array for the worst > case, should we cleanup it before each usage? Otherwise we can mix > different strings. From Sergey.Bylokhov at oracle.com Wed May 8 02:47:24 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 7 May 2019 19:47:24 -0700 Subject: RFR: 8212700: Change the mechanism by which JDK loads the platform-specific AWT Toolkit In-Reply-To: <1c8f20b7-cba3-0978-d805-4465c1e80fb2@oracle.com> References: <1c8f20b7-cba3-0978-d805-4465c1e80fb2@oracle.com> Message-ID: <2dca6e1f-2eda-96bf-ce02-cc3205f6a393@oracle.com> Hi, Phil. Looks fine, but probably it will be worth to rename PlatformGraphicsInfo to PlatformInfo? On 06/05/2019 15:11, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8212700 > CSR: https://bugs.openjdk.java.net/browse/JDK-8223417 > Webrev: https://cr.openjdk.java.net/~prr/8212700 > > Please review this bug + CSR to remove the awt.headless system property. > > This should be the last of the fixes to remove use of system > properties set in the launcher to specify per-platform > internal classes and/or behaviours of the java.desktop module. > > Half of the change is removing code from the launcher, and > then some small changes in Toolkit.java to consult a new > method in the per-platform internal PlatformGraphicsInfo.java class. > > However it was also necessary to update each of the platform toolkit class > constructor code since they all get/set a system property to support > extra mouse buttons (I don't know why this could not be shared in > SunToolkit but that is another matter than this fix), and two of them > access the root thread group. Previously they inherited privileges > from the code in java.awt.Toolkit which instantiated them but now > they need to assert the privileges directly - at to the point of use. > > As well as adding a simple new regression test, all the automated > headless tests and many automated headful tests were run as well > as basic manual testing. > > The CSR also covers updating the javadoc of Toolkit.getDefaultToolkit() > > -phil -- Best regards, Sergey. From philip.race at oracle.com Wed May 8 03:29:52 2019 From: philip.race at oracle.com (Philip Race) Date: Tue, 07 May 2019 20:29:52 -0700 Subject: RFR: 8212700: Change the mechanism by which JDK loads the platform-specific AWT Toolkit In-Reply-To: <2dca6e1f-2eda-96bf-ce02-cc3205f6a393@oracle.com> References: <1c8f20b7-cba3-0978-d805-4465c1e80fb2@oracle.com> <2dca6e1f-2eda-96bf-ce02-cc3205f6a393@oracle.com> Message-ID: <5CD24D30.8040106@oracle.com> On 5/7/19, 7:47 PM, Sergey Bylokhov wrote: > Hi, Phil. > > Looks fine, but probably it will be worth to rename > PlatformGraphicsInfo to PlatformInfo? I don't want (or intend) to do that. I already knew I was going to re-use this class for this purpose when I created it and adjusted the classname then to be reasonably acceptable. There is no ideal and PlatformInfo isn't it either. -phil. > > On 06/05/2019 15:11, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212700 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8223417 >> Webrev: https://cr.openjdk.java.net/~prr/8212700 >> >> Please review this bug + CSR to remove the awt.headless system property. >> >> This should be the last of the fixes to remove use of system >> properties set in the launcher to specify per-platform >> internal classes and/or behaviours of the java.desktop module. >> >> Half of the change is removing code from the launcher, and >> then some small changes in Toolkit.java to consult a new >> method in the per-platform internal PlatformGraphicsInfo.java class. >> >> However it was also necessary to update each of the platform toolkit >> class >> constructor code since they all get/set a system property to support >> extra mouse buttons (I don't know why this could not be shared in >> SunToolkit but that is another matter than this fix), and two of them >> access the root thread group. Previously they inherited privileges >> from the code in java.awt.Toolkit which instantiated them but now >> they need to assert the privileges directly - at to the point of use. >> >> As well as adding a simple new regression test, all the automated >> headless tests and many automated headful tests were run as well >> as basic manual testing. >> >> The CSR also covers updating the javadoc of Toolkit.getDefaultToolkit() >> >> -phil > > From Sergey.Bylokhov at oracle.com Wed May 8 06:38:02 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 7 May 2019 23:38:02 -0700 Subject: RFR: 8212700: Change the mechanism by which JDK loads the platform-specific AWT Toolkit In-Reply-To: <5CD24D30.8040106@oracle.com> References: <1c8f20b7-cba3-0978-d805-4465c1e80fb2@oracle.com> <2dca6e1f-2eda-96bf-ce02-cc3205f6a393@oracle.com> <5CD24D30.8040106@oracle.com> Message-ID: <8ca7dc39-1cce-0da8-8e75-57e73f9e2418@oracle.com> OK, looks fine then. > On 5/7/19, 7:47 PM, Sergey Bylokhov wrote: >> Hi, Phil. >> >> Looks fine, but probably it will be worth to rename PlatformGraphicsInfo to PlatformInfo? > > I don't want (or intend) to do that. I already knew I was going > to re-use this class for this purpose when I created it and adjusted > the classname then to be reasonably acceptable. There is no ideal > and PlatformInfo isn't it either. > > -phil. > >> >> On 06/05/2019 15:11, Phil Race wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212700 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223417 >>> Webrev: https://cr.openjdk.java.net/~prr/8212700 >>> >>> Please review this bug + CSR to remove the awt.headless system property. >>> >>> This should be the last of the fixes to remove use of system >>> properties set in the launcher to specify per-platform >>> internal classes and/or behaviours of the java.desktop module. >>> >>> Half of the change is removing code from the launcher, and >>> then some small changes in Toolkit.java to consult a new >>> method in the per-platform internal PlatformGraphicsInfo.java class. >>> >>> However it was also necessary to update each of the platform toolkit class >>> constructor code since they all get/set a system property to support >>> extra mouse buttons (I don't know why this could not be shared in >>> SunToolkit but that is another matter than this fix), and two of them >>> access the root thread group. Previously they inherited privileges >>> from the code in java.awt.Toolkit which instantiated them but now >>> they need to assert the privileges directly - at to the point of use. >>> >>> As well as adding a simple new regression test, all the automated >>> headless tests and many automated headful tests were run as well >>> as basic manual testing. >>> >>> The CSR also covers updating the javadoc of Toolkit.getDefaultToolkit() >>> >>> -phil >> >> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed May 8 06:54:41 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 7 May 2019 23:54:41 -0700 Subject: [13] Review Request: 7141393 [macosx] CARemoteLayer code refactoring and unit test Message-ID: Hello. Please review the fix for JDK 13. Bug: https://bugs.openjdk.java.net/browse/JDK-7141393 Fix: http://cr.openjdk.java.net/~serb/7141393/webrev.00 AWT on macOS contains some code that is not compiled by default (protected with #ifdef REMOTELAYER) and included to the workspace for testing purposes only. It allows developers to test CALayer support in AWT/Java2D without need to build or download Java Plugin. The description of this bug suggests to move this code to the separate test suite, but I think we can drop it because cross process rendering is not used anymore. -- Best regards, Sergey. From dmitry.markov at oracle.com Wed May 8 11:05:30 2019 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Wed, 8 May 2019 12:05:30 +0100 Subject: [13] Review Request: 7141393 [macosx] CARemoteLayer code refactoring and unit test In-Reply-To: References: Message-ID: <130DCEB9-C709-4E8F-95E6-F975277DC6CA@oracle.com> Hi Sergey, The changes look good to me. Thanks, Dmitry > On 8 May 2019, at 07:54, Sergey Bylokhov wrote: > > Hello. > Please review the fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7141393 > Fix: http://cr.openjdk.java.net/~serb/7141393/webrev.00 > > AWT on macOS contains some code that is not compiled by default (protected with #ifdef REMOTELAYER) and included to the workspace for testing purposes only. It allows developers to test CALayer support in AWT/Java2D without need to build or download Java Plugin. > > The description of this bug suggests to move this code to the separate test suite, but I think we can drop it because cross process rendering is not used anymore. > > -- > Best regards, Sergey. From jayathirth.d.v at oracle.com Wed May 8 11:51:52 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Wed, 8 May 2019 17:21:52 +0530 Subject: [13] Review Request: 7141393 [macosx] CARemoteLayer code refactoring and unit test In-Reply-To: References: Message-ID: Hi Sergey, Changes are fine. Thanks, Jay > On 08-May-2019, at 12:24 PM, Sergey Bylokhov wrote: > > Hello. > Please review the fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7141393 > Fix: http://cr.openjdk.java.net/~serb/7141393/webrev.00 > > AWT on macOS contains some code that is not compiled by default (protected with #ifdef REMOTELAYER) and included to the workspace for testing purposes only. It allows developers to test CALayer support in AWT/Java2D without need to build or download Java Plugin. > > The description of this bug suggests to move this code to the separate test suite, but I think we can drop it because cross process rendering is not used anymore. > > -- > Best regards, Sergey. From dmitry.markov at oracle.com Wed May 8 15:12:01 2019 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Wed, 8 May 2019 16:12:01 +0100 Subject: [13] Review Request: 8144125 [macOS] java/awt/event/ComponentEvent/MovedResizedTwiceTest/MovedResizedTwiceTest.java failed automatically In-Reply-To: References: Message-ID: <94960D1B-076D-48E8-98DE-ED98FD766FF5@oracle.com> Hi Sergey, The fix looks fine. Shall we add ?headful? key to the test? Thanks, Dmitry > On 29 Apr 2019, at 11:27, Sergey Bylokhov wrote: > > Hello. > Please review the fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8144125 > Fix: http://cr.openjdk.java.net/~serb/8144125/webrev.00 > > One of the tests fails on macOS because we send two events for the component is resized/moved. > When the LWComponentPeer was implemented I was not aware that the Component class can send such events: > http://hg.openjdk.java.net/jdk/client/file/6b1bac001aaf/src/java.desktop/share/classes/java/awt/Component.java#l2387 > > Currently, LWComponentPeer sends these events even if the target Component should not be updated. As a fix I suggest to post these events by the peer only if the target should be updated as well, which will mean that we got this change from some other code, not the component(and the component will not fire these events). > > -- > Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed May 8 22:14:41 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 8 May 2019 15:14:41 -0700 Subject: [13] Review Request: 8144125 [macOS] java/awt/event/ComponentEvent/MovedResizedTwiceTest/MovedResizedTwiceTest.java failed automatically In-Reply-To: <94960D1B-076D-48E8-98DE-ED98FD766FF5@oracle.com> References: <94960D1B-076D-48E8-98DE-ED98FD766FF5@oracle.com> Message-ID: <8d3f7391-7651-08af-07c2-0f3371a28a78@oracle.com> On 08/05/2019 08:12, Dmitry Markov wrote: > Hi Sergey, > > The fix looks fine. Shall we add ?headful? key to the test? Right! I'll add it before the push. > > Thanks, > Dmitry > >> On 29 Apr 2019, at 11:27, Sergey Bylokhov wrote: >> >> Hello. >> Please review the fix for JDK 13. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8144125 >> Fix: http://cr.openjdk.java.net/~serb/8144125/webrev.00 >> >> One of the tests fails on macOS because we send two events for the component is resized/moved. >> When the LWComponentPeer was implemented I was not aware that the Component class can send such events: >> http://hg.openjdk.java.net/jdk/client/file/6b1bac001aaf/src/java.desktop/share/classes/java/awt/Component.java#l2387 >> >> Currently, LWComponentPeer sends these events even if the target Component should not be updated. As a fix I suggest to post these events by the peer only if the target should be updated as well, which will mean that we got this change from some other code, not the component(and the component will not fire these events). >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu May 9 00:41:51 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 8 May 2019 17:41:51 -0700 Subject: RFR: 8211826: StringIndexOutOfBoundsException happens via GetStringUTFRegion() In-Reply-To: <2b1ab77a124a866f1da497825f0b4975@linux.vnet.ibm.com> References: <9ef1395b22bf1ec5106f532730f1bd42@linux.vnet.ibm.com> <3b84398c-8376-d3af-5ee5-138d07ba8fe9@oracle.com> <8b86a17d1681f3d64b025bf7fd2f2df3@linux.vnet.ibm.com> <0343e927-118c-8ad4-ed98-f8f277550d9b@oracle.com> <2b1ab77a124a866f1da497825f0b4975@linux.vnet.ibm.com> Message-ID: <379da3fe-4eab-5cbf-25a3-84d3dcb09713@oracle.com> Hi, Ichiroh. This version looks fine, thank you contribution. On 07/05/2019 10:23, Ichiroh Takiguchi wrote: > Hello Sergey. > > Sorry for bad response. > > Could you review the fix again ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8211826 > Change: https://cr.openjdk.java.net/~itakiguchi/8211826/webrev.03/ > > I applied following changes > * Modified testcaes for awt_UNIXToolkit.c (become simpler) > * Clean up the buffer on swing_GTKEngine.c by memset() > > I wrote the testcase for swing_GTKEngine.c. > (It's in JDK-8211826) > It's not easy to detect buffer overflow... > > Ichiroh Takiguchi > > On 2019-04-03 06:55, Sergey Bylokhov wrote: >> Hi, Ichiroh. >> >> On 28/03/2019 06:27, Ichiroh Takiguchi wrote: >>> * On swing_GTKEngine.c, maximum length size for String data is arranged. >>> ???? -static char conversionBuffer[CONV_BUFFER_SIZE]; >>> ???? +static char conversionBuffer[(CONV_BUFFER_SIZE - 1) * 3 + 1]; >> >> As far as I understand that this will allocate the array for the worst >> case, should we cleanup it before each usage? Otherwise we can mix >> different strings. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon May 13 11:10:08 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 13 May 2019 04:10:08 -0700 Subject: [13] Review Request: 8223766 Remains of ancient code in AWT initialization Message-ID: <79eaff7e-83a7-08a0-1e42-82e0cca3d339@oracle.com> Hello. Please review code cleanup for JDK 13. Bug: https://bugs.openjdk.java.net/browse/JDK-8223766 Fix: http://cr.openjdk.java.net/~serb/8223766/webrev.00 We have a few places in which the "initIDs()" methods initialize native data which are never used. This code remains from the MToolkit and some old part of AWT on Windows. In the fix, this code was removed. Note that some of the initIds() methods became empty, in some future fix I'll try to delete them as well. -- Best regards, Sergey. From jayathirth.d.v at oracle.com Mon May 13 13:15:15 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Mon, 13 May 2019 18:45:15 +0530 Subject: [13] Review Request: 8223766 Remains of ancient code in AWT initialization In-Reply-To: <79eaff7e-83a7-08a0-1e42-82e0cca3d339@oracle.com> References: <79eaff7e-83a7-08a0-1e42-82e0cca3d339@oracle.com> Message-ID: <68665445-0BC5-4719-AEA9-A4A7FD1E1E86@oracle.com> Hi Sergey, I see that you have removed content of JNI functions related ti initID's. Do we need the structure of these JNI functions, if yes can we add some kind of trace log to say there is no implementation. Thanks, Jay > On 13-May-2019, at 4:40 PM, Sergey Bylokhov wrote: > > Hello. > Please review code cleanup for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223766 > Fix: http://cr.openjdk.java.net/~serb/8223766/webrev.00 > > We have a few places in which the "initIDs()" methods initialize native data which are never used. > This code remains from the MToolkit and some old part of AWT on Windows. In the fix, this code was removed. > > Note that some of the initIds() methods became empty, in some future fix I'll try to delete them as well. > > -- > Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon May 13 20:46:02 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 13 May 2019 13:46:02 -0700 Subject: [13] Review Request: 8223766 Remains of ancient code in AWT initialization In-Reply-To: <68665445-0BC5-4719-AEA9-A4A7FD1E1E86@oracle.com> References: <79eaff7e-83a7-08a0-1e42-82e0cca3d339@oracle.com> <68665445-0BC5-4719-AEA9-A4A7FD1E1E86@oracle.com> Message-ID: Hi, Jay. I deleted unused code inside the "initIds()", but "initIds()" methods itself(even empty) are still called from the java shared code. On 13/05/2019 06:15, Jayathirth Rao wrote: > Hi Sergey, > > I see that you have removed content of JNI functions related ti initID's. > Do we need the structure of these JNI functions, if yes can we add some kind of trace log to say there is no implementation. > > Thanks, > Jay > >> On 13-May-2019, at 4:40 PM, Sergey Bylokhov wrote: >> >> Hello. >> Please review code cleanup for JDK 13. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223766 >> Fix: http://cr.openjdk.java.net/~serb/8223766/webrev.00 >> >> We have a few places in which the "initIDs()" methods initialize native data which are never used. >> This code remains from the MToolkit and some old part of AWT on Windows. In the fix, this code was removed. >> >> Note that some of the initIds() methods became empty, in some future fix I'll try to delete them as well. >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From andrewluotechnologies at outlook.com Tue May 14 00:39:55 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Tue, 14 May 2019 00:39:55 +0000 Subject: [PATCH] Fix some C++ conformance issues in AWT Windows code Message-ID: I've been trying to get the JDK to compile with the new /permissive- switch in VS2017 (https://devblogs.microsoft.com/cppblog/permissive-switch/) however there have been a few issues in various parts of the code. While testing this, I found some issues in the AWT code. In one case we name a function with the class:: prefix when the function is declared inline in the class definition. Other cases include where we are assigning string literals to non-const char* variables. I took some time to fix these and attached a patch. Let me know if there are any comments. c:\Users\Andrew\Documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt.h(343): error C2440: 'return': cannot convert from 'const unsigned short *' to 'LPWSTR' c:\Users\Andrew\Documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt.h(343): note: Conversion from string literal loses const qualifier (see /Zc:strictStrings) c:\users\andrew\documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt_Component.h(455): error C2061: syntax error: identifier 'javaKey' c:\users\andrew\documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt_Component.h(455): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int Thanks, -Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jdkcomformanceawt.txt URL: From jayathirth.d.v at oracle.com Tue May 14 11:36:30 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Tue, 14 May 2019 17:06:30 +0530 Subject: [13] Review Request: 8223766 Remains of ancient code in AWT initialization In-Reply-To: References: <79eaff7e-83a7-08a0-1e42-82e0cca3d339@oracle.com> <68665445-0BC5-4719-AEA9-A4A7FD1E1E86@oracle.com> Message-ID: Thanks for clarification changes are fine. Regards, Jay > On 14-May-2019, at 2:16 AM, Sergey Bylokhov wrote: > > Hi, Jay. > I deleted unused code inside the "initIds()", but "initIds()" methods itself(even empty) are still called from the java shared code. > > On 13/05/2019 06:15, Jayathirth Rao wrote: >> Hi Sergey, >> I see that you have removed content of JNI functions related ti initID's. >> Do we need the structure of these JNI functions, if yes can we add some kind of trace log to say there is no implementation. >> Thanks, >> Jay >>> On 13-May-2019, at 4:40 PM, Sergey Bylokhov wrote: >>> >>> Hello. >>> Please review code cleanup for JDK 13. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223766 >>> Fix: http://cr.openjdk.java.net/~serb/8223766/webrev.00 >>> >>> We have a few places in which the "initIDs()" methods initialize native data which are never used. >>> This code remains from the MToolkit and some old part of AWT on Windows. In the fix, this code was removed. >>> >>> Note that some of the initIds() methods became empty, in some future fix I'll try to delete them as well. >>> >>> -- >>> Best regards, Sergey. > > > -- > Best regards, Sergey. From prasanta.sadhukhan at oracle.com Wed May 15 07:16:07 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 15 May 2019 12:46:07 +0530 Subject: [13] JDK-8223937: PIT: java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java listed twice in ProblemList Message-ID: Hi All, java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java listed twice in ProblemList (missed in last cleanup attempt 8222830) which is causing one of them to be ignored (for linux,mac) resulting in failure in those 2 platforms. Bug: https://bugs.openjdk.java.net/browse/JDK-8223937 diff -r b267b838272f test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt? Tue May 14 11:23:08 2019 +0530 +++ b/test/jdk/ProblemList.txt? Wed May 15 12:42:32 2019 +0530 @@ -234,14 +234,13 @@ ?java/awt/Window/ShapedAndTranslucentWindows/SetShapeAndClick.java 8197936 macosx-all ?java/awt/Window/ShapedAndTranslucentWindows/SetShapeDynamicallyAndClick.java 8013450 macosx-all ?java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucentWindowClick.java 8013450 macosx-all *-java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 8165218 macosx-all,linux-all* ?java/awt/Window/ShapedAndTranslucentWindows/TranslucentChoice.java 8221901 linux-all ?java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java 8222323 windows-all ?java/awt/Window/ShapedAndTranslucentWindows/FocusAWTTest.java 8222328 windows-all,linux-all,macosx-all ?java/awt/Window/ShapedAndTranslucentWindows/Shaped.java? 8222328 windows-all,linux-all,macosx-all ?java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java 8222328 windows-all,linux-all,macosx-all ?java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java 8222328 windows-all,linux-all,macosx-all *-java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 8222328 windows-all** **+java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 8222328 windows-all,macosx-all,linux-all* ?java/awt/Window/ShapedAndTranslucentWindows/Translucent.java 8222328 windows-all,linux-all,macosx-all ?java/awt/Window/AlwaysOnTop/AutoTestOnTop.java 6847593 macosx-all,windows-all,linux-all ?java/awt/Window/GrabSequence/GrabSequence.java 6848409 macosx-all,linux-all Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.b.bansal at oracle.com Wed May 15 07:23:50 2019 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Wed, 15 May 2019 07:23:50 +0000 (UTC) Subject: [13] JDK-8223937: PIT: java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java listed twice in ProblemList In-Reply-To: References: Message-ID: Looks good to me ? -Pankaj ? From: Prasanta Sadhukhan Sent: Wednesday, May 15, 2019 12:46 PM To: awt-dev at openjdk.java.net Subject: [13] JDK-8223937: PIT: java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java listed twice in ProblemList ? Hi All, java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java listed twice in ProblemList (missed in last cleanup attempt 8222830) which is causing one of them to be ignored (for linux,mac) resulting in failure in those 2 platforms. Bug: https://bugs.openjdk.java.net/browse/JDK-8223937 diff -r b267b838272f test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt? Tue May 14 11:23:08 2019 +0530 +++ b/test/jdk/ProblemList.txt? Wed May 15 12:42:32 2019 +0530 @@ -234,14 +234,13 @@ ?java/awt/Window/ShapedAndTranslucentWindows/SetShapeAndClick.java 8197936 macosx-all ?java/awt/Window/ShapedAndTranslucentWindows/SetShapeDynamicallyAndClick.java 8013450 macosx-all ?java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucentWindowClick.java 8013450 macosx-all -java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 8165218 macosx-all,linux-all ?java/awt/Window/ShapedAndTranslucentWindows/TranslucentChoice.java 8221901 linux-all ?java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java 8222323 windows-all ?java/awt/Window/ShapedAndTranslucentWindows/FocusAWTTest.java 8222328 windows-all,linux-all,macosx-all ?java/awt/Window/ShapedAndTranslucentWindows/Shaped.java? 8222328 windows-all,linux-all,macosx-all ?java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java 8222328 windows-all,linux-all,macosx-all ?java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java 8222328 windows-all,linux-all,macosx-all -java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 8222328 windows-all +java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 8222328 windows-all,macosx-all,linux-all ?java/awt/Window/ShapedAndTranslucentWindows/Translucent.java 8222328 windows-all,linux-all,macosx-all ?java/awt/Window/AlwaysOnTop/AutoTestOnTop.java 6847593 macosx-all,windows-all,linux-all ?java/awt/Window/GrabSequence/GrabSequence.java 6848409 macosx-all,linux-all Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed May 15 08:14:20 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Wed, 15 May 2019 13:44:20 +0530 Subject: [13] JDK-8223937: PIT: java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java listed twice in ProblemList In-Reply-To: References: Message-ID: <0C0B6FA8-2E05-431B-9700-9ACD5EAF9DDD@oracle.com> Changes are fine. Thanks, Jay > On 15-May-2019, at 12:46 PM, Prasanta Sadhukhan wrote: > > Hi All, > > java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java listed twice in ProblemList (missed in last cleanup attempt 8222830) > which is causing one of them to be ignored (for linux,mac) resulting in failure in those 2 platforms. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223937 > diff -r b267b838272f test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt Tue May 14 11:23:08 2019 +0530 > +++ b/test/jdk/ProblemList.txt Wed May 15 12:42:32 2019 +0530 > @@ -234,14 +234,13 @@ > java/awt/Window/ShapedAndTranslucentWindows/SetShapeAndClick.java 8197936 macosx-all > java/awt/Window/ShapedAndTranslucentWindows/SetShapeDynamicallyAndClick.java 8013450 macosx-all > java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucentWindowClick.java 8013450 macosx-all > -java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 8165218 macosx-all,linux-all > java/awt/Window/ShapedAndTranslucentWindows/TranslucentChoice.java 8221901 linux-all > java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java 8222323 windows-all > java/awt/Window/ShapedAndTranslucentWindows/FocusAWTTest.java 8222328 windows-all,linux-all,macosx-all > java/awt/Window/ShapedAndTranslucentWindows/Shaped.java 8222328 windows-all,linux-all,macosx-all > java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java 8222328 windows-all,linux-all,macosx-all > java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java 8222328 windows-all,linux-all,macosx-all > -java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 8222328 windows-all > +java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 8222328 windows-all,macosx-all,linux-all > java/awt/Window/ShapedAndTranslucentWindows/Translucent.java 8222328 windows-all,linux-all,macosx-all > java/awt/Window/AlwaysOnTop/AutoTestOnTop.java 6847593 macosx-all,windows-all,linux-all > java/awt/Window/GrabSequence/GrabSequence.java 6848409 macosx-all,linux-all > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed May 15 16:21:47 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 15 May 2019 09:21:47 -0700 Subject: [13] JDK-8223937: PIT: java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java listed twice in ProblemList In-Reply-To: References: Message-ID: <4e213cc1-738f-9a2f-28c8-2a47c79a4993@oracle.com> Do not push this fix. You need to include both bug ids on the line : java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 8165218,8222328 windows-all,macosx-all,linux-all -phil. On 5/15/19 12:16 AM, Prasanta Sadhukhan wrote: > > Hi All, > > java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java > listed twice in ProblemList (missed in last cleanup attempt 8222830) > > which is causing one of them to be ignored (for linux,mac) resulting > in failure in those 2 platforms. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223937 > > diff -r b267b838272f test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt? Tue May 14 11:23:08 2019 +0530 > +++ b/test/jdk/ProblemList.txt? Wed May 15 12:42:32 2019 +0530 > @@ -234,14 +234,13 @@ > ?java/awt/Window/ShapedAndTranslucentWindows/SetShapeAndClick.java > 8197936 macosx-all > ?java/awt/Window/ShapedAndTranslucentWindows/SetShapeDynamicallyAndClick.java > 8013450 macosx-all > ?java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucentWindowClick.java > 8013450 macosx-all > *-java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java > 8165218 macosx-all,linux-all* > ?java/awt/Window/ShapedAndTranslucentWindows/TranslucentChoice.java > 8221901 linux-all > ?java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java 8222323 > windows-all > ?java/awt/Window/ShapedAndTranslucentWindows/FocusAWTTest.java 8222328 > windows-all,linux-all,macosx-all > ?java/awt/Window/ShapedAndTranslucentWindows/Shaped.java 8222328 > windows-all,linux-all,macosx-all > ?java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java 8222328 > windows-all,linux-all,macosx-all > ?java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java > 8222328 windows-all,linux-all,macosx-all > *-java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java > 8222328 windows-all** > **+java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java > 8222328 windows-all,macosx-all,linux-all* > ?java/awt/Window/ShapedAndTranslucentWindows/Translucent.java 8222328 > windows-all,linux-all,macosx-all > ?java/awt/Window/AlwaysOnTop/AutoTestOnTop.java 6847593 > macosx-all,windows-all,linux-all > ?java/awt/Window/GrabSequence/GrabSequence.java 6848409 > macosx-all,linux-all > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu May 16 05:20:23 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 16 May 2019 10:50:23 +0530 Subject: [13] JDK-8223937: PIT: java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java listed twice in ProblemList In-Reply-To: <4e213cc1-738f-9a2f-28c8-2a47c79a4993@oracle.com> References: <4e213cc1-738f-9a2f-28c8-2a47c79a4993@oracle.com> Message-ID: <49992ef9-f1a2-4530-175a-278aa68c01c3@oracle.com> I am sorry but this fix is already pushed yesterday. Do you want to me create one more bug to cater to what you are asking? Regards Prasanta On 15-May-19 9:51 PM, Phil Race wrote: > Do not push this fix. You need to include both bug ids on the line : > > java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java > 8165218,8222328 windows-all,macosx-all,linux-all > > -phil. > > On 5/15/19 12:16 AM, Prasanta Sadhukhan wrote: >> >> Hi All, >> >> java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java >> listed twice in ProblemList (missed in last cleanup attempt 8222830) >> >> which is causing one of them to be ignored (for linux,mac) resulting >> in failure in those 2 platforms. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223937 >> >> diff -r b267b838272f test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt? Tue May 14 11:23:08 2019 +0530 >> +++ b/test/jdk/ProblemList.txt? Wed May 15 12:42:32 2019 +0530 >> @@ -234,14 +234,13 @@ >> ?java/awt/Window/ShapedAndTranslucentWindows/SetShapeAndClick.java >> 8197936 macosx-all >> ?java/awt/Window/ShapedAndTranslucentWindows/SetShapeDynamicallyAndClick.java >> 8013450 macosx-all >> ?java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucentWindowClick.java >> 8013450 macosx-all >> *-java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java >> 8165218 macosx-all,linux-all* >> ?java/awt/Window/ShapedAndTranslucentWindows/TranslucentChoice.java >> 8221901 linux-all >> ?java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java 8222323 >> windows-all >> ?java/awt/Window/ShapedAndTranslucentWindows/FocusAWTTest.java >> 8222328 windows-all,linux-all,macosx-all >> ?java/awt/Window/ShapedAndTranslucentWindows/Shaped.java 8222328 >> windows-all,linux-all,macosx-all >> ?java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java 8222328 >> windows-all,linux-all,macosx-all >> ?java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java >> 8222328 windows-all,linux-all,macosx-all >> *-java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java >> 8222328 windows-all** >> **+java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java >> 8222328 windows-all,macosx-all,linux-all* >> ?java/awt/Window/ShapedAndTranslucentWindows/Translucent.java 8222328 >> windows-all,linux-all,macosx-all >> ?java/awt/Window/AlwaysOnTop/AutoTestOnTop.java 6847593 >> macosx-all,windows-all,linux-all >> ?java/awt/Window/GrabSequence/GrabSequence.java 6848409 >> macosx-all,linux-all >> >> Regards >> Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri May 17 05:12:57 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 16 May 2019 22:12:57 -0700 Subject: [13] JDK-8223937: PIT: java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java listed twice in ProblemList In-Reply-To: <49992ef9-f1a2-4530-175a-278aa68c01c3@oracle.com> References: <4e213cc1-738f-9a2f-28c8-2a47c79a4993@oracle.com> <49992ef9-f1a2-4530-175a-278aa68c01c3@oracle.com> Message-ID: <5CDE42D9.6080005@oracle.com> I think yes. -phil. On 5/15/19, 10:20 PM, Prasanta Sadhukhan wrote: > > I am sorry but this fix is already pushed yesterday. Do you want to me > create one more bug to cater to what you are asking? > > Regards > Prasanta > On 15-May-19 9:51 PM, Phil Race wrote: >> Do not push this fix. You need to include both bug ids on the line : >> >> java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java >> 8165218,8222328 windows-all,macosx-all,linux-all >> >> -phil. >> >> On 5/15/19 12:16 AM, Prasanta Sadhukhan wrote: >>> >>> Hi All, >>> >>> java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java >>> listed twice in ProblemList (missed in last cleanup attempt 8222830) >>> >>> which is causing one of them to be ignored (for linux,mac) resulting >>> in failure in those 2 platforms. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223937 >>> >>> diff -r b267b838272f test/jdk/ProblemList.txt >>> --- a/test/jdk/ProblemList.txt Tue May 14 11:23:08 2019 +0530 >>> +++ b/test/jdk/ProblemList.txt Wed May 15 12:42:32 2019 +0530 >>> @@ -234,14 +234,13 @@ >>> java/awt/Window/ShapedAndTranslucentWindows/SetShapeAndClick.java >>> 8197936 macosx-all >>> java/awt/Window/ShapedAndTranslucentWindows/SetShapeDynamicallyAndClick.java >>> 8013450 macosx-all >>> java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucentWindowClick.java >>> 8013450 macosx-all >>> *-java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java >>> 8165218 macosx-all,linux-all* >>> java/awt/Window/ShapedAndTranslucentWindows/TranslucentChoice.java >>> 8221901 linux-all >>> java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java 8222323 >>> windows-all >>> java/awt/Window/ShapedAndTranslucentWindows/FocusAWTTest.java >>> 8222328 windows-all,linux-all,macosx-all >>> java/awt/Window/ShapedAndTranslucentWindows/Shaped.java 8222328 >>> windows-all,linux-all,macosx-all >>> java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java >>> 8222328 windows-all,linux-all,macosx-all >>> java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java >>> 8222328 windows-all,linux-all,macosx-all >>> *-java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java >>> 8222328 windows-all** >>> **+java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java >>> 8222328 windows-all,macosx-all,linux-all* >>> java/awt/Window/ShapedAndTranslucentWindows/Translucent.java >>> 8222328 windows-all,linux-all,macosx-all >>> java/awt/Window/AlwaysOnTop/AutoTestOnTop.java 6847593 >>> macosx-all,windows-all,linux-all >>> java/awt/Window/GrabSequence/GrabSequence.java 6848409 >>> macosx-all,linux-all >>> >>> Regards >>> Prasanta >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri May 17 05:23:33 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 17 May 2019 10:53:33 +0530 Subject: [13] RFR 8224096: Add relevant bugid to java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java in ProblemList Message-ID: <69baab42-3301-3cf9-9fd7-ec0fc73e39a0@oracle.com> Hi All, We need to add all relevant bugid to the problematic test in ProblemList Bug: https://bugs.openjdk.java.net/browse/JDK-8224096 diff -r cb2628a4f33f test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt? Wed May 15 15:17:24 2019 +0530 +++ b/test/jdk/ProblemList.txt? Fri May 17 10:52:50 2019 +0530 @@ -240,7 +240,7 @@ ?java/awt/Window/ShapedAndTranslucentWindows/Shaped.java? 8222328 windows-all,linux-all,macosx-all ?java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java 8222328 windows-all,linux-all,macosx-all ?java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java 8222328 windows-all,linux-all,macosx-all *-java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 8222328 windows-all,macosx-all,linux-all** **+java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 8165218,8222328 windows-all,macosx-all,linux-all* ?java/awt/Window/ShapedAndTranslucentWindows/Translucent.java 8222328 windows-all,linux-all,macosx-all ?java/awt/Window/AlwaysOnTop/AutoTestOnTop.java 6847593 macosx-all,windows-all,linux-all ?java/awt/Window/GrabSequence/GrabSequence.java 6848409 macosx-all,linux-all Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Fri May 17 06:23:28 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Fri, 17 May 2019 11:53:28 +0530 Subject: [13] RFR 8224096: Add relevant bugid to java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java in ProblemList In-Reply-To: <69baab42-3301-3cf9-9fd7-ec0fc73e39a0@oracle.com> References: <69baab42-3301-3cf9-9fd7-ec0fc73e39a0@oracle.com> Message-ID: <130BFD2B-D037-4F89-BC60-EF35D0D9098D@oracle.com> Changes are fine. Thanks, Jay > On 17-May-2019, at 10:53 AM, Prasanta Sadhukhan wrote: > > Hi All, > > We need to add all relevant bugid to the problematic test in ProblemList > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224096 > diff -r cb2628a4f33f test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt Wed May 15 15:17:24 2019 +0530 > +++ b/test/jdk/ProblemList.txt Fri May 17 10:52:50 2019 +0530 > @@ -240,7 +240,7 @@ > java/awt/Window/ShapedAndTranslucentWindows/Shaped.java 8222328 windows-all,linux-all,macosx-all > java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java 8222328 windows-all,linux-all,macosx-all > java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java 8222328 windows-all,linux-all,macosx-all > -java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 8222328 windows-all,macosx-all,linux-all > +java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 8165218,8222328 windows-all,macosx-all,linux-all > java/awt/Window/ShapedAndTranslucentWindows/Translucent.java 8222328 windows-all,linux-all,macosx-all > java/awt/Window/AlwaysOnTop/AutoTestOnTop.java 6847593 macosx-all,windows-all,linux-all > java/awt/Window/GrabSequence/GrabSequence.java 6848409 macosx-all,linux-all > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Sat May 18 02:25:50 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 17 May 2019 19:25:50 -0700 Subject: [13] Review Request: 8224152 [macOS] ProblemList tests that leave rubbish on the screen Message-ID: Hello. Please review the fix for JDK 13. Bug: https://bugs.openjdk.java.net/browse/JDK-8224152 Fix: http://cr.openjdk.java.net/~serb/8224152/webrev.00 Bug description: One of the bugs in the Robot implementation can be exposed by 2 different tests. If both runs in a row, they leave some key modifiers pressed which caused another test to press some shortcuts instead of a simple key. One of these shortcuts hide the test window, and as a result, all other shortcuts will send to the terminal window -> tons of utility windows will be opened. Note that these tests are fine, actually, they are a pass but cause some other tests to fail. While I am working on the bug in Robot, I would like to add these tests to the problem list. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat May 18 02:29:38 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 17 May 2019 19:29:38 -0700 Subject: [13] RFR 8224096: Add relevant bugid to java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java in ProblemList In-Reply-To: <130BFD2B-D037-4F89-BC60-EF35D0D9098D@oracle.com> References: <69baab42-3301-3cf9-9fd7-ec0fc73e39a0@oracle.com> <130BFD2B-D037-4F89-BC60-EF35D0D9098D@oracle.com> Message-ID: <89cff725-66d1-341f-be05-d7abab05a388@oracle.com> +1 On 16/05/2019 23:23, Jayathirth Rao wrote: > Changes are fine. > > Thanks, > Jay > >> On 17-May-2019, at 10:53 AM, Prasanta Sadhukhan > wrote: >> >> Hi All, >> >> We need to add all relevant bugid to the problematic test in ProblemList >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224096 >> >> diff -r cb2628a4f33f test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt? Wed May 15 15:17:24 2019 +0530 >> +++ b/test/jdk/ProblemList.txt? Fri May 17 10:52:50 2019 +0530 >> @@ -240,7 +240,7 @@ >> ?java/awt/Window/ShapedAndTranslucentWindows/Shaped.java? 8222328 windows-all,linux-all,macosx-all >> ?java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java 8222328 windows-all,linux-all,macosx-all >> ?java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java 8222328 windows-all,linux-all,macosx-all >> *-java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 8222328 windows-all,macosx-all,linux-all** >> **+java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 8165218,8222328 windows-all,macosx-all,linux-all* >> ?java/awt/Window/ShapedAndTranslucentWindows/Translucent.java 8222328 windows-all,linux-all,macosx-all >> ?java/awt/Window/AlwaysOnTop/AutoTestOnTop.java 6847593 macosx-all,windows-all,linux-all >> ?java/awt/Window/GrabSequence/GrabSequence.java 6848409 macosx-all,linux-all >> >> Regards >> Prasanta > -- Best regards, Sergey. From philip.race at oracle.com Sat May 18 05:29:05 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 17 May 2019 22:29:05 -0700 Subject: [13] Review Request: 8224152 [macOS] ProblemList tests that leave rubbish on the screen In-Reply-To: References: Message-ID: <5CDF9821.90501@oracle.com> +1 -phil. On 5/17/19, 7:25 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224152 > Fix: http://cr.openjdk.java.net/~serb/8224152/webrev.00 > > Bug description: > > One of the bugs in the Robot implementation can be exposed by 2 > different tests. If both runs in a row, they leave some key modifiers > pressed which caused another test to press some shortcuts instead of a > simple key. One of these shortcuts hide the test window, and as a > result, all other shortcuts will send to the terminal window -> tons > of utility windows will be opened. Note that these tests are fine, > actually, they are a pass but cause some other tests to fail. > > While I am working on the bug in Robot, I would like to add these > tests to the problem list. > From semyon.sadetsky at oracle.com Mon May 20 15:37:04 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Mon, 20 May 2019 08:37:04 -0700 Subject: [13] RFR 8153090 8223788 8224149: TAB key cannot change input focus after the radio button in the Color Selection dialog.+ Message-ID: <783fc182-de41-96d1-b0fd-93cdd6dc16a6@oracle.com> bugs: https://bugs.openjdk.java.net/browse/JDK-8153090 https://bugs.openjdk.java.net/browse/JDK-8223788 https://bugs.openjdk.java.net/browse/JDK-8224149 webrev: http://cr.openjdk.java.net/~ssadetsky/8153090/webrev.00/ The fix eliminates issues in JColorChooser dialog making it more accessible by keyboard. See JBS for details. --Semyon From philip.race at oracle.com Mon May 20 17:05:16 2019 From: philip.race at oracle.com (Phil Race) Date: Mon, 20 May 2019 10:05:16 -0700 Subject: [13] Review Request: 8223045 GraphicsEnvironment does not detect resolution changes in multiscreen systems In-Reply-To: <869c8794-907b-828d-eccc-30db0ac2d6a6@oracle.com> References: <869c8794-907b-828d-eccc-30db0ac2d6a6@oracle.com> Message-ID: <00bd3688-08e4-f296-2806-a469082d5bb5@oracle.com> Looks OK. Seems we were previously leaking (or at least not freeing) the XineramaScreenInfo struct after we were done with it. -phil. On 5/1/19 5:09 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223045 > Fix: http://cr.openjdk.java.net/~serb/8223045/webrev.01 > > This fix deletes the array which initialized on startup and contained > the screen resolution data. > After the fix these data calculated on-demand. > > Note: It is possible that the list of screens(which we still cache, > see JDK-8076313[1]) can be out of sync to the real number of screens > on the system, for removed screens we will request the bounds of the > main screen if it fails we will request the screen bounds using X11. > > [1] https://bugs.openjdk.java.net/browse/JDK-8076313 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon May 20 18:04:32 2019 From: philip.race at oracle.com (Philip Race) Date: Mon, 20 May 2019 11:04:32 -0700 Subject: [13] RFR 8153090 8223788 8224149: TAB key cannot change input focus after the radio button in the Color Selection dialog.+ In-Reply-To: <783fc182-de41-96d1-b0fd-93cdd6dc16a6@oracle.com> References: <783fc182-de41-96d1-b0fd-93cdd6dc16a6@oracle.com> Message-ID: <5CE2EC30.1040304@oracle.com> Hi, I'm afraid I know next to nothing about the focus traversal code in Swing or AWT, but it smells very wrong to have such knowledge of a specific Swing component in the AWT focus code. -phil. On 5/20/19, 8:37 AM, semyon.sadetsky at oracle.com wrote: > bugs: > > https://bugs.openjdk.java.net/browse/JDK-8153090 > > https://bugs.openjdk.java.net/browse/JDK-8223788 > > https://bugs.openjdk.java.net/browse/JDK-8224149 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8153090/webrev.00/ > > The fix eliminates issues in JColorChooser dialog making it more > accessible by keyboard. See JBS for details. > > --Semyon > From semyon.sadetsky at oracle.com Mon May 20 20:06:37 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Mon, 20 May 2019 13:06:37 -0700 Subject: [13] RFR 8153090 8223788 8224149: TAB key cannot change input focus after the radio button in the Color Selection dialog.+ In-Reply-To: <5CE2EC30.1040304@oracle.com> References: <783fc182-de41-96d1-b0fd-93cdd6dc16a6@oracle.com> <5CE2EC30.1040304@oracle.com> Message-ID: <3b55845d-a885-cacd-f995-63680846cb0c@oracle.com> On 5/20/19 11:04 AM, Philip Race wrote: > Hi, > > I'm afraid I know next to nothing about the focus traversal > code in Swing or AWT, but it smells very wrong to have > such knowledge of a specific Swing component in the > AWT focus code. I don't see anything wrong here. You can find a lot of Swing component specific code in java.awt.* implementations. This is not the first Swing aware AWT class. --Semyon > > -phil. > > On 5/20/19, 8:37 AM, semyon.sadetsky at oracle.com wrote: >> bugs: >> >> https://bugs.openjdk.java.net/browse/JDK-8153090 >> >> https://bugs.openjdk.java.net/browse/JDK-8223788 >> >> https://bugs.openjdk.java.net/browse/JDK-8224149 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8153090/webrev.00/ >> >> The fix eliminates issues in JColorChooser dialog making it more >> accessible by keyboard. See JBS for details. >> >> --Semyon >> From Sergey.Bylokhov at oracle.com Tue May 21 00:13:34 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 20 May 2019 17:13:34 -0700 Subject: [13] Review Request: 8223045 GraphicsEnvironment does not detect resolution changes in multiscreen systems In-Reply-To: <00bd3688-08e4-f296-2806-a469082d5bb5@oracle.com> References: <869c8794-907b-828d-eccc-30db0ac2d6a6@oracle.com> <00bd3688-08e4-f296-2806-a469082d5bb5@oracle.com> Message-ID: <4469018c-5097-770b-912b-d3c6895e21cd@oracle.com> On 20/05/2019 10:05, Phil Race wrote: > Looks OK. Seems we were previously leaking (or at least not freeing) the > > XineramaScreenInfo struct after we were done with it. -phil. Correct. > > > On 5/1/19 5:09 PM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for JDK 13. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223045 >> Fix: http://cr.openjdk.java.net/~serb/8223045/webrev.01 >> >> This fix deletes the array which initialized on startup and contained the screen resolution data. >> After the fix these data calculated on-demand. >> >> Note: It is possible that the list of screens(which we still cache, see JDK-8076313[1]) can be out of sync to the real number of screens on the system, for removed screens we will request the bounds of the main screen if it fails we will request the screen bounds using X11. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8076313 >> > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Tue May 21 06:48:35 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 21 May 2019 12:18:35 +0530 Subject: [13] RFR 8153090 8223788 8224149: TAB key cannot change input focus after the radio button in the Color Selection dialog.+ In-Reply-To: <3b55845d-a885-cacd-f995-63680846cb0c@oracle.com> References: <783fc182-de41-96d1-b0fd-93cdd6dc16a6@oracle.com> <5CE2EC30.1040304@oracle.com> <3b55845d-a885-cacd-f995-63680846cb0c@oracle.com> Message-ID: <65ee59fe-118e-a7e5-b957-95d48d8c84e9@oracle.com> Probably we can move this traversal code to javax.swing.SortingFocusTraversalPolicy#SwingContainerOrderFocusTraversalPolicy for this JToggleButton swing component to avoid this scepticism. Regards Prasanta On 21-May-19 1:36 AM, semyon.sadetsky at oracle.com wrote: > On 5/20/19 11:04 AM, Philip Race wrote: > >> Hi, >> >> I'm afraid I know next to nothing about the focus traversal >> code in Swing or AWT, but it smells very wrong to have >> such knowledge of a specific Swing component in the >> AWT focus code. > I don't see anything wrong here. You can find a lot of Swing component > specific code in java.awt.* implementations. This is not the first > Swing aware AWT class. > > --Semyon >> >> -phil. >> >> On 5/20/19, 8:37 AM, semyon.sadetsky at oracle.com wrote: >>> bugs: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8153090 >>> >>> https://bugs.openjdk.java.net/browse/JDK-8223788 >>> >>> https://bugs.openjdk.java.net/browse/JDK-8224149 >>> >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8153090/webrev.00/ >>> >>> The fix eliminates issues in JColorChooser dialog making it more >>> accessible by keyboard. See JBS for details. >>> >>> --Semyon >>> > From takiguc at linux.vnet.ibm.com Tue May 21 08:36:28 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 21 May 2019 17:36:28 +0900 Subject: RFR: 8218054 Infinity loop happened on Ubuntu 18.04 XVNC4 with depth 32 Message-ID: <751763cbd93f6a443e7f95a65a958d43@linux.vnet.ibm.com> Hello. Could you review the fix ? Change: https://cr.openjdk.java.net/~itakiguchi/8218054/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8218054 Loop variable "i" needs to handle unsigned 32 bit integer. But it was "int i". To handle unsigned 32 bit integer, "i" should be "long". After this fix is applied, you may see color issue. Screen shots were attached into JDK-8218054 [1] Java's color model may not be applied properly. I tried to fix this color issue, but I could not find out root cause. If you are interested in this color issue, could you solve this one, please ? Xserver is loaded "Extended-Visual-Information" extension [2]. Since xcolors command output is properly, I think the issue is not related VNC viewer side. [1] https://bugs.openjdk.java.net/browse/JDK-8218054 [2] https://www.x.org/releases/X11R7.7/doc/xextproto/evi.html Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From takiguc at linux.vnet.ibm.com Wed May 22 07:15:23 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 22 May 2019 16:15:23 +0900 Subject: RFR: 8221082 Unexpected working behavior when using AIX's dtwm/mwm In-Reply-To: <3f6bb114-4f56-b840-ae06-9b7418143f39@oracle.com> References: <3f6bb114-4f56-b840-ae06-9b7418143f39@oracle.com> Message-ID: Hello Sergey. I appreciate your suggestion. I could start talking with AIX GUI experts about this issue. I'll let you know when the situation is changed. Since CDE is the only desktop environment running on AIX platform, please maintain the current support level of CDE / MWM. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2019-05-02 10:09, Sergey Bylokhov wrote: > Hi, Ichiroh. > On 25/04/2019 04:08, Ichiroh Takiguchi wrote: >> dtwm (CDE's window manager) and mwm (motif window manager) cannot >> handle non focusable window properly. >> (Java cannot control input focus via WM_TAKE_FOCUS) >> I found the fix against dtwm/mwm on AIX platform, but it did not work >> on Linux's mwm. > > Can you please clarify why it doesn't work on Linux? It would be > better to minimize platforms specific code. > > I guess that the problem is that the non-focused window is looking > like the focused, but in fact, it is still unfocused and none of its > children can be focused as well? Otherwise, I think some of the tck > tests could fail. If that's correct it is unclear if this problem is > important and should we as a fix inject more platform-specific code to > the XPeers. Since the CDE is unsupported by AWT for a more than 10 > years I think the issues are not critical. From semyon.sadetsky at oracle.com Wed May 22 22:16:49 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Wed, 22 May 2019 15:16:49 -0700 Subject: [13] RFR 8153090 8223788 8224149: TAB key cannot change input focus after the radio button in the Color Selection dialog.+ In-Reply-To: <65ee59fe-118e-a7e5-b957-95d48d8c84e9@oracle.com> References: <783fc182-de41-96d1-b0fd-93cdd6dc16a6@oracle.com> <5CE2EC30.1040304@oracle.com> <3b55845d-a885-cacd-f995-63680846cb0c@oracle.com> <65ee59fe-118e-a7e5-b957-95d48d8c84e9@oracle.com> Message-ID: <74e3a9b1-b001-28e7-a51a-738f0ab5cfbd@oracle.com> On 5/20/19 11:48 PM, Prasanta Sadhukhan wrote: > Probably we can move this traversal code to > javax.swing.SortingFocusTraversalPolicy#SwingContainerOrderFocusTraversalPolicy > for this JToggleButton swing component to avoid this scepticism. Hi Prasanta, We cannot move it there because it'd not be called when ContainerOrderFocusTraversalPolicy is used. --Semyon > > Regards > Prasanta > On 21-May-19 1:36 AM, semyon.sadetsky at oracle.com wrote: >> On 5/20/19 11:04 AM, Philip Race wrote: >> >>> Hi, >>> >>> I'm afraid I know next to nothing about the focus traversal >>> code in Swing or AWT, but it smells very wrong to have >>> such knowledge of a specific Swing component in the >>> AWT focus code. >> I don't see anything wrong here. You can find a lot of Swing >> component specific code in java.awt.* implementations. This is not >> the first Swing aware AWT class. >> >> --Semyon >>> >>> -phil. >>> >>> On 5/20/19, 8:37 AM, semyon.sadetsky at oracle.com wrote: >>>> bugs: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8153090 >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8223788 >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8224149 >>>> >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8153090/webrev.00/ >>>> >>>> The fix eliminates issues in JColorChooser dialog making it more >>>> accessible by keyboard. See JBS for details. >>>> >>>> --Semyon >>>> >> > From philip.race at oracle.com Thu May 23 20:56:04 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 23 May 2019 13:56:04 -0700 Subject: RFR: 8224632: testbug: java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java fails on MacOS Message-ID: On onw of our test systems which is somewhat under-powered (an oldish mac-mini), the child process in this test takes 114 seconds to run (vs 60-something on my MacBook) So I propose to increase the allowed timeout -phil. bug:? https://bugs.openjdk.java.net/browse/JDK-8224632 fix : diff --git a/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java b/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java --- a/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java +++ b/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java @@ -60,7 +60,7 @@ ?/** ? * @test ? * @key headful - * @bug 4393148 8136999 8186263 + * @bug 4393148 8136999 8186263 8224632 ? * @summary tests that removal of the drop target or disposal of frame during ? *????????? drop processing doesn't cause crash ? * @run main RemoveDropTargetCrashTest RUN_PROCESS @@ -301,7 +301,7 @@ ???????????????? + " " + RemoveDropTargetCrashTest.class.getName() + " " + RUN_TEST; ???????? Process process = Runtime.getRuntime().exec(command); -??????? boolean processExit = process.waitFor(100, TimeUnit.SECONDS); +??????? boolean processExit = process.waitFor(200, TimeUnit.SECONDS); ???????? StringBuilder inStream = new StringBuilder(); ???????? StringBuilder errStream = new StringBuilder(); From Sergey.Bylokhov at oracle.com Thu May 23 21:22:21 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 23 May 2019 14:22:21 -0700 Subject: RFR: 8224632: testbug: java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java fails on MacOS In-Reply-To: References: Message-ID: <64857a94-e4dc-50c8-13f5-14a569e5a518@oracle.com> Hi, Phil. I guess the new timeout is bigger than the default timeout in jtreg, and it should be bumped as well? On 23/05/2019 13:56, Phil Race wrote: > > On onw of our test systems which is somewhat under-powered (an oldish mac-mini), > the child process in this test takes 114 seconds to run (vs 60-something on my MacBook) > So I propose to increase the allowed timeout > > -phil. > > bug:? https://bugs.openjdk.java.net/browse/JDK-8224632 > > fix : > > diff --git a/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java b/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java > --- a/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java > +++ b/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java > @@ -60,7 +60,7 @@ > ?/** > ? * @test > ? * @key headful > - * @bug 4393148 8136999 8186263 > + * @bug 4393148 8136999 8186263 8224632 > ? * @summary tests that removal of the drop target or disposal of frame during > ? *????????? drop processing doesn't cause crash > ? * @run main RemoveDropTargetCrashTest RUN_PROCESS > @@ -301,7 +301,7 @@ > ???????????????? + " " + RemoveDropTargetCrashTest.class.getName() + " " + RUN_TEST; > > ???????? Process process = Runtime.getRuntime().exec(command); > -??????? boolean processExit = process.waitFor(100, TimeUnit.SECONDS); > +??????? boolean processExit = process.waitFor(200, TimeUnit.SECONDS); > > ???????? StringBuilder inStream = new StringBuilder(); > ???????? StringBuilder errStream = new StringBuilder(); > -- Best regards, Sergey. From philip.race at oracle.com Thu May 23 21:23:40 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 23 May 2019 14:23:40 -0700 Subject: RFR: 8224632: testbug: java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java fails on MacOS In-Reply-To: <64857a94-e4dc-50c8-13f5-14a569e5a518@oracle.com> References: <64857a94-e4dc-50c8-13f5-14a569e5a518@oracle.com> Message-ID: Sure :- - * @bug 4393148 8136999 8186263 + * @bug 4393148 8136999 8186263 8224632 ? * @summary tests that removal of the drop target or disposal of frame during ? *????????? drop processing doesn't cause crash - * @run main RemoveDropTargetCrashTest RUN_PROCESS + * @run main/timeout=300 RemoveDropTargetCrashTest RUN_PROCESS ? */ ?public class RemoveDropTargetCrashTest { @@ -301,7 +301,7 @@ ???????????????? + " " + RemoveDropTargetCrashTest.class.getName() + " " + RUN_TEST; ???????? Process process = Runtime.getRuntime().exec(command); -??????? boolean processExit = process.waitFor(100, TimeUnit.SECONDS); +??????? boolean processExit = process.waitFor(200, TimeUnit.SECONDS); -phil. On 5/23/19 2:22 PM, Sergey Bylokhov wrote: > Hi, Phil. > > I guess the new timeout is bigger than the default timeout in jtreg, > and it should be bumped as well? > > On 23/05/2019 13:56, Phil Race wrote: >> >> On onw of our test systems which is somewhat under-powered (an oldish >> mac-mini), >> the child process in this test takes 114 seconds to run (vs >> 60-something on my MacBook) >> So I propose to increase the allowed timeout >> >> -phil. >> >> bug:? https://bugs.openjdk.java.net/browse/JDK-8224632 >> >> fix : >> >> diff --git >> a/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java >> b/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java >> >> --- >> a/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java >> +++ >> b/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java >> @@ -60,7 +60,7 @@ >> ??/** >> ?? * @test >> ?? * @key headful >> - * @bug 4393148 8136999 8186263 >> + * @bug 4393148 8136999 8186263 8224632 >> ?? * @summary tests that removal of the drop target or disposal of >> frame during >> ?? *????????? drop processing doesn't cause crash >> ?? * @run main RemoveDropTargetCrashTest RUN_PROCESS >> @@ -301,7 +301,7 @@ >> ????????????????? + " " + RemoveDropTargetCrashTest.class.getName() + >> " " + RUN_TEST; >> >> ????????? Process process = Runtime.getRuntime().exec(command); >> -??????? boolean processExit = process.waitFor(100, TimeUnit.SECONDS); >> +??????? boolean processExit = process.waitFor(200, TimeUnit.SECONDS); >> >> ????????? StringBuilder inStream = new StringBuilder(); >> ????????? StringBuilder errStream = new StringBuilder(); >> > > From philip.race at oracle.com Thu May 23 21:41:54 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 23 May 2019 14:41:54 -0700 Subject: RFR: 8224705: Tests that need to be problem-listed or have printer resources Message-ID: <5b987102-3543-846d-08cd-ccf3edf6cdb4@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8224705 Webrev: http://cr.openjdk.java.net/~prr/8224705/ There are open bugs and these can be problem listed as well as adding @key headful to the printer tests -phil. From Sergey.Bylokhov at oracle.com Thu May 23 21:54:55 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 23 May 2019 14:54:55 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8224705: Tests that need to be problem-listed or have printer resources In-Reply-To: <5b987102-3543-846d-08cd-ccf3edf6cdb4@oracle.com> References: <5b987102-3543-846d-08cd-ccf3edf6cdb4@oracle.com> Message-ID: Hi, Phil. > There are open bugs and these can be problem listed as well as adding @key headful to the printer test These "open" bugs for printing were closed as "Cannot Reproduce" probably we should reopen them? -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu May 23 21:56:56 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 23 May 2019 14:56:56 -0700 Subject: RFR: 8224632: testbug: java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java fails on MacOS In-Reply-To: References: <64857a94-e4dc-50c8-13f5-14a569e5a518@oracle.com> Message-ID: <7aea166d-9e2d-b54d-714d-6518b5ce72c7@oracle.com> Looks fine. On 23/05/2019 14:23, Phil Race wrote: > Sure :- > > > - * @bug 4393148 8136999 8186263 > + * @bug 4393148 8136999 8186263 8224632 > ? * @summary tests that removal of the drop target or disposal of frame during > ? *????????? drop processing doesn't cause crash > - * @run main RemoveDropTargetCrashTest RUN_PROCESS > + * @run main/timeout=300 RemoveDropTargetCrashTest RUN_PROCESS > ? */ > ?public class RemoveDropTargetCrashTest { > > @@ -301,7 +301,7 @@ > ???????????????? + " " + RemoveDropTargetCrashTest.class.getName() + " " + RUN_TEST; > > ???????? Process process = Runtime.getRuntime().exec(command); > -??????? boolean processExit = process.waitFor(100, TimeUnit.SECONDS); > +??????? boolean processExit = process.waitFor(200, TimeUnit.SECONDS); > > -phil. > > On 5/23/19 2:22 PM, Sergey Bylokhov wrote: >> Hi, Phil. >> >> I guess the new timeout is bigger than the default timeout in jtreg, and it should be bumped as well? >> >> On 23/05/2019 13:56, Phil Race wrote: >>> >>> On onw of our test systems which is somewhat under-powered (an oldish mac-mini), >>> the child process in this test takes 114 seconds to run (vs 60-something on my MacBook) >>> So I propose to increase the allowed timeout >>> >>> -phil. >>> >>> bug:? https://bugs.openjdk.java.net/browse/JDK-8224632 >>> >>> fix : >>> >>> diff --git a/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java b/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java >>> --- a/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java >>> +++ b/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java >>> @@ -60,7 +60,7 @@ >>> ??/** >>> ?? * @test >>> ?? * @key headful >>> - * @bug 4393148 8136999 8186263 >>> + * @bug 4393148 8136999 8186263 8224632 >>> ?? * @summary tests that removal of the drop target or disposal of frame during >>> ?? *????????? drop processing doesn't cause crash >>> ?? * @run main RemoveDropTargetCrashTest RUN_PROCESS >>> @@ -301,7 +301,7 @@ >>> ????????????????? + " " + RemoveDropTargetCrashTest.class.getName() + " " + RUN_TEST; >>> >>> ????????? Process process = Runtime.getRuntime().exec(command); >>> -??????? boolean processExit = process.waitFor(100, TimeUnit.SECONDS); >>> +??????? boolean processExit = process.waitFor(200, TimeUnit.SECONDS); >>> >>> ????????? StringBuilder inStream = new StringBuilder(); >>> ????????? StringBuilder errStream = new StringBuilder(); >>> >> >> > -- Best regards, Sergey. From philip.race at oracle.com Thu May 23 21:54:10 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 23 May 2019 14:54:10 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8224705: Tests that need to be problem-listed or have printer resources In-Reply-To: References: <5b987102-3543-846d-08cd-ccf3edf6cdb4@oracle.com> Message-ID: <4b1c60f2-fef1-50de-7121-633ed7ccbfc7@oracle.com> Done. Since this is very reproducible on our current test setup. -phil On 5/23/19 2:54 PM, Sergey Bylokhov wrote: > Hi, Phil. > >> There are open bugs and these can be problem listed as well as adding >> @key headful to the printer test > These "open" bugs for printing were closed as "Cannot Reproduce" > probably we should reopen them? > From Sergey.Bylokhov at oracle.com Thu May 23 23:44:15 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 23 May 2019 16:44:15 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8224705: Tests that need to be problem-listed or have printer resources In-Reply-To: <4b1c60f2-fef1-50de-7121-633ed7ccbfc7@oracle.com> References: <5b987102-3543-846d-08cd-ccf3edf6cdb4@oracle.com> <4b1c60f2-fef1-50de-7121-633ed7ccbfc7@oracle.com> Message-ID: <13d100da-04c0-6221-c5ef-bda61dc9bb6e@oracle.com> +1 On 23/05/2019 14:54, Phil Race wrote: > Done. Since this is very reproducible on our current test setup. > > -phil > > On 5/23/19 2:54 PM, Sergey Bylokhov wrote: >> Hi, Phil. >> >>> There are open bugs and these can be problem listed as well as adding @key headful to the printer test >> These "open" bugs for printing were closed as "Cannot Reproduce" probably we should reopen them? >> > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Fri May 24 03:53:21 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 24 May 2019 09:23:21 +0530 Subject: RFR: 8224632: testbug: java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java fails on MacOS In-Reply-To: <7aea166d-9e2d-b54d-714d-6518b5ce72c7@oracle.com> References: <64857a94-e4dc-50c8-13f5-14a569e5a518@oracle.com> <7aea166d-9e2d-b54d-714d-6518b5ce72c7@oracle.com> Message-ID: <4aea0da9-9c82-ffd0-3422-8b330b65d37a@oracle.com> I guess Sergey told in one of our review that if it is just a test-only fix, then there's no need to update the bug entry as per http://openjdk.java.net/jtreg/faq.html#when-should-i-update-the-bug-entry-in-a-test-description so I guess it is not needed here as well, as we need to adopt a same approach. Otherwise looks fine. Regards Prasanta On 24-May-19 3:26 AM, Sergey Bylokhov wrote: > Looks fine. > > On 23/05/2019 14:23, Phil Race wrote: >> Sure :- >> >> >> - * @bug 4393148 8136999 8186263 >> + * @bug 4393148 8136999 8186263 8224632 >> ?? * @summary tests that removal of the drop target or disposal of >> frame during >> ?? *????????? drop processing doesn't cause crash >> - * @run main RemoveDropTargetCrashTest RUN_PROCESS >> + * @run main/timeout=300 RemoveDropTargetCrashTest RUN_PROCESS >> ?? */ >> ??public class RemoveDropTargetCrashTest { >> >> @@ -301,7 +301,7 @@ >> ????????????????? + " " + RemoveDropTargetCrashTest.class.getName() + >> " " + RUN_TEST; >> >> ????????? Process process = Runtime.getRuntime().exec(command); >> -??????? boolean processExit = process.waitFor(100, TimeUnit.SECONDS); >> +??????? boolean processExit = process.waitFor(200, TimeUnit.SECONDS); >> >> -phil. >> >> On 5/23/19 2:22 PM, Sergey Bylokhov wrote: >>> Hi, Phil. >>> >>> I guess the new timeout is bigger than the default timeout in jtreg, >>> and it should be bumped as well? >>> >>> On 23/05/2019 13:56, Phil Race wrote: >>>> >>>> On onw of our test systems which is somewhat under-powered (an >>>> oldish mac-mini), >>>> the child process in this test takes 114 seconds to run (vs >>>> 60-something on my MacBook) >>>> So I propose to increase the allowed timeout >>>> >>>> -phil. >>>> >>>> bug:? https://bugs.openjdk.java.net/browse/JDK-8224632 >>>> >>>> fix : >>>> >>>> diff --git >>>> a/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java >>>> b/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java >>>> >>>> --- >>>> a/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java >>>> +++ >>>> b/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java >>>> @@ -60,7 +60,7 @@ >>>> ??/** >>>> ?? * @test >>>> ?? * @key headful >>>> - * @bug 4393148 8136999 8186263 >>>> + * @bug 4393148 8136999 8186263 8224632 >>>> ?? * @summary tests that removal of the drop target or disposal of >>>> frame during >>>> ?? *????????? drop processing doesn't cause crash >>>> ?? * @run main RemoveDropTargetCrashTest RUN_PROCESS >>>> @@ -301,7 +301,7 @@ >>>> ????????????????? + " " + RemoveDropTargetCrashTest.class.getName() >>>> + " " + RUN_TEST; >>>> >>>> ????????? Process process = Runtime.getRuntime().exec(command); >>>> -??????? boolean processExit = process.waitFor(100, TimeUnit.SECONDS); >>>> +??????? boolean processExit = process.waitFor(200, TimeUnit.SECONDS); >>>> >>>> ????????? StringBuilder inStream = new StringBuilder(); >>>> ????????? StringBuilder errStream = new StringBuilder(); >>>> >>> >>> >> > > From prasanta.sadhukhan at oracle.com Fri May 24 03:56:39 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 24 May 2019 09:26:39 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8224705: Tests that need to be problem-listed or have printer resources In-Reply-To: <5b987102-3543-846d-08cd-ccf3edf6cdb4@oracle.com> References: <5b987102-3543-846d-08cd-ccf3edf6cdb4@oracle.com> Message-ID: +1 Regards Prasanta On 24-May-19 3:11 AM, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8224705 > Webrev: http://cr.openjdk.java.net/~prr/8224705/ > > There are open bugs and these can be problem listed as well as adding > @key headful to the printer tests > > -phil. From philip.race at oracle.com Fri May 24 16:35:15 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 24 May 2019 09:35:15 -0700 Subject: RFR: 8223271: SplashScreen is still shown if defaulting to headless on MacOS Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8223271 Webrev : http://cr.openjdk.java.net/~prr/8223271/ Whilst working on removing some inappropriate coupling of the java launcher and the desktop module, and testing out the -splash option, I noticed that on MacOS, in the case when we *default* to headless mode (which happens when we determine that we are not in a desktop session), the launcher still invokes the splash screen code. This could cause an application to completely hang. The problem is explained in detail in the bug report, but briefly, the launcher isn't aware of this defaulting to headless. And the calls the launcher makes to the dynamically loaded splashscreen code, don't return any value it can use to be aware of this. So this fix updates "DoSplashInit()" to return such a code, and in the event of a headful session not being available, it can bail out and not try to show the splashscreen. That is the gist of the small set of changes in java.c that relate to this fix. However I also observed a small memory leak. There are static variables static char* splash_jar_entry = NULL; static char* splash_file_entry = NULL; which are meant to hold the location of the splash image. When everything is done the malloced storage these point to is freed ... except that the malloc code looks like this :- char* splash_file_entry = JLI_MemAlloc(JLI_StrLen(SPLASH_FILE_ENV_ENTRY "=")+JLI_StrLen(splash_file_name)+1); char* splash_jar_entry = JLI_MemAlloc(JLI_StrLen(SPLASH_JAR_ENV_ENTRY "=")+JLI_StrLen(splash_jar_name)+1); So the static vars are never used and the storage pointed to by local variables is never freed. So I am fixing that too. The rest of the fix is in the splashscreen code in the desktop module and it implements the return of the status code described above. There was one leak there too - a stream was not closed in a case where the splash could not be displayed. The regression tests for splash screen were run, but testing this is more an environmental issue - sshing into a MacOS system and running tests and demos which would try to display a splash and verifying they no longer do, so I didn't see a way to add a specific regression test. -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri May 24 17:05:31 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 24 May 2019 10:05:31 -0700 Subject: RFR: 8224771 backout RemoveDropTargetCrashTest.java fix to re-push with correct bugid Message-ID: The wrong commit message file was used, so I need to back out a test fix to re-push\ Below is the backout change : -phil. bug: https://bugs.openjdk.java.net/browse/JDK-8224771 diff --git a/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java b/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java --- a/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java +++ b/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java @@ -60,10 +60,10 @@ ?/** ? * @test ? * @key headful - * @bug 4393148 8136999 8186263 8224632 + * @bug 4393148 8136999 8186263 ? * @summary tests that removal of the drop target or disposal of frame during ? *????????? drop processing doesn't cause crash - * @run main/timeout=300 RemoveDropTargetCrashTest RUN_PROCESS + * @run main RemoveDropTargetCrashTest RUN_PROCESS ? */ ?public class RemoveDropTargetCrashTest { @@ -301,7 +301,7 @@ ???????????????? + " " + RemoveDropTargetCrashTest.class.getName() + " " + RUN_TEST; ???????? Process process = Runtime.getRuntime().exec(command); -??????? boolean processExit = process.waitFor(200, TimeUnit.SECONDS); +??????? boolean processExit = process.waitFor(100, TimeUnit.SECONDS); From Sergey.Bylokhov at oracle.com Fri May 24 19:52:30 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 24 May 2019 12:52:30 -0700 Subject: RFR: 8224771 backout RemoveDropTargetCrashTest.java fix to re-push with correct bugid In-Reply-To: References: Message-ID: <92a85e96-3806-e804-101a-36a4b083f0c5@oracle.com> +1 On 24/05/2019 10:05, Phil Race wrote: > The wrong commit message file was used, so I need to back out a test fix to re-push\ > Below is the backout change : > > -phil. > > bug: https://bugs.openjdk.java.net/browse/JDK-8224771 > > diff --git a/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java b/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java > --- a/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java > +++ b/test/jdk/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java > @@ -60,10 +60,10 @@ > ?/** > ? * @test > ? * @key headful > - * @bug 4393148 8136999 8186263 8224632 > + * @bug 4393148 8136999 8186263 > ? * @summary tests that removal of the drop target or disposal of frame during > ? *????????? drop processing doesn't cause crash > - * @run main/timeout=300 RemoveDropTargetCrashTest RUN_PROCESS > + * @run main RemoveDropTargetCrashTest RUN_PROCESS > ? */ > ?public class RemoveDropTargetCrashTest { > > @@ -301,7 +301,7 @@ > ???????????????? + " " + RemoveDropTargetCrashTest.class.getName() + " " + RUN_TEST; > > ???????? Process process = Runtime.getRuntime().exec(command); > -??????? boolean processExit = process.waitFor(200, TimeUnit.SECONDS); > +??????? boolean processExit = process.waitFor(100, TimeUnit.SECONDS); > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Mon May 27 09:09:35 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 27 May 2019 14:39:35 +0530 Subject: [13] RFR JDK-8224821: java/awt/Focus/NoAutotransferToDisabledCompTest/NoAutotransferToDisabledCompTest.java fails linux-x64 Message-ID: <44c6052c-a0ea-1d68-3761-081aceaf1932@oracle.com> Hi All, Please review a test fix for an issue where it seems focus does not transfer automatically in some case in our headful nightly system. Issue seems to be due to test expects focus to be shifted too soon which may not happen like that in somewhat slow system. So, added some delay which makes the test pass in the mach5 system Bug: https://bugs.openjdk.java.net/browse/JDK-8224821 webrev: http://cr.openjdk.java.net/~psadhukhan/8224821/webrev.0/ Regards Prasanta From prasanta.sadhukhan at oracle.com Mon May 27 10:50:11 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 27 May 2019 16:20:11 +0530 Subject: [13] RFR 8224830:test/jdk/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcludedWindowClickTest.java fails on linux-x64 Message-ID: Hi All, Please review a test fix for an issue where it is seen that button click actionlistener was not called leading to an exception. Issue seems to arise from the fact that buttonclick was performed without waiting for button to really appear/shown. Fix is to make the actual execution of the test wait for button to appear. Bug: https://bugs.openjdk.java.net/browse/JDK-8224830 webrev: http://cr.openjdk.java.net/~psadhukhan/8224830/webrev/ Regards Prasanta From prasanta.sadhukhan at oracle.com Tue May 28 09:16:01 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 28 May 2019 14:46:01 +0530 Subject: [13] RFR 8224830:test/jdk/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcludedWindowClickTest.java fails on linux-x64 In-Reply-To: References: Message-ID: <8cdc3e73-9b91-4cb5-2dd8-ff064a8e4667@oracle.com> PS: Modified test pass on windows,linux,mac headful mach5 systems Regards Prasanta On 27-May-19 4:20 PM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a test fix for an issue where it is seen that button > click actionlistener was not called leading to an exception. > > Issue seems to arise from the fact that buttonclick was performed > without waiting for button to really appear/shown. > > Fix is to make the actual execution of the test wait for button to > appear. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224830 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8224830/webrev/ > > Regards > Prasanta From prasanta.sadhukhan at oracle.com Tue May 28 09:17:18 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 28 May 2019 14:47:18 +0530 Subject: [13] RFR JDK-8224821: java/awt/Focus/NoAutotransferToDisabledCompTest/NoAutotransferToDisabledCompTest.java fails linux-x64 In-Reply-To: <44c6052c-a0ea-1d68-3761-081aceaf1932@oracle.com> References: <44c6052c-a0ea-1d68-3761-081aceaf1932@oracle.com> Message-ID: <100b9b84-3f6d-5727-ee06-54f46f3bd2fb@oracle.com> PS: Modified test pass on windows,linux headful mach5 systems, on mac it is problemlisted already. Regards Prasanta On 27-May-19 2:39 PM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a test fix for an issue where it seems focus does not > transfer automatically in some case in our headful nightly system. > Issue seems to be due to test expects focus to be shifted too soon > which may not happen like that in somewhat slow system. So, added some > delay which makes the test pass in the mach5 system > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224821 > webrev: http://cr.openjdk.java.net/~psadhukhan/8224821/webrev.0/ > > Regards > Prasanta From jayathirth.d.v at oracle.com Tue May 28 10:00:23 2019 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 28 May 2019 03:00:23 -0700 (PDT) Subject: [13] RFR JDK-8224821: java/awt/Focus/NoAutotransferToDisabledCompTest/NoAutotransferToDisabledCompTest.java fails linux-x64 In-Reply-To: <100b9b84-3f6d-5727-ee06-54f46f3bd2fb@oracle.com> References: <44c6052c-a0ea-1d68-3761-081aceaf1932@oracle.com> <100b9b84-3f6d-5727-ee06-54f46f3bd2fb@oracle.com> Message-ID: Hi Prasanta, We are already waiting for 2 secs in Util.focusComponent(), do we need the first delay of 2 secs just before that? Second robot.delay() is okay. Thanks, Jay -----Original Message----- From: Prasanta Sadhukhan Sent: Tuesday, May 28, 2019 2:47 PM To: awt-dev at openjdk.java.net Subject: Re: [13] RFR JDK-8224821: java/awt/Focus/NoAutotransferToDisabledCompTest/NoAutotransferToDisabledCompTest.java fails linux-x64 PS: Modified test pass on windows,linux headful mach5 systems, on mac it is problemlisted already. Regards Prasanta On 27-May-19 2:39 PM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a test fix for an issue where it seems focus does not > transfer automatically in some case in our headful nightly system. > Issue seems to be due to test expects focus to be shifted too soon > which may not happen like that in somewhat slow system. So, added some > delay which makes the test pass in the mach5 system > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224821 > webrev: http://cr.openjdk.java.net/~psadhukhan/8224821/webrev.0/ > > Regards > Prasanta From jayathirth.d.v at oracle.com Tue May 28 10:08:40 2019 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 28 May 2019 03:08:40 -0700 (PDT) Subject: [13] RFR 8224830:test/jdk/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcludedWindowClickTest.java fails on linux-x64 In-Reply-To: <8cdc3e73-9b91-4cb5-2dd8-ff064a8e4667@oracle.com> References: <8cdc3e73-9b91-4cb5-2dd8-ff064a8e4667@oracle.com> Message-ID: <70e7cc17-9e1e-4fe2-9bd2-a47c3f2897e6@default> Hi Prasanta, Changes are fine. Also its better to add delay between input events like Press & release. Or you can set auto delay on robot. Thanks, Jay -----Original Message----- From: Prasanta Sadhukhan Sent: Tuesday, May 28, 2019 2:46 PM To: awt-dev at openjdk.java.net Subject: Re: [13] RFR 8224830:test/jdk/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcludedWindowClickTest.java fails on linux-x64 PS: Modified test pass on windows,linux,mac headful mach5 systems Regards Prasanta On 27-May-19 4:20 PM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a test fix for an issue where it is seen that button > click actionlistener was not called leading to an exception. > > Issue seems to arise from the fact that buttonclick was performed > without waiting for button to really appear/shown. > > Fix is to make the actual execution of the test wait for button to > appear. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224830 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8224830/webrev/ > > Regards > Prasanta From prasanta.sadhukhan at oracle.com Tue May 28 10:45:57 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 28 May 2019 16:15:57 +0530 Subject: [13] RFR 8224830:test/jdk/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcludedWindowClickTest.java fails on linux-x64 In-Reply-To: <70e7cc17-9e1e-4fe2-9bd2-a47c3f2897e6@default> References: <8cdc3e73-9b91-4cb5-2dd8-ff064a8e4667@oracle.com> <70e7cc17-9e1e-4fe2-9bd2-a47c3f2897e6@default> Message-ID: <11254f87-c6e8-302a-2495-162e0415d401@oracle.com> Thanks Jay for review. I have also added the delay between press/release. Modified webrev http://cr.openjdk.java.net/~psadhukhan/8224830/webrev.1/ Regards Prasanta On 28-May-19 3:38 PM, Jayathirth D V wrote: > Hi Prasanta, > > Changes are fine. > Also its better to add delay between input events like Press & release. Or you can set auto delay on robot. > > Thanks, > Jay > > -----Original Message----- > From: Prasanta Sadhukhan > Sent: Tuesday, May 28, 2019 2:46 PM > To: awt-dev at openjdk.java.net > Subject: Re: [13] RFR 8224830:test/jdk/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcludedWindowClickTest.java fails on linux-x64 > > PS: Modified test pass on windows,linux,mac headful mach5 systems > > Regards > Prasanta > On 27-May-19 4:20 PM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a test fix for an issue where it is seen that button >> click actionlistener was not called leading to an exception. >> >> Issue seems to arise from the fact that buttonclick was performed >> without waiting for button to really appear/shown. >> >> Fix is to make the actual execution of the test wait for button to >> appear. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224830 >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8224830/webrev/ >> >> Regards >> Prasanta From jayathirth.d.v at oracle.com Tue May 28 10:48:33 2019 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 28 May 2019 03:48:33 -0700 (PDT) Subject: [13] RFR 8224830:test/jdk/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcludedWindowClickTest.java fails on linux-x64 In-Reply-To: <11254f87-c6e8-302a-2495-162e0415d401@oracle.com> References: <8cdc3e73-9b91-4cb5-2dd8-ff064a8e4667@oracle.com> <70e7cc17-9e1e-4fe2-9bd2-a47c3f2897e6@default> <11254f87-c6e8-302a-2495-162e0415d401@oracle.com> Message-ID: <6f74e264-81b7-4575-a466-50b589cce299@default> +1 Thanks, Jay -----Original Message----- From: Prasanta Sadhukhan Sent: Tuesday, May 28, 2019 4:16 PM To: Jayathirth D V; awt-dev at openjdk.java.net Subject: Re: [13] RFR 8224830:test/jdk/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcludedWindowClickTest.java fails on linux-x64 Thanks Jay for review. I have also added the delay between press/release. Modified webrev http://cr.openjdk.java.net/~psadhukhan/8224830/webrev.1/ Regards Prasanta On 28-May-19 3:38 PM, Jayathirth D V wrote: > Hi Prasanta, > > Changes are fine. > Also its better to add delay between input events like Press & release. Or you can set auto delay on robot. > > Thanks, > Jay > > -----Original Message----- > From: Prasanta Sadhukhan > Sent: Tuesday, May 28, 2019 2:46 PM > To: awt-dev at openjdk.java.net > Subject: Re: [13] RFR > 8224830:test/jdk/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcl > udedWindowClickTest.java fails on linux-x64 > > PS: Modified test pass on windows,linux,mac headful mach5 systems > > Regards > Prasanta > On 27-May-19 4:20 PM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a test fix for an issue where it is seen that button >> click actionlistener was not called leading to an exception. >> >> Issue seems to arise from the fact that buttonclick was performed >> without waiting for button to really appear/shown. >> >> Fix is to make the actual execution of the test wait for button to >> appear. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224830 >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8224830/webrev/ >> >> Regards >> Prasanta From prasanta.sadhukhan at oracle.com Tue May 28 10:49:28 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 28 May 2019 16:19:28 +0530 Subject: [13] RFR JDK-8224821: java/awt/Focus/NoAutotransferToDisabledCompTest/NoAutotransferToDisabledCompTest.java fails linux-x64 In-Reply-To: References: <44c6052c-a0ea-1d68-3761-081aceaf1932@oracle.com> <100b9b84-3f6d-5727-ee06-54f46f3bd2fb@oracle.com> Message-ID: <95bf890a-220d-64ab-a6e8-fcdd5810ea19@oracle.com> Thanks Jay for review. I added it for safety but it seems it is not needed, only the 2nd one is needed. Test still pass with only the 2nd one...So, modified webrev http://cr.openjdk.java.net/~psadhukhan/8224821/webrev.1/ Regards Prasanta On 28-May-19 3:30 PM, Jayathirth D V wrote: > Hi Prasanta, > > We are already waiting for 2 secs in Util.focusComponent(), do we need the first delay of 2 secs just before that? > Second robot.delay() is okay. > > Thanks, > Jay > > -----Original Message----- > From: Prasanta Sadhukhan > Sent: Tuesday, May 28, 2019 2:47 PM > To: awt-dev at openjdk.java.net > Subject: Re: [13] RFR JDK-8224821: java/awt/Focus/NoAutotransferToDisabledCompTest/NoAutotransferToDisabledCompTest.java fails linux-x64 > > PS: Modified test pass on windows,linux headful mach5 systems, on mac it is problemlisted already. > > Regards > Prasanta > > On 27-May-19 2:39 PM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a test fix for an issue where it seems focus does not >> transfer automatically in some case in our headful nightly system. >> Issue seems to be due to test expects focus to be shifted too soon >> which may not happen like that in somewhat slow system. So, added some >> delay which makes the test pass in the mach5 system >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224821 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8224821/webrev.0/ >> >> Regards >> Prasanta From jayathirth.d.v at oracle.com Tue May 28 11:01:08 2019 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 28 May 2019 04:01:08 -0700 (PDT) Subject: [13] RFR JDK-8224821: java/awt/Focus/NoAutotransferToDisabledCompTest/NoAutotransferToDisabledCompTest.java fails linux-x64 In-Reply-To: <95bf890a-220d-64ab-a6e8-fcdd5810ea19@oracle.com> References: <44c6052c-a0ea-1d68-3761-081aceaf1932@oracle.com> <100b9b84-3f6d-5727-ee06-54f46f3bd2fb@oracle.com> <95bf890a-220d-64ab-a6e8-fcdd5810ea19@oracle.com> Message-ID: +1 Thanks, Jay -----Original Message----- From: Prasanta Sadhukhan Sent: Tuesday, May 28, 2019 4:19 PM To: Jayathirth D V; awt-dev at openjdk.java.net Subject: Re: [13] RFR JDK-8224821: java/awt/Focus/NoAutotransferToDisabledCompTest/NoAutotransferToDisabledCompTest.java fails linux-x64 Thanks Jay for review. I added it for safety but it seems it is not needed, only the 2nd one is needed. Test still pass with only the 2nd one...So, modified webrev http://cr.openjdk.java.net/~psadhukhan/8224821/webrev.1/ Regards Prasanta On 28-May-19 3:30 PM, Jayathirth D V wrote: > Hi Prasanta, > > We are already waiting for 2 secs in Util.focusComponent(), do we need the first delay of 2 secs just before that? > Second robot.delay() is okay. > > Thanks, > Jay > > -----Original Message----- > From: Prasanta Sadhukhan > Sent: Tuesday, May 28, 2019 2:47 PM > To: awt-dev at openjdk.java.net > Subject: Re: [13] RFR JDK-8224821: > java/awt/Focus/NoAutotransferToDisabledCompTest/NoAutotransferToDisabl > edCompTest.java fails linux-x64 > > PS: Modified test pass on windows,linux headful mach5 systems, on mac it is problemlisted already. > > Regards > Prasanta > > On 27-May-19 2:39 PM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a test fix for an issue where it seems focus does not >> transfer automatically in some case in our headful nightly system. >> Issue seems to be due to test expects focus to be shifted too soon >> which may not happen like that in somewhat slow system. So, added >> some delay which makes the test pass in the mach5 system >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224821 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8224821/webrev.0/ >> >> Regards >> Prasanta From andrewluotechnologies at outlook.com Tue May 28 20:52:33 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Tue, 28 May 2019 20:52:33 +0000 Subject: [PATCH] Fix some C++ conformance issues in AWT Windows code In-Reply-To: References: Message-ID: Adding an updated patch. It seems I missed a file. Testing done: compiled with both /permissive- set and without. Thanks, -Andrew From: awt-dev On Behalf Of Andrew Luo Sent: Monday, May 13, 2019 5:40 PM To: awt-dev at openjdk.java.net Subject: [PATCH] Fix some C++ conformance issues in AWT Windows code I've been trying to get the JDK to compile with the new /permissive- switch in VS2017 (https://devblogs.microsoft.com/cppblog/permissive-switch/) however there have been a few issues in various parts of the code. While testing this, I found some issues in the AWT code. In one case we name a function with the class:: prefix when the function is declared inline in the class definition. Other cases include where we are assigning string literals to non-const char* variables. I took some time to fix these and attached a patch. Let me know if there are any comments. c:\Users\Andrew\Documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt.h(343): error C2440: 'return': cannot convert from 'const unsigned short *' to 'LPWSTR' c:\Users\Andrew\Documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt.h(343): note: Conversion from string literal loses const qualifier (see /Zc:strictStrings) c:\users\andrew\documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt_Component.h(455): error C2061: syntax error: identifier 'javaKey' c:\users\andrew\documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt_Component.h(455): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int Thanks, -Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jdkcomformanceawt.txt URL: From Sergey.Bylokhov at oracle.com Tue May 28 21:04:05 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 28 May 2019 14:04:05 -0700 Subject: [PATCH] Fix some C++ conformance issues in AWT Windows code In-Reply-To: References: Message-ID: <0c2a51f3-1eb0-adc7-a1ce-3ff7a3f26910@oracle.com> Hi, Andrew. Thank you for the patch! We would be glad to accept patches from you. However, you will need to sign an OCA before we can do that: https://www.oracle.com/technetwork/community/oca-486395.html On 28/05/2019 13:52, Andrew Luo wrote: > Adding an updated patch.? It seems I missed a file. > > Testing done: compiled with both /permissive- set and without. > > Thanks, > > -Andrew > > *From:* awt-dev *On Behalf Of *Andrew Luo > *Sent:* Monday, May 13, 2019 5:40 PM > *To:* awt-dev at openjdk.java.net > *Subject:* [PATCH] Fix some C++ conformance issues in AWT Windows code > > I?ve been trying to get the JDK to compile with the new /permissive- switch in VS2017 (https://devblogs.microsoft.com/cppblog/permissive-switch/) however there have been a few issues in various parts of the code. > > While testing this, I found some issues in the AWT code.? In one case we name a function with the class:: prefix when the function is declared inline in the class definition.? Other cases include where we are assigning string literals to non-const char* variables.? I took some time to fix these and attached a patch.? Let me know if there are any comments. > > c:\Users\Andrew\Documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt.h(343): error C2440: 'return': cannot convert from 'const unsigned short *' to 'LPWSTR' > > c:\Users\Andrew\Documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt.h(343): note: Conversion from string literal loses const qualifier (see /Zc:strictStrings) > > c:\users\andrew\documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt_Component.h(455): error C2061: syntax error: identifier 'javaKey' > > c:\users\andrew\documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt_Component.h(455): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int > > Thanks, > > -Andrew > -- Best regards, Sergey. From philip.race at oracle.com Tue May 28 21:16:51 2019 From: philip.race at oracle.com (Philip Race) Date: Tue, 28 May 2019 14:16:51 -0700 Subject: [PATCH] Fix some C++ conformance issues in AWT Windows code In-Reply-To: <0c2a51f3-1eb0-adc7-a1ce-3ff7a3f26910@oracle.com> References: <0c2a51f3-1eb0-adc7-a1ce-3ff7a3f26910@oracle.com> Message-ID: <5CEDA543.9070705@oracle.com> Andrew's name is on the list already. -phil. On 5/28/19, 2:04 PM, Sergey Bylokhov wrote: > Hi, Andrew. > > Thank you for the patch! We would be glad to accept patches from you. > However, you will need to sign an OCA before we can do that: > https://www.oracle.com/technetwork/community/oca-486395.html > > On 28/05/2019 13:52, Andrew Luo wrote: >> Adding an updated patch. It seems I missed a file. >> >> Testing done: compiled with both /permissive- set and without. >> >> Thanks, >> >> -Andrew >> >> *From:* awt-dev *On Behalf Of >> *Andrew Luo >> *Sent:* Monday, May 13, 2019 5:40 PM >> *To:* awt-dev at openjdk.java.net >> *Subject:* [PATCH] Fix some C++ conformance issues in AWT >> Windows code >> >> I?ve been trying to get the JDK to compile with the new /permissive- >> switch in VS2017 >> (https://devblogs.microsoft.com/cppblog/permissive-switch/) however >> there have been a few issues in various parts of the code. >> >> While testing this, I found some issues in the AWT code. In one case >> we name a function with the class:: prefix when the function is >> declared inline in the class definition. Other cases include where >> we are assigning string literals to non-const char* variables. I >> took some time to fix these and attached a patch. Let me know if >> there are any comments. >> >> c:\Users\Andrew\Documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt.h(343): >> error C2440: 'return': cannot convert from 'const unsigned short *' >> to 'LPWSTR' >> >> c:\Users\Andrew\Documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt.h(343): >> note: Conversion from string literal loses const qualifier (see >> /Zc:strictStrings) >> >> c:\users\andrew\documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt_Component.h(455): >> error C2061: syntax error: identifier 'javaKey' >> >> c:\users\andrew\documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt_Component.h(455): >> error C4430: missing type specifier - int assumed. Note: C++ does not >> support default-int >> >> Thanks, >> >> -Andrew >> > > From philip.race at oracle.com Wed May 29 02:07:32 2019 From: philip.race at oracle.com (Philip Race) Date: Tue, 28 May 2019 19:07:32 -0700 Subject: [PATCH] Fix some C++ conformance issues in AWT Windows code In-Reply-To: <5CEDA543.9070705@oracle.com> References: <0c2a51f3-1eb0-adc7-a1ce-3ff7a3f26910@oracle.com> <5CEDA543.9070705@oracle.com> Message-ID: <5CEDE964.4060204@oracle.com> PS the changes look fine to me. -phil On 5/28/19, 2:16 PM, Philip Race wrote: > Andrew's name is on the list already. > > -phil. > > On 5/28/19, 2:04 PM, Sergey Bylokhov wrote: >> Hi, Andrew. >> >> Thank you for the patch! We would be glad to accept patches from you. >> However, you will need to sign an OCA before we can do that: >> https://www.oracle.com/technetwork/community/oca-486395.html >> >> On 28/05/2019 13:52, Andrew Luo wrote: >>> Adding an updated patch. It seems I missed a file. >>> >>> Testing done: compiled with both /permissive- set and without. >>> >>> Thanks, >>> >>> -Andrew >>> >>> *From:* awt-dev *On Behalf Of >>> *Andrew Luo >>> *Sent:* Monday, May 13, 2019 5:40 PM >>> *To:* awt-dev at openjdk.java.net >>> *Subject:* [PATCH] Fix some C++ conformance issues in AWT >>> Windows code >>> >>> I?ve been trying to get the JDK to compile with the new /permissive- >>> switch in VS2017 >>> (https://devblogs.microsoft.com/cppblog/permissive-switch/) however >>> there have been a few issues in various parts of the code. >>> >>> While testing this, I found some issues in the AWT code. In one >>> case we name a function with the class:: prefix when the function is >>> declared inline in the class definition. Other cases include where >>> we are assigning string literals to non-const char* variables. I >>> took some time to fix these and attached a patch. Let me know if >>> there are any comments. >>> >>> c:\Users\Andrew\Documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt.h(343): >>> error C2440: 'return': cannot convert from 'const unsigned short *' >>> to 'LPWSTR' >>> >>> c:\Users\Andrew\Documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt.h(343): >>> note: Conversion from string literal loses const qualifier (see >>> /Zc:strictStrings) >>> >>> c:\users\andrew\documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt_Component.h(455): >>> error C2061: syntax error: identifier 'javaKey' >>> >>> c:\users\andrew\documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt_Component.h(455): >>> error C4430: missing type specifier - int assumed. Note: C++ does >>> not support default-int >>> >>> Thanks, >>> >>> -Andrew >>> >> >> From philip.race at oracle.com Wed May 29 18:38:17 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 29 May 2019 11:38:17 -0700 Subject: RFR: 8223271: SplashScreen is still shown if defaulting to headless on MacOS In-Reply-To: References: Message-ID: <22ee90fd-4775-b107-a28b-0c70052b4f7c@oracle.com> Any takers ? -phil. On 5/24/19 9:35 AM, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8223271 > Webrev : http://cr.openjdk.java.net/~prr/8223271/ > > Whilst working on removing some inappropriate coupling of the java > launcher and the desktop module, > and testing out the -splash option, I noticed that on MacOS, in the > case when we *default* to headless > mode (which happens when we determine that we are not in a desktop > session), the launcher still > invokes the splash screen code. This could cause an application to > completely hang. > > The problem is explained in detail in the bug report, but briefly, the > launcher isn't aware of this > defaulting to headless. And the calls the launcher makes to the > dynamically loaded splashscreen > code, don't return any value it can use to be aware of this. > > So this fix updates "DoSplashInit()" to return such a code, and in the > event of a headful session > not being available, it can bail out and not try to show the splashscreen. > That is the gist of the small set of changes in java.c that relate to > this fix. > > However I also observed a small memory leak. > There are static variables > > static char* splash_jar_entry = NULL; static char* splash_file_entry = > NULL; > which are meant to hold the location of the splash image. > When everything is done the malloced storage these point to is freed ... > except that the malloc code looks like this :- > > char* splash_file_entry = JLI_MemAlloc(JLI_StrLen(SPLASH_FILE_ENV_ENTRY "=")+JLI_StrLen(splash_file_name)+1); > char* splash_jar_entry = JLI_MemAlloc(JLI_StrLen(SPLASH_JAR_ENV_ENTRY "=")+JLI_StrLen(splash_jar_name)+1); > > So the static vars are never used and the storage pointed to by local > variables is never freed. > > So I am fixing that too. > > The rest of the fix is in the splashscreen code in the desktop module > and it implements > the return of the status code described above. > > There was one leak there too - a stream was not closed in a case where > the splash could > not be displayed. > > The regression tests for splash screen were run, but testing this is > more an environmental issue - > sshing into a MacOS system and running tests and demos which would try > to display a splash > and verifying they no longer do, so I didn't see a way to add a > specific regression test. > > -phil. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Wed May 29 18:52:26 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 29 May 2019 11:52:26 -0700 Subject: RFR: 8223271: SplashScreen is still shown if defaulting to headless on MacOS In-Reply-To: <22ee90fd-4775-b107-a28b-0c70052b4f7c@oracle.com> References: <22ee90fd-4775-b107-a28b-0c70052b4f7c@oracle.com> Message-ID: <2f87c7f8-e9a6-baaf-55be-c681a52bebe2@oracle.com> Looks good to me (note that I am not a "R"eviewer). -- Kevin On 5/29/2019 11:38 AM, Phil Race wrote: > Any takers ? > > -phil. > > On 5/24/19 9:35 AM, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223271 >> Webrev : http://cr.openjdk.java.net/~prr/8223271/ >> >> Whilst working on removing some inappropriate coupling of the java >> launcher and the desktop module, >> and testing out the -splash option, I noticed that on MacOS, in the >> case when we *default* to headless >> mode (which happens when we determine that we are not in a desktop >> session), the launcher still >> invokes the splash screen code. This could cause an application to >> completely hang. >> >> The problem is explained in detail in the bug report, but briefly, >> the launcher isn't aware of this >> defaulting to headless. And the calls the launcher makes to the >> dynamically loaded splashscreen >> code, don't return any value it can use to be aware of this. >> >> So this fix updates "DoSplashInit()" to return such a code, and in >> the event of a headful session >> not being available, it can bail out and not try to show the >> splashscreen. >> That is the gist of the small set of changes in java.c that relate to >> this fix. >> >> However I also observed a small memory leak. >> There are static variables >> >> static char* splash_jar_entry = NULL; static char* splash_file_entry >> = NULL; >> which are meant to hold the location of the splash image. >> When everything is done the malloced storage these point to is freed ... >> except that the malloc code looks like this :- >> >> char* splash_file_entry = >> JLI_MemAlloc(JLI_StrLen(SPLASH_FILE_ENV_ENTRY >> "=")+JLI_StrLen(splash_file_name)+1); >> char* splash_jar_entry = JLI_MemAlloc(JLI_StrLen(SPLASH_JAR_ENV_ENTRY >> "=")+JLI_StrLen(splash_jar_name)+1); >> >> So the static vars are never used and the storage pointed to by local >> variables is never freed. >> >> So I am fixing that too. >> >> The rest of the fix is in the splashscreen code in the desktop module >> and it implements >> the return of the status code described above. >> >> There was one leak there too - a stream was not closed in a case >> where the splash could >> not be displayed. >> >> The regression tests for splash screen were run, but testing this is >> more an environmental issue - >> sshing into a MacOS system and running tests and demos which would >> try to display a splash >> and verifying they no longer do, so I didn't see a way to add a >> specific regression test. >> >> -phil. >> >> >> >> >> > From brian.burkhalter at oracle.com Wed May 29 18:55:03 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 29 May 2019 11:55:03 -0700 Subject: RFR: 8223271: SplashScreen is still shown if defaulting to headless on MacOS In-Reply-To: <2f87c7f8-e9a6-baaf-55be-c681a52bebe2@oracle.com> References: <22ee90fd-4775-b107-a28b-0c70052b4f7c@oracle.com> <2f87c7f8-e9a6-baaf-55be-c681a52bebe2@oracle.com> Message-ID: Likewise, but I am. +1 Brian > On May 29, 2019, at 11:52 AM, Kevin Rushforth wrote: > > Looks good to me (note that I am not a "R"eviewer). -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed May 29 22:22:17 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 29 May 2019 15:22:17 -0700 Subject: RFR: 8223271: SplashScreen is still shown if defaulting to headless on MacOS In-Reply-To: <22ee90fd-4775-b107-a28b-0c70052b4f7c@oracle.com> References: <22ee90fd-4775-b107-a28b-0c70052b4f7c@oracle.com> Message-ID: Looks fine. On 29/05/2019 11:38, Phil Race wrote: > Any takers ? > > -phil. > > On 5/24/19 9:35 AM, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223271 >> Webrev : http://cr.openjdk.java.net/~prr/8223271/ >> >> Whilst working on removing some inappropriate coupling of the java launcher and the desktop module, >> and testing out the -splash option, I noticed that on MacOS, in the case when we *default* to headless >> mode (which happens when we determine that we are not in a desktop session), the launcher still >> invokes the splash screen code. This could cause an application to completely hang. >> >> The problem is explained in detail in the bug report, but briefly, the launcher isn't aware of this >> defaulting to headless. And the calls the launcher makes to the dynamically loaded splashscreen >> code, don't return any value it can use to be aware of this. >> >> So this fix updates "DoSplashInit()" to return such a code, and in the event of a headful session >> not being available, it can bail out and not try to show the splashscreen. >> That is the gist of the small set of changes in java.c that relate to this fix. >> >> However I also observed a small memory leak. >> There are static variables >> >> static char* splash_jar_entry = NULL; static char* splash_file_entry = NULL; >> which are meant to hold the location of the splash image. >> When everything is done the malloced storage these point to is freed ... >> except that the malloc code looks like this :- >> >> char* splash_file_entry = JLI_MemAlloc(JLI_StrLen(SPLASH_FILE_ENV_ENTRY "=")+JLI_StrLen(splash_file_name)+1); >> char* splash_jar_entry = JLI_MemAlloc(JLI_StrLen(SPLASH_JAR_ENV_ENTRY "=")+JLI_StrLen(splash_jar_name)+1); >> >> So the static vars are never used and the storage pointed to by local variables is never freed. >> >> So I am fixing that too. >> >> The rest of the fix is in the splashscreen code in the desktop module and it implements >> the return of the status code described above. >> >> There was one leak there too - a stream was not closed in a case where the splash could >> not be displayed. >> >> The regression tests for splash screen were run, but testing this is more an environmental issue - >> sshing into a MacOS system and running tests and demos which would try to display a splash >> and verifying they no longer do, so I didn't see a way to add a specific regression test. >> >> -phil. >> >> >> >> >> > -- Best regards, Sergey. From andrewluotechnologies at outlook.com Wed May 29 23:57:40 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Wed, 29 May 2019 23:57:40 +0000 Subject: [PATCH] Fix some C++ conformance issues in AWT Windows code In-Reply-To: <5CEDE964.4060204@oracle.com> References: <0c2a51f3-1eb0-adc7-a1ce-3ff7a3f26910@oracle.com> <5CEDA543.9070705@oracle.com> <5CEDE964.4060204@oracle.com> Message-ID: Thanks for taking a look. Yep, I can confirm that the name on the list is indeed me (and not someone else with the same name). I have contributed to OpenJDK before, just not in this mailing list/group. Thanks, -Andrew -----Original Message----- From: awt-dev On Behalf Of Philip Race Sent: Tuesday, May 28, 2019 7:08 PM To: Sergey Bylokhov Cc: awt-dev at openjdk.java.net Subject: Re: [PATCH] Fix some C++ conformance issues in AWT Windows code PS the changes look fine to me. -phil On 5/28/19, 2:16 PM, Philip Race wrote: > Andrew's name is on the list already. > > -phil. > > On 5/28/19, 2:04 PM, Sergey Bylokhov wrote: >> Hi, Andrew. >> >> Thank you for the patch! We would be glad to accept patches from you. >> However, you will need to sign an OCA before we can do that: >> https://www.oracle.com/technetwork/community/oca-486395.html >> >> On 28/05/2019 13:52, Andrew Luo wrote: >>> Adding an updated patch. It seems I missed a file. >>> >>> Testing done: compiled with both /permissive- set and without. >>> >>> Thanks, >>> >>> -Andrew >>> >>> *From:* awt-dev *On Behalf Of >>> *Andrew Luo >>> *Sent:* Monday, May 13, 2019 5:40 PM >>> *To:* awt-dev at openjdk.java.net >>> *Subject:* [PATCH] Fix some C++ conformance issues in AWT >>> Windows code >>> >>> I've been trying to get the JDK to compile with the new /permissive- >>> switch in VS2017 >>> (https://devblogs.microsoft.com/cppblog/permissive-switch/) however >>> there have been a few issues in various parts of the code. >>> >>> While testing this, I found some issues in the AWT code. In one >>> case we name a function with the class:: prefix when the function is >>> declared inline in the class definition. Other cases include where >>> we are assigning string literals to non-const char* variables. I >>> took some time to fix these and attached a patch. Let me know if >>> there are any comments. >>> >>> c:\Users\Andrew\Documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt.h(343): >>> error C2440: 'return': cannot convert from 'const unsigned short *' >>> to 'LPWSTR' >>> >>> c:\Users\Andrew\Documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt.h(343): >>> note: Conversion from string literal loses const qualifier (see >>> /Zc:strictStrings) >>> >>> c:\users\andrew\documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt_Component.h(455): >>> error C2061: syntax error: identifier 'javaKey' >>> >>> c:\users\andrew\documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt_Component.h(455): >>> error C4430: missing type specifier - int assumed. Note: C++ does >>> not support default-int >>> >>> Thanks, >>> >>> -Andrew >>> >> >> From Sergey.Bylokhov at oracle.com Thu May 30 03:13:55 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 29 May 2019 20:13:55 -0700 Subject: [PATCH] Fix some C++ conformance issues in AWT Windows code In-Reply-To: References: <0c2a51f3-1eb0-adc7-a1ce-3ff7a3f26910@oracle.com> <5CEDA543.9070705@oracle.com> <5CEDE964.4060204@oracle.com> Message-ID: <84c26fdd-cd44-3160-bcbc-a37ceba3c3d0@oracle.com> On 29/05/2019 16:57, Andrew Luo wrote: > Yep, I can confirm that the name on the list is indeed me (and not someone else with the same name). I have contributed to OpenJDK before, just not in this mailing list/group. Thank you for the confirmation, I have created the bug/webrev: https://bugs.openjdk.java.net/browse/JDK-8225032 http://cr.openjdk.java.net/~serb/andrew_Luo/8225032/webrev.00 I'll sponsor the fix if there are no objections. > > Thanks, > > -Andrew > > -----Original Message----- > From: awt-dev On Behalf Of Philip Race > Sent: Tuesday, May 28, 2019 7:08 PM > To: Sergey Bylokhov > Cc: awt-dev at openjdk.java.net > Subject: Re: [PATCH] Fix some C++ conformance issues in AWT Windows code > > PS the changes look fine to me. > > -phil > > On 5/28/19, 2:16 PM, Philip Race wrote: >> Andrew's name is on the list already. >> >> -phil. >> >> On 5/28/19, 2:04 PM, Sergey Bylokhov wrote: >>> Hi, Andrew. >>> >>> Thank you for the patch! We would be glad to accept patches from you. >>> However, you will need to sign an OCA before we can do that: >>> https://www.oracle.com/technetwork/community/oca-486395.html >>> >>> On 28/05/2019 13:52, Andrew Luo wrote: >>>> Adding an updated patch. It seems I missed a file. >>>> >>>> Testing done: compiled with both /permissive- set and without. >>>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> *From:* awt-dev *On Behalf Of >>>> *Andrew Luo >>>> *Sent:* Monday, May 13, 2019 5:40 PM >>>> *To:* awt-dev at openjdk.java.net >>>> *Subject:* [PATCH] Fix some C++ conformance issues in AWT >>>> Windows code >>>> >>>> I've been trying to get the JDK to compile with the new /permissive- >>>> switch in VS2017 >>>> (https://devblogs.microsoft.com/cppblog/permissive-switch/) however >>>> there have been a few issues in various parts of the code. >>>> >>>> While testing this, I found some issues in the AWT code. In one >>>> case we name a function with the class:: prefix when the function is >>>> declared inline in the class definition. Other cases include where >>>> we are assigning string literals to non-const char* variables. I >>>> took some time to fix these and attached a patch. Let me know if >>>> there are any comments. >>>> >>>> c:\Users\Andrew\Documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt.h(343): >>>> error C2440: 'return': cannot convert from 'const unsigned short *' >>>> to 'LPWSTR' >>>> >>>> c:\Users\Andrew\Documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt.h(343): >>>> note: Conversion from string literal loses const qualifier (see >>>> /Zc:strictStrings) >>>> >>>> c:\users\andrew\documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt_Component.h(455): >>>> error C2061: syntax error: identifier 'javaKey' >>>> >>>> c:\users\andrew\documents\mercurial\openjdk\jdk\src\java.desktop\windows\native\libawt\windows\awt_Component.h(455): >>>> error C4430: missing type specifier - int assumed. Note: C++ does >>>> not support default-int >>>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>> >>> -- Best regards, Sergey. From jayathirth.d.v at oracle.com Fri May 31 08:51:57 2019 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 31 May 2019 01:51:57 -0700 (PDT) Subject: RFR: 8225105: java/awt/Focus/ShowFrameCheckForegroundTest/ShowFrameCheckForegroundTest.java fails in Windows 10 Message-ID: <10341a0d-8e83-4051-aa08-f2678fc5ce79@default> Hello All, Please review the following fix in JDK 13: Bug : https://bugs.openjdk.java.net/browse/JDK-8225105 Webrev : http://cr.openjdk.java.net/~jdv/8225105/webrev.00/ Cause : As test hits stage 2, if required component is not present in the foreground it fails. Looks like in slower systems this happens frequently and test fails. Solution : Stabilize the test case to add proper wait conditions so that all components are visible as per test requirement. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri May 31 12:35:28 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 31 May 2019 05:35:28 -0700 Subject: RFR: 8225105: java/awt/Focus/ShowFrameCheckForegroundTest/ShowFrameCheckForegroundTest.java fails in Windows 10 In-Reply-To: <10341a0d-8e83-4051-aa08-f2678fc5ce79@default> References: <10341a0d-8e83-4051-aa08-f2678fc5ce79@default> Message-ID: <5CF11F90.7040709@oracle.com> +1. This test seems to fail repeatedly on our slower test system. -phil On 5/31/19, 1:51 AM, Jayathirth D V wrote: > > Hello All, > > Please review the following fix in JDK 13: > > Bug : https://bugs.openjdk.java.net/browse/JDK-8225105 > > Webrev : http://cr.openjdk.java.net/~jdv/8225105/webrev.00/ > > > Cause : As test hits stage 2, if required component is not present in > the foreground it fails. Looks like in slower systems this happens > frequently and test fails. > > Solution : Stabilize the test case to add proper wait conditions so > that all components are visible as per test requirement. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.tarasov at jetbrains.com Fri May 31 16:11:46 2019 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Fri, 31 May 2019 19:11:46 +0300 Subject: [13] Review Request: 8225118 Robot.createScreenCapture() returns black image on HiDPI linux with gtk3 Message-ID: Hi All! Please review the fix for JDK 13: Bug: https://bugs.openjdk.java.net/browse/JDK-8225118 Fix: http://cr.openjdk.java.net/~ant/JDK-8225118/webrev.0 The problem with Robot.createScreenCapture() on gtk3 is in the following function call (quoting from gtk3_interface.h): fp_gdk_pixbuf_get_from_drawable = dl_symbol("gdk_pixbuf_get_from_window") which, as you can see, is resolved to another function in gtk3 (unlike gtk2) due to its deprecation. The spec [1] states that the passed size is scaled: "the width and height arguments scaled by the scale factor of window" however this fact is not taken into account and so the returned pixbuf has wrong size and is then ignored. To meet the spec, I retrieve the root window scale and downscale the size, ceiling the result. Also, I weaken the condition where the pixbuf size is compared to the passed size, from "==" to ">=". My reasoning is this: 1) The original passed size (of the screen) may appear to be lossy due to downscaling/upscaling ops. 2) The weakened condition is enough for the valid pixbuf copying. The test (which I've modified to allow its run on Linux) reproduces the issue. With regards, Anton. [1] https://developer.gnome.org/gdk3/stable/gdk3-Pixbufs.html#gdk-pixbuf-get-from-window -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri May 31 20:57:27 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 31 May 2019 13:57:27 -0700 Subject: RFR: 8225105: java/awt/Focus/ShowFrameCheckForegroundTest/ShowFrameCheckForegroundTest.java fails in Windows 10 In-Reply-To: <10341a0d-8e83-4051-aa08-f2678fc5ce79@default> References: <10341a0d-8e83-4051-aa08-f2678fc5ce79@default> Message-ID: <408b2903-3d66-cc65-e1a3-4f288ead7255@oracle.com> Hi, Jay. Looks fine, please confirm that this test is green in mach5 after this fix. On 31/05/2019 01:51, Jayathirth D V wrote: > Hello All, > > Please review the following fix in JDK 13: > > Bug : https://bugs.openjdk.java.net/browse/JDK-8225105 > > Webrev : http://cr.openjdk.java.net/~jdv/8225105/webrev.00/ > > Cause : As test hits stage 2, if required component is not present in the foreground it fails. Looks like in slower systems this happens frequently and test fails. > > Solution : Stabilize the test case to add proper wait conditions so that all components are visible as per test requirement. > > Thanks, > > Jay > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri May 31 21:58:00 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 31 May 2019 14:58:00 -0700 Subject: [13] Review Request: 8225118 Robot.createScreenCapture() returns black image on HiDPI linux with gtk3 In-Reply-To: References: Message-ID: <58b5ff15-4172-e7f4-ff55-d32a85101411@oracle.com> Hi, Anton. The fix looks fine, thank you for contribution. I guess at some point we need to cleanup this logic, currently on macOS and now on linux-gtk3 we scale the coordinates from the users space to device space in the shared code and then scale them back in the peer... On 31/05/2019 09:11, Anton Tarasov wrote: > Hi All! > > Please review the fix for JDK 13: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8225118 > Fix: http://cr.openjdk.java.net/~ant/JDK-8225118/webrev.0 > > The problem with Robot.createScreenCapture() on gtk3 is in the following function call (quoting from gtk3_interface.h): > fp_gdk_pixbuf_get_from_drawable = dl_symbol("gdk_pixbuf_get_from_window") > which, as you can see, is resolved to another function in gtk3 (unlike gtk2) due to its deprecation. > > The spec [1] states that the passed size is scaled: > "the width and height arguments scaled by the scale factor of window" > however this fact is not taken into account and so the returned pixbuf has wrong size and is then ignored. > > To meet the spec, I retrieve the root window scale and downscale the size, ceiling the result. Also, I weaken the condition where the pixbuf size is compared to the passed size, from "==" to ">=". My reasoning is this: > 1) The original passed size (of the screen) may appear to be lossy due to downscaling/upscaling ops. > 2) The weakened condition is enough for the valid pixbuf copying. > > The test (which I've modified to allow its run on Linux) reproduces the issue. > > With regards, > Anton. > /||/ > /| > |/[1] https://developer.gnome.org/gdk3/stable/gdk3-Pixbufs.html#gdk-pixbuf-get-from-window > -- Best regards, Sergey. From zgu at redhat.com Tue May 28 13:03:57 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 May 2019 09:03:57 -0400 Subject: [8u] RFR 8153732: Windows remote printer changes do not reflect in lookupPrintServices() In-Reply-To: <05c526b3-6ee8-d1d5-a13a-264248701713@redhat.com> References: <5779fda6-fc2f-40c3-f81a-f5f48803fc46@redhat.com> <05c526b3-6ee8-d1d5-a13a-264248701713@redhat.com> Message-ID: Hi, Could you please review this 8u backport? After JDK-8055705 backport, the original patch still does not apply cleanly, due to missing following Thread API in JDK8u. public Thread?(ThreadGroup group, Runnable target, String name, long stackSize, boolean inheritThreadLocals) The original patch has inheritThreadLocals = false, but replacement API public Thread?(ThreadGroup group, Runnable target, String name, long stackSize) has it default to true. Could AWT folks take a look? JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8153732 Original patch: http://hg.openjdk.java.net/jdk/client/rev/732a3b600098 8u Backport: http://cr.openjdk.java.net/~zgu/JDK-8153732_8u/webrev.01/ Test: manual test: RemotePrinterStatusRefresh Thanks, -Zhengyu Thanks, -Zhengyu