From manajit.halder at oracle.com Thu May 3 11:11:49 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Thu, 3 May 2018 16:41:49 +0530 Subject: [11] Review request for JDK-8029250: [macosx] There is no tray icon shown in the system tray area when case starts In-Reply-To: <4919F580-0B5F-46D6-8528-A79E841E9103@oracle.com> References: <4919F580-0B5F-46D6-8528-A79E841E9103@oracle.com> Message-ID: Hi Sergey, Please review the updated webrev. http://cr.openjdk.java.net/~mhalder/8029250/webrev.01/ The modified test case moved to closed test as it contains images with unknown source. Regards, Manajit > On 27-Apr-2018, at 4:06 PM, Manajit Halder wrote: > > Hi All, > > Kindly review the following AWT enhancement changes: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8029250 > Webrev: http://cr.openjdk.java.net/~mhalder/8029250/webrev.00/ > > Fix: > Added support for gif images (image animation) for Mac system tray. Before fix only single frame was passed to Mac OS system tray on mouse click from the Java side. > After fix all the frames are passed at the time interval set in the image one by one to the Mac OS side. > > Note: > The test was moved from closed test to open test along with 3 images: ball.gif, spot.gif and duke.gif. The test code was rewritten dropping the applet code used earlier. > > Regards, > Manajit > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Thu May 3 11:33:26 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 03 May 2018 13:33:26 +0200 Subject: [8u] RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols Message-ID: <1525347206.4079.19.camel@redhat.com> Hi, Could I please get a review of this change for JDK 8u? We are seing build failures due to unresolved symbols when building libfontmanager.so. The build flag to trigger this is to configure with: --with-extra-ldflags="-Wl,-z,defs" Attempting a build of JDK 8 with this fails. This has been fixed in JDK 11 and hasn't shown any issues so far. Due to the change in the build system the JDK 11 patch does not apply cleanly after path unshuffeling (different context it seems). Hence, asking here for a review before asking for JDK 8 backport approval. Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.jdk8/ Review thread for JDK 11: http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021575.html Thanks, Severin From magnus.ihse.bursie at oracle.com Thu May 3 12:31:15 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 3 May 2018 14:31:15 +0200 Subject: [8u] RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: <1525347206.4079.19.camel@redhat.com> References: <1525347206.4079.19.camel@redhat.com> Message-ID: <29bfd9cf-5019-d1d5-4437-301dcb8ab64b@oracle.com> On 2018-05-03 13:33, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this change for JDK 8u? We are seing > build failures due to unresolved symbols when building > libfontmanager.so. The build flag to trigger this is to configure with: > > --with-extra-ldflags="-Wl,-z,defs" > > Attempting a build of JDK 8 with this fails. This has been fixed in JDK > 11 and hasn't shown any issues so far. Due to the change in the build > system the JDK 11 patch does not apply cleanly after path unshuffeling > (different context it seems). Hence, asking here for a review before > asking for JDK 8 backport approval. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.jdk8/ Looks good to me. /Magnus > > Review thread for JDK 11: > http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021575.html > > Thanks, > Severin From dipak.kumar at oracle.com Thu May 3 14:58:57 2018 From: dipak.kumar at oracle.com (Dipak Kumar) Date: Thu, 3 May 2018 07:58:57 -0700 (PDT) Subject: [8u] Review request for 8202478 : Backout JDK-8152974 Message-ID: <08fd9490-4dd7-4216-8022-cc05fcd3f102@default> Hi, Please review the below patch (for JDK 8u-dev) - Webrev : http://cr.openjdk.java.net/~dkumar/8202478/webrev.00/ JBS : https://bugs.openjdk.java.net/browse/JDK-8202478 Fix for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8152974"JDK-8152974 has caused a regression. Above patch is for backing out this changeset. Thanks, Dipak -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Thu May 3 17:06:53 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 3 May 2018 10:06:53 -0700 Subject: [8u] RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: <1525347206.4079.19.camel@redhat.com> References: <1525347206.4079.19.camel@redhat.com> Message-ID: Looks good. /Erik On 2018-05-03 04:33, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this change for JDK 8u? We are seing > build failures due to unresolved symbols when building > libfontmanager.so. The build flag to trigger this is to configure with: > > --with-extra-ldflags="-Wl,-z,defs" > > Attempting a build of JDK 8 with this fails. This has been fixed in JDK > 11 and hasn't shown any issues so far. Due to the change in the build > system the JDK 11 patch does not apply cleanly after path unshuffeling > (different context it seems). Hence, asking here for a review before > asking for JDK 8 backport approval. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.jdk8/ > > Review thread for JDK 11: > http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021575.html > > Thanks, > Severin From Sergey.Bylokhov at oracle.com Thu May 3 18:54:03 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 3 May 2018 11:54:03 -0700 Subject: [8u] Review request for 8202478 : Backout JDK-8152974 In-Reply-To: <08fd9490-4dd7-4216-8022-cc05fcd3f102@default> References: <08fd9490-4dd7-4216-8022-cc05fcd3f102@default> Message-ID: <4b2168c6-b91a-b51b-fae7-6b971416e8c8@oracle.com> +1 On 03/05/2018 07:58, Dipak Kumar wrote: > Hi, > > Please review the below patch (for JDK 8u-dev) - > > Webrev : http://cr.openjdk.java.net/~dkumar/8202478/webrev.00/ > > JBS : https://bugs.openjdk.java.net/browse/JDK-8202478 > > Fix for JDK-8152974 > has caused a regression. Above patch is for backing out this changeset. > > Thanks, > > Dipak > -- Best regards, Sergey. From philip.race at oracle.com Thu May 3 19:01:56 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 3 May 2018 12:01:56 -0700 Subject: [8u] Review request for 8202478 : Backout JDK-8152974 In-Reply-To: <4b2168c6-b91a-b51b-fae7-6b971416e8c8@oracle.com> References: <08fd9490-4dd7-4216-8022-cc05fcd3f102@default> <4b2168c6-b91a-b51b-fae7-6b971416e8c8@oracle.com> Message-ID: <8b7e59d2-a1f9-4aa8-2908-40a48e207a1a@oracle.com> +1. -phil. On 05/03/2018 11:54 AM, Sergey Bylokhov wrote: > +1 > > On 03/05/2018 07:58, Dipak Kumar wrote: >> Hi, >> >> Please review the below patch (for JDK 8u-dev) - >> >> Webrev : http://cr.openjdk.java.net/~dkumar/8202478/webrev.00/ >> >> JBS : https://bugs.openjdk.java.net/browse/JDK-8202478 >> >> Fix for JDK-8152974 >> has caused a >> regression. Above patch is for backing out this changeset. >> >> Thanks, >> >> Dipak >> > > From christoph.langer at sap.com Fri May 4 14:07:00 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 4 May 2018 14:07:00 +0000 Subject: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) Message-ID: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> Hi, please help reviewing the contribution of the support for the AIX Input Method Editor (IME) in AWT's Input Method Framework. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8201429 I took Ichiroh's initial proposal [1] and tried to integrate it better with existing code. I have split src/java.desktop/unix/classes/sun/awt/X11InputMethod.java into a) a base class containing the common code: src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java b) a specific class for the common Linux/Unixes: src/java.desktop/unix/classes/sun/awt/X11InputMethod.java and c) a specific class for AIX: src/java.desktop/aix/classes/sun/awt/X11InputMethod.java The AIX specific additions to the native code of src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c were so much that I decided to add a specific implementation file for AIX: src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod_aix.c. The changes to the former file are some cleanups. I'm still in the process of testing the changes - but maybe you can run further tests, especially on non-AIX unixes to make sure we didn't break something. Thanks & Best regards Christoph [1]: http://mail.openjdk.java.net/pipermail/awt-dev/2018-April/013869.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Fri May 4 15:44:47 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 May 2018 08:44:47 -0700 Subject: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) In-Reply-To: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> References: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> Message-ID: <0cf8df6f-d5ad-9db2-8381-ccca9eaf6a5f@oracle.com> Hello, It looks like what you are trying to achieve is to override awt_InputMethod.c with an OS specific version of that file. We have a construct for this in SetupNativeCompilation that should handle it automatically, if you just list the source dirs in priority order. I would suggest leveraging this by making this change instead: First in the list of LIBAWT_XAWT_DIRS (line 272), prepend a line like this: $(wildcard $(TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS)/native/libawt_xawt) \ /Erik On 2018-05-04 07:07, Langer, Christoph wrote: > Hi, > > please help reviewing the contribution of the support for the AIX Input Method Editor (IME) in AWT's Input Method Framework. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.1/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8201429 > > I took Ichiroh's initial proposal [1] and tried to integrate it better with existing code. I have split src/java.desktop/unix/classes/sun/awt/X11InputMethod.java into > a) a base class containing the common code: src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java > b) a specific class for the common Linux/Unixes: src/java.desktop/unix/classes/sun/awt/X11InputMethod.java and > c) a specific class for AIX: src/java.desktop/aix/classes/sun/awt/X11InputMethod.java > > The AIX specific additions to the native code of src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c were so much that I decided to add a specific implementation file for AIX: src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod_aix.c. The changes to the former file are some cleanups. > > I'm still in the process of testing the changes - but maybe you can run further tests, especially on non-AIX unixes to make sure we didn't break something. > > Thanks & Best regards > Christoph > > [1]: http://mail.openjdk.java.net/pipermail/awt-dev/2018-April/013869.html > From philip.race at oracle.com Fri May 4 23:27:21 2018 From: philip.race at oracle.com (Philip Race) Date: Fri, 04 May 2018 16:27:21 -0700 Subject: RFR: 8202679 : Updates on windows failures in the problem list Message-ID: <5AECEC59.1040008@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8202679 webrev: http://cr.openjdk.java.net/~prr/8202679/ The additions comprise : 4 new bugs were filed for consistent failures A couple of bugs were not included for existing open bugs The modifications are Extending some tests to be generic-all Fixing the path for a couple of bugs. -phil. From Sergey.Bylokhov at oracle.com Fri May 4 23:35:24 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 4 May 2018 16:35:24 -0700 Subject: RFR: 8202679 : Updates on windows failures in the problem list In-Reply-To: <5AECEC59.1040008@oracle.com> References: <5AECEC59.1040008@oracle.com> Message-ID: <37e19d74-e821-704f-35bd-8d2da3c11c85@oracle.com> Looks fine. On 04/05/2018 16:27, Philip Race wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8202679 > webrev: http://cr.openjdk.java.net/~prr/8202679/ > > The additions comprise : > 4 new bugs were filed for consistent failures > A couple of bugs were not included for existing open bugs > > The modifications are > Extending some tests to be generic-all > Fixing the path for a couple of bugs. > > -phil. -- Best regards, Sergey. From prem.balakrishnan at oracle.com Mon May 7 09:33:57 2018 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Mon, 7 May 2018 02:33:57 -0700 (PDT) Subject: [11] Review Request JDK-8196360 java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java fails Message-ID: <4f6d2926-57aa-4141-8564-200138df1cf3@default> Hi All, Please review fix for JDK 11: Bug: https://bugs.openjdk.java.net/browse/JDK-8196360 Webrev: http://cr.openjdk.java.net/~pkbalakr/8196360/webrev00/ On Mac , slight variation in the RGB value caused the test to fail only on OS X 10.12.6 ( On OS X 10.13.1 test passes always). Fixed this issue by comparing two colors with a minimum tolerance value. On Windows 10, test was fetching pixel color even before the UI is rendered completely causing the test to fail. Adding a delay solved this issue. Tested on Windows 7 & 10, Ubuntu 17.10, Mac OS X 10.12.6 and 10.13.1. Regards, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon May 7 19:24:03 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 7 May 2018 12:24:03 -0700 Subject: [11] Review Request JDK-8196360 java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java fails In-Reply-To: <4f6d2926-57aa-4141-8564-200138df1cf3@default> References: <4f6d2926-57aa-4141-8564-200138df1cf3@default> Message-ID: <613d1858-7be6-0df3-33e8-08faf4c73419@oracle.com> Hi, Prem. Did you check why the rong value is returned by the Robot? Maybe some of "window decoration" are different in osx 10.12(shadows/title/etc)? On 07/05/2018 02:33, Prem Balakrishnan wrote: > Please review fix for JDK 11: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196360 > > Webrev: http://cr.openjdk.java.net/~pkbalakr/8196360/webrev00/ > > On Mac , slight variation in the RGB value caused the test to fail ?only > on OS X 10.12.6 ( On OS X 10.13.1 test passes always). -- Best regards, Sergey. From christoph.langer at sap.com Tue May 8 09:54:10 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 8 May 2018 09:54:10 +0000 Subject: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) In-Reply-To: <0cf8df6f-d5ad-9db2-8381-ccca9eaf6a5f@oracle.com> References: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> <0cf8df6f-d5ad-9db2-8381-ccca9eaf6a5f@oracle.com> Message-ID: Hi Eric, thanks for that excellent suggestion. I already thought there should be some means to do that but was not aware of how that could be accomplished. I updated the webrev in place. Thanks Christoph > -----Original Message----- > From: Erik Joelsson [mailto:erik.joelsson at oracle.com] > Sent: Freitag, 4. Mai 2018 17:45 > To: Langer, Christoph ; awt- > dev at openjdk.java.net > Cc: build-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT > Input Method Framework (IMF) > > Hello, > > It looks like what you are trying to achieve is to override > awt_InputMethod.c with an OS specific version of that file. We have a > construct for this in SetupNativeCompilation that should handle it > automatically, if you just list the source dirs in priority order. I > would suggest leveraging this by making this change instead: > > First in the list of LIBAWT_XAWT_DIRS (line 272), prepend a line like this: > > $(wildcard > $(TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS)/native/libawt_xawt) > \ > > /Erik > > > On 2018-05-04 07:07, Langer, Christoph wrote: > > Hi, > > > > please help reviewing the contribution of the support for the AIX Input > Method Editor (IME) in AWT's Input Method Framework. > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.1/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201429 > > > > I took Ichiroh's initial proposal [1] and tried to integrate it better with > existing code. I have split > src/java.desktop/unix/classes/sun/awt/X11InputMethod.java into > > a) a base class containing the common code: > src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java > > b) a specific class for the common Linux/Unixes: > src/java.desktop/unix/classes/sun/awt/X11InputMethod.java and > > c) a specific class for AIX: > src/java.desktop/aix/classes/sun/awt/X11InputMethod.java > > > > The AIX specific additions to the native code of > src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c were so > much that I decided to add a specific implementation file for AIX: > src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod_aix.c. The > changes to the former file are some cleanups. > > > > I'm still in the process of testing the changes - but maybe you can run > further tests, especially on non-AIX unixes to make sure we didn't break > something. > > > > Thanks & Best regards > > Christoph > > > > [1]: http://mail.openjdk.java.net/pipermail/awt-dev/2018- > April/013869.html > > From krishna.addepalli at oracle.com Tue May 8 09:59:14 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 8 May 2018 02:59:14 -0700 (PDT) Subject: [11][JDK-8197810]RFR: Test java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html fails on Windows Message-ID: <500f353e-59bb-42c7-94cd-0d4b00861efb@default> Hi All Please review a fix for JDK-8197810: https://bugs.openjdk.java.net/browse/JDK-8197810 , Webrev: http://cr.openjdk.java.net/~kaddepalli/8197810/webrev00/ The basic problem is that, the Robot mouse move is moving to position where item 0 is located (which is already selected), and selecting it. Since this item is already selected, there is no new item selection event generated, which is why the test fails. Fix is to move the mouse to a position where item1 is located, so that the event is triggered. Along with this fix, I have also fixed these other problems: 1. Removed the applet machinery around the test and made it simple. 2. The test was not disposing the window in case of failure. 3. Test was using lock to determine the success or failure, but it could lead to a deadlock/ failure of the test since the main thread would acquire the lock and wait for it to get notified. Instead, CountDownLatch is a cleaner solution for the same. 4. Cleaned up the imports. I have tested the fix on Windows 10, Mac 10.13.4, Ubuntu 16.10 and it works. Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Tue May 8 15:24:22 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 8 May 2018 08:24:22 -0700 Subject: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) In-Reply-To: References: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> <0cf8df6f-d5ad-9db2-8381-ccca9eaf6a5f@oracle.com> Message-ID: <6d6b9a02-3b81-6978-1104-c4b1c12f65a5@oracle.com> Build change looks good. /Erik On 2018-05-08 02:54, Langer, Christoph wrote: > Hi Eric, > > thanks for that excellent suggestion. I already thought there should be some means to do that but was not aware of how that could be accomplished. I updated the webrev in place. > > Thanks > Christoph > >> -----Original Message----- >> From: Erik Joelsson [mailto:erik.joelsson at oracle.com] >> Sent: Freitag, 4. Mai 2018 17:45 >> To: Langer, Christoph ; awt- >> dev at openjdk.java.net >> Cc: build-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >> Subject: Re: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT >> Input Method Framework (IMF) >> >> Hello, >> >> It looks like what you are trying to achieve is to override >> awt_InputMethod.c with an OS specific version of that file. We have a >> construct for this in SetupNativeCompilation that should handle it >> automatically, if you just list the source dirs in priority order. I >> would suggest leveraging this by making this change instead: >> >> First in the list of LIBAWT_XAWT_DIRS (line 272), prepend a line like this: >> >> $(wildcard >> $(TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS)/native/libawt_xawt) >> \ >> >> /Erik >> >> >> On 2018-05-04 07:07, Langer, Christoph wrote: >>> Hi, >>> >>> please help reviewing the contribution of the support for the AIX Input >> Method Editor (IME) in AWT's Input Method Framework. >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.1/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201429 >>> >>> I took Ichiroh's initial proposal [1] and tried to integrate it better with >> existing code. I have split >> src/java.desktop/unix/classes/sun/awt/X11InputMethod.java into >>> a) a base class containing the common code: >> src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java >>> b) a specific class for the common Linux/Unixes: >> src/java.desktop/unix/classes/sun/awt/X11InputMethod.java and >>> c) a specific class for AIX: >> src/java.desktop/aix/classes/sun/awt/X11InputMethod.java >>> The AIX specific additions to the native code of >> src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c were so >> much that I decided to add a specific implementation file for AIX: >> src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod_aix.c. The >> changes to the former file are some cleanups. >>> I'm still in the process of testing the changes - but maybe you can run >> further tests, especially on non-AIX unixes to make sure we didn't break >> something. >>> Thanks & Best regards >>> Christoph >>> >>> [1]: http://mail.openjdk.java.net/pipermail/awt-dev/2018- >> April/013869.html From prem.balakrishnan at oracle.com Thu May 10 09:37:32 2018 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Thu, 10 May 2018 02:37:32 -0700 (PDT) Subject: [11] Review Request JDK-8196360 java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java fails In-Reply-To: <613d1858-7be6-0df3-33e8-08faf4c73419@oracle.com> References: <4f6d2926-57aa-4141-8564-200138df1cf3@default> <613d1858-7be6-0df3-33e8-08faf4c73419@oracle.com> Message-ID: Hi Sergey, >>Slight variation in the RGB value caused the test to fail on OS X >>10.12.6 and On OS X 10.13.1 test passes always. I am not able to reproduce this issue(slight variation in RGB Value) on OSX 10.12.6.Executed several times. Please review updated patch, which solves Windows 10 related issue. Webrev: http://cr.openjdk.java.net/~pkbalakr/8196360/webrev01/ Regards, Prem -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, May 08, 2018 12:54 AM To: Prem Balakrishnan ; awt-dev at openjdk.java.net Subject: Re: [11] Review Request JDK-8196360 java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java fails Hi, Prem. Did you check why the rong value is returned by the Robot? Maybe some of "window decoration" are different in osx 10.12(shadows/title/etc)? On 07/05/2018 02:33, Prem Balakrishnan wrote: > Please review fix for JDK 11: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196360 > > Webrev: http://cr.openjdk.java.net/~pkbalakr/8196360/webrev00/ > > On Mac , slight variation in the RGB value caused the test to fail ? > only on OS X 10.12.6 ( On OS X 10.13.1 test passes always). -- Best regards, Sergey. From manajit.halder at oracle.com Thu May 10 11:59:09 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Thu, 10 May 2018 17:29:09 +0530 Subject: [11] Review request for JDK-8202841: [macosx] test java/awt/Graphics/LCDTextAndGraphicsState.java fails Message-ID: Hi Phil, Please review the test fix for JDK11. Bug: https://bugs.openjdk.java.net/browse/JDK-8202841 Webrev: http://cr.openjdk.java.net/~mhalder/8202841/webrev.00/ Issue: Test fails due jtreg tag manual=yesno with error ?Parse Exception: Arguments to `manual' option not supported: yesno? Fix: Removed itreg tag manual=yesno and changed the test to a manual test with instructions Regards, Manajit -------------- next part -------------- An HTML attachment was scrubbed... URL: From shashidhara.veerabhadraiah at oracle.com Thu May 10 15:40:47 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Thu, 10 May 2018 08:40:47 -0700 (PDT) Subject: [11] JDK-8169187: [macosx] Aqua: java/awt/image/multiresolution/MultiresolutionIconTest.java Message-ID: Hi All, Please review test fix for the below bug: Bug: https://bugs.openjdk.java.net/browse/JDK-8169187 Webrev: http://cr.openjdk.java.net/~sveerabhadra/8169187/webrev.00/ The test was failing because of the color value mismatches, the fix is to get an image of the part of the window for which color needs to be fetched from the image pixel. This type of check is done only when the color fetch from the robot fails. ProblemList is updated to remove this test. Thanks and regards, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.b.bansal at oracle.com Thu May 10 19:21:29 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Thu, 10 May 2018 12:21:29 -0700 (PDT) Subject: [11] Review Request: JDK-8196616 java/awt/GraphicsDevice/DisplayModes/CompareToXrandrTest.java fails Message-ID: Hi All, Please review test fix for the below bug: Bug: https://bugs.openjdk.java.net/browse/JDK-8196616 Webrev: http://cr.openjdk.java.net/~pbansal/8196616/webrev.00/ The test case create a BufferedReader and this BufferedReader is used to find XRanderModes and JavaModes and compare them. It is assumed in this test that the first two lines of the BufferedReader don't have the useful mode data and contain some other information. So it ignores first two lines. But this is not always true and test may have to ignore more or less lines depending upon the data. Made changes to the test to check how many lines should be ignored, instead of hard coding the number of lines to ignore. Regards, Pankaj Bansal -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu May 10 19:28:41 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 10 May 2018 12:28:41 -0700 Subject: [11] Review Request: JDK-8196616 java/awt/GraphicsDevice/DisplayModes/CompareToXrandrTest.java fails In-Reply-To: References: Message-ID: <117ef21f-bc9d-3f28-a3cd-90eecda356c9@oracle.com> Execing xrandr twice ? Can't we either just re-write the code to not use takeWhile() which is part of the problem, or less desirably store the results into an internal buffer and read it from there using StringReader/StringWriter - wrapped in BufferedReader/BufferedWriter ? Also I think you should use try-with-resources on the reading from the "real" stream. And a style point : while((line = reader.readLine()) != null) { -> while ((line = reader.readLine()) != null) { -phil. On 05/10/2018 12:21 PM, Pankaj Bansal wrote: > > Hi All, Please review test fix for the below bug: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196616 > > Webrev: http://cr.openjdk.java.net/~pbansal/8196616/webrev.00/ > > > The test case create a BufferedReader and this BufferedReader is used > to find XRanderModes and JavaModes and compare them. > > It is assumed in this test that the first two lines of the > BufferedReader don?t have the useful mode data and contain some other > information. So it ignores first two lines. But this is not always > true and test may have to ignore more or less lines depending upon the > data. > > Made changes to the test to check how many lines should be ignored, > instead of hard coding the number of lines to ignore. > > Regards, > Pankaj Bansal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.b.bansal at oracle.com Thu May 10 20:30:00 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Thu, 10 May 2018 13:30:00 -0700 (PDT) Subject: [11] Review Request: JDK-8196616 java/awt/GraphicsDevice/DisplayModes/CompareToXrandrTest.java fails In-Reply-To: <117ef21f-bc9d-3f28-a3cd-90eecda356c9@oracle.com> References: <117ef21f-bc9d-3f28-a3cd-90eecda356c9@oracle.com> Message-ID: Hi Phil, Thanks for the quick review. < while ((line = reader.readLine()) != null) { -phil. On 05/10/2018 12:21 PM, Pankaj Bansal wrote: Hi All, Please review test fix for the below bug: Bug: https://bugs.openjdk.java.net/browse/JDK-8196616 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/8196616/webrev.00/"http://cr.openjdk.java.net/~pbansal/8196616/webrev.00/ The test case create a BufferedReader and this BufferedReader is used to find XRanderModes and JavaModes and compare them. It is assumed in this test that the first two lines of the BufferedReader don't have the useful mode data and contain some other information. So it ignores first two lines. But this is not always true and test may have to ignore more or less lines depending upon the data. Made changes to the test to check how many lines should be ignored, instead of hard coding the number of lines to ignore. Regards, Pankaj Bansal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu May 10 20:55:07 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 10 May 2018 13:55:07 -0700 Subject: [11] Review Request JDK-8196360 java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java fails In-Reply-To: References: <4f6d2926-57aa-4141-8564-200138df1cf3@default> <613d1858-7be6-0df3-33e8-08faf4c73419@oracle.com> Message-ID: <0e5cfebb-b152-6558-23da-4201d978d566@oracle.com> Hi, Prem. The changes are fine, but you need to remove this test from the problemList. On 10/05/2018 02:37, Prem Balakrishnan wrote: > Hi Sergey, > >>> Slight variation in the RGB value caused the test to fail on OS X >>10.12.6 and On OS X 10.13.1 test passes always. > > I am not able to reproduce this issue(slight variation in RGB Value) on OSX 10.12.6.Executed several times. > Please review updated patch, which solves Windows 10 related issue. > Webrev: http://cr.openjdk.java.net/~pkbalakr/8196360/webrev01/ > > Regards, > Prem > > -----Original Message----- > From: Sergey Bylokhov > Sent: Tuesday, May 08, 2018 12:54 AM > To: Prem Balakrishnan ; awt-dev at openjdk.java.net > Subject: Re: [11] Review Request JDK-8196360 java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java fails > > Hi, Prem. > Did you check why the rong value is returned by the Robot? Maybe some of "window decoration" are different in osx 10.12(shadows/title/etc)? > > On 07/05/2018 02:33, Prem Balakrishnan wrote: >> Please review fix for JDK 11: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196360 >> >> Webrev: http://cr.openjdk.java.net/~pkbalakr/8196360/webrev00/ >> >> On Mac , slight variation in the RGB value caused the test to fail >> only on OS X 10.12.6 ( On OS X 10.13.1 test passes always). > > > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu May 10 20:58:15 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 10 May 2018 13:58:15 -0700 Subject: [11] Review request for JDK-8202841: [macosx] test java/awt/Graphics/LCDTextAndGraphicsState.java fails In-Reply-To: References: Message-ID: Hi, Manajit. Did you check other tests with such typos? I found the same strings in our repo. On 10/05/2018 04:59, Manajit Halder wrote: > Hi Phil, > > Please review the test fix for JDK11. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8202841 > > Webrev: > http://cr.openjdk.java.net/~mhalder/8202841/webrev.00/ > > Issue: > Test fails due jtreg tag manual=yesno with error ?Parse Exception: > Arguments to `manual' option not supported: yesno? > > Fix: > Removed itreg tag manual=yesno and changed the test to a manual test > with instructions > > Regards, > Manajit -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu May 10 21:09:58 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 10 May 2018 14:09:58 -0700 Subject: [11] JDK-8169187: [macosx] Aqua: java/awt/image/multiresolution/MultiresolutionIconTest.java In-Reply-To: References: Message-ID: Hi, Shashi. On 10/05/2018 08:40, Shashidhara Veerabhadraiah wrote: > The test was failing because of the color value mismatches, the fix is > to get an image of the part of the window for which color needs to be > fetched from the image pixel. Can you please clarify why r.getPixelColor(x, y) returns incorrect color and r.createScreenCapture(bouns{x,y,1,1}) will work, since internally both of these methods are use the same method CRobot.getRGBPixels() -- Best regards, Sergey. From philip.race at oracle.com Thu May 10 23:21:27 2018 From: philip.race at oracle.com (Philip Race) Date: Thu, 10 May 2018 16:21:27 -0700 Subject: [11] Review request for JDK-8202841: [macosx] test java/awt/Graphics/LCDTextAndGraphicsState.java fails In-Reply-To: References: Message-ID: <5AF4D3F7.5080701@oracle.com> So according to http://openjdk.java.net/jtreg/tag-spec.html this tag is legal and correct /manual[=(yesno|done)] ... If "yesno" is given, then the harness will ask the user whether the action is to pass or fail. But it seems this is only implemented for applets. So are those other strings applets or main programs. -phil. On 5/10/18, 1:58 PM, Sergey Bylokhov wrote: > Hi, Manajit. > Did you check other tests with such typos? > I found the same strings in our repo. > > On 10/05/2018 04:59, Manajit Halder wrote: >> Hi Phil, >> >> Please review the test fix for JDK11. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8202841 >> >> Webrev: >> http://cr.openjdk.java.net/~mhalder/8202841/webrev.00/ >> >> Issue: >> Test fails due jtreg tag manual=yesno with error ?Parse Exception: >> Arguments to `manual' option not supported: yesno? >> >> Fix: >> Removed itreg tag manual=yesno and changed the test to a manual test >> with instructions >> >> Regards, >> Manajit > > From shashidhara.veerabhadraiah at oracle.com Fri May 11 04:59:03 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Thu, 10 May 2018 21:59:03 -0700 (PDT) Subject: [11] Review Request JDK-8196360 java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java fails In-Reply-To: <0e5cfebb-b152-6558-23da-4201d978d566@oracle.com> References: <4f6d2926-57aa-4141-8564-200138df1cf3@default> <613d1858-7be6-0df3-33e8-08faf4c73419@oracle.com> <0e5cfebb-b152-6558-23da-4201d978d566@oracle.com> Message-ID: <70a76f8a-29cc-4261-8fb2-cfa8e9ae986f@default> Hi Prem, The changes looks fine to me. Thanks and regards, Shashi -----Original Message----- From: Sergey Bylokhov Sent: Friday, May 11, 2018 2:25 AM To: Prem Balakrishnan ; awt-dev at openjdk.java.net Subject: Re: [11] Review Request JDK-8196360 java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java fails Hi, Prem. The changes are fine, but you need to remove this test from the problemList. On 10/05/2018 02:37, Prem Balakrishnan wrote: > Hi Sergey, > >>> Slight variation in the RGB value caused the test to fail on OS X >>10.12.6 and On OS X 10.13.1 test passes always. > > I am not able to reproduce this issue(slight variation in RGB Value) on OSX 10.12.6.Executed several times. > Please review updated patch, which solves Windows 10 related issue. > Webrev: http://cr.openjdk.java.net/~pkbalakr/8196360/webrev01/ > > Regards, > Prem > > -----Original Message----- > From: Sergey Bylokhov > Sent: Tuesday, May 08, 2018 12:54 AM > To: Prem Balakrishnan ; > awt-dev at openjdk.java.net > Subject: Re: [11] Review Request JDK-8196360 > java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java fails > > Hi, Prem. > Did you check why the rong value is returned by the Robot? Maybe some of "window decoration" are different in osx 10.12(shadows/title/etc)? > > On 07/05/2018 02:33, Prem Balakrishnan wrote: >> Please review fix for JDK 11: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196360 >> >> Webrev: http://cr.openjdk.java.net/~pkbalakr/8196360/webrev00/ >> >> On Mac , slight variation in the RGB value caused the test to fail >> only on OS X 10.12.6 ( On OS X 10.13.1 test passes always). > > > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Fri May 11 05:11:26 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 10 May 2018 22:11:26 -0700 (PDT) Subject: [11] Review Request JDK-8196360 java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java fails In-Reply-To: <0e5cfebb-b152-6558-23da-4201d978d566@oracle.com> References: <4f6d2926-57aa-4141-8564-200138df1cf3@default> <613d1858-7be6-0df3-33e8-08faf4c73419@oracle.com> <0e5cfebb-b152-6558-23da-4201d978d566@oracle.com> Message-ID: Hi Prem, +1. I was going through this test case as part of JDK-8202824. In ProblemList this test case is listed with a closed bug id. Please verify this test case in all relevant platforms and then remove it from problem list. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Friday, May 11, 2018 2:25 AM To: Prem Balakrishnan; awt-dev at openjdk.java.net Subject: Re: [11] Review Request JDK-8196360 java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java fails Hi, Prem. The changes are fine, but you need to remove this test from the problemList. On 10/05/2018 02:37, Prem Balakrishnan wrote: > Hi Sergey, > >>> Slight variation in the RGB value caused the test to fail on OS X >>10.12.6 and On OS X 10.13.1 test passes always. > > I am not able to reproduce this issue(slight variation in RGB Value) on OSX 10.12.6.Executed several times. > Please review updated patch, which solves Windows 10 related issue. > Webrev: http://cr.openjdk.java.net/~pkbalakr/8196360/webrev01/ > > Regards, > Prem > > -----Original Message----- > From: Sergey Bylokhov > Sent: Tuesday, May 08, 2018 12:54 AM > To: Prem Balakrishnan ; > awt-dev at openjdk.java.net > Subject: Re: [11] Review Request JDK-8196360 > java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java fails > > Hi, Prem. > Did you check why the rong value is returned by the Robot? Maybe some of "window decoration" are different in osx 10.12(shadows/title/etc)? > > On 07/05/2018 02:33, Prem Balakrishnan wrote: >> Please review fix for JDK 11: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196360 >> >> Webrev: http://cr.openjdk.java.net/~pkbalakr/8196360/webrev00/ >> >> On Mac , slight variation in the RGB value caused the test to fail >> only on OS X 10.12.6 ( On OS X 10.13.1 test passes always). > > > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From prem.balakrishnan at oracle.com Fri May 11 06:01:49 2018 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Thu, 10 May 2018 23:01:49 -0700 (PDT) Subject: [11] Review Request JDK-8196360 java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java fails In-Reply-To: References: <4f6d2926-57aa-4141-8564-200138df1cf3@default> <613d1858-7be6-0df3-33e8-08faf4c73419@oracle.com> <0e5cfebb-b152-6558-23da-4201d978d566@oracle.com> Message-ID: Thank you for the review Sergey, Shashi and Jay. I will update the problem list while pushing the patch. @Jay, I have tested on Windows 7 & 10, Ubuntu 17.10, Mac OS X 10.12.6 and 10.13.1, and will be removing the entry related to this test from ProblemList. Regards, -Prem -----Original Message----- From: Jayathirth D V Sent: Friday, May 11, 2018 10:41 AM To: Sergey Bylokhov ; Prem Balakrishnan ; awt-dev at openjdk.java.net Subject: RE: [11] Review Request JDK-8196360 java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java fails Hi Prem, +1. I was going through this test case as part of JDK-8202824. In ProblemList this test case is listed with a closed bug id. Please verify this test case in all relevant platforms and then remove it from problem list. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Friday, May 11, 2018 2:25 AM To: Prem Balakrishnan; awt-dev at openjdk.java.net Subject: Re: [11] Review Request JDK-8196360 java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java fails Hi, Prem. The changes are fine, but you need to remove this test from the problemList. On 10/05/2018 02:37, Prem Balakrishnan wrote: > Hi Sergey, > >>> Slight variation in the RGB value caused the test to fail on OS X >>10.12.6 and On OS X 10.13.1 test passes always. > > I am not able to reproduce this issue(slight variation in RGB Value) on OSX 10.12.6.Executed several times. > Please review updated patch, which solves Windows 10 related issue. > Webrev: http://cr.openjdk.java.net/~pkbalakr/8196360/webrev01/ > > Regards, > Prem > > -----Original Message----- > From: Sergey Bylokhov > Sent: Tuesday, May 08, 2018 12:54 AM > To: Prem Balakrishnan ; > awt-dev at openjdk.java.net > Subject: Re: [11] Review Request JDK-8196360 > java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java fails > > Hi, Prem. > Did you check why the rong value is returned by the Robot? Maybe some of "window decoration" are different in osx 10.12(shadows/title/etc)? > > On 07/05/2018 02:33, Prem Balakrishnan wrote: >> Please review fix for JDK 11: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196360 >> >> Webrev: http://cr.openjdk.java.net/~pkbalakr/8196360/webrev00/ >> >> On Mac , slight variation in the RGB value caused the test to fail >> only on OS X 10.12.6 ( On OS X 10.13.1 test passes always). > > > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From shashidhara.veerabhadraiah at oracle.com Fri May 11 07:45:01 2018 From: shashidhara.veerabhadraiah at oracle.com (shashidhara.veerabhadraiah at oracle.com) Date: Fri, 11 May 2018 13:15:01 +0530 Subject: [11] JDK-8169187: [macosx] Aqua: java/awt/image/multiresolution/MultiresolutionIconTest.java In-Reply-To: References: Message-ID: Hi Sergey, I found some information wrt the use of getPixelColor() compared to the method of using the createScreenCapture() api's. By using the createScreenCapture(): 1. In this case we will be using the low resolution variant of the image that was captured. 2. The low resolution variant was created from the high resolution image that was actually captured from an high res display. This is done using the nearest neighbor interpolation which actually chooses the most nearest point's value and ignores the other points values completely. This may be a reason to get a different color for the said pixel. By using the getPixelColor(): 1. This calls the getRGBPixel(). 2. Here we return only the 0th pixel color ignoring the scaling effect in the case of hidpi display units, where there may be many sub pixels for the given user space coordinates. This may be the reason for getting failed here. Thanks and regards, Shashi On 11/05/18 2:39 AM, Sergey Bylokhov wrote: > Hi, Shashi. > > On 10/05/2018 08:40, Shashidhara Veerabhadraiah wrote: >> The test was failing because of the color value mismatches, the fix >> is to get an image of the part of the window for which color needs to >> be fetched from the image pixel. > > Can you please clarify why r.getPixelColor(x, y) returns incorrect > color and r.createScreenCapture(bouns{x,y,1,1}) will work, since > internally both of these methods are use the same method > CRobot.getRGBPixels() > From philip.race at oracle.com Fri May 11 17:46:52 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 11 May 2018 10:46:52 -0700 Subject: RFR: 8202811: Problem List some tests that leave windows open on the desktop Message-ID: <459a7e40-a35b-9c90-6448-23dfdc189050@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8202811 webrev: http://cr.openjdk.java.net/~prr/8202811/ This started out as wanting to problem list a few tests that left windows open or otherwise did not terminate. And these are in there, but I also tried to clean up most of the reproducible Linux failures I see on Ubuntu 16.04. All the problem listed tests fail when being run one per jtreg invocation and were repeatable. -phil. From philip.race at oracle.com Fri May 11 19:08:29 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 11 May 2018 12:08:29 -0700 Subject: RFR: 8202811: Problem List some tests that leave windows open on the desktop In-Reply-To: <459a7e40-a35b-9c90-6448-23dfdc189050@oracle.com> References: <459a7e40-a35b-9c90-6448-23dfdc189050@oracle.com> Message-ID: <934ded43-12b0-6844-fafc-f5a9634d8129@oracle.com> PS .. I forgot I wanted to piggy back an update to TEST.ROOT to add some remaining directories for jtreg to use othervm mode : http://cr.openjdk.java.net/~prr/8202811.1/ -phil. On 05/11/2018 10:46 AM, Phil Race wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8202811 > webrev: http://cr.openjdk.java.net/~prr/8202811/ > > This started out as wanting to problem list a few tests that left > windows open > or otherwise did not terminate. And these are in there, but I also > tried to clean up > most of the reproducible Linux failures I see on Ubuntu 16.04. > All the problem listed tests fail when being run one per jtreg > invocation and > were repeatable. > > -phil. From Sergey.Bylokhov at oracle.com Fri May 11 20:57:55 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 11 May 2018 13:57:55 -0700 Subject: RFR: 8202811: Problem List some tests that leave windows open on the desktop In-Reply-To: <934ded43-12b0-6844-fafc-f5a9634d8129@oracle.com> References: <459a7e40-a35b-9c90-6448-23dfdc189050@oracle.com> <934ded43-12b0-6844-fafc-f5a9634d8129@oracle.com> Message-ID: Looks fine as a first step in our cleanup of the tests on lin/mac. Note: I think that some of the tests fail because of some unrelated issues(other tests or some setup issues), at least some of them works fine on my mac, for example: java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java 8202931 macosx-all On 11/05/2018 12:08, Phil Race wrote: > PS .. I forgot I wanted to piggy back an update to TEST.ROOT to > add some remaining directories for jtreg to use othervm mode : > > http://cr.openjdk.java.net/~prr/8202811.1/ > > -phil. > > > On 05/11/2018 10:46 AM, Phil Race wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8202811 >> webrev: http://cr.openjdk.java.net/~prr/8202811/ >> >> This started out as wanting to problem list a few tests that left >> windows open >> or otherwise did not terminate. And these are in there, but I also >> tried to clean up >> most of the reproducible Linux failures I see on Ubuntu 16.04. >> All the problem listed tests fail when being run one per jtreg >> invocation and >> were repeatable. >> >> -phil. > -- Best regards, Sergey. From philip.race at oracle.com Fri May 11 21:07:03 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 11 May 2018 14:07:03 -0700 Subject: RFR: 8202811: Problem List some tests that leave windows open on the desktop In-Reply-To: References: <459a7e40-a35b-9c90-6448-23dfdc189050@oracle.com> <934ded43-12b0-6844-fafc-f5a9634d8129@oracle.com> Message-ID: I expect that some tests that fail one one system will pass on another and identifying the set up issues or environmental issues may be tricky. -phil. On 05/11/2018 01:57 PM, Sergey Bylokhov wrote: > Looks fine as a first step in our cleanup of the tests on lin/mac. > > Note: I think that some of the tests fail because of some unrelated > issues(other tests or some setup issues), at least some of them works > fine on my mac, for example: > java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java 8202931 > macosx-all > > On 11/05/2018 12:08, Phil Race wrote: >> PS .. I forgot I wanted to piggy back an update to TEST.ROOT to >> add some remaining directories for jtreg to use othervm mode : >> >> http://cr.openjdk.java.net/~prr/8202811.1/ >> >> -phil. >> >> >> On 05/11/2018 10:46 AM, Phil Race wrote: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8202811 >>> webrev: http://cr.openjdk.java.net/~prr/8202811/ >>> >>> This started out as wanting to problem list a few tests that left >>> windows open >>> or otherwise did not terminate. And these are in there, but I also >>> tried to clean up >>> most of the reproducible Linux failures I see on Ubuntu 16.04. >>> All the problem listed tests fail when being run one per jtreg >>> invocation and >>> were repeatable. >>> >>> -phil. >> > > From Sergey.Bylokhov at oracle.com Fri May 11 23:08:27 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 11 May 2018 16:08:27 -0700 Subject: [11] JDK-8169187: [macosx] Aqua: java/awt/image/multiresolution/MultiresolutionIconTest.java In-Reply-To: References: Message-ID: Hi, Shashi. It means that the updated test will not trust getPixelColor() which returns exact color which is drawn on the screen, but will trust createScreenCapture() which will apply transformation of the actual color. This looks odd. On 11/05/2018 00:45, shashidhara.veerabhadraiah at oracle.com wrote: > 1. In this case we will be using the low resolution variant of the image > that was captured. > > 2. The low resolution variant was created from the high resolution image > that was actually captured from an high res display. This is done using > the nearest neighbor interpolation which actually chooses the most > nearest point's value and ignores the other points values completely. > > This may be a reason to get a different color for the said pixel. > > > By using the getPixelColor(): > > 1. This calls the getRGBPixel(). > > 2. Here we return only the 0th pixel color ignoring the scaling effect > in the case of hidpi display units, where there may be many sub pixels > for the given user space coordinates. > > This may be the reason for getting failed here. > > > Thanks and regards, > > Shashi > > > On 11/05/18 2:39 AM, Sergey Bylokhov wrote: >> Hi, Shashi. >> >> On 10/05/2018 08:40, Shashidhara Veerabhadraiah wrote: >>> The test was failing because of the color value mismatches, the fix >>> is to get an image of the part of the window for which color needs to >>> be fetched from the image pixel. >> >> Can you please clarify why r.getPixelColor(x, y) returns incorrect >> color and r.createScreenCapture(bouns{x,y,1,1}) will work, since >> internally both of these methods are use the same method >> CRobot.getRGBPixels() >> > -- Best regards, Sergey. From shashidhara.veerabhadraiah at oracle.com Sat May 12 16:15:59 2018 From: shashidhara.veerabhadraiah at oracle.com (shashidhara.veerabhadraiah at oracle.com) Date: Sat, 12 May 2018 21:45:59 +0530 Subject: [11] JDK-8169187: [macosx] Aqua: java/awt/image/multiresolution/MultiresolutionIconTest.java In-Reply-To: References: Message-ID: <4a3c7e37-d16f-1bc3-3273-a24db91b1cca@oracle.com> Hi Sergey, I read that slightly different. The getPixelColor() would not be accurate but createScreenCapture() works differently but advantageous to us. The reason for that is that if we have a HiDpi factor screen of say 3, then actually 3 sub pixels forms each particular location. The getPixelColor() would always choose the first pixel(0th) whereas createScreenCapture() since it converts to low res image using the nearest neighbor, it would choose the color of the most nearest point for that particular location. We don't need the information of the 3 pixel color info but since the limitation of getPixelColor() is that it can return only one color and that color should actually be closest to that particular location. But instead we always return the first pixel color. On the other hand, createScreenCapture() would choose the closest pixel out of the 3 pixel color info, which is required in our case. This is what I felt out of the 2 ways, please let me know what do you think of this. Thanks and regards, Shashi On 12/05/18 4:38 AM, Sergey Bylokhov wrote: > Hi, Shashi. > It means that the updated test will not trust getPixelColor() which > returns exact color which is drawn on the screen, but will trust > createScreenCapture() which will apply transformation of the actual > color. This looks odd. > > On 11/05/2018 00:45, shashidhara.veerabhadraiah at oracle.com wrote: >> 1. In this case we will be using the low resolution variant of the >> image that was captured. >> >> 2. The low resolution variant was created from the high resolution >> image that was actually captured from an high res display. This is >> done using the nearest neighbor interpolation which actually chooses >> the most nearest point's value and ignores the other points values >> completely. >> >> This may be a reason to get a different color for the said pixel. >> >> >> By using the getPixelColor(): >> >> 1. This calls the getRGBPixel(). >> >> 2. Here we return only the 0th pixel color ignoring the scaling >> effect in the case of hidpi display units, where there may be many >> sub pixels for the given user space coordinates. >> >> This may be the reason for getting failed here. >> >> >> Thanks and regards, >> >> Shashi >> >> >> On 11/05/18 2:39 AM, Sergey Bylokhov wrote: >>> Hi, Shashi. >>> >>> On 10/05/2018 08:40, Shashidhara Veerabhadraiah wrote: >>>> The test was failing because of the color value mismatches, the fix >>>> is to get an image of the part of the window for which color needs >>>> to be fetched from the image pixel. >>> >>> Can you please clarify why r.getPixelColor(x, y) returns incorrect >>> color and r.createScreenCapture(bouns{x,y,1,1}) will work, since >>> internally both of these methods are use the same method >>> CRobot.getRGBPixels() >>> >> > > From shashidhara.veerabhadraiah at oracle.com Sun May 13 04:47:45 2018 From: shashidhara.veerabhadraiah at oracle.com (shashidhara.veerabhadraiah at oracle.com) Date: Sun, 13 May 2018 10:17:45 +0530 Subject: [11] JDK-8169187: [macosx] Aqua: java/awt/image/multiresolution/MultiresolutionIconTest.java In-Reply-To: <4a3c7e37-d16f-1bc3-3273-a24db91b1cca@oracle.com> References: <4a3c7e37-d16f-1bc3-3273-a24db91b1cca@oracle.com> Message-ID: Hi Sergey, Small correction. If the HiDpi factor is 3, then assuming uniform scaling on x and y, it will be a 3 * 3 area representing a single coordinate point. getPixelColor() will always pick the first point color but the createScreenCapture() would pick the closest one pixel among the 3 * 3. Thanks and regards, Shashi On 12/05/18 9:45 PM, shashidhara.veerabhadraiah at oracle.com wrote: > Hi Sergey, I read that slightly different. The getPixelColor() would > not be accurate but createScreenCapture() works differently but > advantageous to us. The reason for that is that if we have a HiDpi > factor screen of say 3, then actually 3 sub pixels forms each > particular location. The getPixelColor() would always choose the first > pixel(0th) whereas createScreenCapture() since it converts to low res > image using the nearest neighbor, it would choose the color of the > most nearest point for that particular location. > > We don't need the information of the 3 pixel color info but since the > limitation of getPixelColor() is that it can return only one color and > that color should actually be closest to that particular location. But > instead we always return the first pixel color. On the other hand, > createScreenCapture() would choose the closest pixel out of the 3 > pixel color info, which is required in our case. > > This is what I felt out of the 2 ways, please let me know what do you > think of this. > > Thanks and regards, > > Shashi > > > On 12/05/18 4:38 AM, Sergey Bylokhov wrote: >> Hi, Shashi. >> It means that the updated test will not trust getPixelColor() which >> returns exact color which is drawn on the screen, but will trust >> createScreenCapture() which will apply transformation of the actual >> color. This looks odd. >> >> On 11/05/2018 00:45, shashidhara.veerabhadraiah at oracle.com wrote: >>> 1. In this case we will be using the low resolution variant of the >>> image that was captured. >>> >>> 2. The low resolution variant was created from the high resolution >>> image that was actually captured from an high res display. This is >>> done using the nearest neighbor interpolation which actually chooses >>> the most nearest point's value and ignores the other points values >>> completely. >>> >>> This may be a reason to get a different color for the said pixel. >>> >>> >>> By using the getPixelColor(): >>> >>> 1. This calls the getRGBPixel(). >>> >>> 2. Here we return only the 0th pixel color ignoring the scaling >>> effect in the case of hidpi display units, where there may be many >>> sub pixels for the given user space coordinates. >>> >>> This may be the reason for getting failed here. >>> >>> >>> Thanks and regards, >>> >>> Shashi >>> >>> >>> On 11/05/18 2:39 AM, Sergey Bylokhov wrote: >>>> Hi, Shashi. >>>> >>>> On 10/05/2018 08:40, Shashidhara Veerabhadraiah wrote: >>>>> The test was failing because of the color value mismatches, the >>>>> fix is to get an image of the part of the window for which color >>>>> needs to be fetched from the image pixel. >>>> >>>> Can you please clarify why r.getPixelColor(x, y) returns incorrect >>>> color and r.createScreenCapture(bouns{x,y,1,1}) will work, since >>>> internally both of these methods are use the same method >>>> CRobot.getRGBPixels() >>>> >>> >> >> > From Sergey.Bylokhov at oracle.com Sun May 13 06:34:27 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 12 May 2018 23:34:27 -0700 Subject: [11] JDK-8169187: [macosx] Aqua: java/awt/image/multiresolution/MultiresolutionIconTest.java In-Reply-To: References: <4a3c7e37-d16f-1bc3-3273-a24db91b1cca@oracle.com> Message-ID: On 12/05/2018 21:47, shashidhara.veerabhadraiah at oracle.com wrote: > Hi Sergey, Small correction. If the HiDpi factor is 3, then assuming > uniform scaling on x and y, it will be a 3 * 3 area representing a > single coordinate point. getPixelColor() will always pick the first > point color but the createScreenCapture() would pick the closest one > pixel among the 3 * 3. But getPixelColor() will return the real pixel which was painted by the test on the screen. If the test will draw blue/red square then getPixelColor() should return blue/red pixel(even if it was the first left/top pixel in the point). > > Thanks and regards, > > Shashi > > > On 12/05/18 9:45 PM, shashidhara.veerabhadraiah at oracle.com wrote: >> Hi Sergey, I read that slightly different. The getPixelColor() would >> not be accurate but createScreenCapture() works differently but >> advantageous to us. The reason for that is that if we have a HiDpi >> factor screen of say 3, then actually 3 sub pixels forms each >> particular location. The getPixelColor() would always choose the first >> pixel(0th) whereas createScreenCapture() since it converts to low res >> image using the nearest neighbor, it would choose the color of the >> most nearest point for that particular location. >> >> We don't need the information of the 3 pixel color info but since the >> limitation of getPixelColor() is that it can return only one color and >> that color should actually be closest to that particular location. But >> instead we always return the first pixel color. On the other hand, >> createScreenCapture() would choose the closest pixel out of the 3 >> pixel color info, which is required in our case. >> >> This is what I felt out of the 2 ways, please let me know what do you >> think of this. >> >> Thanks and regards, >> >> Shashi >> >> >> On 12/05/18 4:38 AM, Sergey Bylokhov wrote: >>> Hi, Shashi. >>> It means that the updated test will not trust getPixelColor() which >>> returns exact color which is drawn on the screen, but will trust >>> createScreenCapture() which will apply transformation of the actual >>> color. This looks odd. >>> >>> On 11/05/2018 00:45, shashidhara.veerabhadraiah at oracle.com wrote: >>>> 1. In this case we will be using the low resolution variant of the >>>> image that was captured. >>>> >>>> 2. The low resolution variant was created from the high resolution >>>> image that was actually captured from an high res display. This is >>>> done using the nearest neighbor interpolation which actually chooses >>>> the most nearest point's value and ignores the other points values >>>> completely. >>>> >>>> This may be a reason to get a different color for the said pixel. >>>> >>>> >>>> By using the getPixelColor(): >>>> >>>> 1. This calls the getRGBPixel(). >>>> >>>> 2. Here we return only the 0th pixel color ignoring the scaling >>>> effect in the case of hidpi display units, where there may be many >>>> sub pixels for the given user space coordinates. >>>> >>>> This may be the reason for getting failed here. >>>> >>>> >>>> Thanks and regards, >>>> >>>> Shashi >>>> >>>> >>>> On 11/05/18 2:39 AM, Sergey Bylokhov wrote: >>>>> Hi, Shashi. >>>>> >>>>> On 10/05/2018 08:40, Shashidhara Veerabhadraiah wrote: >>>>>> The test was failing because of the color value mismatches, the >>>>>> fix is to get an image of the part of the window for which color >>>>>> needs to be fetched from the image pixel. >>>>> >>>>> Can you please clarify why r.getPixelColor(x, y) returns incorrect >>>>> color and r.createScreenCapture(bouns{x,y,1,1}) will work, since >>>>> internally both of these methods are use the same method >>>>> CRobot.getRGBPixels() >>>>> >>>> >>> >>> >> > -- Best regards, Sergey. From shashidhara.veerabhadraiah at oracle.com Mon May 14 06:55:27 2018 From: shashidhara.veerabhadraiah at oracle.com (shashidhara.veerabhadraiah at oracle.com) Date: Mon, 14 May 2018 12:25:27 +0530 Subject: [11] JDK-8169187: [macosx] Aqua: java/awt/image/multiresolution/MultiresolutionIconTest.java In-Reply-To: References: <4a3c7e37-d16f-1bc3-3273-a24db91b1cca@oracle.com> Message-ID: Hi Sergey, Below are some of the samples captured after debugging: This is with a scale of 2. So 4 sub pixels per location. Here are there colors: Pixel info:java.awt.Rectangle[x=132,y=184,width=2,height=2] ------------------------------------------------------ Pixel colors: --13462275 Pixel colors: --13659139 Pixel colors: --13462275 Pixel colors: --13659139 Pixel info:java.awt.Rectangle[x=136,y=184,width=2,height=2] ------------------------------------------------------ Pixel colors: --14250242 Pixel colors: --14512898 Pixel colors: --14315779 Pixel colors: --14447362 Pixel info:java.awt.Rectangle[x=140,y=184,width=2,height=2] ------------------------------------------------------ Pixel colors: --15104002 Pixel colors: --15301122 Pixel colors: --15038210 Pixel colors: --15300866 Pixel info:java.awt.Rectangle[x=144,y=184,width=2,height=2] ------------------------------------------------------ Pixel colors: --15760641 Pixel colors: --15891969 Pixel colors: --15760641 Pixel colors: --15891969 Pixel info:java.awt.Rectangle[x=148,y=184,width=2,height=2] ------------------------------------------------------ Pixel colors: --16285953 Pixel colors: --16687873 Pixel colors: --16286209 Pixel colors: --16687873 As you can see here, it is possible to have different colors for each sub pixel, but the getPixelColor() will invariably choose only the first pixel color. Thanks and regards, Shashi On 13/05/18 12:04 PM, Sergey Bylokhov wrote: > On 12/05/2018 21:47, shashidhara.veerabhadraiah at oracle.com wrote: >> Hi Sergey, Small correction. If the HiDpi factor is 3, then assuming >> uniform scaling on x and y, it will be a 3 * 3 area representing a >> single coordinate point. getPixelColor() will always pick the first >> point color but the createScreenCapture() would pick the closest one >> pixel among the 3 * 3. > > But getPixelColor() will return the real pixel which was painted by > the test on the screen. If the test will draw blue/red square then > getPixelColor() should return blue/red pixel(even if it was the first > left/top pixel in the point). > > >> >> Thanks and regards, >> >> Shashi >> >> >> On 12/05/18 9:45 PM, shashidhara.veerabhadraiah at oracle.com wrote: >>> Hi Sergey, I read that slightly different. The getPixelColor() would >>> not be accurate but createScreenCapture() works differently but >>> advantageous to us. The reason for that is that if we have a HiDpi >>> factor screen of say 3, then actually 3 sub pixels forms each >>> particular location. The getPixelColor() would always choose the >>> first pixel(0th) whereas createScreenCapture() since it converts to >>> low res image using the nearest neighbor, it would choose the color >>> of the most nearest point for that particular location. >>> >>> We don't need the information of the 3 pixel color info but since >>> the limitation of getPixelColor() is that it can return only one >>> color and that color should actually be closest to that particular >>> location. But instead we always return the first pixel color. On the >>> other hand, createScreenCapture() would choose the closest pixel out >>> of the 3 pixel color info, which is required in our case. >>> >>> This is what I felt out of the 2 ways, please let me know what do >>> you think of this. >>> >>> Thanks and regards, >>> >>> Shashi >>> >>> >>> On 12/05/18 4:38 AM, Sergey Bylokhov wrote: >>>> Hi, Shashi. >>>> It means that the updated test will not trust getPixelColor() which >>>> returns exact color which is drawn on the screen, but will trust >>>> createScreenCapture() which will apply transformation of the actual >>>> color. This looks odd. >>>> >>>> On 11/05/2018 00:45, shashidhara.veerabhadraiah at oracle.com wrote: >>>>> 1. In this case we will be using the low resolution variant of the >>>>> image that was captured. >>>>> >>>>> 2. The low resolution variant was created from the high resolution >>>>> image that was actually captured from an high res display. This is >>>>> done using the nearest neighbor interpolation which actually >>>>> chooses the most nearest point's value and ignores the other >>>>> points values completely. >>>>> >>>>> This may be a reason to get a different color for the said pixel. >>>>> >>>>> >>>>> By using the getPixelColor(): >>>>> >>>>> 1. This calls the getRGBPixel(). >>>>> >>>>> 2. Here we return only the 0th pixel color ignoring the scaling >>>>> effect in the case of hidpi display units, where there may be many >>>>> sub pixels for the given user space coordinates. >>>>> >>>>> This may be the reason for getting failed here. >>>>> >>>>> >>>>> Thanks and regards, >>>>> >>>>> Shashi >>>>> >>>>> >>>>> On 11/05/18 2:39 AM, Sergey Bylokhov wrote: >>>>>> Hi, Shashi. >>>>>> >>>>>> On 10/05/2018 08:40, Shashidhara Veerabhadraiah wrote: >>>>>>> The test was failing because of the color value mismatches, the >>>>>>> fix is to get an image of the part of the window for which color >>>>>>> needs to be fetched from the image pixel. >>>>>> >>>>>> Can you please clarify why r.getPixelColor(x, y) returns >>>>>> incorrect color and r.createScreenCapture(bouns{x,y,1,1}) will >>>>>> work, since internally both of these methods are use the same >>>>>> method CRobot.getRGBPixels() >>>>>> >>>>> >>>> >>>> >>> >> > > From jayathirth.d.v at oracle.com Mon May 14 07:09:25 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 14 May 2018 00:09:25 -0700 (PDT) Subject: [11] RFR JDK-8202824: Cleanup discrepancies in ProblemList for java_awt jtreg tests Message-ID: Hello All, Please review the following fix in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-8202824 Webrev : http://cr.openjdk.java.net/~jdv/8202824/webrev.00/ Issue: There are some discrepancies in java_awt part of ProblemList like bud ID typo, invalid bug id. Solution: I have verified test cases in multiple platform and added/removed/updated java_awt ProblemList content. Detailed comment with clarifications is present in JBS bug. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From takiguc at linux.vnet.ibm.com Mon May 14 12:44:50 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 14 May 2018 21:44:50 +0900 Subject: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) In-Reply-To: <6d6b9a02-3b81-6978-1104-c4b1c12f65a5@oracle.com> References: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> <0cf8df6f-d5ad-9db2-8381-ccca9eaf6a5f@oracle.com> <6d6b9a02-3b81-6978-1104-c4b1c12f65a5@oracle.com> Message-ID: <3e96ae93f38a3cfbcb584cf106f5297f@linux.vnet.ibm.com> Hello Christoph. Our team tested your fixed code on Linux (RHEL7) and AIX (7.1). resetCompositionState() was missing in src/java.desktop/aix/classes/sun/awt/X11InputMethod.java ============================================================ --- a/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Wed May 09 09:05:32 2018 +0900 +++ b/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Mon May 14 21:25:50 2018 +0900 @@ -56,6 +56,21 @@ } /** + * Reset the composition state to the current composition state. + */ + protected void resetCompositionState() { + if (compositionEnableSupported && haveActiveClient()) { + try { + /* Restore the composition mode to the last saved composition + mode. */ + setCompositionEnabled(savedCompositionState); + } catch (UnsupportedOperationException e) { + compositionEnableSupported = false; + } + } + } + + /** * Activate input method. */ public synchronized void activate() { ============================================================ Otherwise, we could not find out any functional difference on Linux. we could not find out any functional difference between our modified code and your code on AIX. By code check, we found following difference. ============================================================ --- a/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c Wed May 09 09:05:32 2018 +0900 +++ b/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c Mon May 14 21:25:50 2018 +0900 @@ -248,6 +248,10 @@ "flushText", "()V"); JNU_CHECK_EXCEPTION_RETURN(env, NULL); + if ((*env)->ExceptionOccurred(env)) { + (*env)->ExceptionDescribe(env); + (*env)->ExceptionClear(env); + } /* IMPORTANT: The order of the following calls is critical since "imInstance" may point to the global reference itself, if "freeX11InputMethodData" is called ============================================================ Did you remove this code intentionally ? Otherwise, I think the other changes were acceptable. Thanks, On 2018-05-09 00:24, Erik Joelsson wrote: > Build change looks good. > > /Erik > > > On 2018-05-08 02:54, Langer, Christoph wrote: >> Hi Eric, >> >> thanks for that excellent suggestion. I already thought there should >> be some means to do that but was not aware of how that could be >> accomplished. I updated the webrev in place. >> >> Thanks >> Christoph >> >>> -----Original Message----- >>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com] >>> Sent: Freitag, 4. Mai 2018 17:45 >>> To: Langer, Christoph ; awt- >>> dev at openjdk.java.net >>> Cc: build-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>> Subject: Re: RFR: 8201429: Support AIX Input Method Editor (IME) for >>> AWT >>> Input Method Framework (IMF) >>> >>> Hello, >>> >>> It looks like what you are trying to achieve is to override >>> awt_InputMethod.c with an OS specific version of that file. We have a >>> construct for this in SetupNativeCompilation that should handle it >>> automatically, if you just list the source dirs in priority order. I >>> would suggest leveraging this by making this change instead: >>> >>> First in the list of LIBAWT_XAWT_DIRS (line 272), prepend a line like >>> this: >>> >>> $(wildcard >>> $(TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS)/native/libawt_xawt) >>> \ >>> >>> /Erik >>> >>> >>> On 2018-05-04 07:07, Langer, Christoph wrote: >>>> Hi, >>>> >>>> please help reviewing the contribution of the support for the AIX >>>> Input >>> Method Editor (IME) in AWT's Input Method Framework. >>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.1/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201429 >>>> >>>> I took Ichiroh's initial proposal [1] and tried to integrate it >>>> better with >>> existing code. I have split >>> src/java.desktop/unix/classes/sun/awt/X11InputMethod.java into >>>> a) a base class containing the common code: >>> src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java >>>> b) a specific class for the common Linux/Unixes: >>> src/java.desktop/unix/classes/sun/awt/X11InputMethod.java and >>>> c) a specific class for AIX: >>> src/java.desktop/aix/classes/sun/awt/X11InputMethod.java >>>> The AIX specific additions to the native code of >>> src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c were >>> so >>> much that I decided to add a specific implementation file for AIX: >>> src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod_aix.c. >>> The >>> changes to the former file are some cleanups. >>>> I'm still in the process of testing the changes - but maybe you can >>>> run >>> further tests, especially on non-AIX unixes to make sure we didn't >>> break >>> something. >>>> Thanks & Best regards >>>> Christoph >>>> >>>> [1]: http://mail.openjdk.java.net/pipermail/awt-dev/2018- >>> April/013869.html From philip.race at oracle.com Mon May 14 17:08:24 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 14 May 2018 10:08:24 -0700 Subject: [11] Review Request: JDK-8196616 java/awt/GraphicsDevice/DisplayModes/CompareToXrandrTest.java fails In-Reply-To: References: <117ef21f-bc9d-3f28-a3cd-90eecda356c9@oracle.com> Message-ID: This works on my system. +1 -phil. On 05/10/2018 01:30 PM, Pankaj Bansal wrote: > > Hi Phil, > > Thanks for the quick review. > > < use takeWhile() which > < internal buffer > < BufferedReader/BufferedWriter ? > > Yes that makes much more sense. I have removed takeWhile as I think > filter should do the work here. There will not be need to ignore any line. > > I have also used the try-with-resource as suggested. > > Webrev: > > http://cr.openjdk.java.net/~pbansal/8196616/webrev.01/ > > > Regards, > > Pankaj Bansal > > *From:*Phil Race > *Sent:* Friday, May 11, 2018 12:59 AM > *To:* Pankaj Bansal; awt-dev at openjdk.java.net > *Subject:* Re: [11] Review Request: JDK-8196616 > java/awt/GraphicsDevice/DisplayModes/CompareToXrandrTest.java fails > > Execing xrandr twice ? Can't we either just re-write the code to not > use takeWhile() which > is part of the problem, or less desirably store the results into an > internal buffer > and read it from there using StringReader/StringWriter - wrapped in > BufferedReader/BufferedWriter ? > > Also I think you should use try-with-resources on the reading from the > "real" stream. > > And a style point : > > while((line = reader.readLine()) != null) { > -> > while ((line = reader.readLine()) != null) { > > > -phil. > > > On 05/10/2018 12:21 PM, Pankaj Bansal wrote: > > Hi All, Please review test fix for the below bug: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196616 > > Webrev: http://cr.openjdk.java.net/~pbansal/8196616/webrev.00/ > > > The test case create a BufferedReader and this BufferedReader is > used to find XRanderModes and JavaModes and compare them. > > It is assumed in this test that the first two lines of the > BufferedReader don?t have the useful mode data and contain some > other information. So it ignores first two lines. But this is not > always true and test may have to ignore more or less lines > depending upon the data. > > Made changes to the test to check how many lines should be > ignored, instead of hard coding the number of lines to ignore. > > Regards, > Pankaj Bansal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From javalists at cbfiddle.com Mon May 14 21:01:55 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Mon, 14 May 2018 14:01:55 -0700 Subject: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors In-Reply-To: <2384DD98-D388-4200-96CB-E81D2B054F25@cbfiddle.com> References: <95521a57-5afa-52bf-b35a-c866479289a7@oracle.com> <22D883A4-B362-411D-82F7-76A418487ADE@cbfiddle.com> <35F57A44-F3B1-484B-9A88-66849FFA9E47@cbfiddle.com> <60f03131-a79d-ed9a-d86d-3ea4be8184c2@oracle.com> <2384DD98-D388-4200-96CB-E81D2B054F25@cbfiddle.com> Message-ID: <2696BB8F-83BC-4AC4-8275-5AAA14809B5F@cbfiddle.com> Please review this revised webrev, which contains changes to the test program per Sergey?s comments. Thank you. Alan http://cr.openjdk.java.net/~serb/alans/8194327/webrev.02 https://bugs.openjdk.java.net/browse/JDK-8194327 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon May 14 21:51:39 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 14 May 2018 14:51:39 -0700 Subject: [11] RFR JDK-8202824: Cleanup discrepancies in ProblemList for java_awt jtreg tests In-Reply-To: References: Message-ID: Looks fine. On 14/05/2018 00:09, Jayathirth D V wrote: > Hello All, > > Please review the following fix in JDK11 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-8202824 > > Webrev : http://cr.openjdk.java.net/~jdv/8202824/webrev.00/ > > _Issue:_ There are some discrepancies in java_awt part of ProblemList > like bud ID typo, invalid bug id. > > _Solution:_ I have verified test cases in multiple platform and > added/removed/updated java_awt ProblemList content. Detailed comment > with clarifications is present in JBS bug. > > Thanks, > > Jay > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon May 14 21:58:35 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 14 May 2018 14:58:35 -0700 Subject: [11] JDK-8169187: [macosx] Aqua: java/awt/image/multiresolution/MultiresolutionIconTest.java In-Reply-To: References: <4a3c7e37-d16f-1bc3-3273-a24db91b1cca@oracle.com> Message-ID: <95f3f2b3-b82c-9a2b-de30-15403a710ff6@oracle.com> On 13/05/2018 23:55, shashidhara.veerabhadraiah at oracle.com wrote: > As you can see here, it is possible to have different colors for each > sub pixel, but the getPixelColor() will invariably choose only the first > pixel color. Then it is unclear why the colors are different for different pixels, since the test draws opaque red/blue rectangles. > > Thanks and regards, > > Shashi > > > On 13/05/18 12:04 PM, Sergey Bylokhov wrote: >> On 12/05/2018 21:47, shashidhara.veerabhadraiah at oracle.com wrote: >>> Hi Sergey, Small correction. If the HiDpi factor is 3, then assuming >>> uniform scaling on x and y, it will be a 3 * 3 area representing a >>> single coordinate point. getPixelColor() will always pick the first >>> point color but the createScreenCapture() would pick the closest one >>> pixel among the 3 * 3. >> >> But getPixelColor() will return the real pixel which was painted by >> the test on the screen. If the test will draw blue/red square then >> getPixelColor() should return blue/red pixel(even if it was the first >> left/top pixel in the point). >> >> >>> >>> Thanks and regards, >>> >>> Shashi >>> >>> >>> On 12/05/18 9:45 PM, shashidhara.veerabhadraiah at oracle.com wrote: >>>> Hi Sergey, I read that slightly different. The getPixelColor() would >>>> not be accurate but createScreenCapture() works differently but >>>> advantageous to us. The reason for that is that if we have a HiDpi >>>> factor screen of say 3, then actually 3 sub pixels forms each >>>> particular location. The getPixelColor() would always choose the >>>> first pixel(0th) whereas createScreenCapture() since it converts to >>>> low res image using the nearest neighbor, it would choose the color >>>> of the most nearest point for that particular location. >>>> >>>> We don't need the information of the 3 pixel color info but since >>>> the limitation of getPixelColor() is that it can return only one >>>> color and that color should actually be closest to that particular >>>> location. But instead we always return the first pixel color. On the >>>> other hand, createScreenCapture() would choose the closest pixel out >>>> of the 3 pixel color info, which is required in our case. >>>> >>>> This is what I felt out of the 2 ways, please let me know what do >>>> you think of this. >>>> >>>> Thanks and regards, >>>> >>>> Shashi >>>> >>>> >>>> On 12/05/18 4:38 AM, Sergey Bylokhov wrote: >>>>> Hi, Shashi. >>>>> It means that the updated test will not trust getPixelColor() which >>>>> returns exact color which is drawn on the screen, but will trust >>>>> createScreenCapture() which will apply transformation of the actual >>>>> color. This looks odd. >>>>> >>>>> On 11/05/2018 00:45, shashidhara.veerabhadraiah at oracle.com wrote: >>>>>> 1. In this case we will be using the low resolution variant of the >>>>>> image that was captured. >>>>>> >>>>>> 2. The low resolution variant was created from the high resolution >>>>>> image that was actually captured from an high res display. This is >>>>>> done using the nearest neighbor interpolation which actually >>>>>> chooses the most nearest point's value and ignores the other >>>>>> points values completely. >>>>>> >>>>>> This may be a reason to get a different color for the said pixel. >>>>>> >>>>>> >>>>>> By using the getPixelColor(): >>>>>> >>>>>> 1. This calls the getRGBPixel(). >>>>>> >>>>>> 2. Here we return only the 0th pixel color ignoring the scaling >>>>>> effect in the case of hidpi display units, where there may be many >>>>>> sub pixels for the given user space coordinates. >>>>>> >>>>>> This may be the reason for getting failed here. >>>>>> >>>>>> >>>>>> Thanks and regards, >>>>>> >>>>>> Shashi >>>>>> >>>>>> >>>>>> On 11/05/18 2:39 AM, Sergey Bylokhov wrote: >>>>>>> Hi, Shashi. >>>>>>> >>>>>>> On 10/05/2018 08:40, Shashidhara Veerabhadraiah wrote: >>>>>>>> The test was failing because of the color value mismatches, the >>>>>>>> fix is to get an image of the part of the window for which color >>>>>>>> needs to be fetched from the image pixel. >>>>>>> >>>>>>> Can you please clarify why r.getPixelColor(x, y) returns >>>>>>> incorrect color and r.createScreenCapture(bouns{x,y,1,1}) will >>>>>>> work, since internally both of these methods are use the same >>>>>>> method CRobot.getRGBPixels() >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> > -- Best regards, Sergey. From manajit.halder at oracle.com Tue May 15 06:52:14 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Tue, 15 May 2018 12:22:14 +0530 Subject: [11] Review Request: JDK-8196616 java/awt/GraphicsDevice/DisplayModes/CompareToXrandrTest.java fails In-Reply-To: References: <117ef21f-bc9d-3f28-a3cd-90eecda356c9@oracle.com> Message-ID: <152F906F-92BF-49FC-8D04-BE9B6C227F5D@oracle.com> Looks good to me Regards, Manajit > On 14-May-2018, at 10:38 PM, Phil Race wrote: > > This works on my system. > > +1 > > -phil. > > On 05/10/2018 01:30 PM, Pankaj Bansal wrote: >> Hi Phil, >> >> Thanks for the quick review. >> >> <> <> <> Yes that makes much more sense. I have removed takeWhile as I think filter should do the work here. There will not be need to ignore any line. <> >> I have also used the try-with-resource as suggested. >> Webrev: >> http://cr.openjdk.java.net/~pbansal/8196616/webrev.01/ >> >> >> Regards, >> Pankaj Bansal >> From: Phil Race >> Sent: Friday, May 11, 2018 12:59 AM >> To: Pankaj Bansal; awt-dev at openjdk.java.net >> Subject: Re: [11] Review Request: JDK-8196616 java/awt/GraphicsDevice/DisplayModes/CompareToXrandrTest.java fails >> >> Execing xrandr twice ? Can't we either just re-write the code to not use takeWhile() which >> is part of the problem, or less desirably store the results into an internal buffer >> and read it from there using StringReader/StringWriter - wrapped in BufferedReader/BufferedWriter ? >> >> Also I think you should use try-with-resources on the reading from the "real" stream. >> >> And a style point : >> while((line = reader.readLine()) != null) { >> -> >> while ((line = reader.readLine()) != null) { >> >> -phil. >> >> >> >> On 05/10/2018 12:21 PM, Pankaj Bansal wrote: >> Hi All, Please review test fix for the below bug: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196616 >> >> Webrev: http://cr.openjdk.java.net/~pbansal/8196616/webrev.00/ >> >> >> The test case create a BufferedReader and this BufferedReader is used to find XRanderModes and JavaModes and compare them. >> It is assumed in this test that the first two lines of the BufferedReader don?t have the useful mode data and contain some other information. So it ignores first two lines. But this is not always true and test may have to ignore more or less lines depending upon the data. >> >> Made changes to the test to check how many lines should be ignored, instead of hard coding the number of lines to ignore. >> >> Regards, >> Pankaj Bansal >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manajit.halder at oracle.com Tue May 15 12:19:34 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Tue, 15 May 2018 17:49:34 +0530 Subject: [11] Review request for JDK-8202841: [macosx] test java/awt/Graphics/LCDTextAndGraphicsState.java fails In-Reply-To: <5AF4D3F7.5080701@oracle.com> References: <5AF4D3F7.5080701@oracle.com> Message-ID: Hi Phil, My observation on test written using manual=yesno: Found approximately 56 tests containing manual=yesno in awt/ tests. Among these 40 are written using applet and 16 are printing tests (awt/print and awt/PrintJob). All the printing test with manual=yesno fails with the same, whereas applet test were working fine. Error: "error "test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno? Jtreg version used: jtreg, version 4.2 dev 380 JDK version: JDK 11 local build Regards, Manajit > On 11-May-2018, at 4:51 AM, Philip Race wrote: > > So according to http://openjdk.java.net/jtreg/tag-spec.html this tag is legal and correct > > /manual[=(yesno|done)] > ... > If "yesno" is given, then the harness will ask the user whether the action is to pass or fail. > > But it seems this is only implemented for applets. > > So are those other strings applets or main programs. > > -phil. > > On 5/10/18, 1:58 PM, Sergey Bylokhov wrote: >> Hi, Manajit. >> Did you check other tests with such typos? >> I found the same strings in our repo. >> >> On 10/05/2018 04:59, Manajit Halder wrote: >>> Hi Phil, >>> >>> Please review the test fix for JDK11. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8202841 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mhalder/8202841/webrev.00/ >>> >>> Issue: >>> Test fails due jtreg tag manual=yesno with error ?Parse Exception: Arguments to `manual' option not supported: yesno? >>> >>> Fix: >>> Removed itreg tag manual=yesno and changed the test to a manual test with instructions >>> >>> Regards, >>> Manajit >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed May 16 16:15:54 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 16 May 2018 09:15:54 -0700 Subject: [11] Review request for JDK-8202841: [macosx] test java/awt/Graphics/LCDTextAndGraphicsState.java fails In-Reply-To: References: <5AF4D3F7.5080701@oracle.com> Message-ID: <6dd56b0f-4570-b9c9-2753-8af3fe60f2fa@oracle.com> Hopefully we can update all 16 tests with the boilerplate developed for this test. One thing that I think needs to change here, is that using interrupt() as a way to signal the main thread doesn't seem ideal. You can either use a semaphore or it can use a sleep loop waiting for a flag to be set. -phil. On 05/15/2018 05:19 AM, Manajit Halder wrote: > Hi Phil, > > My observation on test written using manual=yesno: > > Found approximately 56 tests containing manual=yesno in awt/ tests. > Among these 40 are written using applet and 16 are printing tests > (awt/print and awt/PrintJob). > All the printing test with manual=yesno fails with the same, whereas > applet test were working fine. > > Error: "error "test result: Error. Parse Exception: Arguments to > `manual' option not supported: yesno? > > Jtreg version used: jtreg, version 4.2 dev 380 > JDK version: JDK 11 local build > > Regards, > Manajit > >> On 11-May-2018, at 4:51 AM, Philip Race > > wrote: >> >> So according to http://openjdk.java.net/jtreg/tag-spec.html this tag >> is legal and correct >> >> /manual[=(yesno|done)] >> ... >> If "yesno" is given, then the harness will ask the user whether the >> action is to pass or fail. >> >> But it seems this is only implemented for applets. >> >> So are those other strings applets or main programs. >> >> -phil. >> >> On 5/10/18, 1:58 PM, Sergey Bylokhov wrote: >>> Hi, Manajit. >>> Did you check other tests with such typos? >>> I found the same strings in our repo. >>> >>> On 10/05/2018 04:59, Manajit Halder wrote: >>>> Hi Phil, >>>> >>>> Please review the test fix for JDK11. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8202841 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mhalder/8202841/webrev.00/ >>>> >>>> Issue: >>>> Test fails due jtreg tag manual=yesno with error ?Parse Exception: >>>> Arguments to `manual' option not supported: yesno? >>>> >>>> Fix: >>>> Removed itreg tag manual=yesno and changed the test to a manual >>>> test with instructions >>>> >>>> Regards, >>>> Manajit >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed May 16 16:18:55 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 16 May 2018 09:18:55 -0700 Subject: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors In-Reply-To: <2696BB8F-83BC-4AC4-8275-5AAA14809B5F@cbfiddle.com> References: <95521a57-5afa-52bf-b35a-c866479289a7@oracle.com> <22D883A4-B362-411D-82F7-76A418487ADE@cbfiddle.com> <35F57A44-F3B1-484B-9A88-66849FFA9E47@cbfiddle.com> <60f03131-a79d-ed9a-d86d-3ea4be8184c2@oracle.com> <2384DD98-D388-4200-96CB-E81D2B054F25@cbfiddle.com> <2696BB8F-83BC-4AC4-8275-5AAA14809B5F@cbfiddle.com> Message-ID: Looks fine. cc build-dev to review changes in the make file. On 14/05/2018 14:01, Alan Snyder wrote: > http://cr.openjdk.java.net/~serb/alans/8194327/webrev.02 > > https://bugs.openjdk.java.net/browse/JDK-8194327 -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed May 16 18:23:31 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 16 May 2018 11:23:31 -0700 Subject: [11] Review Request: 8201364 [macosx] Component.getLocation() gives inconsistent coordinate for a component at (0, 0) Message-ID: Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8201364 Webrev: http://cr.openjdk.java.net/~serb/8201364/webrev.00 Description: The bug occurs when the application tries to set location of the window to the point, where the window cannot be placed. For example if this is a place where menubar, dock, taskbar etc are located. We have a bug in our logic which updates the state of the component when the native window is moved. Usually we have these steps: 1 The app set bounds for window to (100,100). 2 The native window is moved to 100,100 or to any other location like 90,90 3 We get a notification from native and update the state of the peer to (100,100/90,90) and then update the component using the up-to-date native bounds(instead of bounds which were set by the app at step 1) When the bug is reproduced we have this steps: 1 The app set bounds for window to (0,0). 2 The native window is moved to 20,20, because 0,0 is a place for menubar. 3 We get a notification from native and update the state of the peer to (20,20) and then update the component using the up-to-date native bounds(instead of bounds which were set by the app at step 1) 4 The app set bounds for the window to (0,0) again. 5 The native window is NOT moved, but still located at 20,20. 6 Our code assume that the native window was not moved and because of that we do not update the bounds in the component(which were set at step 4) Note that this fix is for macOS, but the same bug exists on linux/solaris as well. I'll create a separate bug and will add it to the problem list in this fix. -- Best regards, Sergey. From erik.joelsson at oracle.com Wed May 16 18:51:57 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 16 May 2018 11:51:57 -0700 Subject: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors In-Reply-To: References: <95521a57-5afa-52bf-b35a-c866479289a7@oracle.com> <22D883A4-B362-411D-82F7-76A418487ADE@cbfiddle.com> <35F57A44-F3B1-484B-9A88-66849FFA9E47@cbfiddle.com> <60f03131-a79d-ed9a-d86d-3ea4be8184c2@oracle.com> <2384DD98-D388-4200-96CB-E81D2B054F25@cbfiddle.com> <2696BB8F-83BC-4AC4-8275-5AAA14809B5F@cbfiddle.com> Message-ID: <66abf74f-c1c9-2304-20ee-b68ffba8742d@oracle.com> Build changes look good. /Erik On 2018-05-16 09:18, Sergey Bylokhov wrote: > Looks fine. > cc build-dev to review changes in the make file. > > On 14/05/2018 14:01, Alan Snyder wrote: >> http://cr.openjdk.java.net/~serb/alans/8194327/webrev.02 >> >> https://bugs.openjdk.java.net/browse/JDK-8194327 > > From dmitry.markov at oracle.com Thu May 17 09:05:37 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Thu, 17 May 2018 10:05:37 +0100 Subject: [11] Review Request: 8201364 [macosx] Component.getLocation() gives inconsistent coordinate for a component at (0, 0) In-Reply-To: References: Message-ID: <662CD217-6875-4B39-97AB-8ADE7BD04A35@oracle.com> Hi Sergey, According to your fix replacSurfaceData() and updateMinimumSize() are invoked only if the graphics device has been changed or the peer has been resized: > 734 if (pResized || isNewDevice) { > 735 replaceSurfaceData(); > 736 updateMinimumSize(); > 737 } Shall we also check tResized in the statement above, (i.e. take into account changes in the target's size)? Thanks, Dmitry > On 16 May 2018, at 19:23, Sergey Bylokhov wrote: > > Hello. > Please review the fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201364 > Webrev: http://cr.openjdk.java.net/~serb/8201364/webrev.00 > > Description: > The bug occurs when the application tries to set location of the window to the point, where the window cannot be placed. For example if this is a place where menubar, dock, taskbar etc are located. > > We have a bug in our logic which updates the state of the component when the native window is moved. Usually we have these steps: > 1 The app set bounds for window to (100,100). > 2 The native window is moved to 100,100 or to any other location like 90,90 > 3 We get a notification from native and update the state of the peer to (100,100/90,90) and then update the component using the up-to-date native bounds(instead of bounds which were set by the app at step 1) > > When the bug is reproduced we have this steps: > 1 The app set bounds for window to (0,0). > 2 The native window is moved to 20,20, because 0,0 is a place for menubar. > 3 We get a notification from native and update the state of the peer to (20,20) and then update the component using the up-to-date native bounds(instead of bounds which were set by the app at step 1) > 4 The app set bounds for the window to (0,0) again. > 5 The native window is NOT moved, but still located at 20,20. > 6 Our code assume that the native window was not moved and because of that we do not update the bounds in the component(which were set at step 4) > > Note that this fix is for macOS, but the same bug exists on linux/solaris as well. I'll create a separate bug and will add it to the problem list in this fix. > > > -- > Best regards, Sergey. From takiguc at linux.vnet.ibm.com Thu May 17 11:18:28 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 17 May 2018 20:18:28 +0900 Subject: Proposal:AIX's CDE/MWM support Message-ID: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com> Hello, IBM would like to contribute AIX's CDE (Common Desktop Environment) DTWM (Desktop Window Manager) /MWM (Motif Window Manager) support to OpenJDK project. I'd like contribute following 5 files: M src/java.desktop/share/classes/sun/font/FontUtilities.java (Add isAIX flag to determine AIX platform for GUI environment) M src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java (Add High Color support on CDE, OpenJDK just supports Medium Color) [1] M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java (Avoid miss calculation for window position under DTWM/MWM by XMapRaised/XMapWindow) M src/java.desktop/unix/classes/sun/awt/X11/XWM.java (Detect MWM on AIX platform) M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java (Add non-focusable window support on DTWM/MWM for AIX, because DTWM/MWM does not have enough features for ICCCM) I appreciate any feedback please, and how I would go about obtaining a sponsor and contributor ? Thanks, Ichiroh Takiguchi IBM Japan, Ltd. [1] https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html From philip.race at oracle.com Thu May 17 16:00:52 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 17 May 2018 09:00:52 -0700 Subject: Proposal:AIX's CDE/MWM support In-Reply-To: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com> References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com> Message-ID: I think we'd need to see the actual proposed changes and understand the implications for ongoing support as we no longer support any platform which has a CDE desktop. Solaris 11.3 uses Gnome, so we'd be more inclined to be ripping out such support rather than adding to it. -phil. On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote: > Hello, > IBM would like to contribute AIX's CDE (Common Desktop Environment) > DTWM (Desktop Window Manager) /MWM (Motif Window Manager) support to > OpenJDK project. > > I'd like contribute following 5 files: > > M src/java.desktop/share/classes/sun/font/FontUtilities.java > (Add isAIX flag to determine AIX platform for GUI environment) > M src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java > (Add High Color support on CDE, OpenJDK just supports Medium Color) [1] > M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java > (Avoid miss calculation for window position under DTWM/MWM by > XMapRaised/XMapWindow) > M src/java.desktop/unix/classes/sun/awt/X11/XWM.java > (Detect MWM on AIX platform) > M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java > (Add non-focusable window support on DTWM/MWM for AIX, because > DTWM/MWM does not have enough features for ICCCM) > > I appreciate any feedback please, and how I would go about obtaining a > sponsor and contributor ? > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > [1] > https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html > From Sergey.Bylokhov at oracle.com Thu May 17 18:25:45 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 May 2018 11:25:45 -0700 Subject: [11] Review Request: 8201364 [macosx] Component.getLocation() gives inconsistent coordinate for a component at (0, 0) In-Reply-To: <662CD217-6875-4B39-97AB-8ADE7BD04A35@oracle.com> References: <662CD217-6875-4B39-97AB-8ADE7BD04A35@oracle.com> Message-ID: <54310a21-ef5f-e0a0-87ca-db293ed00a9e@oracle.com> On 17/05/2018 02:05, Dmitry Markov wrote: > Hi Sergey, > > According to your fix replacSurfaceData() and updateMinimumSize() are invoked only if the graphics device has been changed or the peer has been resized: > >> 734 if (pResized || isNewDevice) { >> 735 replaceSurfaceData(); >> 736 updateMinimumSize(); >> 737 } > > Shall we also check tResized in the statement above, (i.e. take into account changes in the target's size)? Both of these methods bounds to the peer object(the size of NSWindow), and should be called when the peer is resized. - surfaceData should be updated because its size should be equal to the size of NSWindow. - updateMinimumSize should be called because it is depends on the MaxTextureHeight of the peer's LWGraphicsConfig -- Best regards, Sergey. From dmitry.markov at oracle.com Thu May 17 18:35:00 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Thu, 17 May 2018 19:35:00 +0100 Subject: [11] Review Request: 8201364 [macosx] Component.getLocation() gives inconsistent coordinate for a component at (0, 0) In-Reply-To: <54310a21-ef5f-e0a0-87ca-db293ed00a9e@oracle.com> References: <662CD217-6875-4B39-97AB-8ADE7BD04A35@oracle.com> <54310a21-ef5f-e0a0-87ca-db293ed00a9e@oracle.com> Message-ID: <9ACFB1E7-8A12-49B3-A866-8C7CB7865C1E@oracle.com> > On 17 May 2018, at 19:25, Sergey Bylokhov wrote: > > On 17/05/2018 02:05, Dmitry Markov wrote: >> Hi Sergey, >> According to your fix replacSurfaceData() and updateMinimumSize() are invoked only if the graphics device has been changed or the peer has been resized: >>> 734 if (pResized || isNewDevice) { >>> 735 replaceSurfaceData(); >>> 736 updateMinimumSize(); >>> 737 } >> Shall we also check tResized in the statement above, (i.e. take into account changes in the target's size)? > > Both of these methods bounds to the peer object(the size of NSWindow), and should be called when the peer is resized. > - surfaceData should be updated because its size should be equal to the size of NSWindow. > - updateMinimumSize should be called because it is depends on the MaxTextureHeight of the peer's LWGraphicsConfig So if I got you right, it is not necessary to call these methods if the target has been resized. In other words we should NOT change the if-statement FROM: if (pResized || isNewDevice) TO: if (pResized || tResized || isNewDevice) Is my understanding correct? Thanks, Dmitry > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu May 17 19:04:49 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 May 2018 12:04:49 -0700 Subject: [11] Review Request: 8201364 [macosx] Component.getLocation() gives inconsistent coordinate for a component at (0, 0) In-Reply-To: <9ACFB1E7-8A12-49B3-A866-8C7CB7865C1E@oracle.com> References: <662CD217-6875-4B39-97AB-8ADE7BD04A35@oracle.com> <54310a21-ef5f-e0a0-87ca-db293ed00a9e@oracle.com> <9ACFB1E7-8A12-49B3-A866-8C7CB7865C1E@oracle.com> Message-ID: On 17/05/2018 11:35, Dmitry Markov wrote: > So if I got you right, it is not necessary to call these methods if the > target has been resized. In other words we should NOT change the > if-statement > FROM: > if (pResized || isNewDevice) > TO: > if (pResized || *tResized *|| isNewDevice) > Is my understanding correct? Yes, correct. -- Best regards, Sergey. From dmitry.markov at oracle.com Thu May 17 19:17:27 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Thu, 17 May 2018 20:17:27 +0100 Subject: [11] Review Request: 8201364 [macosx] Component.getLocation() gives inconsistent coordinate for a component at (0, 0) In-Reply-To: References: <662CD217-6875-4B39-97AB-8ADE7BD04A35@oracle.com> <54310a21-ef5f-e0a0-87ca-db293ed00a9e@oracle.com> <9ACFB1E7-8A12-49B3-A866-8C7CB7865C1E@oracle.com> Message-ID: <747B52E9-6C92-4877-A33C-6DE39B1CB20C@oracle.com> > On 17 May 2018, at 20:04, Sergey Bylokhov wrote: > > On 17/05/2018 11:35, Dmitry Markov wrote: >> So if I got you right, it is not necessary to call these methods if the target has been resized. In other words we should NOT change the if-statement >> FROM: >> if (pResized || isNewDevice) >> TO: >> if (pResized || *tResized *|| isNewDevice) >> Is my understanding correct? > > Yes, correct. Thanks for explanation and confirmation. The fix looks good to me. Thanks, Dmitry > > > -- > Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu May 17 22:17:08 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 May 2018 15:17:08 -0700 Subject: [11] Review Request: 8203380 Missing platform and bug information for MouseModifiersInKeyEvent test Message-ID: Hello. Please review small fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8203380 There is no bug and platform information for this test in the problem list, but it should point to JDK-8157147 on linux/solaris. Since this test was added to the problem list in JDK-8202811 I assume it may hang on windows as well. Fix is inline below: --- a/test/jdk/ProblemList.txt Thu May 17 14:41:23 2018 -0700 +++ b/test/jdk/ProblemList.txt Thu May 17 15:16:22 2018 -0700 @@ -492,7 +492,7 @@ java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java 8203004 linux-all java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java 7107528 linux-all,macosx-all java/awt/Mouse/MouseDragEvent/MouseDraggedTest.java 8080676 linux-all -java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersInKeyEvent.java +java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersInKeyEvent.java 8157147 linux-all,solaris-all,windows-all java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick.html 8148041 linux-all java/awt/Toolkit/DesktopProperties/rfe4758438.java 8193547 linux-all java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java 6847163 -- Best regards, Sergey. From christoph.langer at sap.com Fri May 18 11:59:01 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 18 May 2018 11:59:01 +0000 Subject: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) In-Reply-To: <3e96ae93f38a3cfbcb584cf106f5297f@linux.vnet.ibm.com> References: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> <0cf8df6f-d5ad-9db2-8381-ccca9eaf6a5f@oracle.com> <6d6b9a02-3b81-6978-1104-c4b1c12f65a5@oracle.com> <3e96ae93f38a3cfbcb584cf106f5297f@linux.vnet.ibm.com> Message-ID: Hi all, Here is an updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/ Can someone from the graphics/awt team please have a look at that change? Especially checking that we don't break non-AIX platforms? Thanks in advance. @Ichiroh: Thanks for your review and tests. Adressing your points: > resetCompositionState() was missing in > src/java.desktop/aix/classes/sun/awt/X11InputMethod.java > ========================================================== > == > --- a/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Wed May > 09 09:05:32 2018 +0900 > +++ b/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Mon > May > 14 21:25:50 2018 +0900 > @@ -56,6 +56,21 @@ > } > > /** > + * Reset the composition state to the current composition state. > + */ > + protected void resetCompositionState() { > + if (compositionEnableSupported && haveActiveClient()) { > + try { > + /* Restore the composition mode to the last saved > composition > + mode. */ > + setCompositionEnabled(savedCompositionState); > + } catch (UnsupportedOperationException e) { > + compositionEnableSupported = false; > + } > + } > + } > + > + /** > * Activate input method. > */ > public synchronized void activate() { > ========================================================== Good catch. I've incorporated that in my new webrev. > Otherwise, > we could not find out any functional difference on Linux. > we could not find out any functional difference between our modified code and your code on AIX. > > By code check, we found following difference. > ========================================================== > == > --- a/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c > Wed May 09 09:05:32 2018 +0900 > +++ b/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c > Mon May 14 21:25:50 2018 +0900 > @@ -248,6 +248,10 @@ > "flushText", > "()V"); > JNU_CHECK_EXCEPTION_RETURN(env, NULL); > + if ((*env)->ExceptionOccurred(env)) { > + (*env)->ExceptionDescribe(env); > + (*env)->ExceptionClear(env); > + } > /* IMPORTANT: > The order of the following calls is critical since > "imInstance" may > point to the global reference itself, if > "freeX11InputMethodData" is called > ========================================================== > > Did you remove this code intentionally ? Yes, I removed that one intentionally. There is no point in doing the Exception check/clearing after a call to JNU_CHECK_EXCEPTION_RETURN(env, NULL); > Otherwise, I think the other changes were acceptable. ?? Thanks and Best regards Christoph From takiguc at linux.vnet.ibm.com Fri May 18 17:48:25 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Sat, 19 May 2018 02:48:25 +0900 Subject: Proposal:AIX's CDE/MWM support In-Reply-To: References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com> Message-ID: Hello Phil. Webrev.zip file is stored into http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip Test programs are also stored: No testcase is available for FontUtilities.java and XDecoratedPeer.java. MotifColorUtilities.java http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java Run SystemColorTest2, system colors should be displayed AIX sample is http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt XWM.java http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java On AIX CDE, isMotif and isCDE were true. On AIX MWM, every entry is false. XWindowPeer.java http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java On AIX CDE, click inside of "Non-Focusable" window (not window frame). Window focus should not be changed because of "click on focus" feature. But input focus is moved to "Non-Focusable" window. On 2018-05-18 01:00, Phil Race wrote: > I think we'd need to see the actual proposed changes and understand > the implications > for ongoing support as we no longer support any platform which has a > CDE desktop. > Solaris 11.3 uses Gnome, so we'd be more inclined to be ripping out > such support rather > than adding to it. > > -phil. > > On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote: >> Hello, >> IBM would like to contribute AIX's CDE (Common Desktop Environment) >> DTWM (Desktop Window Manager) /MWM (Motif Window Manager) support to >> OpenJDK project. >> >> I'd like contribute following 5 files: >> >> M src/java.desktop/share/classes/sun/font/FontUtilities.java >> (Add isAIX flag to determine AIX platform for GUI environment) >> M src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java >> (Add High Color support on CDE, OpenJDK just supports Medium Color) >> [1] >> M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java >> (Avoid miss calculation for window position under DTWM/MWM by >> XMapRaised/XMapWindow) >> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java >> (Detect MWM on AIX platform) >> M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java >> (Add non-focusable window support on DTWM/MWM for AIX, because >> DTWM/MWM does not have enough features for ICCCM) >> >> I appreciate any feedback please, and how I would go about obtaining a >> sponsor and contributor ? >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> [1] >> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html >> From Sergey.Bylokhov at oracle.com Fri May 18 19:04:33 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 18 May 2018 12:04:33 -0700 Subject: [11] Review Request: 8196030 and 8190326 Message-ID: <2eeef2ce-6170-71d5-0e1b-0fbc66265873@oracle.com> Hello. Please review the fix for jdk11. Bugs: AWT Robot mouseMove fails on Windows 10 1709 with HiDPI https://bugs.openjdk.java.net/browse/JDK-8196030 https://bugs.openjdk.java.net/browse/JDK-8190326 Webrev: http://cr.openjdk.java.net/~serb/8201364/webrev.00 Description: -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri May 18 19:09:48 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 18 May 2018 12:09:48 -0700 Subject: [11] Review Request: 8196030 and 8190326 In-Reply-To: <2eeef2ce-6170-71d5-0e1b-0fbc66265873@oracle.com> References: <2eeef2ce-6170-71d5-0e1b-0fbc66265873@oracle.com> Message-ID: <3e038e93-63d6-d7e8-fedf-52cfa51104ff@oracle.com> Sorry, I have accidentally pressed send button, I will send correct request soon. On 18/05/2018 12:04, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11. > > Bugs: > ??? AWT Robot mouseMove fails on Windows 10 1709 with HiDPI > ??? https://bugs.openjdk.java.net/browse/JDK-8196030 > ??? https://bugs.openjdk.java.net/browse/JDK-8190326 > Webrev: http://cr.openjdk.java.net/~serb/8201364/webrev.00 > > Description: > > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri May 18 19:38:02 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 18 May 2018 12:38:02 -0700 Subject: [11] Review Request: 8196030 and 8190326 Message-ID: <43d2cc9f-70c4-1f9f-7b72-0a7bff45d495@oracle.com> Hello. Please review the fix for jdk11. Bugs: 8196030: AWT Robot mouseMove fails on Windows 10 1709 with HiDPI https://bugs.openjdk.java.net/browse/JDK-8196030 8190326: Robot.mouseMove uses scaling factor of main display on unscaled second display https://bugs.openjdk.java.net/browse/JDK-8190326 Webrev: http://cr.openjdk.java.net/~serb/8196030/webrev.04 Description: This change will fix two issues: - 8196030: In the Windows 10 relative mouse moving is broken. Solution is to change the code to use the absolute mouse location. Actually the fix reverts the changes which were done in JDK-4288230 [1](It is interesting that previously the absolute mouse position was broken). Take a look to the function which is used to calculate the mouse position, this is the only way I found to align coordinates which passed to windows(::SendInput() and coordinate which returned by windows(::GetCursorPos(). - 8190326: the logic how we convert coordinates from the user space to device space is changed. Previously we use the transformation of the main screen, now we will find the appropriate screen(where coordinates are located) and then use transformation of this screen. I have tested the fix on win7/10 using scales:100%,125%,%150,%175,%200 in multi-monitor configuration. But the new test is quite strict and may fail if there are some rounding error in some variations of screen resolution+scale+screen locations. So I expect some reports for this test. Notes: - The logic in the new method in SwingUtilities2 is similar to Robot.createCompatibleImage(), but the new method uses Region.clipRound() instead of floor/ceil. The reason is that we use same logic in native. I think that Robot.createCompatibleImage() should use clipRound() as well. Will check this later in separate bug. - Similar but not the same bug exists in Robot.getPixelColor() which uses the scale of the main screen, and uses simple cast to (int), but it affects all platforms. Will check this later in separate bug. [1] https://bugs.openjdk.java.net/browse/JDK-4288230 -- Best regards, Sergey. From philip.race at oracle.com Sat May 19 23:53:19 2018 From: philip.race at oracle.com (Philip Race) Date: Sat, 19 May 2018 16:53:19 -0700 Subject: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) In-Reply-To: References: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> <0cf8df6f-d5ad-9db2-8381-ccca9eaf6a5f@oracle.com> <6d6b9a02-3b81-6978-1104-c4b1c12f65a5@oracle.com> <3e96ae93f38a3cfbcb584cf106f5297f@linux.vnet.ibm.com> Message-ID: <5B00B8EF.8000208@oracle.com> I think I am 99% OK with this. In general I see what you are doing here and how you've presented the webrev. Treating even the new files as moved helps see the differences but it is still a challenge to follow all the moving pieces. So before we had just abstract class unix/X11InputMethod <- class unix/XInputMethod Now we have abstract class unix/X11InputMethodBase / \ / \ / \ / \ abstract class unix/X11InputMethod abstract class aix/X11InputMethod \ / \ / \ / class unix/XInputMethod I have submitted a build job with this patch to make sure it all builds on Linux & Solaris .. and it was all fine. But testing for this would have to be manual, and I don't have cycles for that. So I'll have to accept that the testing done by IBM was enough So only minor comments ... http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java.sdiff.html 730 case 0: //None of the value is set by Wnn "value is " -> "values are " ? http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c.sdiff.html why did you move 26 #ifdef HEADLESS 27 #error This file should not be included in headless library 28 #endif I think it should be first. It is also missing from the equivalent AIX file but that is up to you .. I really didn't look any further at the AIX files. .. and there seems no point to moving around some of the other includes except to make the webrev harder to read :-) But good job cleaning up a lot of the formatting of the native code. -phil. On 5/18/18, 4:59 AM, Langer, Christoph wrote: > Hi all, > > Here is an updated webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/ > Can someone from the graphics/awt team please have a look at that change? Especially checking that we don't break non-AIX platforms? Thanks in advance. > > @Ichiroh: Thanks for your review and tests. Adressing your points: > >> resetCompositionState() was missing in >> src/java.desktop/aix/classes/sun/awt/X11InputMethod.java >> ========================================================== >> == >> --- a/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Wed May >> 09 09:05:32 2018 +0900 >> +++ b/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Mon >> May >> 14 21:25:50 2018 +0900 >> @@ -56,6 +56,21 @@ >> } >> >> /** >> + * Reset the composition state to the current composition state. >> + */ >> + protected void resetCompositionState() { >> + if (compositionEnableSupported&& haveActiveClient()) { >> + try { >> + /* Restore the composition mode to the last saved >> composition >> + mode. */ >> + setCompositionEnabled(savedCompositionState); >> + } catch (UnsupportedOperationException e) { >> + compositionEnableSupported = false; >> + } >> + } >> + } >> + >> + /** >> * Activate input method. >> */ >> public synchronized void activate() { >> ========================================================== > Good catch. I've incorporated that in my new webrev. > >> Otherwise, >> we could not find out any functional difference on Linux. >> we could not find out any functional difference between our modified code and your code on AIX. >> >> By code check, we found following difference. >> ========================================================== >> == >> --- a/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c >> Wed May 09 09:05:32 2018 +0900 >> +++ b/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c >> Mon May 14 21:25:50 2018 +0900 >> @@ -248,6 +248,10 @@ >> "flushText", >> "()V"); >> JNU_CHECK_EXCEPTION_RETURN(env, NULL); >> + if ((*env)->ExceptionOccurred(env)) { >> + (*env)->ExceptionDescribe(env); >> + (*env)->ExceptionClear(env); >> + } >> /* IMPORTANT: >> The order of the following calls is critical since >> "imInstance" may >> point to the global reference itself, if >> "freeX11InputMethodData" is called >> ========================================================== >> >> Did you remove this code intentionally ? > Yes, I removed that one intentionally. There is no point in doing the Exception check/clearing after a call to JNU_CHECK_EXCEPTION_RETURN(env, NULL); > >> Otherwise, I think the other changes were acceptable. > ?? > > Thanks and Best regards > Christoph > From manajit.halder at oracle.com Mon May 21 13:05:17 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Mon, 21 May 2018 18:35:17 +0530 Subject: [11] Review request for JDK-8202841: [macosx] test java/awt/Graphics/LCDTextAndGraphicsState.java fails In-Reply-To: <6dd56b0f-4570-b9c9-2753-8af3fe60f2fa@oracle.com> References: <5AF4D3F7.5080701@oracle.com> <6dd56b0f-4570-b9c9-2753-8af3fe60f2fa@oracle.com> Message-ID: Hi Phil, I have modified the code as per your suggestion. Removed interrupt() and instead of that added a sleep loop waiting for a flag to be set. Please review the changes http://cr.openjdk.java.net/~mhalder/8202841/webrev.01/ Thanks, Manajit > On 16-May-2018, at 9:45 PM, Phil Race wrote: > > Hopefully we can update all 16 tests with the boilerplate developed for this test. > One thing that I think needs to change here, is that using interrupt() as a way > to signal the main thread doesn't seem ideal. > You can either use a semaphore or it can use a sleep loop waiting for a flag to be set. > > -phil. > > > > On 05/15/2018 05:19 AM, Manajit Halder wrote: >> Hi Phil, >> >> My observation on test written using manual=yesno: >> >> Found approximately 56 tests containing manual=yesno in awt/ tests. Among these 40 are written using applet and 16 are printing tests (awt/print and awt/PrintJob). >> All the printing test with manual=yesno fails with the same, whereas applet test were working fine. >> >> Error: "error "test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno? >> >> Jtreg version used: jtreg, version 4.2 dev 380 >> JDK version: JDK 11 local build >> >> Regards, >> Manajit >> >>> On 11-May-2018, at 4:51 AM, Philip Race > wrote: >>> >>> So according to http://openjdk.java.net/jtreg/tag-spec.html this tag is legal and correct >>> >>> /manual[=(yesno|done)] >>> ... >>> If "yesno" is given, then the harness will ask the user whether the action is to pass or fail. >>> >>> But it seems this is only implemented for applets. >>> >>> So are those other strings applets or main programs. >>> >>> -phil. >>> >>> On 5/10/18, 1:58 PM, Sergey Bylokhov wrote: >>>> Hi, Manajit. >>>> Did you check other tests with such typos? >>>> I found the same strings in our repo. >>>> >>>> On 10/05/2018 04:59, Manajit Halder wrote: >>>>> Hi Phil, >>>>> >>>>> Please review the test fix for JDK11. >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8202841 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mhalder/8202841/webrev.00/ >>>>> >>>>> Issue: >>>>> Test fails due jtreg tag manual=yesno with error ?Parse Exception: Arguments to `manual' option not supported: yesno? >>>>> >>>>> Fix: >>>>> Removed itreg tag manual=yesno and changed the test to a manual test with instructions >>>>> >>>>> Regards, >>>>> Manajit >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon May 21 17:03:52 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 21 May 2018 10:03:52 -0700 Subject: [11] Review Request: 8196030 and 8190326 In-Reply-To: <43d2cc9f-70c4-1f9f-7b72-0a7bff45d495@oracle.com> References: <43d2cc9f-70c4-1f9f-7b72-0a7bff45d495@oracle.com> Message-ID: <78421a1d-c02a-7803-2a09-097325ec93c9@oracle.com> I don't understand why the new method is added in SwingUtilities2 instead of directly in WRobotPeer.java since a) This makes AWT internals depend on Swing internals. b) There's no other client of this method. -phil. On 05/18/2018 12:38 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11. > > Bugs: > 8196030: AWT Robot mouseMove fails on Windows 10 1709 with HiDPI > https://bugs.openjdk.java.net/browse/JDK-8196030 > 8190326: Robot.mouseMove uses scaling factor of main display on > unscaled second display > https://bugs.openjdk.java.net/browse/JDK-8190326 > > Webrev: http://cr.openjdk.java.net/~serb/8196030/webrev.04 > > Description: > This change will fix two issues: > - 8196030: In the Windows 10 relative mouse moving is broken. > Solution is to change the code to use the absolute mouse location. > Actually the fix reverts the changes which were done in JDK-4288230 > [1](It is interesting that previously the absolute mouse position was > broken). Take a look to the function which is used to calculate the > mouse position, this is the only way I found to align coordinates > which passed to windows(::SendInput() and coordinate which returned by > windows(::GetCursorPos(). > > - 8190326: the logic how we convert coordinates from the user space > to device space is changed. Previously we use the transformation of > the main screen, now we will find the appropriate screen(where > coordinates are located) and then use transformation of this screen. > > I have tested the fix on win7/10 using scales:100%,125%,%150,%175,%200 > in multi-monitor configuration. But the new test is quite strict and > may fail if there are some rounding error in some variations of screen > resolution+scale+screen locations. So I expect some reports for this > test. > > Notes: > - The logic in the new method in SwingUtilities2 is similar to > Robot.createCompatibleImage(), but the new method uses > Region.clipRound() instead of floor/ceil. The reason is that we use > same logic in native. I think that Robot.createCompatibleImage() > should use clipRound() as well. Will check this later in separate bug. > > - Similar but not the same bug exists in Robot.getPixelColor() which > uses the scale of the main screen, and uses simple cast to (int), but > it affects all platforms. Will check this later in separate bug. > > > [1] https://bugs.openjdk.java.net/browse/JDK-4288230 > From Sergey.Bylokhov at oracle.com Mon May 21 17:16:56 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 21 May 2018 10:16:56 -0700 Subject: [11] Review Request: 8196030 and 8190326 In-Reply-To: <78421a1d-c02a-7803-2a09-097325ec93c9@oracle.com> References: <43d2cc9f-70c4-1f9f-7b72-0a7bff45d495@oracle.com> <78421a1d-c02a-7803-2a09-097325ec93c9@oracle.com> Message-ID: <40c6b6c1-639b-e5b8-ac72-be2d67d047a6@oracle.com> This method call getGraphicsConfigurationAtPoint() which is located in the SwingUtilities2 and the robot class already depends on it: http://hg.openjdk.java.net/jdk/jdk/file/f4735ff8d17d/src/java.desktop/share/classes/java/awt/Robot.java#l508 On 21/05/2018 10:03, Phil Race wrote: > I don't understand why the new method is added in SwingUtilities2 instead > of directly in WRobotPeer.java since > a) This makes AWT internals depend on Swing internals. > b) There's no other client of this method. > > -phil. > > > On 05/18/2018 12:38 PM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk11. >> >> Bugs: >> ??? 8196030: AWT Robot mouseMove fails on Windows 10 1709 with HiDPI >> ??? https://bugs.openjdk.java.net/browse/JDK-8196030 >> ??? 8190326: Robot.mouseMove uses scaling factor of main display on >> unscaled second display >> ??? https://bugs.openjdk.java.net/browse/JDK-8190326 >> >> Webrev: http://cr.openjdk.java.net/~serb/8196030/webrev.04 >> >> Description: >> ?This change will fix two issues: >> ?- 8196030: In the Windows 10 relative mouse moving is broken. >> Solution is to change the code to use the absolute mouse location. >> Actually the fix reverts the changes which were done in JDK-4288230 >> [1](It is interesting that previously the absolute mouse position was >> broken). Take a look to the function which is used to calculate the >> mouse position, this is the only way I found to align coordinates >> which passed to windows(::SendInput() and coordinate which returned by >> windows(::GetCursorPos(). >> >> ?- 8190326: the logic how we convert coordinates from the user space >> to device space is changed. Previously we use the transformation of >> the main screen, now we will find the appropriate screen(where >> coordinates are located) and then use transformation of this screen. >> >> I have tested the fix on win7/10 using scales:100%,125%,%150,%175,%200 >> in multi-monitor configuration. But the new test is quite strict and >> may fail if there are some rounding error in some variations of screen >> resolution+scale+screen locations. So I expect some reports for this >> test. >> >> Notes: >> ?- The logic in the new method in SwingUtilities2 is similar to >> Robot.createCompatibleImage(), but the new method uses >> Region.clipRound() instead of floor/ceil. The reason is that we use >> same logic in native. I think that Robot.createCompatibleImage() >> should use clipRound() as well. Will check this later in separate bug. >> >> ?- Similar but not the same bug exists in Robot.getPixelColor() which >> uses the scale of the main screen, and uses simple cast to (int), but >> it affects all platforms. Will check this later in separate bug. >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-4288230 >> > -- Best regards, Sergey. From philip.race at oracle.com Mon May 21 17:44:02 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 21 May 2018 10:44:02 -0700 Subject: [11] Review Request: 8196030 and 8190326 In-Reply-To: <40c6b6c1-639b-e5b8-ac72-be2d67d047a6@oracle.com> References: <43d2cc9f-70c4-1f9f-7b72-0a7bff45d495@oracle.com> <78421a1d-c02a-7803-2a09-097325ec93c9@oracle.com> <40c6b6c1-639b-e5b8-ac72-be2d67d047a6@oracle.com> Message-ID: <0afadf13-acc9-3df8-1eb1-c8830b2c3831@oracle.com> Well I don't understand why that was put into SU2 either. Since it is also used just by the AWT Robot. It is from the fix for https://bugs.openjdk.java.net/browse/JDK-8176097 So I think these should both be moved out of SU2 and into Robot code. -phil. On 05/21/2018 10:16 AM, Sergey Bylokhov wrote: > This method call getGraphicsConfigurationAtPoint() which is located in > the SwingUtilities2 and the robot class already depends on it: > http://hg.openjdk.java.net/jdk/jdk/file/f4735ff8d17d/src/java.desktop/share/classes/java/awt/Robot.java#l508 > > > On 21/05/2018 10:03, Phil Race wrote: >> I don't understand why the new method is added in SwingUtilities2 >> instead >> of directly in WRobotPeer.java since >> a) This makes AWT internals depend on Swing internals. >> b) There's no other client of this method. >> >> -phil. >> >> >> On 05/18/2018 12:38 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk11. >>> >>> Bugs: >>> 8196030: AWT Robot mouseMove fails on Windows 10 1709 with HiDPI >>> https://bugs.openjdk.java.net/browse/JDK-8196030 >>> 8190326: Robot.mouseMove uses scaling factor of main display on >>> unscaled second display >>> https://bugs.openjdk.java.net/browse/JDK-8190326 >>> >>> Webrev: http://cr.openjdk.java.net/~serb/8196030/webrev.04 >>> >>> Description: >>> This change will fix two issues: >>> - 8196030: In the Windows 10 relative mouse moving is broken. >>> Solution is to change the code to use the absolute mouse location. >>> Actually the fix reverts the changes which were done in JDK-4288230 >>> [1](It is interesting that previously the absolute mouse position >>> was broken). Take a look to the function which is used to calculate >>> the mouse position, this is the only way I found to align >>> coordinates which passed to windows(::SendInput() and coordinate >>> which returned by windows(::GetCursorPos(). >>> >>> - 8190326: the logic how we convert coordinates from the user space >>> to device space is changed. Previously we use the transformation of >>> the main screen, now we will find the appropriate screen(where >>> coordinates are located) and then use transformation of this screen. >>> >>> I have tested the fix on win7/10 using >>> scales:100%,125%,%150,%175,%200 in multi-monitor configuration. But >>> the new test is quite strict and may fail if there are some rounding >>> error in some variations of screen resolution+scale+screen >>> locations. So I expect some reports for this test. >>> >>> Notes: >>> - The logic in the new method in SwingUtilities2 is similar to >>> Robot.createCompatibleImage(), but the new method uses >>> Region.clipRound() instead of floor/ceil. The reason is that we use >>> same logic in native. I think that Robot.createCompatibleImage() >>> should use clipRound() as well. Will check this later in separate bug. >>> >>> - Similar but not the same bug exists in Robot.getPixelColor() >>> which uses the scale of the main screen, and uses simple cast to >>> (int), but it affects all platforms. Will check this later in >>> separate bug. >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-4288230 >>> >> > > From Sergey.Bylokhov at oracle.com Mon May 21 18:28:30 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 21 May 2018 11:28:30 -0700 Subject: [11] Review Request: 8196030 and 8190326 In-Reply-To: <0afadf13-acc9-3df8-1eb1-c8830b2c3831@oracle.com> References: <43d2cc9f-70c4-1f9f-7b72-0a7bff45d495@oracle.com> <78421a1d-c02a-7803-2a09-097325ec93c9@oracle.com> <40c6b6c1-639b-e5b8-ac72-be2d67d047a6@oracle.com> <0afadf13-acc9-3df8-1eb1-c8830b2c3831@oracle.com> Message-ID: <459023ee-2056-6328-99a4-333fa0746149@oracle.com> It is also used by, Window peer on windows: http://hg.openjdk.java.net/jdk/jdk/file/f4735ff8d17d/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java#l662 I guess that unix peers should use it as well in the same way as on windows, actually all code which try to move something using x,y coordinates in user space should use this method. On 21/05/2018 10:44, Phil Race wrote: > Well I don't understand why that was put into SU2 either. > Since it is also used just by the AWT Robot. > It is from the fix for https://bugs.openjdk.java.net/browse/JDK-8176097 > > So I think these should both be moved out of SU2 and into Robot code. > > -phil. > > On 05/21/2018 10:16 AM, Sergey Bylokhov wrote: >> This method call getGraphicsConfigurationAtPoint() which is located in >> the SwingUtilities2 and the robot class already depends on it: >> http://hg.openjdk.java.net/jdk/jdk/file/f4735ff8d17d/src/java.desktop/share/classes/java/awt/Robot.java#l508 >> >> >> On 21/05/2018 10:03, Phil Race wrote: >>> I don't understand why the new method is added in SwingUtilities2 >>> instead >>> of directly in WRobotPeer.java since >>> a) This makes AWT internals depend on Swing internals. >>> b) There's no other client of this method. >>> >>> -phil. >>> >>> >>> On 05/18/2018 12:38 PM, Sergey Bylokhov wrote: >>>> Hello. >>>> Please review the fix for jdk11. >>>> >>>> Bugs: >>>> ??? 8196030: AWT Robot mouseMove fails on Windows 10 1709 with HiDPI >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8196030 >>>> ??? 8190326: Robot.mouseMove uses scaling factor of main display on >>>> unscaled second display >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8190326 >>>> >>>> Webrev: http://cr.openjdk.java.net/~serb/8196030/webrev.04 >>>> >>>> Description: >>>> ?This change will fix two issues: >>>> ?- 8196030: In the Windows 10 relative mouse moving is broken. >>>> Solution is to change the code to use the absolute mouse location. >>>> Actually the fix reverts the changes which were done in JDK-4288230 >>>> [1](It is interesting that previously the absolute mouse position >>>> was broken). Take a look to the function which is used to calculate >>>> the mouse position, this is the only way I found to align >>>> coordinates which passed to windows(::SendInput() and coordinate >>>> which returned by windows(::GetCursorPos(). >>>> >>>> ?- 8190326: the logic how we convert coordinates from the user space >>>> to device space is changed. Previously we use the transformation of >>>> the main screen, now we will find the appropriate screen(where >>>> coordinates are located) and then use transformation of this screen. >>>> >>>> I have tested the fix on win7/10 using >>>> scales:100%,125%,%150,%175,%200 in multi-monitor configuration. But >>>> the new test is quite strict and may fail if there are some rounding >>>> error in some variations of screen resolution+scale+screen >>>> locations. So I expect some reports for this test. >>>> >>>> Notes: >>>> ?- The logic in the new method in SwingUtilities2 is similar to >>>> Robot.createCompatibleImage(), but the new method uses >>>> Region.clipRound() instead of floor/ceil. The reason is that we use >>>> same logic in native. I think that Robot.createCompatibleImage() >>>> should use clipRound() as well. Will check this later in separate bug. >>>> >>>> ?- Similar but not the same bug exists in Robot.getPixelColor() >>>> which uses the scale of the main screen, and uses simple cast to >>>> (int), but it affects all platforms. Will check this later in >>>> separate bug. >>>> >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-4288230 >>>> >>> >> >> > -- Best regards, Sergey. From philip.race at oracle.com Mon May 21 18:52:48 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 21 May 2018 11:52:48 -0700 Subject: [11] Review Request: 8196030 and 8190326 In-Reply-To: <459023ee-2056-6328-99a4-333fa0746149@oracle.com> References: <43d2cc9f-70c4-1f9f-7b72-0a7bff45d495@oracle.com> <78421a1d-c02a-7803-2a09-097325ec93c9@oracle.com> <40c6b6c1-639b-e5b8-ac72-be2d67d047a6@oracle.com> <0afadf13-acc9-3df8-1eb1-c8830b2c3831@oracle.com> <459023ee-2056-6328-99a4-333fa0746149@oracle.com> Message-ID: <5c4dad2b-9956-42ae-8716-89b3ea14abf1@oracle.com> All the actual cases seem to be in AWT so we should put these somewhere in AWT, not SU2. -phil. On 05/21/2018 11:28 AM, Sergey Bylokhov wrote: > It is also used by, Window peer on windows: > http://hg.openjdk.java.net/jdk/jdk/file/f4735ff8d17d/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java#l662 > > > I guess that unix peers should use it as well in the same way as on > windows, actually all code which try to move something using x,y > coordinates in user space should use this method. > > On 21/05/2018 10:44, Phil Race wrote: >> Well I don't understand why that was put into SU2 either. >> Since it is also used just by the AWT Robot. >> It is from the fix for https://bugs.openjdk.java.net/browse/JDK-8176097 >> >> So I think these should both be moved out of SU2 and into Robot code. >> >> -phil. >> >> On 05/21/2018 10:16 AM, Sergey Bylokhov wrote: >>> This method call getGraphicsConfigurationAtPoint() which is located >>> in the SwingUtilities2 and the robot class already depends on it: >>> http://hg.openjdk.java.net/jdk/jdk/file/f4735ff8d17d/src/java.desktop/share/classes/java/awt/Robot.java#l508 >>> >>> >>> On 21/05/2018 10:03, Phil Race wrote: >>>> I don't understand why the new method is added in SwingUtilities2 >>>> instead >>>> of directly in WRobotPeer.java since >>>> a) This makes AWT internals depend on Swing internals. >>>> b) There's no other client of this method. >>>> >>>> -phil. >>>> >>>> >>>> On 05/18/2018 12:38 PM, Sergey Bylokhov wrote: >>>>> Hello. >>>>> Please review the fix for jdk11. >>>>> >>>>> Bugs: >>>>> 8196030: AWT Robot mouseMove fails on Windows 10 1709 with HiDPI >>>>> https://bugs.openjdk.java.net/browse/JDK-8196030 >>>>> 8190326: Robot.mouseMove uses scaling factor of main display >>>>> on unscaled second display >>>>> https://bugs.openjdk.java.net/browse/JDK-8190326 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~serb/8196030/webrev.04 >>>>> >>>>> Description: >>>>> This change will fix two issues: >>>>> - 8196030: In the Windows 10 relative mouse moving is broken. >>>>> Solution is to change the code to use the absolute mouse location. >>>>> Actually the fix reverts the changes which were done in >>>>> JDK-4288230 [1](It is interesting that previously the absolute >>>>> mouse position was broken). Take a look to the function which is >>>>> used to calculate the mouse position, this is the only way I found >>>>> to align coordinates which passed to windows(::SendInput() and >>>>> coordinate which returned by windows(::GetCursorPos(). >>>>> >>>>> - 8190326: the logic how we convert coordinates from the user >>>>> space to device space is changed. Previously we use the >>>>> transformation of the main screen, now we will find the >>>>> appropriate screen(where coordinates are located) and then use >>>>> transformation of this screen. >>>>> >>>>> I have tested the fix on win7/10 using >>>>> scales:100%,125%,%150,%175,%200 in multi-monitor configuration. >>>>> But the new test is quite strict and may fail if there are some >>>>> rounding error in some variations of screen >>>>> resolution+scale+screen locations. So I expect some reports for >>>>> this test. >>>>> >>>>> Notes: >>>>> - The logic in the new method in SwingUtilities2 is similar to >>>>> Robot.createCompatibleImage(), but the new method uses >>>>> Region.clipRound() instead of floor/ceil. The reason is that we >>>>> use same logic in native. I think that >>>>> Robot.createCompatibleImage() should use clipRound() as well. Will >>>>> check this later in separate bug. >>>>> >>>>> - Similar but not the same bug exists in Robot.getPixelColor() >>>>> which uses the scale of the main screen, and uses simple cast to >>>>> (int), but it affects all platforms. Will check this later in >>>>> separate bug. >>>>> >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-4288230 >>>>> >>>> >>> >>> >> > > From Sergey.Bylokhov at oracle.com Mon May 21 19:15:16 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 21 May 2018 12:15:16 -0700 Subject: [11] Review Request: 8196030 and 8190326 In-Reply-To: <5c4dad2b-9956-42ae-8716-89b3ea14abf1@oracle.com> References: <43d2cc9f-70c4-1f9f-7b72-0a7bff45d495@oracle.com> <78421a1d-c02a-7803-2a09-097325ec93c9@oracle.com> <40c6b6c1-639b-e5b8-ac72-be2d67d047a6@oracle.com> <0afadf13-acc9-3df8-1eb1-c8830b2c3831@oracle.com> <459023ee-2056-6328-99a4-333fa0746149@oracle.com> <5c4dad2b-9956-42ae-8716-89b3ea14abf1@oracle.com> Message-ID: <56dd5587-3e78-8948-5c65-3d9cc75bd88d@oracle.com> But the code itself is unrelated to awt, coordinate conversion is a java2d stuff, what about sun.java2d.SunGraphicsEnvironment? On 21/05/2018 11:52, Phil Race wrote: > All the actual cases seem to be in AWT so we should put these somewhere > in AWT, not SU2. > > -phil. > > On 05/21/2018 11:28 AM, Sergey Bylokhov wrote: >> It is also used by, Window peer on windows: >> http://hg.openjdk.java.net/jdk/jdk/file/f4735ff8d17d/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java#l662 >> >> >> I guess that unix peers should use it as well in the same way as on >> windows, actually all code which try to move something using x,y >> coordinates? in user space should use this method. >> >> On 21/05/2018 10:44, Phil Race wrote: >>> Well I don't understand why that was put into SU2 either. >>> Since it is also used just by the AWT Robot. >>> It is from the fix for https://bugs.openjdk.java.net/browse/JDK-8176097 >>> >>> So I think these should both be moved out of SU2 and into Robot code. >>> >>> -phil. >>> >>> On 05/21/2018 10:16 AM, Sergey Bylokhov wrote: >>>> This method call getGraphicsConfigurationAtPoint() which is located >>>> in the SwingUtilities2 and the robot class already depends on it: >>>> http://hg.openjdk.java.net/jdk/jdk/file/f4735ff8d17d/src/java.desktop/share/classes/java/awt/Robot.java#l508 >>>> >>>> >>>> On 21/05/2018 10:03, Phil Race wrote: >>>>> I don't understand why the new method is added in SwingUtilities2 >>>>> instead >>>>> of directly in WRobotPeer.java since >>>>> a) This makes AWT internals depend on Swing internals. >>>>> b) There's no other client of this method. >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 05/18/2018 12:38 PM, Sergey Bylokhov wrote: >>>>>> Hello. >>>>>> Please review the fix for jdk11. >>>>>> >>>>>> Bugs: >>>>>> ??? 8196030: AWT Robot mouseMove fails on Windows 10 1709 with HiDPI >>>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8196030 >>>>>> ??? 8190326: Robot.mouseMove uses scaling factor of main display >>>>>> on unscaled second display >>>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8190326 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~serb/8196030/webrev.04 >>>>>> >>>>>> Description: >>>>>> ?This change will fix two issues: >>>>>> ?- 8196030: In the Windows 10 relative mouse moving is broken. >>>>>> Solution is to change the code to use the absolute mouse location. >>>>>> Actually the fix reverts the changes which were done in >>>>>> JDK-4288230 [1](It is interesting that previously the absolute >>>>>> mouse position was broken). Take a look to the function which is >>>>>> used to calculate the mouse position, this is the only way I found >>>>>> to align coordinates which passed to windows(::SendInput() and >>>>>> coordinate which returned by windows(::GetCursorPos(). >>>>>> >>>>>> ?- 8190326: the logic how we convert coordinates from the user >>>>>> space to device space is changed. Previously we use the >>>>>> transformation of the main screen, now we will find the >>>>>> appropriate screen(where coordinates are located) and then use >>>>>> transformation of this screen. >>>>>> >>>>>> I have tested the fix on win7/10 using >>>>>> scales:100%,125%,%150,%175,%200 in multi-monitor configuration. >>>>>> But the new test is quite strict and may fail if there are some >>>>>> rounding error in some variations of screen >>>>>> resolution+scale+screen locations. So I expect some reports for >>>>>> this test. >>>>>> >>>>>> Notes: >>>>>> ?- The logic in the new method in SwingUtilities2 is similar to >>>>>> Robot.createCompatibleImage(), but the new method uses >>>>>> Region.clipRound() instead of floor/ceil. The reason is that we >>>>>> use same logic in native. I think that >>>>>> Robot.createCompatibleImage() should use clipRound() as well. Will >>>>>> check this later in separate bug. >>>>>> >>>>>> ?- Similar but not the same bug exists in Robot.getPixelColor() >>>>>> which uses the scale of the main screen, and uses simple cast to >>>>>> (int), but it affects all platforms. Will check this later in >>>>>> separate bug. >>>>>> >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-4288230 >>>>>> >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From philip.race at oracle.com Mon May 21 19:31:56 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 21 May 2018 12:31:56 -0700 Subject: [11] Review Request: 8196030 and 8190326 In-Reply-To: <56dd5587-3e78-8948-5c65-3d9cc75bd88d@oracle.com> References: <43d2cc9f-70c4-1f9f-7b72-0a7bff45d495@oracle.com> <78421a1d-c02a-7803-2a09-097325ec93c9@oracle.com> <40c6b6c1-639b-e5b8-ac72-be2d67d047a6@oracle.com> <0afadf13-acc9-3df8-1eb1-c8830b2c3831@oracle.com> <459023ee-2056-6328-99a4-333fa0746149@oracle.com> <5c4dad2b-9956-42ae-8716-89b3ea14abf1@oracle.com> <56dd5587-3e78-8948-5c65-3d9cc75bd88d@oracle.com> Message-ID: <1c9b9cbb-5baf-0dad-decc-208318ca8d94@oracle.com> I'd like to have no more "AWT code depends on Swing" in the code when unavoidably "Swing depends on AWT." Put them in 2D if needed but not in SU2. -phil. On 05/21/2018 12:15 PM, Sergey Bylokhov wrote: > But the code itself is unrelated to awt, coordinate conversion is a > java2d stuff, what about sun.java2d.SunGraphicsEnvironment? > > On 21/05/2018 11:52, Phil Race wrote: >> All the actual cases seem to be in AWT so we should put these >> somewhere in AWT, not SU2. >> >> -phil. >> >> On 05/21/2018 11:28 AM, Sergey Bylokhov wrote: >>> It is also used by, Window peer on windows: >>> http://hg.openjdk.java.net/jdk/jdk/file/f4735ff8d17d/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java#l662 >>> >>> >>> I guess that unix peers should use it as well in the same way as on >>> windows, actually all code which try to move something using x,y >>> coordinates in user space should use this method. >>> >>> On 21/05/2018 10:44, Phil Race wrote: >>>> Well I don't understand why that was put into SU2 either. >>>> Since it is also used just by the AWT Robot. >>>> It is from the fix for >>>> https://bugs.openjdk.java.net/browse/JDK-8176097 >>>> >>>> So I think these should both be moved out of SU2 and into Robot code. >>>> >>>> -phil. >>>> >>>> On 05/21/2018 10:16 AM, Sergey Bylokhov wrote: >>>>> This method call getGraphicsConfigurationAtPoint() which is >>>>> located in the SwingUtilities2 and the robot class already depends >>>>> on it: >>>>> http://hg.openjdk.java.net/jdk/jdk/file/f4735ff8d17d/src/java.desktop/share/classes/java/awt/Robot.java#l508 >>>>> >>>>> >>>>> On 21/05/2018 10:03, Phil Race wrote: >>>>>> I don't understand why the new method is added in SwingUtilities2 >>>>>> instead >>>>>> of directly in WRobotPeer.java since >>>>>> a) This makes AWT internals depend on Swing internals. >>>>>> b) There's no other client of this method. >>>>>> >>>>>> -phil. >>>>>> >>>>>> >>>>>> On 05/18/2018 12:38 PM, Sergey Bylokhov wrote: >>>>>>> Hello. >>>>>>> Please review the fix for jdk11. >>>>>>> >>>>>>> Bugs: >>>>>>> 8196030: AWT Robot mouseMove fails on Windows 10 1709 with >>>>>>> HiDPI >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8196030 >>>>>>> 8190326: Robot.mouseMove uses scaling factor of main display >>>>>>> on unscaled second display >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8190326 >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~serb/8196030/webrev.04 >>>>>>> >>>>>>> Description: >>>>>>> This change will fix two issues: >>>>>>> - 8196030: In the Windows 10 relative mouse moving is broken. >>>>>>> Solution is to change the code to use the absolute mouse >>>>>>> location. Actually the fix reverts the changes which were done >>>>>>> in JDK-4288230 [1](It is interesting that previously the >>>>>>> absolute mouse position was broken). Take a look to the function >>>>>>> which is used to calculate the mouse position, this is the only >>>>>>> way I found to align coordinates which passed to >>>>>>> windows(::SendInput() and coordinate which returned by >>>>>>> windows(::GetCursorPos(). >>>>>>> >>>>>>> - 8190326: the logic how we convert coordinates from the user >>>>>>> space to device space is changed. Previously we use the >>>>>>> transformation of the main screen, now we will find the >>>>>>> appropriate screen(where coordinates are located) and then use >>>>>>> transformation of this screen. >>>>>>> >>>>>>> I have tested the fix on win7/10 using >>>>>>> scales:100%,125%,%150,%175,%200 in multi-monitor configuration. >>>>>>> But the new test is quite strict and may fail if there are some >>>>>>> rounding error in some variations of screen >>>>>>> resolution+scale+screen locations. So I expect some reports for >>>>>>> this test. >>>>>>> >>>>>>> Notes: >>>>>>> - The logic in the new method in SwingUtilities2 is similar to >>>>>>> Robot.createCompatibleImage(), but the new method uses >>>>>>> Region.clipRound() instead of floor/ceil. The reason is that we >>>>>>> use same logic in native. I think that >>>>>>> Robot.createCompatibleImage() should use clipRound() as well. >>>>>>> Will check this later in separate bug. >>>>>>> >>>>>>> - Similar but not the same bug exists in Robot.getPixelColor() >>>>>>> which uses the scale of the main screen, and uses simple cast to >>>>>>> (int), but it affects all platforms. Will check this later in >>>>>>> separate bug. >>>>>>> >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-4288230 >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From Sergey.Bylokhov at oracle.com Tue May 22 02:39:06 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 21 May 2018 19:39:06 -0700 Subject: [11] Review Request: 8203308 Remove the appletviewer classes Message-ID: <071dcdda-7d21-74bf-a1fa-dc05c6747d3a@oracle.com> Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8203308 Webrev: http://cr.openjdk.java.net/~serb/8203308/webrev.00 Description: - Implementation of the AppletViewer was removed - Tests in sun/applet were removed and TEST.ROOT/TEST.groups were updated - Small update in make file was done We still have a few classes in sun.applet package which are related to the client security, sound. I think that we can drop it as well at some point. -- Best regards, Sergey. From shashidhara.veerabhadraiah at oracle.com Tue May 22 06:34:07 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Mon, 21 May 2018 23:34:07 -0700 (PDT) Subject: [11] JDK-8199723: Test java/awt/TextComponent/DeselectionDuringDoSelectionNonVisibleTest/DeselectionDuringDoSelectionNonVisibleTest.java fails Message-ID: <060e85b0-fd95-4f45-b4a8-d1f3998bf542@default> Hi, Please review a test fix for the below bug: Bug: https://bugs.openjdk.java.net/browse/JDK-8199723 Webrev: http://cr.openjdk.java.net/~sveerabhadra/8199723/webrev.00/ In the review bug https://bugs.openjdk.java.net/browse/JDK-8194135, a test was introduced to assess the behavior on the linux platforms but later as part of the review process, I mistakenly removed the test case. I think the same test case is valid and needed. Hence bringing it back now. Thanks and regards, Shashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Tue May 22 15:32:11 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 May 2018 08:32:11 -0700 Subject: [11] Review Request: 8203308 Remove the appletviewer classes In-Reply-To: <071dcdda-7d21-74bf-a1fa-dc05c6747d3a@oracle.com> References: <071dcdda-7d21-74bf-a1fa-dc05c6747d3a@oracle.com> Message-ID: <7f1b9c47-58be-6949-b9fd-b798381c1c4c@oracle.com> Build changes look good. /Erik On 2018-05-21 19:39, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203308 > Webrev: http://cr.openjdk.java.net/~serb/8203308/webrev.00 > > Description: > ?- Implementation of the AppletViewer was removed > ?- Tests in sun/applet were removed and TEST.ROOT/TEST.groups were > updated > ?- Small update in make file was done > > We still have a few classes in sun.applet package which are related to > the client security, sound. I think that we can drop it as well at > some point. > From philip.race at oracle.com Tue May 22 23:35:30 2018 From: philip.race at oracle.com (Philip Race) Date: Tue, 22 May 2018 16:35:30 -0700 Subject: [11] Review request for JDK-8202841: [macosx] test java/awt/Graphics/LCDTextAndGraphicsState.java fails In-Reply-To: References: <5AF4D3F7.5080701@oracle.com> <6dd56b0f-4570-b9c9-2753-8af3fe60f2fa@oracle.com> Message-ID: <5B04A942.9090807@oracle.com> Structurally this probably fine. I would suggest that you define at least these static final Strings static final String TITLE = "Composite and Text Test"; static final String INSTRUCTIONS = ... and then use those in the Frame constructor and setText. This will make it easier to copy/paste the same into other tests. You can also try to do the same for the text of the exception .. but some tests may want to customise it with runtime information / results you can't know ahead of time. -phil. On 5/21/18, 6:05 AM, Manajit Halder wrote: > Hi Phil, > > I have modified the code as per your suggestion. Removed interrupt() > and instead of that added a sleep loop waiting for a flag to be set. > Please review the changes > http://cr.openjdk.java.net/~mhalder/8202841/webrev.01/ > > > Thanks, > Manajit > >> On 16-May-2018, at 9:45 PM, Phil Race > > wrote: >> >> Hopefully we can update all 16 tests with the boilerplate developed >> for this test. >> One thing that I think needs to change here, is that using >> interrupt() as a way >> to signal the main thread doesn't seem ideal. >> You can either use a semaphore or it can use a sleep loop waiting for >> a flag to be set. >> >> -phil. >> >> >> >> On 05/15/2018 05:19 AM, Manajit Halder wrote: >>> Hi Phil, >>> >>> My observation on test written using manual=yesno: >>> >>> Found approximately 56 tests containing manual=yesno in awt/ tests. >>> Among these 40 are written using applet and 16 are printing tests >>> (awt/print and awt/PrintJob). >>> All the printing test with manual=yesno fails with the same, >>> whereas applet test were working fine. >>> >>> Error: "error "test result: Error. Parse Exception: Arguments to >>> `manual' option not supported: yesno? >>> >>> Jtreg version used: jtreg, version 4.2 dev 380 >>> JDK version: JDK 11 local build >>> >>> Regards, >>> Manajit >>> >>>> On 11-May-2018, at 4:51 AM, Philip Race >>> > wrote: >>>> >>>> So according to http://openjdk.java.net/jtreg/tag-spec.html this >>>> tag is legal and correct >>>> >>>> /manual[=(yesno|done)] >>>> ... >>>> If "yesno" is given, then the harness will ask the user whether the >>>> action is to pass or fail. >>>> >>>> But it seems this is only implemented for applets. >>>> >>>> So are those other strings applets or main programs. >>>> >>>> -phil. >>>> >>>> On 5/10/18, 1:58 PM, Sergey Bylokhov wrote: >>>>> Hi, Manajit. >>>>> Did you check other tests with such typos? >>>>> I found the same strings in our repo. >>>>> >>>>> On 10/05/2018 04:59, Manajit Halder wrote: >>>>>> Hi Phil, >>>>>> >>>>>> Please review the test fix for JDK11. >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8202841 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mhalder/8202841/webrev.00/ >>>>>> >>>>>> Issue: >>>>>> Test fails due jtreg tag manual=yesno with error ?Parse >>>>>> Exception: Arguments to `manual' option not supported: yesno? >>>>>> >>>>>> Fix: >>>>>> Removed itreg tag manual=yesno and changed the test to a manual >>>>>> test with instructions >>>>>> >>>>>> Regards, >>>>>> Manajit >>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Tue May 22 23:57:42 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 22 May 2018 16:57:42 -0700 Subject: [11] Review Request: 8196030 and 8190326 In-Reply-To: <43d2cc9f-70c4-1f9f-7b72-0a7bff45d495@oracle.com> References: <43d2cc9f-70c4-1f9f-7b72-0a7bff45d495@oracle.com> Message-ID: I can confirm that the patch fixes the problem for me on the Windows 10 machine on which I initially reported the bug. The change in awt_Robot.cpp looks reasonable to me. I didn't review it thoroughly, though (and just skimmed the rest). -- Kevin On 5/18/2018 12:38 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11. > > Bugs: > ??? 8196030: AWT Robot mouseMove fails on Windows 10 1709 with HiDPI > ??? https://bugs.openjdk.java.net/browse/JDK-8196030 > ??? 8190326: Robot.mouseMove uses scaling factor of main display on > unscaled second display > ??? https://bugs.openjdk.java.net/browse/JDK-8190326 > > Webrev: http://cr.openjdk.java.net/~serb/8196030/webrev.04 > > Description: > ?This change will fix two issues: > ?- 8196030: In the Windows 10 relative mouse moving is broken. > Solution is to change the code to use the absolute mouse location. > Actually the fix reverts the changes which were done in JDK-4288230 > [1](It is interesting that previously the absolute mouse position was > broken). Take a look to the function which is used to calculate the > mouse position, this is the only way I found to align coordinates > which passed to windows(::SendInput() and coordinate which returned by > windows(::GetCursorPos(). > > ?- 8190326: the logic how we convert coordinates from the user space > to device space is changed. Previously we use the transformation of > the main screen, now we will find the appropriate screen(where > coordinates are located) and then use transformation of this screen. > > I have tested the fix on win7/10 using scales:100%,125%,%150,%175,%200 > in multi-monitor configuration. But the new test is quite strict and > may fail if there are some rounding error in some variations of screen > resolution+scale+screen locations. So I expect some reports for this > test. > > Notes: > ?- The logic in the new method in SwingUtilities2 is similar to > Robot.createCompatibleImage(), but the new method uses > Region.clipRound() instead of floor/ceil. The reason is that we use > same logic in native. I think that Robot.createCompatibleImage() > should use clipRound() as well. Will check this later in separate bug. > > ?- Similar but not the same bug exists in Robot.getPixelColor() which > uses the scale of the main screen, and uses simple cast to (int), but > it affects all platforms. Will check this later in separate bug. > > > [1] https://bugs.openjdk.java.net/browse/JDK-4288230 > From philip.race at oracle.com Wed May 23 17:53:08 2018 From: philip.race at oracle.com (Philip Race) Date: Wed, 23 May 2018 10:53:08 -0700 Subject: [11] Review Request: 8203308 Remove the appletviewer classes In-Reply-To: <7f1b9c47-58be-6949-b9fd-b798381c1c4c@oracle.com> References: <071dcdda-7d21-74bf-a1fa-dc05c6747d3a@oracle.com> <7f1b9c47-58be-6949-b9fd-b798381c1c4c@oracle.com> Message-ID: <5B05AA84.7030000@oracle.com> I verified that applet based tests (manual + automated) still run in jtreg. So +1 -phil. On 5/22/18, 8:32 AM, Erik Joelsson wrote: > Build changes look good. > > /Erik > > > On 2018-05-21 19:39, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk11. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8203308 >> Webrev: http://cr.openjdk.java.net/~serb/8203308/webrev.00 >> >> Description: >> - Implementation of the AppletViewer was removed >> - Tests in sun/applet were removed and TEST.ROOT/TEST.groups were >> updated >> - Small update in make file was done >> >> We still have a few classes in sun.applet package which are related >> to the client security, sound. I think that we can drop it as well at >> some point. >> > From Sergey.Bylokhov at oracle.com Wed May 23 19:41:34 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 23 May 2018 12:41:34 -0700 Subject: [11] Review Request: 8196030 and 8190326 In-Reply-To: <1c9b9cbb-5baf-0dad-decc-208318ca8d94@oracle.com> References: <43d2cc9f-70c4-1f9f-7b72-0a7bff45d495@oracle.com> <78421a1d-c02a-7803-2a09-097325ec93c9@oracle.com> <40c6b6c1-639b-e5b8-ac72-be2d67d047a6@oracle.com> <0afadf13-acc9-3df8-1eb1-c8830b2c3831@oracle.com> <459023ee-2056-6328-99a4-333fa0746149@oracle.com> <5c4dad2b-9956-42ae-8716-89b3ea14abf1@oracle.com> <56dd5587-3e78-8948-5c65-3d9cc75bd88d@oracle.com> <1c9b9cbb-5baf-0dad-decc-208318ca8d94@oracle.com> Message-ID: The fix is updated: http://cr.openjdk.java.net/~serb/8196030/webrev.06 These methods were moved to sun.java2d.SunGraphicsEnvironment On 21/05/2018 12:31, Phil Race wrote: > I'd like to have no more "AWT code depends on Swing" in the code when > unavoidably > "Swing depends on AWT." > > Put them in 2D if needed but not in SU2. > > -phil. > > On 05/21/2018 12:15 PM, Sergey Bylokhov wrote: >> But the code itself is unrelated to awt, coordinate conversion is a >> java2d stuff, what about sun.java2d.SunGraphicsEnvironment? >> >> On 21/05/2018 11:52, Phil Race wrote: >>> All the actual cases seem to be in AWT so we should put these >>> somewhere in AWT, not SU2. >>> >>> -phil. >>> >>> On 05/21/2018 11:28 AM, Sergey Bylokhov wrote: >>>> It is also used by, Window peer on windows: >>>> http://hg.openjdk.java.net/jdk/jdk/file/f4735ff8d17d/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java#l662 >>>> >>>> >>>> I guess that unix peers should use it as well in the same way as on >>>> windows, actually all code which try to move something using x,y >>>> coordinates? in user space should use this method. >>>> >>>> On 21/05/2018 10:44, Phil Race wrote: >>>>> Well I don't understand why that was put into SU2 either. >>>>> Since it is also used just by the AWT Robot. >>>>> It is from the fix for >>>>> https://bugs.openjdk.java.net/browse/JDK-8176097 >>>>> >>>>> So I think these should both be moved out of SU2 and into Robot code. >>>>> >>>>> -phil. >>>>> >>>>> On 05/21/2018 10:16 AM, Sergey Bylokhov wrote: >>>>>> This method call getGraphicsConfigurationAtPoint() which is >>>>>> located in the SwingUtilities2 and the robot class already depends >>>>>> on it: >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/f4735ff8d17d/src/java.desktop/share/classes/java/awt/Robot.java#l508 >>>>>> >>>>>> >>>>>> On 21/05/2018 10:03, Phil Race wrote: >>>>>>> I don't understand why the new method is added in SwingUtilities2 >>>>>>> instead >>>>>>> of directly in WRobotPeer.java since >>>>>>> a) This makes AWT internals depend on Swing internals. >>>>>>> b) There's no other client of this method. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> >>>>>>> On 05/18/2018 12:38 PM, Sergey Bylokhov wrote: >>>>>>>> Hello. >>>>>>>> Please review the fix for jdk11. >>>>>>>> >>>>>>>> Bugs: >>>>>>>> ??? 8196030: AWT Robot mouseMove fails on Windows 10 1709 with >>>>>>>> HiDPI >>>>>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8196030 >>>>>>>> ??? 8190326: Robot.mouseMove uses scaling factor of main display >>>>>>>> on unscaled second display >>>>>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8190326 >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~serb/8196030/webrev.04 >>>>>>>> >>>>>>>> Description: >>>>>>>> ?This change will fix two issues: >>>>>>>> ?- 8196030: In the Windows 10 relative mouse moving is broken. >>>>>>>> Solution is to change the code to use the absolute mouse >>>>>>>> location. Actually the fix reverts the changes which were done >>>>>>>> in JDK-4288230 [1](It is interesting that previously the >>>>>>>> absolute mouse position was broken). Take a look to the function >>>>>>>> which is used to calculate the mouse position, this is the only >>>>>>>> way I found to align coordinates which passed to >>>>>>>> windows(::SendInput() and coordinate which returned by >>>>>>>> windows(::GetCursorPos(). >>>>>>>> >>>>>>>> ?- 8190326: the logic how we convert coordinates from the user >>>>>>>> space to device space is changed. Previously we use the >>>>>>>> transformation of the main screen, now we will find the >>>>>>>> appropriate screen(where coordinates are located) and then use >>>>>>>> transformation of this screen. >>>>>>>> >>>>>>>> I have tested the fix on win7/10 using >>>>>>>> scales:100%,125%,%150,%175,%200 in multi-monitor configuration. >>>>>>>> But the new test is quite strict and may fail if there are some >>>>>>>> rounding error in some variations of screen >>>>>>>> resolution+scale+screen locations. So I expect some reports for >>>>>>>> this test. >>>>>>>> >>>>>>>> Notes: >>>>>>>> ?- The logic in the new method in SwingUtilities2 is similar to >>>>>>>> Robot.createCompatibleImage(), but the new method uses >>>>>>>> Region.clipRound() instead of floor/ceil. The reason is that we >>>>>>>> use same logic in native. I think that >>>>>>>> Robot.createCompatibleImage() should use clipRound() as well. >>>>>>>> Will check this later in separate bug. >>>>>>>> >>>>>>>> ?- Similar but not the same bug exists in Robot.getPixelColor() >>>>>>>> which uses the scale of the main screen, and uses simple cast to >>>>>>>> (int), but it affects all platforms. Will check this later in >>>>>>>> separate bug. >>>>>>>> >>>>>>>> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-4288230 >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed May 23 21:41:27 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 23 May 2018 14:41:27 -0700 Subject: [11] Review Request: 8203498 The specification for java.applet package should be updated Message-ID: Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8203498 Webrev: http://cr.openjdk.java.net/~serb/8203498/webrev.01 The text for @deprecation tags in java.applet package and classes related to applets are updated. Now it has a notion that there are no new API which replace the Applet API. I am not sure is it necessary to create a CSR for this change, but if needed I'll create it after the technical review. -- Best regards, Sergey. From philip.race at oracle.com Wed May 23 21:42:24 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 23 May 2018 14:42:24 -0700 Subject: [11] Review Request: 8203498 The specification for java.applet package should be updated In-Reply-To: References: Message-ID: <1415ef1d-d2ff-e9e6-8598-8aac95f25d08@oracle.com> Seems fine to me. You aren't changing the deprecation status so I don't think it needs a CSR. -phil. On 05/23/2018 02:41 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203498 > Webrev: http://cr.openjdk.java.net/~serb/8203498/webrev.01 > > The text for @deprecation tags in java.applet package and classes > related to applets are updated. Now it has a notion that there are no > new API which replace the Applet API. > > I am not sure is it necessary to create a CSR for this change, but if > needed I'll create it after the technical review. > From Sergey.Bylokhov at oracle.com Wed May 23 22:03:06 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 23 May 2018 15:03:06 -0700 Subject: [11] JDK-8199723: Test java/awt/TextComponent/DeselectionDuringDoSelectionNonVisibleTest/DeselectionDuringDoSelectionNonVisibleTest.java fails In-Reply-To: <060e85b0-fd95-4f45-b4a8-d1f3998bf542@default> References: <060e85b0-fd95-4f45-b4a8-d1f3998bf542@default> Message-ID: On 21/05/2018 23:34, Shashidhara Veerabhadraiah wrote: > Hi, Please review a test fix for the below bug: > > _Bug:_ https://bugs.openjdk.java.net/browse/JDK-8199723 > > _Webrev:_ http://cr.openjdk.java.net/~sveerabhadra/8199723/webrev.00/ > > In the review bug https://bugs.openjdk.java.net/browse/JDK-8194135, a > test was introduced to assess the behavior on the linux platforms but > later as part of the review process, I mistakenly removed the test case. > I think the same test case is valid and needed. Hence bringing it back now. > > Thanks and regards, > Shashi > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed May 23 22:06:14 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 23 May 2018 15:06:14 -0700 Subject: [11] JDK-8199723: Test java/awt/TextComponent/DeselectionDuringDoSelectionNonVisibleTest/DeselectionDuringDoSelectionNonVisibleTest.java fails In-Reply-To: <060e85b0-fd95-4f45-b4a8-d1f3998bf542@default> References: <060e85b0-fd95-4f45-b4a8-d1f3998bf542@default> Message-ID: <6dfb8d78-190e-dbf9-a397-68278b92a277@oracle.com> Looks fine. On 21/05/2018 23:34, Shashidhara Veerabhadraiah wrote: > Hi, Please review a test fix for the below bug: > > _Bug:_ https://bugs.openjdk.java.net/browse/JDK-8199723 > > _Webrev:_ http://cr.openjdk.java.net/~sveerabhadra/8199723/webrev.00/ > > In the review bug https://bugs.openjdk.java.net/browse/JDK-8194135, a > test was introduced to assess the behavior on the linux platforms but > later as part of the review process, I mistakenly removed the test case. > I think the same test case is valid and needed. Hence bringing it back now. > > Thanks and regards, > Shashi > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu May 24 19:23:56 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 24 May 2018 12:23:56 -0700 Subject: [11] Review request for JDK-8029250: [macosx] There is no tray icon shown in the system tray area when case starts In-Reply-To: References: <4919F580-0B5F-46D6-8528-A79E841E9103@oracle.com> Message-ID: <33024352-b1ea-ce06-5ea4-5a11278e701d@oracle.com> Hi, Manajit. I have only a few comments about a style: - I think it would be good to have two methods createFromImage() the old(without Observer) and new(with Observer). The old method should pass null to the new method. In this case CMenuItem/CCustomCursor will not be changed. - The parentheses around target are not necessary CTrayIcon.java:359 if (image != (target).getImage()) On 03/05/2018 04:11, Manajit Halder wrote: > Hi Sergey, > > Please review the updated webrev. > http://cr.openjdk.java.net/~mhalder/8029250/webrev.01/ > > The modified test case moved to closed test as it contains images with > unknown source. > > Regards, > Manajit > > > >> On 27-Apr-2018, at 4:06 PM, Manajit Halder > > wrote: >> >> Hi All, >> >> Kindly review the following AWT enhancement changes: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8029250 >> Webrev: http://cr.openjdk.java.net/~mhalder/8029250/webrev.00/ >> >> Fix: >> Added support for gif images (image?animation) for Mac system tray. >> Before fix only single frame was passed to?Mac OS?system tray on mouse >> click from the Java side. >> After fix all the frames are passed at the time interval set in the >> image one by one to the Mac OS side. >> >> Note: >> The test was moved from closed test to open test along with 3 images: >> ball.gif, spot.gif and duke.gif. The test code was rewritten dropping >> the applet code used earlier. >> >> Regards, >> Manajit >> >> >> >> >> > -- Best regards, Sergey. From takiguc at linux.vnet.ibm.com Fri May 25 02:02:55 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 25 May 2018 11:02:55 +0900 Subject: Proposal:AIX's CDE/MWM support In-Reply-To: References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com> Message-ID: <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com> Hello Phil. webrev file was extracted. Please see http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/ On 2018-05-19 02:48, Ichiroh Takiguchi wrote: > Hello Phil. > > Webrev.zip file is stored into > http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip > > Test programs are also stored: > No testcase is available for FontUtilities.java and > XDecoratedPeer.java. > > MotifColorUtilities.java > http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java > Run SystemColorTest2, system colors should be displayed > AIX sample is > http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt > > XWM.java > http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java > On AIX CDE, isMotif and isCDE were true. > On AIX MWM, every entry is false. > > XWindowPeer.java > http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java > On AIX CDE, click inside of "Non-Focusable" window (not window frame). > Window focus should not be changed because of "click on focus" feature. > But input focus is moved to "Non-Focusable" window. > > > On 2018-05-18 01:00, Phil Race wrote: >> I think we'd need to see the actual proposed changes and understand >> the implications >> for ongoing support as we no longer support any platform which has a >> CDE desktop. >> Solaris 11.3 uses Gnome, so we'd be more inclined to be ripping out >> such support rather >> than adding to it. >> >> -phil. >> >> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote: >>> Hello, >>> IBM would like to contribute AIX's CDE (Common Desktop Environment) >>> DTWM (Desktop Window Manager) /MWM (Motif Window Manager) support to >>> OpenJDK project. >>> >>> I'd like contribute following 5 files: >>> >>> M src/java.desktop/share/classes/sun/font/FontUtilities.java >>> (Add isAIX flag to determine AIX platform for GUI environment) >>> M src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java >>> (Add High Color support on CDE, OpenJDK just supports Medium Color) >>> [1] >>> M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java >>> (Avoid miss calculation for window position under DTWM/MWM by >>> XMapRaised/XMapWindow) >>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java >>> (Detect MWM on AIX platform) >>> M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java >>> (Add non-focusable window support on DTWM/MWM for AIX, because >>> DTWM/MWM does not have enough features for ICCCM) >>> >>> I appreciate any feedback please, and how I would go about obtaining >>> a sponsor and contributor ? >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> >>> [1] >>> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html >>> From Sergey.Bylokhov at oracle.com Fri May 25 04:48:30 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 24 May 2018 21:48:30 -0700 Subject: [11] Review Request: 8203224 java.awt.desktop.*Event classes could not be instantiated if Desktop feature is not supported Message-ID: <261d614b-e9fc-4f2c-965f-277fc2d72e55@oracle.com> Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8203224 Webrev: http://cr.openjdk.java.net/~serb/8203224/webrev.00 All events in the "java.awt.desktop" package use the instance of Desktop as a source of the event: http://cr.openjdk.java.net/~serb/8203224/webrev.00/src/java.desktop/share/classes/java/awt/desktop/AppEvent.java.sdiff.html The problem is that "Desktop.getDesktop()" can throw an exceptions in some cases. These exceptions are not specified in the event classes. I'll create CSR after the technical review. -- Best regards, Sergey. From takiguc at linux.vnet.ibm.com Fri May 25 05:24:25 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 25 May 2018 14:24:25 +0900 Subject: Proposal:X11 default visual support for IM status window on VNC Message-ID: <46b05293c2bab165a413ac1ac18e0703@linux.vnet.ibm.com> Hello, IBM would like to contribute X11 default visual support for IM status window patch to OpenJDK project. Issue: Java's Native IM status window is not displayed even if it's there. Because of this issue, user cannot get proper visual feedback during key input operation. We found this issue on Tiger VNC. Reason: Java may pick up unexpected visual for Java's Native IM status window when Xserver supports multiple visual. Workaround: X11 default visual can be changed by FORCEDEFVIS environment variable, but it's not easy to find out default visual id. I'd like contribute following 2 files: M src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c (Change X11 visual setting) M src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c (Support 13 point X11 misc fonts (like k14 font for Japanese), since the fonts may defined for unscaled fonts.) webrev files are in http://cr.openjdk.java.net/~aleonard/defvis/ I appreciate any feedback please, and how I would go about obtaining a sponsor and contributor? Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From shashidhara.veerabhadraiah at oracle.com Fri May 25 08:34:36 2018 From: shashidhara.veerabhadraiah at oracle.com (shashidhara.veerabhadraiah at oracle.com) Date: Fri, 25 May 2018 14:04:36 +0530 Subject: [11] Review request for JDK-8029250: [macosx] There is no tray icon shown in the system tray area when case starts In-Reply-To: <33024352-b1ea-ce06-5ea4-5a11278e701d@oracle.com> References: <4919F580-0B5F-46D6-8528-A79E841E9103@oracle.com> <33024352-b1ea-ce06-5ea4-5a11278e701d@oracle.com> Message-ID: <016d8e5a-54a1-b3ec-d2ef-ef72fd5435c9@oracle.com> Hi Manajit, The code changes looks fine to me but wanted to understand the reason for creating the CImage object at updateImage() function. The reason is that updateImage() is also called in the constructor and we can store the CImage object that is created in the updateImage() once and reuse it every time. Currently we load the image thro' mediatracker and wait for it and then create the CImage object. I think that is not required. I do not understand in detail of the CImage class but I think 'creation' at the time of 'update' is not required. We can very well create once and use it every time we do update. Thanks and regards, Shashi On 25/05/18 12:53 AM, Sergey Bylokhov wrote: > Hi, Manajit. > I have only a few comments about a style: > ?- I think it would be good to have two methods createFromImage() the > old(without Observer) and new(with Observer). The old method should > pass null to the new method. In this case CMenuItem/CCustomCursor will > not be changed. > ?- The parentheses around target are not necessary > ?? CTrayIcon.java:359 if (image != (target).getImage()) > > > On 03/05/2018 04:11, Manajit Halder wrote: >> Hi Sergey, >> >> Please review the updated webrev. >> http://cr.openjdk.java.net/~mhalder/8029250/webrev.01/ >> >> The modified test case moved to closed test as it contains images >> with unknown source. >> >> Regards, >> Manajit >> >> >> >>> On 27-Apr-2018, at 4:06 PM, Manajit Halder >>> > wrote: >>> >>> Hi All, >>> >>> Kindly review the following AWT enhancement changes: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029250 >>> Webrev: http://cr.openjdk.java.net/~mhalder/8029250/webrev.00/ >>> >>> Fix: >>> Added support for gif images (image?animation) for Mac system tray. >>> Before fix only single frame was passed to?Mac OS?system tray on >>> mouse click from the Java side. >>> After fix all the frames are passed at the time interval set in the >>> image one by one to the Mac OS side. >>> >>> Note: >>> The test was moved from closed test to open test along with 3 >>> images: ball.gif, spot.gif and duke.gif. The test code was rewritten >>> dropping the applet code used earlier. >>> >>> Regards, >>> Manajit >>> >>> >>> >>> >>> >> > > From manajit.halder at oracle.com Fri May 25 13:43:56 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Fri, 25 May 2018 19:13:56 +0530 Subject: [11] Review request for JDK-8029250: [macosx] There is no tray icon shown in the system tray area when case starts In-Reply-To: <016d8e5a-54a1-b3ec-d2ef-ef72fd5435c9@oracle.com> References: <4919F580-0B5F-46D6-8528-A79E841E9103@oracle.com> <33024352-b1ea-ce06-5ea4-5a11278e701d@oracle.com> <016d8e5a-54a1-b3ec-d2ef-ef72fd5435c9@oracle.com> Message-ID: <40EADE44-3290-4D03-845C-16B7E72B1BFF@oracle.com> Hi Shashi, The reason is updateImage() gets and sets the images every time user changes the image and CImage object needs the images. Whereas CTrayIcon constructor can only set the initial image to the CImage if we move it there. Hope that answers your query. Regards, Manajit > On 25-May-2018, at 2:04 PM, shashidhara.veerabhadraiah at oracle.com wrote: > > Hi Manajit, The code changes looks fine to me but wanted to understand the reason for creating the CImage object at updateImage() function. The reason is that updateImage() is also called in the constructor and we can store the CImage object that is created in the updateImage() once and reuse it every time. Currently we load the image thro' mediatracker and wait for it and then create the CImage object. I think that is not required. I do not understand in detail of the CImage class but I think 'creation' at the time of 'update' is not required. We can very well create once and use it every time we do update. > > Thanks and regards, > > Shashi > > > On 25/05/18 12:53 AM, Sergey Bylokhov wrote: >> Hi, Manajit. >> I have only a few comments about a style: >> - I think it would be good to have two methods createFromImage() the old(without Observer) and new(with Observer). The old method should pass null to the new method. In this case CMenuItem/CCustomCursor will not be changed. >> - The parentheses around target are not necessary >> CTrayIcon.java:359 if (image != (target).getImage()) >> >> >> On 03/05/2018 04:11, Manajit Halder wrote: >>> Hi Sergey, >>> >>> Please review the updated webrev. >>> http://cr.openjdk.java.net/~mhalder/8029250/webrev.01/ >>> >>> The modified test case moved to closed test as it contains images with unknown source. >>> >>> Regards, >>> Manajit >>> >>> >>> >>>> On 27-Apr-2018, at 4:06 PM, Manajit Halder > wrote: >>>> >>>> Hi All, >>>> >>>> Kindly review the following AWT enhancement changes: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029250 >>>> Webrev: http://cr.openjdk.java.net/~mhalder/8029250/webrev.00/ >>>> >>>> Fix: >>>> Added support for gif images (image animation) for Mac system tray. Before fix only single frame was passed to Mac OS system tray on mouse click from the Java side. >>>> After fix all the frames are passed at the time interval set in the image one by one to the Mac OS side. >>>> >>>> Note: >>>> The test was moved from closed test to open test along with 3 images: ball.gif, spot.gif and duke.gif. The test code was rewritten dropping the applet code used earlier. >>>> >>>> Regards, >>>> Manajit >>>> >>>> >>>> >>>> >>>> >>> >> >> > From manajit.halder at oracle.com Fri May 25 16:00:43 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Fri, 25 May 2018 21:30:43 +0530 Subject: [11] Review request for JDK-8029250: [macosx] There is no tray icon shown in the system tray area when case starts In-Reply-To: <016d8e5a-54a1-b3ec-d2ef-ef72fd5435c9@oracle.com> References: <4919F580-0B5F-46D6-8528-A79E841E9103@oracle.com> <33024352-b1ea-ce06-5ea4-5a11278e701d@oracle.com> <016d8e5a-54a1-b3ec-d2ef-ef72fd5435c9@oracle.com> Message-ID: <1115F90C-F54F-4BDB-B805-61262862612E@oracle.com> Hi Sergey, I agree with you. Added two createFromImage methods with and without observer and removed the changes form CMenuItem, CCustomCursor and also from _AppDockIconHandler. Please review the updated code. cr.openjdk.java.net/~mhalder/8029250/webrev.02/ Regards, Manajit > On 25-May-2018, at 2:04 PM, shashidhara.veerabhadraiah at oracle.com wrote: > > Hi Manajit, The code changes looks fine to me but wanted to understand the reason for creating the CImage object at updateImage() function. The reason is that updateImage() is also called in the constructor and we can store the CImage object that is created in the updateImage() once and reuse it every time. Currently we load the image thro' mediatracker and wait for it and then create the CImage object. I think that is not required. I do not understand in detail of the CImage class but I think 'creation' at the time of 'update' is not required. We can very well create once and use it every time we do update. > > Thanks and regards, > > Shashi > > > On 25/05/18 12:53 AM, Sergey Bylokhov wrote: >> Hi, Manajit. >> I have only a few comments about a style: >> - I think it would be good to have two methods createFromImage() the old(without Observer) and new(with Observer). The old method should pass null to the new method. In this case CMenuItem/CCustomCursor will not be changed. >> - The parentheses around target are not necessary >> CTrayIcon.java:359 if (image != (target).getImage()) >> >> >> On 03/05/2018 04:11, Manajit Halder wrote: >>> Hi Sergey, >>> >>> Please review the updated webrev. >>> http://cr.openjdk.java.net/~mhalder/8029250/webrev.01/ >>> >>> The modified test case moved to closed test as it contains images with unknown source. >>> >>> Regards, >>> Manajit >>> >>> >>> >>>> On 27-Apr-2018, at 4:06 PM, Manajit Halder > wrote: >>>> >>>> Hi All, >>>> >>>> Kindly review the following AWT enhancement changes: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029250 >>>> Webrev: http://cr.openjdk.java.net/~mhalder/8029250/webrev.00/ >>>> >>>> Fix: >>>> Added support for gif images (image animation) for Mac system tray. Before fix only single frame was passed to Mac OS system tray on mouse click from the Java side. >>>> After fix all the frames are passed at the time interval set in the image one by one to the Mac OS side. >>>> >>>> Note: >>>> The test was moved from closed test to open test along with 3 images: ball.gif, spot.gif and duke.gif. The test code was rewritten dropping the applet code used earlier. >>>> >>>> Regards, >>>> Manajit >>>> >>>> >>>> >>>> >>>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri May 25 21:08:06 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 25 May 2018 14:08:06 -0700 Subject: [11] Review request for JDK-8029250: [macosx] There is no tray icon shown in the system tray area when case starts In-Reply-To: <1115F90C-F54F-4BDB-B805-61262862612E@oracle.com> References: <4919F580-0B5F-46D6-8528-A79E841E9103@oracle.com> <33024352-b1ea-ce06-5ea4-5a11278e701d@oracle.com> <016d8e5a-54a1-b3ec-d2ef-ef72fd5435c9@oracle.com> <1115F90C-F54F-4BDB-B805-61262862612E@oracle.com> Message-ID: <9d2e5e44-27d3-8b9b-3d26-7252cc9b5344@oracle.com> Looks fine. On 25/05/2018 09:00, Manajit Halder wrote: > Hi Sergey, > > I agree with you. Added two createFromImage methods with and without > observer and removed the changes form CMenuItem, CCustomCursor and also > from _AppDockIconHandler. Please review the updated code. > cr.openjdk.java.net/~mhalder/8029250/webrev.02/ > > > Regards, > Manajit > >> On 25-May-2018, at 2:04 PM, shashidhara.veerabhadraiah at oracle.com >> wrote: >> >> Hi Manajit, The code changes looks fine to me but wanted to understand >> the reason for creating the CImage object at updateImage() function. >> The reason is that updateImage() is also called in the constructor and >> we can store the CImage object that is created in the updateImage() >> once and reuse it every time. Currently we load the image thro' >> mediatracker and wait for it and then create the CImage object. I >> think that is not required. I do not understand in detail of the >> CImage class but I think 'creation' at the time of 'update' is not >> required. We can very well create once and use it every time we do update. >> >> Thanks and regards, >> >> Shashi >> >> >> On 25/05/18 12:53 AM, Sergey Bylokhov wrote: >>> Hi, Manajit. >>> I have only a few comments about a style: >>> ?- I think it would be good to have two methods createFromImage() the >>> old(without Observer) and new(with Observer). The old method should >>> pass null to the new method. In this case CMenuItem/CCustomCursor >>> will not be changed. >>> ?- The parentheses around target are not necessary >>> ?? CTrayIcon.java:359 if (image != (target).getImage()) >>> >>> >>> On 03/05/2018 04:11, Manajit Halder wrote: >>>> Hi Sergey, >>>> >>>> Please review the updated webrev. >>>> http://cr.openjdk.java.net/~mhalder/8029250/webrev.01/ >>>> >>>> The modified test case moved to closed test as it contains images >>>> with unknown source. >>>> >>>> Regards, >>>> Manajit >>>> >>>> >>>> >>>>> On 27-Apr-2018, at 4:06 PM, Manajit Halder >>>>> > wrote: >>>>> >>>>> Hi All, >>>>> >>>>> Kindly review the following AWT enhancement changes: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029250 >>>>> Webrev: http://cr.openjdk.java.net/~mhalder/8029250/webrev.00/ >>>>> >>>>> Fix: >>>>> Added support for gif images (image?animation) for Mac system tray. >>>>> Before fix only single frame was passed to?Mac OS?system tray on >>>>> mouse click from the Java side. >>>>> After fix all the frames are passed at the time interval set in the >>>>> image one by one to the Mac OS side. >>>>> >>>>> Note: >>>>> The test was moved from closed test to open test along with 3 >>>>> images: ball.gif, spot.gif and duke.gif. The test code was >>>>> rewritten dropping the applet code used earlier. >>>>> >>>>> Regards, >>>>> Manajit >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> > -- Best regards, Sergey. From shashidhara.veerabhadraiah at oracle.com Sat May 26 04:54:37 2018 From: shashidhara.veerabhadraiah at oracle.com (shashidhara.veerabhadraiah at oracle.com) Date: Sat, 26 May 2018 10:24:37 +0530 Subject: [11] Review request for JDK-8029250: [macosx] There is no tray icon shown in the system tray area when case starts In-Reply-To: <40EADE44-3290-4D03-845C-16B7E72B1BFF@oracle.com> References: <4919F580-0B5F-46D6-8528-A79E841E9103@oracle.com> <33024352-b1ea-ce06-5ea4-5a11278e701d@oracle.com> <016d8e5a-54a1-b3ec-d2ef-ef72fd5435c9@oracle.com> <40EADE44-3290-4D03-845C-16B7E72B1BFF@oracle.com> Message-ID: <1f96034c-e331-d3aa-e3cd-4fadb6ae03ca@oracle.com> Hi Manajit, The changes looks fine to me then. Thanks and regards, Shashi On 25/05/18 7:13 PM, Manajit Halder wrote: > Hi Shashi, > > The reason is updateImage() gets and sets the images every time user changes the image and CImage object needs the images. Whereas CTrayIcon constructor can only set the initial image to the CImage if we move it there. > Hope that answers your query. > > Regards, > Manajit > >> On 25-May-2018, at 2:04 PM, shashidhara.veerabhadraiah at oracle.com wrote: >> >> Hi Manajit, The code changes looks fine to me but wanted to understand the reason for creating the CImage object at updateImage() function. The reason is that updateImage() is also called in the constructor and we can store the CImage object that is created in the updateImage() once and reuse it every time. Currently we load the image thro' mediatracker and wait for it and then create the CImage object. I think that is not required. I do not understand in detail of the CImage class but I think 'creation' at the time of 'update' is not required. We can very well create once and use it every time we do update. >> >> Thanks and regards, >> >> Shashi >> >> >> On 25/05/18 12:53 AM, Sergey Bylokhov wrote: >>> Hi, Manajit. >>> I have only a few comments about a style: >>> - I think it would be good to have two methods createFromImage() the old(without Observer) and new(with Observer). The old method should pass null to the new method. In this case CMenuItem/CCustomCursor will not be changed. >>> - The parentheses around target are not necessary >>> CTrayIcon.java:359 if (image != (target).getImage()) >>> >>> >>> On 03/05/2018 04:11, Manajit Halder wrote: >>>> Hi Sergey, >>>> >>>> Please review the updated webrev. >>>> http://cr.openjdk.java.net/~mhalder/8029250/webrev.01/ >>>> >>>> The modified test case moved to closed test as it contains images with unknown source. >>>> >>>> Regards, >>>> Manajit >>>> >>>> >>>> >>>>> On 27-Apr-2018, at 4:06 PM, Manajit Halder > wrote: >>>>> >>>>> Hi All, >>>>> >>>>> Kindly review the following AWT enhancement changes: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029250 >>>>> Webrev: http://cr.openjdk.java.net/~mhalder/8029250/webrev.00/ >>>>> >>>>> Fix: >>>>> Added support for gif images (image animation) for Mac system tray. Before fix only single frame was passed to Mac OS system tray on mouse click from the Java side. >>>>> After fix all the frames are passed at the time interval set in the image one by one to the Mac OS side. >>>>> >>>>> Note: >>>>> The test was moved from closed test to open test along with 3 images: ball.gif, spot.gif and duke.gif. The test code was rewritten dropping the applet code used earlier. >>>>> >>>>> Regards, >>>>> Manajit >>>>> >>>>> >>>>> >>>>> >>>>> >>> From Sergey.Bylokhov at oracle.com Sat May 26 21:19:41 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 26 May 2018 14:19:41 -0700 Subject: [11] Review Request: 8202051 Address compilation warnings in libawt with VS2017 Message-ID: <786eedc9-a1c2-a4c3-0741-cc5b529c9cf8@oracle.com> Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8202051 Webrev: http://cr.openjdk.java.net/~serb/8202051/webrev.00 The warnings which were disabled in JDK-8202052[1] are fixed. Note that these warnings were found in debug build only. - warning C4291: one more delete[] operator was added. see [2]. - warning C4311/C4302: intermediate cast to the "intptr_t" was added. [1] https://bugs.openjdk.java.net/browse/JDK-8202052 [2] https://msdn.microsoft.com/en-us/library/cxdxz3x6.aspx -- Best regards, Sergey. From christoph.langer at sap.com Mon May 28 12:38:41 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 28 May 2018 12:38:41 +0000 Subject: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) In-Reply-To: <5B00B8EF.8000208@oracle.com> References: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> <0cf8df6f-d5ad-9db2-8381-ccca9eaf6a5f@oracle.com> <6d6b9a02-3b81-6978-1104-c4b1c12f65a5@oracle.com> <3e96ae93f38a3cfbcb584cf106f5297f@linux.vnet.ibm.com> <5B00B8EF.8000208@oracle.com> Message-ID: <035faeb1c36543378ab06e6828e4f889@sap.com> Hi Phil, thanks for your review. I have incorporated your suggestions: http://cr.openjdk.java.net/~clanger/webrevs/8201429.3/ I'll run it through our internal testing and run a jdk-submit job with it. When all is green, I'll push it to jdk-client tomorrow. Best regards Christoph > -----Original Message----- > From: Philip Race [mailto:philip.race at oracle.com] > Sent: Sonntag, 20. Mai 2018 01:53 > To: Langer, Christoph > Cc: awt-dev at openjdk.java.net; Ichiroh Takiguchi > ; build-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Subject: Re: RFR: 8201429: Support AIX Input Method Editor > (IME) for AWT Input Method Framework (IMF) > > I think I am 99% OK with this. > > In general I see what you are doing here and how you've presented the > webrev. > Treating even the new files as moved helps see the differences but it is > still > a challenge to follow all the moving pieces. > > So before we had just > > abstract class unix/X11InputMethod <- class unix/XInputMethod > > Now we have > > abstract class unix/X11InputMethodBase > > / \ > > / \ > > / \ > > / \ > > abstract class unix/X11InputMethod abstract class > aix/X11InputMethod > > \ / > \ / > \ / > class unix/XInputMethod > > > > I have submitted a build job with this patch to make sure it all builds > on Linux & Solaris .. > and it was all fine. > > But testing for this would have to be manual, and I don't have cycles > for that. > So I'll have to accept that the testing done by IBM was enough > > So only minor comments ... > http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/src/java.desktop/u > nix/classes/sun/awt/X11InputMethodBase.java.sdiff.html > > 730 case 0: //None of the value is set by Wnn > > "value is " -> "values are " ? > > > http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/src/java.desktop/u > nix/native/libawt_xawt/awt/awt_InputMethod.c.sdiff.html > > why did you move > > 26 #ifdef HEADLESS > 27 #error This file should not be included in headless library > 28 #endif > > > I think it should be first. It is also missing from the equivalent AIX file but that > is > up to you .. I really didn't look any further at the AIX files. > > .. and there seems no point to moving around some of the other includes > except to make the webrev harder to read :-) > > But good job cleaning up a lot of the formatting of the native code. > > -phil. > > > > > > On 5/18/18, 4:59 AM, Langer, Christoph wrote: > > Hi all, > > > > Here is an updated webrev: > > http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/ > > Can someone from the graphics/awt team please have a look at that > change? Especially checking that we don't break non-AIX platforms? Thanks > in advance. > > > > @Ichiroh: Thanks for your review and tests. Adressing your points: > > > >> resetCompositionState() was missing in > >> src/java.desktop/aix/classes/sun/awt/X11InputMethod.java > >> > ========================================================== > >> == > >> --- a/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Wed > May > >> 09 09:05:32 2018 +0900 > >> +++ b/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Mon > >> May > >> 14 21:25:50 2018 +0900 > >> @@ -56,6 +56,21 @@ > >> } > >> > >> /** > >> + * Reset the composition state to the current composition state. > >> + */ > >> + protected void resetCompositionState() { > >> + if (compositionEnableSupported&& haveActiveClient()) { > >> + try { > >> + /* Restore the composition mode to the last saved > >> composition > >> + mode. */ > >> + setCompositionEnabled(savedCompositionState); > >> + } catch (UnsupportedOperationException e) { > >> + compositionEnableSupported = false; > >> + } > >> + } > >> + } > >> + > >> + /** > >> * Activate input method. > >> */ > >> public synchronized void activate() { > >> > ========================================================== > > Good catch. I've incorporated that in my new webrev. > > > >> Otherwise, > >> we could not find out any functional difference on Linux. > >> we could not find out any functional difference between our modified > code and your code on AIX. > >> > >> By code check, we found following difference. > >> > ========================================================== > >> == > >> --- a/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c > >> Wed May 09 09:05:32 2018 +0900 > >> +++ b/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c > >> Mon May 14 21:25:50 2018 +0900 > >> @@ -248,6 +248,10 @@ > >> "flushText", > >> "()V"); > >> JNU_CHECK_EXCEPTION_RETURN(env, NULL); > >> + if ((*env)->ExceptionOccurred(env)) { > >> + (*env)->ExceptionDescribe(env); > >> + (*env)->ExceptionClear(env); > >> + } > >> /* IMPORTANT: > >> The order of the following calls is critical since > >> "imInstance" may > >> point to the global reference itself, if > >> "freeX11InputMethodData" is called > >> > ========================================================== > >> > >> Did you remove this code intentionally ? > > Yes, I removed that one intentionally. There is no point in doing the > Exception check/clearing after a call to > JNU_CHECK_EXCEPTION_RETURN(env, NULL); > > > >> Otherwise, I think the other changes were acceptable. > > ?? > > > > Thanks and Best regards > > Christoph > > From Sergey.Bylokhov at oracle.com Tue May 29 03:51:52 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 28 May 2018 20:51:52 -0700 Subject: [11] Review Request: 8195624 Desktop API cannot be used without permission to read "os.version" Message-ID: <49133a11-5170-9525-7076-7550345eae15@oracle.com> Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8195624 Webrev: http://cr.openjdk.java.net/~serb/8195624/webrev.00 The "OSInfo.getWindowsVersion()" which requires "os.version" permission was removed. It was possible to use doPrivileged(), but I doubt that versions prior of Windows Vista are supported. -- Best regards, Sergey. From krishna.addepalli at oracle.com Tue May 29 09:28:02 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 29 May 2018 02:28:02 -0700 (PDT) Subject: [11][JDK-8197810]RFR: Test java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html fails on Windows In-Reply-To: <500f353e-59bb-42c7-94cd-0d4b00861efb@default> References: <500f353e-59bb-42c7-94cd-0d4b00861efb@default> Message-ID: <78f73c94-034a-4642-b42a-46968c28ed9b@default> Gentle reminder to review this. Thanks, Krishna From: Krishna Addepalli Sent: Tuesday, May 8, 2018 3:29 PM To: awt-dev at openjdk.java.net Subject: [11][JDK-8197810]RFR: Test java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html fails on Windows Hi All Please review a fix for JDK-8197810: https://bugs.openjdk.java.net/browse/JDK-8197810 , Webrev: http://cr.openjdk.java.net/~kaddepalli/8197810/webrev00/ The basic problem is that, the Robot mouse move is moving to position where item 0 is located (which is already selected), and selecting it. Since this item is already selected, there is no new item selection event generated, which is why the test fails. Fix is to move the mouse to a position where item1 is located, so that the event is triggered. Along with this fix, I have also fixed these other problems: 1. Removed the applet machinery around the test and made it simple. 2. The test was not disposing the window in case of failure. 3. Test was using lock to determine the success or failure, but it could lead to a deadlock/ failure of the test since the main thread would acquire the lock and wait for it to get notified. Instead, CountDownLatch is a cleaner solution for the same. 4. Cleaned up the imports. I have tested the fix on Windows 10, Mac 10.13.4, Ubuntu 16.10 and it works. Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue May 29 15:18:24 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 29 May 2018 08:18:24 -0700 Subject: [11][JDK-8197810]RFR: Test java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.html fails on Windows In-Reply-To: <500f353e-59bb-42c7-94cd-0d4b00861efb@default> References: <500f353e-59bb-42c7-94cd-0d4b00861efb@default> Message-ID: Hi, Krishna. On 08/05/2018 02:59, Krishna Addepalli wrote: > The basic problem is that, the Robot mouse move is moving to position > where item 0 is located (which is already selected), and selecting it. > Since this item is already selected, there is no new item selection > event generated, which is why the test fails. As far as I understand the usecase which your describe was implemented intentionally in this test to verify the bug: https://bugs.openjdk.java.net/browse/JDK-4902933 Did you check what is the reason of behavior change? -- Best regards, Sergey. From philip.race at oracle.com Wed May 30 18:15:10 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 May 2018 11:15:10 -0700 Subject: [11] Review Request: 8195624 Desktop API cannot be used without permission to read "os.version" In-Reply-To: <49133a11-5170-9525-7076-7550345eae15@oracle.com> References: <49133a11-5170-9525-7076-7550345eae15@oracle.com> Message-ID: <567d7eb6-8e2e-71c9-06a2-00a6edec3c64@oracle.com> +1 -phil. On 05/28/2018 08:51 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195624 > Webrev: http://cr.openjdk.java.net/~serb/8195624/webrev.00 > > The "OSInfo.getWindowsVersion()" which requires "os.version" > permission was removed. It was possible to use doPrivileged(), but I > doubt that versions prior of Windows Vista are supported. > > From philip.race at oracle.com Wed May 30 18:22:21 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 May 2018 11:22:21 -0700 Subject: [11] Review Request: 8203380 Missing platform and bug information for MouseModifiersInKeyEvent test In-Reply-To: References: Message-ID: +1 -phil. On 05/17/2018 03:17 PM, Sergey Bylokhov wrote: > Hello. > Please review small fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203380 > > There is no bug and platform information for this test in the problem > list, but it should point to JDK-8157147 on linux/solaris. > Since this test was added to the problem list in JDK-8202811 I assume > it may hang on windows as well. > > Fix is inline below: > > --- a/test/jdk/ProblemList.txt Thu May 17 14:41:23 2018 -0700 > +++ b/test/jdk/ProblemList.txt Thu May 17 15:16:22 2018 -0700 > @@ -492,7 +492,7 @@ > > java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java > 8203004 linux-all > java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java > 7107528 linux-all,macosx-all > java/awt/Mouse/MouseDragEvent/MouseDraggedTest.java 8080676 linux-all > -java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersInKeyEvent.java > +java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersInKeyEvent.java > 8157147 linux-all,solaris-all,windows-all > java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick.html 8148041 > linux-all > java/awt/Toolkit/DesktopProperties/rfe4758438.java 8193547 linux-all > java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java > 6847163 > > From philip.race at oracle.com Wed May 30 18:36:23 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 May 2018 11:36:23 -0700 Subject: [11] Review Request: 8202051 Address compilation warnings in libawt with VS2017 In-Reply-To: <786eedc9-a1c2-a4c3-0741-cc5b529c9cf8@oracle.com> References: <786eedc9-a1c2-a4c3-0741-cc5b529c9cf8@oracle.com> Message-ID: The cast of HINSTANCE to int and comparison to 32 needed some checking .. no matter whether the compiler complained or not. Could it be a negative value ? Isn't it a pointer ? The docs here for ShellExcute https://msdn.microsoft.com/en-us/library/windows/desktop/bb762153(v=vs.85).aspx seem to say it is safe to do the cast + comparison. So +1 -phil. On 05/26/2018 02:19 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202051 > Webrev: http://cr.openjdk.java.net/~serb/8202051/webrev.00 > > The warnings which were disabled in JDK-8202052[1] are fixed. Note > that these warnings were found in debug build only. > - warning C4291: one more delete[] operator was added. see [2]. > - warning C4311/C4302: intermediate cast to the "intptr_t" was added. > > [1] https://bugs.openjdk.java.net/browse/JDK-8202052 > [2] https://msdn.microsoft.com/en-us/library/cxdxz3x6.aspx >