From github.com+90066231+alisenchung at openjdk.java.net  Fri Oct  1 00:21:40 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Fri, 1 Oct 2021 00:21:40 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v8]
In-Reply-To: <IkLXCri7K15PKo47WW73qa5x5kz3_TrDxhd7kiqvnAw=.f09030d9-8663-4425-8ba4-a3aaf2571dd6@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <zsJFJUWvjsJU0y0oAZnwYSsP4ohFybmjpc3zLCUbBFk=.b3f71931-d4a7-46b4-95e6-d00a1bd74e51@github.com>
 <IkLXCri7K15PKo47WW73qa5x5kz3_TrDxhd7kiqvnAw=.f09030d9-8663-4425-8ba4-a3aaf2571dd6@github.com>
Message-ID: <JfL653sc74SGOMlG6wj9V_KCktQWM4VCaKcj0CiBPas=.6b2cce94-87c9-4fdf-a97c-eb8f918489b3@github.com>

On Wed, 29 Sep 2021 22:59:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> It sound strange, isn't the "_deliverMoveResizeEvent" should be called on the resize only, why it affect the mouse move events which posted later? the new flag NSWindowStyleMaskFullScreen will work when the window was moved to the full screen, what about the case when the window will moved from the full screen -> the mouse will appier outside of the window?

It looks like the line was added for the previous bug only for when fullscreen mode is turned off and the mouse is outside the window. Entering fullscreen already posts a mouseEntered event.

> BTW we also have a call to synthesizeMouseEnteredExitedEventsForAllWindows in the windowDidEnterFullScreen which should do what you tried to achieve in the latest patch, why it does not work?

I'm don't see windowDidEnterFullScreen calls when the window is being fullscreened.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From serb at openjdk.java.net  Fri Oct  1 01:49:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 1 Oct 2021 01:49:36 GMT
Subject: RFR: 8274465: Fix
 javax/swing/text/ParagraphView/6364882/bug6364882.java failures
In-Reply-To: <8-ZdjnyUa7I3IOqegK8TOviOQVx0O3rrKppceY_71R0=.aa20230f-bc96-413d-91f1-2731c62a9639@github.com>
References: <8-ZdjnyUa7I3IOqegK8TOviOQVx0O3rrKppceY_71R0=.aa20230f-bc96-413d-91f1-2731c62a9639@github.com>
Message-ID: <PjOSCbED4cuhQeHjbSonrMSK905ijYvyGnXkPEAhPe4=.fa709304-07e5-40e9-8611-d8e68915bd0b@github.com>

On Wed, 29 Sep 2021 19:48:20 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I made the test and its assertions more flexible in regards to the font size and to the number of lines.
> 
> The test still requires there are at least four lines so that the text is wrapped before the first hard line break; thus at least one line of text is justified. This pre-requisite gets broken if `font-size: 4pt` property is added to the `style` attribute in my local environment. I also ran the test with a few larger font sizes, the updated test passes successfully.
> 
> I made sure the image is saved if any exception gets thrown from `checkJustification`, which wasn't the case.
> 
> This PR replaces #5744.

I assume that the update test still can be used for 6364882 verification.

-------------

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5761


From philip.race at oracle.com  Fri Oct  1 01:56:01 2021
From: philip.race at oracle.com (Philip Race)
Date: Thu, 30 Sep 2021 18:56:01 -0700
Subject: CFV: New Client Libraries Group Member : Prasanta Sadhukhan
 (psadhukhan)
In-Reply-To: <37846e8d-9c3d-5050-bcf4-c8d096b19287@oracle.com>
References: <37846e8d-9c3d-5050-bcf4-c8d096b19287@oracle.com>
Message-ID: <406ebe75-322a-db43-87e9-db7395189220@oracle.com>

Vote:? yes

-phil


From philip.race at oracle.com  Fri Oct  1 01:55:59 2021
From: philip.race at oracle.com (Philip Race)
Date: Thu, 30 Sep 2021 18:55:59 -0700
Subject: CFV: New Client Libraries Group Member : Prasanta Sadhukhan
 (psadhukhan)
In-Reply-To: <37846e8d-9c3d-5050-bcf4-c8d096b19287@oracle.com>
References: <37846e8d-9c3d-5050-bcf4-c8d096b19287@oracle.com>
Message-ID: <4f8a5ea9-6104-a62b-04f7-8781e463792d@oracle.com>

Vote: yes

-phil



From philip.race at oracle.com  Fri Oct  1 01:56:46 2021
From: philip.race at oracle.com (Philip Race)
Date: Thu, 30 Sep 2021 18:56:46 -0700
Subject: CFV: New Client Libraries Group Member : Pankaj Bansal (pbansal)
In-Reply-To: <9bc8698b-35cc-1faa-4dac-e4c97f43254c@oracle.com>
References: <9bc8698b-35cc-1faa-4dac-e4c97f43254c@oracle.com>
Message-ID: <06eb9c65-e207-fbc4-13f0-b0c15bee3da5@oracle.com>

Vote: yes

-phil.


From serb at openjdk.java.net  Fri Oct  1 01:59:34 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 1 Oct 2021 01:59:34 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v8]
In-Reply-To: <JfL653sc74SGOMlG6wj9V_KCktQWM4VCaKcj0CiBPas=.6b2cce94-87c9-4fdf-a97c-eb8f918489b3@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <zsJFJUWvjsJU0y0oAZnwYSsP4ohFybmjpc3zLCUbBFk=.b3f71931-d4a7-46b4-95e6-d00a1bd74e51@github.com>
 <IkLXCri7K15PKo47WW73qa5x5kz3_TrDxhd7kiqvnAw=.f09030d9-8663-4425-8ba4-a3aaf2571dd6@github.com>
 <JfL653sc74SGOMlG6wj9V_KCktQWM4VCaKcj0CiBPas=.6b2cce94-87c9-4fdf-a97c-eb8f918489b3@github.com>
Message-ID: <o67PrNbxVvgnrACOlH6bkIVpOD1BUZpXq1_wAEYEsaI=.111c9f06-ead3-4d23-8e56-5a59a29b5eb5@github.com>

On Fri, 1 Oct 2021 00:18:50 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> I'm don't see windowDidEnterFullScreen calls when the window is being fullscreened.

As far as I understand the windowDidEnterFullScreen should be called when the window moved to the fullscreen mode
https://developer.apple.com/documentation/appkit/nswindowdelegate/1419116-windowdidenterfullscreen?language=objc

There are two fullscreen modes on macOS, one of them can be set via GraphicsDevice.setFullScreenWindow() and another one can be set by pressing the maximized button(https://support.apple.com/guide/mac-help/use-apps-in-full-screen-mchl9c21d2be/mac), which one did you test?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From github.com+90066231+alisenchung at openjdk.java.net  Fri Oct  1 02:10:34 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Fri, 1 Oct 2021 02:10:34 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v8]
In-Reply-To: <o67PrNbxVvgnrACOlH6bkIVpOD1BUZpXq1_wAEYEsaI=.111c9f06-ead3-4d23-8e56-5a59a29b5eb5@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <zsJFJUWvjsJU0y0oAZnwYSsP4ohFybmjpc3zLCUbBFk=.b3f71931-d4a7-46b4-95e6-d00a1bd74e51@github.com>
 <IkLXCri7K15PKo47WW73qa5x5kz3_TrDxhd7kiqvnAw=.f09030d9-8663-4425-8ba4-a3aaf2571dd6@github.com>
 <JfL653sc74SGOMlG6wj9V_KCktQWM4VCaKcj0CiBPas=.6b2cce94-87c9-4fdf-a97c-eb8f918489b3@github.com>
 <o67PrNbxVvgnrACOlH6bkIVpOD1BUZpXq1_wAEYEsaI=.111c9f06-ead3-4d23-8e56-5a59a29b5eb5@github.com>
Message-ID: <l-PXwVydJJ87pw1bQWAzAFusROKW_H828sEVSDmuX4o=.15a9feac-0414-4efb-87d1-d00567bf27dd@github.com>

On Fri, 1 Oct 2021 01:56:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I'm don't see windowDidEnterFullScreen calls when the window is being fullscreened.
> 
> As far as I understand the windowDidEnterFullScreen should be called when the window moved to the fullscreen mode https://developer.apple.com/documentation/appkit/nswindowdelegate/1419116-windowdidenterfullscreen?language=objc
> 
> There are two fullscreen modes on macOS, one of them can be set via GraphicsDevice.setFullScreenWindow() and another one can be set by pressing the maximized button(https://support.apple.com/guide/mac-help/use-apps-in-full-screen-mchl9c21d2be/mac), which one did you test?

I tested both. The maximized button works properly, but fullscreen mode set by GraphicsDevice.setFullScreenWindow() isn't working properly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From serb at openjdk.java.net  Fri Oct  1 02:32:35 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 1 Oct 2021 02:32:35 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v8]
In-Reply-To: <l-PXwVydJJ87pw1bQWAzAFusROKW_H828sEVSDmuX4o=.15a9feac-0414-4efb-87d1-d00567bf27dd@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <zsJFJUWvjsJU0y0oAZnwYSsP4ohFybmjpc3zLCUbBFk=.b3f71931-d4a7-46b4-95e6-d00a1bd74e51@github.com>
 <IkLXCri7K15PKo47WW73qa5x5kz3_TrDxhd7kiqvnAw=.f09030d9-8663-4425-8ba4-a3aaf2571dd6@github.com>
 <JfL653sc74SGOMlG6wj9V_KCktQWM4VCaKcj0CiBPas=.6b2cce94-87c9-4fdf-a97c-eb8f918489b3@github.com>
 <o67PrNbxVvgnrACOlH6bkIVpOD1BUZpXq1_wAEYEsaI=.111c9f06-ead3-4d23-8e56-5a59a29b5eb5@github.com>
 <l-PXwVydJJ87pw1bQWAzAFusROKW_H828sEVSDmuX4o=.15a9feac-0414-4efb-87d1-d00567bf27dd@github.com>
Message-ID: <QtoADMwVmyVvi3l_GomveemEc0f8DnrVSbSkow6_UGg=.a33b1b68-0bbb-4b31-b633-519c99e4cbd6@github.com>

On Fri, 1 Oct 2021 02:07:17 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> I tested both. The maximized button works properly, but fullscreen mode set by GraphicsDevice.setFullScreenWindow() isn't working properly.

And the windowDidEnterFullScreen is not called? Or the fullscreen mode work because this method is called?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From serb at openjdk.java.net  Fri Oct  1 02:42:33 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 1 Oct 2021 02:42:33 GMT
Subject: RFR: 8274497: Unnecessary Vector usage in AquaFileSystemModel
In-Reply-To: <RynQ8VCkYlanv_kRkwdAOM3__VTfXj8gQA-Q8Pyz1XA=.cb960c01-46fa-4cba-87d3-83a3033e19fc@github.com>
References: <RynQ8VCkYlanv_kRkwdAOM3__VTfXj8gQA-Q8Pyz1XA=.cb960c01-46fa-4cba-87d3-83a3033e19fc@github.com>
Message-ID: <JGCX6CDVGAxrrdsCmdwTAemyLq2Q8BU-pd_52kRXXgc=.85b2aeb2-e633-4a72-a8c6-3b6d418fb02e@github.com>

On Fri, 17 Sep 2021 20:32:00 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Fields AquaFileSystemModel.fileCache and AquaFileSystemModel.FilesLoader.queuedTasks are accessed only under synchronized(fileCacheLock).
> It means extract synchronization by Vector is not needed.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5568


From serb at openjdk.java.net  Fri Oct  1 03:03:26 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 1 Oct 2021 03:03:26 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
In-Reply-To: <5Cz27HBZADRf75BlHEr0SD89JFLQqlt3mpqQ3qk0cUA=.adb31201-4b61-4bbd-bb12-3a94bb848aa4@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <ACRHmQY8PTs2zOxEKTqpI3UP2P_OdWXHccoaHC3FrwM=.6bd5a2c9-b92e-4fbb-babe-005fa463a221@github.com>
 <G4VS1_zNJrOsdiajA3_BrSPWpxzSsRafaUs66mTXv4s=.9a7105b0-c946-4815-a118-00c9fd17cbe1@github.com>
 <YEhDJGgk1J8Ah3dE9amNf6NrOgU6iy6Z23bY9IWA8KM=.c36e6711-f2c1-447b-a9c8-4eb8d2e7516f@github.com>
 <ZZfjrVx5ZQFBKjuIbhaaqGKs8GGDFSxAvfav3_gCAeY=.f7c112ec-757a-403f-b5b9-75908c232fb9@github.com>
 <POdns3iPgJRlh4vDuqFMSe5bl-AUKhd5lydHPLIpktI=.9aee1075-da2b-41c0-b4f3-35adca4c8091@github.com>
 <5Cz27HBZADRf75BlHEr0SD89JFLQqlt3mpqQ3qk0cUA=.adb31201-4b61-4bbd-bb12-3a94bb848aa4@github.com>
Message-ID: <Q2_pETtv2PafUoSxtn2nsu4sOS_3IP8GUxp_eQ0nNp0=.208cb2c6-10fa-4323-982f-58fcde648640@github.com>

On Thu, 30 Sep 2021 08:40:44 GMT, Masanori Yano <myano at openjdk.org> wrote:

> At 1st PaintEvent is processing, RepaintArea calls getGraphics(), then D3DScreenUpdateManager finally calls new PaintEvent().
> So, 2nd PaintEvent is posted and invoked later on EDT.

It does not look right, isn't it? Every time we show a frame we render its content twice, and the first rendering is always discarded. Probably we should validate the surface before we posting the first paint event and before we show the window.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5491


From jayathirth.d.v at oracle.com  Fri Oct  1 03:11:16 2021
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Fri, 1 Oct 2021 03:11:16 +0000
Subject: CFV: New Client Libraries Group Member : Pankaj Bansal (pbansal)
In-Reply-To: <9bc8698b-35cc-1faa-4dac-e4c97f43254c@oracle.com>
References: <9bc8698b-35cc-1faa-4dac-e4c97f43254c@oracle.com>
Message-ID: <A2FD6A01-3BB0-486A-8FC1-33F85D68AAB4@oracle.com>

Vote : Yes

Thanks,
Jay

> On 01-Oct-2021, at 4:33 AM, Philip Race <philip.race at oracle.com> wrote:
> 
> I hereby nominate Pankaj Bansal (pbansal) to Membership in the Client Libraries Group.
> 
> Pankaj has worked in the client team at Oracle since 2017 and in that time has contributed approximately 70-80 fixes [1], [2].
> He has been active on the old client lists, awt-dev [3], swing-dev[4] and 2d-dev [5] mailing list over that time,
> He is also a JDK committer and reviewer [6].
> 
> Votes are due by 5pm PDT Thursday 14th October 2021
> 
> //Only current Members of the Client Libraries Group [7] are eligible to vote on this nomination. ||
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [8].
> 
> [1] git log --author pbansal --format='%h %s'
> [2] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Pankaj+Bansal%22&type=commits
> [3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev
> [4] https://mail.openjdk.java.net/mailman/listinfo/swing-dev
> [5] https://mail.openjdk.java.net/mailman/listinfo/2d-dev
> [6] https://openjdk.java.net/census#pbansal
> [7] https://openjdk.java.net/census#client-libs
> [8] http://openjdk.java.net/groups/#member-vote <http://openjdk.java.net/groups/#member-vote%7C>



From jayathirth.d.v at oracle.com  Fri Oct  1 03:11:58 2021
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Fri, 1 Oct 2021 03:11:58 +0000
Subject: CFV: New Client Libraries Group Member : Prasanta Sadhukhan
 (psadhukhan)
In-Reply-To: <37846e8d-9c3d-5050-bcf4-c8d096b19287@oracle.com>
References: <37846e8d-9c3d-5050-bcf4-c8d096b19287@oracle.com>
Message-ID: <CBCCEE58-9488-45BF-A834-CD77ACB8C6E1@oracle.com>

Vote : Yes

Thanks,
Jay

> On 01-Oct-2021, at 4:33 AM, Philip Race <philip.race at oracle.com> wrote:
> 
> I hereby nominate Prasanta Sadhukhan (psadhukhan) to Membership in the Client Libraries Group.
> 
> Prasanta has worked in the client team at Oracle since 2015 and in that time has contributed approximately 460 fixes [1], [2].
> He has been active on the old client lists, awt-dev [3], swing-dev[4] and 2d-dev [5] mailing list over that time,
> He is also a JDK committer and reviewer [6].
> 
> Votes are due by 5pm PDT Thursday 14th October 2021
> 
> //Only current Members of the Client Libraries Group [7] are eligible to vote on this nomination. ||
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [8].
> 
> -Phil.
> 
> [1] git log --author psadhukhan --format='%h %s'
> [2] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Prasanta+Sadhukhan%22&type=commits
> [3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev
> [4] https://mail.openjdk.java.net/mailman/listinfo/swing-dev
> [5] https://mail.openjdk.java.net/mailman/listinfo/2d-dev
> [6] https://openjdk.java.net/census#psadhukhan
> [7] https://openjdk.java.net/census#client-libs
> [8] http://openjdk.java.net/groups/#member-vote <http://openjdk.java.net/groups/#member-vote%7C>



From alexey.ushakov at jetbrains.com  Fri Oct  1 05:07:43 2021
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Fri, 1 Oct 2021 07:07:43 +0200
Subject: CFV: New Client Libraries Group Member : Prasanta Sadhukhan
 (psadhukhan)
In-Reply-To: <37846e8d-9c3d-5050-bcf4-c8d096b19287@oracle.com>
References: <37846e8d-9c3d-5050-bcf4-c8d096b19287@oracle.com>
Message-ID: <7BACD0C4-90DE-44B2-B1D3-C9ADF749A4F8@jetbrains.com>

Vote: yes

Best Regards,
Alexey

> On 1 Oct 2021, at 01:03, Philip Race <philip.race at oracle.com> wrote:
> 
> I hereby nominate Prasanta Sadhukhan (psadhukhan) to Membership in the Client Libraries Group.
> 
> Prasanta has worked in the client team at Oracle since 2015 and in that time has contributed approximately 460 fixes [1], [2].
> He has been active on the old client lists, awt-dev [3], swing-dev[4] and 2d-dev [5] mailing list over that time,
> He is also a JDK committer and reviewer [6].
> 
> Votes are due by 5pm PDT Thursday 14th October 2021
> 
> //Only current Members of the Client Libraries Group [7] are eligible to vote on this nomination. ||
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [8].
> 
> -Phil.
> 
> [1] git log --author psadhukhan --format='%h %s'
> [2] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Prasanta+Sadhukhan%22&type=commits
> [3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev
> [4] https://mail.openjdk.java.net/mailman/listinfo/swing-dev
> [5] https://mail.openjdk.java.net/mailman/listinfo/2d-dev
> [6] https://openjdk.java.net/census#psadhukhan
> [7] https://openjdk.java.net/census#client-libs
> [8] http://openjdk.java.net/groups/#member-vote <http://openjdk.java.net/groups/#member-vote%7C>



From alexey.ushakov at jetbrains.com  Fri Oct  1 05:09:34 2021
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Fri, 1 Oct 2021 07:09:34 +0200
Subject: CFV: New Client Libraries Group Member : Pankaj Bansal (pbansal)
In-Reply-To: <9bc8698b-35cc-1faa-4dac-e4c97f43254c@oracle.com>
References: <9bc8698b-35cc-1faa-4dac-e4c97f43254c@oracle.com>
Message-ID: <3C200F2F-C7CE-4DA1-B844-3FA9A929CE50@jetbrains.com>

Vote: yes


Best Regards,
Alexey

> On 1 Oct 2021, at 01:03, Philip Race <philip.race at oracle.com> wrote:
> 
> I hereby nominate Pankaj Bansal (pbansal) to Membership in the Client Libraries Group.
> 
> Pankaj has worked in the client team at Oracle since 2017 and in that time has contributed approximately 70-80 fixes [1], [2].
> He has been active on the old client lists, awt-dev [3], swing-dev[4] and 2d-dev [5] mailing list over that time,
> He is also a JDK committer and reviewer [6].
> 
> Votes are due by 5pm PDT Thursday 14th October 2021
> 
> //Only current Members of the Client Libraries Group [7] are eligible to vote on this nomination. ||
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [8].
> 
> [1] git log --author pbansal --format='%h %s'
> [2] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Pankaj+Bansal%22&type=commits
> [3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev
> [4] https://mail.openjdk.java.net/mailman/listinfo/swing-dev
> [5] https://mail.openjdk.java.net/mailman/listinfo/2d-dev
> [6] https://openjdk.java.net/census#pbansal
> [7] https://openjdk.java.net/census#client-libs
> [8] http://openjdk.java.net/groups/#member-vote <http://openjdk.java.net/groups/#member-vote%7C>



From pbansal at openjdk.java.net  Fri Oct  1 06:55:31 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 1 Oct 2021 06:55:31 GMT
Subject: RFR: 8274497: Unnecessary Vector usage in AquaFileSystemModel
In-Reply-To: <RynQ8VCkYlanv_kRkwdAOM3__VTfXj8gQA-Q8Pyz1XA=.cb960c01-46fa-4cba-87d3-83a3033e19fc@github.com>
References: <RynQ8VCkYlanv_kRkwdAOM3__VTfXj8gQA-Q8Pyz1XA=.cb960c01-46fa-4cba-87d3-83a3033e19fc@github.com>
Message-ID: <LgNOUbfY_zubbY1UzhI8EVU5zVyKBz-s3iPyMUpBfP0=.ca6a0514-1af2-4c70-a8d6-440b43126e17@github.com>

On Fri, 17 Sep 2021 20:32:00 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Fields AquaFileSystemModel.fileCache and AquaFileSystemModel.FilesLoader.queuedTasks are accessed only under synchronized(fileCacheLock).
> It means extract synchronization by Vector is not needed.

Looks good to me

-------------

Marked as reviewed by pbansal (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5568


From github.com+90066231+alisenchung at openjdk.java.net  Fri Oct  1 06:55:34 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Fri, 1 Oct 2021 06:55:34 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v8]
In-Reply-To: <QtoADMwVmyVvi3l_GomveemEc0f8DnrVSbSkow6_UGg=.a33b1b68-0bbb-4b31-b633-519c99e4cbd6@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <zsJFJUWvjsJU0y0oAZnwYSsP4ohFybmjpc3zLCUbBFk=.b3f71931-d4a7-46b4-95e6-d00a1bd74e51@github.com>
 <IkLXCri7K15PKo47WW73qa5x5kz3_TrDxhd7kiqvnAw=.f09030d9-8663-4425-8ba4-a3aaf2571dd6@github.com>
 <JfL653sc74SGOMlG6wj9V_KCktQWM4VCaKcj0CiBPas=.6b2cce94-87c9-4fdf-a97c-eb8f918489b3@github.com>
 <o67PrNbxVvgnrACOlH6bkIVpOD1BUZpXq1_wAEYEsaI=.111c9f06-ead3-4d23-8e56-5a59a29b5eb5@github.com>
 <l-PXwVydJJ87pw1bQWAzAFusROKW_H828sEVSDmuX4o=.15a9feac-0414-4efb-87d1-d00567bf27dd@github.com>
 <QtoADMwVmyVvi3l_GomveemEc0f8DnrVSbSkow6_UGg=.a33b1b68-0bbb-4b31-b633-519c99e4cbd6@github.com>
Message-ID: <kA_rPdYUfFP7zOgENvAmX_HCddewWideMQA0bcfWMv4=.577664c3-afdf-4fd4-9595-c40b2b02365e@github.com>

On Fri, 1 Oct 2021 02:29:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> And the windowDidEnterFullScreen is not called? Or the fullscreen mode work because this method is called?

windowDIdEnterFullScreen isn't being called but entering fullscreen mode still posts a mouseEntered event.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From mvs at openjdk.java.net  Fri Oct  1 08:27:34 2021
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 1 Oct 2021 08:27:34 GMT
Subject: RFR: 8274597: [TESTBUG] Two of the dnd tests times out and fails
In-Reply-To: <bPoUm64FEMN2fC6sJm80cFX0JmHBrObu_IiaJn0M3zA=.61f066b3-426c-4a62-a399-5ba5d0b110ac@github.com>
References: <0ISZ7X0xu1zN3SLn-p1XkZm8Brkb-Ozu_nTe3RF8xXg=.f3b3c6ed-3719-4347-8f13-a8b89bc1d836@github.com>
 <bPoUm64FEMN2fC6sJm80cFX0JmHBrObu_IiaJn0M3zA=.61f066b3-426c-4a62-a399-5ba5d0b110ac@github.com>
Message-ID: <3gMmtwYbcWvX90UNLQoxsEcfuFVVUomDkgt7wTZsTUk=.622fae3d-3e36-42f8-9d22-534c7001656e@github.com>

On Thu, 30 Sep 2021 20:17:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> These two dnd tests fails most of the time with a time out, mostly noticed in windows 11 machines.
>> 1. java/awt/dnd/AcceptDropMultipleTimes/AcceptDropMultipleTimes.java
>> 2. java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
>> 
>> Fix:
>> From the logs, I have noticed that some of the non-daemon threads are still waiting even after the test execution is complete. So it could be possible that java is waiting for these threads to be finished execution before the main thread exits.
>> As a fix for this, I have put a Thread.sleep(100) at the end of the main() in order to enable other non-daemon threads get a chance to finish their execution before the main thread completes.
>
> Looks like the hang occurs in some of the hook executed at the "exit" step. DId you check which ShutdownHook is executed and hang? Is it possible it is some of the AWT toolkit related?
> 
> 	at java.lang.Object.wait(java.base at 11.0.14-ea/Native Method)
> 	- waiting on <0x00000000ff504d78> (a java.lang.Thread)
> 	at java.lang.Thread.join(java.base at 11.0.14-ea/Thread.java:1305)
> 	- waiting to re-lock in wait() <0x00000000ff504d78> (a java.lang.Thread)
> 	at java.lang.Thread.join(java.base at 11.0.14-ea/Thread.java:1379)
> 	at java.lang.ApplicationShutdownHooks.runHooks(java.base at 11.0.14-ea/ApplicationShutdownHooks.java:107)
> 	at java.lang.ApplicationShutdownHooks$1.run(java.base at 11.0.14-ea/ApplicationShutdownHooks.java:46)

@mrserb I can see three non-daemon threads in 'WAITING' state(given below). So looks like 'AWT-Shutdown' thread created by AWTAutoShutdown.java is the hook which is getting blocked. But I think this is an expected behaviour only as it will block this thread until all AWT tasks are complete. 
"main" #1 prio=5 os_prio=0 cpu=78.13ms elapsed=240.13s tid=0x0000017129532000 nid=0x1518 in Object.wait()  [0x0000001fb8ffe000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(java.base at 11.0.14-ea/Native Method)
	- waiting on <0x00000000ff504d78> (a java.lang.Thread)
	at java.lang.Thread.join(java.base at 11.0.14-ea/Thread.java:1305)
	- waiting to re-lock in wait() <0x00000000ff504d78> (a java.lang.Thread)
	at java.lang.Thread.join(java.base at 11.0.14-ea/Thread.java:1379)
	at java.lang.ApplicationShutdownHooks.runHooks(java.base at 11.0.14-ea/ApplicationShutdownHooks.java:107)
	at java.lang.ApplicationShutdownHooks$1.run(java.base at 11.0.14-ea/ApplicationShutdownHooks.java:46)
	at java.lang.Shutdown.runHooks(java.base at 11.0.14-ea/Shutdown.java:130)
	at java.lang.Shutdown.exit(java.base at 11.0.14-ea/Shutdown.java:174)
	- locked <0x00000000ff50a4e0> (a java.lang.Class for java.lang.Shutdown)
	at java.lang.Runtime.exit(java.base at 11.0.14-ea/Runtime.java:113)
	at java.lang.System.exit(java.base at 11.0.14-ea/System.java:1750)
	at com.sun.javatest.regtest.agent.AStatus.exit(AStatus.java:199)
	at com.sun.javatest.regtest.agent.MainWrapper.main(MainWrapper.java:84)


"AWT-Shutdown" #24 prio=5 os_prio=0 cpu=0.00ms elapsed=239.97s tid=0x000001714cd43800 nid=0x29c4 in Object.wait()  [0x0000001fba6fe000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(java.base at 11.0.14-ea/Native Method)
	- waiting on <0x00000000ff69b6c0> (a java.lang.Object)
	at java.lang.Object.wait(java.base at 11.0.14-ea/Object.java:328)
	at sun.awt.AWTAutoShutdown.run(java.desktop at 11.0.14-ea/AWTAutoShutdown.java:291)
	- waiting to re-lock in wait() <0x00000000ff69b6c0> (a java.lang.Object)
	at java.lang.Thread.run(java.base at 11.0.14-ea/Thread.java:834)



"AWT-EventQueue-0" #27 prio=6 os_prio=0 cpu=109.38ms elapsed=239.96s tid=0x000001714d006800 nid=0x1f70 waiting on condition  [0x0000001fba8fe000]
   java.lang.Thread.State: WAITING (parking)
	at jdk.internal.misc.Unsafe.park(java.base at 11.0.14-ea/Native Method)
	- parking to wait for  <0x00000000ff6eda50> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(java.base at 11.0.14-ea/LockSupport.java:194)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11.0.14-ea/AbstractQueuedSynchronizer.java:2081)
	at java.awt.EventQueue.getNextEvent(java.desktop at 11.0.14-ea/EventQueue.java:566)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11.0.14-ea/EventDispatchThread.java:190)
	at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11.0.14-ea/EventDispatchThread.java:124)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11.0.14-ea/EventDispatchThread.java:113)
	at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11.0.14-ea/EventDispatchThread.java:109)
	at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11.0.14-ea/EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.run(java.desktop at 11.0.14-ea/EventDispatchThread.java:90)

-------------

PR: https://git.openjdk.java.net/jdk/pull/5777


From github.com+741251+turbanoff at openjdk.java.net  Fri Oct  1 09:35:42 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 1 Oct 2021 09:35:42 GMT
Subject: RFR: 8274634: Use String.equals instead of String.compareTo in
 java.desktop
Message-ID: <wLvu4WcvTpZEPB68R9hdYIN3zxiGXTtRGHAeiNsgre8=.8b482331-cf8d-4ab9-8f4f-af0ab0dfc7a0@github.com>

In several places, String.compareTo was _compared_ with 0 ( via `== 0`).
Instead of this, we can use String.equals calls. `String.equals` is faster and shorter.

-------------

Commit messages:
 - [PATCH] Use String.equals instead of String.compareTo in java.desktop
 - [PATCH] Use String.equals instead of String.compareTo in java.desktop

Changes: https://git.openjdk.java.net/jdk/pull/5751/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5751&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274634
  Stats: 15 lines in 3 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5751.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5751/head:pull/5751

PR: https://git.openjdk.java.net/jdk/pull/5751


From serb at openjdk.java.net  Fri Oct  1 09:35:42 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 1 Oct 2021 09:35:42 GMT
Subject: RFR: 8274634: Use String.equals instead of String.compareTo in
 java.desktop
In-Reply-To: <wLvu4WcvTpZEPB68R9hdYIN3zxiGXTtRGHAeiNsgre8=.8b482331-cf8d-4ab9-8f4f-af0ab0dfc7a0@github.com>
References: <wLvu4WcvTpZEPB68R9hdYIN3zxiGXTtRGHAeiNsgre8=.8b482331-cf8d-4ab9-8f4f-af0ab0dfc7a0@github.com>
Message-ID: <ASvfjv6IzjKKuIsL8DhKgz9yMHmuw_RuHF5LWaHOZ48=.e911a454-2a80-4091-9c63-85ce3ee39195@github.com>

On Wed, 29 Sep 2021 13:27:32 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> In several places, String.compareTo was _compared_ with 0 ( via `== 0`).
> Instead of this, we can use String.equals calls. `String.equals` is faster and shorter.

Looks fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5751


From github.com+741251+turbanoff at openjdk.java.net  Fri Oct  1 09:45:09 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 1 Oct 2021 09:45:09 GMT
Subject: RFR: 8274635: Use String.equals instead of String.compareTo in
 jdk.accessibility
Message-ID: <DRuPYmFwgjz23wD4kqXnCnC4zgmTu2hdnDTLD9OV-SU=.cd893593-3493-4d0d-8835-b73486bd7f8c@github.com>

In several places, String.compareTo was _compared_ with 0 ( via `== 0`).
Instead of this, we can use String.equals calls. `String.equals` is faster and shorter.

-------------

Commit messages:
 - [PATCH] Use String.equals instead of String.compareTo in jdk.accessibility

Changes: https://git.openjdk.java.net/jdk/pull/5752/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5752&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274635
  Stats: 14 lines in 2 files changed: 0 ins; 2 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5752.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5752/head:pull/5752

PR: https://git.openjdk.java.net/jdk/pull/5752


From serb at openjdk.java.net  Fri Oct  1 09:45:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 1 Oct 2021 09:45:10 GMT
Subject: RFR: 8274635: Use String.equals instead of String.compareTo in
 jdk.accessibility
In-Reply-To: <DRuPYmFwgjz23wD4kqXnCnC4zgmTu2hdnDTLD9OV-SU=.cd893593-3493-4d0d-8835-b73486bd7f8c@github.com>
References: <DRuPYmFwgjz23wD4kqXnCnC4zgmTu2hdnDTLD9OV-SU=.cd893593-3493-4d0d-8835-b73486bd7f8c@github.com>
Message-ID: <8LIJQv6Rl3IiWVxWVrsJ3QJLIAzPsmmFcT6O9I1B30E=.fab9a910-10ec-4ee8-a4a6-1779b8935ff2@github.com>

On Wed, 29 Sep 2021 13:34:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> In several places, String.compareTo was _compared_ with 0 ( via `== 0`).
> Instead of this, we can use String.equals calls. `String.equals` is faster and shorter.

Looks fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5752


From serb at openjdk.java.net  Fri Oct  1 10:33:37 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 1 Oct 2021 10:33:37 GMT
Subject: RFR: 8274635: Use String.equals instead of String.compareTo in
 jdk.accessibility
In-Reply-To: <DRuPYmFwgjz23wD4kqXnCnC4zgmTu2hdnDTLD9OV-SU=.cd893593-3493-4d0d-8835-b73486bd7f8c@github.com>
References: <DRuPYmFwgjz23wD4kqXnCnC4zgmTu2hdnDTLD9OV-SU=.cd893593-3493-4d0d-8835-b73486bd7f8c@github.com>
Message-ID: <82yV5c8FVJ5ld179PGNR5sOZUQsMmQb5s88NkaHmBPg=.596cf297-df07-4e06-b2b2-17c420b05a2a@github.com>

On Wed, 29 Sep 2021 13:34:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> In several places, String.compareTo was _compared_ with 0 ( via `== 0`).
> Instead of this, we can use String.equals calls. `String.equals` is faster and shorter.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5752


From serb at openjdk.java.net  Fri Oct  1 10:33:37 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 1 Oct 2021 10:33:37 GMT
Subject: RFR: 8274634: Use String.equals instead of String.compareTo in
 java.desktop
In-Reply-To: <wLvu4WcvTpZEPB68R9hdYIN3zxiGXTtRGHAeiNsgre8=.8b482331-cf8d-4ab9-8f4f-af0ab0dfc7a0@github.com>
References: <wLvu4WcvTpZEPB68R9hdYIN3zxiGXTtRGHAeiNsgre8=.8b482331-cf8d-4ab9-8f4f-af0ab0dfc7a0@github.com>
Message-ID: <yqKY8aBbS4uqLYycnn4AHIPzP8xbiNwikqnqrh0tTfs=.59e8f310-8d99-4c5e-a2ba-5b87d2457ead@github.com>

On Wed, 29 Sep 2021 13:27:32 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> In several places, String.compareTo was _compared_ with 0 ( via `== 0`).
> Instead of this, we can use String.equals calls. `String.equals` is faster and shorter.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5751


From pbansal at openjdk.java.net  Fri Oct  1 11:08:30 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 1 Oct 2021 11:08:30 GMT
Subject: RFR: 8274634: Use String.equals instead of String.compareTo in
 java.desktop
In-Reply-To: <wLvu4WcvTpZEPB68R9hdYIN3zxiGXTtRGHAeiNsgre8=.8b482331-cf8d-4ab9-8f4f-af0ab0dfc7a0@github.com>
References: <wLvu4WcvTpZEPB68R9hdYIN3zxiGXTtRGHAeiNsgre8=.8b482331-cf8d-4ab9-8f4f-af0ab0dfc7a0@github.com>
Message-ID: <Putj1Ucce7nqNkOtECGee2n2FfsEL5OfnHiXQkLns30=.f1038b6c-8562-42ee-a855-31d83678a813@github.com>

On Wed, 29 Sep 2021 13:27:32 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> In several places, String.compareTo was _compared_ with 0 ( via `== 0`).
> Instead of this, we can use String.equals calls. `String.equals` is faster and shorter.

Looks good to me

-------------

Marked as reviewed by pbansal (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5751


From github.com+741251+turbanoff at openjdk.java.net  Fri Oct  1 11:54:55 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 1 Oct 2021 11:54:55 GMT
Subject: RFR: 8274640: Cleanup unnecessary null comparison before instanceof
 check in java.desktop
Message-ID: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>

Updated code checks both non-null and instance of a class in java.desktop module classes.
The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. 
Similar cleanups
1. [JDK-8273484](https://bugs.openjdk.java.net/browse/JDK-8273484) java.naming
2. [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) java.base

-------------

Commit messages:
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.desktop
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.desktop
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.desktop
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.desktop
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.desktop
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.desktop
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.desktop

Changes: https://git.openjdk.java.net/jdk/pull/5482/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5482&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274640
  Stats: 543 lines in 122 files changed: 0 ins; 114 del; 429 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5482/head:pull/5482

PR: https://git.openjdk.java.net/jdk/pull/5482


From github.com+741251+turbanoff at openjdk.java.net  Fri Oct  1 16:04:50 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 1 Oct 2021 16:04:50 GMT
Subject: RFR: 8274651: Possible race in FontDesignMetrics.KeyReference.dispose
Message-ID: <IPUit2hWm84B_HDXEzOnWiH-7zKTIsULEPaURsJyqSw=.bf1c6c4a-1b9e-4a71-82b1-326d8802a805@github.com>

Possible race condition could happen if another thread put value into 'metricsCache' by the same key.
We can use `ConcurrentHashMap.remove(key, value)` method to avoid it.

-------------

Commit messages:
 - [PATCH] Fix possible concurrency problem in FontDesignMetrics.KeyReference.dispose method

Changes: https://git.openjdk.java.net/jdk/pull/5753/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5753&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274651
  Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5753.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5753/head:pull/5753

PR: https://git.openjdk.java.net/jdk/pull/5753


From serb at openjdk.java.net  Fri Oct  1 16:04:50 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 1 Oct 2021 16:04:50 GMT
Subject: RFR: 8274651: Possible race in
 FontDesignMetrics.KeyReference.dispose
In-Reply-To: <IPUit2hWm84B_HDXEzOnWiH-7zKTIsULEPaURsJyqSw=.bf1c6c4a-1b9e-4a71-82b1-326d8802a805@github.com>
References: <IPUit2hWm84B_HDXEzOnWiH-7zKTIsULEPaURsJyqSw=.bf1c6c4a-1b9e-4a71-82b1-326d8802a805@github.com>
Message-ID: <j9Mpp-5-QEYXUICV1Hlp4L88RCx2UPumtppcM8t9r54=.629536f8-e126-401d-aca7-f6a2e3ffc2e6@github.com>

On Wed, 29 Sep 2021 14:01:17 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Possible race condition could happen if another thread put value into 'metricsCache' by the same key.
> We can use `ConcurrentHashMap.remove(key, value)` method to avoid it.

Looks fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5753


From prr at openjdk.java.net  Fri Oct  1 16:44:32 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 1 Oct 2021 16:44:32 GMT
Subject: RFR: 8274651: Possible race in
 FontDesignMetrics.KeyReference.dispose
In-Reply-To: <IPUit2hWm84B_HDXEzOnWiH-7zKTIsULEPaURsJyqSw=.bf1c6c4a-1b9e-4a71-82b1-326d8802a805@github.com>
References: <IPUit2hWm84B_HDXEzOnWiH-7zKTIsULEPaURsJyqSw=.bf1c6c4a-1b9e-4a71-82b1-326d8802a805@github.com>
Message-ID: <u55l0RPhUG3xsAFO_xXetlcrpHm1l4ICkXThXrp4o2o=.eb7d252e-436f-4e6d-8612-5e811e3e2bad@github.com>

On Wed, 29 Sep 2021 14:01:17 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Possible race condition could happen if another thread put value into 'metricsCache' by the same key.
> We can use `ConcurrentHashMap.remove(key, value)` method to avoid it.

The race condition isn't actually a problem, as we'd just need to repopulate the cache in this unlikely scenario, but the fix looks fine. I guess this method was just overlooked when the code was first written.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5753


From serb at openjdk.java.net  Fri Oct  1 18:12:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 1 Oct 2021 18:12:36 GMT
Subject: RFR: 8274651: Possible race in
 FontDesignMetrics.KeyReference.dispose
In-Reply-To: <IPUit2hWm84B_HDXEzOnWiH-7zKTIsULEPaURsJyqSw=.bf1c6c4a-1b9e-4a71-82b1-326d8802a805@github.com>
References: <IPUit2hWm84B_HDXEzOnWiH-7zKTIsULEPaURsJyqSw=.bf1c6c4a-1b9e-4a71-82b1-326d8802a805@github.com>
Message-ID: <xX2IQm1eIph_-ap0-B_xarGcTZu6CX585AaQVeQshbk=.07149115-d616-4a79-bf90-2f97ea7086ed@github.com>

On Wed, 29 Sep 2021 14:01:17 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Possible race condition could happen if another thread put value into 'metricsCache' by the same key.
> We can use `ConcurrentHashMap.remove(key, value)` method to avoid it.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5753


From github.com+87324768+lawrence-andrew at openjdk.java.net  Fri Oct  1 18:37:04 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Fri, 1 Oct 2021 18:37:04 GMT
Subject: RFR: 8274456 : Remove jtreg tag manual=yesno
 java/awt/print/PrinterJob/PageDialogTest.java
Message-ID: <gMmkvVXiwZJd7lPeSzgz2N2IpQBxJJaF8gWKrWY1Brk=.df46feb9-3043-4074-81b8-964c3686cba7@github.com>

1) Removed =yesno
2) After running the test case, test  UI will close immediately. Where the user cannot interact so rewrote the test case.
a) Toolkit Modal Dialog will be shown after clicking the show button.
b) Added timeout & tested
c) Step by step instruction what the user has to perform

@shurymury

-------------

Commit messages:
 - 8274456 : Remove jtreg tag manual=yesno java/awt/print/PrinterJob/PageDialogTest.java

Changes: https://git.openjdk.java.net/jdk/pull/5789/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5789&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274456
  Stats: 180 lines in 1 file changed: 44 ins; 90 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5789.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5789/head:pull/5789

PR: https://git.openjdk.java.net/jdk/pull/5789


From aivanov at openjdk.java.net  Fri Oct  1 18:45:35 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 1 Oct 2021 18:45:35 GMT
Subject: RFR: 8274465: Fix
 javax/swing/text/ParagraphView/6364882/bug6364882.java failures
In-Reply-To: <PjOSCbED4cuhQeHjbSonrMSK905ijYvyGnXkPEAhPe4=.fa709304-07e5-40e9-8611-d8e68915bd0b@github.com>
References: <8-ZdjnyUa7I3IOqegK8TOviOQVx0O3rrKppceY_71R0=.aa20230f-bc96-413d-91f1-2731c62a9639@github.com>
 <PjOSCbED4cuhQeHjbSonrMSK905ijYvyGnXkPEAhPe4=.fa709304-07e5-40e9-8611-d8e68915bd0b@github.com>
Message-ID: <lvVeNfCPIRvdWqFshwE5hpgElddk0oxBifg6sIb6zGw=.5180f43f-f7e0-4063-adcb-aba4849f7518@github.com>

On Fri, 1 Oct 2021 01:46:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I assume that the update test still can be used for 6364882 verification.

Yes, the assertions still work correctly. In JDK 6-b75, the explicitly broken lines are justified:


java.lang.Error: Line 5 is justified: 453 > 290
        at bug6364882.checkJustification(bug6364882.java:192)
        ?
java.lang.Error: Line 5 and 6 have different width: 453 != 567
        at bug6364882.checkJustification(bug6364882.java:198)
        ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5761


From aivanov at openjdk.java.net  Fri Oct  1 18:45:36 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 1 Oct 2021 18:45:36 GMT
Subject: Integrated: 8274465: Fix
 javax/swing/text/ParagraphView/6364882/bug6364882.java failures
In-Reply-To: <8-ZdjnyUa7I3IOqegK8TOviOQVx0O3rrKppceY_71R0=.aa20230f-bc96-413d-91f1-2731c62a9639@github.com>
References: <8-ZdjnyUa7I3IOqegK8TOviOQVx0O3rrKppceY_71R0=.aa20230f-bc96-413d-91f1-2731c62a9639@github.com>
Message-ID: <iSQ8YCZsiJhAqgSnx3Adzpspn2LogJGRmayIttYEjbA=.1531b1da-7dab-4dba-b8c4-e5d7cc4b9d38@github.com>

On Wed, 29 Sep 2021 19:48:20 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I made the test and its assertions more flexible in regards to the font size and to the number of lines.
> 
> The test still requires there are at least four lines so that the text is wrapped before the first hard line break; thus at least one line of text is justified. This pre-requisite gets broken if `font-size: 4pt` property is added to the `style` attribute in my local environment. I also ran the test with a few larger font sizes, the updated test passes successfully.
> 
> I made sure the image is saved if any exception gets thrown from `checkJustification`, which wasn't the case.
> 
> This PR replaces #5744.

This pull request has now been integrated.

Changeset: bb4500d0
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bb4500d0d227cbb238bd6c862e143f864106a31a
Stats:     64 lines in 1 file changed: 20 ins; 7 del; 37 mod

8274465: Fix javax/swing/text/ParagraphView/6364882/bug6364882.java failures

Reviewed-by: jiefu, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/5761


From serb at openjdk.java.net  Fri Oct  1 19:22:26 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 1 Oct 2021 19:22:26 GMT
Subject: RFR: 8274597: [TESTBUG] Two of the dnd tests times out and fails
In-Reply-To: <3gMmtwYbcWvX90UNLQoxsEcfuFVVUomDkgt7wTZsTUk=.622fae3d-3e36-42f8-9d22-534c7001656e@github.com>
References: <0ISZ7X0xu1zN3SLn-p1XkZm8Brkb-Ozu_nTe3RF8xXg=.f3b3c6ed-3719-4347-8f13-a8b89bc1d836@github.com>
 <bPoUm64FEMN2fC6sJm80cFX0JmHBrObu_IiaJn0M3zA=.61f066b3-426c-4a62-a399-5ba5d0b110ac@github.com>
 <3gMmtwYbcWvX90UNLQoxsEcfuFVVUomDkgt7wTZsTUk=.622fae3d-3e36-42f8-9d22-534c7001656e@github.com>
Message-ID: <Y5yp9hdvALRyjAEm8N1Mgys7g99xvVLCnQ-AKzs6ZUA=.0b2beada-07f1-4e4d-a572-5d47f7513d42@github.com>

On Fri, 1 Oct 2021 08:22:50 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>  I can see three non-daemon threads in 'WAITING' state(given below). So looks like 'AWT-Shutdown' thread created by AWTAutoShutdown.java is the hook which is getting blocked. But I think this is an expected behaviour only as it will block this thread until all AWT tasks are complete.

This issue is unrelated to the non-daemon threads since the System.exit() is called, it should exit the whole JVM. But before exit it executes some number of registered ShutdownHook, we need to check what ShutdownHook is executed and why it hangs. The AWT-Shutdown is not a hook, it is a thread which prevents vm exit if there are some UI peers, but it does ont prevent the System.exit().

-------------

PR: https://git.openjdk.java.net/jdk/pull/5777


From prr at openjdk.java.net  Fri Oct  1 21:10:27 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 1 Oct 2021 21:10:27 GMT
Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid>
 in launcher code [v4]
In-Reply-To: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
Message-ID: <6g0EhtvtHXXr80qFDYESUQ-PhKf97oikta-MnPf2QSY=.4e52ca70-f604-4bbd-b340-9229d6edb118@github.com>

> macOS launcher code sets JAVA_MAIN_CLASS_<pid> which is read by AWT to set the name of the application in the system menu bar.
> 
> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549
> 
> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose,
> we can set that instead of the env. var and avoid the threading issue.
> 
> This trades the JAVA_MAIN_CLASS_<pid> pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8274397: Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5724/files
  - new: https://git.openjdk.java.net/jdk/pull/5724/files/96a5590c..4c8fb9af

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=02-03

  Stats: 112 lines in 2 files changed: 112 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5724.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5724/head:pull/5724

PR: https://git.openjdk.java.net/jdk/pull/5724


From prr at openjdk.java.net  Fri Oct  1 21:12:34 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 1 Oct 2021 21:12:34 GMT
Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid>
 in launcher code [v3]
In-Reply-To: <rWjRxqEvSuEXDQJX6DLXGebarexgC9IO3Lq3fUxKeVY=.f3e4e040-a269-4300-a85c-d48bd2cb7f56@github.com>
References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
 <rWjRxqEvSuEXDQJX6DLXGebarexgC9IO3Lq3fUxKeVY=.f3e4e040-a269-4300-a85c-d48bd2cb7f56@github.com>
Message-ID: <xQmNYv9H0CtcjTxHxWi4wireU_HCRWodwUEQ92czKsU=.373791c5-a62d-44d6-95c5-dfee7d8b9d2e@github.com>

On Wed, 29 Sep 2021 03:39:09 GMT, Phil Race <prr at openjdk.org> wrote:

>> macOS launcher code sets JAVA_MAIN_CLASS_<pid> which is read by AWT to set the name of the application in the system menu bar.
>> 
>> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549
>> 
>> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose,
>> we can set that instead of the env. var and avoid the threading issue.
>> 
>> This trades the JAVA_MAIN_CLASS_<pid> pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274397: Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code

I've now pushed the new test to verify the system property.
I've verified the test passes on my local machine but can't (until Monday) be sure it passes in the CI test framework because of power maintenance that has just started.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5724


From github.com+90066231+alisenchung at openjdk.java.net  Fri Oct  1 22:13:38 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Fri, 1 Oct 2021 22:13:38 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v8]
In-Reply-To: <zsJFJUWvjsJU0y0oAZnwYSsP4ohFybmjpc3zLCUbBFk=.b3f71931-d4a7-46b4-95e6-d00a1bd74e51@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <zsJFJUWvjsJU0y0oAZnwYSsP4ohFybmjpc3zLCUbBFk=.b3f71931-d4a7-46b4-95e6-d00a1bd74e51@github.com>
Message-ID: <6YsYfbpMiVutZfIAXIWvmaxLw44S6zgAsF9IEgM7W44=.97032334-d216-4c26-8db1-8c03ae859dae@github.com>

On Wed, 29 Sep 2021 22:29:19 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added check for fullscreen mode to synthesize mouseEntered event

I think synthesizeMouseEnteredExitedEventsForAllWindows shouldn't be in deliverMoveResizeEvent since there shouldn't be any mouseEnter/Exit events during a resize or move and I can submit another bug for didWindowEnterFullscreen and didWindowExitFullscreen not being called/not posting mouseEvents that I can work on separately..

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From github.com+90066231+alisenchung at openjdk.java.net  Fri Oct  1 22:28:10 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Fri, 1 Oct 2021 22:28:10 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v9]
In-Reply-To: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
Message-ID: <BUO3yGBz6ja11UoRUArVDYvB1zgXtEELEV1U7wYCFvA=.42ad2406-3f2a-40d5-ab2c-aa617548264c@github.com>

> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  removed synthesizeMouseEnteredExitEvent call

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5497/files
  - new: https://git.openjdk.java.net/jdk/pull/5497/files/fc14e5bf..b1e26846

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5497&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5497&range=07-08

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5497.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5497/head:pull/5497

PR: https://git.openjdk.java.net/jdk/pull/5497


From serb at openjdk.java.net  Fri Oct  1 22:35:31 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 1 Oct 2021 22:35:31 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v8]
In-Reply-To: <kA_rPdYUfFP7zOgENvAmX_HCddewWideMQA0bcfWMv4=.577664c3-afdf-4fd4-9595-c40b2b02365e@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <zsJFJUWvjsJU0y0oAZnwYSsP4ohFybmjpc3zLCUbBFk=.b3f71931-d4a7-46b4-95e6-d00a1bd74e51@github.com>
 <IkLXCri7K15PKo47WW73qa5x5kz3_TrDxhd7kiqvnAw=.f09030d9-8663-4425-8ba4-a3aaf2571dd6@github.com>
 <JfL653sc74SGOMlG6wj9V_KCktQWM4VCaKcj0CiBPas=.6b2cce94-87c9-4fdf-a97c-eb8f918489b3@github.com>
 <o67PrNbxVvgnrACOlH6bkIVpOD1BUZpXq1_wAEYEsaI=.111c9f06-ead3-4d23-8e56-5a59a29b5eb5@github.com>
 <l-PXwVydJJ87pw1bQWAzAFusROKW_H828sEVSDmuX4o=.15a9feac-0414-4efb-87d1-d00567bf27dd@github.com>
 <QtoADMwVmyVvi3l_GomveemEc0f8DnrVSbSkow6_UGg=.a33b1b68-0bbb-4b31-b633-519c99e4cbd6@github.com>
 <kA_rPdYUfFP7zOgENvAmX_HCddewWideMQA0bcfWMv4=.577664c3-afdf-4fd4-9595-c40b2b02365e@github.com>
Message-ID: <wkJ_rMcUdlfWQ_QUPrfgMOuvYRt-bpVLtwMiMpk_rvs=.5b1d3ac7-6da6-4ec6-b9ab-077a97878b60@github.com>

On Fri, 1 Oct 2021 06:52:43 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> windowDIdEnterFullScreen isn't being called but entering fullscreen mode still posts a mouseEntered event.

I have added a trace to the window WillEnterFullScreen and window DIdEnterFull Screen and see that both are called when the window is moved to the full screen mode via green button.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From serb at openjdk.java.net  Fri Oct  1 22:40:29 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 1 Oct 2021 22:40:29 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v8]
In-Reply-To: <6YsYfbpMiVutZfIAXIWvmaxLw44S6zgAsF9IEgM7W44=.97032334-d216-4c26-8db1-8c03ae859dae@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <zsJFJUWvjsJU0y0oAZnwYSsP4ohFybmjpc3zLCUbBFk=.b3f71931-d4a7-46b4-95e6-d00a1bd74e51@github.com>
 <6YsYfbpMiVutZfIAXIWvmaxLw44S6zgAsF9IEgM7W44=.97032334-d216-4c26-8db1-8c03ae859dae@github.com>
Message-ID: <XHOApVNKaTbVA4cfjYY-5RK7IZB_fhySC-5SOx_YVn4=.125093c7-9cf8-41ea-ae75-549afc7fc6f0@github.com>

On Fri, 1 Oct 2021 22:10:40 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> I think synthesizeMouseEnteredExitedEventsForAllWindows shouldn't be in deliverMoveResizeEvent since there shouldn't be any mouseEnter/Exit events during a resize or move

Why do you think that if the window is moved/resized and/or appeared under the mouse then the mouse event should not be posted? I do not think so. We can try to minimize the number of events when the user drags/resizes the window, but we should not change the number of events if the macos/app moved/resized the window.

> and I can submit another bug for didWindowEnterFullscreen and didWindowExitFullscreen not being called/not posting mouseEvents that I can work on separately..

It should be called, I have checked that on macOS 11.5, but I do not think it depends on the version.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From github.com+741251+turbanoff at openjdk.java.net  Sat Oct  2 03:10:33 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sat, 2 Oct 2021 03:10:33 GMT
Subject: Integrated: 8274505: Too weak variable type leads to unnecessary cast
 in java.desktop
In-Reply-To: <6cJslwsJnRSY_LscZNkLV6zo3yLRh2TYkTUTY6qx-Kw=.a6d0d551-6c0a-40af-af26-1fbd70b9b319@github.com>
References: <6cJslwsJnRSY_LscZNkLV6zo3yLRh2TYkTUTY6qx-Kw=.a6d0d551-6c0a-40af-af26-1fbd70b9b319@github.com>
Message-ID: <LAZ1LzI4eiWACVXuHmuAGYVWdVawfHai9kmea-Xu6-I=.77b6ef2a-3af1-493f-a117-bda94275e92a@github.com>

On Tue, 28 Sep 2021 08:02:12 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Such casts are actually redundant, but they are inserted, because variable is declared with too weak type.

This pull request has now been integrated.

Changeset: 9ca6bf0d
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9ca6bf0d22ac39d4ee29c756903038f09087ca12
Stats:     78 lines in 11 files changed: 0 ins; 22 del; 56 mod

8274505: Too weak variable type leads to unnecessary cast in java.desktop

Reviewed-by: serb, kizune, pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/5731


From psadhukhan at openjdk.java.net  Mon Oct  4 06:52:50 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 4 Oct 2021 06:52:50 GMT
Subject: Integrated: 8268084: [macos] Disabled JMenuItem arrow is not disabled
In-Reply-To: <WxRHHau9pg90x90bi1YkZJP_fOTR4oLoA8UOswtNQH8=.0064bb1c-68d1-4226-ae6f-648fd5afdebd@github.com>
References: <WxRHHau9pg90x90bi1YkZJP_fOTR4oLoA8UOswtNQH8=.0064bb1c-68d1-4226-ae6f-648fd5afdebd@github.com>
Message-ID: <sPwFEP-HO2S1ZVBHnezX1MvnewPzLLX_AF9XPGa0o94=.38065c08-d7b7-4918-a8a3-63eb238cea16@github.com>

On Tue, 31 Aug 2021 06:09:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is seen in macos disabled JMenuItem arrow is not disabled even though JMenuItem itself is disabled.
> In native app, same menuitem arrow is disabled for disabled menuitem.
> 
> Issue is when AquaMenuPainter#paintMenuItem() is called, it tries to draw a ImageIcon image of the arrow via ImageIcon#paintIcon which tries to generate MultiResolutionCachedImage via getResolutionVariant() by calling AquaUtils#generateFilteredImage.
> It does not take into account if disabled arrow icon image needs to be drawn or not, so it is always enabled.
> 
> Proposed fix is to generate a disabled ImageIcon image of the same arrow icon and use it for disabled state.

This pull request has now been integrated.

Changeset: 32811026
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/32811026ce5ecb1d27d835eac33de9ccbd51fcbf
Stats:     194 lines in 2 files changed: 193 ins; 0 del; 1 mod

8268084: [macos] Disabled JMenuItem arrow is not disabled

Reviewed-by: serb, jdv

-------------

PR: https://git.openjdk.java.net/jdk/pull/5310


From mvs at openjdk.java.net  Mon Oct  4 07:35:08 2021
From: mvs at openjdk.java.net (Manukumar V S)
Date: Mon, 4 Oct 2021 07:35:08 GMT
Subject: RFR: 8274597: [TESTBUG] Two of the dnd tests times out and fails
In-Reply-To: <Y5yp9hdvALRyjAEm8N1Mgys7g99xvVLCnQ-AKzs6ZUA=.0b2beada-07f1-4e4d-a572-5d47f7513d42@github.com>
References: <0ISZ7X0xu1zN3SLn-p1XkZm8Brkb-Ozu_nTe3RF8xXg=.f3b3c6ed-3719-4347-8f13-a8b89bc1d836@github.com>
 <bPoUm64FEMN2fC6sJm80cFX0JmHBrObu_IiaJn0M3zA=.61f066b3-426c-4a62-a399-5ba5d0b110ac@github.com>
 <3gMmtwYbcWvX90UNLQoxsEcfuFVVUomDkgt7wTZsTUk=.622fae3d-3e36-42f8-9d22-534c7001656e@github.com>
 <Y5yp9hdvALRyjAEm8N1Mgys7g99xvVLCnQ-AKzs6ZUA=.0b2beada-07f1-4e4d-a572-5d47f7513d42@github.com>
Message-ID: <uFstrlHPyzUZfWZz6jCKT9fqgrIr4HWvL4GdD5U1Ssk=.1ba19e0f-6806-4023-b0e8-505dba64ecf9@github.com>

On Fri, 1 Oct 2021 19:19:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I can see three non-daemon threads in 'WAITING' state(given below). So looks like 'AWT-Shutdown' thread created by AWTAutoShutdown.java is the hook which is getting blocked. But I think this is an expected behaviour only as it will block this thread until all AWT tasks are complete.
> 
> This issue is unrelated to the non-daemon threads since the System.exit() is called, it should exit the whole JVM. But before exit it executes some number of registered ShutdownHook, we need to check what ShutdownHook is executed and why it hangs. The AWT-Shutdown is not a hook, it is a thread which prevents vm exit if there are some UI peers, but it does ont prevent the System.exit().

@mrserb I can see only two shutdown hooks registered, Thread[ToolkitShutdown,6,system] and Thread[ScreenUpdater,6,system]. But I don't know which one of this is getting hanged, any idea how can I check it?. Also if we put a Thread.sleep(100) or just a System.out.println() at the end of the main(), its not hanging and the tests are passing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5777


From github.com+741251+turbanoff at openjdk.java.net  Mon Oct  4 07:55:23 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 4 Oct 2021 07:55:23 GMT
Subject: RFR: 8274680: Remove unnecessary conversion to String in java.desktop
Message-ID: <Kj-zZoiJu9UXLIOPpccjfSQVV915gfqL-acr1oQL5Bk=.1eed378e-51c3-48b8-b230-304767e6f7d5@github.com>

Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway

-------------

Commit messages:
 - [PATCH] Remove unnecessary conversion to String in java.desktop

Changes: https://git.openjdk.java.net/jdk/pull/5799/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5799&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274680
  Stats: 67 lines in 16 files changed: 0 ins; 18 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5799.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5799/head:pull/5799

PR: https://git.openjdk.java.net/jdk/pull/5799


From pbansal at openjdk.java.net  Mon Oct  4 08:16:07 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 4 Oct 2021 08:16:07 GMT
Subject: RFR: 8274680: Remove unnecessary conversion to String in
 java.desktop
In-Reply-To: <Kj-zZoiJu9UXLIOPpccjfSQVV915gfqL-acr1oQL5Bk=.1eed378e-51c3-48b8-b230-304767e6f7d5@github.com>
References: <Kj-zZoiJu9UXLIOPpccjfSQVV915gfqL-acr1oQL5Bk=.1eed378e-51c3-48b8-b230-304767e6f7d5@github.com>
Message-ID: <amyXzR9ielb2GcgITcw_wQ3yeaWGPzM2a8cmG5tLk38=.3694fba4-9eb6-4a9a-b0cc-64dfc4617557@github.com>

On Sun, 3 Oct 2021 16:55:36 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway

src/java.desktop/share/classes/javax/swing/text/html/OptionListModel.java line 459:

> 457:     public String toString() {
> 458:         String s =  ((getValueIsAdjusting()) ? "~" : "=") + value.toString();
> 459:         return getClass().getName() + " " + hashCode() + " " + s;

Please change copyright year for this file

-------------

PR: https://git.openjdk.java.net/jdk/pull/5799


From github.com+741251+turbanoff at openjdk.java.net  Mon Oct  4 09:05:30 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 4 Oct 2021 09:05:30 GMT
Subject: RFR: 8274680: Remove unnecessary conversion to String in
 java.desktop [v2]
In-Reply-To: <Kj-zZoiJu9UXLIOPpccjfSQVV915gfqL-acr1oQL5Bk=.1eed378e-51c3-48b8-b230-304767e6f7d5@github.com>
References: <Kj-zZoiJu9UXLIOPpccjfSQVV915gfqL-acr1oQL5Bk=.1eed378e-51c3-48b8-b230-304767e6f7d5@github.com>
Message-ID: <4gUX3W4bIm5Nzy6ebY7YIYbds6kKUUhC5CBL_6-scOo=.0058c449-2949-449c-b444-57da79ce455c@github.com>

> Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8274680: Remove unnecessary conversion to String in java.desktop
  update copyright year

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5799/files
  - new: https://git.openjdk.java.net/jdk/pull/5799/files/86022f44..d0cc5f8b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5799&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5799&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5799.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5799/head:pull/5799

PR: https://git.openjdk.java.net/jdk/pull/5799


From pbansal at openjdk.java.net  Mon Oct  4 10:28:10 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 4 Oct 2021 10:28:10 GMT
Subject: RFR: 8274680: Remove unnecessary conversion to String in
 java.desktop [v2]
In-Reply-To: <4gUX3W4bIm5Nzy6ebY7YIYbds6kKUUhC5CBL_6-scOo=.0058c449-2949-449c-b444-57da79ce455c@github.com>
References: <Kj-zZoiJu9UXLIOPpccjfSQVV915gfqL-acr1oQL5Bk=.1eed378e-51c3-48b8-b230-304767e6f7d5@github.com>
 <4gUX3W4bIm5Nzy6ebY7YIYbds6kKUUhC5CBL_6-scOo=.0058c449-2949-449c-b444-57da79ce455c@github.com>
Message-ID: <5eqUgVyv55NFvozagr9PYipsdOVVM7HpXvHs2LItrMo=.8c925783-431d-4979-b124-9b1691d31b5f@github.com>

On Mon, 4 Oct 2021 09:05:30 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274680: Remove unnecessary conversion to String in java.desktop
>   update copyright year

Looks good to me. Please wait for one more review before integrating.

-------------

Marked as reviewed by pbansal (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5799


From github.com+741251+turbanoff at openjdk.java.net  Mon Oct  4 10:31:09 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 4 Oct 2021 10:31:09 GMT
Subject: Integrated: 8274634: Use String.equals instead of String.compareTo in
 java.desktop
In-Reply-To: <wLvu4WcvTpZEPB68R9hdYIN3zxiGXTtRGHAeiNsgre8=.8b482331-cf8d-4ab9-8f4f-af0ab0dfc7a0@github.com>
References: <wLvu4WcvTpZEPB68R9hdYIN3zxiGXTtRGHAeiNsgre8=.8b482331-cf8d-4ab9-8f4f-af0ab0dfc7a0@github.com>
Message-ID: <HdhhRVh1CNFBNgOSN36YB6nDh694BYDyOxbCAuUCbNo=.9bc875f9-917f-451a-952c-947d4d44ee67@github.com>

On Wed, 29 Sep 2021 13:27:32 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> In several places, String.compareTo was _compared_ with 0 ( via `== 0`).
> Instead of this, we can use String.equals calls. `String.equals` is faster and shorter.

This pull request has now been integrated.

Changeset: 6726c592
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Pankaj Bansal <pbansal at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6726c592ed01b112f5eb85d8f1e4406b25c8df2b
Stats:     15 lines in 3 files changed: 0 ins; 0 del; 15 mod

8274634: Use String.equals instead of String.compareTo in java.desktop

Reviewed-by: serb, pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/5751


From github.com+87324768+lawrence-andrew at openjdk.java.net  Mon Oct  4 14:46:35 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Mon, 4 Oct 2021 14:46:35 GMT
Subject: RFR: 8274032 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java & show test UI [v3]
In-Reply-To: <3PeA1uV6v8hufkV83MCl4ADDpKRSqoM39m8vkkuOdak=.d30c9535-1d20-49d9-8df1-d48bae3fd483@github.com>
References: <3PeA1uV6v8hufkV83MCl4ADDpKRSqoM39m8vkkuOdak=.d30c9535-1d20-49d9-8df1-d48bae3fd483@github.com>
Message-ID: <p-15TqYx5r21b7Dgy-VY3aZBaG9FXBWmFYKq5mPwxn0=.1960d3ea-2844-4cc5-8d9a-e27f9a02d4ca@github.com>

> Problem : 
> 1) Testcase was failing due to parse exception yesno
> 2) After removing yesno tag test frame and immediately get disposed
> 
> Fix : 
> 1) Removed yesno tag
> 2) Show the test frame with pass, fail button.  Now user can click on the `print' button to show the print dialog and take the print out and compare the print with the graphics rendered on the frame. Click either on the 'Pass' or 'Fail' button to make the pass or fail also clicking the 'Pass' or 'Fail' closes the test frame.
> 3) Added the timeout If not interaction is performed on the test frame.
> 
> @shurymury

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  print message if printer is not install

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5595/files
  - new: https://git.openjdk.java.net/jdk/pull/5595/files/98a9e315..105fc91f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5595&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5595&range=01-02

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5595.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5595/head:pull/5595

PR: https://git.openjdk.java.net/jdk/pull/5595


From azvegint at openjdk.java.net  Mon Oct  4 15:09:16 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 4 Oct 2021 15:09:16 GMT
Subject: RFR: 8269698: Specification for methods of java.awt.im.InputContext
 should mention that they do nothing
Message-ID: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>

This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.

-------------

Commit messages:
 - rewording
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/5806/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5806&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269698
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5806.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5806/head:pull/5806

PR: https://git.openjdk.java.net/jdk/pull/5806


From github.com+90066231+alisenchung at openjdk.java.net  Mon Oct  4 15:40:11 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Mon, 4 Oct 2021 15:40:11 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v9]
In-Reply-To: <BUO3yGBz6ja11UoRUArVDYvB1zgXtEELEV1U7wYCFvA=.42ad2406-3f2a-40d5-ab2c-aa617548264c@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <BUO3yGBz6ja11UoRUArVDYvB1zgXtEELEV1U7wYCFvA=.42ad2406-3f2a-40d5-ab2c-aa617548264c@github.com>
Message-ID: <xZ6uTUr0dMlEQijN2yTaTMvg29IzIt4cbbef5hjN33c=.d065001b-9f97-4447-9dde-006b1c2ad635@github.com>

On Fri, 1 Oct 2021 22:28:10 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed synthesizeMouseEnteredExitEvent call

I added a keyListener to SpuriousExitEnter test to enter and exit fullscreen with GraphicsDevice on a specific keypress and I wasn't able to get NSLog to show up in AWTWindow. What test were you able to see the trace and did it also post a mouseEntered/mouseExit event properly?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From alexander.zvegintsev at oracle.com  Mon Oct  4 17:06:39 2021
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 4 Oct 2021 19:06:39 +0200
Subject: CFV: New Client Libraries Group Member : Prasanta Sadhukhan
 (psadhukhan)
In-Reply-To: <37846e8d-9c3d-5050-bcf4-c8d096b19287@oracle.com>
References: <37846e8d-9c3d-5050-bcf4-c8d096b19287@oracle.com>
Message-ID: <8cc50c39-856a-47f8-92d5-e7e3b4702f9b@oracle.com>

Vote: yes

--
Thanks,
Alexander.

On 01/10/2021 01:03, Philip Race wrote:
> I hereby nominate Prasanta Sadhukhan (psadhukhan) to Membership in the 
> Client Libraries Group.
>
> Prasanta has worked in the client team at Oracle since 2015 and in 
> that time has contributed approximately 460 fixes [1], [2].
> He has been active on the old client lists, awt-dev [3], swing-dev[4] 
> and 2d-dev [5] mailing list over that time,
> He is also a JDK committer and reviewer [6].
>
> Votes are due by 5pm PDT Thursday 14th October 2021
>
> //Only current Members of the Client Libraries Group [7] are eligible 
> to vote on this nomination. ||
> Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [8].
>
> -Phil.
>
> [1] git log --author psadhukhan --format='%h %s'
> [2] 
> https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Prasanta+Sadhukhan%22&type=commits
> [3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev
> [4] https://mail.openjdk.java.net/mailman/listinfo/swing-dev
> [5] https://mail.openjdk.java.net/mailman/listinfo/2d-dev
> [6] https://openjdk.java.net/census#psadhukhan
> [7] https://openjdk.java.net/census#client-libs
> [8] http://openjdk.java.net/groups/#member-vote 
> <http://openjdk.java.net/groups/#member-vote%7C>


From alexander.zvegintsev at oracle.com  Mon Oct  4 17:06:56 2021
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 4 Oct 2021 19:06:56 +0200
Subject: CFV: New Client Libraries Group Member : Pankaj Bansal (pbansal)
In-Reply-To: <9bc8698b-35cc-1faa-4dac-e4c97f43254c@oracle.com>
References: <9bc8698b-35cc-1faa-4dac-e4c97f43254c@oracle.com>
Message-ID: <34950eb9-249b-cde5-1d28-c10f40d62535@oracle.com>

Vote: yes

--
Thanks,
Alexander.

On 01/10/2021 01:03, Philip Race wrote:
> I hereby nominate Pankaj Bansal (pbansal) to Membership in the Client 
> Libraries Group.
>
> Pankaj has worked in the client team at Oracle since 2017 and in that 
> time has contributed approximately 70-80 fixes [1], [2].
> He has been active on the old client lists, awt-dev [3], swing-dev[4] 
> and 2d-dev [5] mailing list over that time,
> He is also a JDK committer and reviewer [6].
>
> Votes are due by 5pm PDT Thursday 14th October 2021
>
> //Only current Members of the Client Libraries Group [7] are eligible 
> to vote on this nomination. ||
> Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [8].
>
> [1] git log --author pbansal --format='%h %s'
> [2] 
> https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Pankaj+Bansal%22&type=commits
> [3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev
> [4] https://mail.openjdk.java.net/mailman/listinfo/swing-dev
> [5] https://mail.openjdk.java.net/mailman/listinfo/2d-dev
> [6] https://openjdk.java.net/census#pbansal
> [7] https://openjdk.java.net/census#client-libs
> [8] http://openjdk.java.net/groups/#member-vote 
> <http://openjdk.java.net/groups/#member-vote%7C>


From serb at openjdk.java.net  Mon Oct  4 17:28:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 4 Oct 2021 17:28:09 GMT
Subject: RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing
In-Reply-To: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
Message-ID: <5o3brNWAUIPHurnnBS3bcuus_9fQwTLc5g3nUTkSA5Y=.ced390ad-d751-4bb7-ad60-d1927e9cb062@github.com>

On Mon, 4 Oct 2021 14:54:27 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.

If the problem is in the validation of the parameters maybe we can enforce it?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5806


From azvegint at openjdk.java.net  Mon Oct  4 18:11:06 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 4 Oct 2021 18:11:06 GMT
Subject: RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing
In-Reply-To: <5o3brNWAUIPHurnnBS3bcuus_9fQwTLc5g3nUTkSA5Y=.ced390ad-d751-4bb7-ad60-d1927e9cb062@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
 <5o3brNWAUIPHurnnBS3bcuus_9fQwTLc5g3nUTkSA5Y=.ced390ad-d751-4bb7-ad60-d1927e9cb062@github.com>
Message-ID: <aTwn8PCU8sRsLsSZUza5C5CAMrxjj6HlynFLL9gE5bY=.1cabd115-2969-48d1-9d7b-30c5332de197@github.com>

On Mon, 4 Oct 2021 17:25:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> If the problem is in the validation of the parameters maybe we can enforce it?

It is one of possible solutions. 
Also we have a following javadoc:



    /**
     * Constructs an InputContext.
     * This method is protected so clients cannot instantiate
     * InputContext directly. Input contexts are obtained by
     * calling {@link #getInstance}.
     */
    protected InputContext() {

So those validation of the parameters enforcements will be an almost dead code, only used by synthetic specification test.

Another solution is to make this class abstract.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5806


From serb at openjdk.java.net  Mon Oct  4 18:20:18 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 4 Oct 2021 18:20:18 GMT
Subject: RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing
In-Reply-To: <aTwn8PCU8sRsLsSZUza5C5CAMrxjj6HlynFLL9gE5bY=.1cabd115-2969-48d1-9d7b-30c5332de197@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
 <5o3brNWAUIPHurnnBS3bcuus_9fQwTLc5g3nUTkSA5Y=.ced390ad-d751-4bb7-ad60-d1927e9cb062@github.com>
 <aTwn8PCU8sRsLsSZUza5C5CAMrxjj6HlynFLL9gE5bY=.1cabd115-2969-48d1-9d7b-30c5332de197@github.com>
Message-ID: <7-5hGeRQVGJzHNP7XzuVvrG2Gf03CEUjAmIqJBgtEGc=.5531a550-e96c-4baf-a76b-367b813ef4a6@github.com>

On Mon, 4 Oct 2021 18:07:48 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Another solution is to make this class abstract.

It won't help, since they will subclass this class and call the parent methods, which they do a few times already for some other cases.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5806


From serb at openjdk.java.net  Mon Oct  4 18:26:16 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 4 Oct 2021 18:26:16 GMT
Subject: RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing
In-Reply-To: <aTwn8PCU8sRsLsSZUza5C5CAMrxjj6HlynFLL9gE5bY=.1cabd115-2969-48d1-9d7b-30c5332de197@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
 <5o3brNWAUIPHurnnBS3bcuus_9fQwTLc5g3nUTkSA5Y=.ced390ad-d751-4bb7-ad60-d1927e9cb062@github.com>
 <aTwn8PCU8sRsLsSZUza5C5CAMrxjj6HlynFLL9gE5bY=.1cabd115-2969-48d1-9d7b-30c5332de197@github.com>
Message-ID: <u1OodZcXP4jOXJ-abZj1BYNGj2JlU1ZWsuVRde8KZ5A=.fcde7820-802e-44f4-a04c-d15b2014a794@github.com>

On Mon, 4 Oct 2021 18:07:48 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> So those validation of the parameters enforcements will be an almost dead code, only used by synthetic specification test.

But is it worth it to update the spec in stone that these methods will return null/false/no-exceptions forever just because of one synthetic specification test?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5806


From serb at openjdk.java.net  Mon Oct  4 18:28:12 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 4 Oct 2021 18:28:12 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v9]
In-Reply-To: <xZ6uTUr0dMlEQijN2yTaTMvg29IzIt4cbbef5hjN33c=.d065001b-9f97-4447-9dde-006b1c2ad635@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <BUO3yGBz6ja11UoRUArVDYvB1zgXtEELEV1U7wYCFvA=.42ad2406-3f2a-40d5-ab2c-aa617548264c@github.com>
 <xZ6uTUr0dMlEQijN2yTaTMvg29IzIt4cbbef5hjN33c=.d065001b-9f97-4447-9dde-006b1c2ad635@github.com>
Message-ID: <P1gPCh3HbgzLCSFe1UnSyILTPVLhzsjsgQ3VSt_M4pI=.e1741a62-0e40-4611-a2e1-6d024aad2d0e@github.com>

On Mon, 4 Oct 2021 15:37:31 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> What test were you able to see the trace and did it also post a mouseEntered/mouseExit event properly?

I just added the fprintf(stderr, "windowDidEnterExitFullScreen\n");
to the AWTWindow.m#windowDidEnterFullScreen/windowDidExitFullScreen
and see that the logging is printed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From naoto at openjdk.java.net  Mon Oct  4 20:19:08 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 4 Oct 2021 20:19:08 GMT
Subject: RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing
In-Reply-To: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
Message-ID: <wnkZxd_5tta66XeulIK3uF1boXhDKTh_uCkopyct0ug=.f4e6bbcc-6a46-4ffe-a78f-0ce319c91608@github.com>

On Mon, 4 Oct 2021 14:54:27 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.

I'd agree we add clarification to the spec, instead of adding parameter checks. Java input methods became less useful after JDK9, where it restricted system-wide Java IM installation (The extension mechanism was removed).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5806


From serb at openjdk.java.net  Mon Oct  4 20:54:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 4 Oct 2021 20:54:05 GMT
Subject: RFR: 8274597: [TESTBUG] Two of the dnd tests times out and fails
In-Reply-To: <Y5yp9hdvALRyjAEm8N1Mgys7g99xvVLCnQ-AKzs6ZUA=.0b2beada-07f1-4e4d-a572-5d47f7513d42@github.com>
References: <0ISZ7X0xu1zN3SLn-p1XkZm8Brkb-Ozu_nTe3RF8xXg=.f3b3c6ed-3719-4347-8f13-a8b89bc1d836@github.com>
 <bPoUm64FEMN2fC6sJm80cFX0JmHBrObu_IiaJn0M3zA=.61f066b3-426c-4a62-a399-5ba5d0b110ac@github.com>
 <3gMmtwYbcWvX90UNLQoxsEcfuFVVUomDkgt7wTZsTUk=.622fae3d-3e36-42f8-9d22-534c7001656e@github.com>
 <Y5yp9hdvALRyjAEm8N1Mgys7g99xvVLCnQ-AKzs6ZUA=.0b2beada-07f1-4e4d-a572-5d47f7513d42@github.com>
Message-ID: <fk0tAkQOdUkr29JqfMFLRBg7YR8EqDLbFsz0O6I74r0=.1d57c49b-3b86-4a42-bf03-bc11cb885289@github.com>

On Fri, 1 Oct 2021 19:19:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @mrserb I can see three non-daemon threads in 'WAITING' state(given below). So looks like 'AWT-Shutdown' thread created by AWTAutoShutdown.java is the hook which is getting blocked. But I think this is an expected behaviour only as it will block this thread until all AWT tasks are complete. 
>> 
>> 
>> "main" #1 prio=5 os_prio=0 cpu=78.13ms elapsed=240.13s tid=0x0000017129532000 nid=0x1518 in Object.wait()  [0x0000001fb8ffe000]
>>    java.lang.Thread.State: WAITING (on object monitor)
>> 	at java.lang.Object.wait(java.base at 11.0.14-ea/Native Method)
>> 	- waiting on <0x00000000ff504d78> (a java.lang.Thread)
>> 	at java.lang.Thread.join(java.base at 11.0.14-ea/Thread.java:1305)
>> 	- waiting to re-lock in wait() <0x00000000ff504d78> (a java.lang.Thread)
>> 	at java.lang.Thread.join(java.base at 11.0.14-ea/Thread.java:1379)
>> 	at java.lang.ApplicationShutdownHooks.runHooks(java.base at 11.0.14-ea/ApplicationShutdownHooks.java:107)
>> 	at java.lang.ApplicationShutdownHooks$1.run(java.base at 11.0.14-ea/ApplicationShutdownHooks.java:46)
>> 	at java.lang.Shutdown.runHooks(java.base at 11.0.14-ea/Shutdown.java:130)
>> 	at java.lang.Shutdown.exit(java.base at 11.0.14-ea/Shutdown.java:174)
>> 	- locked <0x00000000ff50a4e0> (a java.lang.Class for java.lang.Shutdown)
>> 	at java.lang.Runtime.exit(java.base at 11.0.14-ea/Runtime.java:113)
>> 	at java.lang.System.exit(java.base at 11.0.14-ea/System.java:1750)
>> 	at com.sun.javatest.regtest.agent.AStatus.exit(AStatus.java:199)
>> 	at com.sun.javatest.regtest.agent.MainWrapper.main(MainWrapper.java:84)
>> 
>> 
>> "AWT-Shutdown" #24 prio=5 os_prio=0 cpu=0.00ms elapsed=239.97s tid=0x000001714cd43800 nid=0x29c4 in Object.wait()  [0x0000001fba6fe000]
>>    java.lang.Thread.State: WAITING (on object monitor)
>> 	at java.lang.Object.wait(java.base at 11.0.14-ea/Native Method)
>> 	- waiting on <0x00000000ff69b6c0> (a java.lang.Object)
>> 	at java.lang.Object.wait(java.base at 11.0.14-ea/Object.java:328)
>> 	at sun.awt.AWTAutoShutdown.run(java.desktop at 11.0.14-ea/AWTAutoShutdown.java:291)
>> 	- waiting to re-lock in wait() <0x00000000ff69b6c0> (a java.lang.Object)
>> 	at java.lang.Thread.run(java.base at 11.0.14-ea/Thread.java:834)
>> 
>> 
>> 
>> "AWT-EventQueue-0" #27 prio=6 os_prio=0 cpu=109.38ms elapsed=239.96s tid=0x000001714d006800 nid=0x1f70 waiting on condition  [0x0000001fba8fe000]
>>    java.lang.Thread.State: WAITING (parking)
>> 	at jdk.internal.misc.Unsafe.park(java.base at 11.0.14-ea/Native Method)
>> 	- parking to wait for  <0x00000000ff6eda50> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>> 	at java.util.concurrent.locks.LockSupport.park(java.base at 11.0.14-ea/LockSupport.java:194)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 11.0.14-ea/AbstractQueuedSynchronizer.java:2081)
>> 	at java.awt.EventQueue.getNextEvent(java.desktop at 11.0.14-ea/EventQueue.java:566)
>> 	at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 11.0.14-ea/EventDispatchThread.java:190)
>> 	at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 11.0.14-ea/EventDispatchThread.java:124)
>> 	at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 11.0.14-ea/EventDispatchThread.java:113)
>> 	at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11.0.14-ea/EventDispatchThread.java:109)
>> 	at java.awt.EventDispatchThread.pumpEvents(java.desktop at 11.0.14-ea/EventDispatchThread.java:101)
>> 	at java.awt.EventDispatchThread.run(java.desktop at 11.0.14-ea/EventDispatchThread.java:90)
>
>>  I can see three non-daemon threads in 'WAITING' state(given below). So looks like 'AWT-Shutdown' thread created by AWTAutoShutdown.java is the hook which is getting blocked. But I think this is an expected behaviour only as it will block this thread until all AWT tasks are complete.
> 
> This issue is unrelated to the non-daemon threads since the System.exit() is called, it should exit the whole JVM. But before exit it executes some number of registered ShutdownHook, we need to check what ShutdownHook is executed and why it hangs. The AWT-Shutdown is not a hook, it is a thread which prevents vm exit if there are some UI peers, but it does ont prevent the System.exit().

> @mrserb I can see only two shutdown hooks registered, Thread[ToolkitShutdown,6,system] and Thread[ScreenUpdater,6,system]. But I don't know which one of this is getting hanged, any idea how can I check it?

You can add logging to each of them and check, or you can debug the native code.

>Also if we put a Thread.sleep(100) or just a System.out.println() at the end of the main(), its not hanging and the tests are passing.

maybe the test found a deadlock in the product and you just workaround it?

>So for the time being in order to stabilise the test run on mach5 systems and also considering the fact that this issue is currently reproducible only with Windows 11 systems, can I go ahead and fix the tests?.

The algorithm to use in such cases is something like this:
 - If the bug is in the test, then fix the test
 - If the bug is in the product then fix the product
 - If the root cause is unknown then add test to the problem list
 - Continue to work on the bug
 - Find the root cause
 - Fix the test/product and remove the test from the problem list

-------------

PR: https://git.openjdk.java.net/jdk/pull/5777


From serb at openjdk.java.net  Mon Oct  4 21:40:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 4 Oct 2021 21:40:09 GMT
Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid>
 in launcher code [v4]
In-Reply-To: <6g0EhtvtHXXr80qFDYESUQ-PhKf97oikta-MnPf2QSY=.4e52ca70-f604-4bbd-b340-9229d6edb118@github.com>
References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
 <6g0EhtvtHXXr80qFDYESUQ-PhKf97oikta-MnPf2QSY=.4e52ca70-f604-4bbd-b340-9229d6edb118@github.com>
Message-ID: <TyR5X133NCof5zg3No32sZ19vvDZ2AomnITKL4xNz50=.47df6807-5d2f-47ac-8301-02398606f239@github.com>

On Fri, 1 Oct 2021 21:10:27 GMT, Phil Race <prr at openjdk.org> wrote:

>> macOS launcher code sets JAVA_MAIN_CLASS_<pid> which is read by AWT to set the name of the application in the system menu bar.
>> 
>> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549
>> 
>> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose,
>> we can set that instead of the env. var and avoid the threading issue.
>> 
>> This trades the JAVA_MAIN_CLASS_<pid> pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274397: Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5724


From duke at openjdk.java.net  Mon Oct  4 23:14:13 2021
From: duke at openjdk.java.net (duke)
Date: Mon, 4 Oct 2021 23:14:13 GMT
Subject: Withdrawn: 8270331: [TESTBUG] Error: Not a test or directory
 containing tests: java/awt/print/PrinterJob/InitToBlack.java
In-Reply-To: <6nU9tbBxyjpAPR8G72jAMJiRHOhM8yhqrtxKBKhfnc4=.fc28c161-ff74-4b39-b1c7-ec23591413ce@github.com>
References: <6nU9tbBxyjpAPR8G72jAMJiRHOhM8yhqrtxKBKhfnc4=.fc28c161-ff74-4b39-b1c7-ec23591413ce@github.com>
Message-ID: <NDey1_Kz-wtPizRGFB2pC1ImUzkscYQl8amSavlS5yU=.e679520e-6ff6-49a0-b351-a0e242a6120c@github.com>

On Fri, 6 Aug 2021 17:35:22 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

> 1) Removed Testcase depending on InitToBlack.html file which makes the testcase to executed independently.
> 2) Removed Applet class dependent.
> 3) Moved applet/manual=yesno to  main/manual InitToBlack
> 
> @shurymury

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5035


From prr at openjdk.java.net  Tue Oct  5 00:25:41 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 5 Oct 2021 00:25:41 GMT
Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid>
 in launcher code [v5]
In-Reply-To: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
Message-ID: <awcfCiRCgWX_v4j5zhPeM0y_Yqgqbozyix99rXqVG54=.051178c2-9751-490e-b037-2b6560fb473f@github.com>

> macOS launcher code sets JAVA_MAIN_CLASS_<pid> which is read by AWT to set the name of the application in the system menu bar.
> 
> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549
> 
> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose,
> we can set that instead of the env. var and avoid the threading issue.
> 
> This trades the JAVA_MAIN_CLASS_<pid> pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8274397: Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5724/files
  - new: https://git.openjdk.java.net/jdk/pull/5724/files/4c8fb9af..ffd77dd9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5724&range=03-04

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5724.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5724/head:pull/5724

PR: https://git.openjdk.java.net/jdk/pull/5724


From prr at openjdk.java.net  Tue Oct  5 00:25:44 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 5 Oct 2021 00:25:44 GMT
Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid>
 in launcher code [v4]
In-Reply-To: <6g0EhtvtHXXr80qFDYESUQ-PhKf97oikta-MnPf2QSY=.4e52ca70-f604-4bbd-b340-9229d6edb118@github.com>
References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
 <6g0EhtvtHXXr80qFDYESUQ-PhKf97oikta-MnPf2QSY=.4e52ca70-f604-4bbd-b340-9229d6edb118@github.com>
Message-ID: <j0LLeyerqBMiMpXOjiQyW-p7bUIMOk5xmgDxgD7fuUs=.f8e511ab-938b-45a5-853b-4113b07d58db@github.com>

On Fri, 1 Oct 2021 21:10:27 GMT, Phil Race <prr at openjdk.org> wrote:

>> macOS launcher code sets JAVA_MAIN_CLASS_<pid> which is read by AWT to set the name of the application in the system menu bar.
>> 
>> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549
>> 
>> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose,
>> we can set that instead of the env. var and avoid the threading issue.
>> 
>> This trades the JAVA_MAIN_CLASS_<pid> pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274397: Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code

I just pushed a small update to the new test.
The compiled class file of the child process was not found when I ran it in our test framework even though jtreg run locally found it. I just had to explicitly add the location of the compiled classes to the classpath. 
So it is just about getting the test to run in that env. rather than any problem with the fix, or the test logic.
This update HAS passed in that framework - as well as locally

-------------

PR: https://git.openjdk.java.net/jdk/pull/5724


From github.com+741251+turbanoff at openjdk.java.net  Tue Oct  5 00:58:09 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 5 Oct 2021 00:58:09 GMT
Subject: Integrated: 8274651: Possible race in
 FontDesignMetrics.KeyReference.dispose
In-Reply-To: <IPUit2hWm84B_HDXEzOnWiH-7zKTIsULEPaURsJyqSw=.bf1c6c4a-1b9e-4a71-82b1-326d8802a805@github.com>
References: <IPUit2hWm84B_HDXEzOnWiH-7zKTIsULEPaURsJyqSw=.bf1c6c4a-1b9e-4a71-82b1-326d8802a805@github.com>
Message-ID: <t0gTs9S0PN44DTRpuKFH2fKILsuxIG4J1GsZHimLpEM=.00d19e40-7a72-4856-b744-f53ae89a8fea@github.com>

On Wed, 29 Sep 2021 14:01:17 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Possible race condition could happen if another thread put value into 'metricsCache' by the same key.
> We can use `ConcurrentHashMap.remove(key, value)` method to avoid it.

This pull request has now been integrated.

Changeset: e43f540c
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e43f540cde58ee973b97a943f14d3c60e064b801
Stats:     9 lines in 1 file changed: 0 ins; 6 del; 3 mod

8274651: Possible race in FontDesignMetrics.KeyReference.dispose

Reviewed-by: prr, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/5753


From github.com+741251+turbanoff at openjdk.java.net  Tue Oct  5 06:44:10 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 5 Oct 2021 06:44:10 GMT
Subject: Integrated: 8274635: Use String.equals instead of String.compareTo in
 jdk.accessibility
In-Reply-To: <DRuPYmFwgjz23wD4kqXnCnC4zgmTu2hdnDTLD9OV-SU=.cd893593-3493-4d0d-8835-b73486bd7f8c@github.com>
References: <DRuPYmFwgjz23wD4kqXnCnC4zgmTu2hdnDTLD9OV-SU=.cd893593-3493-4d0d-8835-b73486bd7f8c@github.com>
Message-ID: <mu2iWw0stTNnqzMz5CPMH-3YpfGxixn-Q4koLvqA4o0=.98c0a839-b355-4e0b-a57d-a4ddff8b9cad@github.com>

On Wed, 29 Sep 2021 13:34:40 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> In several places, String.compareTo was _compared_ with 0 ( via `== 0`).
> Instead of this, we can use String.equals calls. `String.equals` is faster and shorter.

This pull request has now been integrated.

Changeset: 53d7e95b
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/53d7e95bc637c8b629efc4587b2ae7961d719b00
Stats:     14 lines in 2 files changed: 0 ins; 2 del; 12 mod

8274635: Use String.equals instead of String.compareTo in jdk.accessibility

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/5752


From serb at openjdk.java.net  Tue Oct  5 07:11:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 5 Oct 2021 07:11:10 GMT
Subject: RFR: 8274456 : Remove jtreg tag manual=yesno
 java/awt/print/PrinterJob/PageDialogTest.java
In-Reply-To: <gMmkvVXiwZJd7lPeSzgz2N2IpQBxJJaF8gWKrWY1Brk=.df46feb9-3043-4074-81b8-964c3686cba7@github.com>
References: <gMmkvVXiwZJd7lPeSzgz2N2IpQBxJJaF8gWKrWY1Brk=.df46feb9-3043-4074-81b8-964c3686cba7@github.com>
Message-ID: <vv_OzdxMEz4gFcno6RY1Jgt8uuISuvOjxAFvhuTusmM=.2382092a-fcf4-46d5-a985-b4ac668b59c2@github.com>

On Fri, 1 Oct 2021 18:27:21 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

> 1) Removed =yesno
> 2) After running the test case, test  UI will close immediately. Where the user cannot interact so rewrote the test case.
> a) Toolkit Modal Dialog will be shown after clicking the show button.
> b) Added timeout & tested
> c) Step by step instruction what the user has to perform
> 
> @shurymury

A few comments:
 - Looks like you invert the assertion in the test: 
       old: "The test fails if the page dialog blocks the toolkit"
       new:  "Check if page dialog blocks the 'Toolkit modal dialog'. If yes, then test Pass else test fail."
 - Please update the copyright date

-------------

PR: https://git.openjdk.java.net/jdk/pull/5789


From serb at openjdk.java.net  Tue Oct  5 07:31:11 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 5 Oct 2021 07:31:11 GMT
Subject: RFR: 8274680: Remove unnecessary conversion to String in
 java.desktop [v2]
In-Reply-To: <4gUX3W4bIm5Nzy6ebY7YIYbds6kKUUhC5CBL_6-scOo=.0058c449-2949-449c-b444-57da79ce455c@github.com>
References: <Kj-zZoiJu9UXLIOPpccjfSQVV915gfqL-acr1oQL5Bk=.1eed378e-51c3-48b8-b230-304767e6f7d5@github.com>
 <4gUX3W4bIm5Nzy6ebY7YIYbds6kKUUhC5CBL_6-scOo=.0058c449-2949-449c-b444-57da79ce455c@github.com>
Message-ID: <AFs3B6uwHy-VN2FFAbLcmABDIDznxMZC9eemPtEU9jA=.e331e200-ac9b-4cb0-8150-f279c58f85e0@github.com>

On Mon, 4 Oct 2021 09:05:30 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274680: Remove unnecessary conversion to String in java.desktop
>   update copyright year

src/java.desktop/share/classes/sun/java2d/marlin/RendererContext.java line 52:

> 50:     static RendererContext createContext() {
> 51:         return new RendererContext("ctx"
> 52:                        + CTX_COUNT.getAndIncrement());

can be moved one line up

-------------

PR: https://git.openjdk.java.net/jdk/pull/5799


From serb at openjdk.java.net  Tue Oct  5 07:49:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 5 Oct 2021 07:49:08 GMT
Subject: RFR: 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid>
 in launcher code [v5]
In-Reply-To: <awcfCiRCgWX_v4j5zhPeM0y_Yqgqbozyix99rXqVG54=.051178c2-9751-490e-b037-2b6560fb473f@github.com>
References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
 <awcfCiRCgWX_v4j5zhPeM0y_Yqgqbozyix99rXqVG54=.051178c2-9751-490e-b037-2b6560fb473f@github.com>
Message-ID: <M8Kz7etDj3MVdwdNdU5IPJJ7xkdvykDJrmaUytnIVSk=.90d59dbb-88b3-4e61-b016-85ec4003afb6@github.com>

On Tue, 5 Oct 2021 00:25:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> macOS launcher code sets JAVA_MAIN_CLASS_<pid> which is read by AWT to set the name of the application in the system menu bar.
>> 
>> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549
>> 
>> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose,
>> we can set that instead of the env. var and avoid the threading issue.
>> 
>> This trades the JAVA_MAIN_CLASS_<pid> pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274397: Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code

Looks fine

-------------

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5724


From pbansal at openjdk.java.net  Tue Oct  5 08:29:16 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 5 Oct 2021 08:29:16 GMT
Subject: RFR: 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged()
 returns leftButton and rightButton as null with GTKLookAndFeel [v3]
In-Reply-To: <gn3LMUUrEY_c2nN80EtPV17dp4EngVkxIRghNQPmfkE=.37d5ff5e-2dd1-406c-995d-b40e3bb9c0bc@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
 <gn3LMUUrEY_c2nN80EtPV17dp4EngVkxIRghNQPmfkE=.37d5ff5e-2dd1-406c-995d-b40e3bb9c0bc@github.com>
Message-ID: <z4pMvTAq1RU8rn96ccrvX28RwoEnfRbj91AjGMaltYM=.084ffe93-d897-4616-8a67-58ba98cdb979@github.com>

On Mon, 27 Sep 2021 13:34:44 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> The function documentation for oneTouchExpandableChanged states that the function does couple of things, but in reality  it only does those things if the Look and Feel supports the supportsOneTouchButtons. In case the Look and Feel does not support supportsOneTouchButtons, this functions just returns in beginning and does not do anything.
>> This change clarifies the above in function documentation.
>
> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes according to JBS discussion

@jayathirthrao  @prsadhuk could one of you please have a look at this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5263


From psadhukhan at openjdk.java.net  Tue Oct  5 09:29:07 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 5 Oct 2021 09:29:07 GMT
Subject: RFR: 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged()
 returns leftButton and rightButton as null with GTKLookAndFeel [v3]
In-Reply-To: <gn3LMUUrEY_c2nN80EtPV17dp4EngVkxIRghNQPmfkE=.37d5ff5e-2dd1-406c-995d-b40e3bb9c0bc@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
 <gn3LMUUrEY_c2nN80EtPV17dp4EngVkxIRghNQPmfkE=.37d5ff5e-2dd1-406c-995d-b40e3bb9c0bc@github.com>
Message-ID: <DGSOwFul0Xhfu47cqD6VMTlbigvNfAZJ6ePGoJ3ve3I=.2271c461-0e1e-4e08-8ca9-ec87eaccffaa@github.com>

On Mon, 27 Sep 2021 13:34:44 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> The function documentation for oneTouchExpandableChanged states that the function does couple of things, but in reality  it only does those things if the Look and Feel supports the supportsOneTouchButtons. In case the Look and Feel does not support supportsOneTouchButtons, this functions just returns in beginning and does not do anything.
>> This change clarifies the above in function documentation.
>
> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes according to JBS discussion

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java line 379:

> 377:     /**
> 378:      * Messaged when the oneTouchExpandable value of the JSplitPane the
> 379:      * divider is contained in changes. Will create the

I guess "value of the current JSplitPane divider" makes more sense. 
Also, I guess leftButton,rightButton wll be created not only if they are null but also when oneTouchExpandable property is set as per code..It might seem to user from current wording that left/right button will be set if they are null even if oneTouchExpandable is not set.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5263


From jdv at openjdk.java.net  Tue Oct  5 10:40:11 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 5 Oct 2021 10:40:11 GMT
Subject: RFR: 8273102: Delete deprecated for removal the empty finalize()
 in java.desktop module
In-Reply-To: <OAhmO3Akwb17uxlk-Kn3_8ZJNy1Tkqds13JLAevCfs0=.df8f6c03-48da-4d05-8575-d304c7d97b6d@github.com>
References: <OAhmO3Akwb17uxlk-Kn3_8ZJNy1Tkqds13JLAevCfs0=.df8f6c03-48da-4d05-8575-d304c7d97b6d@github.com>
Message-ID: <jnDgUbGtWs_ZcLPSXL9kxpz7_OheCvReRR-5ahiRQ3w=.7a093acc-7fd7-408a-8dc1-3c768080f206@github.com>

On Sun, 29 Aug 2021 01:09:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "java.desktop" module has a few implementations of the finalize() which do nothing, deprecated since jdk9, and are marked "forRemoval = true" since jdk16. 
> 
> This is a request to delete such empty methods. 
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8273103

@mrserb Are we waiting on something to integrate this change?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5292


From jdv at openjdk.java.net  Tue Oct  5 10:56:06 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 5 Oct 2021 10:56:06 GMT
Subject: RFR: 8274680: Remove unnecessary conversion to String in
 java.desktop [v2]
In-Reply-To: <4gUX3W4bIm5Nzy6ebY7YIYbds6kKUUhC5CBL_6-scOo=.0058c449-2949-449c-b444-57da79ce455c@github.com>
References: <Kj-zZoiJu9UXLIOPpccjfSQVV915gfqL-acr1oQL5Bk=.1eed378e-51c3-48b8-b230-304767e6f7d5@github.com>
 <4gUX3W4bIm5Nzy6ebY7YIYbds6kKUUhC5CBL_6-scOo=.0058c449-2949-449c-b444-57da79ce455c@github.com>
Message-ID: <KQGXtdPyTa20VjBtKxiDx_0w__6_Ml0UZzMewN-6YYs=.dfae7d1a-65a3-47a6-a7c4-222c17268060@github.com>

On Mon, 4 Oct 2021 09:05:30 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274680: Remove unnecessary conversion to String in java.desktop
>   update copyright year

I see some cleanup also apart from the main issue

-------------

Marked as reviewed by jdv (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5799


From github.com+741251+turbanoff at openjdk.java.net  Tue Oct  5 11:17:29 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 5 Oct 2021 11:17:29 GMT
Subject: RFR: 8274680: Remove unnecessary conversion to String in
 java.desktop [v3]
In-Reply-To: <Kj-zZoiJu9UXLIOPpccjfSQVV915gfqL-acr1oQL5Bk=.1eed378e-51c3-48b8-b230-304767e6f7d5@github.com>
References: <Kj-zZoiJu9UXLIOPpccjfSQVV915gfqL-acr1oQL5Bk=.1eed378e-51c3-48b8-b230-304767e6f7d5@github.com>
Message-ID: <LI8Wy2gyQIc1_8z6Si5T0QuTL_Jc9dxH7sx8lbxRq0s=.acae6a5f-d7d5-4324-a968-15c50f78820a@github.com>

> Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8274680: Remove unnecessary conversion to String in java.desktop

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5799/files
  - new: https://git.openjdk.java.net/jdk/pull/5799/files/d0cc5f8b..99a8c51e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5799&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5799&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5799.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5799/head:pull/5799

PR: https://git.openjdk.java.net/jdk/pull/5799


From jdv at openjdk.java.net  Tue Oct  5 11:42:06 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 5 Oct 2021 11:42:06 GMT
Subject: RFR: 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged()
 returns leftButton and rightButton as null with GTKLookAndFeel [v3]
In-Reply-To: <DGSOwFul0Xhfu47cqD6VMTlbigvNfAZJ6ePGoJ3ve3I=.2271c461-0e1e-4e08-8ca9-ec87eaccffaa@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
 <gn3LMUUrEY_c2nN80EtPV17dp4EngVkxIRghNQPmfkE=.37d5ff5e-2dd1-406c-995d-b40e3bb9c0bc@github.com>
 <DGSOwFul0Xhfu47cqD6VMTlbigvNfAZJ6ePGoJ3ve3I=.2271c461-0e1e-4e08-8ca9-ec87eaccffaa@github.com>
Message-ID: <MiGHlf5KcqIH5qxdngR9GVS0izvahMiv7L3x-WrKJFk=.e4ac66b3-559b-4029-b0de-f9b8f2fb15d1@github.com>

On Tue, 5 Oct 2021 09:26:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes according to JBS discussion
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java line 379:
> 
>> 377:     /**
>> 378:      * Messaged when the oneTouchExpandable value of the JSplitPane the
>> 379:      * divider is contained in changes. Will create the
> 
> I guess "value of the current JSplitPane divider" makes more sense. 
> Also, I guess leftButton,rightButton wll be created not only if they are null but also when oneTouchExpandable property is set as per code..It might seem to user from current wording that left/right button will be set if they are null even if oneTouchExpandable is not set.

Messaged when XXXX is little bit confusing but since it is used at many places we can alter them may be as part of another bug.

As @prsadhuk mentioned we can update second statement as "Creates <code>leftButton</code> and <code>rightButton</code> if they are null and corresponding <code>JSplitPane</code> supports oneTouchExpandable buttons"

Its better to use "divider" instead of receiver for same reasons in third statement and update "invalidates" -> "Invalidates".

Since this just clarifies the behavior of this function and nothing is changed from compatibility side. I dont think it needs a CSR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5263


From github.com+87324768+lawrence-andrew at openjdk.java.net  Tue Oct  5 12:10:30 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Tue, 5 Oct 2021 12:10:30 GMT
Subject: RFR: 8274456 : Remove jtreg tag manual=yesno
 java/awt/print/PrinterJob/PageDialogTest.java
In-Reply-To: <vv_OzdxMEz4gFcno6RY1Jgt8uuISuvOjxAFvhuTusmM=.2382092a-fcf4-46d5-a985-b4ac668b59c2@github.com>
References: <gMmkvVXiwZJd7lPeSzgz2N2IpQBxJJaF8gWKrWY1Brk=.df46feb9-3043-4074-81b8-964c3686cba7@github.com>
 <vv_OzdxMEz4gFcno6RY1Jgt8uuISuvOjxAFvhuTusmM=.2382092a-fcf4-46d5-a985-b4ac668b59c2@github.com>
Message-ID: <_GtsqdpsoCLPWjldD5lRMimbb0s588doXKqfmw2EvrQ=.a1c7e288-1f88-4c44-9d3c-85773acb0f8f@github.com>

On Tue, 5 Oct 2021 07:08:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> 1) Removed =yesno
>> 2) After running the test case, test  UI will close immediately. Where the user cannot interact so rewrote the test case.
>> a) Toolkit Modal Dialog will be shown after clicking the show button.
>> b) Added timeout & tested
>> c) Step by step instruction what the user has to perform
>> 
>> @shurymury
>
> A few comments:
>  - Looks like you invert the assertion in the test: 
>        old: "The test fails if the page dialog blocks the toolkit"
>        new:  "Check if page dialog blocks the 'Toolkit modal dialog'. If yes, then test Pass else test fail."
>  - Please update the copyright date

@mrserb , fixed the instruction and the copyright date.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5789


From github.com+87324768+lawrence-andrew at openjdk.java.net  Tue Oct  5 12:10:30 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Tue, 5 Oct 2021 12:10:30 GMT
Subject: RFR: 8274456 : Remove jtreg tag manual=yesno
 java/awt/print/PrinterJob/PageDialogTest.java [v2]
In-Reply-To: <gMmkvVXiwZJd7lPeSzgz2N2IpQBxJJaF8gWKrWY1Brk=.df46feb9-3043-4074-81b8-964c3686cba7@github.com>
References: <gMmkvVXiwZJd7lPeSzgz2N2IpQBxJJaF8gWKrWY1Brk=.df46feb9-3043-4074-81b8-964c3686cba7@github.com>
Message-ID: <krKfyjA57dfWy4PlkMuZkScwwf_XAl03VM3z8IoFCYM=.52e91b4d-51ca-4fd3-aa98-d71616f7804a@github.com>

> 1) Removed =yesno
> 2) After running the test case, test  UI will close immediately. Where the user cannot interact so rewrote the test case.
> a) Toolkit Modal Dialog will be shown after clicking the show button.
> b) Added timeout & tested
> c) Step by step instruction what the user has to perform
> 
> @shurymury

lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:

  Fixed the instruction for the test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5789/files
  - new: https://git.openjdk.java.net/jdk/pull/5789/files/d525bb33..88d27006

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5789&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5789&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5789.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5789/head:pull/5789

PR: https://git.openjdk.java.net/jdk/pull/5789


From lbourges at openjdk.java.net  Tue Oct  5 17:15:09 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Tue, 5 Oct 2021 17:15:09 GMT
Subject: RFR: 8274680: Remove unnecessary conversion to String in
 java.desktop [v3]
In-Reply-To: <LI8Wy2gyQIc1_8z6Si5T0QuTL_Jc9dxH7sx8lbxRq0s=.acae6a5f-d7d5-4324-a968-15c50f78820a@github.com>
References: <Kj-zZoiJu9UXLIOPpccjfSQVV915gfqL-acr1oQL5Bk=.1eed378e-51c3-48b8-b230-304767e6f7d5@github.com>
 <LI8Wy2gyQIc1_8z6Si5T0QuTL_Jc9dxH7sx8lbxRq0s=.acae6a5f-d7d5-4324-a968-15c50f78820a@github.com>
Message-ID: <Oo_3xMFUzg9RdNofGjasRhdZ3zpDXVk5b6xePv6y5sc=.f3da7858-36d1-4968-bcf1-f98170c6a35e@github.com>

On Tue, 5 Oct 2021 11:17:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274680: Remove unnecessary conversion to String in java.desktop

Not an official reviewer but I approve Marlin renderer's changes

-------------

PR: https://git.openjdk.java.net/jdk/pull/5799


From prr at openjdk.java.net  Tue Oct  5 17:34:24 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 5 Oct 2021 17:34:24 GMT
Subject: Integrated: 8274397: [macOS] Stop setting env. var
 JAVA_MAIN_CLASS_<pid> in launcher code
In-Reply-To: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
References: <8j-vMsDYbF5100Dpc1DP_JGNV5V0W0D7i2fP7QnXCpU=.9169a246-f866-49c5-99fb-04f9fb946b9e@github.com>
Message-ID: <p5LSXKY40TcjuAhwfEE6hjsLvtGCbEC14X6zr1PJsws=.00c595df-3a60-4f34-a8af-d740d6d24569@github.com>

On Mon, 27 Sep 2021 20:56:28 GMT, Phil Race <prr at openjdk.org> wrote:

> macOS launcher code sets JAVA_MAIN_CLASS_<pid> which is read by AWT to set the name of the application in the system menu bar.
> 
> Because this set shortly after the VM is running, it causes a thread safety issue described in https://bugs.openjdk.java.net/browse/JDK-8270549
> 
> Since the AWT already looks for the system property "apple.awt.application.name" for this same purpose,
> we can set that instead of the env. var and avoid the threading issue.
> 
> This trades the JAVA_MAIN_CLASS_<pid> pollution of the environment for setting a system property which is visible to apps as well but it seems a reasonable trade-off since we already (implicitly) support this variable anyway in preference to the env. var.

This pull request has now been integrated.

Changeset: 37890650
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/37890650a7c97d484b6b520d909f677dac4e46e1
Stats:     205 lines in 5 files changed: 159 ins; 26 del; 20 mod

8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code

Reviewed-by: rriggs, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/5724


From serb at openjdk.java.net  Tue Oct  5 22:35:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 5 Oct 2021 22:35:09 GMT
Subject: RFR: 8274680: Remove unnecessary conversion to String in
 java.desktop [v3]
In-Reply-To: <LI8Wy2gyQIc1_8z6Si5T0QuTL_Jc9dxH7sx8lbxRq0s=.acae6a5f-d7d5-4324-a968-15c50f78820a@github.com>
References: <Kj-zZoiJu9UXLIOPpccjfSQVV915gfqL-acr1oQL5Bk=.1eed378e-51c3-48b8-b230-304767e6f7d5@github.com>
 <LI8Wy2gyQIc1_8z6Si5T0QuTL_Jc9dxH7sx8lbxRq0s=.acae6a5f-d7d5-4324-a968-15c50f78820a@github.com>
Message-ID: <25MMA4oSPrjp0XHCPU00QxfU7d7Mr8SChC5rYy4g3pA=.592fafe0-5564-4163-9067-779c23842c29@github.com>

On Tue, 5 Oct 2021 11:17:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274680: Remove unnecessary conversion to String in java.desktop

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5799


From kizune at openjdk.java.net  Tue Oct  5 22:53:06 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 5 Oct 2021 22:53:06 GMT
Subject: RFR: 8274680: Remove unnecessary conversion to String in
 java.desktop [v3]
In-Reply-To: <LI8Wy2gyQIc1_8z6Si5T0QuTL_Jc9dxH7sx8lbxRq0s=.acae6a5f-d7d5-4324-a968-15c50f78820a@github.com>
References: <Kj-zZoiJu9UXLIOPpccjfSQVV915gfqL-acr1oQL5Bk=.1eed378e-51c3-48b8-b230-304767e6f7d5@github.com>
 <LI8Wy2gyQIc1_8z6Si5T0QuTL_Jc9dxH7sx8lbxRq0s=.acae6a5f-d7d5-4324-a968-15c50f78820a@github.com>
Message-ID: <RCGyYq_MhU5Ko9myUJZJAL8FlFTzkx_9Q2CSntSIiSo=.3f58952c-5a48-4630-91f8-a6f368de61d4@github.com>

On Tue, 5 Oct 2021 11:17:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274680: Remove unnecessary conversion to String in java.desktop

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5799


From andrew at openjdk.java.net  Wed Oct  6 02:09:16 2021
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 6 Oct 2021 02:09:16 GMT
Subject: RFR: 8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on
 Manjaro Linux [v3]
In-Reply-To: <Dd1tpX41xYE43y7GoNxSiApEHoniYEx3YcpbQGCwOmE=.d9146b76-b2e9-4f37-aa4b-b4d7a96c6ba2@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
 <Dd1tpX41xYE43y7GoNxSiApEHoniYEx3YcpbQGCwOmE=.d9146b76-b2e9-4f37-aa4b-b4d7a96c6ba2@github.com>
Message-ID: <4c3mNrXIiTqcgFfgjy5jD_04YzQwPYguxxV8OOy5r8U=.a3312d01-4570-4294-8006-b02f5a66f561@github.com>

On Tue, 16 Mar 2021 16:56:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> From a build perspective this partially reverts https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps 
>> the harfbuzz sources separate and still supports building and running against a system harfbuzz which is only of interest or relevance on Linux.
>> 
>> I ended up having to go this way because its is the least unsatisfactory solution.
>> I did not want us to build a devkit to link against a system linux only to find we couldn't use it at runtime
>> because too many systems have to old a version of harfbuzz.
>> 
>> This solves the Manjaro Linux problem and I've manually verified building against a system hardbuxz on Ubuntu 20.10
>> 
>> There are couple of incidental fixes in here too
>> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building against a system version
>> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory needed to build the bundled copy
>> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux

Yes, it would fail at runtime, perhaps in subtle ways if the issue is not a missing function but a difference in behaviour.

In the scenario I'm considering, the build and runtime environments are effectively the same, as we're building packages for Fedora or RHEL on a specific version of that OS, which is then provided for that OS alone. We tend to use system libraries where possible as we know the library is going to be the same or newer than what we built against, and we benefit from fixes to the system library without rebuilding OpenJDK.

Rather than relying on failures being found in an older environment at runtime, I'd like the build to check it is being built against is suitable. With that early build failure, we can then flip those builds to using the in-tree library.

You do, however, make a good point that this check can be overridden at runtime if the build is run on a different system. So, if possible, it would be good to also have a runtime check if there is some clear entry point to add one.

I'll try and look into a fix for both once the October security update cycle is out of the way. That's taking up most of my time right now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2982


From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 02:56:10 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 02:56:10 GMT
Subject: Integrated: 8274680: Remove unnecessary conversion to String in
 java.desktop
In-Reply-To: <Kj-zZoiJu9UXLIOPpccjfSQVV915gfqL-acr1oQL5Bk=.1eed378e-51c3-48b8-b230-304767e6f7d5@github.com>
References: <Kj-zZoiJu9UXLIOPpccjfSQVV915gfqL-acr1oQL5Bk=.1eed378e-51c3-48b8-b230-304767e6f7d5@github.com>
Message-ID: <chhvCLkb70WBQc7uUujduovqifyO0dC3sHV_f-kso0o=.dfa1fbf4-acad-4236-9638-3d288d828247@github.com>

On Sun, 3 Oct 2021 16:55:36 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway

This pull request has now been integrated.

Changeset: 8a4d2b4a
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8a4d2b4aa76e6aae1cb27f476c6cc71dcd9779f0
Stats:     69 lines in 16 files changed: 0 ins; 19 del; 50 mod

8274680: Remove unnecessary conversion to String in java.desktop

Reviewed-by: pbansal, jdv, serb, kizune

-------------

PR: https://git.openjdk.java.net/jdk/pull/5799


From serb at openjdk.java.net  Wed Oct  6 03:07:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Oct 2021 03:07:08 GMT
Subject: RFR: 8274456 : Remove jtreg tag manual=yesno
 java/awt/print/PrinterJob/PageDialogTest.java [v2]
In-Reply-To: <krKfyjA57dfWy4PlkMuZkScwwf_XAl03VM3z8IoFCYM=.52e91b4d-51ca-4fd3-aa98-d71616f7804a@github.com>
References: <gMmkvVXiwZJd7lPeSzgz2N2IpQBxJJaF8gWKrWY1Brk=.df46feb9-3043-4074-81b8-964c3686cba7@github.com>
 <krKfyjA57dfWy4PlkMuZkScwwf_XAl03VM3z8IoFCYM=.52e91b4d-51ca-4fd3-aa98-d71616f7804a@github.com>
Message-ID: <151HtFBwQy8heMNvsHRP96VvO9dPOXsHzGKW69iwris=.080aad67-8556-4fa2-bbd0-ad6118905e71@github.com>

On Tue, 5 Oct 2021 12:10:30 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

>> 1) Removed =yesno
>> 2) After running the test case, test  UI will close immediately. Where the user cannot interact so rewrote the test case.
>> a) Toolkit Modal Dialog will be shown after clicking the show button.
>> b) Added timeout & tested
>> c) Step by step instruction what the user has to perform
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the instruction for the test

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5789


From serb at openjdk.java.net  Wed Oct  6 06:52:23 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Oct 2021 06:52:23 GMT
Subject: RFR: 8274806: Simplify equals() call on nullable variable and a
 constant in java.desktop
In-Reply-To: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>
References: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>
Message-ID: <DNk_2qGGR0HJUpRUc-_lGDVgCSY2KDmmwI_NhA4ezkg=.8a0bae19-79ed-472a-acee-777c6555d73c@github.com>

On Sat, 2 Oct 2021 09:14:49 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Flipping arguments of 'equals' method, allows simplifying boolean expressions: now we can remove redundant null check before.

Looks fine

src/java.desktop/share/classes/javax/swing/JSplitPane.java line 1000:

> 998:             leftComponent = comp;
> 999:             index = -1;
> 1000:         } else if (JSplitPane.RIGHT.equals(constraints) ||

I do not think that calling the equals on some object is equivalent to calling the equals on String. Please check other cases for similar issues.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5794


From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 06:52:22 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 06:52:22 GMT
Subject: RFR: 8274806: Simplify equals() call on nullable variable and a
 constant in java.desktop
Message-ID: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>

Flipping arguments of 'equals' method, allows simplifying boolean expressions: now we can remove redundant null check before.

-------------

Commit messages:
 - [PATCH] Simplify equals() call on nullable variable and a constant in java.desktop
 - [PATCH] Simplify equals() call on nullable variable and a constant

Changes: https://git.openjdk.java.net/jdk/pull/5794/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5794&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274806
  Stats: 17 lines in 11 files changed: 0 ins; 1 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5794.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5794/head:pull/5794

PR: https://git.openjdk.java.net/jdk/pull/5794


From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 10:54:13 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 10:54:13 GMT
Subject: Integrated: 8274496: Use String.contains() instead of
 String.indexOf() in java.desktop
In-Reply-To: <xfGt9s0_ZLvwVgCEAj8sF4tCvQqNztpHBMlih_9CtS8=.b3b0ed70-d010-4153-814b-1af900f53ee1@github.com>
References: <xfGt9s0_ZLvwVgCEAj8sF4tCvQqNztpHBMlih_9CtS8=.b3b0ed70-d010-4153-814b-1af900f53ee1@github.com>
Message-ID: <OTHZWMZmdYR6tuH2wpAibsy5ad7JvIVNZklGresI4Q8=.5292234c-2594-4e36-bd3e-45f2603752d4@github.com>

On Fri, 17 Sep 2021 15:46:51 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> String.contains was introduced in Java 5.
> Some code in java.desktop still uses old approach with String.indexOf to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

This pull request has now been integrated.

Changeset: 9759fcb1
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Pankaj Bansal <pbansal at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9759fcb17b62d76d75b893481bbd4ef45e7ad366
Stats:     58 lines in 10 files changed: 0 ins; 6 del; 52 mod

8274496: Use String.contains() instead of String.indexOf() in java.desktop

Reviewed-by: pbansal, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/5565


From myano at openjdk.java.net  Wed Oct  6 10:56:14 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 6 Oct 2021 10:56:14 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
In-Reply-To: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
Message-ID: <RptJ5z9Q-NQZEhVgH64DTZ_ECBawXJm1RRZ0rnOkWNw=.175cdce5-0685-42d8-ba70-dfdc0d78a34c@github.com>

On Mon, 13 Sep 2021 11:32:37 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the 7001973 fixes?
> 
> On Windows, CopyAreaOOB.java fails with a blank window. The cause of this problem is that paint() works one time only. Painting area is not guaranteed when showing a window.
> 
> I think this behavior should be removed for purpose of this test (`@summary: Verifies that copyArea() works properly`). Also, this program uses a Robot, but implements waiting logic by itself. This logic should be replaced to Robot API.
> 
> This fix works fine in Windows, so this test can be removed from ProblemList.txt. I don't have a Mac environment, so can someone please confirm that this fix will work on Mac?

I think we should fix D3DScreenUpdateManager. I would like to create a new issue for it.

But I think this test should be fixed, because the purpose of this test is to confirm the usual drawing result on default settings, then there is no need to restrict paint() one time.

If the test that verifies paint() isn't called twice is needed, we should create a new test in the new bug id.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5491


From serb at openjdk.java.net  Wed Oct  6 19:09:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Oct 2021 19:09:08 GMT
Subject: RFR: 8273102: Delete deprecated for removal the empty finalize()
 in java.desktop module
In-Reply-To: <NdjQfloHkOvY8oNZPKCquTK0fISmmvpUSRxtk-XuUVw=.3e9d534e-7fb2-4aa7-84c3-ef48d2d5f5e8@github.com>
References: <OAhmO3Akwb17uxlk-Kn3_8ZJNy1Tkqds13JLAevCfs0=.df8f6c03-48da-4d05-8575-d304c7d97b6d@github.com>
 <NdjQfloHkOvY8oNZPKCquTK0fISmmvpUSRxtk-XuUVw=.3e9d534e-7fb2-4aa7-84c3-ef48d2d5f5e8@github.com>
Message-ID: <0iCi9z9VVGna3Cna8UiW-4_qRsgYJXuvWltL2i2zNnk=.9aa5a1e8-b675-4117-97e6-03c2850da58c@github.com>

On Sun, 12 Sep 2021 04:38:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> The "java.desktop" module has a few implementations of the finalize() which do nothing, deprecated since jdk9, and are marked "forRemoval = true" since jdk16. 
>> 
>> This is a request to delete such empty methods. 
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8273103
>
> Marked as reviewed by prr (Reviewer).

@prrace @jayathirthrao I am going to push this change, please note it might cause some test failures in JCK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5292


From serb at openjdk.java.net  Wed Oct  6 22:34:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Oct 2021 22:34:14 GMT
Subject: Integrated: 8273102: Delete deprecated for removal the empty
 finalize() in java.desktop module
In-Reply-To: <OAhmO3Akwb17uxlk-Kn3_8ZJNy1Tkqds13JLAevCfs0=.df8f6c03-48da-4d05-8575-d304c7d97b6d@github.com>
References: <OAhmO3Akwb17uxlk-Kn3_8ZJNy1Tkqds13JLAevCfs0=.df8f6c03-48da-4d05-8575-d304c7d97b6d@github.com>
Message-ID: <awK20-3ROHr23v5HheDr5llwH00R70KocO7B4yyyGsQ=.0d329feb-933a-4c7a-b3a2-6d5b183ece52@github.com>

On Sun, 29 Aug 2021 01:09:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "java.desktop" module has a few implementations of the finalize() which do nothing, deprecated since jdk9, and are marked "forRemoval = true" since jdk16. 
> 
> This is a request to delete such empty methods. 
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8273103

This pull request has now been integrated.

Changeset: 9561fea7
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9561fea79035f23ca3a6619c9e150433cdf4a232
Stats:     57 lines in 3 files changed: 0 ins; 57 del; 0 mod

8273102: Delete deprecated for removal the empty finalize() in java.desktop module

Reviewed-by: pbansal, aivanov, iris, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/5292


From serb at openjdk.java.net  Wed Oct  6 22:36:17 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Oct 2021 22:36:17 GMT
Subject: RFR: 8041125: ColorConvertOp filter much slower in JDK 8 compared to
 JDK7
Message-ID: <01oQmcaxpb_DFPCTQS_ek2CnCbEJRCNODsZNF7KR8t0=.9e9f761d-0c08-40de-bc8b-fcc612da9d2e@github.com>

We have improved the cmm code over a few releases and mostly resolve the JDK-8041125. But I have executed an attached test case under a profiler and found that:

* less than 10% is an actual pixel transformation inside littlecms
* 30% is a native up-calls like getXXField
* 30% is incoming arrays coping
* 30% results array saving
* others

This change removes the native up-calls and passes all data from the java side.

Notes:

* The above numbers are true for the "pure Java" implementation in the test case, where we transform the image pixel by pixel, if the image is big and we transform it at once via filter then we spend most of the time in the littlecms code
* JDK7 uses 4 threads in the filter implementation, but single-threaded jdk17 is faster because of some code improvement in cmm profiles initialization during the "cold start". And probably because the image is not so big(625x843).
* If the size of the image will be increased and the warmup is done the jdk7 will be 4x time faster, this is another opportunity that I'll try to resolve later.


Tested on macOS (fastest result after a few runs):
||JDK 7 | JDK 8 | JDK 17 | FIX |
|----|----|----|----|----|
|With filter |  307 ms  |  456 ms  |  242 ms  |   236 ms |
|In pure Java|  1672 ms  |  389 ms  |  300 ms  |  259 ms  |


JMH before/after the fix
`ColorSpace.toRGB/fromRGB/toCIEXYZ/fromCIEXYZ(new float[]{1,1,1})`
single threaded and multi-threaded(MAX = 30):
![image](https://user-images.githubusercontent.com/14138494/136283699-05e47dca-e7f8-43a1-97d3-53072d3589f6.png)

https://jmh.morethan.io/?gists=b1edd5e5ebeb1b76867b2112be30145d,fc86ce4a6f8f2f49e9ab512ef641c11b

-------------

Commit messages:
 - Update LCMS.java
 - initial fix

Changes: https://git.openjdk.java.net/jdk/pull/5835/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5835&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8041125
  Stats: 137 lines in 4 files changed: 9 ins; 101 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5835.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5835/head:pull/5835

PR: https://git.openjdk.java.net/jdk/pull/5835


From github.com+87324768+lawrence-andrew at openjdk.java.net  Wed Oct  6 23:16:09 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Wed, 6 Oct 2021 23:16:09 GMT
Subject: Integrated: 8274456 : Remove jtreg tag manual=yesno
 java/awt/print/PrinterJob/PageDialogTest.java
In-Reply-To: <gMmkvVXiwZJd7lPeSzgz2N2IpQBxJJaF8gWKrWY1Brk=.df46feb9-3043-4074-81b8-964c3686cba7@github.com>
References: <gMmkvVXiwZJd7lPeSzgz2N2IpQBxJJaF8gWKrWY1Brk=.df46feb9-3043-4074-81b8-964c3686cba7@github.com>
Message-ID: <O4h7IPePz9D-by_6pCoQN3amid7beaqYdiU3SLiM9CA=.300d2421-5cf8-45a7-80cd-90ce70601124@github.com>

On Fri, 1 Oct 2021 18:27:21 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

> 1) Removed =yesno
> 2) After running the test case, test  UI will close immediately. Where the user cannot interact so rewrote the test case.
> a) Toolkit Modal Dialog will be shown after clicking the show button.
> b) Added timeout & tested
> c) Step by step instruction what the user has to perform
> 
> @shurymury

This pull request has now been integrated.

Changeset: d57fb6f6
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d57fb6f684eac5a7e68842dcf3284309e3867521
Stats:     181 lines in 1 file changed: 44 ins; 90 del; 47 mod

8274456: Remove jtreg tag manual=yesno java/awt/print/PrinterJob/PageDialogTest.java

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/5789


From github.com+741251+turbanoff at openjdk.java.net  Thu Oct  7 03:46:10 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 7 Oct 2021 03:46:10 GMT
Subject: Integrated: 8274497: Unnecessary Vector usage in AquaFileSystemModel
In-Reply-To: <RynQ8VCkYlanv_kRkwdAOM3__VTfXj8gQA-Q8Pyz1XA=.cb960c01-46fa-4cba-87d3-83a3033e19fc@github.com>
References: <RynQ8VCkYlanv_kRkwdAOM3__VTfXj8gQA-Q8Pyz1XA=.cb960c01-46fa-4cba-87d3-83a3033e19fc@github.com>
Message-ID: <Nxv_Tb1ID8bufER9IIe3Q2RS3wNV__pwpZo5lwdJ0p0=.f6aa510c-72ae-4c0a-8229-7ef4865b3941@github.com>

On Fri, 17 Sep 2021 20:32:00 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Fields AquaFileSystemModel.fileCache and AquaFileSystemModel.FilesLoader.queuedTasks are accessed only under synchronized(fileCacheLock).
> It means extract synchronization by Vector is not needed.

This pull request has now been integrated.

Changeset: 4e960fe5
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4e960fe53f0948c0b0decfeb13f6dd8f74bf3d6f
Stats:     8 lines in 1 file changed: 0 ins; 0 del; 8 mod

8274497: Unnecessary Vector usage in AquaFileSystemModel

Reviewed-by: serb, pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/5568


From github.com+741251+turbanoff at openjdk.java.net  Thu Oct  7 08:17:20 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 7 Oct 2021 08:17:20 GMT
Subject: RFR: 8274882: Cleanup redundant boxing in java.desktop
Message-ID: <dZULF4WEflGF9TNi85mG3QnmXayrHzuhzgk6MdsnufY=.4053c03a-d1ad-4db1-9c00-5dd7a15562d1@github.com>

I missed a few places in https://bugs.openjdk.java.net/browse/JDK-8273168

-------------

Commit messages:
 - [PATCH] Cleanup redundant boxing in java.desktop

Changes: https://git.openjdk.java.net/jdk/pull/5834/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5834&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274882
  Stats: 18 lines in 9 files changed: 0 ins; 3 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5834.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5834/head:pull/5834

PR: https://git.openjdk.java.net/jdk/pull/5834


From serb at openjdk.java.net  Thu Oct  7 09:00:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 7 Oct 2021 09:00:10 GMT
Subject: RFR: 8274882: Cleanup redundant boxing in java.desktop
In-Reply-To: <dZULF4WEflGF9TNi85mG3QnmXayrHzuhzgk6MdsnufY=.4053c03a-d1ad-4db1-9c00-5dd7a15562d1@github.com>
References: <dZULF4WEflGF9TNi85mG3QnmXayrHzuhzgk6MdsnufY=.4053c03a-d1ad-4db1-9c00-5dd7a15562d1@github.com>
Message-ID: <9vVzV9ZbIVnm1KYI6y6dv6kPN6S97hmsEKTXrJTXaCs=.435cb32a-9e1e-48d6-bd9b-4d26354ec2a2@github.com>

On Wed, 6 Oct 2021 07:29:51 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I missed a few places in https://bugs.openjdk.java.net/browse/JDK-8273168

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5834


From serb at openjdk.java.net  Thu Oct  7 09:03:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 7 Oct 2021 09:03:07 GMT
Subject: RFR: 8274806: Simplify equals() call on nullable variable and a
 constant in java.desktop
In-Reply-To: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>
References: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>
Message-ID: <uJwYxt3HrHwF2EfW0obfA9L7NFE_tyhMvhtpxzQF2Cw=.7f2ebad2-fdab-451b-94ec-568149a359df@github.com>

On Sat, 2 Oct 2021 09:14:49 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Flipping arguments of 'equals' method, allows simplifying boolean expressions: now we can remove redundant null check before.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5794


From pbansal at openjdk.java.net  Thu Oct  7 09:11:12 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 7 Oct 2021 09:11:12 GMT
Subject: RFR: 8274806: Simplify equals() call on nullable variable and a
 constant in java.desktop
In-Reply-To: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>
References: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>
Message-ID: <aHJQud28sKjC-O_FC6_WKvzcmgV1YMNQFsVIbb8Vh84=.69234042-ecc6-4c8e-9cd1-74e872d5c2a4@github.com>

On Sat, 2 Oct 2021 09:14:49 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Flipping arguments of 'equals' method, allows simplifying boolean expressions: now we can remove redundant null check before.

looks good to me

-------------

Marked as reviewed by pbansal (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5794


From github.com+741251+turbanoff at openjdk.java.net  Thu Oct  7 10:23:28 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 7 Oct 2021 10:23:28 GMT
Subject: RFR: 8274893: Update java.desktop classes to use try-with-resources
Message-ID: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>

8274893: Update java.desktop classes to use try-with-resources

-------------

Commit messages:
 - [PATCH] Use try-with-resources to close resources in java.desktop
 - [PATCH] Use try-with-resources to close resources in java.desktop
 - [PATCH] Use try-with-resources to close InputStream in java.desktop

Changes: https://git.openjdk.java.net/jdk/pull/5817/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5817&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274893
  Stats: 217 lines in 24 files changed: 20 ins; 105 del; 92 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5817.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5817/head:pull/5817

PR: https://git.openjdk.java.net/jdk/pull/5817


From pbansal at openjdk.java.net  Thu Oct  7 10:41:09 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 7 Oct 2021 10:41:09 GMT
Subject: RFR: 8274882: Cleanup redundant boxing in java.desktop
In-Reply-To: <dZULF4WEflGF9TNi85mG3QnmXayrHzuhzgk6MdsnufY=.4053c03a-d1ad-4db1-9c00-5dd7a15562d1@github.com>
References: <dZULF4WEflGF9TNi85mG3QnmXayrHzuhzgk6MdsnufY=.4053c03a-d1ad-4db1-9c00-5dd7a15562d1@github.com>
Message-ID: <dqPvQSq9cN2xZjMJT4SHLcuTlZGBe97o3dduhB-vJJM=.4fa87f47-8af1-4270-bfc0-94fb5c14774d@github.com>

On Wed, 6 Oct 2021 07:29:51 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I missed a few places in https://bugs.openjdk.java.net/browse/JDK-8273168

Marked as reviewed by pbansal (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5834


From github.com+741251+turbanoff at openjdk.java.net  Thu Oct  7 11:41:25 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 7 Oct 2021 11:41:25 GMT
Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules
Message-ID: <mzVeRcWIXkzXKXQsKh-lhT74R7J3XixXSvGBtKqByrQ=.c6f98337-7cf7-4628-9be2-f720f7717147@github.com>

StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance

-------------

Commit messages:
 - [PATCH] Cleanup usages of StringBuffer in jdk tools modules

Changes: https://git.openjdk.java.net/jdk/pull/5433/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5433&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274898
  Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5433.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5433/head:pull/5433

PR: https://git.openjdk.java.net/jdk/pull/5433


From github.com+90066231+alisenchung at openjdk.java.net  Thu Oct  7 15:05:10 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Thu, 7 Oct 2021 15:05:10 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v8]
In-Reply-To: <XHOApVNKaTbVA4cfjYY-5RK7IZB_fhySC-5SOx_YVn4=.125093c7-9cf8-41ea-ae75-549afc7fc6f0@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <zsJFJUWvjsJU0y0oAZnwYSsP4ohFybmjpc3zLCUbBFk=.b3f71931-d4a7-46b4-95e6-d00a1bd74e51@github.com>
 <6YsYfbpMiVutZfIAXIWvmaxLw44S6zgAsF9IEgM7W44=.97032334-d216-4c26-8db1-8c03ae859dae@github.com>
 <XHOApVNKaTbVA4cfjYY-5RK7IZB_fhySC-5SOx_YVn4=.125093c7-9cf8-41ea-ae75-549afc7fc6f0@github.com>
Message-ID: <Wkuh5u61pLb-47PvsR2Jr4PlumeBs7QKkfuVcYqPr-c=.28110e1f-6e42-4d70-8f25-9e6b6ae26a03@github.com>

On Fri, 1 Oct 2021 22:37:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I think synthesizeMouseEnteredExitedEventsForAllWindows shouldn't be in deliverMoveResizeEvent since there shouldn't be any mouseEnter/Exit events during a resize or move
> 
> Why do you think that if the window is moved/resized and/or appeared under the mouse then the mouse event should not be posted? I do not think so. We can try to minimize the number of events when the user drags/resizes the window, but we should not change the number of events if the macos/app moved/resized the window.

I think mouseEvents are already posted by macos when the mouse enters the window thru fullscreen-resizing (green button) or tiling, so I think we don't need to synthesize additional events. I suggest we remove the line because it introduces another bug where dragging to move the window will post a mouseEntered event without the mouse ever entering the actual window. It also introduces the bug from the original bug report.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From sspitsyn at openjdk.java.net  Thu Oct  7 15:23:09 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 7 Oct 2021 15:23:09 GMT
Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules
In-Reply-To: <mzVeRcWIXkzXKXQsKh-lhT74R7J3XixXSvGBtKqByrQ=.c6f98337-7cf7-4628-9be2-f720f7717147@github.com>
References: <mzVeRcWIXkzXKXQsKh-lhT74R7J3XixXSvGBtKqByrQ=.c6f98337-7cf7-4628-9be2-f720f7717147@github.com>
Message-ID: <QIj79kNVlrpVcL-Rx0W7nCXiFIBPLqplm0i4vNeyx80=.5dc68c62-7768-4197-82ee-7ac16ce059b8@github.com>

On Thu, 9 Sep 2021 06:53:13 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5433


From prr at openjdk.java.net  Thu Oct  7 19:34:06 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 7 Oct 2021 19:34:06 GMT
Subject: RFR: 8274304: Update or Problem List tests which may fail with
 uiScale=2 on macOS
In-Reply-To: <j-ULwTmOaaJyAo9uzLv-mI9OLjIvpEVoE1iY52j_vv0=.98b2f37f-d11d-49fb-a2ab-dd6472829db7@github.com>
References: <j-ULwTmOaaJyAo9uzLv-mI9OLjIvpEVoE1iY52j_vv0=.98b2f37f-d11d-49fb-a2ab-dd6472829db7@github.com>
Message-ID: <-8e42ZUP2UFvVL77Bc0s52CAh3z-7UebU4RbNehZQYI=.da767811-7ef0-4ee6-8d5d-7022ba764679@github.com>

On Thu, 30 Sep 2021 04:43:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The fix for 8274296 added uiScale=1 to some of the tests to fix the problem of incorrect pixel color capture by the robot.
> In both cases uiScale=1 or uiScale=2 the same call should be made to the macOS. But if uiScale=1 is set we just read one pixel on the screen, but if uiScale=2 is set we prepare the data in some clumsy way(at the end we should also read just one pixel).
> 
> Since uiScale=1 affects the test case execution means that we probably have some bugs in the coordinate/size calculation of the area. Note that none of these tests have dependencies on the precise rendering, so it is quite a common use-case and may affect any external applications.
> 
> This is a request to update the https://github.com/openjdk/jdk/pull/5687/files
> and move all tests to the problem list.

I don't think "we" have a problem. I think there is a macOS bug.
But more to the immediate point since I don't think UI scale is important for anything these tests  test,
I think it is fine as is. 
So let's leave the tests running using uiScale=1 here they are doing something useful and withdraw this PR

-------------

PR: https://git.openjdk.java.net/jdk/pull/5766


From serb at openjdk.java.net  Thu Oct  7 22:20:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 7 Oct 2021 22:20:09 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v8]
In-Reply-To: <Wkuh5u61pLb-47PvsR2Jr4PlumeBs7QKkfuVcYqPr-c=.28110e1f-6e42-4d70-8f25-9e6b6ae26a03@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <zsJFJUWvjsJU0y0oAZnwYSsP4ohFybmjpc3zLCUbBFk=.b3f71931-d4a7-46b4-95e6-d00a1bd74e51@github.com>
 <6YsYfbpMiVutZfIAXIWvmaxLw44S6zgAsF9IEgM7W44=.97032334-d216-4c26-8db1-8c03ae859dae@github.com>
 <XHOApVNKaTbVA4cfjYY-5RK7IZB_fhySC-5SOx_YVn4=.125093c7-9cf8-41ea-ae75-549afc7fc6f0@github.com>
 <Wkuh5u61pLb-47PvsR2Jr4PlumeBs7QKkfuVcYqPr-c=.28110e1f-6e42-4d70-8f25-9e6b6ae26a03@github.com>
Message-ID: <42aBdnqpfOHEz0bvd7zWT180Jtg-p2Wdfqz6wz7aIMA=.dcecf7af-4cce-4cb0-b239-9e06538f5ef0@github.com>

On Thu, 7 Oct 2021 15:01:48 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> I think mouseEvents are already posted by macos when the mouse enters the window thru fullscreen-resizing (green button) or tiling, so I think we don't need to synthesize additional events. 

If we do not need to synthesize additional events then why do you see a difference in behavior before/after the fix here:
https://github.com/openjdk/jdk/pull/5497#issuecomment-930588684
?

> I suggest we remove the line because it introduces another bug where dragging to move the window will post a mouseEntered event without the mouse ever entering the actual window. It also introduces the bug from the original bug report.

But we should not introduce the new one.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From serb at openjdk.java.net  Thu Oct  7 22:37:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 7 Oct 2021 22:37:08 GMT
Subject: RFR: 8274304: Update or Problem List tests which may fail with
 uiScale=2 on macOS
In-Reply-To: <-8e42ZUP2UFvVL77Bc0s52CAh3z-7UebU4RbNehZQYI=.da767811-7ef0-4ee6-8d5d-7022ba764679@github.com>
References: <j-ULwTmOaaJyAo9uzLv-mI9OLjIvpEVoE1iY52j_vv0=.98b2f37f-d11d-49fb-a2ab-dd6472829db7@github.com>
 <-8e42ZUP2UFvVL77Bc0s52CAh3z-7UebU4RbNehZQYI=.da767811-7ef0-4ee6-8d5d-7022ba764679@github.com>
Message-ID: <x59gS9ub8FWLtweyuABKbjTKvzgCsh6so_Iieoz6oaQ=.3607e498-f202-4f17-9cdf-2a66734ec285@github.com>

On Thu, 7 Oct 2021 19:30:41 GMT, Phil Race <prr at openjdk.org> wrote:

> I don't think "we" have a problem. I think there is a macOS bug.

In both cases, we should execute the same code and request the same number of pixels(the one pixel) from the macOS. The robot native code should not be affected by the uiScale parameter, since the native macOS API gets the coordinates/size in the device space.

>  So let's leave the tests running using uiScale=1 here they are doing something useful and withdraw this PR

That tests found a bug, and it will be better to fix it other than workaround it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5766


From prr at openjdk.java.net  Thu Oct  7 23:02:09 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 7 Oct 2021 23:02:09 GMT
Subject: RFR: 8274304: Update or Problem List tests which may fail with
 uiScale=2 on macOS
In-Reply-To: <j-ULwTmOaaJyAo9uzLv-mI9OLjIvpEVoE1iY52j_vv0=.98b2f37f-d11d-49fb-a2ab-dd6472829db7@github.com>
References: <j-ULwTmOaaJyAo9uzLv-mI9OLjIvpEVoE1iY52j_vv0=.98b2f37f-d11d-49fb-a2ab-dd6472829db7@github.com>
Message-ID: <WsxsomkSPF_qv6CBm66BhfrkjRR875v7Ot1EdeCYpzY=.3db56f4b-eb79-499c-9562-1f27cb85d69b@github.com>

On Thu, 30 Sep 2021 04:43:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The fix for 8274296 added uiScale=1 to some of the tests to fix the problem of incorrect pixel color capture by the robot.
> In both cases uiScale=1 or uiScale=2 the same call should be made to the macOS. But if uiScale=1 is set we just read one pixel on the screen, but if uiScale=2 is set we prepare the data in some clumsy way(at the end we should also read just one pixel).
> 
> Since uiScale=1 affects the test case execution means that we probably have some bugs in the coordinate/size calculation of the area. Note that none of these tests have dependencies on the precise rendering, so it is quite a common use-case and may affect any external applications.
> 
> This is a request to update the https://github.com/openjdk/jdk/pull/5687/files
> and move all tests to the problem list.

We already have several bugs problem listed and I do not want to exclude more tests than necessary that work everywhere including hidpi except on some specific h/w and are NOT related to hidpi
So, in other words, leave it as it is. I thought this through when I made the original change and you've said nothing that comes within a mile of convincing me otherwise.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5766


From serb at openjdk.java.net  Thu Oct  7 23:20:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 7 Oct 2021 23:20:08 GMT
Subject: RFR: 8274304: Update or Problem List tests which may fail with
 uiScale=2 on macOS
In-Reply-To: <WsxsomkSPF_qv6CBm66BhfrkjRR875v7Ot1EdeCYpzY=.3db56f4b-eb79-499c-9562-1f27cb85d69b@github.com>
References: <j-ULwTmOaaJyAo9uzLv-mI9OLjIvpEVoE1iY52j_vv0=.98b2f37f-d11d-49fb-a2ab-dd6472829db7@github.com>
 <WsxsomkSPF_qv6CBm66BhfrkjRR875v7Ot1EdeCYpzY=.3db56f4b-eb79-499c-9562-1f27cb85d69b@github.com>
Message-ID: <EoGFPXE6nzReAS_lmNgdxaU_OOGCAk2JYBTHFOXAFIo=.8eed5fc5-cf30-4931-9adc-48f101f1dec4@github.com>

On Thu, 7 Oct 2021 22:59:16 GMT, Phil Race <prr at openjdk.org> wrote:

> We already have several bugs problem listed and I do not want to exclude more tests than necessary that work everywhere including hidpi except on some specific h/w and are NOT related to hidpi So, in other words, leave it as it is. I thought this through when I made the original change and you've said nothing that comes within a mile of convincing me otherwise.

You did even worse than excluding it for some platforms, you actually exclude all these tests from the executing in HiDPI mode on all platforms which were not affected by the bug, to work around the bug on macOS where this option does not affect the robot API, does not affect the size of the windows as well as other coordinates, it is a plain workaround.

I do not understand why do you think it is unnecessary to run these tests in the HiDPI mode since we already know that these tests already found a bug in the JDK?

> I do not want to exclude more tests than necessary that work everywhere including hidpi

How do you know that they work in HiDPI since you excluded them from that mode? Why not do this per macOS platform? Why do you think this is a macOS bug?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5766


From serb at openjdk.java.net  Thu Oct  7 23:39:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 7 Oct 2021 23:39:14 GMT
Subject: RFR: 8274029 : Remove jtreg tag manual=yesno for
 java/awt/print/Dialog/DialogOrient.java
In-Reply-To: <Ro_fn0IJMpEylrSDc18KA2ja2kqn9pXV2VGJVNYILBw=.32f3e969-5ea3-4739-81dc-84199b86ab50@github.com>
References: <Ro_fn0IJMpEylrSDc18KA2ja2kqn9pXV2VGJVNYILBw=.32f3e969-5ea3-4739-81dc-84199b86ab50@github.com>
Message-ID: <TwbdMxxTydd20ZWEebZ99ZE4eX4CVfCkIo6btXTWWZU=.257947a2-8bc6-4eca-977a-61391fa91d79@github.com>

On Mon, 20 Sep 2021 21:36:34 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

> Problem : Testcase was failing with parser exception 
> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno 
> Fix : Removed =yesno and run the testcase and Test UI ( instruction and print dialog ) is visible
> 
> @shurymury

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5589


From prr at openjdk.java.net  Thu Oct  7 23:45:07 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 7 Oct 2021 23:45:07 GMT
Subject: RFR: 8274304: Update or Problem List tests which may fail with
 uiScale=2 on macOS
In-Reply-To: <j-ULwTmOaaJyAo9uzLv-mI9OLjIvpEVoE1iY52j_vv0=.98b2f37f-d11d-49fb-a2ab-dd6472829db7@github.com>
References: <j-ULwTmOaaJyAo9uzLv-mI9OLjIvpEVoE1iY52j_vv0=.98b2f37f-d11d-49fb-a2ab-dd6472829db7@github.com>
Message-ID: <X5Yc9XrFWMpq5VvOcpZsk7ZWoJ-90qaeZv7ncNGohqM=.63191ae9-de59-46db-8834-01e1aba466cf@github.com>

On Thu, 30 Sep 2021 04:43:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The fix for 8274296 added uiScale=1 to some of the tests to fix the problem of incorrect pixel color capture by the robot.
> In both cases uiScale=1 or uiScale=2 the same call should be made to the macOS. But if uiScale=1 is set we just read one pixel on the screen, but if uiScale=2 is set we prepare the data in some clumsy way(at the end we should also read just one pixel).
> 
> Since uiScale=1 affects the test case execution means that we probably have some bugs in the coordinate/size calculation of the area. Note that none of these tests have dependencies on the precise rendering, so it is quite a common use-case and may affect any external applications.
> 
> This is a request to update the https://github.com/openjdk/jdk/pull/5687/files
> and move all tests to the problem list.

Once again, hi-dpi does not matter for these tests. It is not what they are trying to test and there is no other "hi-dpi" testing going on anyway on these other platforms, and I keep saying bug in macos not JDK for the reasons I wrote in
https://bugs.openjdk.java.net/browse/JDK-8274106 which is tracking the underlying issue and is aware of ALL the tests that fail. I looked at the Robot code and it was getting different answers *from a macos api* depending on  whether it asked for some larger region first.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5766


From serb at openjdk.java.net  Fri Oct  8 00:14:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 8 Oct 2021 00:14:05 GMT
Subject: RFR: 8274304: Update or Problem List tests which may fail with
 uiScale=2 on macOS
In-Reply-To: <X5Yc9XrFWMpq5VvOcpZsk7ZWoJ-90qaeZv7ncNGohqM=.63191ae9-de59-46db-8834-01e1aba466cf@github.com>
References: <j-ULwTmOaaJyAo9uzLv-mI9OLjIvpEVoE1iY52j_vv0=.98b2f37f-d11d-49fb-a2ab-dd6472829db7@github.com>
 <X5Yc9XrFWMpq5VvOcpZsk7ZWoJ-90qaeZv7ncNGohqM=.63191ae9-de59-46db-8834-01e1aba466cf@github.com>
Message-ID: <lVOaLVmsVdpjZ25Xj07Au4kMqP4sDrDHUHbAt6T8st8=.5d107296-6d82-4d5f-b6be-bfdbc7e04ec7@github.com>

On Thu, 7 Oct 2021 23:41:37 GMT, Phil Race <prr at openjdk.org> wrote:

> Once again, hi-dpi does not matter for these tests. It is not what they are trying to test and there is no other "hi-dpi" testing going on anyway on these other platforms

Why hiDPI does not matter for the tests like these PaintNativeOnUpdate/BackgroundIsNotUpdated/TranslucentJAppletTest? All of them may have different bihaviour in low and hi modes.

> there is no other "hi-dpi" testing going on anyway on these other platforms

I run the tests in this mode all the time.

> I looked at the Robot code and it was getting different answers _from a macos api_ depending on whether it asked for some larger region first.

It is just impossible that CGWindowListCreateImage which we use to catch the pixels returns different results, since we call it using the same coordinates, it does not affect by the uiScale option. The bug in some other place/methods. We ever calculate the wrong bounds/size of the image or incorrectly store it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5766


From serb at openjdk.java.net  Fri Oct  8 00:19:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 8 Oct 2021 00:19:05 GMT
Subject: RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing
In-Reply-To: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
Message-ID: <EbfOB5mmFL1ZgltetdXtwRmaRAWRuX7DwA8Ht0HkNyU=.19467570-ac50-4548-aa60-1755a3c44768@github.com>

On Mon, 4 Oct 2021 14:54:27 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.

I am fine with any solution but think the check will be simpler and safer, and later we will be able to change the behavior of some of these methods if it will be needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5806


From serb at openjdk.java.net  Fri Oct  8 01:00:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 8 Oct 2021 01:00:08 GMT
Subject: RFR: 8274304: Update or Problem List tests which may fail with
 uiScale=2 on macOS
In-Reply-To: <j-ULwTmOaaJyAo9uzLv-mI9OLjIvpEVoE1iY52j_vv0=.98b2f37f-d11d-49fb-a2ab-dd6472829db7@github.com>
References: <j-ULwTmOaaJyAo9uzLv-mI9OLjIvpEVoE1iY52j_vv0=.98b2f37f-d11d-49fb-a2ab-dd6472829db7@github.com>
Message-ID: <5vdF4E8zMqugviBVhstOBz6zyHa3HvFTfgBuBwVyrjs=.56607e4a-bf02-4987-aa0a-21b25a56cb85@github.com>

On Thu, 30 Sep 2021 04:43:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The fix for 8274296 added uiScale=1 to some of the tests to fix the problem of incorrect pixel color capture by the robot.
> In both cases uiScale=1 or uiScale=2 the same call should be made to the macOS. But if uiScale=1 is set we just read one pixel on the screen, but if uiScale=2 is set we prepare the data in some clumsy way(at the end we should also read just one pixel).
> 
> Since uiScale=1 affects the test case execution means that we probably have some bugs in the coordinate/size calculation of the area. Note that none of these tests have dependencies on the precise rendering, so it is quite a common use-case and may affect any external applications.
> 
> This is a request to update the https://github.com/openjdk/jdk/pull/5687/files
> and move all tests to the problem list.

It looks like where is at least one buffer overrun caused by the JDK-8162959, I'll work on it. But still suggest to accept this patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5766


From github.com+741251+turbanoff at openjdk.java.net  Fri Oct  8 07:20:21 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 8 Oct 2021 07:20:21 GMT
Subject: RFR: 8274945: Cleanup unnecessary calls to Throwable.initCause() in
 java.desktop
Message-ID: <9cAqNXhLLsUf-c78adEzM3ddvAOtmu--0e-ge5UHiHY=.be9e7ec9-158f-4352-8e06-1e023a5fb161@github.com>

Pass cause exception as constructor parameter is shorter and easier to read.

-------------

Commit messages:
 - [PATCH] Cleanup unnecessary calls to Throwable.initCause() in java.desktop module

Changes: https://git.openjdk.java.net/jdk/pull/5847/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5847&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274945
  Stats: 21 lines in 4 files changed: 0 ins; 15 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5847.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5847/head:pull/5847

PR: https://git.openjdk.java.net/jdk/pull/5847


From serb at openjdk.java.net  Fri Oct  8 07:20:22 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 8 Oct 2021 07:20:22 GMT
Subject: RFR: 8274945: Cleanup unnecessary calls to Throwable.initCause()
 in java.desktop
In-Reply-To: <9cAqNXhLLsUf-c78adEzM3ddvAOtmu--0e-ge5UHiHY=.be9e7ec9-158f-4352-8e06-1e023a5fb161@github.com>
References: <9cAqNXhLLsUf-c78adEzM3ddvAOtmu--0e-ge5UHiHY=.be9e7ec9-158f-4352-8e06-1e023a5fb161@github.com>
Message-ID: <9JBA2eCMJgASGVl4Fi0SO8u4C84q_bOve44qJ2LszMI=.acad51ad-51d6-4740-8621-5592a03dd59d@github.com>

On Thu, 7 Oct 2021 12:39:10 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Pass cause exception as constructor parameter is shorter and easier to read.

Looks fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5847


From jdv at openjdk.java.net  Fri Oct  8 07:33:07 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Fri, 8 Oct 2021 07:33:07 GMT
Subject: RFR: 8274945: Cleanup unnecessary calls to Throwable.initCause()
 in java.desktop
In-Reply-To: <9cAqNXhLLsUf-c78adEzM3ddvAOtmu--0e-ge5UHiHY=.be9e7ec9-158f-4352-8e06-1e023a5fb161@github.com>
References: <9cAqNXhLLsUf-c78adEzM3ddvAOtmu--0e-ge5UHiHY=.be9e7ec9-158f-4352-8e06-1e023a5fb161@github.com>
Message-ID: <cy0fZFlBHkuhqy-nZwEtVMjsGmJcSLnzqhFRfQCDm8I=.6e7f56b7-feae-4885-b713-37de7ccc4bdc@github.com>

On Thu, 7 Oct 2021 12:39:10 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Pass cause exception as constructor parameter is shorter and easier to read.

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5847


From jdv at openjdk.java.net  Fri Oct  8 07:41:19 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Fri, 8 Oct 2021 07:41:19 GMT
Subject: RFR: 8272756: Remove unnecessary explicit initialization of
 volatile variables in java.desktop [v3]
In-Reply-To: <HTEWllQGW95dAuz2LclbAaQ8DJrmzjUwJVSAem3GFh4=.e0f6cac2-07b0-43df-8d0a-c99b07434530@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <HTEWllQGW95dAuz2LclbAaQ8DJrmzjUwJVSAem3GFh4=.e0f6cac2-07b0-43df-8d0a-c99b07434530@github.com>
Message-ID: <VFpOcB6a0dzCLy42Lj18VYKGpSDa9ll7E1T4fx6g6V8=.d9205ccb-0d7e-498f-9b02-6cfd1a57cd70@github.com>

On Sat, 25 Sep 2021 19:30:31 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> This is a continuation of
>> 
>> - https://bugs.openjdk.java.net/browse/JDK-6736490
>> - https://bugs.openjdk.java.net/browse/JDK-8035284
>> - https://bugs.openjdk.java.net/browse/JDK-8145680
>> - https://bugs.openjdk.java.net/browse/JDK-8251548
>> 
>> As mentioned in JDK-6736490:
>> 
>> _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._
>
> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8272756
>  - 8272756: Remove unnecessary explicit initialization of volatile fields in java.desktop
>  - 8272756: Remove unnecessary explicit initialization of volatile fields in java.desktop

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5197


From serb at openjdk.java.net  Fri Oct  8 07:49:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 8 Oct 2021 07:49:06 GMT
Subject: RFR: 8274945: Cleanup unnecessary calls to Throwable.initCause()
 in java.desktop
In-Reply-To: <9cAqNXhLLsUf-c78adEzM3ddvAOtmu--0e-ge5UHiHY=.be9e7ec9-158f-4352-8e06-1e023a5fb161@github.com>
References: <9cAqNXhLLsUf-c78adEzM3ddvAOtmu--0e-ge5UHiHY=.be9e7ec9-158f-4352-8e06-1e023a5fb161@github.com>
Message-ID: <WT_q4oM2A0RxUoc_9YSDwzWDfpW9rDXQ_Zl-DYkjMrs=.12c7def5-452b-479a-bc10-d42d0148dd4f@github.com>

On Thu, 7 Oct 2021 12:39:10 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Pass cause exception as constructor parameter is shorter and easier to read.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5847


From pbansal at openjdk.java.net  Fri Oct  8 07:56:09 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 8 Oct 2021 07:56:09 GMT
Subject: RFR: 8274945: Cleanup unnecessary calls to Throwable.initCause()
 in java.desktop
In-Reply-To: <9cAqNXhLLsUf-c78adEzM3ddvAOtmu--0e-ge5UHiHY=.be9e7ec9-158f-4352-8e06-1e023a5fb161@github.com>
References: <9cAqNXhLLsUf-c78adEzM3ddvAOtmu--0e-ge5UHiHY=.be9e7ec9-158f-4352-8e06-1e023a5fb161@github.com>
Message-ID: <4TM_06c0jN2oMXGYhiGaphS165bIHD4iGTsL2dSSx5A=.7236069c-4012-4ea5-9265-171878d2c910@github.com>

On Thu, 7 Oct 2021 12:39:10 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Pass cause exception as constructor parameter is shorter and easier to read.

Marked as reviewed by pbansal (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5847


From serb at openjdk.java.net  Fri Oct  8 10:32:19 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 8 Oct 2021 10:32:19 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
Message-ID: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>

In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.

It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.

Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

-------------

Commit messages:
 - Initial fix JDK-8274939

Changes: https://git.openjdk.java.net/jdk/pull/5864/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5864&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274939
  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5864.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5864/head:pull/5864

PR: https://git.openjdk.java.net/jdk/pull/5864


From alexsch at openjdk.java.net  Fri Oct  8 11:25:09 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Fri, 8 Oct 2021 11:25:09 GMT
Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app [v3]
In-Reply-To: <aUa1XLjw8b49-HzpaZAEO76vM4hAC9WR2iNjoooljmU=.3fb94a6b-2246-42d4-b87c-534ef06e6585@github.com>
References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com>
 <aUa1XLjw8b49-HzpaZAEO76vM4hAC9WR2iNjoooljmU=.3fb94a6b-2246-42d4-b87c-534ef06e6585@github.com>
Message-ID: <ognJm2TQyulEqokn9NnLXJKuZDiqSMh_oUlvnct90oY=.641f818c-feb8-4dc3-91c3-37caa5d1a3e8@github.com>

On Tue, 24 Aug 2021 15:49:00 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9.
>> 
>> Create a native macOS app from the Hello.java file, sign and run it in sandbox:
>> 
>> import javax.print.*;
>> import javax.swing.*;
>> 
>> public class Hello {
>> 
>>     public static void main(String[] args) throws Exception {
>>         SwingUtilities.invokeAndWait(() -> {
>>             boolean isSandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID") != null;
>>             PrintService defaultPrinter = PrintServiceLookup.lookupDefaultPrintService();
>>             PrintService[] services = PrintServiceLookup.lookupPrintServices(null, null);
>> 
>>             StringBuilder builder = new StringBuilder();
>>             builder.append("is sandboxed: ").append(isSandboxed).append("\n");
>>             builder.append("default printer: ").append(defaultPrinter).append("\n");
>>             int size = services.length;
>>             for (int i = 0; i < size; i++) {
>>                 builder.append("printer[").append(i).append("]=").append(services[i]).append("\n");
>>             }
>>             JOptionPane.showMessageDialog(null, builder.toString());
>>         });
>>     }
>> }
>> 
>> The signed app in sandbox shows null default printer and PrintServiceLookup.lookupPrintServices(null, null) returns "Unix Printer: lp".
>> ![PrintSandboxedApp](https://bugs.openjdk.java.net/secure/attachment/95629/PrintSandboxedApp.png)
>> 
>> The problem has been discussed on  2d-dev mail list:
>>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-June/008375.html
>>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-July/008418.html
>> 
>> According to the discussion:
>> 
>>> I've submitted a DTS incident to Apple and a friend there has followed-up.
>>> Their unofficial position is that java should be connecting to the cups interface returned
>>> by the cupsServer() function and not changing the interface string to "localhost".
>>> Security changes in 10.12.4 reject the TCP connection which they say confuses
>>> network-client access with print access.  They don't seem interested in loosening that change.
>> 
>> 
>> The proposed solution is to use the domain socket pathname in httpConnect(...) cups function and cupsGetDests(...) to get list of printers from cups  when the app is signed and is run in sandbox on MacOs.
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Return null if printers are not found in sandboxed app on MacOS

Just some more details about code in CUPSPrinter class static initialization.

The getCupsServer() native method from CUPSPrinter calls j2d_cupsServer() function to get the cups server. If the server name starts with "/" it is replaced to "localhost"
https://github.com/openjdk/jdk/blob/f608e81ad8309a001b8a92563a93b8adee1ce2b8/src/java.desktop/unix/native/common/awt/CUPSfuncs.c#L176

To keep the domain socket path name from j2d_cupsServer() call the fix moves the cups server name handling to the java side. The original domain socket path name is preserved in the  CUPSPrinter class only for MacOS when sandboxed app is used.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4861


From pbansal at openjdk.java.net  Fri Oct  8 12:58:36 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 8 Oct 2021 12:58:36 GMT
Subject: RFR: 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged()
 returns leftButton and rightButton as null with GTKLookAndFeel [v4]
In-Reply-To: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
Message-ID: <H_ogltJEJFItmAH0Up68odTGAY7AeRcQNH2omo57Zfk=.f3834668-c042-498e-ac58-c87d80d3133f@github.com>

> The function documentation for oneTouchExpandableChanged states that the function does couple of things, but in reality  it only does those things if the Look and Feel supports the supportsOneTouchButtons. In case the Look and Feel does not support supportsOneTouchButtons, this functions just returns in beginning and does not do anything.
> This change clarifies the above in function documentation.

Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5263/files
  - new: https://git.openjdk.java.net/jdk/pull/5263/files/d48ff5c8..2f7a612a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5263&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5263&range=02-03

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5263.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5263/head:pull/5263

PR: https://git.openjdk.java.net/jdk/pull/5263


From pbansal at openjdk.java.net  Fri Oct  8 13:05:34 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 8 Oct 2021 13:05:34 GMT
Subject: RFR: 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged()
 returns leftButton and rightButton as null with GTKLookAndFeel [v5]
In-Reply-To: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
Message-ID: <nX3uKbltg1SyBa3rcXp25q4oHwkE8di3HkEvXM6qDUY=.460dc57a-baa9-4496-95d2-d2c483923a3f@github.com>

> The function documentation for oneTouchExpandableChanged states that the function does couple of things, but in reality  it only does those things if the Look and Feel supports the supportsOneTouchButtons. In case the Look and Feel does not support supportsOneTouchButtons, this functions just returns in beginning and does not do anything.
> This change clarifies the above in function documentation.

Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:

  Review Comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5263/files
  - new: https://git.openjdk.java.net/jdk/pull/5263/files/2f7a612a..4a0ad2a2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5263&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5263&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5263.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5263/head:pull/5263

PR: https://git.openjdk.java.net/jdk/pull/5263


From pbansal at openjdk.java.net  Fri Oct  8 13:05:36 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 8 Oct 2021 13:05:36 GMT
Subject: RFR: 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged()
 returns leftButton and rightButton as null with GTKLookAndFeel [v3]
In-Reply-To: <DGSOwFul0Xhfu47cqD6VMTlbigvNfAZJ6ePGoJ3ve3I=.2271c461-0e1e-4e08-8ca9-ec87eaccffaa@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
 <gn3LMUUrEY_c2nN80EtPV17dp4EngVkxIRghNQPmfkE=.37d5ff5e-2dd1-406c-995d-b40e3bb9c0bc@github.com>
 <DGSOwFul0Xhfu47cqD6VMTlbigvNfAZJ6ePGoJ3ve3I=.2271c461-0e1e-4e08-8ca9-ec87eaccffaa@github.com>
Message-ID: <-UHzn2SsyJZERA1awE4NQga-YlraZpfH9o7o6aMLeQM=.de93df31-4eae-4765-a867-fefc58177210@github.com>

On Tue, 5 Oct 2021 09:26:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes according to JBS discussion
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java line 379:
> 
>> 377:     /**
>> 378:      * Messaged when the oneTouchExpandable value of the JSplitPane the
>> 379:      * divider is contained in changes. Will create the
> 
> I guess "value of the current JSplitPane divider" makes more sense. 
> Also, I guess leftButton,rightButton wll be created not only if they are null but also when oneTouchExpandable property is set as per code..It might seem to user from current wording that left/right button will be set if they are null even if oneTouchExpandable is not set.

I have addressed the review comments. @prsadhuk  I have not changed the first line as the property change is of JSplitPane not divider. So "value of the current JSplitPane divider changes" will be wrong. It is "value of JSplitpane the divider is contained in changes". All other comments are addressed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5263


From jdv at openjdk.java.net  Fri Oct  8 14:13:16 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Fri, 8 Oct 2021 14:13:16 GMT
Subject: RFR: 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged()
 returns leftButton and rightButton as null with GTKLookAndFeel [v5]
In-Reply-To: <nX3uKbltg1SyBa3rcXp25q4oHwkE8di3HkEvXM6qDUY=.460dc57a-baa9-4496-95d2-d2c483923a3f@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
 <nX3uKbltg1SyBa3rcXp25q4oHwkE8di3HkEvXM6qDUY=.460dc57a-baa9-4496-95d2-d2c483923a3f@github.com>
Message-ID: <1Dt7NxRTI3jp3sgibjUmjHKQhRY9XtgS-OQgXZIgnxk=.462e7164-6d89-4e67-8b0f-cabff4d48781@github.com>

On Fri, 8 Oct 2021 13:05:34 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> The function documentation for oneTouchExpandableChanged states that the function does couple of things, but in reality  it only does those things if the Look and Feel supports the supportsOneTouchButtons. In case the Look and Feel does not support supportsOneTouchButtons, this functions just returns in beginning and does not do anything.
>> This change clarifies the above in function documentation.
>
> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comment

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5263


From mbaesken at openjdk.java.net  Fri Oct  8 14:33:17 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 8 Oct 2021 14:33:17 GMT
Subject: RFR: JDK-8274977: Remove expandPacked and extendEdge from
 awt_ImagingLib.c
Message-ID: <1tSvf8JjhHG7crHsLOqHpNOsCcBziywqBBG6Q4SgYZk=.fec63717-09a4-4812-8e30-bdf86536cf4c@github.com>

Please review this small cleanup change.
Looks like expandPacked and extendEdge from awt_ImagingLib.c are unreferenced/unused and can be removed.

Thanks, Matthias

-------------

Commit messages:
 - JDK-8274977

Changes: https://git.openjdk.java.net/jdk/pull/5866/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5866&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274977
  Stats: 85 lines in 1 file changed: 0 ins; 84 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5866.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5866/head:pull/5866

PR: https://git.openjdk.java.net/jdk/pull/5866


From aivanov at openjdk.java.net  Fri Oct  8 15:33:14 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 8 Oct 2021 15:33:14 GMT
Subject: RFR: 8272756: Remove unnecessary explicit initialization of
 volatile variables in java.desktop [v3]
In-Reply-To: <HTEWllQGW95dAuz2LclbAaQ8DJrmzjUwJVSAem3GFh4=.e0f6cac2-07b0-43df-8d0a-c99b07434530@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <HTEWllQGW95dAuz2LclbAaQ8DJrmzjUwJVSAem3GFh4=.e0f6cac2-07b0-43df-8d0a-c99b07434530@github.com>
Message-ID: <V_VGqFcYAVr-15-Qwr8sUNUDjwJSPWV9f442MsUTLec=.e31a0eeb-8dc3-468f-ae66-a773161b8fab@github.com>

On Sat, 25 Sep 2021 19:30:31 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> This is a continuation of
>> 
>> - https://bugs.openjdk.java.net/browse/JDK-6736490
>> - https://bugs.openjdk.java.net/browse/JDK-8035284
>> - https://bugs.openjdk.java.net/browse/JDK-8145680
>> - https://bugs.openjdk.java.net/browse/JDK-8251548
>> 
>> As mentioned in JDK-6736490:
>> 
>> _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._
>
> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8272756
>  - 8272756: Remove unnecessary explicit initialization of volatile fields in java.desktop
>  - 8272756: Remove unnecessary explicit initialization of volatile fields in java.desktop

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5197


From github.com+90066231+alisenchung at openjdk.java.net  Fri Oct  8 15:44:09 2021
From: github.com+90066231+alisenchung at openjdk.java.net (Alisen Chung)
Date: Fri, 8 Oct 2021 15:44:09 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v9]
In-Reply-To: <BUO3yGBz6ja11UoRUArVDYvB1zgXtEELEV1U7wYCFvA=.42ad2406-3f2a-40d5-ab2c-aa617548264c@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <BUO3yGBz6ja11UoRUArVDYvB1zgXtEELEV1U7wYCFvA=.42ad2406-3f2a-40d5-ab2c-aa617548264c@github.com>
Message-ID: <z-TZZpb0Jct_6ttpuHvkrXnVL3JMhMhuZp62dzP-XgE=.1be31b5b-89dd-4950-97c5-90c35826b872@github.com>

On Fri, 1 Oct 2021 22:28:10 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

>> Added a resizing flag when the window is currently being resized to block mouseEntered and mouseExited events from being posted to that window.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed synthesizeMouseEnteredExitEvent call

> > I think mouseEvents are already posted by macos when the mouse enters the window thru fullscreen-resizing (green button) or tiling, so I think we don't need to synthesize additional events.
> 
> If we do not need to synthesize additional events then why do you see a difference in behavior before/after the fix here: [#5497 (comment)](https://github.com/openjdk/jdk/pull/5497#issuecomment-930588684) ?

The case I tested is supposed to be covered by windowDidEnterFullscreen. Also it passed when I tested it manually, but only the automatic test has different behavior..
 
> > I suggest we remove the line because it introduces another bug where dragging to move the window will post a mouseEntered event without the mouse ever entering the actual window. It also introduces the bug from the original bug report.
> 
> But we should not introduce the new one.

I meant that by removing the line 2 different bugs are fixed

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From github.com+10835776+stsypanov at openjdk.java.net  Fri Oct  8 16:04:11 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 8 Oct 2021 16:04:11 GMT
Subject: Integrated: 8272756: Remove unnecessary explicit initialization of
 volatile variables in java.desktop
In-Reply-To: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
Message-ID: <OHNnhxXi8nN1NfL14aXHwo37nVvPTXHhjPM3TRUTJmE=.a257f8f0-fade-452d-961d-a90dec733f3a@github.com>

On Fri, 20 Aug 2021 09:41:15 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> This is a continuation of
> 
> - https://bugs.openjdk.java.net/browse/JDK-6736490
> - https://bugs.openjdk.java.net/browse/JDK-8035284
> - https://bugs.openjdk.java.net/browse/JDK-8145680
> - https://bugs.openjdk.java.net/browse/JDK-8251548
> 
> As mentioned in JDK-6736490:
> 
> _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._

This pull request has now been integrated.

Changeset: ccbce107
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ccbce107f299c3b1c444e819c1fda7ae3c4866b5
Stats:     54 lines in 28 files changed: 0 ins; 0 del; 54 mod

8272756: Remove unnecessary explicit initialization of volatile variables in java.desktop

Reviewed-by: jdv, aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/5197


From serb at openjdk.java.net  Fri Oct  8 18:39:12 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 8 Oct 2021 18:39:12 GMT
Subject: RFR: 8272756: Remove unnecessary explicit initialization of
 volatile variables in java.desktop [v3]
In-Reply-To: <gnl7URRoEcqD7Dnb2-LkT6wucR7OH1eHY5ICtupHuoM=.56c7a040-fb9b-403e-ba3c-aeb83e847d4a@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com>
 <umwDn9Nke1Bnse87ZiQp9k_MyZDXpO45YUFtEXnFU80=.92a2b18b-f32d-4201-94ff-4c75b20e7bd8@github.com>
 <QeTE-KIuatog_Q5dU4BCp8u-U3HarxmHCSfw9uvyEd4=.0ea2627a-d2d5-4185-92cd-2069d9bb3f91@github.com>
 <aQwgzJ4B4oswyjPwlUna8_ccoFwQsnwtUz9TgUCxVmg=.7802c612-eb73-4b5d-b512-6fa6f829cebc@github.com>
 <xVBLj997Laf-N2IwD8dfI2bzfHvtV1P2ji63kXcc10g=.7127c961-2ddb-49e7-a565-4c3351303952@github.com>
 <gnl7URRoEcqD7Dnb2-LkT6wucR7OH1eHY5ICtupHuoM=.56c7a040-fb9b-403e-ba3c-aeb83e847d4a@github.com>
Message-ID: <B8NjgmYChCnd0bMEQtUU9bgbiTMFhnAKfCNuG2KjKsI=.d52f9e1d-ccdc-4385-b20f-bf8549b62102@github.com>

On Sun, 26 Sep 2021 20:57:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Agree.
>
> I still suggest to remove the local tag completely.

@jayathirthrao @stsypanov  Looks like this was not addressed?  It will be good to include it in some future cleanup.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5197


From aivanov at openjdk.java.net  Fri Oct  8 18:50:12 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 8 Oct 2021 18:50:12 GMT
Subject: RFR: 8272756: Remove unnecessary explicit initialization of
 volatile variables in java.desktop [v3]
In-Reply-To: <B8NjgmYChCnd0bMEQtUU9bgbiTMFhnAKfCNuG2KjKsI=.d52f9e1d-ccdc-4385-b20f-bf8549b62102@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com>
 <umwDn9Nke1Bnse87ZiQp9k_MyZDXpO45YUFtEXnFU80=.92a2b18b-f32d-4201-94ff-4c75b20e7bd8@github.com>
 <QeTE-KIuatog_Q5dU4BCp8u-U3HarxmHCSfw9uvyEd4=.0ea2627a-d2d5-4185-92cd-2069d9bb3f91@github.com>
 <aQwgzJ4B4oswyjPwlUna8_ccoFwQsnwtUz9TgUCxVmg=.7802c612-eb73-4b5d-b512-6fa6f829cebc@github.com>
 <xVBLj997Laf-N2IwD8dfI2bzfHvtV1P2ji63kXcc10g=.7127c961-2ddb-49e7-a565-4c3351303952@github.com>
 <gnl7URRoEcqD7Dnb2-LkT6wucR7OH1eHY5ICtupHuoM=.56c7a040-fb9b-403e-ba3c-aeb83e847d4a@github.com>
 <B8NjgmYChCnd0bMEQtUU9bgbiTMFhnAKfCNuG2KjKsI=.d52f9e1d-ccdc-4385-b20f-bf8549b62102@github.com>
Message-ID: <m8Ld3F0yc15DfH7wheZmF_UwhlA-AYEoUlK2om3VslE=.7e7667a9-d23f-4d2d-9866-bdc2b70a9d9a@github.com>

On Fri, 8 Oct 2021 18:35:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I still suggest to remove the local tag completely.
>
> @jayathirthrao @stsypanov  Looks like this was not addressed?  It will be good to include it in some future cleanup.

As far as I can see, it was. [Line 64](https://github.com/stsypanov/jdk/blob/d13ca9004b8e45f7df57c849271f3cfda5c43ec9/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java#L64):

            essentialTags = Set.of(


And it shows as such in [the diff of the commit](https://github.com/openjdk/jdk/commit/ccbce107f299c3b1c444e819c1fda7ae3c4866b5#diff-054fa06ac6a28817c38d879245a8490f22789d7c93d51b723c08616e154746c9).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5197


From serb at openjdk.java.net  Fri Oct  8 19:14:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 8 Oct 2021 19:14:08 GMT
Subject: RFR: 8254841: [macos] Enter and Exit events shouldn't be sent
 whilst resizing [v9]
In-Reply-To: <z-TZZpb0Jct_6ttpuHvkrXnVL3JMhMhuZp62dzP-XgE=.1be31b5b-89dd-4950-97c5-90c35826b872@github.com>
References: <lG9R8wX_Gwu_QibtJteuqEEgOW3lw4CxFIcmEQ8ZaNo=.74301d0c-f63a-4b6e-93c2-389eb5453d5b@github.com>
 <BUO3yGBz6ja11UoRUArVDYvB1zgXtEELEV1U7wYCFvA=.42ad2406-3f2a-40d5-ab2c-aa617548264c@github.com>
 <z-TZZpb0Jct_6ttpuHvkrXnVL3JMhMhuZp62dzP-XgE=.1be31b5b-89dd-4950-97c5-90c35826b872@github.com>
Message-ID: <tlMNi29sP3Q298gTT5ofPuyJxDq-oIVl-M7gC4WJ8RQ=.6bc6f50f-da20-4c6e-9a2e-c97a8bc39e6b@github.com>

On Fri, 8 Oct 2021 15:41:25 GMT, Alisen Chung <github.com+90066231+alisenchung at openjdk.org> wrote:

> > If we do not need to synthesize additional events then why do you see a difference in behavior before/after the fix here: [#5497 (comment)](https://github.com/openjdk/jdk/pull/5497#issuecomment-930588684) ?
> 
> The case I tested is supposed to be covered by windowDidEnterFullscreen. Also it passed when I tested it manually, but only the automatic test has different behavior..

The windowDidEnterFullscreen is called before and after the fix, so If automatic test has a different behaviour means that the current change affects it in some unclear way, right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5497


From serb at openjdk.java.net  Fri Oct  8 19:19:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 8 Oct 2021 19:19:09 GMT
Subject: RFR: 8272756: Remove unnecessary explicit initialization of
 volatile variables in java.desktop [v3]
In-Reply-To: <m8Ld3F0yc15DfH7wheZmF_UwhlA-AYEoUlK2om3VslE=.7e7667a9-d23f-4d2d-9866-bdc2b70a9d9a@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com>
 <umwDn9Nke1Bnse87ZiQp9k_MyZDXpO45YUFtEXnFU80=.92a2b18b-f32d-4201-94ff-4c75b20e7bd8@github.com>
 <QeTE-KIuatog_Q5dU4BCp8u-U3HarxmHCSfw9uvyEd4=.0ea2627a-d2d5-4185-92cd-2069d9bb3f91@github.com>
 <aQwgzJ4B4oswyjPwlUna8_ccoFwQsnwtUz9TgUCxVmg=.7802c612-eb73-4b5d-b512-6fa6f829cebc@github.com>
 <xVBLj997Laf-N2IwD8dfI2bzfHvtV1P2ji63kXcc10g=.7127c961-2ddb-49e7-a565-4c3351303952@github.com>
 <gnl7URRoEcqD7Dnb2-LkT6wucR7OH1eHY5ICtupHuoM=.56c7a040-fb9b-403e-ba3c-aeb83e847d4a@github.com>
 <B8NjgmYChCnd0bMEQtUU9bgbiTMFhnAKfCNuG2KjKsI=.d52f9e1d-ccdc-4385-b20f-bf8549b62102@github.com>
 <m8Ld3F0yc15DfH7wheZmF_UwhlA-AYEoUlK2om3VslE=.7e7667a9-d23f-4d2d-9866-bdc2b70a9d9a@github.com>
Message-ID: <DpKpLN_GnVBgAEXzGxYPIkV99DoL69P0lt6g4dT00aY=.4f65db56-c665-46ec-a566-c604cef46e2f@github.com>

On Fri, 8 Oct 2021 18:44:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @jayathirthrao @stsypanov  Looks like this was not addressed?  It will be good to include it in some future cleanup.
>
> As far as I can see, it was. [Line 64](https://github.com/stsypanov/jdk/blob/d13ca9004b8e45f7df57c849271f3cfda5c43ec9/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java#L64):
> 
>             essentialTags = Set.of(
> 
> 
> And it shows as such in [the diff of the commit](https://github.com/openjdk/jdk/commit/ccbce107f299c3b1c444e819c1fda7ae3c4866b5#diff-054fa06ac6a28817c38d879245a8490f22789d7c93d51b723c08616e154746c9).

That was the usage of the local var, the current thread was about the local var itself, it is still there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5197


From aivanov at openjdk.java.net  Fri Oct  8 19:23:13 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 8 Oct 2021 19:23:13 GMT
Subject: RFR: 8272756: Remove unnecessary explicit initialization of
 volatile variables in java.desktop [v3]
In-Reply-To: <DpKpLN_GnVBgAEXzGxYPIkV99DoL69P0lt6g4dT00aY=.4f65db56-c665-46ec-a566-c604cef46e2f@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com>
 <umwDn9Nke1Bnse87ZiQp9k_MyZDXpO45YUFtEXnFU80=.92a2b18b-f32d-4201-94ff-4c75b20e7bd8@github.com>
 <QeTE-KIuatog_Q5dU4BCp8u-U3HarxmHCSfw9uvyEd4=.0ea2627a-d2d5-4185-92cd-2069d9bb3f91@github.com>
 <aQwgzJ4B4oswyjPwlUna8_ccoFwQsnwtUz9TgUCxVmg=.7802c612-eb73-4b5d-b512-6fa6f829cebc@github.com>
 <xVBLj997Laf-N2IwD8dfI2bzfHvtV1P2ji63kXcc10g=.7127c961-2ddb-49e7-a565-4c3351303952@github.com>
 <gnl7URRoEcqD7Dnb2-LkT6wucR7OH1eHY5ICtupHuoM=.56c7a040-fb9b-403e-ba3c-aeb83e847d4a@github.com>
 <B8NjgmYChCnd0bMEQtUU9bgbiTMFhnAKfCNuG2KjKsI=.d52f9e1d-ccdc-4385-b20f-bf8549b62102@github.com>
 <m8Ld3F0yc15DfH7wheZmF_UwhlA-AYEoUlK2om3VslE=.7e7667a9-d23f-4d2d-9866-bdc2b70a9d9a@github.com>
 <DpKpLN_GnVBgAEXzGxYPIkV99DoL69P0lt6g4dT00aY=.4f65db56-c665-46ec-a566-c604cef46e2f@github.com>
Message-ID: <2v7DaFfR7eyYtloWn6AnUerhe6bwgneHMPiSc2NFRwI=.57d7bad5-78ae-44db-afcc-0e65786b52cc@github.com>

On Fri, 8 Oct 2021 19:15:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> As far as I can see, it was. [Line 64](https://github.com/stsypanov/jdk/blob/d13ca9004b8e45f7df57c849271f3cfda5c43ec9/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java#L64):
>> 
>>             essentialTags = Set.of(
>> 
>> 
>> And it shows as such in [the diff of the commit](https://github.com/openjdk/jdk/commit/ccbce107f299c3b1c444e819c1fda7ae3c4866b5#diff-054fa06ac6a28817c38d879245a8490f22789d7c93d51b723c08616e154746c9).
>
> That was the usage of the local var, the current thread was about the local var itself, it is still there.

Good catch!
I missed that the local variable is still there and now it's unused, so an IDE should issue a warning about it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5197


From pbansal at openjdk.java.net  Fri Oct  8 19:38:08 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 8 Oct 2021 19:38:08 GMT
Subject: RFR: 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged()
 returns leftButton and rightButton as null with GTKLookAndFeel
In-Reply-To: <bIp9wRw-hW7IMoPvO2KtZud5c65Jq0cGPEKdLamS_0w=.e8ed72f9-b889-45c8-8fa3-2baac947ad7a@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
 <bIp9wRw-hW7IMoPvO2KtZud5c65Jq0cGPEKdLamS_0w=.e8ed72f9-b889-45c8-8fa3-2baac947ad7a@github.com>
Message-ID: <6RKaTy31VtYzGOKeuaaFFue_pQ8jGuEgVMz4fpzCYKA=.e644a6f4-bf8b-4c40-966b-87b42951b9fe@github.com>

On Thu, 26 Aug 2021 22:10:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The function documentation for oneTouchExpandableChanged states that the function does couple of things, but in reality  it only does those things if the Look and Feel supports the supportsOneTouchButtons. In case the Look and Feel does not support supportsOneTouchButtons, this functions just returns in beginning and does not do anything.
>> This change clarifies the above in function documentation.
>
> I think that the current test case is wrong, the oneTouchExpandableChanged() should not be called directly, only when the "oneTouchExpandable" property is changed.
> 
> So to consider this as a bug the test should trigger the call to the oneTouchExpandableChanged() as a result of the " oneTouchExpandable value change" and then validate the state of the buttons.

@mrserb Would you like to have a look at the new version as some small changes have been made since you approved this PR? Or I should just integrate the PR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5263


From github.com+10835776+stsypanov at openjdk.java.net  Fri Oct  8 19:42:07 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 8 Oct 2021 19:42:07 GMT
Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules
In-Reply-To: <mzVeRcWIXkzXKXQsKh-lhT74R7J3XixXSvGBtKqByrQ=.c6f98337-7cf7-4628-9be2-f720f7717147@github.com>
References: <mzVeRcWIXkzXKXQsKh-lhT74R7J3XixXSvGBtKqByrQ=.c6f98337-7cf7-4628-9be2-f720f7717147@github.com>
Message-ID: <kJSFz5tKeUoknBevSYfXLoNcF3QfAp8ZI3PBXi0k-1w=.a0190ba2-4a42-4fb4-ab95-9ee5a977b865@github.com>

On Thu, 9 Sep 2021 06:53:13 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance

src/jdk.jpackage/share/classes/jdk/jpackage/internal/Log.java line 117:

> 115: 
> 116:                 for (String s : strings) {
> 117:                     sb.append(" " + s);

Shouldn't it be `sb.append(" ").append(s)`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5433


From serb at openjdk.java.net  Fri Oct  8 20:01:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 8 Oct 2021 20:01:09 GMT
Subject: RFR: 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged()
 returns leftButton and rightButton as null with GTKLookAndFeel [v5]
In-Reply-To: <nX3uKbltg1SyBa3rcXp25q4oHwkE8di3HkEvXM6qDUY=.460dc57a-baa9-4496-95d2-d2c483923a3f@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
 <nX3uKbltg1SyBa3rcXp25q4oHwkE8di3HkEvXM6qDUY=.460dc57a-baa9-4496-95d2-d2c483923a3f@github.com>
Message-ID: <zxuaeIENRve-RFtKU78VQIgGq3_88PUYUElg0lHKrRQ=.8243961d-de2f-44c3-8ffe-8f8c98cd5f97@github.com>

On Fri, 8 Oct 2021 13:05:34 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> The function documentation for oneTouchExpandableChanged states that the function does couple of things, but in reality  it only does those things if the Look and Feel supports the supportsOneTouchButtons. In case the Look and Feel does not support supportsOneTouchButtons, this functions just returns in beginning and does not do anything.
>> This change clarifies the above in function documentation.
>
> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comment

Marked as reviewed by serb (Reviewer).

New version looks fine

-------------

PR: https://git.openjdk.java.net/jdk/pull/5263


From github.com+741251+turbanoff at openjdk.java.net  Sat Oct  9 00:49:11 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sat, 9 Oct 2021 00:49:11 GMT
Subject: Integrated: 8274806: Simplify equals() call on nullable variable and
 a constant in java.desktop
In-Reply-To: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>
References: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>
Message-ID: <xC3oYKIv5AdzbiIwvvSWHwe3Q-eS7ErtOE2OAGtFLf0=.788e3a6e-d3bb-4b05-9cd3-d7f0223fd233@github.com>

On Sat, 2 Oct 2021 09:14:49 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Flipping arguments of 'equals' method, allows simplifying boolean expressions: now we can remove redundant null check before.

This pull request has now been integrated.

Changeset: f640c7aa
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f640c7aaa852b6c0e9144654b7222a6777201370
Stats:     17 lines in 11 files changed: 0 ins; 1 del; 16 mod

8274806: Simplify equals() call on nullable variable and a constant in java.desktop

Reviewed-by: serb, pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/5794


From kizune at openjdk.java.net  Sat Oct  9 03:23:09 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 9 Oct 2021 03:23:09 GMT
Subject: RFR: 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged()
 returns leftButton and rightButton as null with GTKLookAndFeel [v5]
In-Reply-To: <nX3uKbltg1SyBa3rcXp25q4oHwkE8di3HkEvXM6qDUY=.460dc57a-baa9-4496-95d2-d2c483923a3f@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
 <nX3uKbltg1SyBa3rcXp25q4oHwkE8di3HkEvXM6qDUY=.460dc57a-baa9-4496-95d2-d2c483923a3f@github.com>
Message-ID: <DKRjwdFHNU7OfucGxJuBLXStQg8fqbFDnOTyW4fvlo8=.ddf03b4e-db94-497f-9e73-81adc5fee5cb@github.com>

On Fri, 8 Oct 2021 13:05:34 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> The function documentation for oneTouchExpandableChanged states that the function does couple of things, but in reality  it only does those things if the Look and Feel supports the supportsOneTouchButtons. In case the Look and Feel does not support supportsOneTouchButtons, this functions just returns in beginning and does not do anything.
>> This change clarifies the above in function documentation.
>
> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comment

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5263


From pbansal at openjdk.java.net  Sat Oct  9 03:57:08 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sat, 9 Oct 2021 03:57:08 GMT
Subject: Integrated: 8272229:
 BasicSplitPaneDivider:oneTouchExpandableChanged() returns leftButton and
 rightButton as null with GTKLookAndFeel
In-Reply-To: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
Message-ID: <3qgLZ8bdu9pVK9GL0WEcBgHonQGEGUPpYnoCc52pFgs=.5bcee16e-6d5a-48ed-a6e0-1ff0d44186e1@github.com>

On Thu, 26 Aug 2021 07:18:43 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> The function documentation for oneTouchExpandableChanged states that the function does couple of things, but in reality  it only does those things if the Look and Feel supports the supportsOneTouchButtons. In case the Look and Feel does not support supportsOneTouchButtons, this functions just returns in beginning and does not do anything.
> This change clarifies the above in function documentation.

This pull request has now been integrated.

Changeset: aac6c4ea
Author:    Pankaj Bansal <pbansal at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/aac6c4ea707fa592b2bcd7586c1fe61a19e3725e
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8272229: BasicSplitPaneDivider:oneTouchExpandableChanged() returns leftButton and rightButton as null with GTKLookAndFeel

Reviewed-by: serb, jdv, kizune

-------------

PR: https://git.openjdk.java.net/jdk/pull/5263


From azvegint at openjdk.java.net  Sat Oct  9 11:16:29 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Sat, 9 Oct 2021 11:16:29 GMT
Subject: RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing [v2]
In-Reply-To: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
Message-ID: <3ImBG1zONPFt9j_xXbC2ha49uVBoqTZwfUBXP_TQCLI=.91448fe7-a57f-4600-8c7f-ce32c08e42d1@github.com>

> This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  throw exceptions instead of doc change

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5806/files
  - new: https://git.openjdk.java.net/jdk/pull/5806/files/9bf48ed6..6f6f2680

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5806&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5806&range=00-01

  Stats: 17 lines in 1 file changed: 11 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5806.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5806/head:pull/5806

PR: https://git.openjdk.java.net/jdk/pull/5806


From azvegint at openjdk.java.net  Sat Oct  9 12:02:07 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Sat, 9 Oct 2021 12:02:07 GMT
Subject: RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing
In-Reply-To: <EbfOB5mmFL1ZgltetdXtwRmaRAWRuX7DwA8Ht0HkNyU=.19467570-ac50-4548-aa60-1755a3c44768@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
 <EbfOB5mmFL1ZgltetdXtwRmaRAWRuX7DwA8Ht0HkNyU=.19467570-ac50-4548-aa60-1755a3c44768@github.com>
Message-ID: <zKbRas8EklJKWdoSQiXw_uKTgih6M6U-_x8mAmB2Ftk=.7a32d45b-c6c8-4ccc-84cf-5deda5ec056f@github.com>

On Fri, 8 Oct 2021 00:16:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I am fine with any solution but think the check will be simpler and safer, and later we will be able to change the behavior of some of these methods if it will be needed.

Makes sense. Testing is green with last code changes.
CSR label will be removed once we agreed on this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5806


From github.com+741251+turbanoff at openjdk.java.net  Sun Oct 10 08:45:11 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 10 Oct 2021 08:45:11 GMT
Subject: Integrated: 8274882: Cleanup redundant boxing in java.desktop
In-Reply-To: <dZULF4WEflGF9TNi85mG3QnmXayrHzuhzgk6MdsnufY=.4053c03a-d1ad-4db1-9c00-5dd7a15562d1@github.com>
References: <dZULF4WEflGF9TNi85mG3QnmXayrHzuhzgk6MdsnufY=.4053c03a-d1ad-4db1-9c00-5dd7a15562d1@github.com>
Message-ID: <1-X-ykimnXza1LBDsFFq89JSiMlR7nb2Dxi5ru7wPDc=.86ed7499-40fd-4101-bd22-6dd2fa5521cb@github.com>

On Wed, 6 Oct 2021 07:29:51 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I missed a few places in https://bugs.openjdk.java.net/browse/JDK-8273168

This pull request has now been integrated.

Changeset: 2c83559e
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2c83559eda410d268c6d8a56d7fd1c34f817cb83
Stats:     18 lines in 9 files changed: 0 ins; 3 del; 15 mod

8274882: Cleanup redundant boxing in java.desktop

Reviewed-by: serb, pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/5834


From github.com+87324768+lawrence-andrew at openjdk.java.net  Sun Oct 10 08:49:16 2021
From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews)
Date: Sun, 10 Oct 2021 08:49:16 GMT
Subject: Integrated: 8274029 : Remove jtreg tag manual=yesno for
 java/awt/print/Dialog/DialogOrient.java
In-Reply-To: <Ro_fn0IJMpEylrSDc18KA2ja2kqn9pXV2VGJVNYILBw=.32f3e969-5ea3-4739-81dc-84199b86ab50@github.com>
References: <Ro_fn0IJMpEylrSDc18KA2ja2kqn9pXV2VGJVNYILBw=.32f3e969-5ea3-4739-81dc-84199b86ab50@github.com>
Message-ID: <1aj0xaB-SM1kvUou19TwVmBBLbto4YpEsPjCT2IlHok=.af438fc3-f7fb-4b60-a2f6-1541bdcc3db4@github.com>

On Mon, 20 Sep 2021 21:36:34 GMT, lawrence.andrews <github.com+87324768+lawrence-andrew at openjdk.org> wrote:

> Problem : Testcase was failing with parser exception 
> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno 
> Fix : Removed =yesno and run the testcase and Test UI ( instruction and print dialog ) is visible
> 
> @shurymury

This pull request has now been integrated.

Changeset: 296f8537
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/296f8537f71b84f194cf2718ac9b85ba6843cfa3
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8274029: Remove jtreg tag manual=yesno for java/awt/print/Dialog/DialogOrient.java

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/5589


From avu at openjdk.java.net  Sun Oct 10 18:34:16 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Sun, 10 Oct 2021 18:34:16 GMT
Subject: RFR: JDK-8272392 Lanai: SwingSet2. Black background on expanding tree
 node
Message-ID: <TQsP5ddyfnqWKK4YVlTwqErFXRjdFGvfKhVuhbr9vQc=.0f9a0b06-696b-4fdf-95a2-a38e23f38408@github.com>

Handled SRC composite mode in MTLBlitLoops_IsoBlit

-------------

Commit messages:
 - JDK-8272392 Lanai: SwingSet2. Black background on expanding tree node

Changes: https://git.openjdk.java.net/jdk/pull/5882/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5882&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272392
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5882.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5882/head:pull/5882

PR: https://git.openjdk.java.net/jdk/pull/5882


From serb at openjdk.java.net  Sun Oct 10 20:26:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 10 Oct 2021 20:26:05 GMT
Subject: RFR: JDK-8274977: Remove expandPacked and extendEdge from
 awt_ImagingLib.c
In-Reply-To: <1tSvf8JjhHG7crHsLOqHpNOsCcBziywqBBG6Q4SgYZk=.fec63717-09a4-4812-8e30-bdf86536cf4c@github.com>
References: <1tSvf8JjhHG7crHsLOqHpNOsCcBziywqBBG6Q4SgYZk=.fec63717-09a4-4812-8e30-bdf86536cf4c@github.com>
Message-ID: <-7xrzAzkvYf5f70f2Ihd7pp0NNbGrEAPJPzibJXgWrs=.12350f0f-3f7c-42cf-9253-4b08549d6b9a@github.com>

On Fri, 8 Oct 2021 14:25:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small cleanup change.
> Looks like expandPacked and extendEdge from awt_ImagingLib.c are unreferenced/unused and can be removed.
> 
> Thanks, Matthias

Are you sure that these library methods are dead code and cannot be reused for some use-cases? As far as I underst5and the comment in the "allocateArray" the implementation of "edges" was a work in progress.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5866


From serb at openjdk.java.net  Sun Oct 10 22:10:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 10 Oct 2021 22:10:10 GMT
Subject: RFR: JDK-8272392 Lanai: SwingSet2. Black background on expanding
 tree node
In-Reply-To: <TQsP5ddyfnqWKK4YVlTwqErFXRjdFGvfKhVuhbr9vQc=.0f9a0b06-696b-4fdf-95a2-a38e23f38408@github.com>
References: <TQsP5ddyfnqWKK4YVlTwqErFXRjdFGvfKhVuhbr9vQc=.0f9a0b06-696b-4fdf-95a2-a38e23f38408@github.com>
Message-ID: <7R6YWmG28TMMIH3CRkmbILd7S3OaCxUcANLZjHZm9rk=.62c993bd-4db9-4f6e-a352-10134e4a6c4c@github.com>

On Sun, 10 Oct 2021 18:26:13 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Handled SRC composite mode in MTLBlitLoops_IsoBlit

Can we add an automated test for this use case?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5882


From avu at openjdk.java.net  Mon Oct 11 06:04:10 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 11 Oct 2021 06:04:10 GMT
Subject: RFR: JDK-8272392 Lanai: SwingSet2. Black background on expanding
 tree node
In-Reply-To: <TQsP5ddyfnqWKK4YVlTwqErFXRjdFGvfKhVuhbr9vQc=.0f9a0b06-696b-4fdf-95a2-a38e23f38408@github.com>
References: <TQsP5ddyfnqWKK4YVlTwqErFXRjdFGvfKhVuhbr9vQc=.0f9a0b06-696b-4fdf-95a2-a38e23f38408@github.com>
Message-ID: <Rna_cvKQa5t3ipS6Q7m-bHQ5TOae9JWoKkxLLS4RUDI=.dc21ea45-45e0-4fa4-bfaf-c6cfa4c66b68@github.com>

On Sun, 10 Oct 2021 18:26:13 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Handled SRC composite mode in MTLBlitLoops_IsoBlit

I thought about the test in the context of this particular bug - where we face garbage in VRAM and decided that the test would be not reliable. However, probably it's possible to invent some other scenario with IsoBlit to check this particular change. I'll try to make a test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5882


From mbaesken at openjdk.java.net  Mon Oct 11 06:55:14 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 11 Oct 2021 06:55:14 GMT
Subject: RFR: JDK-8274977: Remove expandPacked and extendEdge from
 awt_ImagingLib.c
In-Reply-To: <1tSvf8JjhHG7crHsLOqHpNOsCcBziywqBBG6Q4SgYZk=.fec63717-09a4-4812-8e30-bdf86536cf4c@github.com>
References: <1tSvf8JjhHG7crHsLOqHpNOsCcBziywqBBG6Q4SgYZk=.fec63717-09a4-4812-8e30-bdf86536cf4c@github.com>
Message-ID: <1AAjHWOPHreFP5QQd2YOuIarfUo_H9xczFgoiK7TsKc=.413934dd-8dbc-4b72-9918-c03ee2247d43@github.com>

On Fri, 8 Oct 2021 14:25:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small cleanup change.
> Looks like expandPacked and extendEdge from awt_ImagingLib.c are unreferenced/unused and can be removed.
> 
> Thanks, Matthias

Hi Sergey,

>Are you sure that these library methods are dead code and cannot be reused for some use-cases? As far as I underst5and the >comment in the "allocateArray" the implementation of "edges" was a work in progress.

both functions expandPacked and extendEdge  are already unused/unreferenced in  jdk11u. So I wonder what usages are planned for them and when.

Best regards, Matthias

-------------

PR: https://git.openjdk.java.net/jdk/pull/5866


From kizune at openjdk.java.net  Mon Oct 11 08:27:13 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 11 Oct 2021 08:27:13 GMT
Subject: RFR: 8271071 accessibility of a table on macOS lacks cell
 navigation [v5]
In-Reply-To: <CRrvnV9hDhLkjGogdXZbBbBw3oiYR0NYJWVfINBBNRU=.1f615936-0df8-4cb9-9071-9eb565b8a7df@github.com>
References: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
 <CRrvnV9hDhLkjGogdXZbBbBw3oiYR0NYJWVfINBBNRU=.1f615936-0df8-4cb9-9071-9eb565b8a7df@github.com>
Message-ID: <pG6rw6AKs2_ZrFNzOibm2covpzcqidIMgb8Z5cZ4Lec=.811a03a8-f5b0-4850-b237-a8cf16d4af12@github.com>

On Thu, 30 Sep 2021 12:02:08 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> We've extended the current implementation of TableAccessibility to make sure that individual cells are voiced when navigating with the keyboard.
>
> Artem Semenov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Latest version seems to work Ok.

-------------

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5466


From vdyakov at openjdk.java.net  Mon Oct 11 18:03:37 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Mon, 11 Oct 2021 18:03:37 GMT
Subject: RFR: 8271071 accessibility of a table on macOS lacks cell
 navigation [v5]
In-Reply-To: <CRrvnV9hDhLkjGogdXZbBbBw3oiYR0NYJWVfINBBNRU=.1f615936-0df8-4cb9-9071-9eb565b8a7df@github.com>
References: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
 <CRrvnV9hDhLkjGogdXZbBbBw3oiYR0NYJWVfINBBNRU=.1f615936-0df8-4cb9-9071-9eb565b8a7df@github.com>
Message-ID: <rFjYYBKk0OXvuzpUZca4UWAwTNtxpgBvyt-EBLWwvtA=.3ededc1d-8edd-4cdf-a3b4-b4585720be01@github.com>

On Thu, 30 Sep 2021 12:02:08 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> We've extended the current implementation of TableAccessibility to make sure that individual cells are voiced when navigating with the keyboard.
>
> Artem Semenov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

@pbansal please review

-------------

PR: https://git.openjdk.java.net/jdk/pull/5466


From duke at openjdk.java.net  Mon Oct 11 19:02:09 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 11 Oct 2021 19:02:09 GMT
Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules
In-Reply-To: <mzVeRcWIXkzXKXQsKh-lhT74R7J3XixXSvGBtKqByrQ=.c6f98337-7cf7-4628-9be2-f720f7717147@github.com>
References: <mzVeRcWIXkzXKXQsKh-lhT74R7J3XixXSvGBtKqByrQ=.c6f98337-7cf7-4628-9be2-f720f7717147@github.com>
Message-ID: <V63QDZddUntw44gDI5DTxW6olc-LmAi9qx5AUkGX2f0=.a5e505c8-ea06-4b71-b01c-3578ad42eceb@github.com>

On Thu, 9 Sep 2021 06:53:13 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance

Marked as reviewed by stsypanov at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5433


From duke at openjdk.java.net  Mon Oct 11 19:02:18 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 11 Oct 2021 19:02:18 GMT
Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules
In-Reply-To: <kJSFz5tKeUoknBevSYfXLoNcF3QfAp8ZI3PBXi0k-1w=.a0190ba2-4a42-4fb4-ab95-9ee5a977b865@github.com>
References: <mzVeRcWIXkzXKXQsKh-lhT74R7J3XixXSvGBtKqByrQ=.c6f98337-7cf7-4628-9be2-f720f7717147@github.com>
 <kJSFz5tKeUoknBevSYfXLoNcF3QfAp8ZI3PBXi0k-1w=.a0190ba2-4a42-4fb4-ab95-9ee5a977b865@github.com>
Message-ID: <92uut52ZoNSElCDbL-0JcebbUyJSpnzEvNGPmY8ITuM=.bc9093e9-9f37-4fb4-bb26-bcb0eb6497f8@github.com>

On Fri, 8 Oct 2021 19:38:57 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Log.java line 117:
> 
>> 115: 
>> 116:                 for (String s : strings) {
>> 117:                     sb.append(" " + s);
> 
> Shouldn't it be `sb.append(" ").append(s)`?

I will do under a separate issue and PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5433


From duke at openjdk.java.net  Mon Oct 11 19:02:20 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 11 Oct 2021 19:02:20 GMT
Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules
In-Reply-To: <92uut52ZoNSElCDbL-0JcebbUyJSpnzEvNGPmY8ITuM=.bc9093e9-9f37-4fb4-bb26-bcb0eb6497f8@github.com>
References: <mzVeRcWIXkzXKXQsKh-lhT74R7J3XixXSvGBtKqByrQ=.c6f98337-7cf7-4628-9be2-f720f7717147@github.com>
 <kJSFz5tKeUoknBevSYfXLoNcF3QfAp8ZI3PBXi0k-1w=.a0190ba2-4a42-4fb4-ab95-9ee5a977b865@github.com>
 <92uut52ZoNSElCDbL-0JcebbUyJSpnzEvNGPmY8ITuM=.bc9093e9-9f37-4fb4-bb26-bcb0eb6497f8@github.com>
Message-ID: <h01KIjxTzUsnFLdmy4b1l0OqZRlqbh_C1mj189dEXGM=.24eda4c9-fa42-4e27-b251-27cb8715e878@github.com>

On Mon, 11 Oct 2021 18:52:13 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Log.java line 117:
>> 
>>> 115: 
>>> 116:                 for (String s : strings) {
>>> 117:                     sb.append(" " + s);
>> 
>> Shouldn't it be `sb.append(" ").append(s)`?
>
> I will do under a separate issue and PR.

Cool!

-------------

PR: https://git.openjdk.java.net/jdk/pull/5433


From duke at openjdk.java.net  Mon Oct 11 19:22:53 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 11 Oct 2021 19:22:53 GMT
Subject: Integrated: 8274945: Cleanup unnecessary calls to
 Throwable.initCause() in java.desktop
In-Reply-To: <9cAqNXhLLsUf-c78adEzM3ddvAOtmu--0e-ge5UHiHY=.be9e7ec9-158f-4352-8e06-1e023a5fb161@github.com>
References: <9cAqNXhLLsUf-c78adEzM3ddvAOtmu--0e-ge5UHiHY=.be9e7ec9-158f-4352-8e06-1e023a5fb161@github.com>
Message-ID: <WiDYkKZX0cIfNz2u8NLNoFS5hYO02P7mt076HTzJwmg=.379ae28b-d4b9-411f-bfee-a1e99a989546@github.com>

On Thu, 7 Oct 2021 12:39:10 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Pass cause exception as constructor parameter is shorter and easier to read.

This pull request has now been integrated.

Changeset: 829dea45
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Pankaj Bansal <pbansal at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/829dea45c9ab90518f03a66aad7e681cd4fda8b3
Stats:     21 lines in 4 files changed: 0 ins; 15 del; 6 mod

8274945: Cleanup unnecessary calls to Throwable.initCause() in java.desktop

Reviewed-by: jdv, serb, pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/5847


From serb at openjdk.java.net  Tue Oct 12 06:06:47 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Oct 2021 06:06:47 GMT
Subject: RFR: 8274032 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java & show test UI [v3]
In-Reply-To: <p-15TqYx5r21b7Dgy-VY3aZBaG9FXBWmFYKq5mPwxn0=.1960d3ea-2844-4cc5-8d9a-e27f9a02d4ca@github.com>
References: <3PeA1uV6v8hufkV83MCl4ADDpKRSqoM39m8vkkuOdak=.d30c9535-1d20-49d9-8df1-d48bae3fd483@github.com>
 <p-15TqYx5r21b7Dgy-VY3aZBaG9FXBWmFYKq5mPwxn0=.1960d3ea-2844-4cc5-8d9a-e27f9a02d4ca@github.com>
Message-ID: <2USD4FTtsrWYYMbooj0XxAEtQDSR5YEIskV7nU4uWmY=.07bbd794-ed0b-4efb-9409-cdfbc4e6c0ba@github.com>

On Mon, 4 Oct 2021 14:46:35 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> Problem : 
>> 1) Testcase was failing due to parse exception yesno
>> 2) After removing yesno tag test frame and immediately get disposed
>> 
>> Fix : 
>> 1) Removed yesno tag
>> 2) Show the test frame with pass, fail button.  Now user can click on the `print' button to show the print dialog and take the print out and compare the print with the graphics rendered on the frame. Click either on the 'Pass' or 'Fail' button to make the pass or fail also clicking the 'Pass' or 'Fail' closes the test frame.
>> 3) Added the timeout If not interaction is performed on the test frame.
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   print message if printer is not install

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5595


From serb at openjdk.java.net  Tue Oct 12 06:10:54 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Oct 2021 06:10:54 GMT
Subject: RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing [v2]
In-Reply-To: <3ImBG1zONPFt9j_xXbC2ha49uVBoqTZwfUBXP_TQCLI=.91448fe7-a57f-4600-8c7f-ce32c08e42d1@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
 <3ImBG1zONPFt9j_xXbC2ha49uVBoqTZwfUBXP_TQCLI=.91448fe7-a57f-4600-8c7f-ce32c08e42d1@github.com>
Message-ID: <EyKjrAxYxRk5xQsVmY_DrnNwXGZuquhK2nqvyj4-axk=.8425588c-8dca-4937-83ec-194932b04a01@github.com>

On Sat, 9 Oct 2021 11:16:29 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   throw exceptions instead of doc change

src/java.desktop/share/classes/java/awt/im/InputContext.java line 147:

> 145:         // real implementation is in sun.awt.im.InputContext
> 146:         if (locale == null) {
> 147:             throw new NullPointerException();

Probably we can reuse the Objects.requireNonNull()?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5806


From serb at openjdk.java.net  Tue Oct 12 06:12:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Oct 2021 06:12:48 GMT
Subject: RFR: JDK-8274977: Remove expandPacked and extendEdge from
 awt_ImagingLib.c
In-Reply-To: <1AAjHWOPHreFP5QQd2YOuIarfUo_H9xczFgoiK7TsKc=.413934dd-8dbc-4b72-9918-c03ee2247d43@github.com>
References: <1tSvf8JjhHG7crHsLOqHpNOsCcBziywqBBG6Q4SgYZk=.fec63717-09a4-4812-8e30-bdf86536cf4c@github.com>
 <1AAjHWOPHreFP5QQd2YOuIarfUo_H9xczFgoiK7TsKc=.413934dd-8dbc-4b72-9918-c03ee2247d43@github.com>
Message-ID: <C1JewXvNArMni8YqCJ-Cqw9JDST4jqClc1NcerP3Mgo=.09a4d28e-1636-4de4-bbe6-ce55e9b5521c@github.com>

On Mon, 11 Oct 2021 06:51:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> both functions expandPacked and extendEdge are already unused/unreferenced in jdk11u. So I wonder what usages are planned for them and when.

It is necessary to dig into the history of this file, and related bugs in JBS to say how these methods were planned to use.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5866


From serb at openjdk.java.net  Tue Oct 12 06:18:51 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Oct 2021 06:18:51 GMT
Subject: RFR: 8274893: Update java.desktop classes to use
 try-with-resources
In-Reply-To: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
Message-ID: <ZuG9q2jWpcnH2eqlcc7QsHdJWz9-xOx_KkPRBb73JrE=.08ad0963-ff8b-4cac-8df2-7ace734d088e@github.com>

On Tue, 5 Oct 2021 08:13:53 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> 8274893: Update java.desktop classes to use try-with-resources

src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java line 587:

> 585:                     // Pending: verify character encoding spec for gconf
> 586:                     StringBuilder sb = new StringBuilder();
> 587:                     try (Reader reader = new InputStreamReader(url.openStream(), ISO_8859_1)) {

I did not check all code but look like in some places the close method was missed when a few streams were wrapped.
Looks like in this place, the "url.openStream()" may be leaked if the constructor of InputStreamReader will throw an exception. Please check other places for similar issues.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5817


From serb at openjdk.java.net  Tue Oct 12 06:29:54 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Oct 2021 06:29:54 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
In-Reply-To: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
Message-ID: <0F3OiniYz_-jXYsqf2GLXlKx4iSmn61bsoyA3uwn_Xo=.07d1a0c6-7835-45fe-99b4-ef6bf0cf0d3f@github.com>

On Mon, 13 Sep 2021 11:32:37 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the 7001973 fixes?
> 
> On Windows, CopyAreaOOB.java fails with a blank window. The cause of this problem is that paint() works one time only. Painting area is not guaranteed when showing a window.
> 
> I think this behavior should be removed for purpose of this test (`@summary: Verifies that copyArea() works properly`). Also, this program uses a Robot, but implements waiting logic by itself. This logic should be replaced to Robot API.
> 
> This fix works fine in Windows, so this test can be removed from ProblemList.txt. I don't have a Mac environment, so can someone please confirm that this fix will work on Mac?

You will not be able to write the test which will check that only one paint event is posted, it is not guaranteed.
You can only check that each rendering caused by the paint event will work fine. This test case check that the first event works fine, it can be improved to check all paint events.

So for the test update, you can add a big delay after the rendering, and wait for what will occur on the screen, any ideas why it may not work? You also can create a separate bug to investigate how we can validate the surface before showing the window so we did not post more events than necessary.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5491


From serb at openjdk.java.net  Tue Oct 12 07:10:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Oct 2021 07:10:48 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v4]
In-Reply-To: <eciHLB1bKgy02_eV0d-Y-RiECZshzMxHakK2ZaUhFk0=.298fe17f-0913-4f1e-8eba-4587c28b05b1@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
 <eciHLB1bKgy02_eV0d-Y-RiECZshzMxHakK2ZaUhFk0=.298fe17f-0913-4f1e-8eba-4587c28b05b1@github.com>
Message-ID: <AygLHuLKyHmMPVhiXXWNEhGgSOqezXqwtrpxoC6fvsE=.5cc824e8-ab5a-40d9-8f32-5146e5a4c45d@github.com>

On Thu, 1 Jul 2021 12:19:53 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>>     return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8268764: Update copy-right year

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4491


From mbaesken at openjdk.java.net  Tue Oct 12 07:40:47 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 12 Oct 2021 07:40:47 GMT
Subject: RFR: JDK-8274977: Remove expandPacked and extendEdge from
 awt_ImagingLib.c
In-Reply-To: <C1JewXvNArMni8YqCJ-Cqw9JDST4jqClc1NcerP3Mgo=.09a4d28e-1636-4de4-bbe6-ce55e9b5521c@github.com>
References: <1tSvf8JjhHG7crHsLOqHpNOsCcBziywqBBG6Q4SgYZk=.fec63717-09a4-4812-8e30-bdf86536cf4c@github.com>
 <1AAjHWOPHreFP5QQd2YOuIarfUo_H9xczFgoiK7TsKc=.413934dd-8dbc-4b72-9918-c03ee2247d43@github.com>
 <C1JewXvNArMni8YqCJ-Cqw9JDST4jqClc1NcerP3Mgo=.09a4d28e-1636-4de4-bbe6-ce55e9b5521c@github.com>
Message-ID: <xgIIsfnIDGaRbvMxGMeyFIDWEl3GTkzZXhJQcP0Gqm4=.f6c99e16-48f0-4421-bd74-d7f4fb5bee5d@github.com>

On Tue, 12 Oct 2021 06:10:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > both functions expandPacked and extendEdge are already unused/unreferenced in jdk11u. So I wonder what usages are planned for them and when.
> 
> It is necessary to dig into the history of this file, and related bugs in JBS to say how these methods were planned to use.

Searching JBS for the 2 functions did not bring me much useful results (no surprise, no one will fix unused code).
Looking into jdk8u history, seems the functions came with "Initial load" in 2007 (!) 

https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/annotate/37a05a11f281/src/share/native/sun/awt/medialib/awt_ImagingLib.c#l1721

Best regards, Matthias

-------------

PR: https://git.openjdk.java.net/jdk/pull/5866


From duke at openjdk.java.net  Tue Oct 12 08:08:00 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 12 Oct 2021 08:08:00 GMT
Subject: RFR: 8275106: Cleanup Iterator usages in java.desktop
Message-ID: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>

Cycles with 'Iterator' are error-prone. It's better to use more high-level code, which easier to read.
We can use enhanced-for or Collection.removeIf

-------------

Commit messages:
 - [PATCH] Cleanup Iterator usages in java.desktop
 - [PATCH] Cleanup Iterator usages in java.desktop

Changes: https://git.openjdk.java.net/jdk/pull/5871/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5871&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275106
  Stats: 115 lines in 18 files changed: 5 ins; 62 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5871.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5871/head:pull/5871

PR: https://git.openjdk.java.net/jdk/pull/5871


From serb at openjdk.java.net  Tue Oct 12 08:08:01 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Oct 2021 08:08:01 GMT
Subject: RFR: 8275106: Cleanup Iterator usages in java.desktop
In-Reply-To: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
References: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
Message-ID: <67_gtYOB0J6rTskYAfPpmfV2vIcVFSaz1E7s1m9fBVo=.378b27d8-5d07-44bb-bd6c-c5a6817eef8a@github.com>

On Fri, 8 Oct 2021 19:37:35 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Cycles with 'Iterator' are error-prone. It's better to use more high-level code, which easier to read.
> We can use enhanced-for or Collection.removeIf

src/java.desktop/share/classes/javax/swing/JDesktopPane.java line 330:

> 328:     public JInternalFrame[] getAllFramesInLayer(int layer) {
> 329:         Collection<JInternalFrame> allFrames = getAllFrames(this);
> 330:         allFrames.removeIf(jInternalFrame -> jInternalFrame.getLayer() != layer);

This line is longer than 80 char, you can rename jInternalFrame to the frame.

src/java.desktop/unix/classes/sun/awt/X11/ListHelper.java line 569:

> 567: 
> 568:     private boolean isItemSelected(int index) {
> 569:         for (Integer val : selected) {

In some other places you did unboxing for the loop var, why not in this place?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5871


From duke at openjdk.java.net  Tue Oct 12 08:08:02 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 12 Oct 2021 08:08:02 GMT
Subject: RFR: 8275106: Cleanup Iterator usages in java.desktop
In-Reply-To: <67_gtYOB0J6rTskYAfPpmfV2vIcVFSaz1E7s1m9fBVo=.378b27d8-5d07-44bb-bd6c-c5a6817eef8a@github.com>
References: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
 <67_gtYOB0J6rTskYAfPpmfV2vIcVFSaz1E7s1m9fBVo=.378b27d8-5d07-44bb-bd6c-c5a6817eef8a@github.com>
Message-ID: <Pk_mgT2Ft7xGG_RCD6ydLXhzYh7QzQz1Y_0hljV5p3k=.380f06f3-6f18-46c9-ba14-81103172ab2d@github.com>

On Tue, 12 Oct 2021 05:49:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Cycles with 'Iterator' are error-prone. It's better to use more high-level code, which easier to read.
>> We can use enhanced-for or Collection.removeIf
>
> src/java.desktop/unix/classes/sun/awt/X11/ListHelper.java line 569:
> 
>> 567: 
>> 568:     private boolean isItemSelected(int index) {
>> 569:         for (Integer val : selected) {
> 
> In some other places you did unboxing for the loop var, why not in this place?

I tried to mimic original code.
If in original code iterator.next() was assigned to a primitive - I use primitive for loop variable declaration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5871


From dbatrak at openjdk.java.net  Tue Oct 12 12:31:00 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Tue, 12 Oct 2021 12:31:00 GMT
Subject: RFR: 8275131: Exceptions after a touchpad gesture on macOS
Message-ID: <8EOvAdXj3GaHwYv45H3QnwQ47dUpledS5EZ3Rq-934o=.a4e872fb-fb52-4a19-baca-b3d8c417440e@github.com>

This is a small fix for a mistake in JDK-8257853 implementation, replacing DECLARE_METHOD JNI lookup macro with DECLARE_STATIC_METHOD in [AWTWindow_Normal postGesture:as:a?].
I did not created a test for the fix, as AWT Robot doesn't currently support touchpad gestures.

-------------

Commit messages:
 - 8275131: Exceptions after a touchpad gesture on macOS

Changes: https://git.openjdk.java.net/jdk/pull/5910/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5910&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275131
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5910.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5910/head:pull/5910

PR: https://git.openjdk.java.net/jdk/pull/5910


From azvegint at openjdk.java.net  Tue Oct 12 13:39:21 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 12 Oct 2021 13:39:21 GMT
Subject: RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing [v3]
In-Reply-To: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
Message-ID: <YyttCdiq2pvjMGLSlX_cGFyHh1O2RGS4NN_ZN_vJXaA=.a97df6a7-c789-4f28-921e-e9d5d4eac0b3@github.com>

> This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  use Objects.requireNonNull

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5806/files
  - new: https://git.openjdk.java.net/jdk/pull/5806/files/6f6f2680..7ee18860

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5806&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5806&range=01-02

  Stats: 10 lines in 1 file changed: 1 ins; 6 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5806.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5806/head:pull/5806

PR: https://git.openjdk.java.net/jdk/pull/5806


From azvegint at openjdk.java.net  Tue Oct 12 13:39:26 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 12 Oct 2021 13:39:26 GMT
Subject: RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing [v2]
In-Reply-To: <EyKjrAxYxRk5xQsVmY_DrnNwXGZuquhK2nqvyj4-axk=.8425588c-8dca-4937-83ec-194932b04a01@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
 <3ImBG1zONPFt9j_xXbC2ha49uVBoqTZwfUBXP_TQCLI=.91448fe7-a57f-4600-8c7f-ce32c08e42d1@github.com>
 <EyKjrAxYxRk5xQsVmY_DrnNwXGZuquhK2nqvyj4-axk=.8425588c-8dca-4937-83ec-194932b04a01@github.com>
Message-ID: <2CqX5Mv_7AtpidKqXK-Uxi0qLx83BF8b7Q041ncuGO0=.789c14e5-43f1-486e-b3cf-d149a66a98f4@github.com>

On Tue, 12 Oct 2021 06:07:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   throw exceptions instead of doc change
>
> src/java.desktop/share/classes/java/awt/im/InputContext.java line 147:
> 
>> 145:         // real implementation is in sun.awt.im.InputContext
>> 146:         if (locale == null) {
>> 147:             throw new NullPointerException();
> 
> Probably we can reuse the Objects.requireNonNull()?

Sure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5806


From dmarkov at openjdk.java.net  Tue Oct 12 14:55:48 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Tue, 12 Oct 2021 14:55:48 GMT
Subject: RFR: 8275131: Exceptions after a touchpad gesture on macOS
In-Reply-To: <8EOvAdXj3GaHwYv45H3QnwQ47dUpledS5EZ3Rq-934o=.a4e872fb-fb52-4a19-baca-b3d8c417440e@github.com>
References: <8EOvAdXj3GaHwYv45H3QnwQ47dUpledS5EZ3Rq-934o=.a4e872fb-fb52-4a19-baca-b3d8c417440e@github.com>
Message-ID: <Y-bTdZxvzh2rHaNPDQFXFP0GvLPk-jM0er05Mul2KMY=.d148852f-38b4-4240-ba84-9079f17dd837@github.com>

On Tue, 12 Oct 2021 12:23:02 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> This is a small fix for a mistake in JDK-8257853 implementation, replacing DECLARE_METHOD JNI lookup macro with DECLARE_STATIC_METHOD in [AWTWindow_Normal postGesture:as:a?].
> I did not created a test for the fix, as AWT Robot doesn't currently support touchpad gestures.

Marked as reviewed by dmarkov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5910


From prr at openjdk.java.net  Tue Oct 12 15:32:47 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 12 Oct 2021 15:32:47 GMT
Subject: RFR: 8275131: Exceptions after a touchpad gesture on macOS
In-Reply-To: <8EOvAdXj3GaHwYv45H3QnwQ47dUpledS5EZ3Rq-934o=.a4e872fb-fb52-4a19-baca-b3d8c417440e@github.com>
References: <8EOvAdXj3GaHwYv45H3QnwQ47dUpledS5EZ3Rq-934o=.a4e872fb-fb52-4a19-baca-b3d8c417440e@github.com>
Message-ID: <pnr1c-isZUgmcUdIYFED4XOVRFvVYrLi3eBGms7XA2k=.b076aba7-aa8e-46c0-aac8-3a7c57e3debb@github.com>

On Tue, 12 Oct 2021 12:23:02 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> This is a small fix for a mistake in JDK-8257853 implementation, replacing DECLARE_METHOD JNI lookup macro with DECLARE_STATIC_METHOD in [AWTWindow_Normal postGesture:as:a?].
> I did not created a test for the fix, as AWT Robot doesn't currently support touchpad gestures.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5910


From dbatrak at openjdk.java.net  Tue Oct 12 15:39:50 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Tue, 12 Oct 2021 15:39:50 GMT
Subject: Integrated: 8275131: Exceptions after a touchpad gesture on macOS
In-Reply-To: <8EOvAdXj3GaHwYv45H3QnwQ47dUpledS5EZ3Rq-934o=.a4e872fb-fb52-4a19-baca-b3d8c417440e@github.com>
References: <8EOvAdXj3GaHwYv45H3QnwQ47dUpledS5EZ3Rq-934o=.a4e872fb-fb52-4a19-baca-b3d8c417440e@github.com>
Message-ID: <pG_PfsGcwa4RdimocQl4ZTr0nWc0mI9-LU4CR7d7NBE=.d5327d13-08c1-42ee-9683-9ca2d08eadde@github.com>

On Tue, 12 Oct 2021 12:23:02 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> This is a small fix for a mistake in JDK-8257853 implementation, replacing DECLARE_METHOD JNI lookup macro with DECLARE_STATIC_METHOD in [AWTWindow_Normal postGesture:as:a?].
> I did not created a test for the fix, as AWT Robot doesn't currently support touchpad gestures.

This pull request has now been integrated.

Changeset: 89999f70
Author:    Dmitry Batrak <dbatrak at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/89999f70e06b41704c7c5b0f9a19582f90806a10
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8275131: Exceptions after a touchpad gesture on macOS

Reviewed-by: dmarkov, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/5910


From duke at openjdk.java.net  Tue Oct 12 19:16:52 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 12 Oct 2021 19:16:52 GMT
Subject: Integrated: 8268764: Use Long.hashCode() instead of int-cast where
 applicable
In-Reply-To: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
Message-ID: <QfvXFKWNAo7KMigQy6uuthHhLPLGjb03brzhQ2rKtMg=.81e62395-3e8b-4bbe-bb7e-52b426ff07e2@github.com>

On Tue, 15 Jun 2021 12:15:11 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> In some JDK classes there's still the following hashCode() implementation:
> 
> long objNum;
> 
> public int hashCode() {
>     return (int) objNum;
> }
> 
> This outdated expression should be replaced with Long.hashCode(long) as it
> 
> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
> 
> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
> 
> See https://stackoverflow.com/a/4045083
> 
> This is related to https://github.com/openjdk/jdk/pull/4309

This pull request has now been integrated.

Changeset: 124f8237
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/124f82377ba93359bc59118ee315ba194080fa92
Stats:     21 lines in 9 files changed: 6 ins; 0 del; 15 mod

8268764: Use Long.hashCode() instead of int-cast where applicable

Reviewed-by: kevinw, prr, kizune, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/4491


From serb at openjdk.java.net  Tue Oct 12 19:52:49 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Oct 2021 19:52:49 GMT
Subject: RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing [v3]
In-Reply-To: <YyttCdiq2pvjMGLSlX_cGFyHh1O2RGS4NN_ZN_vJXaA=.a97df6a7-c789-4f28-921e-e9d5d4eac0b3@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
 <YyttCdiq2pvjMGLSlX_cGFyHh1O2RGS4NN_ZN_vJXaA=.a97df6a7-c789-4f28-921e-e9d5d4eac0b3@github.com>
Message-ID: <6o57ovUp6BbtHXnpabSsUPyQ02rqgQkRgScwj7Wymmc=.18fec80e-a529-4f38-a31f-0302a4a31457@github.com>

On Tue, 12 Oct 2021 13:39:21 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use Objects.requireNonNull

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5806


From serb at openjdk.java.net  Tue Oct 12 20:44:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Oct 2021 20:44:48 GMT
Subject: RFR: 8275106: Cleanup Iterator usages in java.desktop
In-Reply-To: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
References: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
Message-ID: <YbuIr7y-I2hIolooSlo5ohM5xGxiOv0FRUC9doPyo5c=.9fac69a3-90d6-48e4-ab20-f724bdef9d33@github.com>

On Fri, 8 Oct 2021 19:37:35 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Cycles with 'Iterator' are error-prone. It's better to use more high-level code, which easier to read.
> We can use enhanced-for or Collection.removeIf

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5871


From serb at openjdk.java.net  Tue Oct 12 21:05:03 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Oct 2021 21:05:03 GMT
Subject: RFR: JDK-8274977: Remove expandPacked and extendEdge from
 awt_ImagingLib.c
In-Reply-To: <1tSvf8JjhHG7crHsLOqHpNOsCcBziywqBBG6Q4SgYZk=.fec63717-09a4-4812-8e30-bdf86536cf4c@github.com>
References: <1tSvf8JjhHG7crHsLOqHpNOsCcBziywqBBG6Q4SgYZk=.fec63717-09a4-4812-8e30-bdf86536cf4c@github.com>
Message-ID: <Ubohmw7vHm8uzWgP-lGujBRTy_T-mE52JrKibjjqzVk=.08ff6433-e1e6-4b0a-9ab8-4f18368b8395@github.com>

On Fri, 8 Oct 2021 14:25:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small cleanup change.
> Looks like expandPacked and extendEdge from awt_ImagingLib.c are unreferenced/unused and can be removed.
> 
> Thanks, Matthias

You do not need to search the names of two functions it is unlikely mentioned somewhere, but something related to the usage of the edges in the image lib itself. My point is that delete all "useEdges" stuff that is excluded by the macro, or leave it as is until someone will figure out how it can be improved/completed or deleted.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5866


From duke at openjdk.java.net  Wed Oct 13 07:35:16 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 13 Oct 2021 07:35:16 GMT
Subject: RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v2]
In-Reply-To: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
Message-ID: <DZpSTzGC0LcaK9FqwBCGbVIPUle1YEazznQZkfYOm58=.2f864fc5-3804-4180-be13-b7f1c2b5bed3@github.com>

> 8274893: Update java.desktop classes to use try-with-resources

Andrey Turbanov has updated the pull request incrementally with two additional commits since the last revision:

 - 8274893: Update java.desktop classes to use try-with-resources
   close nested resources too
 - [PATCH] Use try-with-resources to close resources in java.desktop

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5817/files
  - new: https://git.openjdk.java.net/jdk/pull/5817/files/6db4fd8e..13bdbc0d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5817&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5817&range=00-01

  Stats: 16 lines in 4 files changed: 9 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5817.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5817/head:pull/5817

PR: https://git.openjdk.java.net/jdk/pull/5817


From duke at openjdk.java.net  Wed Oct 13 07:40:51 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 13 Oct 2021 07:40:51 GMT
Subject: RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v2]
In-Reply-To: <ZuG9q2jWpcnH2eqlcc7QsHdJWz9-xOx_KkPRBb73JrE=.08ad0963-ff8b-4cac-8df2-7ace734d088e@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
 <ZuG9q2jWpcnH2eqlcc7QsHdJWz9-xOx_KkPRBb73JrE=.08ad0963-ff8b-4cac-8df2-7ace734d088e@github.com>
Message-ID: <cROilBuMVej0JIKBrbA6lJocPUPmakpTdyEJepDaVhQ=.456c4e7d-1fcc-4cdc-9de3-0503e37f9936@github.com>

On Tue, 12 Oct 2021 06:16:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8274893: Update java.desktop classes to use try-with-resources
>>    close nested resources too
>>  - [PATCH] Use try-with-resources to close resources in java.desktop
>
> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java line 587:
> 
>> 585:                     // Pending: verify character encoding spec for gconf
>> 586:                     StringBuilder sb = new StringBuilder();
>> 587:                     try (Reader reader = new InputStreamReader(url.openStream(), ISO_8859_1)) {
> 
> I did not check all code but look like in some places the close method was missed when a few streams were wrapped.
> Looks like in this place, the "url.openStream()" may be leaked if the constructor of InputStreamReader will throw an exception. Please check other places for similar issues.

updated

-------------

PR: https://git.openjdk.java.net/jdk/pull/5817


From harald.kuhr at gmail.com  Wed Oct 13 18:02:20 2021
From: harald.kuhr at gmail.com (Harald Kuhr)
Date: Wed, 13 Oct 2021 20:02:20 +0200
Subject: Possibility of backporting fix for JDK-6986863
Message-ID: <CAGYrztHYpOe=LeF-NoKW265ZG=AEmJdnN2yh363o-B1e+NBt4Q@mail.gmail.com>

Hi all,

I just signed up for the client-libs-dev mailing list, so bear with me? ?

I?m the author of TwelveMonkeys ImageIO (
https://github.com/haraldk/TwelveMonkeys) and ever so often users of my
library run into https://bugs.openjdk.java.net/browse/JDK-6986863
(ProfileDeferralMgr throwing ConcurrentModificationException) or one of its
various incarnations/duplicates. See for example
https://github.com/haraldk/TwelveMonkeys/issues/631 or #402

I am very happy to see this bug finally being fixed in Java 17!

However, I wonder what it would take to backport Sergey?s fix (
https://github.com/openjdk/jdk/commit/64a150c5) to OpenJDK 11 (or even 8)
as it?s hard to create a reliable workaround (from a library viewpoint)?

I?m fairly familiar with this part of the JDK code base and have looked
through the fix commit and believe it should be fairly straightforward to
apply the changes to JDK 11 and 8 (there haven?t been many changes to this
part of the code since Java 8 if I remember correctly). I?m currently not a
contributor, but I?m trying to sign the necessary OCA and may provide a
patch in the future.


Best regards,

?
Harald K


From philip.race at oracle.com  Wed Oct 13 18:08:18 2021
From: philip.race at oracle.com (Philip Race)
Date: Wed, 13 Oct 2021 11:08:18 -0700
Subject: Possibility of backporting fix for JDK-6986863
In-Reply-To: <CAGYrztHYpOe=LeF-NoKW265ZG=AEmJdnN2yh363o-B1e+NBt4Q@mail.gmail.com>
References: <CAGYrztHYpOe=LeF-NoKW265ZG=AEmJdnN2yh363o-B1e+NBt4Q@mail.gmail.com>
Message-ID: <7ac53f87-7c5a-8ac5-f80e-d347d9a055c5@oracle.com>

I think it would be good to backport and I suspect Sergey may well do so ..
although generally the place to ask about backports to older releases is 
one of
the update release mailing lists.

phil.

On 10/13/21 11:02 AM, Harald Kuhr wrote:
> Hi all,
>
> I just signed up for the client-libs-dev mailing list, so bear with me? ?
>
> I?m the author of TwelveMonkeys ImageIO (
> https://github.com/haraldk/TwelveMonkeys) and ever so often users of my
> library run into https://bugs.openjdk.java.net/browse/JDK-6986863
> (ProfileDeferralMgr throwing ConcurrentModificationException) or one of its
> various incarnations/duplicates. See for example
> https://github.com/haraldk/TwelveMonkeys/issues/631 or #402
>
> I am very happy to see this bug finally being fixed in Java 17!
>
> However, I wonder what it would take to backport Sergey?s fix (
> https://github.com/openjdk/jdk/commit/64a150c5) to OpenJDK 11 (or even 8)
> as it?s hard to create a reliable workaround (from a library viewpoint)?
>
> I?m fairly familiar with this part of the JDK code base and have looked
> through the fix commit and believe it should be fairly straightforward to
> apply the changes to JDK 11 and 8 (there haven?t been many changes to this
> part of the code since Java 8 if I remember correctly). I?m currently not a
> contributor, but I?m trying to sign the necessary OCA and may provide a
> patch in the future.
>
>
> Best regards,
>
> ?
> Harald K



From harald.kuhr at gmail.com  Wed Oct 13 18:51:39 2021
From: harald.kuhr at gmail.com (Harald Kuhr)
Date: Wed, 13 Oct 2021 20:51:39 +0200
Subject: Possibility of backporting fix for JDK-6986863
In-Reply-To: <7ac53f87-7c5a-8ac5-f80e-d347d9a055c5@oracle.com>
References: <CAGYrztHYpOe=LeF-NoKW265ZG=AEmJdnN2yh363o-B1e+NBt4Q@mail.gmail.com>
 <7ac53f87-7c5a-8ac5-f80e-d347d9a055c5@oracle.com>
Message-ID: <CAGYrztH32VWFifp7ybntQQquRUQSin8GtDzG2y2xdFJgVVf+fw@mail.gmail.com>

Thanks Phil,

A backport would be great, and I really hope that happens!

Reading his (Sergey's) comments on my project issues, I was under the
impression that it would not happen, unless someone filed a bug/request for
this. But I will raise the issue again in the update mailing lists (if I
can find my way around them).


Again, thanks, and sorry for using the wrong list,

-- 
Harald K


On Wed, Oct 13, 2021 at 8:08 PM Philip Race <philip.race at oracle.com> wrote:

> I think it would be good to backport and I suspect Sergey may well do so ..
> although generally the place to ask about backports to older releases is
> one of
> the update release mailing lists.
>
> phil.
>
> On 10/13/21 11:02 AM, Harald Kuhr wrote:
> > Hi all,
> >
> > I just signed up for the client-libs-dev mailing list, so bear with me?
> ?
> >
> > I?m the author of TwelveMonkeys ImageIO (
> > https://github.com/haraldk/TwelveMonkeys) and ever so often users of my
> > library run into https://bugs.openjdk.java.net/browse/JDK-6986863
> > (ProfileDeferralMgr throwing ConcurrentModificationException) or one of
> its
> > various incarnations/duplicates. See for example
> > https://github.com/haraldk/TwelveMonkeys/issues/631 or #402
> >
> > I am very happy to see this bug finally being fixed in Java 17!
> >
> > However, I wonder what it would take to backport Sergey?s fix (
> > https://github.com/openjdk/jdk/commit/64a150c5) to OpenJDK 11 (or even
> 8)
> > as it?s hard to create a reliable workaround (from a library viewpoint)?
> >
> > I?m fairly familiar with this part of the JDK code base and have looked
> > through the fix commit and believe it should be fairly straightforward to
> > apply the changes to JDK 11 and 8 (there haven?t been many changes to
> this
> > part of the code since Java 8 if I remember correctly). I?m currently
> not a
> > contributor, but I?m trying to sign the necessary OCA and may provide a
> > patch in the future.
> >
> >
> > Best regards,
> >
> > ?
> > Harald K
>
>


From duke at openjdk.java.net  Wed Oct 13 18:56:03 2021
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 13 Oct 2021 18:56:03 GMT
Subject: RFR: 8275234 : java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java
 is entered twice in ProblemList
Message-ID: <5RcFPNS-JHH3dNtitXhpmuwKdMc9i4B2mpN9dKsdYUo=.c313570d-b621-415c-9c1f-0e0b838c77c7@github.com>

java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java is entered twice in the problemList.txt 
jtreg always picks the second entry not the first one and user expects that test should be executed on the first entry platform but it executes.

@shurymury

-------------

Commit messages:
 - 8275234 : java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java is entered twice in ProblemList

Changes: https://git.openjdk.java.net/jdk/pull/5932/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5932&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275234
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5932.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5932/head:pull/5932

PR: https://git.openjdk.java.net/jdk/pull/5932


From serb at openjdk.java.net  Wed Oct 13 18:56:03 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 13 Oct 2021 18:56:03 GMT
Subject: RFR: 8275234 :
 java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java is entered twice in
 ProblemList
In-Reply-To: <5RcFPNS-JHH3dNtitXhpmuwKdMc9i4B2mpN9dKsdYUo=.c313570d-b621-415c-9c1f-0e0b838c77c7@github.com>
References: <5RcFPNS-JHH3dNtitXhpmuwKdMc9i4B2mpN9dKsdYUo=.c313570d-b621-415c-9c1f-0e0b838c77c7@github.com>
Message-ID: <VhUByoaidsirB26nfCh2LRCrAAPbMgaXqsrfRqDsrtk=.843dae66-af01-459a-a897-67074fca84d8@github.com>

On Wed, 13 Oct 2021 18:37:40 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java is entered twice in the problemList.txt 
> jtreg always picks the second entry not the first one and user expects that test should be executed on the first entry platform but it executes.
> 
> @shurymury

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5932


From prr at openjdk.java.net  Wed Oct 13 19:10:51 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 13 Oct 2021 19:10:51 GMT
Subject: RFR: 8041125: ColorConvertOp filter much slower in JDK 8 compared
 to JDK7
In-Reply-To: <01oQmcaxpb_DFPCTQS_ek2CnCbEJRCNODsZNF7KR8t0=.9e9f761d-0c08-40de-bc8b-fcc612da9d2e@github.com>
References: <01oQmcaxpb_DFPCTQS_ek2CnCbEJRCNODsZNF7KR8t0=.9e9f761d-0c08-40de-bc8b-fcc612da9d2e@github.com>
Message-ID: <iHAww4Mdc0fAJPaA-85AcTd8DrTMpna6QvL4o79VcUI=.c2956665-826e-46a0-9ad2-bfaa4f5c4bd3@github.com>

On Wed, 6 Oct 2021 08:41:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> We have improved the cmm code over a few releases and mostly resolve the JDK-8041125. But I have executed an attached test case under a profiler and found that:
> 
> * less than 10% is an actual pixel transformation inside littlecms
> * 30% is a native up-calls like getXXField
> * 30% is incoming arrays coping
> * 30% results array saving
> * others
> 
> This change removes the native up-calls and passes all data from the java side.
> 
> Notes:
> 
> * The above numbers are true for the "pure Java" implementation in the test case, where we transform the image pixel by pixel, if the image is big and we transform it at once via filter then we spend most of the time in the littlecms code
> * JDK7 uses 4 threads in the filter implementation, but single-threaded jdk17 is faster because of some code improvement in cmm profiles initialization during the "cold start". And probably because the image is not so big(625x843).
> * If the size of the image will be increased and the warmup is done the jdk7 will be 4x time faster, this is another opportunity that I'll try to resolve later.
> 
> 
> Tested on macOS (fastest result after a few runs):
> ||JDK 7 | JDK 8 | JDK 17 | FIX |
> |----|----|----|----|----|
> |With filter |  307 ms  |  456 ms  |  242 ms  |   236 ms |
> |In pure Java|  1672 ms  |  389 ms  |  300 ms  |  259 ms  |
> 
> 
> JMH before/after the fix
> `ColorSpace.toRGB/fromRGB/toCIEXYZ/fromCIEXYZ(new float[]{1,1,1})`
> single threaded and multi-threaded(MAX = 30):
> ![image](https://user-images.githubusercontent.com/14138494/136283699-05e47dca-e7f8-43a1-97d3-53072d3589f6.png)
> 
> https://jmh.morethan.io/?gists=b1edd5e5ebeb1b76867b2112be30145d,fc86ce4a6f8f2f49e9ab512ef641c11b

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5835


From pbansal at openjdk.java.net  Wed Oct 13 19:22:48 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 13 Oct 2021 19:22:48 GMT
Subject: RFR: 8275234 :
 java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java is entered twice in
 ProblemList
In-Reply-To: <5RcFPNS-JHH3dNtitXhpmuwKdMc9i4B2mpN9dKsdYUo=.c313570d-b621-415c-9c1f-0e0b838c77c7@github.com>
References: <5RcFPNS-JHH3dNtitXhpmuwKdMc9i4B2mpN9dKsdYUo=.c313570d-b621-415c-9c1f-0e0b838c77c7@github.com>
Message-ID: <28t6uIh5XMy8osvIUGpaGJzzizG5kEfH0_8RYI-6C94=.b77e9e7e-f659-433d-9da0-818549778bd0@github.com>

On Wed, 13 Oct 2021 18:37:40 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java is entered twice in the problemList.txt 
> jtreg always picks the second entry not the first one and user expects that test should be executed on the first entry platform but it executes.
> 
> @shurymury

Marked as reviewed by pbansal (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5932


From serb at openjdk.java.net  Wed Oct 13 19:44:49 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 13 Oct 2021 19:44:49 GMT
Subject: RFR: 8274032 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java & show test UI [v3]
In-Reply-To: <p-15TqYx5r21b7Dgy-VY3aZBaG9FXBWmFYKq5mPwxn0=.1960d3ea-2844-4cc5-8d9a-e27f9a02d4ca@github.com>
References: <3PeA1uV6v8hufkV83MCl4ADDpKRSqoM39m8vkkuOdak=.d30c9535-1d20-49d9-8df1-d48bae3fd483@github.com>
 <p-15TqYx5r21b7Dgy-VY3aZBaG9FXBWmFYKq5mPwxn0=.1960d3ea-2844-4cc5-8d9a-e27f9a02d4ca@github.com>
Message-ID: <xagiZsy1FNxs6UTcAG0klnewOtIhGD_nnqHJDrIPqWs=.2fdc06e6-f0a8-4ae2-8165-e9cfad0fc8d8@github.com>

On Mon, 4 Oct 2021 14:46:35 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> Problem : 
>> 1) Testcase was failing due to parse exception yesno
>> 2) After removing yesno tag test frame and immediately get disposed
>> 
>> Fix : 
>> 1) Removed yesno tag
>> 2) Show the test frame with pass, fail button.  Now user can click on the `print' button to show the print dialog and take the print out and compare the print with the graphics rendered on the frame. Click either on the 'Pass' or 'Fail' button to make the pass or fail also clicking the 'Pass' or 'Fail' closes the test frame.
>> 3) Added the timeout If not interaction is performed on the test frame.
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   print message if printer is not install

@pankaj-bansal please take a look, did your comment was fixed?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5595


From pbansal at openjdk.java.net  Wed Oct 13 19:47:49 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 13 Oct 2021 19:47:49 GMT
Subject: RFR: 8274032 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java & show test UI [v3]
In-Reply-To: <p-15TqYx5r21b7Dgy-VY3aZBaG9FXBWmFYKq5mPwxn0=.1960d3ea-2844-4cc5-8d9a-e27f9a02d4ca@github.com>
References: <3PeA1uV6v8hufkV83MCl4ADDpKRSqoM39m8vkkuOdak=.d30c9535-1d20-49d9-8df1-d48bae3fd483@github.com>
 <p-15TqYx5r21b7Dgy-VY3aZBaG9FXBWmFYKq5mPwxn0=.1960d3ea-2844-4cc5-8d9a-e27f9a02d4ca@github.com>
Message-ID: <AfbBParrSVqrDx4S_eR5mARIlpRJNSDYobMts3aBz0I=.cd54f4b3-156d-412b-96ec-1d542f334523@github.com>

On Mon, 4 Oct 2021 14:46:35 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

>> Problem : 
>> 1) Testcase was failing due to parse exception yesno
>> 2) After removing yesno tag test frame and immediately get disposed
>> 
>> Fix : 
>> 1) Removed yesno tag
>> 2) Show the test frame with pass, fail button.  Now user can click on the `print' button to show the print dialog and take the print out and compare the print with the graphics rendered on the frame. Click either on the 'Pass' or 'Fail' button to make the pass or fail also clicking the 'Pass' or 'Fail' closes the test frame.
>> 3) Added the timeout If not interaction is performed on the test frame.
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   print message if printer is not install

Marked as reviewed by pbansal (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5595


From pbansal at openjdk.java.net  Wed Oct 13 19:47:50 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 13 Oct 2021 19:47:50 GMT
Subject: RFR: 8274032 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java & show test UI [v3]
In-Reply-To: <xagiZsy1FNxs6UTcAG0klnewOtIhGD_nnqHJDrIPqWs=.2fdc06e6-f0a8-4ae2-8165-e9cfad0fc8d8@github.com>
References: <3PeA1uV6v8hufkV83MCl4ADDpKRSqoM39m8vkkuOdak=.d30c9535-1d20-49d9-8df1-d48bae3fd483@github.com>
 <p-15TqYx5r21b7Dgy-VY3aZBaG9FXBWmFYKq5mPwxn0=.1960d3ea-2844-4cc5-8d9a-e27f9a02d4ca@github.com>
 <xagiZsy1FNxs6UTcAG0klnewOtIhGD_nnqHJDrIPqWs=.2fdc06e6-f0a8-4ae2-8165-e9cfad0fc8d8@github.com>
Message-ID: <NMkyjhYcRleWU4jddWnsTix87Z3txwCyhIGoSbQX1I0=.b2604262-203f-4cdd-8bf0-b78f353bae65@github.com>

On Wed, 13 Oct 2021 19:41:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> @pankaj-bansal please take a look, did your comment was fixed?

Yes, I see that my comment has been take care of.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5595


From prr at openjdk.java.net  Wed Oct 13 19:50:51 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 13 Oct 2021 19:50:51 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out on
 macOS 12 [v2]
In-Reply-To: <m83G8HcxiSfHhmCCnxkQuqlg4LNke_u6f9e-hr9b0Fc=.469919a9-9e03-4bce-b584-b16751bfe0e0@github.com>
References: <qQBVkoEwZk-W7_WDcvY5cqHxN3DuYj2IDNMETl50WHg=.b2c0ab63-c7aa-4191-a207-1bff83933743@github.com>
 <m83G8HcxiSfHhmCCnxkQuqlg4LNke_u6f9e-hr9b0Fc=.469919a9-9e03-4bce-b584-b16751bfe0e0@github.com>
Message-ID: <icUVkm8AVTS1p49sKFE6CJJtUZluyMw0wcaQ2Ebkzss=.c5efb5ac-993e-4954-9b4b-f24ebd239d4a@github.com>

On Tue, 28 Sep 2021 10:02:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java is timing out every time on macOS 12 even though the test passed.
>> Looks like the the main process waits for child process created in the test forever, making it timeout after jtreg timeout of 2min.
>> Modified to wait for childprocess for 30secs.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove thread blocking

If changing waiting to NO doesn't fix the hang, then test would still hang and time out wouldn't it ?
It would be nice to know what *actually happens* on the system with that change.
And if it does fix it .. why ? Could it be a deadlock ? But if so who's and where ?
If the problem is anything like that then a simple native test case may not show it.
But the child process that hangs and does all the display mode changing doesn't create a lot of threads.
And why does it hang and the (several) other tests we have that change display modes etc not hang ?
If you just directly (no jtreg, no parent process) run the child from the command line does it hang ?
Without your updates I mean ..

-------------

PR: https://git.openjdk.java.net/jdk/pull/5647


From duke at openjdk.java.net  Wed Oct 13 20:07:50 2021
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 13 Oct 2021 20:07:50 GMT
Subject: Integrated: 8275234 :
 java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java is entered twice in
 ProblemList
In-Reply-To: <5RcFPNS-JHH3dNtitXhpmuwKdMc9i4B2mpN9dKsdYUo=.c313570d-b621-415c-9c1f-0e0b838c77c7@github.com>
References: <5RcFPNS-JHH3dNtitXhpmuwKdMc9i4B2mpN9dKsdYUo=.c313570d-b621-415c-9c1f-0e0b838c77c7@github.com>
Message-ID: <TrpToHlTrTAt4igScH9C0SVGlVZeiRu0TuvBya3kopw=.973abe8a-f562-429a-aada-f9306d49581a@github.com>

On Wed, 13 Oct 2021 18:37:40 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java is entered twice in the problemList.txt 
> jtreg always picks the second entry not the first one and user expects that test should be executed on the first entry platform but it executes.
> 
> @shurymury

This pull request has now been integrated.

Changeset: 1e0184d1
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1e0184d142deb18e719fc28814a293b44bab6c63
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8275234: java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java is entered twice in ProblemList

Reviewed-by: serb, pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/5932


From duke at openjdk.java.net  Wed Oct 13 20:09:52 2021
From: duke at openjdk.java.net (lawrence.andrews)
Date: Wed, 13 Oct 2021 20:09:52 GMT
Subject: Integrated: 8274032 : Remove jtreg tag manual=yesno for
 java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java & show test UI
In-Reply-To: <3PeA1uV6v8hufkV83MCl4ADDpKRSqoM39m8vkkuOdak=.d30c9535-1d20-49d9-8df1-d48bae3fd483@github.com>
References: <3PeA1uV6v8hufkV83MCl4ADDpKRSqoM39m8vkkuOdak=.d30c9535-1d20-49d9-8df1-d48bae3fd483@github.com>
Message-ID: <9ky7XchKhNio21VJ4MycfiJ7jBK2zOaVs5K0f37Kt3U=.56b51a7e-b59c-4f98-9f97-36f07ee15271@github.com>

On Tue, 21 Sep 2021 03:24:24 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> Problem : 
> 1) Testcase was failing due to parse exception yesno
> 2) After removing yesno tag test frame and immediately get disposed
> 
> Fix : 
> 1) Removed yesno tag
> 2) Show the test frame with pass, fail button.  Now user can click on the `print' button to show the print dialog and take the print out and compare the print with the graphics rendered on the frame. Click either on the 'Pass' or 'Fail' button to make the pass or fail also clicking the 'Pass' or 'Fail' closes the test frame.
> 3) Added the timeout If not interaction is performed on the test frame.
> 
> @shurymury

This pull request has now been integrated.

Changeset: 7dc2db4a
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7dc2db4aacfeea0caffcc76fd352eabf64ee34c4
Stats:     155 lines in 1 file changed: 80 ins; 41 del; 34 mod

8274032: Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java & show test UI

Reviewed-by: serb, pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/5595


From prr at openjdk.java.net  Wed Oct 13 20:22:54 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 13 Oct 2021 20:22:54 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
Message-ID: <4MvvIPQABEkvmdCF7yoiBV-woGbtwaWfHcwaqliByCw=.2f3943b1-e103-4b6b-a7e4-a918ab274429@github.com>

On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.
> 
> It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.
> 
> Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

Whilst more in keeping with the code that grabs an area It's not easy to know if this really makes things better in any practical way.
It definitely does not fix a single one of the tests described in https://bugs.openjdk.java.net/browse/JDK-8274106
(after of course un-doing the problem listing and work arounds of setting) as tested on both imacs on which they were previously observed to fail. As noted in that bug report, it seems like there may be an Apple bug.
Meanwhile I will run more tests (not just those previously failing ones) to make sure this change doesn't introduce any new issues.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5864


From serb at openjdk.java.net  Wed Oct 13 20:27:54 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 13 Oct 2021 20:27:54 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <4MvvIPQABEkvmdCF7yoiBV-woGbtwaWfHcwaqliByCw=.2f3943b1-e103-4b6b-a7e4-a918ab274429@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
 <4MvvIPQABEkvmdCF7yoiBV-woGbtwaWfHcwaqliByCw=.2f3943b1-e103-4b6b-a7e4-a918ab274429@github.com>
Message-ID: <7TU6YM9S48uzdYxVLqyVe-zAKil1QL4jPpA8oNYUwnU=.a55ddef1-e201-4b95-adac-4f4efac40b85@github.com>

On Wed, 13 Oct 2021 20:20:08 GMT, Phil Race <prr at openjdk.org> wrote:

> It definitely does not fix a single one of the tests described in https://bugs.openjdk.java.net/browse/JDK-8274106

As I mentioned in that bug, the scaleUI option does not affect the macOS API we use, and if the option solves the tests failures mean that we still have some other bugs somewhere.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5864


From serb at openjdk.java.net  Thu Oct 14 06:27:13 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 14 Oct 2021 06:27:13 GMT
Subject: RFR: 8273831: PrintServiceLookup spawns 2 threads in the current
 classloader, getting orphaned
Message-ID: <eXuUD3WLjn4xv-R9bL_xU0tXyZV3HVNLpliZLBX9yFM=.1398debc-971a-4013-bbef-17e388a944d5@github.com>

The PrintServiceLookupProvider can spawn 2 threads on WIndows and one thread on Linux. These threads are connected to the classloader of the web application.  During undeployment the app classloader gets removed together with the two orphaned threads by the Tomcat. 

Looks like the tomcat has special machinery to workaround such threads:
https://cwiki.apache.org/confluence/display/tomcat/MemoryLeakProtection#MemoryLeakProtection-cclThreadSpawnedByJRE
But it should be updated each time we add/update/rename the threads in the JDK. So JreMemoryLeakPreventionListener can be updated to solve this problem, but it will be good to reset the ref to the app class loader as we usually do for our internal threads. 

The change updates threads to use the root thread group and null context class loader.

A similar pattern is used here:
https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.desktop/share/classes/com/sun/imageio/stream/StreamCloser.java#L89

@aivanov-jdk please take a look

-------------

Commit messages:
 - cleanup
 - Update PrintServiceLookupProvider.java
 - Update FlushCustomClassLoader.java
 - cleanup and test
 - Update PrintServiceLookupProvider.java

Changes: https://git.openjdk.java.net/jdk/pull/5939/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5939&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273831
  Stats: 120 lines in 3 files changed: 104 ins; 3 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5939.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5939/head:pull/5939

PR: https://git.openjdk.java.net/jdk/pull/5939


From duke at openjdk.java.net  Thu Oct 14 17:58:01 2021
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 14 Oct 2021 17:58:01 GMT
Subject: RFR: 8275165 : ProblemList InterpolationQualityTest.java
Message-ID: <9gURgNbbZoa-8XRoDtrga0WI0E-9Eb7-CHeBlMDiYho=.ba41750d-a7bc-4535-879e-052919ad3cbd@github.com>

InterpolationQualityTest.java test fails consistently on windows 10 hence adding it in the problemList.

@shurymury

-------------

Commit messages:
 - Added the right test case failure bugid
 - 8275165 : ProblemList InterpolationQualityTest.java

Changes: https://git.openjdk.java.net/jdk/pull/5930/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5930&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275165
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5930.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5930/head:pull/5930

PR: https://git.openjdk.java.net/jdk/pull/5930


From serb at openjdk.java.net  Thu Oct 14 17:58:01 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 14 Oct 2021 17:58:01 GMT
Subject: RFR: 8275165 : ProblemList InterpolationQualityTest.java
In-Reply-To: <9gURgNbbZoa-8XRoDtrga0WI0E-9Eb7-CHeBlMDiYho=.ba41750d-a7bc-4535-879e-052919ad3cbd@github.com>
References: <9gURgNbbZoa-8XRoDtrga0WI0E-9Eb7-CHeBlMDiYho=.ba41750d-a7bc-4535-879e-052919ad3cbd@github.com>
Message-ID: <WaEge8HDDlbiAdtNkg42eklzYxYqcgCKPEpOUG2gAkk=.a5f7e0f0-8ed6-43b6-8634-b3bb3261e3b2@github.com>

On Wed, 13 Oct 2021 17:02:03 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> InterpolationQualityTest.java test fails consistently on windows 10 hence adding it in the problemList.
> 
> @shurymury

I remember this test was(and is) quite stable, did you check what is the reason of the failure. Is it possible it is caused by some of the @run main/othervm option(d3d/gdi)?

It looks like it fail when d3d is enabled by default(unclear why d3d is enabled by default inside of VM), so it passed only when we disable d3d explicitly. Does it fail in the mach5 headful lab or it is the new system?

Then double check the VM graphics system configuration, version of the driver, etc. I am worried to disable it completely since this is the only one test we have for interpolation, and it was stable for one year since the last November.

What happens if you will disable d3d? You also mat try to update the driver or do the opposite and remove it, is the problem in this test only, or do some other tests fail as well?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5930


From duke at openjdk.java.net  Thu Oct 14 17:58:02 2021
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 14 Oct 2021 17:58:02 GMT
Subject: RFR: 8275165 : ProblemList InterpolationQualityTest.java
In-Reply-To: <WaEge8HDDlbiAdtNkg42eklzYxYqcgCKPEpOUG2gAkk=.a5f7e0f0-8ed6-43b6-8634-b3bb3261e3b2@github.com>
References: <9gURgNbbZoa-8XRoDtrga0WI0E-9Eb7-CHeBlMDiYho=.ba41750d-a7bc-4535-879e-052919ad3cbd@github.com>
 <WaEge8HDDlbiAdtNkg42eklzYxYqcgCKPEpOUG2gAkk=.a5f7e0f0-8ed6-43b6-8634-b3bb3261e3b2@github.com>
Message-ID: <MEshGtQq0hG-3dd7VklhDptTUPX2zmo9R0B_bTHtrJ0=.f08ce1c2-308f-4e8a-8418-56c5a26b21b8@github.com>

On Wed, 13 Oct 2021 18:10:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> InterpolationQualityTest.java test fails consistently on windows 10 hence adding it in the problemList.
>> 
>> @shurymury
>
> I remember this test was(and is) quite stable, did you check what is the reason of the failure. Is it possible it is caused by some of the @run main/othervm option(d3d/gdi)?

@mrserb - I run the test with all the options as well as one by one @ main/othervm options and only the following passes.
@run main/othervm -Dsun.java2d.uiScale=1 -Dsun.java2d.d3d=false InterpolationQualityTest 

All the other options fails. Only bilinear fails  but other two hint passes
-----------------------------------------------------------------------
nearest passed.
resImage.getRGB(13, 0) = java.awt.Color[r=207,g=207,b=207] != java.awt.Color[r=211,g=211,b=211]
bilinear failed.
bicubic passed.
----------System.err:(14/884)----------
java.lang.RuntimeException: Test FAILED.
        at InterpolationQualityTest.test(InterpolationQualityTest.java:158)
        at InterpolationQualityTest.main(InterpolationQualityTest.java:186)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
        at java.base/java.lang.reflect.Method.invoke(Method.java:569)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
        at java.base/java.lang.Thread.run(Thread.java:833)

---------------------------------------------------------------
Display resolution is set to 1920 * 1080

Test is tested on VM

-------------

PR: https://git.openjdk.java.net/jdk/pull/5930


From duke at openjdk.java.net  Thu Oct 14 17:58:02 2021
From: duke at openjdk.java.net (lawrence.andrews)
Date: Thu, 14 Oct 2021 17:58:02 GMT
Subject: RFR: 8275165 : ProblemList InterpolationQualityTest.java
In-Reply-To: <9gURgNbbZoa-8XRoDtrga0WI0E-9Eb7-CHeBlMDiYho=.ba41750d-a7bc-4535-879e-052919ad3cbd@github.com>
References: <9gURgNbbZoa-8XRoDtrga0WI0E-9Eb7-CHeBlMDiYho=.ba41750d-a7bc-4535-879e-052919ad3cbd@github.com>
Message-ID: <bo6gcyzt4qw8pYDnOROxYABDj5Azri2ODkSO5y7LL0E=.fdbbcd6c-97ab-4500-a6a9-a782cc5675a7@github.com>

On Wed, 13 Oct 2021 17:02:03 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> InterpolationQualityTest.java test fails consistently on windows 10 hence adding it in the problemList.
> 
> @shurymury

Its a latest window on a new VM.

Checking the VM's graphic system configuration.

I checked the VM graphics configuration
1) DirectDraw Acceleration - Enabled
2) Direct3D Acceleration - Enabled
3) AGP Acceleration - Enabled
4) Direct3D DDI - 12
5) Driver model - WDDM 1.3
6) HDR : not supported
7) DirectX version - 12

1) There is no enable/ disable button in dxdiag to turn on / off D3D
2) Tried disabling Hardware acceleration and still not able to disable d3d via regedit
3) Removed driver and and tried upgrading and still not able to disable d3d.
4) Finally checked for "Display adapter" in device manager and its not seen. 

Since I am able to disable the d3d and test I can't say whether its a test case issue. This test case fails on Windows VMs. Let me try in other hosts.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5930


From prr at openjdk.java.net  Thu Oct 14 17:58:02 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 14 Oct 2021 17:58:02 GMT
Subject: RFR: 8275165 : ProblemList InterpolationQualityTest.java
In-Reply-To: <9gURgNbbZoa-8XRoDtrga0WI0E-9Eb7-CHeBlMDiYho=.ba41750d-a7bc-4535-879e-052919ad3cbd@github.com>
References: <9gURgNbbZoa-8XRoDtrga0WI0E-9Eb7-CHeBlMDiYho=.ba41750d-a7bc-4535-879e-052919ad3cbd@github.com>
Message-ID: <COrHHRfw7gDQlhpn9vgH59LYa5O2eOIvhy0Sf_RhYgE=.153d9609-7cee-4f1f-8b00-0d81a2ac1b00@github.com>

On Wed, 13 Oct 2021 17:02:03 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> InterpolationQualityTest.java test fails consistently on windows 10 hence adding it in the problemList.
> 
> @shurymury

This VM can't possibly be reporting an AMD or Nvidia D3D card can it ??
That's the only two cases we should be enabling D3D without someone forcing it.
Also this PR has a problem. It claims to be resolving bug 8275165 but that's the bug added to the problem list ... 
The bug ID in the problem list needs to be a different one - and that's why this PR is not yet ready for review (no rfr label)

-------------

PR: https://git.openjdk.java.net/jdk/pull/5930


From prr at openjdk.java.net  Thu Oct 14 18:12:47 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 14 Oct 2021 18:12:47 GMT
Subject: RFR: 8275165 : ProblemList InterpolationQualityTest.java
In-Reply-To: <9gURgNbbZoa-8XRoDtrga0WI0E-9Eb7-CHeBlMDiYho=.ba41750d-a7bc-4535-879e-052919ad3cbd@github.com>
References: <9gURgNbbZoa-8XRoDtrga0WI0E-9Eb7-CHeBlMDiYho=.ba41750d-a7bc-4535-879e-052919ad3cbd@github.com>
Message-ID: <Vjzn_GVyk87bWoRuixGqXW5C9rZBickfsqUhJMgydjo=.d780bea6-0ddb-43bb-a8eb-bbc2145304a3@github.com>

On Wed, 13 Oct 2021 17:02:03 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> InterpolationQualityTest.java test fails consistently on windows 10 hence adding it in the problemList.
> 
> @shurymury

Yes I was also very surprised to see this stable test fail.

FWIW 
- when connecting by VNC the VM doesn't enumerate a display adapter in Device Manager
- when connecting by RDP it lists an RDP software one
It is quite funny actually, connecting via RDP when  you were already logged in by VNC you can see it kill the VNC session and the "open" Device Manager quickly refreshes and removes the display adapter.


BOTH seem to claim D3D is supported and enabled by default for 2D 
So right now I'm assuming this isn't an adapter on which we'd want to enable D3D and that's why the test fails.

It will take a debugging build to understand what we see in start up that causes 2d to enable the D3D pipeline here.
I am not sure it can be intentional as I have no recollection of that ever being something we would want to do.

This is a blocker for using available VMs for testing.
So until we figure it out then either we PL the test on windows, or we have to update all these lines
below in the test to include -Dsun.java2d.d3d=false

 * @run main/othervm -Dsun.java2d.uiScale=1 -Dsun.java2d.xrender=false InterpolationQualityTest
 * @run main/othervm -Dsun.java2d.uiScale=1 -Dsun.java2d.xrender=True InterpolationQualityTest
 * @run main/othervm -Dsun.java2d.uiScale=1 -Dsun.java2d.d3d=false InterpolationQualityTest
 * @run main/othervm -Dsun.java2d.uiScale=1 -Dsun.java2d.d3d=True InterpolationQualityTest
 * @run main/othervm -Dsun.java2d.uiScale=1 InterpolationQualityTest


BTW we probably need a better way of doing this because where a setting doesn't apply to a platform its a no-op
So on both Windows and Linux we are running this 4 times in the "default" mode and once in another in non-default and then
on Mac 5 times in the same default mode  .. and not covering metal there FWIW.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5930


From duke at openjdk.java.net  Thu Oct 14 18:21:14 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Thu, 14 Oct 2021 18:21:14 GMT
Subject: RFR: 8185429: [macos] After the dialog is closed,
 there is no window become active.
Message-ID: <Yd__4DRz1fmgZ7IOS9WdD3EHUC78u8BMV17MG51Beak=.34e38af4-32fa-4d83-b628-4266eddf1733@github.com>

After a modal dialog is closed, its parent window should be pushed to the front and made key.

-------------

Commit messages:
 - removed from ProblemList.txt
 - 8185429: [macos] After the dialog is closed, there is no window become active.

Changes: https://git.openjdk.java.net/jdk/pull/5884/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5884&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8185429
  Stats: 5 lines in 2 files changed: 4 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5884.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5884/head:pull/5884

PR: https://git.openjdk.java.net/jdk/pull/5884


From vdyakov at openjdk.java.net  Thu Oct 14 18:21:14 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Thu, 14 Oct 2021 18:21:14 GMT
Subject: RFR: 8185429: [macos] After the dialog is closed,
 there is no window become active.
In-Reply-To: <Yd__4DRz1fmgZ7IOS9WdD3EHUC78u8BMV17MG51Beak=.34e38af4-32fa-4d83-b628-4266eddf1733@github.com>
References: <Yd__4DRz1fmgZ7IOS9WdD3EHUC78u8BMV17MG51Beak=.34e38af4-32fa-4d83-b628-4266eddf1733@github.com>
Message-ID: <TXrN7us2i-8cEXbGF1ZkWpxeXEPP7S-7ml18rENaeTg=.6038b57a-7a5a-493d-ad6e-b1bb2f6e8a0c@github.com>

On Sun, 10 Oct 2021 21:26:05 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

> After a modal dialog is closed, its parent window should be pushed to the front and made key.

@prsadhuk please review

@azuev-java   please review

this JBS ID is referenced in the problem list, so the problem list file should be updated as part of the fix

-------------

PR: https://git.openjdk.java.net/jdk/pull/5884


From kcr at openjdk.java.net  Thu Oct 14 18:21:14 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 14 Oct 2021 18:21:14 GMT
Subject: RFR: 8185429: [macos] After the dialog is closed,
 there is no window become active.
In-Reply-To: <Yd__4DRz1fmgZ7IOS9WdD3EHUC78u8BMV17MG51Beak=.34e38af4-32fa-4d83-b628-4266eddf1733@github.com>
References: <Yd__4DRz1fmgZ7IOS9WdD3EHUC78u8BMV17MG51Beak=.34e38af4-32fa-4d83-b628-4266eddf1733@github.com>
Message-ID: <7ljWrYPJ9reW6um8kyD323YqV0i95GSQUkSqZ-nMLAw=.9aff4e81-4d75-4b59-a759-0c13b915c56f@github.com>

On Sun, 10 Oct 2021 21:26:05 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

> After a modal dialog is closed, its parent window should be pushed to the front and made key.

The error in the ProblemList reported in the Description is preventing this PR from being `rfr`. I filed [SKARA-1217](https://bugs.openjdk.java.net/browse/SKARA-1217) to track changing the bot to consider this error as an integration blocker, but not something that will stop a PR from being `rfr`.

@alisenchung you will need to remove this bug ID from the ProblemList (after verifying that the problem-listed tests pass).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5884


From serb at openjdk.java.net  Thu Oct 14 18:21:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 14 Oct 2021 18:21:15 GMT
Subject: RFR: 8185429: [macos] After the dialog is closed,
 there is no window become active.
In-Reply-To: <Yd__4DRz1fmgZ7IOS9WdD3EHUC78u8BMV17MG51Beak=.34e38af4-32fa-4d83-b628-4266eddf1733@github.com>
References: <Yd__4DRz1fmgZ7IOS9WdD3EHUC78u8BMV17MG51Beak=.34e38af4-32fa-4d83-b628-4266eddf1733@github.com>
Message-ID: <pi7w46zFyJNqHhS-vo7JVCN3QMcyCuLXfb5zZ4EiuCM=.7b958aa7-35de-406c-ad09-ca0a94eb2a9f@github.com>

On Sun, 10 Oct 2021 21:26:05 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

> After a modal dialog is closed, its parent window should be pushed to the front and made key.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 1032:

> 1030:             execute(ptr -> nativePushNSWindowToFront(ptr));
> 1031:         }
> 1032: 

Do not we need to push the previously blocked window upfront only if the blocker window was active?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5884


From duke at openjdk.java.net  Thu Oct 14 18:21:16 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Thu, 14 Oct 2021 18:21:16 GMT
Subject: RFR: 8185429: [macos] After the dialog is closed,
 there is no window become active.
In-Reply-To: <pi7w46zFyJNqHhS-vo7JVCN3QMcyCuLXfb5zZ4EiuCM=.7b958aa7-35de-406c-ad09-ca0a94eb2a9f@github.com>
References: <Yd__4DRz1fmgZ7IOS9WdD3EHUC78u8BMV17MG51Beak=.34e38af4-32fa-4d83-b628-4266eddf1733@github.com>
 <pi7w46zFyJNqHhS-vo7JVCN3QMcyCuLXfb5zZ4EiuCM=.7b958aa7-35de-406c-ad09-ca0a94eb2a9f@github.com>
Message-ID: <-MUOq50MjJJwA1-xqkUHGaOGqS4sjzQDFQD0u8GSuPY=.e4e8977c-175e-4ce4-84af-dfd00ee40f1d@github.com>

On Sun, 10 Oct 2021 22:06:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> After a modal dialog is closed, its parent window should be pushed to the front and made key.
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 1032:
> 
>> 1030:             execute(ptr -> nativePushNSWindowToFront(ptr));
>> 1031:         }
>> 1032: 
> 
> Do not we need to push the previously blocked window upfront only if the blocker window was active?

Yea, that makes sense. I'm stuck on how to check for whether the blocker window was in focus since by the time setModalBlocked(false) is called the blocker window is no longer in focus. Do you have any suggestions on how to approach this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5884


From serb at openjdk.java.net  Thu Oct 14 18:21:16 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 14 Oct 2021 18:21:16 GMT
Subject: RFR: 8185429: [macos] After the dialog is closed,
 there is no window become active.
In-Reply-To: <-MUOq50MjJJwA1-xqkUHGaOGqS4sjzQDFQD0u8GSuPY=.e4e8977c-175e-4ce4-84af-dfd00ee40f1d@github.com>
References: <Yd__4DRz1fmgZ7IOS9WdD3EHUC78u8BMV17MG51Beak=.34e38af4-32fa-4d83-b628-4266eddf1733@github.com>
 <pi7w46zFyJNqHhS-vo7JVCN3QMcyCuLXfb5zZ4EiuCM=.7b958aa7-35de-406c-ad09-ca0a94eb2a9f@github.com>
 <-MUOq50MjJJwA1-xqkUHGaOGqS4sjzQDFQD0u8GSuPY=.e4e8977c-175e-4ce4-84af-dfd00ee40f1d@github.com>
Message-ID: <BbMpZlSETmu-o6Uv8xv4Mk3rrNdZdkKY69u7JOARvuo=.69facc2a-c9ad-4153-8b10-eb02f80b16a7@github.com>

On Wed, 13 Oct 2021 18:48:50 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

>> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 1032:
>> 
>>> 1030:             execute(ptr -> nativePushNSWindowToFront(ptr));
>>> 1031:         }
>>> 1032: 
>> 
>> Do not we need to push the previously blocked window upfront only if the blocker window was active?
>
> Yea, that makes sense. I'm stuck on how to check for whether the blocker window was in focus since by the time setModalBlocked(false) is called the blocker window is no longer in focus. Do you have any suggestions on how to approach this?

probably it is possible to save the state of the closed dialog before closing it and pass it here? This class is not a public API you can change the parameters in these methods.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5884


From duke at openjdk.java.net  Thu Oct 14 18:26:49 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Thu, 14 Oct 2021 18:26:49 GMT
Subject: RFR: 8185429: [macos] After the dialog is closed,
 there is no window become active.
In-Reply-To: <BbMpZlSETmu-o6Uv8xv4Mk3rrNdZdkKY69u7JOARvuo=.69facc2a-c9ad-4153-8b10-eb02f80b16a7@github.com>
References: <Yd__4DRz1fmgZ7IOS9WdD3EHUC78u8BMV17MG51Beak=.34e38af4-32fa-4d83-b628-4266eddf1733@github.com>
 <pi7w46zFyJNqHhS-vo7JVCN3QMcyCuLXfb5zZ4EiuCM=.7b958aa7-35de-406c-ad09-ca0a94eb2a9f@github.com>
 <-MUOq50MjJJwA1-xqkUHGaOGqS4sjzQDFQD0u8GSuPY=.e4e8977c-175e-4ce4-84af-dfd00ee40f1d@github.com>
 <BbMpZlSETmu-o6Uv8xv4Mk3rrNdZdkKY69u7JOARvuo=.69facc2a-c9ad-4153-8b10-eb02f80b16a7@github.com>
Message-ID: <VnK2qm2qArBpHjDijQduFm-UgwiBnGxcKUPJXjMaewA=.34cf3ab7-a139-41f6-93e9-2877832b3bd4@github.com>

On Wed, 13 Oct 2021 20:02:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yea, that makes sense. I'm stuck on how to check for whether the blocker window was in focus since by the time setModalBlocked(false) is called the blocker window is no longer in focus. Do you have any suggestions on how to approach this?
>
> probably it is possible to save the state of the closed dialog before closing it and pass it here? This class is not a public API you can change the parameters in these methods.

I wasn't able to find when or where the dialog ever becomes active, and I actually think now that it never does become active window. I checked Apple's documentation on NSPrintPanel and turns out that it doesn't even inherit from NSPanel nor NSWindow so it can never become a key window (active status). Looks like it should be safe to not check for active status because a print dialog popup should block all other windows in the application anyway, so it will always be "active" window.

https://developer.apple.com/documentation/appkit/nsprintpanel?language=objc

This is also the case for page setup and NSPageLayout.

https://developer.apple.com/documentation/appkit/nspagelayout?language=objc

-------------

PR: https://git.openjdk.java.net/jdk/pull/5884


From duke at openjdk.java.net  Thu Oct 14 18:39:50 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Thu, 14 Oct 2021 18:39:50 GMT
Subject: RFR: 8262945: [macos] Regression Manual Test for Key Events Fails
 [v3]
In-Reply-To: <k-0hmzZ-NTF8KavFyuo1m4RxJZjfB4b2INfWOwXX6JQ=.f34b98cd-5708-4a0e-96e0-0f6276fdc8eb@github.com>
References: <LhSIteG6WssDHH2if3oeA-0qLZGhxfqb11JyTC4EPh8=.b8b62eb4-a50c-4eb2-98c7-6f122f87d08b@github.com>
 <k-0hmzZ-NTF8KavFyuo1m4RxJZjfB4b2INfWOwXX6JQ=.f34b98cd-5708-4a0e-96e0-0f6276fdc8eb@github.com>
Message-ID: <QhCijU4cfD17lZhMmREYLm3sfr2163OlKE5A2rgROc4=.d381b287-c2e0-4795-8bc1-4fd4d3ab8c26@github.com>

On Mon, 27 Sep 2021 16:19:21 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

>> Added a check for active keyboard language and added support for Russian NSEvent keyCodes to JavaVirtualKeyCode translation. Originally, only English characters were checked for even if other languages were in native letterCharacterSet. Can be easily expanded to include other languages as well.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding comment explaining offset numbers

Comments have been added for the 0x10000000 value (from ExtendedKeyCodes.java)

-------------

PR: https://git.openjdk.java.net/jdk/pull/5617


From prr at openjdk.java.net  Thu Oct 14 18:46:52 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 14 Oct 2021 18:46:52 GMT
Subject: RFR: 8275165 : ProblemList InterpolationQualityTest.java
In-Reply-To: <9gURgNbbZoa-8XRoDtrga0WI0E-9Eb7-CHeBlMDiYho=.ba41750d-a7bc-4535-879e-052919ad3cbd@github.com>
References: <9gURgNbbZoa-8XRoDtrga0WI0E-9Eb7-CHeBlMDiYho=.ba41750d-a7bc-4535-879e-052919ad3cbd@github.com>
Message-ID: <tLr-8wpralivVLAqPg5Yu7NzhLuJk7dssEVoQMajLww=.a8e1d560-637a-4886-a836-f5e6d933b509@github.com>

On Wed, 13 Oct 2021 17:02:03 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> InterpolationQualityTest.java test fails consistently on windows 10 hence adding it in the problemList.
> 
> @shurymury

So the way the check is done, we exclude D3D if it is known to be bad hardware. ie it is an exclude list, not an include list.
I suspect the vendorID and/or deviceID are being passed through as unknown so supported until told otherwise.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5930


From prr at openjdk.java.net  Thu Oct 14 20:54:48 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 14 Oct 2021 20:54:48 GMT
Subject: RFR: 8275165 : ProblemList InterpolationQualityTest.java
In-Reply-To: <9gURgNbbZoa-8XRoDtrga0WI0E-9Eb7-CHeBlMDiYho=.ba41750d-a7bc-4535-879e-052919ad3cbd@github.com>
References: <9gURgNbbZoa-8XRoDtrga0WI0E-9Eb7-CHeBlMDiYho=.ba41750d-a7bc-4535-879e-052919ad3cbd@github.com>
Message-ID: <_mgz0gZAB5FAIIWJSj3HhfvS5vaR_6z69LZcShrphHY=.a6b252dc-6010-4769-84b5-e4111a72ea8d@github.com>

On Wed, 13 Oct 2021 17:02:03 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> InterpolationQualityTest.java test fails consistently on windows 10 hence adding it in the problemList.
> 
> @shurymury

So it reports the Microsoft Basic Render Driver ..

-------------

PR: https://git.openjdk.java.net/jdk/pull/5930


From philip.race at oracle.com  Fri Oct 15 00:07:07 2021
From: philip.race at oracle.com (Philip Race)
Date: Thu, 14 Oct 2021 17:07:07 -0700
Subject: Result : CFV: New Client Libraries Group Member : Prasanta Sadhukhan
 (psadhukhan)
Message-ID: <afb932b1-7e23-c908-a192-ecf951ab82ff@oracle.com>

The vote for Prasanta Sadhukhan [1] is now closed.

Yes: 4
Veto: 0
Abstain: 0

According to the OpenJDK Bylaws definition of Lazy Consensus [2],
this is sufficient to approve the nomination.

-phil.

[1] 
https://mail.openjdk.java.net/pipermail/client-libs-dev/2021-September/000502.html
[2] http://openjdk.java.net/bylaws#lazy-consensus


From philip.race at oracle.com  Fri Oct 15 00:07:22 2021
From: philip.race at oracle.com (Philip Race)
Date: Thu, 14 Oct 2021 17:07:22 -0700
Subject: Result: CFV: New Client Libraries Group Member : Pankaj Bansal
 (pbansal)
Message-ID: <899c0c5a-2800-e002-73e0-9063bd6dadbd@oracle.com>

The vote for Pankaj Bansal? [1] is now closed.

Yes: 4
Veto: 0
Abstain: 0

According to the OpenJDK Bylaws definition of Lazy Consensus [2],
this is sufficient to approve the nomination.

-phil.

[1] 
https://mail.openjdk.java.net/pipermail/client-libs-dev/2021-September/000503.html
[2] http://openjdk.java.net/bylaws#lazy-consensus


From serb at openjdk.java.net  Fri Oct 15 02:25:54 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 15 Oct 2021 02:25:54 GMT
Subject: Integrated: 8041125: ColorConvertOp filter much slower in JDK 8
 compared to JDK7
In-Reply-To: <01oQmcaxpb_DFPCTQS_ek2CnCbEJRCNODsZNF7KR8t0=.9e9f761d-0c08-40de-bc8b-fcc612da9d2e@github.com>
References: <01oQmcaxpb_DFPCTQS_ek2CnCbEJRCNODsZNF7KR8t0=.9e9f761d-0c08-40de-bc8b-fcc612da9d2e@github.com>
Message-ID: <AlWMRxA92x3vCh04OQ8gz6THyCiVe1P6jENXhIAWkPs=.89f648ae-623f-4423-9b06-84e02fd44ab6@github.com>

On Wed, 6 Oct 2021 08:41:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> We have improved the cmm code over a few releases and mostly resolve the JDK-8041125. But I have executed an attached test case under a profiler and found that:
> 
> * less than 10% is an actual pixel transformation inside littlecms
> * 30% is a native up-calls like getXXField
> * 30% is incoming arrays coping
> * 30% results array saving
> * others
> 
> This change removes the native up-calls and passes all data from the java side.
> 
> Notes:
> 
> * The above numbers are true for the "pure Java" implementation in the test case, where we transform the image pixel by pixel, if the image is big and we transform it at once via filter then we spend most of the time in the littlecms code
> * JDK7 uses 4 threads in the filter implementation, but single-threaded jdk17 is faster because of some code improvement in cmm profiles initialization during the "cold start". And probably because the image is not so big(625x843).
> * If the size of the image will be increased and the warmup is done the jdk7 will be 4x time faster, this is another opportunity that I'll try to resolve later.
> 
> 
> Tested on macOS (fastest result after a few runs):
> ||JDK 7 | JDK 8 | JDK 17 | FIX |
> |----|----|----|----|----|
> |With filter |  307 ms  |  456 ms  |  242 ms  |   236 ms |
> |In pure Java|  1672 ms  |  389 ms  |  300 ms  |  259 ms  |
> 
> 
> JMH before/after the fix
> `ColorSpace.toRGB/fromRGB/toCIEXYZ/fromCIEXYZ(new float[]{1,1,1})`
> single threaded and multi-threaded(MAX = 30):
> ![image](https://user-images.githubusercontent.com/14138494/136283699-05e47dca-e7f8-43a1-97d3-53072d3589f6.png)
> 
> https://jmh.morethan.io/?gists=b1edd5e5ebeb1b76867b2112be30145d,fc86ce4a6f8f2f49e9ab512ef641c11b

This pull request has now been integrated.

Changeset: c355704a
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c355704a4b3d376b5429daba1576442b575f41ea
Stats:     137 lines in 4 files changed: 9 ins; 101 del; 27 mod

8041125: ColorConvertOp filter much slower in JDK 8 compared to JDK7

Reviewed-by: prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/5835


From pbansal at openjdk.java.net  Fri Oct 15 05:43:51 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 15 Oct 2021 05:43:51 GMT
Subject: RFR: 8271071 accessibility of a table on macOS lacks cell
 navigation [v5]
In-Reply-To: <CRrvnV9hDhLkjGogdXZbBbBw3oiYR0NYJWVfINBBNRU=.1f615936-0df8-4cb9-9071-9eb565b8a7df@github.com>
References: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
 <CRrvnV9hDhLkjGogdXZbBbBw3oiYR0NYJWVfINBBNRU=.1f615936-0df8-4cb9-9071-9eb565b8a7df@github.com>
Message-ID: <GssoRX7Q3TXje65OxPjm7nUSew-cRDqV8fqRHPrzjs0=.2c9316c2-dc23-4982-ae42-4a5f114cf12f@github.com>

On Thu, 30 Sep 2021 12:02:08 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> We've extended the current implementation of TableAccessibility to make sure that individual cells are voiced when navigating with the keyboard.
>
> Artem Semenov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

I tested the table accessibility during cell navigation and it looks fine. I have given minor comment, but this fix looks good overall.

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.m line 235:

> 233:         for (NSNumber *col in selectedColumns ) {
> 234:             CellAccessibility *cell = [self accessibilityCellForColumn:[col integerValue] row:[row integerValue]];
> 235: //            if ([self isAccessibleChildSelectedFromIndex:[cell accessibilityIndex]]) {

Can we just get rid of these lines instead of commenting the code unless there is specific reason to do it like this?

-------------

Marked as reviewed by pbansal (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5466


From pbansal at openjdk.java.net  Fri Oct 15 06:15:48 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 15 Oct 2021 06:15:48 GMT
Subject: RFR: 8275106: Cleanup Iterator usages in java.desktop
In-Reply-To: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
References: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
Message-ID: <4E4MEHcmE5532FqWb3v06usYf8nPv8CsozbUuDDY4y8=.18206b5f-9c49-4894-a42d-0bf2d8a85400@github.com>

On Fri, 8 Oct 2021 19:37:35 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Cycles with 'Iterator' are error-prone. It's better to use more high-level code, which easier to read.
> We can use enhanced-for or Collection.removeIf

Marked as reviewed by pbansal (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5871


From duke at openjdk.java.net  Fri Oct 15 07:12:51 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 15 Oct 2021 07:12:51 GMT
Subject: Integrated: 8275106: Cleanup Iterator usages in java.desktop
In-Reply-To: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
References: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
Message-ID: <Wawivc3EC_OHayAriUG7yCOxebMAg0y9c7DtxHm5Xr0=.fbe7d3a1-f68f-41e6-b049-14d4842dcfea@github.com>

On Fri, 8 Oct 2021 19:37:35 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Cycles with 'Iterator' are error-prone. It's better to use more high-level code, which easier to read.
> We can use enhanced-for or Collection.removeIf

This pull request has now been integrated.

Changeset: 322b1301
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Pankaj Bansal <pbansal at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/322b1301061ba113dc5f7f3710dde2d80a18a14e
Stats:     115 lines in 18 files changed: 5 ins; 62 del; 48 mod

8275106: Cleanup Iterator usages in java.desktop

Reviewed-by: serb, pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/5871


From asemenov at openjdk.java.net  Fri Oct 15 09:55:16 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Fri, 15 Oct 2021 09:55:16 GMT
Subject: RFR: 8271071 accessibility of a table on macOS lacks cell
 navigation [v6]
In-Reply-To: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
References: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
Message-ID: <9uLHM4szRyAbcOC3XxnFmSLV5qbM5gNjT_rOVSLE0hs=.263ce03e-0cb9-49c2-bbd2-83db90fe7279@github.com>

> We've extended the current implementation of TableAccessibility to make sure that individual cells are voiced when navigating with the keyboard.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  Can we just get rid of these lines instead of commenting the code?

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5466/files
  - new: https://git.openjdk.java.net/jdk/pull/5466/files/248e2c64..31d55af4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5466&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5466&range=04-05

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5466.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5466/head:pull/5466

PR: https://git.openjdk.java.net/jdk/pull/5466


From asemenov at openjdk.java.net  Fri Oct 15 09:55:18 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Fri, 15 Oct 2021 09:55:18 GMT
Subject: RFR: 8271071 accessibility of a table on macOS lacks cell
 navigation [v5]
In-Reply-To: <GssoRX7Q3TXje65OxPjm7nUSew-cRDqV8fqRHPrzjs0=.2c9316c2-dc23-4982-ae42-4a5f114cf12f@github.com>
References: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
 <CRrvnV9hDhLkjGogdXZbBbBw3oiYR0NYJWVfINBBNRU=.1f615936-0df8-4cb9-9071-9eb565b8a7df@github.com>
 <GssoRX7Q3TXje65OxPjm7nUSew-cRDqV8fqRHPrzjs0=.2c9316c2-dc23-4982-ae42-4a5f114cf12f@github.com>
Message-ID: <O-QxsaMHJhZNvHcVbk-HccpkU27XROxQMOr7PL-PFrM=.d3f12500-ad5b-40c2-982d-e7075a1cd952@github.com>

On Fri, 15 Oct 2021 05:38:12 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> Artem Semenov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.m line 235:
> 
>> 233:         for (NSNumber *col in selectedColumns ) {
>> 234:             CellAccessibility *cell = [self accessibilityCellForColumn:[col integerValue] row:[row integerValue]];
>> 235: //            if ([self isAccessibleChildSelectedFromIndex:[cell accessibilityIndex]]) {
> 
> Can we just get rid of these lines instead of commenting the code unless there is specific reason to do it like this?

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/5466


From asemenov at openjdk.java.net  Fri Oct 15 09:55:18 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Fri, 15 Oct 2021 09:55:18 GMT
Subject: Integrated: 8271071 accessibility of a table on macOS lacks cell
 navigation
In-Reply-To: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
References: <dYyU_qCNvlNpoFXQhvBgPoSIXlghDuFsLg5A2BkcLrM=.d0bd78c6-58f4-431c-8a9e-21b6646401da@github.com>
Message-ID: <gE_HelwxW9HvsA9wZ8Yd6OXRps91UdncFzSzVInFYn4=.b93e5acc-c3cd-4b0d-ade1-ee2b0c42bbda@github.com>

On Fri, 10 Sep 2021 15:11:20 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> We've extended the current implementation of TableAccessibility to make sure that individual cells are voiced when navigating with the keyboard.

This pull request has now been integrated.

Changeset: c0f3e1d6
Author:    Artem Semenov <asemenov at openjdk.org>
Committer: Anton Tarasov <ant at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c0f3e1d6beab94a6b361814585b6d77fa617e7e4
Stats:     115 lines in 6 files changed: 77 ins; 30 del; 8 mod

8271071: accessibility of a table on macOS lacks cell navigation

Reviewed-by: ant, kizune, pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/5466


From myano at openjdk.java.net  Fri Oct 15 11:09:26 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 15 Oct 2021 11:09:26 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails [v2]
In-Reply-To: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
Message-ID: <rPnwSUK5os-UosusAicJMekZup50FucJbREshLrg9yw=.e1cd3257-b0be-4790-b746-74044ba35046@github.com>

> Could you please review the 7001973 fixes?
> 
> On Windows, CopyAreaOOB.java fails with a blank window. The cause of this problem is that paint() works one time only. Painting area is not guaranteed when showing a window.
> 
> I think this behavior should be removed for purpose of this test (`@summary: Verifies that copyArea() works properly`). Also, this program uses a Robot, but implements waiting logic by itself. This logic should be replaced to Robot API.
> 
> This fix works fine in Windows, so this test can be removed from ProblemList.txt. I don't have a Mac environment, so can someone please confirm that this fix will work on Mac?

Masanori Yano has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
 - Merge branch 'master' of https://github.com/masyano/jdk into 7001973
 - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
 - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5491/files
  - new: https://git.openjdk.java.net/jdk/pull/5491/files/9b3f57a2..52c5ca79

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5491&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5491&range=00-01

  Stats: 54722 lines in 1656 files changed: 35144 ins; 11674 del; 7904 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5491.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5491/head:pull/5491

PR: https://git.openjdk.java.net/jdk/pull/5491


From myano at openjdk.java.net  Fri Oct 15 11:09:27 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 15 Oct 2021 11:09:27 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
In-Reply-To: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
Message-ID: <aANIdnPPcxa_-aAG_BLemSZR-4WTrQODraNF9qhcTJs=.46d296b9-4340-436d-8f2e-fb1f41b4da20@github.com>

On Mon, 13 Sep 2021 11:32:37 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the 7001973 fixes?
> 
> On Windows, CopyAreaOOB.java fails with a blank window. The cause of this problem is that paint() works one time only. Painting area is not guaranteed when showing a window.
> 
> I think this behavior should be removed for purpose of this test (`@summary: Verifies that copyArea() works properly`). Also, this program uses a Robot, but implements waiting logic by itself. This logic should be replaced to Robot API.
> 
> This fix works fine in Windows, so this test can be removed from ProblemList.txt. I don't have a Mac environment, so can someone please confirm that this fix will work on Mac?

I understood what you wanted to test.

I think all paint events can be examined by only checking at the end of paint(). So I moved checkRegion into paint() part. It also works fine in case of multi paint events happen when restoring Frame from the iconified status to normal status.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5491


From dmarkov at openjdk.java.net  Fri Oct 15 11:35:53 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Fri, 15 Oct 2021 11:35:53 GMT
Subject: RFR: 8185429: [macos] After the dialog is closed,
 there is no window become active.
In-Reply-To: <VnK2qm2qArBpHjDijQduFm-UgwiBnGxcKUPJXjMaewA=.34cf3ab7-a139-41f6-93e9-2877832b3bd4@github.com>
References: <Yd__4DRz1fmgZ7IOS9WdD3EHUC78u8BMV17MG51Beak=.34e38af4-32fa-4d83-b628-4266eddf1733@github.com>
 <pi7w46zFyJNqHhS-vo7JVCN3QMcyCuLXfb5zZ4EiuCM=.7b958aa7-35de-406c-ad09-ca0a94eb2a9f@github.com>
 <-MUOq50MjJJwA1-xqkUHGaOGqS4sjzQDFQD0u8GSuPY=.e4e8977c-175e-4ce4-84af-dfd00ee40f1d@github.com>
 <BbMpZlSETmu-o6Uv8xv4Mk3rrNdZdkKY69u7JOARvuo=.69facc2a-c9ad-4153-8b10-eb02f80b16a7@github.com>
 <VnK2qm2qArBpHjDijQduFm-UgwiBnGxcKUPJXjMaewA=.34cf3ab7-a139-41f6-93e9-2877832b3bd4@github.com>
Message-ID: <cQ1dnS5xNraMU3-1_MMOV5PUZNmfoK_xUQQqIBgP5jA=.f01cf80e-0f6d-4432-9490-f04e9da96c40@github.com>

On Thu, 14 Oct 2021 18:22:20 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

>> probably it is possible to save the state of the closed dialog before closing it and pass it here? This class is not a public API you can change the parameters in these methods.
>
> I wasn't able to find when or where the dialog ever becomes active, and I actually think now that it never does become active window. I checked Apple's documentation on NSPrintPanel and turns out that it doesn't even inherit from NSPanel nor NSWindow so it can never become a key window (active status). Looks like it should be safe to not check for active status because a print dialog popup should block all other windows in the application anyway, so it will always be "active" window.
> 
> https://developer.apple.com/documentation/appkit/nsprintpanel?language=objc
> 
> This is also the case for page setup and NSPageLayout.
> 
> https://developer.apple.com/documentation/appkit/nspagelayout?language=objc

Possible way to test whether the blocker window was active before setBlocked(false) call is to store the information about the blocker when the window is blocked, (i.e. during setBlocked(true) call). Once the window is unblocked you need to check that the blocker was the previous focus owner.

As for nativePushNSWindowToFront() call it does not work properly for the case when we have a hierarchy of windows. So I would recommend replacing nativePushNSWindowToFront() with orderAboveSiblings().

-------------

PR: https://git.openjdk.java.net/jdk/pull/5884


From azvegint at openjdk.java.net  Fri Oct 15 14:07:58 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 15 Oct 2021 14:07:58 GMT
Subject: Integrated: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing
In-Reply-To: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
Message-ID: <UISM0m2UyDXYAMVpUpMDLeWPwkH2bD3yRJaUWq-d9pQ=.f2fa91bc-eee2-4175-ba73-29b322425880@github.com>

On Mon, 4 Oct 2021 14:54:27 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.

This pull request has now been integrated.

Changeset: da8da3a1
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/da8da3a16148a750ce502f7b7281fe289acaef40
Stats:     8 lines in 1 file changed: 5 ins; 0 del; 3 mod

8269698: Specification for methods of java.awt.im.InputContext should mention that they do nothing

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/5806


From martin.desruisseaux at geomatys.com  Fri Oct 15 15:10:49 2021
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Fri, 15 Oct 2021 17:10:49 +0200
Subject: RasterFormatException thrown when drawing a tiled image made of
 non-writable rasters
Message-ID: <a934d35d-4266-3eb9-ab43-75e8f0939ed0@geomatys.com>

Hello all

Call to Graphics2D.drawRenderedImage(RenderedImage, AffineTransform) 
fails if the image contains more than one tile (or a single tile not 
located at 0,0) and the tiles are not instances of WritableRaster (i.e. 
are instances of the read-only Raster parent class). A test case [1] 
reproduces this issue. The bug is demonstrated by drawing the same image 
twice: once with WritableRaster tiles (which succeed), then the same 
operation where the only change is the use of Raster tiles. The 
exception is:

Exception in thread "main" java.awt.image.RasterFormatException: (parentX + width) is outside raster
     at java.desktop/java.awt.image.WritableRaster.createWritableChild(WritableRaster.java:228)
     at java.desktop/sun.java2d.SunGraphics2D.drawTranslatedRenderedImage(SunGraphics2D.java:2852)
     at java.desktop/sun.java2d.SunGraphics2D.drawRenderedImage(SunGraphics2D.java:2711)

The cause is in the following code in SunGraphics2D:

// Create a WritableRaster containing the tile
WritableRaster wRaster = null;
if (raster instanceof WritableRaster) {
     wRaster = (WritableRaster)raster;
} else {
     // Create a WritableRaster in the same coordinate system
     // as the original raster.
     wRaster =
         Raster.createWritableRaster(raster.getSampleModel(),
                                     raster.getDataBuffer(),
                                     null);
}
// Translate wRaster to start at (0, 0) and to contain
// only the relevent portion of the tile
wRaster = wRaster.createWritableChild(tileRect.x, tileRect.y,
                                       tileRect.width,
                                       tileRect.height,
                                       0, 0,
                                       null);

If the tile is not an instance of WritableRaster, then the code wraps 
the tile DataBuffer in a new WritableRaster*but with a location set to 
(0,0)*, because the location argument in createWritableRaster(?) call is 
null. Then the call to createWritableChild(?) applies a translation for 
bringing the tile location to (0,0). But in the case where the raster 
has been converted from Raster to WritableRaster, that translation has 
already been applied, and the effect of current code is to apply the 
translation twice.

I think that this bug has been largely unnoticed because most users use 
BufferedImage, which has a single tile always located at (0,0), and the 
minority of developers using their own RenderedImage implementation uses 
WritableRaster instances, because Raster.create(?) methods provide 
optimizations for common cases which result in WritableRaster instances 
created even when the user asked only for a Raster. To make this bug 
apparent, it is necessary to invoke Raster.createRaster(?) with a sample 
model for which no optimization is provided.

The commit at [1] provides a test case and a suggested fix. From that 
point, I'm not sure how to proceed (I'm sure there is many steps, that 
the proposed commit needs to be modified, etc.). Can anyone can give me 
some hints?

 ??? Regards,

 ??? ??? Martin

[1]https://github.com/Geomatys/jdk/commit/94242a05ff8b9c1af603a11133af7c6016c9e833


From philip.race at oracle.com  Fri Oct 15 16:28:51 2021
From: philip.race at oracle.com (Philip Race)
Date: Fri, 15 Oct 2021 09:28:51 -0700
Subject: RasterFormatException thrown when drawing a tiled image made of
 non-writable rasters
In-Reply-To: <a934d35d-4266-3eb9-ab43-75e8f0939ed0@geomatys.com>
References: <a934d35d-4266-3eb9-ab43-75e8f0939ed0@geomatys.com>
Message-ID: <711bc9aa-f0c4-1de6-d7d2-541f90b8ea6e@oracle.com>

Hi Martin,

You? do show up on the list of folks who have signed the OCA so the 
process is to submit a bug
and then a PR referencing it at https://github.com/openjdk/jdk following 
the process at https://openjdk.java.net/guide/
I don't see that you have a JBS (https://bugs.openjdk.java.net/) account 
so I can submit the bug for you
if needed or (better for me) you can submit it yourself at 
https://bugreport.java.com/bugreport/ and
let me know the ID and I can convert it into a JBS bug.

-phil

On 10/15/21 8:10 AM, Martin Desruisseaux wrote:
> Hello all
>
> Call to Graphics2D.drawRenderedImage(RenderedImage, AffineTransform) 
> fails if the image contains more than one tile (or a single tile not 
> located at 0,0) and the tiles are not instances of WritableRaster 
> (i.e. are instances of the read-only Raster parent class). A test case 
> [1] reproduces this issue. The bug is demonstrated by drawing the same 
> image twice: once with WritableRaster tiles (which succeed), then the 
> same operation where the only change is the use of Raster tiles. The 
> exception is:
>
> Exception in thread "main" java.awt.image.RasterFormatException: 
> (parentX + width) is outside raster
> ??? at 
> java.desktop/java.awt.image.WritableRaster.createWritableChild(WritableRaster.java:228)
> ??? at 
> java.desktop/sun.java2d.SunGraphics2D.drawTranslatedRenderedImage(SunGraphics2D.java:2852)
> ??? at 
> java.desktop/sun.java2d.SunGraphics2D.drawRenderedImage(SunGraphics2D.java:2711)
>
> The cause is in the following code in SunGraphics2D:
>
> // Create a WritableRaster containing the tile
> WritableRaster wRaster = null;
> if (raster instanceof WritableRaster) {
> ??? wRaster = (WritableRaster)raster;
> } else {
> ??? // Create a WritableRaster in the same coordinate system
> ??? // as the original raster.
> ??? wRaster =
> ??????? Raster.createWritableRaster(raster.getSampleModel(),
> ??????????????????????????????????? raster.getDataBuffer(),
> ??????????????????????????????????? null);
> }
> // Translate wRaster to start at (0, 0) and to contain
> // only the relevent portion of the tile
> wRaster = wRaster.createWritableChild(tileRect.x, tileRect.y,
> ????????????????????????????????????? tileRect.width,
> ????????????????????????????????????? tileRect.height,
> ????????????????????????????????????? 0, 0,
> ????????????????????????????????????? null);
>
> If the tile is not an instance of WritableRaster, then the code wraps 
> the tile DataBuffer in a new WritableRaster*but with a location set to 
> (0,0)*, because the location argument in createWritableRaster(?) call 
> is null. Then the call to createWritableChild(?) applies a translation 
> for bringing the tile location to (0,0). But in the case where the 
> raster has been converted from Raster to WritableRaster, that 
> translation has already been applied, and the effect of current code 
> is to apply the translation twice.
>
> I think that this bug has been largely unnoticed because most users 
> use BufferedImage, which has a single tile always located at (0,0), 
> and the minority of developers using their own RenderedImage 
> implementation uses WritableRaster instances, because Raster.create(?) 
> methods provide optimizations for common cases which result in 
> WritableRaster instances created even when the user asked only for a 
> Raster. To make this bug apparent, it is necessary to invoke 
> Raster.createRaster(?) with a sample model for which no optimization 
> is provided.
>
> The commit at [1] provides a test case and a suggested fix. From that 
> point, I'm not sure how to proceed (I'm sure there is many steps, that 
> the proposed commit needs to be modified, etc.). Can anyone can give 
> me some hints?
>
> ??? Regards,
>
> ??? ??? Martin
>
> [1]https://github.com/Geomatys/jdk/commit/94242a05ff8b9c1af603a11133af7c6016c9e833 
>



From duke at openjdk.java.net  Fri Oct 15 17:05:10 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Fri, 15 Oct 2021 17:05:10 GMT
Subject: RFR: 8185429: [macos] After the dialog is closed,
 there is no window become active. [v2]
In-Reply-To: <Yd__4DRz1fmgZ7IOS9WdD3EHUC78u8BMV17MG51Beak=.34e38af4-32fa-4d83-b628-4266eddf1733@github.com>
References: <Yd__4DRz1fmgZ7IOS9WdD3EHUC78u8BMV17MG51Beak=.34e38af4-32fa-4d83-b628-4266eddf1733@github.com>
Message-ID: <tEATq14iJT26W-MdZMdqyB9vIEVhyAElDvPoKndKkGs=.9a2c8c48-314f-47db-9dbd-f463fd137099@github.com>

> After a modal dialog is closed, its parent window should be pushed to the front and made key.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  replaced nativePushNSWindowToFront() with orderAboveSiblings()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5884/files
  - new: https://git.openjdk.java.net/jdk/pull/5884/files/92f63610..001cacbd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5884&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5884&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5884.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5884/head:pull/5884

PR: https://git.openjdk.java.net/jdk/pull/5884


From duke at openjdk.java.net  Fri Oct 15 17:08:49 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Fri, 15 Oct 2021 17:08:49 GMT
Subject: RFR: 8185429: [macos] After the dialog is closed,
 there is no window become active. [v2]
In-Reply-To: <cQ1dnS5xNraMU3-1_MMOV5PUZNmfoK_xUQQqIBgP5jA=.f01cf80e-0f6d-4432-9490-f04e9da96c40@github.com>
References: <Yd__4DRz1fmgZ7IOS9WdD3EHUC78u8BMV17MG51Beak=.34e38af4-32fa-4d83-b628-4266eddf1733@github.com>
 <pi7w46zFyJNqHhS-vo7JVCN3QMcyCuLXfb5zZ4EiuCM=.7b958aa7-35de-406c-ad09-ca0a94eb2a9f@github.com>
 <-MUOq50MjJJwA1-xqkUHGaOGqS4sjzQDFQD0u8GSuPY=.e4e8977c-175e-4ce4-84af-dfd00ee40f1d@github.com>
 <BbMpZlSETmu-o6Uv8xv4Mk3rrNdZdkKY69u7JOARvuo=.69facc2a-c9ad-4153-8b10-eb02f80b16a7@github.com>
 <VnK2qm2qArBpHjDijQduFm-UgwiBnGxcKUPJXjMaewA=.34cf3ab7-a139-41f6-93e9-2877832b3bd4@github.com>
 <cQ1dnS5xNraMU3-1_MMOV5PUZNmfoK_xUQQqIBgP5jA=.f01cf80e-0f6d-4432-9490-f04e9da96c40@github.com>
Message-ID: <-TnY74y9vtqmQjsnjbNrE1ol4YrkoxhTG6X-n-JiIxY=.4329beec-49ff-48bc-b51f-26b8cd22e7c5@github.com>

On Fri, 15 Oct 2021 11:28:32 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> I wasn't able to find when or where the dialog ever becomes active, and I actually think now that it never does become active window. I checked Apple's documentation on NSPrintPanel and turns out that it doesn't even inherit from NSPanel nor NSWindow so it can never become a key window (active status). Looks like it should be safe to not check for active status because a print dialog popup should block all other windows in the application anyway, so it will always be "active" window.
>> 
>> https://developer.apple.com/documentation/appkit/nsprintpanel?language=objc
>> 
>> This is also the case for page setup and NSPageLayout.
>> 
>> https://developer.apple.com/documentation/appkit/nspagelayout?language=objc
>
> Possible way to test whether the blocker window was active before setBlocked(false) call is to store the information about the blocker when the window is blocked, (i.e. during setBlocked(true) call). Once the window is unblocked you need to check that the blocker was the previous focus owner.
> 
> As for nativePushNSWindowToFront() call it does not work properly for the case when we have a hierarchy of windows. So I would recommend replacing nativePushNSWindowToFront() with orderAboveSiblings().

I'm still not able to see when the blocker isActive() is true
Here is some debug outputs when calling setModalBlocked(true) and setModalBlocked(false). In both cases Dialog.isActive() is false. Is there maybe another place where it's true?

`LWWindowPeer setModalBlocked setBlocked: true
LWWindowPeer setModalBlocked blocker: 
sun.lwawt.macosx.CPrinterPageDialog[dialog0,0,-2,80x28,APPLICATION_MODAL,title=]
LWWindowPeer setModalBlocked blocker isActive: false

2021-10-15 09:57:31.447 java[34690:12425514] createDefaultNSPrintInfo
2021-10-15 09:57:31.452 java[34690:12425514] runPageSetup

CPrinterDialogPeer printerDialog isActive: false
Dialog modalHide blocker isActive: false
Dialog modalHide blocker hasFocus: false
Dialog modalHide blocker isFocusOwner: false

LWWindowPeer setModalBlocked setBlocked: false
LWWindowPeer setModalBlocked blocker: sun.lwawt.macosx.CPrinterPageDialog[dialog0,0,25,80x28,APPLICATION_MODAL,title=]
LWWindowPeer setModalBlocked blocker isActive: false`

-------------

PR: https://git.openjdk.java.net/jdk/pull/5884


From martin.desruisseaux at geomatys.com  Fri Oct 15 20:11:33 2021
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Fri, 15 Oct 2021 22:11:33 +0200
Subject: RasterFormatException thrown when drawing a tiled image made of
 non-writable rasters
In-Reply-To: <711bc9aa-f0c4-1de6-d7d2-541f90b8ea6e@oracle.com>
References: <a934d35d-4266-3eb9-ab43-75e8f0939ed0@geomatys.com>
 <711bc9aa-f0c4-1de6-d7d2-541f90b8ea6e@oracle.com>
Message-ID: <82dec70b-ffff-a7ab-c043-2373cfe4d2fc@geomatys.com>

Hello Philip

Le 15/10/2021 ? 18:28, Philip Race a ?crit?:

> I don't see that you have a JBS (https://bugs.openjdk.java.net/) 
> account so I can submit the bug for you if needed or (better for me) 
> you can submit it yourself at https://bugreport.java.com/bugreport/ 
> and let me know the ID and I can convert it into a JBS bug.
>
Thanks. I just submitted it. It got internal review ID 9071685.

 ??? Martin




From philip.race at oracle.com  Fri Oct 15 21:28:17 2021
From: philip.race at oracle.com (Philip Race)
Date: Fri, 15 Oct 2021 14:28:17 -0700
Subject: RasterFormatException thrown when drawing a tiled image made of
 non-writable rasters
In-Reply-To: <82dec70b-ffff-a7ab-c043-2373cfe4d2fc@geomatys.com>
References: <a934d35d-4266-3eb9-ab43-75e8f0939ed0@geomatys.com>
 <711bc9aa-f0c4-1de6-d7d2-541f90b8ea6e@oracle.com>
 <82dec70b-ffff-a7ab-c043-2373cfe4d2fc@geomatys.com>
Message-ID: <7be77f9a-a477-25de-567e-309b1dca54f0@oracle.com>

Now https://bugs.openjdk.java.net/browse/JDK-8275345

-phil

On 10/15/21 1:11 PM, Martin Desruisseaux wrote:
> Hello Philip
>
> Le 15/10/2021 ? 18:28, Philip Race a ?crit?:
>
>> I don't see that you have a JBS (https://bugs.openjdk.java.net/) 
>> account so I can submit the bug for you if needed or (better for me) 
>> you can submit it yourself at https://bugreport.java.com/bugreport/ 
>> and let me know the ID and I can convert it into a JBS bug.
>>
> Thanks. I just submitted it. It got internal review ID 9071685.
>
> ??? Martin
>
>



From serb at openjdk.java.net  Sun Oct 17 00:36:00 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 17 Oct 2021 00:36:00 GMT
Subject: RFR: 8275344: -Xcheck:jni produces some warnings in the LCMS.c
Message-ID: <eTiQj-RC56VaT_bkLPKniDwjvNvWwR0zA28wtsuJR8w=.f3bdfb2a-b358-40da-bf65-ab2142ddf47d@github.com>

The newly added test MTTransformReplacedProfile(yeah that test again) produce some warning if check:jni is enabled:

WARNING in native method: JNI call made with exception pending
at sun.java2d.cmm.lcms.LCMS.setTagDataNative(java.desktop at 17-internal/Native Method)
at sun.java2d.cmm.lcms.LCMSProfile.setTag(java.desktop at 17-internal/LCMSProfile.java:82)
at sun.java2d.cmm.lcms.LCMS.setTagData(java.desktop at 17-internal/LCMS.java:84) 


The root cause is in the "errorHandler", which is called by the lcms library and where we throw a CMSException. So when we get an error code from some lcms API and try to throw the CMSException it is might be already thrown in the "errorHandler".

The fix contains two parts:
 * If an exception already occurred we skip the creation of the CMSException. So the first error will be reported to the user.
 * If an exception already occurred we DO NOT skip the creation of the IllegalArgumentException, because it is required by the specification to be thrown. But we use the initial exception as a "cause" for the new IllegalArgumentException. Note that it is also possible to just clear an occurred exception before the creation of the IllegalArgumentException. Any thoughts about it?

The second part changed the stack trace which will get the user, an example:

old:

java.lang.IllegalArgumentException: Can not write tag data.
	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagDataNative(Native Method)
	at java.desktop/sun.java2d.cmm.lcms.LCMSProfile.setTag(LCMSProfile.java:82)
	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagData(LCMS.java:84)
	at java.desktop/java.awt.color.ICC_Profile.setData(ICC_Profile.java:1132)
	at SetDataTest$TestCase.doTest(SetDataTest.java:77)
	at SetDataTest.main(SetDataTest.java:140)

new:

java.lang.IllegalArgumentException: Can not write tag data.
	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagDataNative(Native Method)
	at java.desktop/sun.java2d.cmm.lcms.LCMSProfile.setTag(LCMSProfile.java:82)
	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagData(LCMS.java:92)
	at java.desktop/java.awt.color.ICC_Profile.setData(ICC_Profile.java:1114)
	at SetDataTest$TestCase.doTest(SetDataTest.java:77)
	at SetDataTest.main(SetDataTest.java:140)
Caused by: java.awt.color.CMMException: LCMS error 8: Unknown tag type 'AAAA' found.
	... 6 more

-------------

Commit messages:
 - Update LCMS.c
 - Update LCMS.c
 - Init the cause of the IllegalArgumentException
 - 8275344: -Xcheck:jni produces some warnings in the LCMS.c

Changes: https://git.openjdk.java.net/jdk/pull/5975/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5975&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275344
  Stats: 67 lines in 2 files changed: 47 ins; 1 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5975.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5975/head:pull/5975

PR: https://git.openjdk.java.net/jdk/pull/5975


From jdv at openjdk.java.net  Mon Oct 18 13:07:09 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 18 Oct 2021 13:07:09 GMT
Subject: RFR: 8255898: Test
 java/awt/FileDialog/FilenameFilterTest/FilenameFilterst.java fails on Mac OS
Message-ID: <p9X6PdlS1XH8R3YVyOn5SAqUiC9qU2YfZw_gxFC9NSM=.40dafec4-ff13-4b94-8a5c-2d9a7b4c8767@github.com>

Root cause for this test failure in our CI systems was macOS regression in specific version of Catalina.
This issue is fixed in macOS 10.12 Catalina Beta7 (19A546d) and it is no longer failing after multiple individual test runs as well as multiple FileDialog jtreg test bunch run in our CI systems.

I have added details of similar issue faced in this Catalina version by other applications in the JBS. Some of these observations talk about permission issues when running the application, so to be on safer side i have updated test case to run on othervm mode.

-------------

Commit messages:
 - 8255898: Test java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.java fails on Mac OS

Changes: https://git.openjdk.java.net/jdk/pull/5986/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5986&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255898
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5986.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5986/head:pull/5986

PR: https://git.openjdk.java.net/jdk/pull/5986


From jdv at openjdk.java.net  Mon Oct 18 13:07:09 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 18 Oct 2021 13:07:09 GMT
Subject: RFR: 8255898: Test
 java/awt/FileDialog/FilenameFilterTest/FilenameFilterst.java fails on Mac OS
In-Reply-To: <p9X6PdlS1XH8R3YVyOn5SAqUiC9qU2YfZw_gxFC9NSM=.40dafec4-ff13-4b94-8a5c-2d9a7b4c8767@github.com>
References: <p9X6PdlS1XH8R3YVyOn5SAqUiC9qU2YfZw_gxFC9NSM=.40dafec4-ff13-4b94-8a5c-2d9a7b4c8767@github.com>
Message-ID: <XVwm0jWV3WvZ8743idPQBUDsZvsqRIogkTtW23VTfx8=.b9a92954-96af-4fb3-a9d1-95eb4a7c6cf2@github.com>

On Mon, 18 Oct 2021 12:58:20 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Root cause for this test failure in our CI systems was macOS regression in specific version of Catalina.
> This issue is fixed in macOS 10.12 Catalina Beta7 (19A546d) and it is no longer failing after multiple individual test runs as well as multiple FileDialog jtreg test bunch run in our CI systems.
> 
> I have added details of similar issue faced in this Catalina version by other applications in the JBS. Some of these observations talk about permission issues when running the application, so to be on safer side i have updated test case to run on othervm mode.

Test failure in Linux is different and it is related to GTK. So this PR is only for macOS related failure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5986


From prr at openjdk.java.net  Mon Oct 18 21:12:47 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 18 Oct 2021 21:12:47 GMT
Subject: RFR: 8255898: Test
 java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.java fails on Mac OS
In-Reply-To: <p9X6PdlS1XH8R3YVyOn5SAqUiC9qU2YfZw_gxFC9NSM=.40dafec4-ff13-4b94-8a5c-2d9a7b4c8767@github.com>
References: <p9X6PdlS1XH8R3YVyOn5SAqUiC9qU2YfZw_gxFC9NSM=.40dafec4-ff13-4b94-8a5c-2d9a7b4c8767@github.com>
Message-ID: <iAPROf9drz0CBFMbeJoxYQ6299mtmWk0fXLj2Rs00qI=.18070841-75ac-4958-a7c4-298552bffc95@github.com>

On Mon, 18 Oct 2021 12:58:20 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Root cause for this test failure in our CI systems was macOS regression in specific version of Catalina.
> This issue is fixed in macOS 10.12 Catalina Beta7 (19A546d) and it is no longer failing after multiple individual test runs as well as multiple FileDialog jtreg test bunch run in our CI systems.
> 
> I have added details of similar issue faced in this Catalina version by other applications in the JBS. Some of these observations talk about permission issues when running the application, so to be on safer side i have updated test case to run on othervm mode.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5986


From prr at openjdk.java.net  Mon Oct 18 23:12:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 18 Oct 2021 23:12:57 GMT
Subject: RFR: 8192931: Regression test
 java/awt/font/TextLayout/CombiningPerf.java fails
Message-ID: <uinr9XYA6uJJ0pYyM4goilZbZDGqF2TBb8ff4bT_5cY=.7fa00ba5-5e1b-4913-a1ef-5d3681b475fa@github.com>

As described in the bug evaluation, this test was only useful when it had Lucida Sans as a font in the JDK and
the ICU layout engine. 

I don't think it can be made reliable any more given unknown fonts and the difference in the layput engine.

So delete it.

-------------

Commit messages:
 - 8192931: Regression test java/awt/font/TextLayout/CombiningPerf.java fails

Changes: https://git.openjdk.java.net/jdk/pull/5999/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5999&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8192931
  Stats: 86 lines in 2 files changed: 0 ins; 86 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5999.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5999/head:pull/5999

PR: https://git.openjdk.java.net/jdk/pull/5999


From serb at openjdk.java.net  Tue Oct 19 00:06:53 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 19 Oct 2021 00:06:53 GMT
Subject: RFR: 8192931: Regression test
 java/awt/font/TextLayout/CombiningPerf.java fails
In-Reply-To: <uinr9XYA6uJJ0pYyM4goilZbZDGqF2TBb8ff4bT_5cY=.7fa00ba5-5e1b-4913-a1ef-5d3681b475fa@github.com>
References: <uinr9XYA6uJJ0pYyM4goilZbZDGqF2TBb8ff4bT_5cY=.7fa00ba5-5e1b-4913-a1ef-5d3681b475fa@github.com>
Message-ID: <VJ7lADtKgzbXH-RnCUADtX9eX5IJ0xrFa09OEhYqRhQ=.93005171-b0c0-4670-b370-84c639697197@github.com>

On Mon, 18 Oct 2021 23:06:34 GMT, Phil Race <prr at openjdk.org> wrote:

> As described in the bug evaluation, this test was only useful when it had Lucida Sans as a font in the JDK and
> the ICU layout engine. 
> 
> I don't think it can be made reliable any more given unknown fonts and the difference in the layput engine.
> 
> So delete it.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5999


From serb at openjdk.java.net  Tue Oct 19 00:08:47 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 19 Oct 2021 00:08:47 GMT
Subject: RFR: 8255898: Test
 java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.java fails on Mac OS
In-Reply-To: <p9X6PdlS1XH8R3YVyOn5SAqUiC9qU2YfZw_gxFC9NSM=.40dafec4-ff13-4b94-8a5c-2d9a7b4c8767@github.com>
References: <p9X6PdlS1XH8R3YVyOn5SAqUiC9qU2YfZw_gxFC9NSM=.40dafec4-ff13-4b94-8a5c-2d9a7b4c8767@github.com>
Message-ID: <SeS9i6bjFwIMHzE1Xzuwn9PksDx3QG3hnTWrSN90p5c=.6a03a305-ac19-4961-aec6-0b0dd72e3eff@github.com>

On Mon, 18 Oct 2021 12:58:20 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Root cause for this test failure in our CI systems was macOS regression in specific version of Catalina.
> This issue is fixed in macOS 10.12 Catalina Beta7 (19A546d) and it is no longer failing after multiple individual test runs as well as multiple FileDialog jtreg test bunch run in our CI systems.
> 
> I have added details of similar issue faced in this Catalina version by other applications in the JBS. Some of these observations talk about permission issues when running the application, so to be on safer side i have updated test case to run on othervm mode.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5986


From jdv at openjdk.java.net  Tue Oct 19 04:07:53 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 19 Oct 2021 04:07:53 GMT
Subject: Integrated: 8255898: Test
 java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.java fails on Mac OS
In-Reply-To: <p9X6PdlS1XH8R3YVyOn5SAqUiC9qU2YfZw_gxFC9NSM=.40dafec4-ff13-4b94-8a5c-2d9a7b4c8767@github.com>
References: <p9X6PdlS1XH8R3YVyOn5SAqUiC9qU2YfZw_gxFC9NSM=.40dafec4-ff13-4b94-8a5c-2d9a7b4c8767@github.com>
Message-ID: <dozDZr1d1-1SQxq8Rr4yZfSdmJoi49j4m-bfGo-VK3E=.fa435f0f-a909-4e17-8ee5-710c657c3754@github.com>

On Mon, 18 Oct 2021 12:58:20 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Root cause for this test failure in our CI systems was macOS regression in specific version of Catalina.
> This issue is fixed in macOS 10.12 Catalina Beta7 (19A546d) and it is no longer failing after multiple individual test runs as well as multiple FileDialog jtreg test bunch run in our CI systems.
> 
> I have added details of similar issue faced in this Catalina version by other applications in the JBS. Some of these observations talk about permission issues when running the application, so to be on safer side i have updated test case to run on othervm mode.

This pull request has now been integrated.

Changeset: 947d52c4
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/947d52c4c3deec1bdea43959c200201c614ae114
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8255898: Test java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.java fails on Mac OS

Reviewed-by: prr, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/5986


From jdv at openjdk.java.net  Tue Oct 19 05:43:46 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 19 Oct 2021 05:43:46 GMT
Subject: RFR: 8192931: Regression test
 java/awt/font/TextLayout/CombiningPerf.java fails
In-Reply-To: <uinr9XYA6uJJ0pYyM4goilZbZDGqF2TBb8ff4bT_5cY=.7fa00ba5-5e1b-4913-a1ef-5d3681b475fa@github.com>
References: <uinr9XYA6uJJ0pYyM4goilZbZDGqF2TBb8ff4bT_5cY=.7fa00ba5-5e1b-4913-a1ef-5d3681b475fa@github.com>
Message-ID: <3KjR5h6cGWVw9lzAyz2AyTo4zfoPVcTd1QWyNLUL9gM=.ceaf96c0-36fe-486a-a830-3a5521aad8df@github.com>

On Mon, 18 Oct 2021 23:06:34 GMT, Phil Race <prr at openjdk.org> wrote:

> As described in the bug evaluation, this test was only useful when it had Lucida Sans as a font in the JDK and
> the ICU layout engine. 
> 
> I don't think it can be made reliable any more given unknown fonts and the difference in the layput engine.
> 
> So delete it.

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5999


From pbansal at openjdk.java.net  Tue Oct 19 05:52:00 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 19 Oct 2021 05:52:00 GMT
Subject: RFR: 8198626:
 java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac
Message-ID: <v5BYnld6TnTrMIyuShOK3gWkw6rQ319lXX49W9oZ9DU=.4bb0af15-077f-4d18-96f1-a21d4c94e58e@github.com>

Test java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac fails on Mac. The test fails on my local machine (macOS BigSur) always and on mach5 also. The test uses Robot for mouse clicks and there is no delay or autoDelay set on Robot.

The fix adds set autoDelay on the robot. Along with this, a lot of cleanup is done including removing the local Semaphore class etc. The test passes after the changes on my local mac and mach5 (Link in the JBS)

-------------

Commit messages:
 - Allignment issues
 - ProblemList
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/5976/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5976&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8198626
  Stats: 114 lines in 2 files changed: 32 ins; 54 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5976.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5976/head:pull/5976

PR: https://git.openjdk.java.net/jdk/pull/5976


From pbansal at openjdk.java.net  Tue Oct 19 07:23:52 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 19 Oct 2021 07:23:52 GMT
Subject: Withdrawn: 8198626:
 java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac
In-Reply-To: <v5BYnld6TnTrMIyuShOK3gWkw6rQ319lXX49W9oZ9DU=.4bb0af15-077f-4d18-96f1-a21d4c94e58e@github.com>
References: <v5BYnld6TnTrMIyuShOK3gWkw6rQ319lXX49W9oZ9DU=.4bb0af15-077f-4d18-96f1-a21d4c94e58e@github.com>
Message-ID: <K2yE98EWONDF9Gw1pIs9UAb7W5dZrnrwNkLKe95eM08=.b7426241-7f16-407b-a79b-bb2c0fa97fb5@github.com>

On Sun, 17 Oct 2021 10:23:11 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> Test java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac fails on Mac. The test fails on my local machine (macOS BigSur) always and on mach5 also. The test uses Robot for mouse clicks and there is no delay or autoDelay set on Robot.
> 
> The fix adds set autoDelay on the robot. Along with this, a lot of cleanup is done including removing the local Semaphore class etc. The test passes after the changes on my local mac and mach5 (Link in the JBS)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5976


From jdv at openjdk.java.net  Tue Oct 19 10:04:00 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 19 Oct 2021 10:04:00 GMT
Subject: RFR: 8255724: [XRender] the BlitRotateClippedArea test fails on Linux
 in the XR pipeline
Message-ID: <KHM4_5ntEG9EMuw_HYYgBjeUeXdSIBOzr7AER0wvxZ8=.f722e5c1-4c81-4ba3-9a67-869695eb6899@github.com>

This test was added under https://bugs.openjdk.java.net/browse/JDK-8255722 to verify rotated blit operation. But it started failing XRender pipeline because of pixel color mismatch. Looks like we have minor difference in pixel color because of arithmetic precision differences in transformations.

This test fails every-time in XRender without tolerance and passes with +/-1 in Color values in CI systems. Updated test to use +/-1 tolerance as mentioned in JBS. Added this little tolerance in Color will not change functionality that we are verifying in this test.

-------------

Commit messages:
 - 8255724: [XRender] the BlitRotateClippedArea test fails on Linux in the XR pipeline

Changes: https://git.openjdk.java.net/jdk/pull/6002/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6002&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255724
  Stats: 12 lines in 2 files changed: 5 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6002.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6002/head:pull/6002

PR: https://git.openjdk.java.net/jdk/pull/6002


From psadhukhan at openjdk.java.net  Tue Oct 19 12:21:50 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 19 Oct 2021 12:21:50 GMT
Subject: RFR: 8255724: [XRender] the BlitRotateClippedArea test fails on
 Linux in the XR pipeline
In-Reply-To: <KHM4_5ntEG9EMuw_HYYgBjeUeXdSIBOzr7AER0wvxZ8=.f722e5c1-4c81-4ba3-9a67-869695eb6899@github.com>
References: <KHM4_5ntEG9EMuw_HYYgBjeUeXdSIBOzr7AER0wvxZ8=.f722e5c1-4c81-4ba3-9a67-869695eb6899@github.com>
Message-ID: <mSFUkwCHWWfUbKwLKwfbSnLMFRKJouAIKSa9SPv850w=.d30b74f0-f7cc-4707-b04d-0ec74fd627ea@github.com>

On Tue, 19 Oct 2021 09:56:07 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This test was added under https://bugs.openjdk.java.net/browse/JDK-8255722 to verify rotated blit operation. But it started failing XRender pipeline because of pixel color mismatch. Looks like we have minor difference in pixel color because of arithmetic precision differences in transformations.
> 
> This test fails every-time in XRender without tolerance and passes with +/-1 in Color values in CI systems. Updated test to use +/-1 tolerance as mentioned in JBS. Added this little tolerance in Color will not change functionality that we are verifying in this test.

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6002


From jdv at openjdk.java.net  Tue Oct 19 12:29:56 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 19 Oct 2021 12:29:56 GMT
Subject: Integrated: 8255724: [XRender] the BlitRotateClippedArea test fails on
 Linux in the XR pipeline
In-Reply-To: <KHM4_5ntEG9EMuw_HYYgBjeUeXdSIBOzr7AER0wvxZ8=.f722e5c1-4c81-4ba3-9a67-869695eb6899@github.com>
References: <KHM4_5ntEG9EMuw_HYYgBjeUeXdSIBOzr7AER0wvxZ8=.f722e5c1-4c81-4ba3-9a67-869695eb6899@github.com>
Message-ID: <sRpZ6ble9dKHJJI9iWbIW6O3hQwu1Dag9GE4os6K4ic=.5cfa9a89-5cec-4a51-90ab-80492a1ded42@github.com>

On Tue, 19 Oct 2021 09:56:07 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This test was added under https://bugs.openjdk.java.net/browse/JDK-8255722 to verify rotated blit operation. But it started failing XRender pipeline because of pixel color mismatch. Looks like we have minor difference in pixel color because of arithmetic precision differences in transformations.
> 
> This test fails every-time in XRender without tolerance and passes with +/-1 in Color values in CI systems. Updated test to use +/-1 tolerance as mentioned in JBS. Added this little tolerance in Color will not change functionality that we are verifying in this test.

This pull request has now been integrated.

Changeset: dcd6e0da
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dcd6e0da245338de68d9dede451e233f4bfaa934
Stats:     12 lines in 2 files changed: 5 ins; 1 del; 6 mod

8255724: [XRender] the BlitRotateClippedArea test fails on Linux in the XR pipeline

Reviewed-by: psadhukhan

-------------

PR: https://git.openjdk.java.net/jdk/pull/6002


From azvegint at openjdk.java.net  Tue Oct 19 14:11:11 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 19 Oct 2021 14:11:11 GMT
Subject: RFR: 8274160: java/awt/Window/ShapedAndTranslucentWindows/Common.java
 delay is too high
Message-ID: <X1nwjngQIHyO9eF_C5OoWO-in3JEbrWv_V9G36t6Eaw=.19927c48-880c-4d10-b488-5fa3f93a58c9@github.com>

Along with [JDK-8210776](https://bugs.openjdk.java.net/browse/JDK-8210776) fix, a typo was [introduced](http://hg.openjdk.java.net/jdk/jdk/rev/8c7638601045#l11.8).

This fix reverts it back.

Multiple test runs showed no failures.

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/6014/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6014&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274160
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6014.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6014/head:pull/6014

PR: https://git.openjdk.java.net/jdk/pull/6014


From psadhukhan at openjdk.java.net  Tue Oct 19 14:22:59 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 19 Oct 2021 14:22:59 GMT
Subject: RFR: 8274160:
 java/awt/Window/ShapedAndTranslucentWindows/Common.java delay is too high
In-Reply-To: <X1nwjngQIHyO9eF_C5OoWO-in3JEbrWv_V9G36t6Eaw=.19927c48-880c-4d10-b488-5fa3f93a58c9@github.com>
References: <X1nwjngQIHyO9eF_C5OoWO-in3JEbrWv_V9G36t6Eaw=.19927c48-880c-4d10-b488-5fa3f93a58c9@github.com>
Message-ID: <lgmd6Q6dBTW2mBjoZ-mOLskHYiKyp0x0lmrdHZSUkjo=.dd4e0fbc-9590-450e-bfbd-5a446b82fbf7@github.com>

On Tue, 19 Oct 2021 13:56:52 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Along with [JDK-8210776](https://bugs.openjdk.java.net/browse/JDK-8210776) fix, a typo was [introduced](http://hg.openjdk.java.net/jdk/jdk/rev/8c7638601045#l11.8).
> 
> This fix reverts it back.
> 
> Multiple test runs showed no failures.

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6014


From azvegint at openjdk.java.net  Tue Oct 19 14:23:17 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 19 Oct 2021 14:23:17 GMT
Subject: RFR: 8233648: [TESTBUG] DefaultMenuBarTest.java failing on macos
Message-ID: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>

Looks like this test does not fail anymore.

It does not fail once even without changes, but I've added extra `waitForIdle()` just for safety.

Checked on ~350 test runs.

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/6015/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6015&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8233648
  Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6015.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6015/head:pull/6015

PR: https://git.openjdk.java.net/jdk/pull/6015


From pbansal at openjdk.java.net  Tue Oct 19 14:40:51 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 19 Oct 2021 14:40:51 GMT
Subject: RFR: 8274160:
 java/awt/Window/ShapedAndTranslucentWindows/Common.java delay is too high
In-Reply-To: <X1nwjngQIHyO9eF_C5OoWO-in3JEbrWv_V9G36t6Eaw=.19927c48-880c-4d10-b488-5fa3f93a58c9@github.com>
References: <X1nwjngQIHyO9eF_C5OoWO-in3JEbrWv_V9G36t6Eaw=.19927c48-880c-4d10-b488-5fa3f93a58c9@github.com>
Message-ID: <bggMBCTK2rrS9pQz2gqXba2QxrXEUn21rUBSvxTOSUY=.3a77129e-7ea9-47a0-8bbe-2aaa5784e481@github.com>

On Tue, 19 Oct 2021 13:56:52 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Along with [JDK-8210776](https://bugs.openjdk.java.net/browse/JDK-8210776) fix, a typo was [introduced](http://hg.openjdk.java.net/jdk/jdk/rev/8c7638601045#l11.8).
> 
> This fix reverts it back.
> 
> Multiple test runs showed no failures.

Marked as reviewed by pbansal (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6014


From pbansal at openjdk.java.net  Tue Oct 19 14:45:53 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 19 Oct 2021 14:45:53 GMT
Subject: RFR: 8233648: [TESTBUG] DefaultMenuBarTest.java failing on macos
In-Reply-To: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>
References: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>
Message-ID: <k1qvcBfZooFXxJkAOrh1yhhAiQWCjODk9ETHOnJoc6U=.3d3ea2e3-e642-4135-9103-03389595244f@github.com>

On Tue, 19 Oct 2021 14:12:24 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Looks like this test does not fail anymore.
> 
> It does not fail once even without changes, but I've added extra `waitForIdle()` just for safety.
> 
> Checked on ~350 test runs.

Marked as reviewed by pbansal (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6015


From psadhukhan at openjdk.java.net  Tue Oct 19 15:00:53 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 19 Oct 2021 15:00:53 GMT
Subject: RFR: 8233648: [TESTBUG] DefaultMenuBarTest.java failing on macos
In-Reply-To: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>
References: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>
Message-ID: <3rw2cJ4fQNoBMlCnXI9RlGIjMbLCK5nW_tTinSY7OIs=.c82f081c-cd14-4dfa-8a2c-796bd73da1f4@github.com>

On Tue, 19 Oct 2021 14:12:24 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Looks like this test does not fail anymore.
> 
> It does not fail once even without changes, but I've added extra `waitForIdle()` just for safety.
> 
> Checked on ~350 test runs.

I guess you can remove @modules sun.awt which is not needed anymore..
Also, since you are touching the test, you probably can replace wildcard imports and remove author tag.
Additionally, i believe we should throw exception instead of catching and only print stacktrace at end of file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6015


From psadhukhan at openjdk.java.net  Tue Oct 19 17:03:10 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 19 Oct 2021 17:03:10 GMT
Subject: RFR: 7124287: [TEST_BUG] [macosx] JTableHeader doesn't get focus after
 pressing F8 key
Message-ID: <VPA0JzAMlevIwGlJADl82NuRM8LGVaryzMq4UzqQGb0=.ccc99f44-0fa2-4feb-ad60-cf4bc07f8ebb@github.com>

JTableHeader doesn't get focus after pressing F8 key in macos causing test to fail. Added F8 keybindings to macos similar to 
MetalLookAndFeel
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L1232
and BasicLookAndFeel
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#L1497

Test is moved from closed to open and now passing in macos.

-------------

Commit messages:
 - 7124287: [TEST_BUG] [macosx] JTableHeader doesn't get focus after pressing F8 key

Changes: https://git.openjdk.java.net/jdk/pull/6019/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6019&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-7124287
  Stats: 75 lines in 2 files changed: 74 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6019.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6019/head:pull/6019

PR: https://git.openjdk.java.net/jdk/pull/6019


From azvegint at openjdk.java.net  Tue Oct 19 17:09:58 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 19 Oct 2021 17:09:58 GMT
Subject: RFR: 8275344: -Xcheck:jni produces some warnings in the LCMS.c
In-Reply-To: <eTiQj-RC56VaT_bkLPKniDwjvNvWwR0zA28wtsuJR8w=.f3bdfb2a-b358-40da-bf65-ab2142ddf47d@github.com>
References: <eTiQj-RC56VaT_bkLPKniDwjvNvWwR0zA28wtsuJR8w=.f3bdfb2a-b358-40da-bf65-ab2142ddf47d@github.com>
Message-ID: <GeeAxeI2yVRLZRxBHVrY7Y1ZokHhIMzuBUym6HgvxQc=.deaaad12-a270-4d58-9201-ed9c521c7d61@github.com>

On Sun, 17 Oct 2021 00:09:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The newly added test MTTransformReplacedProfile(yeah that test again) produce some warning if check:jni is enabled:
> 
> WARNING in native method: JNI call made with exception pending
> at sun.java2d.cmm.lcms.LCMS.setTagDataNative(java.desktop at 17-internal/Native Method)
> at sun.java2d.cmm.lcms.LCMSProfile.setTag(java.desktop at 17-internal/LCMSProfile.java:82)
> at sun.java2d.cmm.lcms.LCMS.setTagData(java.desktop at 17-internal/LCMS.java:84) 
> 
> 
> The root cause is in the "errorHandler", which is called by the lcms library and where we throw a CMSException. So when we get an error code from some lcms API and try to throw the CMSException it is might be already thrown in the "errorHandler".
> 
> The fix contains two parts:
>  * If an exception already occurred we skip the creation of the CMSException. So the first error will be reported to the user.
>  * If an exception already occurred we DO NOT skip the creation of the IllegalArgumentException, because it is required by the specification to be thrown. But we use the initial exception as a "cause" for the new IllegalArgumentException. Note that it is also possible to just clear an occurred exception before the creation of the IllegalArgumentException. Any thoughts about it?
> 
> The second part changed the stack trace which will get the user, an example:
> 
> old:
> 
> java.lang.IllegalArgumentException: Can not write tag data.
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagDataNative(Native Method)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMSProfile.setTag(LCMSProfile.java:82)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagData(LCMS.java:84)
> 	at java.desktop/java.awt.color.ICC_Profile.setData(ICC_Profile.java:1132)
> 	at SetDataTest$TestCase.doTest(SetDataTest.java:77)
> 	at SetDataTest.main(SetDataTest.java:140)
> 
> new:
> 
> java.lang.IllegalArgumentException: Can not write tag data.
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagDataNative(Native Method)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMSProfile.setTag(LCMSProfile.java:82)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagData(LCMS.java:92)
> 	at java.desktop/java.awt.color.ICC_Profile.setData(ICC_Profile.java:1114)
> 	at SetDataTest$TestCase.doTest(SetDataTest.java:77)
> 	at SetDataTest.main(SetDataTest.java:140)
> Caused by: java.awt.color.CMMException: LCMS error 8: Unknown tag type 'AAAA' found.
> 	... 6 more

Marked as reviewed by azvegint (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5975


From asemenov at openjdk.java.net  Tue Oct 19 17:23:11 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Tue, 19 Oct 2021 17:23:11 GMT
Subject: RFR: 8273678 TableAccessibility and TableRowAccessibility miss
 autorelease
Message-ID: <A54SFKDa5sz5XioUaL4wDIqIxp9QVSk3Q8YM_CB-UtY=.8ea6b5aa-ea49-4d00-b611-c74923c761e9@github.com>

The TableAccessibility obj-c class should call [autorelease] on an object it allocates (see: [TableRowAccessibility alloc] and [ColumnAccessibility alloc]). 

The TableRowAccessibility obj-c class should not call [retain] on an allocated object (see: [CellAccessibility alloc]). 

"You own any object you create", see: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html

-------------

Commit messages:
 - 8273678 TableAccessibility and TableRowAccessibility miss autorelease

Changes: https://git.openjdk.java.net/jdk/pull/6020/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6020&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273678
  Stats: 231 lines in 5 files changed: 136 ins; 78 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6020.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6020/head:pull/6020

PR: https://git.openjdk.java.net/jdk/pull/6020


From azvegint at openjdk.java.net  Tue Oct 19 17:27:57 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 19 Oct 2021 17:27:57 GMT
Subject: Integrated: 8274160:
 java/awt/Window/ShapedAndTranslucentWindows/Common.java delay is too high
In-Reply-To: <X1nwjngQIHyO9eF_C5OoWO-in3JEbrWv_V9G36t6Eaw=.19927c48-880c-4d10-b488-5fa3f93a58c9@github.com>
References: <X1nwjngQIHyO9eF_C5OoWO-in3JEbrWv_V9G36t6Eaw=.19927c48-880c-4d10-b488-5fa3f93a58c9@github.com>
Message-ID: <cavgHtWayEhmpMHmGEe51mbSwa1fnrOMFG_dB1L2G9M=.d420b446-b9e2-4f8b-a2f0-312ff77cc7f7@github.com>

On Tue, 19 Oct 2021 13:56:52 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Along with [JDK-8210776](https://bugs.openjdk.java.net/browse/JDK-8210776) fix, a typo was [introduced](http://hg.openjdk.java.net/jdk/jdk/rev/8c7638601045#l11.8).
> 
> This fix reverts it back.
> 
> Multiple test runs showed no failures.

This pull request has now been integrated.

Changeset: 895e2bd7
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/895e2bd7c0bded5283eca8792fbfb287bb75016b
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8274160: java/awt/Window/ShapedAndTranslucentWindows/Common.java delay is too high

Reviewed-by: psadhukhan, pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/6014


From prr at openjdk.java.net  Tue Oct 19 20:19:28 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 19 Oct 2021 20:19:28 GMT
Subject: RFR: 8275344: -Xcheck:jni produces some warnings in the LCMS.c
In-Reply-To: <eTiQj-RC56VaT_bkLPKniDwjvNvWwR0zA28wtsuJR8w=.f3bdfb2a-b358-40da-bf65-ab2142ddf47d@github.com>
References: <eTiQj-RC56VaT_bkLPKniDwjvNvWwR0zA28wtsuJR8w=.f3bdfb2a-b358-40da-bf65-ab2142ddf47d@github.com>
Message-ID: <xiJ0Fr86sjfknasKJmb2BJ1QNTiJQrRHkmYMAHf5q1k=.69dd765a-866d-43af-85c7-6708339f029f@github.com>

On Sun, 17 Oct 2021 00:09:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The newly added test MTTransformReplacedProfile(yeah that test again) produce some warning if check:jni is enabled:
> 
> WARNING in native method: JNI call made with exception pending
> at sun.java2d.cmm.lcms.LCMS.setTagDataNative(java.desktop at 17-internal/Native Method)
> at sun.java2d.cmm.lcms.LCMSProfile.setTag(java.desktop at 17-internal/LCMSProfile.java:82)
> at sun.java2d.cmm.lcms.LCMS.setTagData(java.desktop at 17-internal/LCMS.java:84) 
> 
> 
> The root cause is in the "errorHandler", which is called by the lcms library and where we throw a CMSException. So when we get an error code from some lcms API and try to throw the CMSException it is might be already thrown in the "errorHandler".
> 
> The fix contains two parts:
>  * If an exception already occurred we skip the creation of the CMSException. So the first error will be reported to the user.
>  * If an exception already occurred we DO NOT skip the creation of the IllegalArgumentException, because it is required by the specification to be thrown. But we use the initial exception as a "cause" for the new IllegalArgumentException. Note that it is also possible to just clear an occurred exception before the creation of the IllegalArgumentException. Any thoughts about it?
> 
> The second part changed the stack trace which will get the user, an example:
> 
> old:
> 
> java.lang.IllegalArgumentException: Can not write tag data.
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagDataNative(Native Method)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMSProfile.setTag(LCMSProfile.java:82)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagData(LCMS.java:84)
> 	at java.desktop/java.awt.color.ICC_Profile.setData(ICC_Profile.java:1132)
> 	at SetDataTest$TestCase.doTest(SetDataTest.java:77)
> 	at SetDataTest.main(SetDataTest.java:140)
> 
> new:
> 
> java.lang.IllegalArgumentException: Can not write tag data.
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagDataNative(Native Method)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMSProfile.setTag(LCMSProfile.java:82)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagData(LCMS.java:92)
> 	at java.desktop/java.awt.color.ICC_Profile.setData(ICC_Profile.java:1114)
> 	at SetDataTest$TestCase.doTest(SetDataTest.java:77)
> 	at SetDataTest.main(SetDataTest.java:140)
> Caused by: java.awt.color.CMMException: LCMS error 8: Unknown tag type 'AAAA' found.
> 	... 6 more

Marked as reviewed by prr (Reviewer).

"Note that it is also possible to just clear an occurred exception before the creation of the IllegalArgumentException. Any thoughts about it?"

I think wrapping it as you do is fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5975


From kizune at openjdk.java.net  Tue Oct 19 20:19:28 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 19 Oct 2021 20:19:28 GMT
Subject: RFR: 8192931: Regression test
 java/awt/font/TextLayout/CombiningPerf.java fails
In-Reply-To: <uinr9XYA6uJJ0pYyM4goilZbZDGqF2TBb8ff4bT_5cY=.7fa00ba5-5e1b-4913-a1ef-5d3681b475fa@github.com>
References: <uinr9XYA6uJJ0pYyM4goilZbZDGqF2TBb8ff4bT_5cY=.7fa00ba5-5e1b-4913-a1ef-5d3681b475fa@github.com>
Message-ID: <XLuiGNUl3I0d6OAei1xmlfS_mcLB1ODyKJULKMgJKSw=.699a034d-867f-4633-8d68-ce26f05997f9@github.com>

On Mon, 18 Oct 2021 23:06:34 GMT, Phil Race <prr at openjdk.org> wrote:

> As described in the bug evaluation, this test was only useful when it had Lucida Sans as a font in the JDK and
> the ICU layout engine. 
> 
> I don't think it can be made reliable any more given unknown fonts and the difference in the layput engine.
> 
> So delete it.

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5999


From duke at openjdk.java.net  Tue Oct 19 20:19:40 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Tue, 19 Oct 2021 20:19:40 GMT
Subject: RFR: 8233558: [TESTBUG] WindowOwnedByEmbeddedFrameTest.java fails on
 macos
Message-ID: <J2JVR0xAXruoxTSDNgFG8sNpLefmxKVTmjMoMTV2mcM=.e1427069-5ea4-4e87-8967-3febd9b11382@github.com>

added export java.desktop/sun.lwawt.macosx:open

-------------

Commit messages:
 - removed from ProblemList
 - 8233558: [TESTBUG] WindowOwnedByEmbeddedFrameTest.java fails on macos

Changes: https://git.openjdk.java.net/jdk/pull/6022/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6022&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8233558
  Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6022.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6022/head:pull/6022

PR: https://git.openjdk.java.net/jdk/pull/6022


From azvegint at openjdk.java.net  Tue Oct 19 20:20:00 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 19 Oct 2021 20:20:00 GMT
Subject: RFR: 8233648: [TESTBUG] DefaultMenuBarTest.java failing on macos
 [v2]
In-Reply-To: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>
References: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>
Message-ID: <ZdtvGTiO43LZJOe7T7ePsDkLIbU5Vrvd80xS6F586tA=.de37025c-bfaa-4c08-aa1a-08e85be7c801@github.com>

> Looks like this test does not fail anymore.
> 
> It does not fail once even without changes, but I've added extra `waitForIdle()` just for safety.
> 
> Checked on ~350 test runs.

Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:

 - remove wildcard imports
 - cleanup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6015/files
  - new: https://git.openjdk.java.net/jdk/pull/6015/files/5218b7b7..e1c0625e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6015&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6015&range=00-01

  Stats: 24 lines in 1 file changed: 5 ins; 12 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6015.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6015/head:pull/6015

PR: https://git.openjdk.java.net/jdk/pull/6015


From azvegint at openjdk.java.net  Tue Oct 19 20:20:06 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 19 Oct 2021 20:20:06 GMT
Subject: RFR: 8233648: [TESTBUG] DefaultMenuBarTest.java failing on macos
In-Reply-To: <3rw2cJ4fQNoBMlCnXI9RlGIjMbLCK5nW_tTinSY7OIs=.c82f081c-cd14-4dfa-8a2c-796bd73da1f4@github.com>
References: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>
 <3rw2cJ4fQNoBMlCnXI9RlGIjMbLCK5nW_tTinSY7OIs=.c82f081c-cd14-4dfa-8a2c-796bd73da1f4@github.com>
Message-ID: <hZ4OrNqLuwQCquGV16KclkBXG3iaD3vFh4iua0pY2rA=.e6b07ebb-5a7a-4a7c-89ac-824f046f4ce2@github.com>

On Tue, 19 Oct 2021 14:57:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I guess you can remove @modules sun.awt which is not needed anymore.. Also, since you are touching the test, you probably can replace wildcard imports and remove author tag. Additionally, i believe we should throw exception instead of catching and only print stacktrace at end of file.

updated, testing still green.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6015


From prr at openjdk.java.net  Tue Oct 19 20:50:10 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 19 Oct 2021 20:50:10 GMT
Subject: Integrated: 8192931: Regression test
 java/awt/font/TextLayout/CombiningPerf.java fails
In-Reply-To: <uinr9XYA6uJJ0pYyM4goilZbZDGqF2TBb8ff4bT_5cY=.7fa00ba5-5e1b-4913-a1ef-5d3681b475fa@github.com>
References: <uinr9XYA6uJJ0pYyM4goilZbZDGqF2TBb8ff4bT_5cY=.7fa00ba5-5e1b-4913-a1ef-5d3681b475fa@github.com>
Message-ID: <te1AWfU2CTeO96xUsGu1mhnZazNMa5Pz-Ysq-9RbA4U=.457a5958-3026-46d1-80ba-c0a802505c6e@github.com>

On Mon, 18 Oct 2021 23:06:34 GMT, Phil Race <prr at openjdk.org> wrote:

> As described in the bug evaluation, this test was only useful when it had Lucida Sans as a font in the JDK and
> the ICU layout engine. 
> 
> I don't think it can be made reliable any more given unknown fonts and the difference in the layput engine.
> 
> So delete it.

This pull request has now been integrated.

Changeset: 54a29a44
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/54a29a4470a0482c6b7f9f2d695e357044e684a7
Stats:     86 lines in 2 files changed: 0 ins; 86 del; 0 mod

8192931: Regression test java/awt/font/TextLayout/CombiningPerf.java fails

Reviewed-by: serb, jdv, kizune

-------------

PR: https://git.openjdk.java.net/jdk/pull/5999


From kizune at openjdk.java.net  Tue Oct 19 21:32:08 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 19 Oct 2021 21:32:08 GMT
Subject: RFR: 8275344: -Xcheck:jni produces some warnings in the LCMS.c
In-Reply-To: <eTiQj-RC56VaT_bkLPKniDwjvNvWwR0zA28wtsuJR8w=.f3bdfb2a-b358-40da-bf65-ab2142ddf47d@github.com>
References: <eTiQj-RC56VaT_bkLPKniDwjvNvWwR0zA28wtsuJR8w=.f3bdfb2a-b358-40da-bf65-ab2142ddf47d@github.com>
Message-ID: <p979xrEDBOoFDmq4pjnsD1bk4rThf1boxavzN1ZiLwQ=.7aba746a-285e-4cd3-b1aa-7db65be5f5c8@github.com>

On Sun, 17 Oct 2021 00:09:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The newly added test MTTransformReplacedProfile(yeah that test again) produce some warning if check:jni is enabled:
> 
> WARNING in native method: JNI call made with exception pending
> at sun.java2d.cmm.lcms.LCMS.setTagDataNative(java.desktop at 17-internal/Native Method)
> at sun.java2d.cmm.lcms.LCMSProfile.setTag(java.desktop at 17-internal/LCMSProfile.java:82)
> at sun.java2d.cmm.lcms.LCMS.setTagData(java.desktop at 17-internal/LCMS.java:84) 
> 
> 
> The root cause is in the "errorHandler", which is called by the lcms library and where we throw a CMSException. So when we get an error code from some lcms API and try to throw the CMSException it is might be already thrown in the "errorHandler".
> 
> The fix contains two parts:
>  * If an exception already occurred we skip the creation of the CMSException. So the first error will be reported to the user.
>  * If an exception already occurred we DO NOT skip the creation of the IllegalArgumentException, because it is required by the specification to be thrown. But we use the initial exception as a "cause" for the new IllegalArgumentException. Note that it is also possible to just clear an occurred exception before the creation of the IllegalArgumentException. Any thoughts about it?
> 
> The second part changed the stack trace which will get the user, an example:
> 
> old:
> 
> java.lang.IllegalArgumentException: Can not write tag data.
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagDataNative(Native Method)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMSProfile.setTag(LCMSProfile.java:82)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagData(LCMS.java:84)
> 	at java.desktop/java.awt.color.ICC_Profile.setData(ICC_Profile.java:1132)
> 	at SetDataTest$TestCase.doTest(SetDataTest.java:77)
> 	at SetDataTest.main(SetDataTest.java:140)
> 
> new:
> 
> java.lang.IllegalArgumentException: Can not write tag data.
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagDataNative(Native Method)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMSProfile.setTag(LCMSProfile.java:82)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagData(LCMS.java:92)
> 	at java.desktop/java.awt.color.ICC_Profile.setData(ICC_Profile.java:1114)
> 	at SetDataTest$TestCase.doTest(SetDataTest.java:77)
> 	at SetDataTest.main(SetDataTest.java:140)
> Caused by: java.awt.color.CMMException: LCMS error 8: Unknown tag type 'AAAA' found.
> 	... 6 more

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5975


From kizune at openjdk.java.net  Tue Oct 19 21:45:07 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 19 Oct 2021 21:45:07 GMT
Subject: RFR: 7124287: [TEST_BUG] [macosx] JTableHeader doesn't get focus
 after pressing F8 key
In-Reply-To: <VPA0JzAMlevIwGlJADl82NuRM8LGVaryzMq4UzqQGb0=.ccc99f44-0fa2-4feb-ad60-cf4bc07f8ebb@github.com>
References: <VPA0JzAMlevIwGlJADl82NuRM8LGVaryzMq4UzqQGb0=.ccc99f44-0fa2-4feb-ad60-cf4bc07f8ebb@github.com>
Message-ID: <Tu8NKHdnr9nWDybNajqzn_5RkUq8nc8khV2vH3Mj9YA=.4efd3371-e2d5-4e92-a17f-2dc49554fb91@github.com>

On Tue, 19 Oct 2021 16:57:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> JTableHeader doesn't get focus after pressing F8 key in macos causing test to fail. Added F8 keybindings to macos similar to 
> MetalLookAndFeel
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L1232
> and BasicLookAndFeel
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#L1497
> 
> Test is moved from closed to open and now passing in macos.

Looks good

-------------

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6019


From serb at openjdk.java.net  Tue Oct 19 22:41:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 19 Oct 2021 22:41:05 GMT
Subject: RFR: 7124287: [TEST_BUG] [macosx] JTableHeader doesn't get focus
 after pressing F8 key
In-Reply-To: <VPA0JzAMlevIwGlJADl82NuRM8LGVaryzMq4UzqQGb0=.ccc99f44-0fa2-4feb-ad60-cf4bc07f8ebb@github.com>
References: <VPA0JzAMlevIwGlJADl82NuRM8LGVaryzMq4UzqQGb0=.ccc99f44-0fa2-4feb-ad60-cf4bc07f8ebb@github.com>
Message-ID: <R5O9J3BrB1Yad8xuPE31vWgUWnmvADjgisexymLnEI0=.83db27ce-8f69-4396-afba-7f83ddacec86@github.com>

On Tue, 19 Oct 2021 16:57:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> JTableHeader doesn't get focus after pressing F8 key in macos causing test to fail. Added F8 keybindings to macos similar to 
> MetalLookAndFeel
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L1232
> and BasicLookAndFeel
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#L1497
> 
> Test is moved from closed to open and now passing in macos.

I do not think it should be marked as a TEST_BUG

-------------

PR: https://git.openjdk.java.net/jdk/pull/6019


From serb at openjdk.java.net  Tue Oct 19 23:06:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 19 Oct 2021 23:06:08 GMT
Subject: RFR: 8233648: [TESTBUG] DefaultMenuBarTest.java failing on macos
 [v2]
In-Reply-To: <ZdtvGTiO43LZJOe7T7ePsDkLIbU5Vrvd80xS6F586tA=.de37025c-bfaa-4c08-aa1a-08e85be7c801@github.com>
References: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>
 <ZdtvGTiO43LZJOe7T7ePsDkLIbU5Vrvd80xS6F586tA=.de37025c-bfaa-4c08-aa1a-08e85be7c801@github.com>
Message-ID: <CdsaD19b0ql6BejPLZS0dbFFTbrxrS7LJCGw_e-huKg=.a0ba6d78-31d3-4b71-825d-c93abca3a896@github.com>

On Tue, 19 Oct 2021 20:20:00 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Looks like this test does not fail anymore.
>> 
>> It does not fail once even without changes, but I've added extra `waitForIdle()` just for safety.
>> 
>> Checked on ~350 test runs.
>
> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove wildcard imports
>  - cleanup

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6015


From serb at openjdk.java.net  Tue Oct 19 23:29:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 19 Oct 2021 23:29:06 GMT
Subject: RFR: 8233558: [TESTBUG] WindowOwnedByEmbeddedFrameTest.java fails
 on macos
In-Reply-To: <J2JVR0xAXruoxTSDNgFG8sNpLefmxKVTmjMoMTV2mcM=.e1427069-5ea4-4e87-8967-3febd9b11382@github.com>
References: <J2JVR0xAXruoxTSDNgFG8sNpLefmxKVTmjMoMTV2mcM=.e1427069-5ea4-4e87-8967-3febd9b11382@github.com>
Message-ID: <RO1dHZK9ZenUXQklRIfFSz2CC75oC_5I3vtRtm7Jyi0=.213f79bd-cbcc-4e33-94f0-f1f7b6858c45@github.com>

On Tue, 19 Oct 2021 17:27:03 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

> added export java.desktop/sun.lwawt.macosx:open

Looks fine

-------------

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6022


From serb at openjdk.java.net  Wed Oct 20 01:46:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 20 Oct 2021 01:46:10 GMT
Subject: RFR: 8255724: [XRender] the BlitRotateClippedArea test fails on
 Linux in the XR pipeline
In-Reply-To: <KHM4_5ntEG9EMuw_HYYgBjeUeXdSIBOzr7AER0wvxZ8=.f722e5c1-4c81-4ba3-9a67-869695eb6899@github.com>
References: <KHM4_5ntEG9EMuw_HYYgBjeUeXdSIBOzr7AER0wvxZ8=.f722e5c1-4c81-4ba3-9a67-869695eb6899@github.com>
Message-ID: <CbwHkO9_9tYwCsoOt3Y15RiZ7mO0LYWXIxNJoXV0NUc=.9c842dfa-f808-4865-9c39-6a27f6593ecd@github.com>

On Tue, 19 Oct 2021 09:56:07 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This test was added under https://bugs.openjdk.java.net/browse/JDK-8255722 to verify rotated blit operation. But it started failing XRender pipeline because of pixel color mismatch. Looks like we have minor difference in pixel color because of arithmetic precision differences in transformations.
> 
> This test fails every-time in XRender without tolerance and passes with +/-1 in Color values in CI systems. Updated test to use +/-1 tolerance as mentioned in JBS. Added this little tolerance in Color will not change functionality that we are verifying in this test.

Why it does not check for the xrender usage? As far as I remember all other pipelines work fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6002


From prr at openjdk.java.net  Wed Oct 20 04:06:05 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 20 Oct 2021 04:06:05 GMT
Subject: RFR: 8262945: [macos] Regression Manual Test for Key Events Fails
 [v3]
In-Reply-To: <k-0hmzZ-NTF8KavFyuo1m4RxJZjfB4b2INfWOwXX6JQ=.f34b98cd-5708-4a0e-96e0-0f6276fdc8eb@github.com>
References: <LhSIteG6WssDHH2if3oeA-0qLZGhxfqb11JyTC4EPh8=.b8b62eb4-a50c-4eb2-98c7-6f122f87d08b@github.com>
 <k-0hmzZ-NTF8KavFyuo1m4RxJZjfB4b2INfWOwXX6JQ=.f34b98cd-5708-4a0e-96e0-0f6276fdc8eb@github.com>
Message-ID: <9HGQPrp3YgPSXVBGPdfehecTYUvd-fy7sO-TmXwFVPs=.d6862a0e-22b4-45b9-bbdb-6b264e3946db@github.com>

On Mon, 27 Sep 2021 16:19:21 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

>> Added a check for active keyboard language and added support for Russian NSEvent keyCodes to JavaVirtualKeyCode translation. Originally, only English characters were checked for even if other languages were in native letterCharacterSet. Can be easily expanded to include other languages as well.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding comment explaining offset numbers

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5617


From jdv at openjdk.java.net  Wed Oct 20 04:18:17 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 20 Oct 2021 04:18:17 GMT
Subject: RFR: 8255724: [XRender] the BlitRotateClippedArea test fails on
 Linux in the XR pipeline
In-Reply-To: <CbwHkO9_9tYwCsoOt3Y15RiZ7mO0LYWXIxNJoXV0NUc=.9c842dfa-f808-4865-9c39-6a27f6593ecd@github.com>
References: <KHM4_5ntEG9EMuw_HYYgBjeUeXdSIBOzr7AER0wvxZ8=.f722e5c1-4c81-4ba3-9a67-869695eb6899@github.com>
 <CbwHkO9_9tYwCsoOt3Y15RiZ7mO0LYWXIxNJoXV0NUc=.9c842dfa-f808-4865-9c39-6a27f6593ecd@github.com>
Message-ID: <CqBH2cZZ6VrTUacoNzLLOC1pULFg__lQuw8RBSt3HHk=.6e219443-a106-4413-acec-08f5ec8732e1@github.com>

On Wed, 20 Oct 2021 01:43:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Why it does not check for the xrender usage? As far as I remember all other pipelines work fine.

@mrserb Yes i ran this test without fix on all platforms and it does pass in all pipelines except XRender. Since adding tolerance doesnt change original objective of this test i have not added any specific checks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6002


From prr at openjdk.java.net  Wed Oct 20 04:19:30 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 20 Oct 2021 04:19:30 GMT
Subject: RFR: 8198336: java/awt/FontMetrics/FontCrash.java fails in headless
 mode
Message-ID: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>

The code this test exercises is very obsolete. So this removes the test that triggers it along with that code.

-------------

Commit messages:
 - 8198336: java/awt/FontMetrics/FontCrash.java

Changes: https://git.openjdk.java.net/jdk/pull/6027/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6027&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8198336
  Stats: 92 lines in 5 files changed: 0 ins; 92 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6027.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6027/head:pull/6027

PR: https://git.openjdk.java.net/jdk/pull/6027


From psadhukhan at openjdk.java.net  Wed Oct 20 04:24:05 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Oct 2021 04:24:05 GMT
Subject: RFR: 8233648: [TESTBUG] DefaultMenuBarTest.java failing on macos
 [v2]
In-Reply-To: <ZdtvGTiO43LZJOe7T7ePsDkLIbU5Vrvd80xS6F586tA=.de37025c-bfaa-4c08-aa1a-08e85be7c801@github.com>
References: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>
 <ZdtvGTiO43LZJOe7T7ePsDkLIbU5Vrvd80xS6F586tA=.de37025c-bfaa-4c08-aa1a-08e85be7c801@github.com>
Message-ID: <Gp_hTiJ-psy4aBpSvwCoTmiCeuMMbypZvRS0mkSyI6w=.f82258d5-a0ca-4706-b656-d95b96d202ec@github.com>

On Tue, 19 Oct 2021 20:20:00 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Looks like this test does not fail anymore.
>> 
>> It does not fail once even without changes, but I've added extra `waitForIdle()` just for safety.
>> 
>> Checked on ~350 test runs.
>
> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove wildcard imports
>  - cleanup

One more thing..since you are setting apple.laf.useScreenMenuBar property, wouldn't it be prudent to run the test in main/othervm mode explicitly?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6015


From prr at openjdk.java.net  Wed Oct 20 04:33:08 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 20 Oct 2021 04:33:08 GMT
Subject: RFR: 8233648: [TESTBUG] DefaultMenuBarTest.java failing on macos
 [v2]
In-Reply-To: <ZdtvGTiO43LZJOe7T7ePsDkLIbU5Vrvd80xS6F586tA=.de37025c-bfaa-4c08-aa1a-08e85be7c801@github.com>
References: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>
 <ZdtvGTiO43LZJOe7T7ePsDkLIbU5Vrvd80xS6F586tA=.de37025c-bfaa-4c08-aa1a-08e85be7c801@github.com>
Message-ID: <hXuAsRhvqUWIVAny3NnL9WAdO0bc-66z9tC9BwYeeCg=.aad10d73-386b-47bb-86ac-bd97925feeb4@github.com>

On Tue, 19 Oct 2021 20:20:00 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Looks like this test does not fail anymore.
>> 
>> It does not fail once even without changes, but I've added extra `waitForIdle()` just for safety.
>> 
>> Checked on ~350 test runs.
>
> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove wildcard imports
>  - cleanup

One for the monitor list.
Could you add this bug ID to the @bug list - so it can be found more easily in case of recurrence ?

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6015


From kizune at openjdk.java.net  Wed Oct 20 04:37:06 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 20 Oct 2021 04:37:06 GMT
Subject: RFR: 8233558: [TESTBUG] WindowOwnedByEmbeddedFrameTest.java fails
 on macos
In-Reply-To: <J2JVR0xAXruoxTSDNgFG8sNpLefmxKVTmjMoMTV2mcM=.e1427069-5ea4-4e87-8967-3febd9b11382@github.com>
References: <J2JVR0xAXruoxTSDNgFG8sNpLefmxKVTmjMoMTV2mcM=.e1427069-5ea4-4e87-8967-3febd9b11382@github.com>
Message-ID: <KiI_BPzV60pugkLKsJ693-7wU6bzldo2TukxmLQbCNk=.cc41e6af-204e-4c18-af36-233636e5f454@github.com>

On Tue, 19 Oct 2021 17:27:03 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

> added export java.desktop/sun.lwawt.macosx:open

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6022


From psadhukhan at openjdk.java.net  Wed Oct 20 06:35:16 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Oct 2021 06:35:16 GMT
Subject: Integrated: 7124287: [macosx] JTableHeader doesn't get focus after
 pressing F8 key
In-Reply-To: <VPA0JzAMlevIwGlJADl82NuRM8LGVaryzMq4UzqQGb0=.ccc99f44-0fa2-4feb-ad60-cf4bc07f8ebb@github.com>
References: <VPA0JzAMlevIwGlJADl82NuRM8LGVaryzMq4UzqQGb0=.ccc99f44-0fa2-4feb-ad60-cf4bc07f8ebb@github.com>
Message-ID: <d8se3b1fxIDwQ38uIajoQ7gur5n5mDhzPy73WgL7TnA=.ba095eb6-40e0-4c2b-9dff-280684196860@github.com>

On Tue, 19 Oct 2021 16:57:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> JTableHeader doesn't get focus after pressing F8 key in macos causing test to fail. Added F8 keybindings to macos similar to 
> MetalLookAndFeel
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L1232
> and BasicLookAndFeel
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#L1497
> 
> Test is moved from closed to open and now passing in macos.

This pull request has now been integrated.

Changeset: 77b27893
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/77b27893969d84de7c890a60c3cccb99e89d5d91
Stats:     75 lines in 2 files changed: 74 ins; 0 del; 1 mod

7124287: [macosx] JTableHeader doesn't get focus after pressing F8 key

Reviewed-by: kizune

-------------

PR: https://git.openjdk.java.net/jdk/pull/6019


From serb at openjdk.java.net  Wed Oct 20 06:55:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 20 Oct 2021 06:55:07 GMT
Subject: RFR: 8233648: [TESTBUG] DefaultMenuBarTest.java failing on macos
 [v2]
In-Reply-To: <ZdtvGTiO43LZJOe7T7ePsDkLIbU5Vrvd80xS6F586tA=.de37025c-bfaa-4c08-aa1a-08e85be7c801@github.com>
References: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>
 <ZdtvGTiO43LZJOe7T7ePsDkLIbU5Vrvd80xS6F586tA=.de37025c-bfaa-4c08-aa1a-08e85be7c801@github.com>
Message-ID: <Va6i9aqWlAV5ONrjOJFNhF48YqCIeDFt0S8AozG1n5s=.31117610-6801-478c-ae0a-3d2afbc8fd30@github.com>

On Tue, 19 Oct 2021 20:20:00 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Looks like this test does not fail anymore.
>> 
>> It does not fail once even without changes, but I've added extra `waitForIdle()` just for safety.
>> 
>> Checked on ~350 test runs.
>
> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove wildcard imports
>  - cleanup

All tests for java client should be configured to be run, it is done via othervm.dirs option in the TEST.ROOT

-------------

PR: https://git.openjdk.java.net/jdk/pull/6015


From psadhukhan at openjdk.java.net  Wed Oct 20 07:02:06 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Oct 2021 07:02:06 GMT
Subject: RFR: 8233648: [TESTBUG] DefaultMenuBarTest.java failing on macos
 [v2]
In-Reply-To: <ZdtvGTiO43LZJOe7T7ePsDkLIbU5Vrvd80xS6F586tA=.de37025c-bfaa-4c08-aa1a-08e85be7c801@github.com>
References: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>
 <ZdtvGTiO43LZJOe7T7ePsDkLIbU5Vrvd80xS6F586tA=.de37025c-bfaa-4c08-aa1a-08e85be7c801@github.com>
Message-ID: <Zzqt4zcgWfhtJZPvCZn8Af-aO2DYMKhJzXub_sXdQvM=.ae680237-6bef-4942-951a-ca12a7912c28@github.com>

On Tue, 19 Oct 2021 20:20:00 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Looks like this test does not fail anymore.
>> 
>> It does not fail once even without changes, but I've added extra `waitForIdle()` just for safety.
>> 
>> Checked on ~350 test runs.
>
> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove wildcard imports
>  - cleanup

It is run in othervm mode for java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java 
java/awt/MenuBar/DefaultMenuBarDispose.java, java/awt/MenuBar/TestNoScreenMenuBar.java
setting the same property so I asked.
I know all jtreg tests are run in othervm mode but, in last few weeks, couple of tests have set othervm mode explicitly to be more safe PR of which was approved.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6015


From serb at openjdk.java.net  Wed Oct 20 07:04:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 20 Oct 2021 07:04:06 GMT
Subject: RFR: 8198336: java/awt/FontMetrics/FontCrash.java fails in
 headless mode
In-Reply-To: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>
References: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>
Message-ID: <1lDUR82e_OvDR55Au0p-i1MS6JI5-4TuHwUnlwNXqeU=.383aa1b2-83fb-4af4-8495-3173b31ab072@github.com>

On Wed, 20 Oct 2021 04:12:46 GMT, Phil Race <prr at openjdk.org> wrote:

> The code this test exercises is very obsolete. So this removes the test that triggers it along with that code.

src/java.desktop/windows/classes/sun/awt/windows/WToolkit.java line 696:

> 694:             && ((SunFontManager) fm).usePlatformFontMetrics()) {
> 695:             return WFontMetrics.getFontMetrics(font);
> 696:         }

The whole method can be removed? it is identical to the parent now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6027


From kizune at openjdk.java.net  Wed Oct 20 07:12:31 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 20 Oct 2021 07:12:31 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null"
Message-ID: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>

8168388: GetMousePositionTest fails with the message "Mouse position should not be null"

-------------

Commit messages:
 - 8168388: GetMousePositionTest fails with the message "Mouse position should not be null"

Changes: https://git.openjdk.java.net/jdk/pull/6028/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6028&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8168388
  Stats: 22 lines in 2 files changed: 6 ins; 2 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6028.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6028/head:pull/6028

PR: https://git.openjdk.java.net/jdk/pull/6028


From kizune at openjdk.java.net  Wed Oct 20 07:12:31 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 20 Oct 2021 07:12:31 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null"
In-Reply-To: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
Message-ID: <VPbKPJV6nh0PbQ8AsbhrtObkWwiwVI_hTJbfSnActVQ=.4c5d6072-ed8c-49e5-8e95-5b53d4feda77@github.com>

On Wed, 20 Oct 2021 07:04:18 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8168388: GetMousePositionTest fails with the message "Mouse position should not be null"

The main reason is that the second test frame is so small that if Window Manager decorations are tall enough mouse ended up on top of the frame border thus formally outside of the frame content. The main idea is to make frames undecorated so WM decorations do not interfere with the testing. Also did some general cleanup like moving frame manipulations to EDT, set the autodelay to a reasonable number and get rid of the statically provided coordinates for the last mouse position.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6028


From serb at openjdk.java.net  Wed Oct 20 07:21:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 20 Oct 2021 07:21:09 GMT
Subject: RFR: 8255724: [XRender] the BlitRotateClippedArea test fails on
 Linux in the XR pipeline
In-Reply-To: <KHM4_5ntEG9EMuw_HYYgBjeUeXdSIBOzr7AER0wvxZ8=.f722e5c1-4c81-4ba3-9a67-869695eb6899@github.com>
References: <KHM4_5ntEG9EMuw_HYYgBjeUeXdSIBOzr7AER0wvxZ8=.f722e5c1-4c81-4ba3-9a67-869695eb6899@github.com>
Message-ID: <5lB9ee1E7BguEESzy8qtH3FdxCY_mwXEqKwIsEQDp3c=.e5069127-d929-4eca-87c5-53a7144c534b@github.com>

On Tue, 19 Oct 2021 09:56:07 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This test was added under https://bugs.openjdk.java.net/browse/JDK-8255722 to verify rotated blit operation. But it started failing XRender pipeline because of pixel color mismatch. Looks like we have minor difference in pixel color because of arithmetic precision differences in transformations.
> 
> This test fails every-time in XRender without tolerance and passes with +/-1 in Color values in CI systems. Updated test to use +/-1 tolerance as mentioned in JBS. Added this little tolerance in Color will not change functionality that we are verifying in this test.

actually it does change the meaning of the test, take a look how it generate the pattern in the drawing image, to check many combination of colors. And in fact it found a bug in the XRender, so it will be good to preserve that strict requirements in the test for other/new pipelines.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6002


From psadhukhan at openjdk.java.net  Wed Oct 20 07:26:03 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Oct 2021 07:26:03 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null"
In-Reply-To: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
Message-ID: <4LdCt3a2NAilqVqPB082VefhWLdu3J6Wf4EvrhiJpFw=.019dbd7c-fec0-4b87-851a-97420d9476a8@github.com>

On Wed, 20 Oct 2021 07:04:18 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8168388: GetMousePositionTest fails with the message "Mouse position should not be null"

test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java line 34:

> 32:  * @key headful
> 33:  * @bug 8012026 8196435
> 34:  * @library ../../regtesthelpers

Why do you  need this?

test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java line 50:

> 48: 
> 49:         try {
> 50:             SwingUtilities.invokeAndWait(GetMousePositionWithOverlay::constructTestUI);

Do we need EDT as it is constructing a Frame and not a JFrame

-------------

PR: https://git.openjdk.java.net/jdk/pull/6028


From serb at openjdk.java.net  Wed Oct 20 07:29:02 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 20 Oct 2021 07:29:02 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null"
In-Reply-To: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
Message-ID: <qnTbsNMWe0TnWX_RgVZV37GNfDmAocrhGPky3t564ho=.5a5e73ec-a13e-4863-9810-8b983a6f2ffd@github.com>

On Wed, 20 Oct 2021 07:04:18 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8168388: GetMousePositionTest fails with the message "Mouse position should not be null"

Please confirm that an updated test still can be used for JDK-8012026.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6028


From kizune at openjdk.java.net  Wed Oct 20 08:25:08 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 20 Oct 2021 08:25:08 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null"
In-Reply-To: <4LdCt3a2NAilqVqPB082VefhWLdu3J6Wf4EvrhiJpFw=.019dbd7c-fec0-4b87-851a-97420d9476a8@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
 <4LdCt3a2NAilqVqPB082VefhWLdu3J6Wf4EvrhiJpFw=.019dbd7c-fec0-4b87-851a-97420d9476a8@github.com>
Message-ID: <mvouDrU3HnZtYg5OyVeqwz6nAhTDaRaB_qtHi8wKrCc=.227b6f29-1fea-44ec-9cd9-4b5f853bbebe@github.com>

On Wed, 20 Oct 2021 07:22:02 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> 8168388: GetMousePositionTest fails with the message "Mouse position should not be null"
>
> test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java line 34:
> 
>> 32:  * @key headful
>> 33:  * @bug 8012026 8196435
>> 34:  * @library ../../regtesthelpers
> 
> Why do you  need this?

I wanted to use Util to use some helper methods but then decided not to change that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6028


From kizune at openjdk.java.net  Wed Oct 20 08:33:07 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 20 Oct 2021 08:33:07 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null"
In-Reply-To: <qnTbsNMWe0TnWX_RgVZV37GNfDmAocrhGPky3t564ho=.5a5e73ec-a13e-4863-9810-8b983a6f2ffd@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
 <qnTbsNMWe0TnWX_RgVZV37GNfDmAocrhGPky3t564ho=.5a5e73ec-a13e-4863-9810-8b983a6f2ffd@github.com>
Message-ID: <A9DsFfazwLXOh6hxdQMIrfZn-eP9rFpbBAzvlpP0yf0=.61097f2c-504d-4e93-abe4-7ef2d0e008ad@github.com>

On Wed, 20 Oct 2021 07:26:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please confirm that an updated test still can be used for JDK-8012026.

Yes it does. In general the logic of the test has not changed i just removed false negative due to the mouse position was overlapped by the WM window decorations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6028


From kizune at openjdk.java.net  Wed Oct 20 08:33:09 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 20 Oct 2021 08:33:09 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null"
In-Reply-To: <4LdCt3a2NAilqVqPB082VefhWLdu3J6Wf4EvrhiJpFw=.019dbd7c-fec0-4b87-851a-97420d9476a8@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
 <4LdCt3a2NAilqVqPB082VefhWLdu3J6Wf4EvrhiJpFw=.019dbd7c-fec0-4b87-851a-97420d9476a8@github.com>
Message-ID: <Rkv9J-Y93Pi85h3hjSTS-bYIPGXm3q0FvZazV5ad86g=.3f0b506b-4d1a-4023-af7e-6873c072176b@github.com>

On Wed, 20 Oct 2021 07:22:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> 8168388: GetMousePositionTest fails with the message "Mouse position should not be null"
>
> test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java line 50:
> 
>> 48: 
>> 49:         try {
>> 50:             SwingUtilities.invokeAndWait(GetMousePositionWithOverlay::constructTestUI);
> 
> Do we need EDT as it is constructing a Frame and not a JFrame

It does not hurt so i tend to use it just to make execution more streamlined.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6028


From kizune at openjdk.java.net  Wed Oct 20 08:44:38 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 20 Oct 2021 08:44:38 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null" [v2]
In-Reply-To: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
Message-ID: <Jya383ifS0mIQg8RLdv3_n4_YHzeDaokE4uw-MoEt7E=.ac4293d1-19bf-4c86-a336-a365e4e65134@github.com>

> 8168388: GetMousePositionTest fails with the message "Mouse position should not be null"

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Removed regtesthepler library requirement

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6028/files
  - new: https://git.openjdk.java.net/jdk/pull/6028/files/8c3c08d1..e53239a1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6028&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6028&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6028.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6028/head:pull/6028

PR: https://git.openjdk.java.net/jdk/pull/6028


From psadhukhan at openjdk.java.net  Wed Oct 20 09:01:08 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Oct 2021 09:01:08 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null" [v2]
In-Reply-To: <Jya383ifS0mIQg8RLdv3_n4_YHzeDaokE4uw-MoEt7E=.ac4293d1-19bf-4c86-a336-a365e4e65134@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
 <Jya383ifS0mIQg8RLdv3_n4_YHzeDaokE4uw-MoEt7E=.ac4293d1-19bf-4c86-a336-a365e4e65134@github.com>
Message-ID: <lkmCjqCKuGeMVWYmuyA0FHer-GX8NwgT6_AOmLD9JcU=.702c8707-ecdf-43f8-8b72-c5c06f5ce9d0@github.com>

On Wed, 20 Oct 2021 08:44:38 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 8168388: GetMousePositionTest fails with the message "Mouse position should not be null"
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed regtesthepler library requirement

SInce you are touching the test, maybe you can consider calling dispose in finally block rather than being called so many times in the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6028


From azvegint at openjdk.java.net  Wed Oct 20 11:53:33 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 20 Oct 2021 11:53:33 GMT
Subject: RFR: 8233648: [TESTBUG] DefaultMenuBarTest.java failing on macos
 [v3]
In-Reply-To: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>
References: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>
Message-ID: <ZIC4GSwFxy8qh0OfqzFTgehlfq4WdI722uG39D9up0M=.c259d903-de56-42b3-8c5b-fdd478916d3c@github.com>

> Looks like this test does not fail anymore.
> 
> It does not fail once even without changes, but I've added extra `waitForIdle()` just for safety.
> 
> Checked on ~350 test runs.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  added bugid, othervm

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6015/files
  - new: https://git.openjdk.java.net/jdk/pull/6015/files/e1c0625e..ae25e228

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6015&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6015&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6015.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6015/head:pull/6015

PR: https://git.openjdk.java.net/jdk/pull/6015


From azvegint at openjdk.java.net  Wed Oct 20 12:13:34 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 20 Oct 2021 12:13:34 GMT
Subject: RFR: 8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu
Message-ID: <qg109bdSP2hEfYj2OX60PzZpasVQ7gYUf9YpXC1UbXg=.cf7eac5e-623a-426d-adff-8328a9a5c63f@github.com>

Looks like the test started failing after increasing of window's title height in Ubuntu theme:

![image](https://user-images.githubusercontent.com/77687766/138088503-f380bcb2-1ffc-4d58-b6b2-2efc56b7975c.png)
So the click happens on windows title instead of the button.

For example, macOS has smaller window title height, which allows test to pass.
<img src="https://user-images.githubusercontent.com/77687766/138088659-bd636518-c23c-4c5e-bf97-61035753c71a.png" width="50%" height="50%">

Fix moves buttons away from window title.
![image](https://user-images.githubusercontent.com/77687766/138088880-a9d1ec38-cde2-437e-80b9-5b7bdf73fd6b.png)

Testing is green.

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/6040/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6040&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8225777
  Stats: 32 lines in 2 files changed: 5 ins; 15 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6040.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6040/head:pull/6040

PR: https://git.openjdk.java.net/jdk/pull/6040


From psadhukhan at openjdk.java.net  Wed Oct 20 12:27:05 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Oct 2021 12:27:05 GMT
Subject: RFR: 8233648: [TESTBUG] DefaultMenuBarTest.java failing on macos
 [v3]
In-Reply-To: <ZIC4GSwFxy8qh0OfqzFTgehlfq4WdI722uG39D9up0M=.c259d903-de56-42b3-8c5b-fdd478916d3c@github.com>
References: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>
 <ZIC4GSwFxy8qh0OfqzFTgehlfq4WdI722uG39D9up0M=.c259d903-de56-42b3-8c5b-fdd478916d3c@github.com>
Message-ID: <F1iPrKl9bAwymbLOxUAHVc6qpc--6-cUZjfApvyAoR0=.09dbf92d-4f96-4c16-ba8f-7100dedef3fa@github.com>

On Wed, 20 Oct 2021 11:53:33 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Looks like this test does not fail anymore.
>> 
>> It does not fail once even without changes, but I've added extra `waitForIdle()` just for safety.
>> 
>> Checked on ~350 test runs.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added bugid, othervm

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6015


From psadhukhan at openjdk.java.net  Wed Oct 20 12:56:13 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 20 Oct 2021 12:56:13 GMT
Subject: RFR: 8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu
In-Reply-To: <qg109bdSP2hEfYj2OX60PzZpasVQ7gYUf9YpXC1UbXg=.cf7eac5e-623a-426d-adff-8328a9a5c63f@github.com>
References: <qg109bdSP2hEfYj2OX60PzZpasVQ7gYUf9YpXC1UbXg=.cf7eac5e-623a-426d-adff-8328a9a5c63f@github.com>
Message-ID: <jixEoBSgEO0LziMrpf6IQoKfYxW4medffjLrqkNaeXI=.a08ac21d-17a3-4db5-b877-c388ebcba2c5@github.com>

On Wed, 20 Oct 2021 12:05:57 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Looks like the test started failing after increasing of window's title height in Ubuntu theme:
> 
> ![image](https://user-images.githubusercontent.com/77687766/138088503-f380bcb2-1ffc-4d58-b6b2-2efc56b7975c.png)
> So the click happens on windows title instead of the button.
> 
> For example, macOS has smaller window title height, which allows test to pass.
> <img src="https://user-images.githubusercontent.com/77687766/138088659-bd636518-c23c-4c5e-bf97-61035753c71a.png" width="50%" height="50%">
> 
> Fix moves buttons away from window title.
> ![image](https://user-images.githubusercontent.com/77687766/138088880-a9d1ec38-cde2-437e-80b9-5b7bdf73fd6b.png)
> 
> Testing is green.

test/jdk/java/awt/Mixing/MixingOnDialog.java line 71:

> 69:         // Overlap the buttons
> 70:         heavy.setBounds(130, 130, 200, 200);
> 71:         light.setBounds(110, 110, 50, 50);

Probably you can call setUndecorated instead of changing the coordinate to avoid the issue. Also, maybe move the dialog to centre of screen...Also, I see setAutoDelay(20) is too less, should be consistent with other test which is 100ms

-------------

PR: https://git.openjdk.java.net/jdk/pull/6040


From kizune at openjdk.java.net  Wed Oct 20 14:04:32 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 20 Oct 2021 14:04:32 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null" [v3]
In-Reply-To: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
Message-ID: <fsRp2-2OzU2eYz7odk8Yv8Zh0de_ECny5z2YzKHb-YY=.4d8f1648-80d1-4936-82e4-e8928e4c1435@github.com>

> 8168388: GetMousePositionTest fails with the message "Mouse position should not be null"

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Call dispose() from the test final block. Also added original exception to the unexpected exception handler for easier triage in the future.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6028/files
  - new: https://git.openjdk.java.net/jdk/pull/6028/files/e53239a1..382c31f8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6028&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6028&range=01-02

  Stats: 15 lines in 1 file changed: 8 ins; 7 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6028.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6028/head:pull/6028

PR: https://git.openjdk.java.net/jdk/pull/6028


From kizune at openjdk.java.net  Wed Oct 20 14:04:34 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 20 Oct 2021 14:04:34 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null" [v2]
In-Reply-To: <lkmCjqCKuGeMVWYmuyA0FHer-GX8NwgT6_AOmLD9JcU=.702c8707-ecdf-43f8-8b72-c5c06f5ce9d0@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
 <Jya383ifS0mIQg8RLdv3_n4_YHzeDaokE4uw-MoEt7E=.ac4293d1-19bf-4c86-a336-a365e4e65134@github.com>
 <lkmCjqCKuGeMVWYmuyA0FHer-GX8NwgT6_AOmLD9JcU=.702c8707-ecdf-43f8-8b72-c5c06f5ce9d0@github.com>
Message-ID: <8v2RRQXgxcvig6Sfv5NkDOQ-2GyD2mics4luambChXI=.23a91338-7cd6-4ff5-ba09-1620980014fa@github.com>

On Wed, 20 Oct 2021 08:57:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> SInce you are touching the test, maybe you can consider calling dispose in finally block rather than being called so many times in the test.

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6028


From azvegint at openjdk.java.net  Wed Oct 20 16:46:31 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 20 Oct 2021 16:46:31 GMT
Subject: RFR: 8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu
 [v2]
In-Reply-To: <jixEoBSgEO0LziMrpf6IQoKfYxW4medffjLrqkNaeXI=.a08ac21d-17a3-4db5-b877-c388ebcba2c5@github.com>
References: <qg109bdSP2hEfYj2OX60PzZpasVQ7gYUf9YpXC1UbXg=.cf7eac5e-623a-426d-adff-8328a9a5c63f@github.com>
 <jixEoBSgEO0LziMrpf6IQoKfYxW4medffjLrqkNaeXI=.a08ac21d-17a3-4db5-b877-c388ebcba2c5@github.com>
Message-ID: <xqt-c51aloFFg5rlcPxXU7zRrED3UOLVylfJxjioDnQ=.a3888c8c-9b9a-412f-8b24-7d1308ad68a5@github.com>

On Wed, 20 Oct 2021 12:52:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - d.setLocationRelativeTo(null);
>>  - increase auto delay
>
> test/jdk/java/awt/Mixing/MixingOnDialog.java line 71:
> 
>> 69:         // Overlap the buttons
>> 70:         heavy.setBounds(130, 130, 200, 200);
>> 71:         light.setBounds(110, 110, 50, 50);
> 
> Probably you can call setUndecorated instead of changing the coordinate to avoid the issue. Also, maybe move the dialog to centre of screen...Also, I see setAutoDelay(20) is too less, should be consistent with other test which is 100ms

Yes, `setUndecorated` is one of possible solutions, however it looks equal to changing location.

Updated the delay and dialog's location.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6040


From azvegint at openjdk.java.net  Wed Oct 20 16:46:30 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 20 Oct 2021 16:46:30 GMT
Subject: RFR: 8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu
 [v2]
In-Reply-To: <qg109bdSP2hEfYj2OX60PzZpasVQ7gYUf9YpXC1UbXg=.cf7eac5e-623a-426d-adff-8328a9a5c63f@github.com>
References: <qg109bdSP2hEfYj2OX60PzZpasVQ7gYUf9YpXC1UbXg=.cf7eac5e-623a-426d-adff-8328a9a5c63f@github.com>
Message-ID: <suY5K52zoRNpqHYj1eNRUEkzhdD-rDZVKNplUudSKtc=.5288390a-c025-4f7a-ad0d-d61cb3feaa24@github.com>

> Looks like the test started failing after increasing of window's title height in Ubuntu theme:
> 
> ![image](https://user-images.githubusercontent.com/77687766/138088503-f380bcb2-1ffc-4d58-b6b2-2efc56b7975c.png)
> So the click happens on windows title instead of the button.
> 
> For example, macOS has smaller window title height, which allows test to pass.
> <img src="https://user-images.githubusercontent.com/77687766/138088659-bd636518-c23c-4c5e-bf97-61035753c71a.png" width="50%" height="50%">
> 
> Fix moves buttons away from window title.
> ![image](https://user-images.githubusercontent.com/77687766/138088880-a9d1ec38-cde2-437e-80b9-5b7bdf73fd6b.png)
> 
> Testing is green.

Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:

 - d.setLocationRelativeTo(null);
 - increase auto delay

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6040/files
  - new: https://git.openjdk.java.net/jdk/pull/6040/files/73f085be..f1806ef2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6040&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6040&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6040.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6040/head:pull/6040

PR: https://git.openjdk.java.net/jdk/pull/6040


From azvegint at openjdk.java.net  Wed Oct 20 16:48:10 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 20 Oct 2021 16:48:10 GMT
Subject: Integrated: 8233648: [TESTBUG] DefaultMenuBarTest.java failing on
 macos
In-Reply-To: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>
References: <qDzs8IxQ5ETkLgL97SxQGok2UzH6CI_izHf52TTq_ds=.54df166c-9554-4dfb-8702-262ca465af2c@github.com>
Message-ID: <n2ci1c6il2qH-ghsF5GHINbKrYBR64jsXGdgOGk0JHs=.6fb78927-1b9f-4703-809e-3a5109efb8b6@github.com>

On Tue, 19 Oct 2021 14:12:24 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Looks like this test does not fail anymore.
> 
> It does not fail once even without changes, but I've added extra `waitForIdle()` just for safety.
> 
> Checked on ~350 test runs.

This pull request has now been integrated.

Changeset: 46b5bfbc
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/46b5bfbc38f14607f0db686a42f1fa96d2f61891
Stats:     29 lines in 2 files changed: 6 ins; 13 del; 10 mod

8233648: [TESTBUG] DefaultMenuBarTest.java failing on macos

Reviewed-by: pbansal, serb, psadhukhan, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/6015


From prr at openjdk.java.net  Wed Oct 20 16:48:41 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 20 Oct 2021 16:48:41 GMT
Subject: RFR: 8198336: java/awt/FontMetrics/FontCrash.java fails in
 headless mode [v2]
In-Reply-To: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>
References: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>
Message-ID: <e4B62Qda_-qetOo2Nk3yEa-vKpmHcLHxglPpTAygkw4=.ea73dde9-d9b8-4d34-ad41-eaa8739a57ff@github.com>

> The code this test exercises is very obsolete. So this removes the test that triggers it along with that code.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8198336: java/awt/FontMetrics/FontCrash.java fails in headless mode

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6027/files
  - new: https://git.openjdk.java.net/jdk/pull/6027/files/c86b4ef3..74583d37

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6027&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6027&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6027.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6027/head:pull/6027

PR: https://git.openjdk.java.net/jdk/pull/6027


From prr at openjdk.java.net  Wed Oct 20 16:48:45 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 20 Oct 2021 16:48:45 GMT
Subject: RFR: 8198336: java/awt/FontMetrics/FontCrash.java fails in
 headless mode [v2]
In-Reply-To: <1lDUR82e_OvDR55Au0p-i1MS6JI5-4TuHwUnlwNXqeU=.383aa1b2-83fb-4af4-8495-3173b31ab072@github.com>
References: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>
 <1lDUR82e_OvDR55Au0p-i1MS6JI5-4TuHwUnlwNXqeU=.383aa1b2-83fb-4af4-8495-3173b31ab072@github.com>
Message-ID: <5seTVbfbbL5Jh6qp7LIrgg5hKDjy4xnBb6rlw6vdHSA=.78f55c23-ddc4-47c5-8e7b-322728202f74@github.com>

On Wed, 20 Oct 2021 06:58:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8198336: java/awt/FontMetrics/FontCrash.java fails in headless mode
>
> src/java.desktop/windows/classes/sun/awt/windows/WToolkit.java line 696:
> 
>> 694:             && ((SunFontManager) fm).usePlatformFontMetrics()) {
>> 695:             return WFontMetrics.getFontMetrics(font);
>> 696:         }
> 
> The whole method can be removed? it is identical to the parent now.

true, I can't see any reason to keep it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6027


From prr at openjdk.java.net  Wed Oct 20 18:54:07 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 20 Oct 2021 18:54:07 GMT
Subject: RFR: 8233558: [TESTBUG] WindowOwnedByEmbeddedFrameTest.java fails
 on macos
In-Reply-To: <J2JVR0xAXruoxTSDNgFG8sNpLefmxKVTmjMoMTV2mcM=.e1427069-5ea4-4e87-8967-3febd9b11382@github.com>
References: <J2JVR0xAXruoxTSDNgFG8sNpLefmxKVTmjMoMTV2mcM=.e1427069-5ea4-4e87-8967-3febd9b11382@github.com>
Message-ID: <XpkanyoB6OwQaPckmSzAGrn5ElE4bQRq6mAidbj4kGM=.2a417e47-7c45-43ea-b9a1-5b8df2271df1@github.com>

On Tue, 19 Oct 2021 17:27:03 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

> added export java.desktop/sun.lwawt.macosx:open

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6022


From duke at openjdk.java.net  Wed Oct 20 18:54:08 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Wed, 20 Oct 2021 18:54:08 GMT
Subject: Integrated: 8233558: [TESTBUG] WindowOwnedByEmbeddedFrameTest.java
 fails on macos
In-Reply-To: <J2JVR0xAXruoxTSDNgFG8sNpLefmxKVTmjMoMTV2mcM=.e1427069-5ea4-4e87-8967-3febd9b11382@github.com>
References: <J2JVR0xAXruoxTSDNgFG8sNpLefmxKVTmjMoMTV2mcM=.e1427069-5ea4-4e87-8967-3febd9b11382@github.com>
Message-ID: <_lp2CaFTAWLw0ci0Mq9caH4iAqZpiVlku6nY3UvIGa0=.600c7b37-c85f-4a0d-8951-9842b769ae19@github.com>

On Tue, 19 Oct 2021 17:27:03 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

> added export java.desktop/sun.lwawt.macosx:open

This pull request has now been integrated.

Changeset: d1e3ca4e
Author:    Alisen Chung <alisen.chung at oracle.com>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d1e3ca4ee35bf4c2ce9b6dae2518f533f36a98dd
Stats:     2 lines in 2 files changed: 0 ins; 1 del; 1 mod

8233558: [TESTBUG] WindowOwnedByEmbeddedFrameTest.java fails on macos

Reviewed-by: serb, kizune, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/6022


From tnakamura at openjdk.java.net  Thu Oct 21 00:57:47 2021
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Thu, 21 Oct 2021 00:57:47 GMT
Subject: RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese
 characters were garbled [v3]
In-Reply-To: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
References: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
Message-ID: <wtw6CL7UmKW6QM67dWNhZNGz2N1dQOvVs_-0w57iKao=.9c965195-4343-48b4-a8b0-65d75a38da23@github.com>

> Hi,
> 
> Could you review the fix?
> When non-English characters were printed from JTable on MacOS, CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, CTextPipe seems not support glyph with slot number of composite fonts.
> 
> The slot data mask of GlyphVector is 0xff000000. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn.

Toshio Nakamura has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
 - revert previous proposal
 - Merge branch 'master' into 8240756
 - 2nd proposal
 - Revert previous change
 - Merge branch 'master' into 8240756
   merge master
 - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3619/files
  - new: https://git.openjdk.java.net/jdk/pull/3619/files/c2910791..c52a9f98

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3619&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3619&range=01-02

  Stats: 233347 lines in 4569 files changed: 153154 ins; 56185 del; 24008 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3619.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3619/head:pull/3619

PR: https://git.openjdk.java.net/jdk/pull/3619


From tnakamura at openjdk.java.net  Thu Oct 21 00:57:59 2021
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Thu, 21 Oct 2021 00:57:59 GMT
Subject: RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese
 characters were garbled [v2]
In-Reply-To: <gSWVk7c86gLoQBXz4BUgx_lBDXMlpcX52cte4mf96ss=.134edd2c-4630-4df4-b0e3-ba1d31328a1c@github.com>
References: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
 <gSWVk7c86gLoQBXz4BUgx_lBDXMlpcX52cte4mf96ss=.134edd2c-4630-4df4-b0e3-ba1d31328a1c@github.com>
Message-ID: <6TMt6bRyBaySaK-KhSsgthXLuqiSarSflw7xDBsdDlo=.8b0accd3-8a67-4887-8ac5-84ec75983b67@github.com>

On Thu, 17 Jun 2021 09:29:07 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

>> Hi,
>> 
>> Could you review the fix?
>> When non-English characters were printed from JTable on MacOS, CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, CTextPipe seems not support glyph with slot number of composite fonts.
>> 
>> The slot data mask of GlyphVector is 0xff000000. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn.
>
> Toshio Nakamura has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - 2nd proposal
>  - Revert previous change
>  - Merge branch 'master' into 8240756
>    merge master
>  - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled

Sorry for the long interruption.
I completely revised the fix. The new proposal could be combined the modifications into MacOS specific class.
Please review the latest version.

Tests: tier1, java/awt, and javax.swing on MacOS (BigSur)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3619


From serb at openjdk.java.net  Thu Oct 21 01:37:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 21 Oct 2021 01:37:05 GMT
Subject: RFR: 8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu
 [v2]
In-Reply-To: <xqt-c51aloFFg5rlcPxXU7zRrED3UOLVylfJxjioDnQ=.a3888c8c-9b9a-412f-8b24-7d1308ad68a5@github.com>
References: <qg109bdSP2hEfYj2OX60PzZpasVQ7gYUf9YpXC1UbXg=.cf7eac5e-623a-426d-adff-8328a9a5c63f@github.com>
 <jixEoBSgEO0LziMrpf6IQoKfYxW4medffjLrqkNaeXI=.a08ac21d-17a3-4db5-b877-c388ebcba2c5@github.com>
 <xqt-c51aloFFg5rlcPxXU7zRrED3UOLVylfJxjioDnQ=.a3888c8c-9b9a-412f-8b24-7d1308ad68a5@github.com>
Message-ID: <TlNEql1a7-ZSYQlSi6_QiRSjpaelG-0izeSt9zkmnyc=.03e8f182-245e-4fcd-b843-d242077a085a@github.com>

On Wed, 20 Oct 2021 16:42:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> test/jdk/java/awt/Mixing/MixingOnDialog.java line 71:
>> 
>>> 69:         // Overlap the buttons
>>> 70:         heavy.setBounds(130, 130, 200, 200);
>>> 71:         light.setBounds(110, 110, 50, 50);
>> 
>> Probably you can call setUndecorated instead of changing the coordinate to avoid the issue. Also, maybe move the dialog to centre of screen...Also, I see setAutoDelay(20) is too less, should be consistent with other test which is 100ms
>
> Yes, `setUndecorated` is one of possible solutions, however it looks equal to changing location.
> 
> Updated the delay and dialog's location.

Can you please double-check all Mixing tests, some of the problem listed, but I think most of them has the same issue related to the big window decoration especially on windows 10 and the latest ubuntu?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6040


From serb at openjdk.java.net  Thu Oct 21 01:38:04 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 21 Oct 2021 01:38:04 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null" [v3]
In-Reply-To: <fsRp2-2OzU2eYz7odk8Yv8Zh0de_ECny5z2YzKHb-YY=.4d8f1648-80d1-4936-82e4-e8928e4c1435@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
 <fsRp2-2OzU2eYz7odk8Yv8Zh0de_ECny5z2YzKHb-YY=.4d8f1648-80d1-4936-82e4-e8928e4c1435@github.com>
Message-ID: <s9L7ICEIQaA7PFtNu18NWBr84y2RISOIReMvoRm6mOg=.0d62c41f-7d54-43d1-8d04-9d65d142a54f@github.com>

On Wed, 20 Oct 2021 14:04:32 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 8168388: GetMousePositionTest fails with the message "Mouse position should not be null"
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Call dispose() from the test final block. Also added original exception to the unexpected exception handler for easier triage in the future.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6028


From serb at openjdk.java.net  Thu Oct 21 01:38:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 21 Oct 2021 01:38:08 GMT
Subject: RFR: 8198336: java/awt/FontMetrics/FontCrash.java fails in
 headless mode [v2]
In-Reply-To: <e4B62Qda_-qetOo2Nk3yEa-vKpmHcLHxglPpTAygkw4=.ea73dde9-d9b8-4d34-ad41-eaa8739a57ff@github.com>
References: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>
 <e4B62Qda_-qetOo2Nk3yEa-vKpmHcLHxglPpTAygkw4=.ea73dde9-d9b8-4d34-ad41-eaa8739a57ff@github.com>
Message-ID: <WkudWu7KD8qzNueBv6BrImWwBNH69170bjgNtkh3JH4=.93a3bc41-fb04-4069-b041-28a16d2509f6@github.com>

On Wed, 20 Oct 2021 16:48:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> The code this test exercises is very obsolete. So this removes the test that triggers it along with that code.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8198336: java/awt/FontMetrics/FontCrash.java fails in headless mode

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6027


From azvegint at openjdk.java.net  Thu Oct 21 02:11:19 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 21 Oct 2021 02:11:19 GMT
Subject: RFR: 8202932:
 java/awt/Component/NativeInLightShow/NativeInLightShow.java fails
Message-ID: <vY4S5SLgt0RvQVidwLC5Kqp37ljbyIM_K735XfBlyl8=.5015954d-5207-4095-82bd-ab6608a77151@github.com>

Looks like the test does not fail anymore.

However some cleanup was made:

- fixed wildcard imports
- frame centered and explicitly disposed at the end
- removed unused `setAutoDelay()` call (no key/mouse key events generated)
- improved variable naming

Testing still green.

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/6056/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6056&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8202932
  Stats: 54 lines in 2 files changed: 17 ins; 19 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6056.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6056/head:pull/6056

PR: https://git.openjdk.java.net/jdk/pull/6056


From psadhukhan at openjdk.java.net  Thu Oct 21 04:27:07 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 21 Oct 2021 04:27:07 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null" [v3]
In-Reply-To: <fsRp2-2OzU2eYz7odk8Yv8Zh0de_ECny5z2YzKHb-YY=.4d8f1648-80d1-4936-82e4-e8928e4c1435@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
 <fsRp2-2OzU2eYz7odk8Yv8Zh0de_ECny5z2YzKHb-YY=.4d8f1648-80d1-4936-82e4-e8928e4c1435@github.com>
Message-ID: <EEe4u6m-fC4rCb_XxFeBUj6nEqq_I0vboV1ZV41Aeeg=.02347571-0fd0-4338-9e80-1ec3ecb05be5@github.com>

On Wed, 20 Oct 2021 14:04:32 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 8168388: GetMousePositionTest fails with the message "Mouse position should not be null"
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Call dispose() from the test final block. Also added original exception to the unexpected exception handler for easier triage in the future.

test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java line 52:

> 50:             doTest();
> 51:         } catch (Exception e) {
> 52:             if (e instanceof RuntimeException) {

Do we need this catch block? I guess main() throws Exception so we can just have try-finally block, no?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6028


From jdv at openjdk.java.net  Thu Oct 21 05:16:11 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 21 Oct 2021 05:16:11 GMT
Subject: RFR: 8255724: [XRender] the BlitRotateClippedArea test fails on
 Linux in the XR pipeline
In-Reply-To: <5lB9ee1E7BguEESzy8qtH3FdxCY_mwXEqKwIsEQDp3c=.e5069127-d929-4eca-87c5-53a7144c534b@github.com>
References: <KHM4_5ntEG9EMuw_HYYgBjeUeXdSIBOzr7AER0wvxZ8=.f722e5c1-4c81-4ba3-9a67-869695eb6899@github.com>
 <5lB9ee1E7BguEESzy8qtH3FdxCY_mwXEqKwIsEQDp3c=.e5069127-d929-4eca-87c5-53a7144c534b@github.com>
Message-ID: <ttoaA1428euvGE0foQIt15Ki9tZ5CQfK6H7y0agUya4=.617c31a2-ba4a-4136-93fe-ba698d7f3a06@github.com>

On Wed, 20 Oct 2021 07:18:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This test was added under https://bugs.openjdk.java.net/browse/JDK-8255722 to verify rotated blit operation. But it started failing XRender pipeline because of pixel color mismatch. Looks like we have minor difference in pixel color because of arithmetic precision differences in transformations.
>> 
>> This test fails every-time in XRender without tolerance and passes with +/-1 in Color values in CI systems. Updated test to use +/-1 tolerance as mentioned in JBS. Added this little tolerance in Color will not change functionality that we are verifying in this test.
>
> actually it does change the meaning of the test, take a look how it generate the pattern in the drawing image, to check many combination of colors. And in fact it found a bug in the XRender, so it will be good to preserve that strict requirements in the test for other/new pipelines.

@mrserb I have created follow up bug for the same : https://bugs.openjdk.java.net/browse/JDK-8275689

-------------

PR: https://git.openjdk.java.net/jdk/pull/6002


From kizune at openjdk.java.net  Thu Oct 21 06:00:10 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 21 Oct 2021 06:00:10 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null" [v3]
In-Reply-To: <EEe4u6m-fC4rCb_XxFeBUj6nEqq_I0vboV1ZV41Aeeg=.02347571-0fd0-4338-9e80-1ec3ecb05be5@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
 <fsRp2-2OzU2eYz7odk8Yv8Zh0de_ECny5z2YzKHb-YY=.4d8f1648-80d1-4936-82e4-e8928e4c1435@github.com>
 <EEe4u6m-fC4rCb_XxFeBUj6nEqq_I0vboV1ZV41Aeeg=.02347571-0fd0-4338-9e80-1ec3ecb05be5@github.com>
Message-ID: <KSuLZ5hXF3Hb2PSIdY9VotITs6CBlJPb5SG6qPft5r8=.af491bb3-8fff-42c9-972d-8c3264b20960@github.com>

On Thu, 21 Oct 2021 04:24:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Call dispose() from the test final block. Also added original exception to the unexpected exception handler for easier triage in the future.
>
> test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java line 52:
> 
>> 50:             doTest();
>> 51:         } catch (Exception e) {
>> 52:             if (e instanceof RuntimeException) {
> 
> Do we need this catch block? I guess main() throws Exception so we can just have try-finally block, no?

The catch block was already there and i decided not to remove it and moved the rest of the code instead of the try block.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6028


From psadhukhan at openjdk.java.net  Thu Oct 21 06:14:02 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 21 Oct 2021 06:14:02 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null" [v3]
In-Reply-To: <KSuLZ5hXF3Hb2PSIdY9VotITs6CBlJPb5SG6qPft5r8=.af491bb3-8fff-42c9-972d-8c3264b20960@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
 <fsRp2-2OzU2eYz7odk8Yv8Zh0de_ECny5z2YzKHb-YY=.4d8f1648-80d1-4936-82e4-e8928e4c1435@github.com>
 <EEe4u6m-fC4rCb_XxFeBUj6nEqq_I0vboV1ZV41Aeeg=.02347571-0fd0-4338-9e80-1ec3ecb05be5@github.com>
 <KSuLZ5hXF3Hb2PSIdY9VotITs6CBlJPb5SG6qPft5r8=.af491bb3-8fff-42c9-972d-8c3264b20960@github.com>
Message-ID: <zc9V8DMxJ9KBDROIQetf0IlQ1mCDAYvjNJBMwpnaVEk=.4896ea20-8e79-4b9a-8ec4-8098075493e7@github.com>

On Thu, 21 Oct 2021 05:57:30 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java line 52:
>> 
>>> 50:             doTest();
>>> 51:         } catch (Exception e) {
>>> 52:             if (e instanceof RuntimeException) {
>> 
>> Do we need this catch block? I guess main() throws Exception so we can just have try-finally block, no?
>
> The catch block was already there and i decided not to remove it and moved the rest of the code instead of the try block.

I know it was already there but since you are touching the test, it might be better to better the code to remove unneeded block, as here we are just catching exception and rethrowing, when we already have main() signature having "throws Throwable"

-------------

PR: https://git.openjdk.java.net/jdk/pull/6028


From serb at openjdk.java.net  Thu Oct 21 07:46:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 21 Oct 2021 07:46:09 GMT
Subject: RFR: 8202932:
 java/awt/Component/NativeInLightShow/NativeInLightShow.java fails
In-Reply-To: <vY4S5SLgt0RvQVidwLC5Kqp37ljbyIM_K735XfBlyl8=.5015954d-5207-4095-82bd-ab6608a77151@github.com>
References: <vY4S5SLgt0RvQVidwLC5Kqp37ljbyIM_K735XfBlyl8=.5015954d-5207-4095-82bd-ab6608a77151@github.com>
Message-ID: <TuhwolAvm-j5Gc68dsH-zaFkqQlqDGMNf88ef6mHwNk=.9d52eed5-bf8d-4d94-8540-8426c08f8175@github.com>

On Thu, 21 Oct 2021 02:04:01 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Looks like the test does not fail anymore.
> 
> However some cleanup was made:
> 
> - fixed wildcard imports
> - frame centered and explicitly disposed at the end
> - removed unused `setAutoDelay()` call (no key/mouse key events generated)
> - improved variable naming
> 
> Testing still green.

test/jdk/java/awt/Component/NativeInLightShow/NativeInLightShow.java line 27:

> 25:   @test 1.0 04/05/20
> 26:   @key headful
> 27:   @bug 4140484 8202932

BTW it is not necessary to update bugid for the simple cleanups, this is for the bugs which can be verified by this test, or for some big logic rework in the test. So for every next test update, it will be easy to check that the old bugs still can be verified by the updated test. In the current case it is clear that the test should fail before 4140484 was fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6056


From myano at openjdk.java.net  Thu Oct 21 07:46:08 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Thu, 21 Oct 2021 07:46:08 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
In-Reply-To: <0F3OiniYz_-jXYsqf2GLXlKx4iSmn61bsoyA3uwn_Xo=.07d1a0c6-7835-45fe-99b4-ef6bf0cf0d3f@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <0F3OiniYz_-jXYsqf2GLXlKx4iSmn61bsoyA3uwn_Xo=.07d1a0c6-7835-45fe-99b4-ef6bf0cf0d3f@github.com>
Message-ID: <-j5FQuza4HlLvo-lEo_JsX_HtJf7ddIaokQ1LqfQns8=.c0d443c2-3436-4d36-9a13-974a3300b169@github.com>

On Tue, 12 Oct 2021 06:27:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Could you please review the 7001973 fixes?
>> 
>> On Windows, CopyAreaOOB.java fails with a blank window. The cause of this problem is that paint() works one time only. Painting area is not guaranteed when showing a window.
>> 
>> I think this behavior should be removed for purpose of this test (`@summary: Verifies that copyArea() works properly`). Also, this program uses a Robot, but implements waiting logic by itself. This logic should be replaced to Robot API.
>> 
>> This fix works fine in Windows, so this test can be removed from ProblemList.txt. I don't have a Mac environment, so can someone please confirm that this fix will work on Mac?
>
> You will not be able to write the test which will check that only one paint event is posted, it is not guaranteed.
> You can only check that each rendering caused by the paint event will work fine. This test case check that the first event works fine, it can be improved to check all paint events.
> 
> So for the test update, you can add a big delay after the rendering, and wait for what will occur on the screen, any ideas why it may not work? You also can create a separate bug to investigate how we can validate the surface before showing the window so we did not post more events than necessary.

@mrserb Could you please reply to the above comments and fix of test?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5491


From serb at openjdk.java.net  Thu Oct 21 07:48:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 21 Oct 2021 07:48:08 GMT
Subject: RFR: 8225777: java/awt/Mixing/MixingOnDialog.java fails on Ubuntu
 [v2]
In-Reply-To: <TlNEql1a7-ZSYQlSi6_QiRSjpaelG-0izeSt9zkmnyc=.03e8f182-245e-4fcd-b843-d242077a085a@github.com>
References: <qg109bdSP2hEfYj2OX60PzZpasVQ7gYUf9YpXC1UbXg=.cf7eac5e-623a-426d-adff-8328a9a5c63f@github.com>
 <jixEoBSgEO0LziMrpf6IQoKfYxW4medffjLrqkNaeXI=.a08ac21d-17a3-4db5-b877-c388ebcba2c5@github.com>
 <xqt-c51aloFFg5rlcPxXU7zRrED3UOLVylfJxjioDnQ=.a3888c8c-9b9a-412f-8b24-7d1308ad68a5@github.com>
 <TlNEql1a7-ZSYQlSi6_QiRSjpaelG-0izeSt9zkmnyc=.03e8f182-245e-4fcd-b843-d242077a085a@github.com>
Message-ID: <IagmNxQWIGAopDo1s4g-jlUk5Rdk7IigpKGAHLQBPb0=.4e9e15f7-80c0-4490-8c9c-5fa2fb38b9dc@github.com>

On Thu, 21 Oct 2021 01:34:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yes, `setUndecorated` is one of possible solutions, however it looks equal to changing location.
>> 
>> Updated the delay and dialog's location.
>
> Can you please double-check all Mixing tests, some of the problem listed, but I think most of them has the same issue related to the big window decoration especially on windows 10 and the latest ubuntu?

I think those tests are even more broken in the HiDPI environment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6040


From kizune at openjdk.java.net  Thu Oct 21 09:06:30 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 21 Oct 2021 09:06:30 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null" [v4]
In-Reply-To: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
Message-ID: <NeSuIzx9qNIF2Uv18om5nWZcKXPFmVuYJ1Ew98MYb54=.234a073d-b56b-4869-9fdc-4da3bab285ad@github.com>

> 8168388: GetMousePositionTest fails with the message "Mouse position should not be null"

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Remove catch block

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6028/files
  - new: https://git.openjdk.java.net/jdk/pull/6028/files/382c31f8..577de2e5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6028&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6028&range=02-03

  Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6028.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6028/head:pull/6028

PR: https://git.openjdk.java.net/jdk/pull/6028


From kizune at openjdk.java.net  Thu Oct 21 09:06:31 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 21 Oct 2021 09:06:31 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null" [v3]
In-Reply-To: <zc9V8DMxJ9KBDROIQetf0IlQ1mCDAYvjNJBMwpnaVEk=.4896ea20-8e79-4b9a-8ec4-8098075493e7@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
 <fsRp2-2OzU2eYz7odk8Yv8Zh0de_ECny5z2YzKHb-YY=.4d8f1648-80d1-4936-82e4-e8928e4c1435@github.com>
 <EEe4u6m-fC4rCb_XxFeBUj6nEqq_I0vboV1ZV41Aeeg=.02347571-0fd0-4338-9e80-1ec3ecb05be5@github.com>
 <KSuLZ5hXF3Hb2PSIdY9VotITs6CBlJPb5SG6qPft5r8=.af491bb3-8fff-42c9-972d-8c3264b20960@github.com>
 <zc9V8DMxJ9KBDROIQetf0IlQ1mCDAYvjNJBMwpnaVEk=.4896ea20-8e79-4b9a-8ec4-8098075493e7@github.com>
Message-ID: <SW-wvaMgskpIZ3T2GWDg9NOkxufjr7o_iVOQfdym04Q=.d7d0e22d-c7fe-4c1c-9a01-ca742669b189@github.com>

On Thu, 21 Oct 2021 06:10:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The catch block was already there and i decided not to remove it and moved the rest of the code instead of the try block.
>
> I know it was already there but since you are touching the test, it might be better to better the code to remove unneeded block, as here we are just catching exception and rethrowing, when we already have main() signature having "throws Throwable"

Ok, i removed it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6028


From psadhukhan at openjdk.java.net  Thu Oct 21 09:26:16 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 21 Oct 2021 09:26:16 GMT
Subject: RFR: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null" [v4]
In-Reply-To: <NeSuIzx9qNIF2Uv18om5nWZcKXPFmVuYJ1Ew98MYb54=.234a073d-b56b-4869-9fdc-4da3bab285ad@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
 <NeSuIzx9qNIF2Uv18om5nWZcKXPFmVuYJ1Ew98MYb54=.234a073d-b56b-4869-9fdc-4da3bab285ad@github.com>
Message-ID: <nvMFGG0RmOVkP2_M8H9t-YVQ9tRit7BQezCT_V6WJo8=.6a0d3dbe-ae49-48c1-8af7-2de632c32df9@github.com>

On Thu, 21 Oct 2021 09:06:30 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 8168388: GetMousePositionTest fails with the message "Mouse position should not be null"
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove catch block

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6028


From kizune at openjdk.java.net  Thu Oct 21 09:55:08 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 21 Oct 2021 09:55:08 GMT
Subject: Integrated: 8168388: GetMousePositionTest fails with the message
 "Mouse position should not be null"
In-Reply-To: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
References: <5ywHaLchOzO5HN7I3hEMfAn4GnoP57J1Hr5RN-sz9Po=.af53315c-79b4-4608-a823-ad0bf3075650@github.com>
Message-ID: <4QSvN2oej1mCRP_ST2bbMl_l-UAXzwK1gxDCew00KuQ=.dc4d485d-687c-407d-97c9-40213d8b8d4e@github.com>

On Wed, 20 Oct 2021 07:04:18 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8168388: GetMousePositionTest fails with the message "Mouse position should not be null"

This pull request has now been integrated.

Changeset: 0c3eaea1
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0c3eaea11c83b3ee63d80de85d58a1cb6f870fd3
Stats:     30 lines in 2 files changed: 6 ins; 9 del; 15 mod

8168388: GetMousePositionTest fails with the message "Mouse position should not be null"

Reviewed-by: psadhukhan, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/6028


From azvegint at openjdk.java.net  Thu Oct 21 10:57:28 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 21 Oct 2021 10:57:28 GMT
Subject: RFR: 8202932:
 java/awt/Component/NativeInLightShow/NativeInLightShow.java fails [v2]
In-Reply-To: <vY4S5SLgt0RvQVidwLC5Kqp37ljbyIM_K735XfBlyl8=.5015954d-5207-4095-82bd-ab6608a77151@github.com>
References: <vY4S5SLgt0RvQVidwLC5Kqp37ljbyIM_K735XfBlyl8=.5015954d-5207-4095-82bd-ab6608a77151@github.com>
Message-ID: <95Ty6Hv3R3Ct4J2oOvMIjp7cfDSvV55Uo76W0adP30E=.c6b3a36a-6249-48bd-bcb8-9e155b557bff@github.com>

> Looks like the test does not fail anymore.
> 
> However some cleanup was made:
> 
> - fixed wildcard imports
> - frame centered and explicitly disposed at the end
> - removed unused `setAutoDelay()` call (no key/mouse key events generated)
> - improved variable naming
> 
> Testing still green.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  bug id removed

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6056/files
  - new: https://git.openjdk.java.net/jdk/pull/6056/files/6897480f..19fa417e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6056&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6056&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6056.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6056/head:pull/6056

PR: https://git.openjdk.java.net/jdk/pull/6056


From myano at openjdk.java.net  Thu Oct 21 12:27:30 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Thu, 21 Oct 2021 12:27:30 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at initial
 drawing
Message-ID: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>

Could you please review the 8275715 bug fixes?

I think D3DScreenUpdateManager posts unnecessary PaintEvent during processing PaintEvent. When the validate method is called from createGraphics, repaintPeerTarget should not be called.

-------------

Commit messages:
 - 8275715: D3D pipeline processes multiple PaintEvent at initial drawing

Changes: https://git.openjdk.java.net/jdk/pull/6064/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6064&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275715
  Stats: 86 lines in 2 files changed: 82 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6064.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6064/head:pull/6064

PR: https://git.openjdk.java.net/jdk/pull/6064


From serb at openjdk.java.net  Fri Oct 22 02:06:04 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Oct 2021 02:06:04 GMT
Subject: RFR: 8202932:
 java/awt/Component/NativeInLightShow/NativeInLightShow.java fails [v2]
In-Reply-To: <95Ty6Hv3R3Ct4J2oOvMIjp7cfDSvV55Uo76W0adP30E=.c6b3a36a-6249-48bd-bcb8-9e155b557bff@github.com>
References: <vY4S5SLgt0RvQVidwLC5Kqp37ljbyIM_K735XfBlyl8=.5015954d-5207-4095-82bd-ab6608a77151@github.com>
 <95Ty6Hv3R3Ct4J2oOvMIjp7cfDSvV55Uo76W0adP30E=.c6b3a36a-6249-48bd-bcb8-9e155b557bff@github.com>
Message-ID: <7Ug6UOYRmQKVjsKNNNnboGhOrJdc30jQdBJKriHFitw=.8ee7bb71-f4ef-4969-bb15-473bb0561f9f@github.com>

On Thu, 21 Oct 2021 10:57:28 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Looks like the test does not fail anymore.
>> 
>> However some cleanup was made:
>> 
>> - fixed wildcard imports
>> - frame centered and explicitly disposed at the end
>> - removed unused `setAutoDelay()` call (no key/mouse key events generated)
>> - improved variable naming
>> 
>> Testing still green.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bug id removed

Did you check the possibility to verify JDK-4140484, I think it should be possible but just in case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6056


From serb at openjdk.java.net  Fri Oct 22 03:08:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Oct 2021 03:08:07 GMT
Subject: Integrated: 8275344: -Xcheck:jni produces some warnings in the LCMS.c
In-Reply-To: <eTiQj-RC56VaT_bkLPKniDwjvNvWwR0zA28wtsuJR8w=.f3bdfb2a-b358-40da-bf65-ab2142ddf47d@github.com>
References: <eTiQj-RC56VaT_bkLPKniDwjvNvWwR0zA28wtsuJR8w=.f3bdfb2a-b358-40da-bf65-ab2142ddf47d@github.com>
Message-ID: <oGwi9zS8ZPN87wIPtzgzwpHOp6-Zgwjdk_kf6agCeMw=.2fe3a526-ded5-44f7-be17-329c45995e4a@github.com>

On Sun, 17 Oct 2021 00:09:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The newly added test MTTransformReplacedProfile(yeah that test again) produce some warning if check:jni is enabled:
> 
> WARNING in native method: JNI call made with exception pending
> at sun.java2d.cmm.lcms.LCMS.setTagDataNative(java.desktop at 17-internal/Native Method)
> at sun.java2d.cmm.lcms.LCMSProfile.setTag(java.desktop at 17-internal/LCMSProfile.java:82)
> at sun.java2d.cmm.lcms.LCMS.setTagData(java.desktop at 17-internal/LCMS.java:84) 
> 
> 
> The root cause is in the "errorHandler", which is called by the lcms library and where we throw a CMSException. So when we get an error code from some lcms API and try to throw the CMSException it is might be already thrown in the "errorHandler".
> 
> The fix contains two parts:
>  * If an exception already occurred we skip the creation of the CMSException. So the first error will be reported to the user.
>  * If an exception already occurred we DO NOT skip the creation of the IllegalArgumentException, because it is required by the specification to be thrown. But we use the initial exception as a "cause" for the new IllegalArgumentException. Note that it is also possible to just clear an occurred exception before the creation of the IllegalArgumentException. Any thoughts about it?
> 
> The second part changed the stack trace which will get the user, an example:
> 
> old:
> 
> java.lang.IllegalArgumentException: Can not write tag data.
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagDataNative(Native Method)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMSProfile.setTag(LCMSProfile.java:82)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagData(LCMS.java:84)
> 	at java.desktop/java.awt.color.ICC_Profile.setData(ICC_Profile.java:1132)
> 	at SetDataTest$TestCase.doTest(SetDataTest.java:77)
> 	at SetDataTest.main(SetDataTest.java:140)
> 
> new:
> 
> java.lang.IllegalArgumentException: Can not write tag data.
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagDataNative(Native Method)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMSProfile.setTag(LCMSProfile.java:82)
> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.setTagData(LCMS.java:92)
> 	at java.desktop/java.awt.color.ICC_Profile.setData(ICC_Profile.java:1114)
> 	at SetDataTest$TestCase.doTest(SetDataTest.java:77)
> 	at SetDataTest.main(SetDataTest.java:140)
> Caused by: java.awt.color.CMMException: LCMS error 8: Unknown tag type 'AAAA' found.
> 	... 6 more

This pull request has now been integrated.

Changeset: c978ca87
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c978ca87de2d9152345dfd85983278c42bb28cd3
Stats:     67 lines in 2 files changed: 47 ins; 1 del; 19 mod

8275344: -Xcheck:jni produces some warnings in the LCMS.c

Reviewed-by: azvegint, prr, kizune

-------------

PR: https://git.openjdk.java.net/jdk/pull/5975


From azvegint at openjdk.java.net  Fri Oct 22 12:05:24 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 22 Oct 2021 12:05:24 GMT
Subject: RFR: 8202932:
 java/awt/Component/NativeInLightShow/NativeInLightShow.java fails [v3]
In-Reply-To: <vY4S5SLgt0RvQVidwLC5Kqp37ljbyIM_K735XfBlyl8=.5015954d-5207-4095-82bd-ab6608a77151@github.com>
References: <vY4S5SLgt0RvQVidwLC5Kqp37ljbyIM_K735XfBlyl8=.5015954d-5207-4095-82bd-ab6608a77151@github.com>
Message-ID: <lysXyb-6c3QeqdRvPT4aD1JLjTSG0m5OhPHt5LHRqH0=.e69afd4f-41c4-4fd3-8885-15e2f0c5f41b@github.com>

> Looks like the test does not fail anymore.
> 
> However some cleanup was made:
> 
> - fixed wildcard imports
> - frame centered and explicitly disposed at the end
> - removed unused `setAutoDelay()` call (no key/mouse key events generated)
> - improved variable naming
> 
> Testing still green.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  extra safety

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6056/files
  - new: https://git.openjdk.java.net/jdk/pull/6056/files/19fa417e..56ad9f98

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6056&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6056&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6056.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6056/head:pull/6056

PR: https://git.openjdk.java.net/jdk/pull/6056


From azvegint at openjdk.java.net  Fri Oct 22 12:17:06 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 22 Oct 2021 12:17:06 GMT
Subject: RFR: 8202932:
 java/awt/Component/NativeInLightShow/NativeInLightShow.java fails [v2]
In-Reply-To: <7Ug6UOYRmQKVjsKNNNnboGhOrJdc30jQdBJKriHFitw=.8ee7bb71-f4ef-4969-bb15-473bb0561f9f@github.com>
References: <vY4S5SLgt0RvQVidwLC5Kqp37ljbyIM_K735XfBlyl8=.5015954d-5207-4095-82bd-ab6608a77151@github.com>
 <95Ty6Hv3R3Ct4J2oOvMIjp7cfDSvV55Uo76W0adP30E=.c6b3a36a-6249-48bd-bcb8-9e155b557bff@github.com>
 <7Ug6UOYRmQKVjsKNNNnboGhOrJdc30jQdBJKriHFitw=.8ee7bb71-f4ef-4969-bb15-473bb0561f9f@github.com>
Message-ID: <n4bN1ctWwpwO4apSBwHqakHb7hli9ep2q_I_wIDbGtc=.6d02e0d2-563a-4a6f-871b-d4dd8ba17fcb@github.com>

On Fri, 22 Oct 2021 02:03:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Did you check the possibility to verify JDK-4140484, I think it should be possible but just in case.

Original test cases from JDK-4140484 description are still have no issues.

Hundreds of runs of this test on mach5 has not a single failure(nor before nor after modification)

However I've added delay after setVisible() call for extra safety.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6056


From ant at openjdk.java.net  Fri Oct 22 16:12:26 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Fri, 22 Oct 2021 16:12:26 GMT
Subject: RFR: 8275720: CommonComponentAccessibility.createWithParent isWrapped
 causes mem leak
Message-ID: <TlyyL4OvaG8rPWGgx3GTG5-zBF8URNxTargyF3CVsQA=.3bb05eb6-4a10-4828-8f4a-e11d41090a82@github.com>

This is a reimplementation of the `isWrapped` logic in the method:

`+[CommonComponentAccessibility createWithParent:accessible:role:index:withEnv:withView:isWrapped:]`

The `isWrapped` arg was used to create an a11y element which is wrapped into an object that does not have direct peer in Java (like `ListRowAccessibility`, `TableRowAccessibility`). The problem is that such objects leak, because when the wrapped element is created (`isWrapped == YES`), the native pointer to the element is rewritten in the associated java peer (the `accessible` arg) and the element object is then released via the `CFRetainedResource` mechanism. However the wrapping object (`ListRowAccessibility`, `TableRowAccessibility`) is never released.

This fix proposes a dedicated class for creating such paired objects, where a wrapper object releases its wrapped child when the deallocation is triggered by garbage collecting the associated java peer.

-------------

Commit messages:
 - 8275720: CommonComponentAccessibility.createWithParent isWrapped causes mem leak

Changes: https://git.openjdk.java.net/jdk/pull/6081/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6081&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275720
  Stats: 252 lines in 11 files changed: 110 ins; 112 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6081.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6081/head:pull/6081

PR: https://git.openjdk.java.net/jdk/pull/6081


From ant at openjdk.java.net  Fri Oct 22 16:51:11 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Fri, 22 Oct 2021 16:51:11 GMT
Subject: RFR: 8275720: CommonComponentAccessibility.createWithParent
 isWrapped causes mem leak
In-Reply-To: <TlyyL4OvaG8rPWGgx3GTG5-zBF8URNxTargyF3CVsQA=.3bb05eb6-4a10-4828-8f4a-e11d41090a82@github.com>
References: <TlyyL4OvaG8rPWGgx3GTG5-zBF8URNxTargyF3CVsQA=.3bb05eb6-4a10-4828-8f4a-e11d41090a82@github.com>
Message-ID: <ojKbcF54XoXEwQwirTn7uITdpOWjcq5PGgxILuzF4oM=.9d9160d4-2a1c-4853-ac8d-fa5f111ca73b@github.com>

On Fri, 22 Oct 2021 16:02:32 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> This is a reimplementation of the `isWrapped` logic in the method:
> 
> `+[CommonComponentAccessibility createWithParent:accessible:role:index:withEnv:withView:isWrapped:]`
> 
> The `isWrapped` arg was used to create an a11y element which is wrapped into an object that does not have direct peer in Java (like `ListRowAccessibility`, `TableRowAccessibility`). The problem is that such objects leak, because when the wrapped element is created (`isWrapped == YES`), the native pointer to the element is rewritten in the associated java peer (the `accessible` arg) and the element object is then released via the `CFRetainedResource` mechanism. However the wrapping object (`ListRowAccessibility`, `TableRowAccessibility`) is never released.
> 
> This fix proposes a dedicated class for creating such paired objects, where a wrapper object releases its wrapped child when the deallocation is triggered by garbage collecting the associated java peer.

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CellAccessibility.m line 38:

> 36: }
> 37: 
> 38: - (NSArray *)accessibilityChildren

The `accessibilityChildren` method is now inherited from `ComponentWrapperAccessibility`.

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ColumnAccessibility.m line 52:

> 50: }
> 51: 
> 52: - (NSArray *)accessibilityChildren

By removing this method I'm duplicating the change proposed in ttps://github.com/openjdk/jdk/pull/6020. So this fix should be merged after the referred commit is integrated.

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListRowAccessibility.m line 41:

> 39: }
> 40: 
> 41: - (NSArray *)accessibilityChildren

The method is now inherited.

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableRowAccessibility.m line 99:

> 97:                                                       withView:self->fView];
> 98: 
> 99:             [childrenCells addObject:child];

Here we create a wrapping object and we rely on the default release logic, so we do not need to additionally retain/release it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6081


From rolf at vankleef.me  Fri Oct 22 12:42:00 2021
From: rolf at vankleef.me (Rolf van Kleef)
Date: Fri, 22 Oct 2021 12:42:00 +0000
Subject: Allow overriding lp and lpr binary paths in PSPrintJob
Message-ID: <667978336fa7b5f2deb7f892e8d289c7@vankleef.me>

I am not sure about whether this is the correct list for this, or whether this is an appropriate
message for this list, but I have been told to send an email here regarding a PR I submitted on
GitHub.

I recently ran into trouble with printing on Linux, where the lpr binary was on a non-standard path
(not in /usr/bin/lpr). After looking in the code, I found out that this path cannot be overridden.
It seems that such paths should be able to be overriden, and so, I propose to add a system property
named "sun.print.lprPath" and "sun.print.lpPath" to override these paths. See the PR below.

https://github.com/openjdk/jdk/pull/6052

Regards,
Rolf van Kleef


From darkzalgo at gmail.com  Fri Oct 22 16:37:45 2021
From: darkzalgo at gmail.com (John Cummings)
Date: Fri, 22 Oct 2021 09:37:45 -0700
Subject: ARMv7A Sound Not Working On OpenJDK-11
Message-ID: <CAA3xS4nNG7RLRs0gs7D8VQx2pZrXwpJbs0A545ONqOJrmDX6eg@mail.gmail.com>

Hello all,
I have been attempting to build OpenJDK-11 for an ARMv7-A system using
Cortex-A7 that currently runs Java 8. After resolving my build issues with
the build-dev mailing list (who sent me here for this issue), I'm able to
make it run on the system, but it cannot play sound and I have been unable
to figure out why. Running the same java applications one after another, 8
will play sound, 11 will crash upon trying to get the source line.

Please let me know if there's any additional information I can provide that
may help!

I have attempted building with two different toolchains, I've used the
branch at https://hg.openjdk.java.net/jdk/jdk11 as well as the one at
https://github.com/openjdk/jdk11u-dev/. I've tried the server, client, and
zero variants of both, with and without fastdebug enabled, and haven't made
much progress with it. I've also tried with java 8 still on the system, and
with deleting it entirely. I've also attempted to add the following to the
sound.properties:

javax.sound.sampled.Clip=com.sun.media.sound.DirectAudioDeviceProvider
javax.sound.sampled.Port=com.sun.media.sound.PortMixerProvider
javax.sound.sampled.SourceDataLine=com.sun.media.sound.DirectAudioDeviceProvider
javax.sound.sampled.TargetDataLine=com.sun.media.sound.DirectAudioDeviceProvider

This is the configuration I've been using:
bash configure \
--openjdk-target=arm-unknown-linux-gnueabihf \
--with-native-debug-symbols=none \
--disable-warnings-as-errors \
--with-abi-profile=arm-vfp-hflt \
--disable-ccache \
--with-build-jdk=/opt/openjdk/jdk11u-dev/build/linux-x86_64-normal-server-release/images/jdk
\
--with-sysroot=/opt/buildroot-2017.08/output/host/arm-buildroot-linux-gnueabihf/sysroot/
\
--with-toolchain-path=/opt/x-tools/arm-unknown-linux-gnueabihf/bin \
--with-x=/opt/buildroot-2017.08/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr
 \
--with-cups=/opt/sbuildroot-2017.08/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr
\
--with-fontconfig=/opt/buildroot-2017.08/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr
\
--with-freetype-lib=/opt/buildroot-2017.08/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib
\
--with-freetype-include=/opt/buildroot-2017.08/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include
\
--with-alsa=/opt/buildroot-2017.08/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr
\
--with-stdc++lib=dynamic \
--with-extra-cxxflags='-O2 -pipe' \
--with-extra-cflags='-O2 -pipe' \
--with-jobs=8 \
--with-jvm-variants=client


Output of uname -a for this system is
Linux sun6i 3.3.0 #125 SMP PREEMPT Fri Feb 5 07:04:03 CST 2021 armv7l
GNU/Linux

Output of java -version for 8 is
# java8 -version
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) Client VM (build 25.144-b01, mixed mode)
Output for the newly built 11 is:
# java -version
openjdk version "11.0.14-internal" 2022-01-18
OpenJDK Runtime Environment (build
11.0.14-internal+0-adhoc.johnc.jdk11u-dev)
OpenJDK Client VM (build 11.0.14-internal+0-adhoc.johnc.jdk11u-dev, mixed
mode)

  The app I've been collecting information with just gets the mixers, and
any data lines and prints their values, and then plays a .wav file using
SourceDataLine, and again with Clip. I use -Daudio.mixer="M1 PCM [default]"
because in the Java 11 build, setting it to null for the default just
returns null, and it doesn't even return the "Found Audio Mixer" line. If
it helps, here is the java itself: https://pastebin.com/CCfUWTTf

The output is as follows for 8 and 11:



Java 8 output



# java8 -Daudio.mixer="M1 PCM [default]" AudioFormats SuccessBuzzer.wav
Found audio mixer: M1 PCM [default]
Supported Lines of default mixer (M1 PCM [default]):


Mixer ClassName:
com.sun.media.sound.DirectAudioDeviceProvider$DirectAudioDeviceInfo
Mixer Desc: Direct Audio Device: sun7i PCM, M1 PCM, sun7i PCM
Vendor: ALSA (http://www.alsa-project.org)

M1 PCM [default]        ---     interface SourceDataLine supporting 8 audio
formats, and buffers of at least 32 bytes -----
com.sun.media.sound.DirectAudioDevice$DirectSDL at 873330
M1 PCM [default]        ---     interface Clip supporting 8 audio formats,
and buffers of at least 32 bytes -----
com.sun.media.sound.DirectAudioDevice$DirectClip at 19d7047
com.sun.media.sound.DirectAudioDevice at 16ec8df   ---     interface
TargetDataLine supporting 8 audio formats, and buffers of at least 32 bytes
-----   com.sun.media.sound.DirectAudioDevice$DirectTDL at ec7777
Mixer Num Source Info Lines: 2
Mixer Num Target Info Lines: 1
interface SourceDataLine supporting 8 audio formats, and buffers of at
least 32 bytes
  max buffer size:      -1
  min buffer size:      32
  Supported Audio formats:
    PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame,
little-endian
      encoding:           PCM_SIGNED
      channels:           1
      frame size [bytes]: 2
      sample size [bit]:  16
      big endian:         false
      line supported:         true
    PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, big-endian
      encoding:           PCM_SIGNED
      channels:           1
      frame size [bytes]: 2
      sample size [bit]:  16
      big endian:         true
      line supported:         true
    PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame,
little-endian
      encoding:           PCM_SIGNED
      channels:           2
      frame size [bytes]: 4
      sample size [bit]:  16
      big endian:         false
      line supported:         true
    PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame,
big-endian
      encoding:           PCM_SIGNED
      channels:           2
      frame size [bytes]: 4
      sample size [bit]:  16
      big endian:         true
      line supported:         true
    PCM_SIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame,
      encoding:           PCM_SIGNED
      channels:           1
      frame size [bytes]: 1
      sample size [bit]:  8
      big endian:         false
      line supported:         true
    PCM_UNSIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame,
      encoding:           PCM_UNSIGNED
      channels:           1
      frame size [bytes]: 1
      sample size [bit]:  8
      big endian:         false
      line supported:         true
    PCM_SIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame,
      encoding:           PCM_SIGNED
      channels:           2
      frame size [bytes]: 2
      sample size [bit]:  8
      big endian:         false
      line supported:         true
    PCM_UNSIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame,
      encoding:           PCM_UNSIGNED
      channels:           2
      frame size [bytes]: 2
      sample size [bit]:  8
      big endian:         false
      line supported:         true


interface Clip supporting 8 audio formats, and buffers of at least 32 bytes

Playing SuccessBuzzer.wav
Source Data Lines:     PCM_SIGNED 22050.0 Hz, 16 bit, stereo, 4
bytes/frame, little-endian
      encoding:           PCM_SIGNED
      channels:           2
      frame rate [1/s]:   22050.0
      frame size [bytes]: 4
      sample rate [1/s]:  22050.0
      sample size [bit]:  16
      big endian:         false
      line supported:         true



Clip Data Lines:     PCM_SIGNED 22050.0 Hz, 16 bit, stereo, 4 bytes/frame,
little-endian
      encoding:           PCM_SIGNED
      channels:           2
      frame rate [1/s]:   22050.0
      frame size [bytes]: 4
      sample rate [1/s]:  22050.0
      sample size [bit]:  16
      big endian:         false
      line supported:         true



Target Data Lines:     PCM_SIGNED 22050.0 Hz, 16 bit, stereo, 4
bytes/frame, little-endian
      encoding:           PCM_SIGNED
      channels:           2
      frame rate [1/s]:   22050.0
      frame size [bytes]: 4
      sample rate [1/s]:  22050.0
      sample size [bit]:  16
      big endian:         false
      line supported:         true








Java 11 Output





# java -Daudio.mixer="M1 PCM [default]" AudioFormats SuccessBuzzer.wav
Found audio mixer: M1 PCM [default]
Supported Lines of default mixer (M1 PCM [default]):


Mixer ClassName:
com.sun.media.sound.DirectAudioDeviceProvider$DirectAudioDeviceInfo
Mixer Desc: Direct Audio Device: sun7i PCM, M1 PCM, sun7i PCM
Vendor: ALSA (http://www.alsa-project.org)

Mixer Has 0 Source Info Lines:
Mixer Has 0 Target Info Lines:





Playing SuccessBuzzer.wav
Source Data Lines:     PCM_SIGNED 22050.0 Hz, 16 bit, stereo, 4
bytes/frame, little-endian
      encoding:           PCM_SIGNED
      channels:           2
      frame rate [1/s]:   22050.0
      frame size [bytes]: 4
      sample rate [1/s]:  22050.0
      sample size [bit]:  16
      big endian:         false
      line supported:         false



Clip Data Lines:     PCM_SIGNED 22050.0 Hz, 16 bit, stereo, 4 bytes/frame,
little-endian
      encoding:           PCM_SIGNED
      channels:           2
      frame rate [1/s]:   22050.0
      frame size [bytes]: 4
      sample rate [1/s]:  22050.0
      sample size [bit]:  16
      big endian:         false
      line supported:         false



Target Data Lines:     PCM_SIGNED 22050.0 Hz, 16 bit, stereo, 4
bytes/frame, little-endian
      encoding:           PCM_SIGNED
      channels:           2
      frame rate [1/s]:   22050.0
      frame size [bytes]: 4
      sample rate [1/s]:  22050.0
      sample size [bit]:  16
      big endian:         false
      line supported:         false
java.lang.IllegalArgumentException: No line matching interface
SourceDataLine supporting format PCM_SIGNED 22050.0 Hz, 16 bit, stereo, 4
bytes/frame, little-endian is supported.
        at
java.desktop/javax.sound.sampled.AudioSystem.getLine(AudioSystem.java:425)
        at AudioFormats.main(AudioFormats.java:77)
java.lang.IllegalArgumentException: No line matching interface Clip
supporting format PCM_SIGNED unknown sample rate, 16 bit, stereo, 4
bytes/frame, big-endian is supported.
        at
java.desktop/javax.sound.sampled.AudioSystem.getLine(AudioSystem.java:425)
        at
java.desktop/javax.sound.sampled.AudioSystem.getClip(AudioSystem.java:461)
        at AudioFormats.main(AudioFormats.java:94)

On another application I've also had an error pointing to the
DirectAudioDevice.java that also plays the same .wav file.

Caused by: java.lang.IllegalArgumentException: Line unsupported: interface
SourceDataLine
        at
java.desktop/com.sun.media.sound.DirectAudioDevice.getLine(DirectAudioDevice.java:175)
        at
java.desktop/javax.sound.sampled.AudioSystem.getSourceDataLine(AudioSystem.java:572)

Here's aplay output for that file too in case that helps:

#aplay -vvv SuccessBuzzer.wav
Playing WAVE 'SuccessBuzzer.wav' : Signed 16 bit Little Endian, Rate 22050
Hz, Stereo
Hardware PCM card 0 'audiocodec' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 22050
  exact rate   : 22050 (22050/1)
  msbits       : 16
  buffer_size  : 8192
  period_size  : 2048
  period_time  : 92879
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 2048
  period_event : 0
  start_threshold  : 8192
  stop_threshold   : 8192
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
  appl_ptr     : 0
  hw_ptr       : 0
Max peak (4096 samples): 0x0000095f ##                   7%
Max peak (4096 samples): 0x00001a62 #####                20%
Max peak (4096 samples): 0x00001b1c #####                21%
Max peak (4096 samples): 0x0000182c ####                 18%
Max peak (4096 samples): 0x000005de #                    4%
Max peak (4096 samples): 0x00000451 #                    3%
Max peak (4096 samples): 0x000001d5 #                    1%


Thanks,
John Cummings


From ant at openjdk.java.net  Fri Oct 22 16:55:19 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Fri, 22 Oct 2021 16:55:19 GMT
Subject: RFR: 8275809: crash in [CommonComponentAccessibility
 getCAccessible:withEnv:]
Message-ID: <X3K_hgrMAbmWMUdptB22Nsxi0T4r9U5A-4NKtAMsTSM=.b4a95a97-7a6b-4132-94f0-3e876a10cd3a@github.com>

Adding a JNI weak ref check. There's a couple of other similar places in the code where a JNI weak ref is checked for null, in the rest of the code we pass such refs to java where they are checked for null. So, I was not able to eye catch any other similar place in the a11y code where such check is also required.

-------------

Commit messages:
 - 8275809: crash in [CommonComponentAccessibility getCAccessible:withEnv:]

Changes: https://git.openjdk.java.net/jdk/pull/6083/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6083&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275809
  Stats: 22 lines in 1 file changed: 7 ins; 5 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6083.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6083/head:pull/6083

PR: https://git.openjdk.java.net/jdk/pull/6083


From philip.race at oracle.com  Fri Oct 22 17:05:08 2021
From: philip.race at oracle.com (Philip Race)
Date: Fri, 22 Oct 2021 10:05:08 -0700
Subject: Allow overriding lp and lpr binary paths in PSPrintJob
In-Reply-To: <667978336fa7b5f2deb7f892e8d289c7@vankleef.me>
References: <667978336fa7b5f2deb7f892e8d289c7@vankleef.me>
Message-ID: <5b3bd9a9-38da-aa8a-b061-c4b89bdd1331@oracle.com>

Well ..

1) Please read the comment the bots added to your PR.
There are steps you need to take before we can even look at your 
contribution.

2) PRs need a JBS bug ID else the bots will? still reject it.
You'll need to submit an RFE at bugreport.java.com and go from there.

3) I understand your problem up to a point but we'd need to think about 
the proposed solution
and why your Linux doesn't put lpr in the standard place. There could be 
legitimate
security concerns about allowing such an over-ride.
Perhaps you need a port of OpenJDK to that distro which you don't name ?

-phil

On 10/22/21 5:42 AM, Rolf van Kleef wrote:
> I am not sure about whether this is the correct list for this, or whether this is an appropriate
> message for this list, but I have been told to send an email here regarding a PR I submitted on
> GitHub.
>
> I recently ran into trouble with printing on Linux, where the lpr binary was on a non-standard path
> (not in /usr/bin/lpr). After looking in the code, I found out that this path cannot be overridden.
> It seems that such paths should be able to be overriden, and so, I propose to add a system property
> named "sun.print.lprPath" and "sun.print.lpPath" to override these paths. See the PR below.
>
> https://github.com/openjdk/jdk/pull/6052
>
> Regards,
> Rolf van Kleef



From prr at openjdk.java.net  Fri Oct 22 17:25:13 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 22 Oct 2021 17:25:13 GMT
Subject: Integrated: 8198336: java/awt/FontMetrics/FontCrash.java fails in
 headless mode
In-Reply-To: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>
References: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>
Message-ID: <5zBi2eC103VihM-KJm7B1TJFLUDJuIEsW50-AD9H3U8=.8aec4f7c-e861-4fc3-af81-9aea2a9fa357@github.com>

On Wed, 20 Oct 2021 04:12:46 GMT, Phil Race <prr at openjdk.org> wrote:

> The code this test exercises is very obsolete. So this removes the test that triggers it along with that code.

This pull request has now been integrated.

Changeset: 6523c558
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6523c558d92dedf350576126960dee6cff8f6067
Stats:     98 lines in 5 files changed: 0 ins; 98 del; 0 mod

8198336: java/awt/FontMetrics/FontCrash.java fails in headless mode

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/6027


From kizune at openjdk.java.net  Fri Oct 22 17:36:08 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 22 Oct 2021 17:36:08 GMT
Subject: RFR: 8262945: [macos] Regression Manual Test for Key Events Fails
 [v3]
In-Reply-To: <k-0hmzZ-NTF8KavFyuo1m4RxJZjfB4b2INfWOwXX6JQ=.f34b98cd-5708-4a0e-96e0-0f6276fdc8eb@github.com>
References: <LhSIteG6WssDHH2if3oeA-0qLZGhxfqb11JyTC4EPh8=.b8b62eb4-a50c-4eb2-98c7-6f122f87d08b@github.com>
 <k-0hmzZ-NTF8KavFyuo1m4RxJZjfB4b2INfWOwXX6JQ=.f34b98cd-5708-4a0e-96e0-0f6276fdc8eb@github.com>
Message-ID: <PHEHjQPy3t37_p3sddLE-QfjnUMr8ADlUfX20BbS9vE=.b017b919-0572-459b-a047-32eb50269ca2@github.com>

On Mon, 27 Sep 2021 16:19:21 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

>> Added a check for active keyboard language and added support for Russian NSEvent keyCodes to JavaVirtualKeyCode translation. Originally, only English characters were checked for even if other languages were in native letterCharacterSet. Can be easily expanded to include other languages as well.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding comment explaining offset numbers

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5617


From vdyakov at openjdk.java.net  Fri Oct 22 18:03:05 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Fri, 22 Oct 2021 18:03:05 GMT
Subject: RFR: 8275809: crash in [CommonComponentAccessibility
 getCAccessible:withEnv:]
In-Reply-To: <X3K_hgrMAbmWMUdptB22Nsxi0T4r9U5A-4NKtAMsTSM=.b4a95a97-7a6b-4132-94f0-3e876a10cd3a@github.com>
References: <X3K_hgrMAbmWMUdptB22Nsxi0T4r9U5A-4NKtAMsTSM=.b4a95a97-7a6b-4132-94f0-3e876a10cd3a@github.com>
Message-ID: <H10zCer2btNGRGAxVeXHxFYWbZVKQl9F6XImpLDIbdY=.c01e30b4-5c27-425e-9f28-3dca587ce3fe@github.com>

On Fri, 22 Oct 2021 16:47:24 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> Adding a JNI weak ref check. There's a couple of other similar places in the code where a JNI weak ref is checked for null, in the rest of the code we pass such refs to java where they are checked for null. So, I was not able to eye catch any other similar place in the a11y code where such check is also required.

@azuev-java @pankaj-bansal  please review

-------------

PR: https://git.openjdk.java.net/jdk/pull/6083


From vdyakov at openjdk.java.net  Fri Oct 22 18:05:11 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Fri, 22 Oct 2021 18:05:11 GMT
Subject: RFR: 8275720: CommonComponentAccessibility.createWithParent
 isWrapped causes mem leak
In-Reply-To: <TlyyL4OvaG8rPWGgx3GTG5-zBF8URNxTargyF3CVsQA=.3bb05eb6-4a10-4828-8f4a-e11d41090a82@github.com>
References: <TlyyL4OvaG8rPWGgx3GTG5-zBF8URNxTargyF3CVsQA=.3bb05eb6-4a10-4828-8f4a-e11d41090a82@github.com>
Message-ID: <cC_DxH6P1jL6ztoHxW7df-VphwSJA4FTLuFo_wL1nso=.75dc3ef1-6a55-4da6-ae90-bcf506136324@github.com>

On Fri, 22 Oct 2021 16:02:32 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> This is a reimplementation of the `isWrapped` logic in the method:
> 
> `+[CommonComponentAccessibility createWithParent:accessible:role:index:withEnv:withView:isWrapped:]`
> 
> The `isWrapped` arg was used to create an a11y element which is wrapped into an object that does not have direct peer in Java (like `ListRowAccessibility`, `TableRowAccessibility`). The problem is that such objects leak, because when the wrapped element is created (`isWrapped == YES`), the native pointer to the element is rewritten in the associated java peer (the `accessible` arg) and the element object is then released via the `CFRetainedResource` mechanism. However the wrapping object (`ListRowAccessibility`, `TableRowAccessibility`) is never released.
> 
> This fix proposes a dedicated class for creating such paired objects, where a wrapper object releases its wrapped child when the deallocation is triggered by garbage collecting the associated java peer.

@azuev-java @pankaj-bansal please review

-------------

PR: https://git.openjdk.java.net/jdk/pull/6081


From kizune at openjdk.java.net  Fri Oct 22 18:30:11 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 22 Oct 2021 18:30:11 GMT
Subject: RFR: 8275720: CommonComponentAccessibility.createWithParent
 isWrapped causes mem leak
In-Reply-To: <cC_DxH6P1jL6ztoHxW7df-VphwSJA4FTLuFo_wL1nso=.75dc3ef1-6a55-4da6-ae90-bcf506136324@github.com>
References: <TlyyL4OvaG8rPWGgx3GTG5-zBF8URNxTargyF3CVsQA=.3bb05eb6-4a10-4828-8f4a-e11d41090a82@github.com>
 <cC_DxH6P1jL6ztoHxW7df-VphwSJA4FTLuFo_wL1nso=.75dc3ef1-6a55-4da6-ae90-bcf506136324@github.com>
Message-ID: <ni7-9D8JB7eE_F2WMFna-orWVE97luLNlBwsyqHdLtM=.8803bc0d-5491-4159-8add-e8e81c0955fc@github.com>

On Fri, 22 Oct 2021 18:02:28 GMT, Victor Dyakov <vdyakov at openjdk.org> wrote:

> @azuev-java @pankaj-bansal please review

Note that this change can be applied only after the https://github.com/openjdk/jdk/pull/6020 so i'm testing that change at the moment and will report on it first.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6081


From ant at openjdk.java.net  Fri Oct 22 18:42:20 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Fri, 22 Oct 2021 18:42:20 GMT
Subject: RFR: 8275819: [TableRowAccessibility accessibilityChildren] method is
 ineffective
Message-ID: <HyEBVOJtMpIhHE-bQzWs_06Gg3DU8w9JHIW39yAT-68=.171ba533-0b45-41d0-b024-e25bdc8b36d0@github.com>

Retrieve only cells for a particular table row when requested, not the whole table.

-------------

Commit messages:
 - 8275819: [TableRowAccessibility accessibilityChildren] method is ineffective

Changes: https://git.openjdk.java.net/jdk/pull/6085/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6085&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275819
  Stats: 101 lines in 2 files changed: 71 ins; 13 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6085.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6085/head:pull/6085

PR: https://git.openjdk.java.net/jdk/pull/6085


From ant at openjdk.java.net  Fri Oct 22 18:49:02 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Fri, 22 Oct 2021 18:49:02 GMT
Subject: RFR: 8273678 TableAccessibility and TableRowAccessibility miss
 autorelease
In-Reply-To: <A54SFKDa5sz5XioUaL4wDIqIxp9QVSk3Q8YM_CB-UtY=.8ea6b5aa-ea49-4d00-b611-c74923c761e9@github.com>
References: <A54SFKDa5sz5XioUaL4wDIqIxp9QVSk3Q8YM_CB-UtY=.8ea6b5aa-ea49-4d00-b611-c74923c761e9@github.com>
Message-ID: <ur3U4HKaf8cfUUCb7UpJAJy_8vr6y526pk_mrwkjoMw=.0980c371-e138-488c-84ce-d26c36a87ed7@github.com>

On Tue, 19 Oct 2021 17:11:18 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The TableAccessibility obj-c class should call [autorelease] on an object it allocates (see: [TableRowAccessibility alloc] and [ColumnAccessibility alloc]). 
> 
> The TableRowAccessibility obj-c class should not call [retain] on an allocated object (see: [CellAccessibility alloc]). 
> 
> "You own any object you create", see: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html
> 
> The logic of creating a CellAccessibility object will be reimplemented in the context of [JDK-8275720](https://bugs.openjdk.java.net/browse/JDK-8275720 "bugs.openjdk.java.net").

Marked as reviewed by ant (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6020


From kizune at openjdk.java.net  Fri Oct 22 18:59:03 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 22 Oct 2021 18:59:03 GMT
Subject: RFR: 8273678 TableAccessibility and TableRowAccessibility miss
 autorelease
In-Reply-To: <A54SFKDa5sz5XioUaL4wDIqIxp9QVSk3Q8YM_CB-UtY=.8ea6b5aa-ea49-4d00-b611-c74923c761e9@github.com>
References: <A54SFKDa5sz5XioUaL4wDIqIxp9QVSk3Q8YM_CB-UtY=.8ea6b5aa-ea49-4d00-b611-c74923c761e9@github.com>
Message-ID: <gAYUH5Y9R5a99_NDVOMOSbAaKJHHcoPkgmCxSlgpQus=.fe476a91-d738-46c4-9f67-fc5ff0ea4d23@github.com>

On Tue, 19 Oct 2021 17:11:18 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The TableAccessibility obj-c class should call [autorelease] on an object it allocates (see: [TableRowAccessibility alloc] and [ColumnAccessibility alloc]). 
> 
> The TableRowAccessibility obj-c class should not call [retain] on an allocated object (see: [CellAccessibility alloc]). 
> 
> "You own any object you create", see: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html
> 
> The logic of creating a CellAccessibility object will be reimplemented in the context of [JDK-8275720](https://bugs.openjdk.java.net/browse/JDK-8275720 "bugs.openjdk.java.net").

Looks good.

-------------

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6020


From prr at openjdk.java.net  Fri Oct 22 19:09:21 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 22 Oct 2021 19:09:21 GMT
Subject: RFR: 8275170: Some jtreg sound tests should be marked headful
Message-ID: <X41BDIEKsSkDT89l1hdzX-UaUgdSjsDy93urJmQVRl8=.32fc5ade-4d6a-4d0a-ac00-2fab11ded55d@github.com>

This fix adds "headful sound" keywords to a number of javax/sound jtreg tests

The jtreg javax.sound tests are written in such a way that if a needed audio device
or other platform resource is not available, they just exit with a "pass" for the test.
It is as if headful tests just swallowed HeadlessException and issued a pass.
If we allowed that we'd be effectively testing almost nothing of real importance.

Currently almost  all sound tests have no keyword like "headful" to indicate they
may need access to a hardware resource to do anything useful so a similar
situation arises there except when someone runs those tests manually on
a local system which has audio devices.

Of course "headful" and "audio device" aren't exactly interchangeable terms
but if tests are allowed to be run - or worse usually or always run - in a situation
where they potentially are on a system without an audio device (a headless VM) or are running in
a session which doesn't have full desktop access - which may in some
cases be how audio device access is granted, then they are more likely
to be running in this scenario where the testing isn't valid.

Another point is that headful tests must be run one at a time - no concurrency because
you can't have multiple tests moving the mouse at the same time
Whereas for headless tests, a test harness may choose to run concurrently - perhaps even in the same VM
When tests that really need access to an audio device are run it is probably safer to consider
the headful attribute as implying one test at a time is best .. granted on a desktop it isn't
usual for a single app to be able to monopolize access to a speaker, but for input devices
that is what you'd generally expect.

By no means am I sure that the tests being updated here are the full set that need tagging.
There are a lot of tests and they are all known to pass on systems with NO audio
devices, so the search has been for tests which call APIs which will definitely
need access to some device in order to do anything useful.
So likely there are more to be added - either by a reviewer pointing them out or by later discovery.
Alternatively we could mark ALL sound tests headful .. but given where we are starting from
that might be erring unnecessarily far in the opposite direction.

By adding both headful and sound keywords it gives options to someone who
wants to identify the tests and perhaps run just tests which need "sound" on some
config they know supports audio but isn't headful.

-------------

Commit messages:
 - 8275170: Some jtreg sound tests should be marked headful

Changes: https://git.openjdk.java.net/jdk/pull/6086/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6086&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275170
  Stats: 63 lines in 58 files changed: 59 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6086.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6086/head:pull/6086

PR: https://git.openjdk.java.net/jdk/pull/6086


From serb at openjdk.java.net  Fri Oct 22 19:15:17 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Oct 2021 19:15:17 GMT
Subject: RFR: 8202932:
 java/awt/Component/NativeInLightShow/NativeInLightShow.java fails [v2]
In-Reply-To: <n4bN1ctWwpwO4apSBwHqakHb7hli9ep2q_I_wIDbGtc=.6d02e0d2-563a-4a6f-871b-d4dd8ba17fcb@github.com>
References: <vY4S5SLgt0RvQVidwLC5Kqp37ljbyIM_K735XfBlyl8=.5015954d-5207-4095-82bd-ab6608a77151@github.com>
 <95Ty6Hv3R3Ct4J2oOvMIjp7cfDSvV55Uo76W0adP30E=.c6b3a36a-6249-48bd-bcb8-9e155b557bff@github.com>
 <7Ug6UOYRmQKVjsKNNNnboGhOrJdc30jQdBJKriHFitw=.8ee7bb71-f4ef-4969-bb15-473bb0561f9f@github.com>
 <n4bN1ctWwpwO4apSBwHqakHb7hli9ep2q_I_wIDbGtc=.6d02e0d2-563a-4a6f-871b-d4dd8ba17fcb@github.com>
Message-ID: <IqkERTX-PMd7Cc32Mm3NcLyX4FcOM4_ZAMKMeqDouXE=.3051ad31-0404-4c21-945d-c2782aa8866f@github.com>

On Fri, 22 Oct 2021 12:14:20 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> > Did you check the possibility to verify JDK-4140484, I think it should be possible but just in case.
> 
> Original test cases from JDK-4140484 description are still have no issues.

Please clarify, did the updated test fail before that fix, and pass after?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6056


From prr at openjdk.java.net  Fri Oct 22 19:34:23 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 22 Oct 2021 19:34:23 GMT
Subject: RFR: 8273704: DrawStringWithInfiniteXform.java failed : drawString
 with InfiniteXform transform takes long time
Message-ID: <Lpf8FVKhBAteysIOTzRIoWtn6p1EajY6ehzReguXoGc=.c4321b67-bfbc-4215-8ef7-1e88a856de8e@github.com>

This test has only failed once - for reasons that are not clear.
I wanted to just increase the timeout but the test was written such that it always waited as long
as the timeout since it had an un-canceled scheduled task.

So I've also made the test cancel the task once it is complete and made the variables volatile
so that they should be read properly by the other thread.

-------------

Commit messages:
 - 8273704: DrawStringWithInfiniteXform.java failed : drawString with InfiniteXform transform takes long time

Changes: https://git.openjdk.java.net/jdk/pull/6087/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6087&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273704
  Stats: 7 lines in 1 file changed: 3 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6087.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6087/head:pull/6087

PR: https://git.openjdk.java.net/jdk/pull/6087


From azvegint at openjdk.java.net  Fri Oct 22 20:07:26 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 22 Oct 2021 20:07:26 GMT
Subject: RFR: 8196440: Regression automated Test
 'java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java' fails
Message-ID: <09f_P3LaFU1pPdYsexSXSV9fJflRjwlgEmOlq-UZWNk=.38fbc1fa-5329-4579-bb97-480024065500@github.com>

The test doesn't take into account that SystemTray may not be supported.
In case of Ubuntu this happens when `_NET_SYSTEM_TRAY` is not present.

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/6088/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6088&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8196440
  Stats: 6 lines in 2 files changed: 4 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6088.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6088/head:pull/6088

PR: https://git.openjdk.java.net/jdk/pull/6088


From azvegint at openjdk.java.net  Fri Oct 22 20:19:07 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 22 Oct 2021 20:19:07 GMT
Subject: RFR: 8202932:
 java/awt/Component/NativeInLightShow/NativeInLightShow.java fails [v2]
In-Reply-To: <IqkERTX-PMd7Cc32Mm3NcLyX4FcOM4_ZAMKMeqDouXE=.3051ad31-0404-4c21-945d-c2782aa8866f@github.com>
References: <vY4S5SLgt0RvQVidwLC5Kqp37ljbyIM_K735XfBlyl8=.5015954d-5207-4095-82bd-ab6608a77151@github.com>
 <95Ty6Hv3R3Ct4J2oOvMIjp7cfDSvV55Uo76W0adP30E=.c6b3a36a-6249-48bd-bcb8-9e155b557bff@github.com>
 <7Ug6UOYRmQKVjsKNNNnboGhOrJdc30jQdBJKriHFitw=.8ee7bb71-f4ef-4969-bb15-473bb0561f9f@github.com>
 <n4bN1ctWwpwO4apSBwHqakHb7hli9ep2q_I_wIDbGtc=.6d02e0d2-563a-4a6f-871b-d4dd8ba17fcb@github.com>
 <IqkERTX-PMd7Cc32Mm3NcLyX4FcOM4_ZAMKMeqDouXE=.3051ad31-0404-4c21-945d-c2782aa8866f@github.com>
Message-ID: <zrYi9Nj-0Y6c6_cZNlirC08hO4ex0Fj-1QOsisDJL7Q=.4a8174e0-9df5-4ad8-8e6f-6352743a9b4a@github.com>

On Fri, 22 Oct 2021 19:11:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please clarify, did the updated test fail before that fix, and pass after?

Unfortunately I could not find a correct repo location for jdk6 containing the original fix changeset. 

All I've found is a bunch of mercurial repos `jdk6u*/j2se`, which are containing the fix, but has no history about it, since it was loaded along with `Initial load` changeset. 

IIRC it should be something other than mercurial(SVN or smth else), but still have no idea where to find it.

The fix proposed in JDK-4140484 comments is too far away from current code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6056


From darkzalgo at gmail.com  Fri Oct 22 22:07:26 2021
From: darkzalgo at gmail.com (John Cummings)
Date: Fri, 22 Oct 2021 15:07:26 -0700
Subject: ARMv7A Sound Not Working On OpenJDK-11
In-Reply-To: <CAA3xS4nNG7RLRs0gs7D8VQx2pZrXwpJbs0A545ONqOJrmDX6eg@mail.gmail.com>
References: <CAA3xS4nNG7RLRs0gs7D8VQx2pZrXwpJbs0A545ONqOJrmDX6eg@mail.gmail.com>
Message-ID: <CAA3xS4khP90LpvBMmzLeC-4w8cHVBV5p-wYO6W-mRk+rQe_hJA@mail.gmail.com>

Nevermind! I found the solution shortly after: it turns out there was a
discrepancy between the libasound.so.2.0.0 on the system and the one in my
buildroot. For some reason snd_pcm_hw_params_get_channels_min in
src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_PCM.c at
156 would always return an error. After copying over the buildroot
libasound.so.2.0.0, everything worked just fine.

On Fri, Oct 22, 2021 at 9:37 AM John Cummings <darkzalgo at gmail.com> wrote:

> Hello all,
> I have been attempting to build OpenJDK-11 for an ARMv7-A system using
> Cortex-A7 that currently runs Java 8. After resolving my build issues with
> the build-dev mailing list (who sent me here for this issue), I'm able to
> make it run on the system, but it cannot play sound and I have been unable
> to figure out why. Running the same java applications one after another, 8
> will play sound, 11 will crash upon trying to get the source line.
>
> Please let me know if there's any additional information I can provide
> that may help!
>
> I have attempted building with two different toolchains, I've used the
> branch at https://hg.openjdk.java.net/jdk/jdk11 as well as the one at
> https://github.com/openjdk/jdk11u-dev/. I've tried the server, client,
> and zero variants of both, with and without fastdebug enabled, and haven't
> made much progress with it. I've also tried with java 8 still on the
> system, and with deleting it entirely. I've also attempted to add the
> following to the sound.properties:
>
> javax.sound.sampled.Clip=com.sun.media.sound.DirectAudioDeviceProvider
> javax.sound.sampled.Port=com.sun.media.sound.PortMixerProvider
>
> javax.sound.sampled.SourceDataLine=com.sun.media.sound.DirectAudioDeviceProvider
>
> javax.sound.sampled.TargetDataLine=com.sun.media.sound.DirectAudioDeviceProvider
>
> This is the configuration I've been using:
> bash configure \
> --openjdk-target=arm-unknown-linux-gnueabihf \
> --with-native-debug-symbols=none \
> --disable-warnings-as-errors \
> --with-abi-profile=arm-vfp-hflt \
> --disable-ccache \
> --with-build-jdk=/opt/openjdk/jdk11u-dev/build/linux-x86_64-normal-server-release/images/jdk
> \
> --with-sysroot=/opt/buildroot-2017.08/output/host/arm-buildroot-linux-gnueabihf/sysroot/
> \
> --with-toolchain-path=/opt/x-tools/arm-unknown-linux-gnueabihf/bin \
> --with-x=/opt/buildroot-2017.08/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr
>  \
> --with-cups=/opt/sbuildroot-2017.08/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr
> \
> --with-fontconfig=/opt/buildroot-2017.08/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr
> \
> --with-freetype-lib=/opt/buildroot-2017.08/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib
> \
> --with-freetype-include=/opt/buildroot-2017.08/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include
> \
> --with-alsa=/opt/buildroot-2017.08/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr
> \
> --with-stdc++lib=dynamic \
> --with-extra-cxxflags='-O2 -pipe' \
> --with-extra-cflags='-O2 -pipe' \
> --with-jobs=8 \
> --with-jvm-variants=client
>
>
> Output of uname -a for this system is
> Linux sun6i 3.3.0 #125 SMP PREEMPT Fri Feb 5 07:04:03 CST 2021 armv7l
> GNU/Linux
>
> Output of java -version for 8 is
> # java8 -version
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) Client VM (build 25.144-b01, mixed mode)
> Output for the newly built 11 is:
> # java -version
> openjdk version "11.0.14-internal" 2022-01-18
> OpenJDK Runtime Environment (build
> 11.0.14-internal+0-adhoc.johnc.jdk11u-dev)
> OpenJDK Client VM (build 11.0.14-internal+0-adhoc.johnc.jdk11u-dev, mixed
> mode)
>
>   The app I've been collecting information with just gets the mixers, and
> any data lines and prints their values, and then plays a .wav file using
> SourceDataLine, and again with Clip. I use -Daudio.mixer="M1 PCM [default]"
> because in the Java 11 build, setting it to null for the default just
> returns null, and it doesn't even return the "Found Audio Mixer" line. If
> it helps, here is the java itself: https://pastebin.com/CCfUWTTf
>
> The output is as follows for 8 and 11:
>
>
>
> Java 8 output
>
>
>
> # java8 -Daudio.mixer="M1 PCM [default]" AudioFormats SuccessBuzzer.wav
> Found audio mixer: M1 PCM [default]
> Supported Lines of default mixer (M1 PCM [default]):
>
>
> Mixer ClassName:
> com.sun.media.sound.DirectAudioDeviceProvider$DirectAudioDeviceInfo
> Mixer Desc: Direct Audio Device: sun7i PCM, M1 PCM, sun7i PCM
> Vendor: ALSA (http://www.alsa-project.org)
>
> M1 PCM [default]        ---     interface SourceDataLine supporting 8
> audio formats, and buffers of at least 32 bytes -----
> com.sun.media.sound.DirectAudioDevice$DirectSDL at 873330
> M1 PCM [default]        ---     interface Clip supporting 8 audio formats,
> and buffers of at least 32 bytes -----
> com.sun.media.sound.DirectAudioDevice$DirectClip at 19d7047
> com.sun.media.sound.DirectAudioDevice at 16ec8df   ---     interface
> TargetDataLine supporting 8 audio formats, and buffers of at least 32 bytes
> -----   com.sun.media.sound.DirectAudioDevice$DirectTDL at ec7777
> Mixer Num Source Info Lines: 2
> Mixer Num Target Info Lines: 1
> interface SourceDataLine supporting 8 audio formats, and buffers of at
> least 32 bytes
>   max buffer size:      -1
>   min buffer size:      32
>   Supported Audio formats:
>     PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame,
> little-endian
>       encoding:           PCM_SIGNED
>       channels:           1
>       frame size [bytes]: 2
>       sample size [bit]:  16
>       big endian:         false
>       line supported:         true
>     PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, big-endian
>       encoding:           PCM_SIGNED
>       channels:           1
>       frame size [bytes]: 2
>       sample size [bit]:  16
>       big endian:         true
>       line supported:         true
>     PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame,
> little-endian
>       encoding:           PCM_SIGNED
>       channels:           2
>       frame size [bytes]: 4
>       sample size [bit]:  16
>       big endian:         false
>       line supported:         true
>     PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame,
> big-endian
>       encoding:           PCM_SIGNED
>       channels:           2
>       frame size [bytes]: 4
>       sample size [bit]:  16
>       big endian:         true
>       line supported:         true
>     PCM_SIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame,
>       encoding:           PCM_SIGNED
>       channels:           1
>       frame size [bytes]: 1
>       sample size [bit]:  8
>       big endian:         false
>       line supported:         true
>     PCM_UNSIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame,
>       encoding:           PCM_UNSIGNED
>       channels:           1
>       frame size [bytes]: 1
>       sample size [bit]:  8
>       big endian:         false
>       line supported:         true
>     PCM_SIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame,
>       encoding:           PCM_SIGNED
>       channels:           2
>       frame size [bytes]: 2
>       sample size [bit]:  8
>       big endian:         false
>       line supported:         true
>     PCM_UNSIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame,
>       encoding:           PCM_UNSIGNED
>       channels:           2
>       frame size [bytes]: 2
>       sample size [bit]:  8
>       big endian:         false
>       line supported:         true
>
>
> interface Clip supporting 8 audio formats, and buffers of at least 32 bytes
>
> Playing SuccessBuzzer.wav
> Source Data Lines:     PCM_SIGNED 22050.0 Hz, 16 bit, stereo, 4
> bytes/frame, little-endian
>       encoding:           PCM_SIGNED
>       channels:           2
>       frame rate [1/s]:   22050.0
>       frame size [bytes]: 4
>       sample rate [1/s]:  22050.0
>       sample size [bit]:  16
>       big endian:         false
>       line supported:         true
>
>
>
> Clip Data Lines:     PCM_SIGNED 22050.0 Hz, 16 bit, stereo, 4 bytes/frame,
> little-endian
>       encoding:           PCM_SIGNED
>       channels:           2
>       frame rate [1/s]:   22050.0
>       frame size [bytes]: 4
>       sample rate [1/s]:  22050.0
>       sample size [bit]:  16
>       big endian:         false
>       line supported:         true
>
>
>
> Target Data Lines:     PCM_SIGNED 22050.0 Hz, 16 bit, stereo, 4
> bytes/frame, little-endian
>       encoding:           PCM_SIGNED
>       channels:           2
>       frame rate [1/s]:   22050.0
>       frame size [bytes]: 4
>       sample rate [1/s]:  22050.0
>       sample size [bit]:  16
>       big endian:         false
>       line supported:         true
>
>
>
>
>
>
>
>
> Java 11 Output
>
>
>
>
>
> # java -Daudio.mixer="M1 PCM [default]" AudioFormats SuccessBuzzer.wav
> Found audio mixer: M1 PCM [default]
> Supported Lines of default mixer (M1 PCM [default]):
>
>
> Mixer ClassName:
> com.sun.media.sound.DirectAudioDeviceProvider$DirectAudioDeviceInfo
> Mixer Desc: Direct Audio Device: sun7i PCM, M1 PCM, sun7i PCM
> Vendor: ALSA (http://www.alsa-project.org)
>
> Mixer Has 0 Source Info Lines:
> Mixer Has 0 Target Info Lines:
>
>
>
>
>
> Playing SuccessBuzzer.wav
> Source Data Lines:     PCM_SIGNED 22050.0 Hz, 16 bit, stereo, 4
> bytes/frame, little-endian
>       encoding:           PCM_SIGNED
>       channels:           2
>       frame rate [1/s]:   22050.0
>       frame size [bytes]: 4
>       sample rate [1/s]:  22050.0
>       sample size [bit]:  16
>       big endian:         false
>       line supported:         false
>
>
>
> Clip Data Lines:     PCM_SIGNED 22050.0 Hz, 16 bit, stereo, 4 bytes/frame,
> little-endian
>       encoding:           PCM_SIGNED
>       channels:           2
>       frame rate [1/s]:   22050.0
>       frame size [bytes]: 4
>       sample rate [1/s]:  22050.0
>       sample size [bit]:  16
>       big endian:         false
>       line supported:         false
>
>
>
> Target Data Lines:     PCM_SIGNED 22050.0 Hz, 16 bit, stereo, 4
> bytes/frame, little-endian
>       encoding:           PCM_SIGNED
>       channels:           2
>       frame rate [1/s]:   22050.0
>       frame size [bytes]: 4
>       sample rate [1/s]:  22050.0
>       sample size [bit]:  16
>       big endian:         false
>       line supported:         false
> java.lang.IllegalArgumentException: No line matching interface
> SourceDataLine supporting format PCM_SIGNED 22050.0 Hz, 16 bit, stereo, 4
> bytes/frame, little-endian is supported.
>         at
> java.desktop/javax.sound.sampled.AudioSystem.getLine(AudioSystem.java:425)
>         at AudioFormats.main(AudioFormats.java:77)
> java.lang.IllegalArgumentException: No line matching interface Clip
> supporting format PCM_SIGNED unknown sample rate, 16 bit, stereo, 4
> bytes/frame, big-endian is supported.
>         at
> java.desktop/javax.sound.sampled.AudioSystem.getLine(AudioSystem.java:425)
>         at
> java.desktop/javax.sound.sampled.AudioSystem.getClip(AudioSystem.java:461)
>         at AudioFormats.main(AudioFormats.java:94)
>
> On another application I've also had an error pointing to the
> DirectAudioDevice.java that also plays the same .wav file.
>
> Caused by: java.lang.IllegalArgumentException: Line unsupported: interface
> SourceDataLine
>         at
> java.desktop/com.sun.media.sound.DirectAudioDevice.getLine(DirectAudioDevice.java:175)
>         at
> java.desktop/javax.sound.sampled.AudioSystem.getSourceDataLine(AudioSystem.java:572)
>
> Here's aplay output for that file too in case that helps:
>
> #aplay -vvv SuccessBuzzer.wav
> Playing WAVE 'SuccessBuzzer.wav' : Signed 16 bit Little Endian, Rate 22050
> Hz, Stereo
> Hardware PCM card 0 'audiocodec' device 0 subdevice 0
> Its setup is:
>   stream       : PLAYBACK
>   access       : RW_INTERLEAVED
>   format       : S16_LE
>   subformat    : STD
>   channels     : 2
>   rate         : 22050
>   exact rate   : 22050 (22050/1)
>   msbits       : 16
>   buffer_size  : 8192
>   period_size  : 2048
>   period_time  : 92879
>   tstamp_mode  : NONE
>   tstamp_type  : MONOTONIC
>   period_step  : 1
>   avail_min    : 2048
>   period_event : 0
>   start_threshold  : 8192
>   stop_threshold   : 8192
>   silence_threshold: 0
>   silence_size : 0
>   boundary     : 1073741824
>   appl_ptr     : 0
>   hw_ptr       : 0
> Max peak (4096 samples): 0x0000095f ##                   7%
> Max peak (4096 samples): 0x00001a62 #####                20%
> Max peak (4096 samples): 0x00001b1c #####                21%
> Max peak (4096 samples): 0x0000182c ####                 18%
> Max peak (4096 samples): 0x000005de #                    4%
> Max peak (4096 samples): 0x00000451 #                    3%
> Max peak (4096 samples): 0x000001d5 #                    1%
>
>
> Thanks,
> John Cummings
>
>


From serb at openjdk.java.net  Sat Oct 23 01:25:01 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 23 Oct 2021 01:25:01 GMT
Subject: RFR: 8196440: Regression automated Test
 'java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java' fails
In-Reply-To: <09f_P3LaFU1pPdYsexSXSV9fJflRjwlgEmOlq-UZWNk=.38fbc1fa-5329-4579-bb97-480024065500@github.com>
References: <09f_P3LaFU1pPdYsexSXSV9fJflRjwlgEmOlq-UZWNk=.38fbc1fa-5329-4579-bb97-480024065500@github.com>
Message-ID: <Aa9PnFV05pTf8S81-8Fvt18QCc-obcyT3GAlBBdlzZ4=.91d1c058-2b9b-43fc-a496-a2878f0ec293@github.com>

On Fri, 22 Oct 2021 19:59:31 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The test doesn't take into account that SystemTray may not be supported.
> In case of Ubuntu this happens when `_NET_SYSTEM_TRAY` is not present.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6088


From serb at openjdk.java.net  Sat Oct 23 01:38:02 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 23 Oct 2021 01:38:02 GMT
Subject: RFR: 8275170: Some jtreg sound tests should be marked headful
In-Reply-To: <X41BDIEKsSkDT89l1hdzX-UaUgdSjsDy93urJmQVRl8=.32fc5ade-4d6a-4d0a-ac00-2fab11ded55d@github.com>
References: <X41BDIEKsSkDT89l1hdzX-UaUgdSjsDy93urJmQVRl8=.32fc5ade-4d6a-4d0a-ac00-2fab11ded55d@github.com>
Message-ID: <i8N4fiRBafjP-aYA3cB3ovjxtgWJCNq93EHks3epN1k=.cd764806-2964-4eec-b62a-1ccb8b99df00@github.com>

On Fri, 22 Oct 2021 19:01:27 GMT, Phil Race <prr at openjdk.org> wrote:

> This fix adds "headful sound" keywords to a number of javax/sound jtreg tests
> 
> The jtreg javax.sound tests are written in such a way that if a needed audio device
> or other platform resource is not available, they just exit with a "pass" for the test.
> It is as if headful tests just swallowed HeadlessException and issued a pass.
> If we allowed that we'd be effectively testing almost nothing of real importance.
> 
> Currently almost  all sound tests have no keyword like "headful" to indicate they
> may need access to a hardware resource to do anything useful so a similar
> situation arises there except when someone runs those tests manually on
> a local system which has audio devices.
> 
> Of course "headful" and "audio device" aren't exactly interchangeable terms
> but if tests are allowed to be run - or worse usually or always run - in a situation
> where they potentially are on a system without an audio device (a headless VM) or are running in
> a session which doesn't have full desktop access - which may in some
> cases be how audio device access is granted, then they are more likely
> to be running in this scenario where the testing isn't valid.
> 
> Another point is that headful tests must be run one at a time - no concurrency because
> you can't have multiple tests moving the mouse at the same time
> Whereas for headless tests, a test harness may choose to run concurrently - perhaps even in the same VM
> When tests that really need access to an audio device are run it is probably safer to consider
> the headful attribute as implying one test at a time is best .. granted on a desktop it isn't
> usual for a single app to be able to monopolize access to a speaker, but for input devices
> that is what you'd generally expect.
> 
> By no means am I sure that the tests being updated here are the full set that need tagging.
> There are a lot of tests and they are all known to pass on systems with NO audio
> devices, so the search has been for tests which call APIs which will definitely
> need access to some device in order to do anything useful.
> So likely there are more to be added - either by a reviewer pointing them out or by later discovery.
> Alternatively we could mark ALL sound tests headful .. but given where we are starting from
> that might be erring unnecessarily far in the opposite direction.
> 
> By adding both headful and sound keywords it gives options to someone who
> wants to identify the tests and perhaps run just tests which need "sound" on some
> config they know supports audio but isn't headful.

I am not sure this is the right thing to do, as you pointed out the headless system may or may not have the sound configured, similar to the headful system may not have a sound. I see a lot of headful systems in the cloud where the audio device is not configured, and the opposite where the headless system actually has some audio devices. And this change just makes things complicated by assignee the headful keyword to the unrelated sound system.

Actually, it is the step in the opposite direction that was done when these tests were moved to tier3, at that the headful keyword was removed from these tests to make tier3 coverage as much as possible.

I am still not sure what problem do you want to solve? If the problem is to run the tests on the system where the sound is configured then just run them there, so it will not be necessary to validate each test does it really need a sound/headful keyword or not, otherwise what is the benefit?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6086


From serb at openjdk.java.net  Sat Oct 23 01:42:01 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 23 Oct 2021 01:42:01 GMT
Subject: RFR: 8273704: DrawStringWithInfiniteXform.java failed : drawString
 with InfiniteXform transform takes long time
In-Reply-To: <Lpf8FVKhBAteysIOTzRIoWtn6p1EajY6ehzReguXoGc=.c4321b67-bfbc-4215-8ef7-1e88a856de8e@github.com>
References: <Lpf8FVKhBAteysIOTzRIoWtn6p1EajY6ehzReguXoGc=.c4321b67-bfbc-4215-8ef7-1e88a856de8e@github.com>
Message-ID: <PHYYnjMZir3xg1Nx9VjGoF4ZzIWjC8_RiIKdUdeIJ7U=.b1031758-6e82-4933-937e-e54fe22d5233@github.com>

On Fri, 22 Oct 2021 19:25:28 GMT, Phil Race <prr at openjdk.org> wrote:

> This test has only failed once - for reasons that are not clear.
> I wanted to just increase the timeout but the test was written such that it always waited as long
> as the timeout since it had an un-canceled scheduled task.
> 
> So I've also made the test cancel the task once it is complete and made the variables volatile
> so that they should be read properly by the other thread.

Why do we need all that TimerTask machinery? We can just place the code to the main method, and the jtreg will provide useful information on the timeout if any.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6087


From serb at openjdk.java.net  Sat Oct 23 01:44:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 23 Oct 2021 01:44:10 GMT
Subject: RFR: 8202932:
 java/awt/Component/NativeInLightShow/NativeInLightShow.java fails [v3]
In-Reply-To: <lysXyb-6c3QeqdRvPT4aD1JLjTSG0m5OhPHt5LHRqH0=.e69afd4f-41c4-4fd3-8885-15e2f0c5f41b@github.com>
References: <vY4S5SLgt0RvQVidwLC5Kqp37ljbyIM_K735XfBlyl8=.5015954d-5207-4095-82bd-ab6608a77151@github.com>
 <lysXyb-6c3QeqdRvPT4aD1JLjTSG0m5OhPHt5LHRqH0=.e69afd4f-41c4-4fd3-8885-15e2f0c5f41b@github.com>
Message-ID: <WJ-FwgU19ABHANa1CxHRoNcbR-5U2IB-VO3xeRyAtaI=.82dbd2c0-26c1-4be0-b549-b5f014234b5d@github.com>

On Fri, 22 Oct 2021 12:05:24 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Looks like the test does not fail anymore.
>> 
>> However some cleanup was made:
>> 
>> - fixed wildcard imports
>> - frame centered and explicitly disposed at the end
>> - removed unused `setAutoDelay()` call (no key/mouse key events generated)
>> - improved variable naming
>> 
>> Testing still green.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   extra safety

It was fixed in jdk6 but reported for the early release, so probably it can reproduce the bug in jdk5?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6056


From serb at openjdk.java.net  Sat Oct 23 19:37:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 23 Oct 2021 19:37:14 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails [v2]
In-Reply-To: <rPnwSUK5os-UosusAicJMekZup50FucJbREshLrg9yw=.e1cd3257-b0be-4790-b746-74044ba35046@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <rPnwSUK5os-UosusAicJMekZup50FucJbREshLrg9yw=.e1cd3257-b0be-4790-b746-74044ba35046@github.com>
Message-ID: <QSryHpbWmqvmoNapItM-_QT0KttKlweI3ZkeNEG4Zh0=.3a6592c8-bdd0-4db4-8b78-ef9e05b7530b@github.com>

On Fri, 15 Oct 2021 11:09:26 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 7001973 fixes?
>> 
>> On Windows, CopyAreaOOB.java fails with a blank window. The cause of this problem is that paint() works one time only. Painting area is not guaranteed when showing a window.
>> 
>> I think this behavior should be removed for purpose of this test (`@summary: Verifies that copyArea() works properly`). Also, this program uses a Robot, but implements waiting logic by itself. This logic should be replaced to Robot API.
>> 
>> This fix works fine in Windows, so this test can be removed from ProblemList.txt. I don't have a Mac environment, so can someone please confirm that this fix will work on Mac?
>
> Masanori Yano has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>  - Merge branch 'master' of https://github.com/masyano/jdk into 7001973
>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails

This looks fine, but should be checked on other platforms Linux/macOS since it can uncover some issues there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5491


From serb at openjdk.java.net  Sat Oct 23 19:44:00 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 23 Oct 2021 19:44:00 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing
In-Reply-To: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
Message-ID: <-hj0v7RZ0HPpP9GND5csZsZ1Vz7oxaufOAC0-ZygtwM=.6a5ae7a8-52d6-4e3e-a166-2fae2c23dbe0@github.com>

On Thu, 21 Oct 2021 12:19:43 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the 8275715 bug fixes?
> 
> I think D3DScreenUpdateManager posts unnecessary PaintEvent during processing PaintEvent. When the validate method is called from createGraphics, repaintPeerTarget should not be called.

src/java.desktop/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java line 455:

> 453:                             rq.unlock();
> 454:                         }
> 455:                     } else if (!validate(sd, true)) {

The comment below says that "the surface will also trigger a repaint", will it be possible we will trigger it inside validate here and then later inside "replaceSurfaceDataLater"?

test/jdk/sun/java2d/DirectX/MultiPaintEventTest/MultiPaintEventTest.java line 36:

> 34: public class MultiPaintEventTest extends Canvas {
> 35: 
> 36:     private int count = 0;

Some synchronization is needed, the field is updated on EDT and checked on the main thread.

test/jdk/sun/java2d/DirectX/MultiPaintEventTest/MultiPaintEventTest.java line 75:

> 73:                 throw new RuntimeException("Processed unnecessary paint().");
> 74:             }
> 75:         } catch (InterruptedException ex) {

Do not ignore an exception

-------------

PR: https://git.openjdk.java.net/jdk/pull/6064


From azvegint at openjdk.java.net  Sat Oct 23 20:54:01 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Sat, 23 Oct 2021 20:54:01 GMT
Subject: RFR: 8202932:
 java/awt/Component/NativeInLightShow/NativeInLightShow.java fails [v3]
In-Reply-To: <lysXyb-6c3QeqdRvPT4aD1JLjTSG0m5OhPHt5LHRqH0=.e69afd4f-41c4-4fd3-8885-15e2f0c5f41b@github.com>
References: <vY4S5SLgt0RvQVidwLC5Kqp37ljbyIM_K735XfBlyl8=.5015954d-5207-4095-82bd-ab6608a77151@github.com>
 <lysXyb-6c3QeqdRvPT4aD1JLjTSG0m5OhPHt5LHRqH0=.e69afd4f-41c4-4fd3-8885-15e2f0c5f41b@github.com>
Message-ID: <u3sy4hXeKV96zqU-4ycQyGWfrQF-IHOGlX5HojMHO_U=.6ceefd55-5264-4003-beb5-bb3baa539bcd@github.com>

On Fri, 22 Oct 2021 12:05:24 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Looks like the test does not fail anymore.
>> 
>> However some cleanup was made:
>> 
>> - fixed wildcard imports
>> - frame centered and explicitly disposed at the end
>> - removed unused `setAutoDelay()` call (no key/mouse key events generated)
>> - improved variable naming
>> 
>> Testing still green.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   extra safety

Yes, it is reproducible with jdk1.5, and not reproducible with jdk1.6 at least on Windows(jdk1.5 on Linux won't launch)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6056


From prr at openjdk.java.net  Sun Oct 24 03:37:00 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 24 Oct 2021 03:37:00 GMT
Subject: RFR: 8273704: DrawStringWithInfiniteXform.java failed : drawString
 with InfiniteXform transform takes long time
In-Reply-To: <Lpf8FVKhBAteysIOTzRIoWtn6p1EajY6ehzReguXoGc=.c4321b67-bfbc-4215-8ef7-1e88a856de8e@github.com>
References: <Lpf8FVKhBAteysIOTzRIoWtn6p1EajY6ehzReguXoGc=.c4321b67-bfbc-4215-8ef7-1e88a856de8e@github.com>
Message-ID: <AHzQL5xS-NmS8mjEyN6BKrVk5PzZhfKSU3b2yDEL7dk=.9b4a017f-fd3e-4a5d-82ce-802f15995991@github.com>

On Fri, 22 Oct 2021 19:25:28 GMT, Phil Race <prr at openjdk.org> wrote:

> This test has only failed once - for reasons that are not clear.
> I wanted to just increase the timeout but the test was written such that it always waited as long
> as the timeout since it had an un-canceled scheduled task.
> 
> So I've also made the test cancel the task once it is complete and made the variables volatile
> so that they should be read properly by the other thread.

The test is just being minimally updated for stability.
If you want to re-write it under a follow up PR - you may do so, but I'm just stabilising what is there

-------------

PR: https://git.openjdk.java.net/jdk/pull/6087


From prr at openjdk.java.net  Sun Oct 24 16:48:04 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 24 Oct 2021 16:48:04 GMT
Subject: RFR: 8275170: Some jtreg sound tests should be marked headful
In-Reply-To: <X41BDIEKsSkDT89l1hdzX-UaUgdSjsDy93urJmQVRl8=.32fc5ade-4d6a-4d0a-ac00-2fab11ded55d@github.com>
References: <X41BDIEKsSkDT89l1hdzX-UaUgdSjsDy93urJmQVRl8=.32fc5ade-4d6a-4d0a-ac00-2fab11ded55d@github.com>
Message-ID: <SriqZUu-zXKsMZMS1HTeh-iZ1oRh4XD9i-J7RZm7oDk=.0691a19c-26a6-45c8-abc0-c0d51ef7713d@github.com>

On Fri, 22 Oct 2021 19:01:27 GMT, Phil Race <prr at openjdk.org> wrote:

> This fix adds "headful sound" keywords to a number of javax/sound jtreg tests
> 
> The jtreg javax.sound tests are written in such a way that if a needed audio device
> or other platform resource is not available, they just exit with a "pass" for the test.
> It is as if headful tests just swallowed HeadlessException and issued a pass.
> If we allowed that we'd be effectively testing almost nothing of real importance.
> 
> Currently almost  all sound tests have no keyword like "headful" to indicate they
> may need access to a hardware resource to do anything useful so a similar
> situation arises there except when someone runs those tests manually on
> a local system which has audio devices.
> 
> Of course "headful" and "audio device" aren't exactly interchangeable terms
> but if tests are allowed to be run - or worse usually or always run - in a situation
> where they potentially are on a system without an audio device (a headless VM) or are running in
> a session which doesn't have full desktop access - which may in some
> cases be how audio device access is granted, then they are more likely
> to be running in this scenario where the testing isn't valid.
> 
> Another point is that headful tests must be run one at a time - no concurrency because
> you can't have multiple tests moving the mouse at the same time
> Whereas for headless tests, a test harness may choose to run concurrently - perhaps even in the same VM
> When tests that really need access to an audio device are run it is probably safer to consider
> the headful attribute as implying one test at a time is best .. granted on a desktop it isn't
> usual for a single app to be able to monopolize access to a speaker, but for input devices
> that is what you'd generally expect.
> 
> By no means am I sure that the tests being updated here are the full set that need tagging.
> There are a lot of tests and they are all known to pass on systems with NO audio
> devices, so the search has been for tests which call APIs which will definitely
> need access to some device in order to do anything useful.
> So likely there are more to be added - either by a reviewer pointing them out or by later discovery.
> Alternatively we could mark ALL sound tests headful .. but given where we are starting from
> that might be erring unnecessarily far in the opposite direction.
> 
> By adding both headful and sound keywords it gives options to someone who
> wants to identify the tests and perhaps run just tests which need "sound" on some
> config they know supports audio but isn't headful.

This makes the tests eligible to be run on headful systems.
In practice it seems like ONLY headful systems actually have the sound devices.
The sound keyword isn't understood by anything yet, so adding headful is the only way
we have right now of ensuring these tests are eligible to be run on systems that have the
necessary support.

As I explained in the initial PR description headful is also useful for implying exclusive access.

And without this keyword it means that these tests are ALWAYS run on systems without
sound device support. So for years we've effectively problem listed these tests due to
the tests not having headful and silently passing when there's no sound.
Without headful  no one runs these on systems that have the needed device.

So this solves a big hole that we aren't testing this case.

The 2 keywords give flexibility - anyone who wants to filter when its marked headful
and needing sound can do this, but just adding sound right now will solve nothing.

And there are a couple of tests NOT in OpenJDK that already do this so we have precedent - and in a previous life one was added by you and the other approved by you ..

-------------

PR: https://git.openjdk.java.net/jdk/pull/6086


From serb at openjdk.java.net  Sun Oct 24 23:03:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 24 Oct 2021 23:03:06 GMT
Subject: RFR: 8275170: Some jtreg sound tests should be marked headful
In-Reply-To: <SriqZUu-zXKsMZMS1HTeh-iZ1oRh4XD9i-J7RZm7oDk=.0691a19c-26a6-45c8-abc0-c0d51ef7713d@github.com>
References: <X41BDIEKsSkDT89l1hdzX-UaUgdSjsDy93urJmQVRl8=.32fc5ade-4d6a-4d0a-ac00-2fab11ded55d@github.com>
 <SriqZUu-zXKsMZMS1HTeh-iZ1oRh4XD9i-J7RZm7oDk=.0691a19c-26a6-45c8-abc0-c0d51ef7713d@github.com>
Message-ID: <cdD36MzU5YV3QBIVXe9Czc2cbiY3xGl8qRu4b3rmUE4=.7481deff-b232-4520-9cff-f6fa82be871b@github.com>

On Sun, 24 Oct 2021 16:45:15 GMT, Phil Race <prr at openjdk.org> wrote:

> This makes the tests eligible to be run on headful systems. In practice it seems like ONLY headful systems actually have the sound devices. The sound keyword isn't understood by anything yet, so adding headful is the only way we have right now of ensuring these tests are eligible to be run on systems that have the necessary support.

This is not the right approach, it was made a hard work to eliminate the headful keyword from any tests including sound which are not throw the headless exception or something. The "headful" means that the test will fail otherwise due to UI session missing. We should not abuse it to select some other unrelated tests. Like we do not doing this for printer.

The problem you try to solve is that you have a "bad" system where nothing is configured and the "good" system where UI/sound(what about printer?) are configured. And you want to exclude all tests from the "bad" host and run them on the "good" one by using the headful keyword which is not targeted for this usecase.

> As I explained in the initial PR description headful is also useful for implying exclusive access.

Such exclusive access should not be needed by the sound, in fact it was found a few hard too spot concurrency bugs when we start to run the sound tests in parallel.
 
> And without this keyword it means that these tests are ALWAYS run on systems without sound device support.

Is it always just because the sound is not configured on the systems where you run the tests without headful keyword? How it is related to the "headfulness" of the systems?

> So for years we've effectively problem listed these tests due to the tests not having headful and silently passing when there's no sound. Without headful no one runs these on systems that have the needed device.

This was done intentionally that everybody who run the tests also run the tests for the sound, moreover it was included the openjdk tier3, before it was accidentally removed from there. 

> The 2 keywords give flexibility - anyone who wants to filter when its marked headful and needing sound can do this, but just adding sound right now will solve nothing.

Such flexibility exists already, it is possible to run test/jdk/javax/sound on any computer you want and exclude it from the jdk_desktop test run.

> And there are a couple of tests NOT in OpenJDK that already do this so we have precedent - and in a previous life one was added by you and the other approved by you ..

If it is not in the OpenJDK then we do not need to discuss it here and that's not actually a precedent. We should investigate each case one by one, the headful keyword does not solve any issue on windows, since all windows are headful(or most of them where we interested in the audio), on macOS the sound subsystem is built-in. And on Linux it is possible to configure sound as well and it will work fine w/o X server.

I think most of the sound tests are written according to the spec which does not required UI, and if it was necessary to make it pass by running on the system which have UI system configured make me think that some product bug was workaround.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6086


From serb at openjdk.java.net  Sun Oct 24 23:12:03 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 24 Oct 2021 23:12:03 GMT
Subject: RFR: 8273704: DrawStringWithInfiniteXform.java failed : drawString
 with InfiniteXform transform takes long time
In-Reply-To: <Lpf8FVKhBAteysIOTzRIoWtn6p1EajY6ehzReguXoGc=.c4321b67-bfbc-4215-8ef7-1e88a856de8e@github.com>
References: <Lpf8FVKhBAteysIOTzRIoWtn6p1EajY6ehzReguXoGc=.c4321b67-bfbc-4215-8ef7-1e88a856de8e@github.com>
Message-ID: <PoKeiw07AQ_YqmDdcuPyRQ03m41PjlPAesCOZWzqfXM=.7940cb7a-8260-4db4-bced-6cce82b4eda7@github.com>

On Fri, 22 Oct 2021 19:25:28 GMT, Phil Race <prr at openjdk.org> wrote:

> This test has only failed once - for reasons that are not clear.
> I wanted to just increase the timeout but the test was written such that it always waited as long
> as the timeout since it had an un-canceled scheduled task.
> 
> So I've also made the test cancel the task once it is complete and made the variables volatile
> so that they should be read properly by the other thread.

ok, looks fine then

-------------

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6087


From serb at openjdk.java.net  Mon Oct 25 00:36:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 25 Oct 2021 00:36:06 GMT
Subject: RFR: 8202932:
 java/awt/Component/NativeInLightShow/NativeInLightShow.java fails [v3]
In-Reply-To: <lysXyb-6c3QeqdRvPT4aD1JLjTSG0m5OhPHt5LHRqH0=.e69afd4f-41c4-4fd3-8885-15e2f0c5f41b@github.com>
References: <vY4S5SLgt0RvQVidwLC5Kqp37ljbyIM_K735XfBlyl8=.5015954d-5207-4095-82bd-ab6608a77151@github.com>
 <lysXyb-6c3QeqdRvPT4aD1JLjTSG0m5OhPHt5LHRqH0=.e69afd4f-41c4-4fd3-8885-15e2f0c5f41b@github.com>
Message-ID: <3EK8NOJPhB7AzVKjZUxs1Uq-lWDwLjI3Ohszswlr7T0=.5b93e913-cdbd-468f-b933-56869b8fd4f2@github.com>

On Fri, 22 Oct 2021 12:05:24 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Looks like the test does not fail anymore.
>> 
>> However some cleanup was made:
>> 
>> - fixed wildcard imports
>> - frame centered and explicitly disposed at the end
>> - removed unused `setAutoDelay()` call (no key/mouse key events generated)
>> - improved variable naming
>> 
>> Testing still green.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   extra safety

Thank you for confirmation, looks fine.

-------------

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6056


From psadhukhan at openjdk.java.net  Mon Oct 25 04:53:01 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 25 Oct 2021 04:53:01 GMT
Subject: RFR: 8273704: DrawStringWithInfiniteXform.java failed : drawString
 with InfiniteXform transform takes long time
In-Reply-To: <Lpf8FVKhBAteysIOTzRIoWtn6p1EajY6ehzReguXoGc=.c4321b67-bfbc-4215-8ef7-1e88a856de8e@github.com>
References: <Lpf8FVKhBAteysIOTzRIoWtn6p1EajY6ehzReguXoGc=.c4321b67-bfbc-4215-8ef7-1e88a856de8e@github.com>
Message-ID: <-KNEFSqonrxm3bFlCBe7Bz9cCY86OGra1odoCN5V9HY=.cab1a092-e933-4f4a-9977-849ee6eafd6c@github.com>

On Fri, 22 Oct 2021 19:25:28 GMT, Phil Race <prr at openjdk.org> wrote:

> This test has only failed once - for reasons that are not clear.
> I wanted to just increase the timeout but the test was written such that it always waited as long
> as the timeout since it had an un-canceled scheduled task.
> 
> So I've also made the test cancel the task once it is complete and made the variables volatile
> so that they should be read properly by the other thread.

Probably you can consider rectifying the wild card imports also...

-------------

Marked as reviewed by psadhukhan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6087


From psadhukhan at openjdk.java.net  Mon Oct 25 04:54:00 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 25 Oct 2021 04:54:00 GMT
Subject: RFR: 8196440: Regression automated Test
 'java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java' fails
In-Reply-To: <09f_P3LaFU1pPdYsexSXSV9fJflRjwlgEmOlq-UZWNk=.38fbc1fa-5329-4579-bb97-480024065500@github.com>
References: <09f_P3LaFU1pPdYsexSXSV9fJflRjwlgEmOlq-UZWNk=.38fbc1fa-5329-4579-bb97-480024065500@github.com>
Message-ID: <-7K01DK_MFU4ZkyGq5VNAfg0YnxDnCrJoDWKAOP9r3g=.39e0714c-468e-486e-881c-e1572b440901@github.com>

On Fri, 22 Oct 2021 19:59:31 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The test doesn't take into account that SystemTray may not be supported.
> In case of Ubuntu this happens when `_NET_SYSTEM_TRAY` is not present.

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6088


From psadhukhan at openjdk.java.net  Mon Oct 25 07:21:21 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 25 Oct 2021 07:21:21 GMT
Subject: RFR: 8275851: Deproblemlist
 open/test/jdk/javax/swing/JComponent/6683775/bug6683775.java
Message-ID: <LAjI8RJuX_7Z7gJnDRGSbtPm_0mACnIJQktvapGFf-8=.3632723f-6712-42ba-aee4-a471922bad44@github.com>

Test was problemlisted long time back by JDK-8193211 but it is passing now..Modified testFrame access in EDT and dispose in finally block for better safeguard. Problemlisted test was marked for 8u so did not close it..
Several iterations of the test pass in all platforms in mainline..

-------------

Commit messages:
 - 8275851: Deproblemlist open/test/jdk/javax/swing/JComponent/6683775/bug6683775.java
 - 8275851: Deproblemlist open/test/jdk/javax/swing/JComponent/6683775/bug6683775.java

Changes: https://git.openjdk.java.net/jdk/pull/6097/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6097&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275851
  Stats: 33 lines in 2 files changed: 7 ins; 2 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6097.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6097/head:pull/6097

PR: https://git.openjdk.java.net/jdk/pull/6097


From ant at openjdk.java.net  Mon Oct 25 09:44:04 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Mon, 25 Oct 2021 09:44:04 GMT
Subject: RFR: 8275819: [TableRowAccessibility accessibilityChildren] method
 is ineffective
In-Reply-To: <HyEBVOJtMpIhHE-bQzWs_06Gg3DU8w9JHIW39yAT-68=.171ba533-0b45-41d0-b024-e25bdc8b36d0@github.com>
References: <HyEBVOJtMpIhHE-bQzWs_06Gg3DU8w9JHIW39yAT-68=.171ba533-0b45-41d0-b024-e25bdc8b36d0@github.com>
Message-ID: <LG6kREpOeLHDE4jZLzWwZ5vjHymz_MkwKowY0-U3HJE=.3e459615-adae-4430-8312-3c6bf27045be@github.com>

On Fri, 22 Oct 2021 18:29:01 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> Retrieve only cells for a particular table row when requested, not the whole table.

@azuev-java @pankaj-bansal please review

-------------

PR: https://git.openjdk.java.net/jdk/pull/6085


From pbansal at openjdk.java.net  Mon Oct 25 10:54:00 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 25 Oct 2021 10:54:00 GMT
Subject: RFR: 8275819: [TableRowAccessibility accessibilityChildren] method
 is ineffective
In-Reply-To: <HyEBVOJtMpIhHE-bQzWs_06Gg3DU8w9JHIW39yAT-68=.171ba533-0b45-41d0-b024-e25bdc8b36d0@github.com>
References: <HyEBVOJtMpIhHE-bQzWs_06Gg3DU8w9JHIW39yAT-68=.171ba533-0b45-41d0-b024-e25bdc8b36d0@github.com>
Message-ID: <iiObnkt0KAi_L-4gPDsXPPvYGAPH4Yb5hw0VRXakbWg=.cb458aa3-4628-4562-84f4-e941704acbf6@github.com>

On Fri, 22 Oct 2021 18:29:01 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> Retrieve only cells for a particular table row when requested, not the whole table.

Marked as reviewed by pbansal (Reviewer).

Looks good to me

-------------

PR: https://git.openjdk.java.net/jdk/pull/6085


From myano at openjdk.java.net  Mon Oct 25 10:55:05 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Mon, 25 Oct 2021 10:55:05 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails [v2]
In-Reply-To: <QSryHpbWmqvmoNapItM-_QT0KttKlweI3ZkeNEG4Zh0=.3a6592c8-bdd0-4db4-8b78-ef9e05b7530b@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <rPnwSUK5os-UosusAicJMekZup50FucJbREshLrg9yw=.e1cd3257-b0be-4790-b746-74044ba35046@github.com>
 <QSryHpbWmqvmoNapItM-_QT0KttKlweI3ZkeNEG4Zh0=.3a6592c8-bdd0-4db4-8b78-ef9e05b7530b@github.com>
Message-ID: <Y92jezHVfDFcXa1TrmAhqPvppEg3xGYKdaYmnA6UVhI=.5d77bdfd-c6ff-4637-b62c-5404518ef9c0@github.com>

On Sat, 23 Oct 2021 19:34:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Masanori Yano has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - Merge branch 'master' of https://github.com/masyano/jdk into 7001973
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>
> This looks fine, but should be checked on other platforms Linux/macOS since it can uncover some issues there.

@mrserb I have tested on Linux, and it worked fine. But I don't have MacOS environment. Could you test it instead of me?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5491


From kizune at openjdk.java.net  Mon Oct 25 12:32:20 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 25 Oct 2021 12:32:20 GMT
Subject: RFR: 8017175: [TESTBUG] javax/swing/JPopupMenu/4634626/bug4634626.java
 sometimes failed on mac
Message-ID: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>

Moved Swing component modification to the EDT.
Increased wait time for popup to show up.
Made checking variabled volatile.
Generic code cleanup.
Removed the test from ProblemList.txt

-------------

Commit messages:
 - 8017175: [TESTBUG] javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac

Changes: https://git.openjdk.java.net/jdk/pull/6104/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6104&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8017175
  Stats: 48 lines in 2 files changed: 22 ins; 6 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6104.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6104/head:pull/6104

PR: https://git.openjdk.java.net/jdk/pull/6104


From azvegint at openjdk.java.net  Mon Oct 25 14:31:12 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 25 Oct 2021 14:31:12 GMT
Subject: Integrated: 8196440: Regression automated Test
 'java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java' fails
In-Reply-To: <09f_P3LaFU1pPdYsexSXSV9fJflRjwlgEmOlq-UZWNk=.38fbc1fa-5329-4579-bb97-480024065500@github.com>
References: <09f_P3LaFU1pPdYsexSXSV9fJflRjwlgEmOlq-UZWNk=.38fbc1fa-5329-4579-bb97-480024065500@github.com>
Message-ID: <DXmRACaJuE5YzYsiaUmzRRQS7Gra8tJ1AFtp41woN9U=.55a90d27-76ed-4853-aa49-1eb6cd4a2dd6@github.com>

On Fri, 22 Oct 2021 19:59:31 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The test doesn't take into account that SystemTray may not be supported.
> In case of Ubuntu this happens when `_NET_SYSTEM_TRAY` is not present.

This pull request has now been integrated.

Changeset: f610ef0d
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f610ef0dbc17cd3066da799a02f7f5e977261d44
Stats:     6 lines in 2 files changed: 4 ins; 1 del; 1 mod

8196440: Regression automated Test 'java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java' fails

Reviewed-by: serb, psadhukhan

-------------

PR: https://git.openjdk.java.net/jdk/pull/6088


From azvegint at openjdk.java.net  Mon Oct 25 14:38:14 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 25 Oct 2021 14:38:14 GMT
Subject: Integrated: 8202932:
 java/awt/Component/NativeInLightShow/NativeInLightShow.java fails
In-Reply-To: <vY4S5SLgt0RvQVidwLC5Kqp37ljbyIM_K735XfBlyl8=.5015954d-5207-4095-82bd-ab6608a77151@github.com>
References: <vY4S5SLgt0RvQVidwLC5Kqp37ljbyIM_K735XfBlyl8=.5015954d-5207-4095-82bd-ab6608a77151@github.com>
Message-ID: <Ijm-FWQlFoymwTBLjehIY0Z4Dw3mYzgj0AHizLayIHg=.8120c24e-6f33-4974-a88e-d10e89ea02ec@github.com>

On Thu, 21 Oct 2021 02:04:01 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Looks like the test does not fail anymore.
> 
> However some cleanup was made:
> 
> - fixed wildcard imports
> - frame centered and explicitly disposed at the end
> - removed unused `setAutoDelay()` call (no key/mouse key events generated)
> - improved variable naming
> 
> Testing still green.

This pull request has now been integrated.

Changeset: 7cf68b19
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7cf68b1901cc6f8ab30f8f8496de10f4017bfc58
Stats:     54 lines in 2 files changed: 18 ins; 19 del; 17 mod

8202932: java/awt/Component/NativeInLightShow/NativeInLightShow.java fails

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/6056


From asemenov at openjdk.java.net  Mon Oct 25 16:03:06 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Mon, 25 Oct 2021 16:03:06 GMT
Subject: RFR: 8273678 TableAccessibility and TableRowAccessibility miss
 autorelease
In-Reply-To: <A54SFKDa5sz5XioUaL4wDIqIxp9QVSk3Q8YM_CB-UtY=.8ea6b5aa-ea49-4d00-b611-c74923c761e9@github.com>
References: <A54SFKDa5sz5XioUaL4wDIqIxp9QVSk3Q8YM_CB-UtY=.8ea6b5aa-ea49-4d00-b611-c74923c761e9@github.com>
Message-ID: <jRoxUSqVKIsVhkIuCIPDueZFG2spSoPUZdkNf-P-WgE=.fedc8bee-ffc8-4c99-8c83-cb996aa84467@github.com>

On Tue, 19 Oct 2021 17:11:18 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The TableAccessibility obj-c class should call [autorelease] on an object it allocates (see: [TableRowAccessibility alloc] and [ColumnAccessibility alloc]). 
> 
> The TableRowAccessibility obj-c class should not call [retain] on an allocated object (see: [CellAccessibility alloc]). 
> 
> "You own any object you create", see: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html
> 
> The logic of creating a CellAccessibility object will be reimplemented in the context of [JDK-8275720](https://bugs.openjdk.java.net/browse/JDK-8275720 "bugs.openjdk.java.net").

@pankaj-bansal please review

-------------

PR: https://git.openjdk.java.net/jdk/pull/6020


From jvanek at openjdk.java.net  Mon Oct 25 16:13:20 2021
From: jvanek at openjdk.java.net (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=)
Date: Mon, 25 Oct 2021 16:13:20 GMT
Subject: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with
 build.xml
Message-ID: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>

The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
lacking the dist directory. This patch is fixing it. Note, that
build.xml have correct paths

-------------

Commit messages:
 - 8275872: Sync J2DBench run and analyze Makefile targets with build.xml

Changes: https://git.openjdk.java.net/jdk/pull/6068/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6068&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275872
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6068.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6068/head:pull/6068

PR: https://git.openjdk.java.net/jdk/pull/6068


From jvanek at openjdk.java.net  Mon Oct 25 16:13:20 2021
From: jvanek at openjdk.java.net (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=)
Date: Mon, 25 Oct 2021 16:13:20 GMT
Subject: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with
 build.xml
In-Reply-To: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
References: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
Message-ID: <LmzyyPjgBOOIzfkVpH55YGYaAlIN9vqE4Ww0XnVLNKo=.82f9b12f-15e0-4ac1-8c20-06950beed373@github.com>

On Thu, 21 Oct 2021 17:04:08 GMT, Ji?? Van?k <jvanek at openjdk.org> wrote:

> The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
> lacking the dist directory. This patch is fixing it. Note, that
> build.xml have correct paths

I'm looking for kind soul to create bug and merge on my behalf.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6068


From ihse at openjdk.java.net  Mon Oct 25 16:13:20 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 25 Oct 2021 16:13:20 GMT
Subject: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with
 build.xml
In-Reply-To: <LmzyyPjgBOOIzfkVpH55YGYaAlIN9vqE4Ww0XnVLNKo=.82f9b12f-15e0-4ac1-8c20-06950beed373@github.com>
References: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
 <LmzyyPjgBOOIzfkVpH55YGYaAlIN9vqE4Ww0XnVLNKo=.82f9b12f-15e0-4ac1-8c20-06950beed373@github.com>
Message-ID: <Isj_awX6WE-50VBB15GLH3lXHjhDcVt8OQL8tUAlHA0=.3a39d244-7870-488c-8fc1-85dc74cf5e3a@github.com>

On Thu, 21 Oct 2021 17:04:54 GMT, Ji?? Van?k <jvanek at openjdk.org> wrote:

>> The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
>> lacking the dist directory. This patch is fixing it. Note, that
>> build.xml have correct paths
>
> I'm looking for kind soul to create bug and merge on my behalf.

Hi @judovana 

This PR is not going to be noticed by anyone who can review it. Please send an email to the relevant mailing lists (in this case client-dev at openjdk.java.net and build-dev at openjdk.java.net) to raise a discussion and, hopefully, have someone sponsor this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6068


From serb at openjdk.java.net  Mon Oct 25 16:13:20 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 25 Oct 2021 16:13:20 GMT
Subject: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with
 build.xml
In-Reply-To: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
References: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
Message-ID: <dlghvesmpNm2jxzdVRNWAdE2nbMfkRNCs3ZPxKOjNTg=.12409132-28dc-41ef-a986-d038c2a676c3@github.com>

On Thu, 21 Oct 2021 17:04:08 GMT, Ji?? Van?k <jvanek at openjdk.org> wrote:

> The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
> lacking the dist directory. This patch is fixing it. Note, that
> build.xml have correct paths

this looks fine, please update the copyright date

-------------

PR: https://git.openjdk.java.net/jdk/pull/6068


From andrew at openjdk.java.net  Mon Oct 25 16:13:20 2021
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 25 Oct 2021 16:13:20 GMT
Subject: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with
 build.xml
In-Reply-To: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
References: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
Message-ID: <LTyYF8SEDcagdjgEsCeD1QQJVYJncE9bHTDIuBcn8tU=.c75a50bc-cff7-4287-bad1-6ca960ea07e8@github.com>

On Thu, 21 Oct 2021 17:04:08 GMT, Ji?? Van?k <jvanek at openjdk.org> wrote:

> The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
> lacking the dist directory. This patch is fixing it. Note, that
> build.xml have correct paths

I've filed https://bugs.openjdk.java.net/browse/JDK-8275872 and am happy to sponsor this minor change.
@judovana, please update the summary with the bug ID. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6068


From jvanek at openjdk.java.net  Mon Oct 25 16:13:21 2021
From: jvanek at openjdk.java.net (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=)
Date: Mon, 25 Oct 2021 16:13:21 GMT
Subject: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with
 build.xml
In-Reply-To: <dlghvesmpNm2jxzdVRNWAdE2nbMfkRNCs3ZPxKOjNTg=.12409132-28dc-41ef-a986-d038c2a676c3@github.com>
References: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
 <dlghvesmpNm2jxzdVRNWAdE2nbMfkRNCs3ZPxKOjNTg=.12409132-28dc-41ef-a986-d038c2a676c3@github.com>
Message-ID: <HoEfkGOHYtkQzgh_HXdyAY2gVCoFjOH7CwaDOciAQM4=.5990a8c3-8752-426c-9ab3-bd4566bdb103@github.com>

On Sat, 23 Oct 2021 01:50:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
>> lacking the dist directory. This patch is fixing it. Note, that
>> build.xml have correct paths
>
> this looks fine, please update the copyright date

@mrserb  @gnu-andrew  hi! Thanx! The PR was amended.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6068


From pbansal at openjdk.java.net  Mon Oct 25 16:22:03 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 25 Oct 2021 16:22:03 GMT
Subject: RFR: 8273678 TableAccessibility and TableRowAccessibility miss
 autorelease
In-Reply-To: <A54SFKDa5sz5XioUaL4wDIqIxp9QVSk3Q8YM_CB-UtY=.8ea6b5aa-ea49-4d00-b611-c74923c761e9@github.com>
References: <A54SFKDa5sz5XioUaL4wDIqIxp9QVSk3Q8YM_CB-UtY=.8ea6b5aa-ea49-4d00-b611-c74923c761e9@github.com>
Message-ID: <o6wS6aHT4YiitM0MSKJdfDPPnVmo2NkwQz5HW0P7yig=.6e1e53da-ac35-4aa2-acdf-377665afcff8@github.com>

On Tue, 19 Oct 2021 17:11:18 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The TableAccessibility obj-c class should call [autorelease] on an object it allocates (see: [TableRowAccessibility alloc] and [ColumnAccessibility alloc]). 
> 
> The TableRowAccessibility obj-c class should not call [retain] on an allocated object (see: [CellAccessibility alloc]). 
> 
> "You own any object you create", see: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html
> 
> The logic of creating a CellAccessibility object will be reimplemented in the context of [JDK-8275720](https://bugs.openjdk.java.net/browse/JDK-8275720 "bugs.openjdk.java.net").

Marked as reviewed by pbansal (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6020


From asemenov at openjdk.java.net  Mon Oct 25 16:30:12 2021
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Mon, 25 Oct 2021 16:30:12 GMT
Subject: Integrated: 8273678 TableAccessibility and TableRowAccessibility miss
 autorelease
In-Reply-To: <A54SFKDa5sz5XioUaL4wDIqIxp9QVSk3Q8YM_CB-UtY=.8ea6b5aa-ea49-4d00-b611-c74923c761e9@github.com>
References: <A54SFKDa5sz5XioUaL4wDIqIxp9QVSk3Q8YM_CB-UtY=.8ea6b5aa-ea49-4d00-b611-c74923c761e9@github.com>
Message-ID: <LisLewYls2JU_SegJfsoM4k4s95fKp-cZEnxin4bqfs=.b0240987-fd26-424d-a065-21fd6c92970d@github.com>

On Tue, 19 Oct 2021 17:11:18 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The TableAccessibility obj-c class should call [autorelease] on an object it allocates (see: [TableRowAccessibility alloc] and [ColumnAccessibility alloc]). 
> 
> The TableRowAccessibility obj-c class should not call [retain] on an allocated object (see: [CellAccessibility alloc]). 
> 
> "You own any object you create", see: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html
> 
> The logic of creating a CellAccessibility object will be reimplemented in the context of [JDK-8275720](https://bugs.openjdk.java.net/browse/JDK-8275720 "bugs.openjdk.java.net").

This pull request has now been integrated.

Changeset: 3221a14f
Author:    Artem Semenov <asemenov at openjdk.org>
Committer: Anton Tarasov <ant at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3221a14f9eaf002d91597d84efdb125704710a4c
Stats:     231 lines in 5 files changed: 136 ins; 78 del; 17 mod

8273678: TableAccessibility and TableRowAccessibility miss autorelease

Reviewed-by: ant, kizune, pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/6020


From kizune at openjdk.java.net  Mon Oct 25 17:24:05 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 25 Oct 2021 17:24:05 GMT
Subject: RFR: 8275819: [TableRowAccessibility accessibilityChildren] method
 is ineffective
In-Reply-To: <HyEBVOJtMpIhHE-bQzWs_06Gg3DU8w9JHIW39yAT-68=.171ba533-0b45-41d0-b024-e25bdc8b36d0@github.com>
References: <HyEBVOJtMpIhHE-bQzWs_06Gg3DU8w9JHIW39yAT-68=.171ba533-0b45-41d0-b024-e25bdc8b36d0@github.com>
Message-ID: <Rl8bCPAwJRV6jwo7vTXAVUzP55LElfZSeLl4uP5_ar0=.18ddec82-260c-4eb2-8ff0-f64e3d90a738@github.com>

On Fri, 22 Oct 2021 18:29:01 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> Retrieve only cells for a particular table row when requested, not the whole table.

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6085


From kizune at openjdk.java.net  Mon Oct 25 17:26:04 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 25 Oct 2021 17:26:04 GMT
Subject: RFR: 8275809: crash in [CommonComponentAccessibility
 getCAccessible:withEnv:]
In-Reply-To: <X3K_hgrMAbmWMUdptB22Nsxi0T4r9U5A-4NKtAMsTSM=.b4a95a97-7a6b-4132-94f0-3e876a10cd3a@github.com>
References: <X3K_hgrMAbmWMUdptB22Nsxi0T4r9U5A-4NKtAMsTSM=.b4a95a97-7a6b-4132-94f0-3e876a10cd3a@github.com>
Message-ID: <fcEiv42WAkpA9q7QthT7cM74sIpCICpKG8SXkk1VG_M=.880cf152-af81-4244-9475-f7770466f1ee@github.com>

On Fri, 22 Oct 2021 16:47:24 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> Adding a JNI weak ref check. There's a couple of other similar places in the code where a JNI weak ref is checked for null, in the rest of the code we pass such refs to java where they are checked for null. So, I was not able to eye catch any other similar place in the a11y code where such check is also required.

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6083


From kizune at openjdk.java.net  Mon Oct 25 17:27:11 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 25 Oct 2021 17:27:11 GMT
Subject: RFR: 8275720: CommonComponentAccessibility.createWithParent
 isWrapped causes mem leak
In-Reply-To: <TlyyL4OvaG8rPWGgx3GTG5-zBF8URNxTargyF3CVsQA=.3bb05eb6-4a10-4828-8f4a-e11d41090a82@github.com>
References: <TlyyL4OvaG8rPWGgx3GTG5-zBF8URNxTargyF3CVsQA=.3bb05eb6-4a10-4828-8f4a-e11d41090a82@github.com>
Message-ID: <JyWmeOAHo8uUvS9mUzZuP-aoYlf85fOBoXcaLHzq4HQ=.35b9905e-ec2f-419b-a41f-96d2fbf67f39@github.com>

On Fri, 22 Oct 2021 16:02:32 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> This is a reimplementation of the `isWrapped` logic in the method:
> 
> `+[CommonComponentAccessibility createWithParent:accessible:role:index:withEnv:withView:isWrapped:]`
> 
> The `isWrapped` arg was used to create an a11y element which is wrapped into an object that does not have direct peer in Java (like `ListRowAccessibility`, `TableRowAccessibility`). The problem is that such objects leak, because when the wrapped element is created (`isWrapped == YES`), the native pointer to the element is rewritten in the associated java peer (the `accessible` arg) and the element object is then released via the `CFRetainedResource` mechanism. However the wrapping object (`ListRowAccessibility`, `TableRowAccessibility`) is never released.
> 
> This fix proposes a dedicated class for creating such paired objects, where a wrapper object releases its wrapped child when the deallocation is triggered by garbage collecting the associated java peer.

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6081


From pbansal at openjdk.java.net  Mon Oct 25 17:48:05 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 25 Oct 2021 17:48:05 GMT
Subject: RFR: 8275809: crash in [CommonComponentAccessibility
 getCAccessible:withEnv:]
In-Reply-To: <X3K_hgrMAbmWMUdptB22Nsxi0T4r9U5A-4NKtAMsTSM=.b4a95a97-7a6b-4132-94f0-3e876a10cd3a@github.com>
References: <X3K_hgrMAbmWMUdptB22Nsxi0T4r9U5A-4NKtAMsTSM=.b4a95a97-7a6b-4132-94f0-3e876a10cd3a@github.com>
Message-ID: <X0njTrKwewA2VP0g6HNjqfXpzEKQg7YgkIVvtc6Y49E=.4110d384-c425-44ed-ae2f-e444d352bad8@github.com>

On Fri, 22 Oct 2021 16:47:24 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> Adding a JNI weak ref check. There's a couple of other similar places in the code where a JNI weak ref is checked for null, in the rest of the code we pass such refs to java where they are checked for null. So, I was not able to eye catch any other similar place in the a11y code where such check is also required.

looks good

-------------

Marked as reviewed by pbansal (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6083


From pbansal at openjdk.java.net  Mon Oct 25 18:36:05 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 25 Oct 2021 18:36:05 GMT
Subject: RFR: 8275720: CommonComponentAccessibility.createWithParent
 isWrapped causes mem leak
In-Reply-To: <TlyyL4OvaG8rPWGgx3GTG5-zBF8URNxTargyF3CVsQA=.3bb05eb6-4a10-4828-8f4a-e11d41090a82@github.com>
References: <TlyyL4OvaG8rPWGgx3GTG5-zBF8URNxTargyF3CVsQA=.3bb05eb6-4a10-4828-8f4a-e11d41090a82@github.com>
Message-ID: <U03V5RwdtKAOIO-qS0a1K-SWB1oE94RPjP1qWyYaeFk=.fecd1844-d754-431e-8622-1b8c42626fee@github.com>

On Fri, 22 Oct 2021 16:02:32 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> This is a reimplementation of the `isWrapped` logic in the method:
> 
> `+[CommonComponentAccessibility createWithParent:accessible:role:index:withEnv:withView:isWrapped:]`
> 
> The `isWrapped` arg was used to create an a11y element which is wrapped into an object that does not have direct peer in Java (like `ListRowAccessibility`, `TableRowAccessibility`). The problem is that such objects leak, because when the wrapped element is created (`isWrapped == YES`), the native pointer to the element is rewritten in the associated java peer (the `accessible` arg) and the element object is then released via the `CFRetainedResource` mechanism. However the wrapping object (`ListRowAccessibility`, `TableRowAccessibility`) is never released.
> 
> This fix proposes a dedicated class for creating such paired objects, where a wrapper object releases its wrapped child when the deallocation is triggered by garbage collecting the associated java peer.

Marked as reviewed by pbansal (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6081


From serb at openjdk.java.net  Mon Oct 25 23:14:17 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 25 Oct 2021 23:14:17 GMT
Subject: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with
 build.xml
In-Reply-To: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
References: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
Message-ID: <SULUanTihrjWf5dQV7LJlG2q4c91kRo_UmYU_maDFMY=.37d4ad7e-b8d8-4979-91a7-eac092b16694@github.com>

On Thu, 21 Oct 2021 17:04:08 GMT, Ji?? Van?k <jvanek at openjdk.org> wrote:

> The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
> lacking the dist directory. This patch is fixing it. Note, that
> build.xml have correct paths

src/demo/share/java2d/J2DBench/Makefile line 2:

> 1: #
> 2: # Copyright (c) 2002, 2020, 2021 Oracle and/or its affiliates. All rights reserved.

You need to update the second date, no need to create an additional one.
The first date is when the file was created and the second is when it was updated last time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6068


From serb at openjdk.java.net  Tue Oct 26 04:55:19 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 26 Oct 2021 04:55:19 GMT
Subject: RFR: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails [v2]
In-Reply-To: <rPnwSUK5os-UosusAicJMekZup50FucJbREshLrg9yw=.e1cd3257-b0be-4790-b746-74044ba35046@github.com>
References: <tV38ZV4vqCw3Qk3m6E1ZSRxeXXavHBlOPsTWJqFQ2ww=.f1dc4d3a-6a8a-47c5-98a2-f73dc29d30b4@github.com>
 <rPnwSUK5os-UosusAicJMekZup50FucJbREshLrg9yw=.e1cd3257-b0be-4790-b746-74044ba35046@github.com>
Message-ID: <UKR8wMlK7SPXlzhSDpyUIZrYggegX3_nL8uO1t5zhGs=.a9fa0456-112b-4956-83b9-44e8aecfaa7a@github.com>

On Fri, 15 Oct 2021 11:09:26 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 7001973 fixes?
>> 
>> On Windows, CopyAreaOOB.java fails with a blank window. The cause of this problem is that paint() works one time only. Painting area is not guaranteed when showing a window.
>> 
>> I think this behavior should be removed for purpose of this test (`@summary: Verifies that copyArea() works properly`). Also, this program uses a Robot, but implements waiting logic by itself. This logic should be replaced to Robot API.
>> 
>> This fix works fine in Windows, so this test can be removed from ProblemList.txt. I don't have a Mac environment, so can someone please confirm that this fix will work on Mac?
>
> Masanori Yano has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>  - Merge branch 'master' of https://github.com/masyano/jdk into 7001973
>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
>  - 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails

I'll check it, let me some time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5491


From jvanek at openjdk.java.net  Tue Oct 26 08:25:35 2021
From: jvanek at openjdk.java.net (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=)
Date: Tue, 26 Oct 2021 08:25:35 GMT
Subject: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with
 build.xml [v2]
In-Reply-To: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
References: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
Message-ID: <k7_O_pqswvMmicaO0nmPzI6tjeMyO2PvM7Re0CD0XxQ=.3a15b66b-9c34-458f-8d57-29bdec377421@github.com>

> The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
> lacking the dist directory. This patch is fixing it. Note, that
> build.xml have correct paths

Ji?? Van?k has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8275872: Sync J2DBench run and analyze Makefile targets with build.xml
  
  Fixed path for run of J2DBench.jar and J2DAnalyzer.jar
  The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
  lacking the dist directory. This patch is fixing it. Note, that
  build.xml have correct paths

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6068/files
  - new: https://git.openjdk.java.net/jdk/pull/6068/files/e28f550b..811f18d8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6068&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6068&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6068.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6068/head:pull/6068

PR: https://git.openjdk.java.net/jdk/pull/6068


From ihse at openjdk.java.net  Tue Oct 26 08:25:36 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 26 Oct 2021 08:25:36 GMT
Subject: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with
 build.xml [v2]
In-Reply-To: <k7_O_pqswvMmicaO0nmPzI6tjeMyO2PvM7Re0CD0XxQ=.3a15b66b-9c34-458f-8d57-29bdec377421@github.com>
References: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
 <k7_O_pqswvMmicaO0nmPzI6tjeMyO2PvM7Re0CD0XxQ=.3a15b66b-9c34-458f-8d57-29bdec377421@github.com>
Message-ID: <YxRC7MhNHS9TSk14MkVwS_8mTw2j4UeyOnPJORphilk=.c638a606-92a8-46d2-baff-4d0d7871e9cf@github.com>

On Tue, 26 Oct 2021 08:20:46 GMT, Ji?? Van?k <jvanek at openjdk.org> wrote:

>> The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
>> lacking the dist directory. This patch is fixing it. Note, that
>> build.xml have correct paths
>
> Ji?? Van?k has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8275872: Sync J2DBench run and analyze Makefile targets with build.xml
>   
>   Fixed path for run of J2DBench.jar and J2DAnalyzer.jar
>   The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
>   lacking the dist directory. This patch is fixing it. Note, that
>   build.xml have correct paths

Marked as reviewed by ihse (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6068


From jvanek at openjdk.java.net  Tue Oct 26 08:25:37 2021
From: jvanek at openjdk.java.net (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=)
Date: Tue, 26 Oct 2021 08:25:37 GMT
Subject: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with
 build.xml [v2]
In-Reply-To: <SULUanTihrjWf5dQV7LJlG2q4c91kRo_UmYU_maDFMY=.37d4ad7e-b8d8-4979-91a7-eac092b16694@github.com>
References: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
 <SULUanTihrjWf5dQV7LJlG2q4c91kRo_UmYU_maDFMY=.37d4ad7e-b8d8-4979-91a7-eac092b16694@github.com>
Message-ID: <ckbopFQdSp373LWssfGaHQ4KbaEgk3jgOdu7rDxdTB8=.e7b0beeb-008f-4a39-8d3f-a860107550bc@github.com>

On Mon, 25 Oct 2021 23:11:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Ji?? Van?k has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8275872: Sync J2DBench run and analyze Makefile targets with build.xml
>>   
>>   Fixed path for run of J2DBench.jar and J2DAnalyzer.jar
>>   The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
>>   lacking the dist directory. This patch is fixing it. Note, that
>>   build.xml have correct paths
>
> src/demo/share/java2d/J2DBench/Makefile line 2:
> 
>> 1: #
>> 2: # Copyright (c) 2002, 2020, 2021 Oracle and/or its affiliates. All rights reserved.
> 
> You need to update the second date, no need to create an additional one.
> The first date is when the file was created and the second is when it was updated last time.

Oh damn. Sorry. Fixed

-------------

PR: https://git.openjdk.java.net/jdk/pull/6068


From jdv at openjdk.java.net  Tue Oct 26 09:48:22 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 26 Oct 2021 09:48:22 GMT
Subject: RFR: 8213120:
 java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java
 fails on mac10.13
Message-ID: <8-cSc7Vq-p03stE6abJjft-s9P24pO8uw93L1-_xcGc=.07109ca1-f79d-44a4-bd62-c0824383c627@github.com>

Looks like this test was failing in one local system in JDK12 and it was problemlisted.
I ran this test multiple times in our CI systems it doesnt fail.
Made modifications to move test window to the middle of the screen and added autodelay for robot. Tested in our CI systems with modifications and test run is green.

-------------

Commit messages:
 - 8213120: java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java fails on mac10.13

Changes: https://git.openjdk.java.net/jdk/pull/6116/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6116&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8213120
  Stats: 3 lines in 2 files changed: 2 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6116.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6116/head:pull/6116

PR: https://git.openjdk.java.net/jdk/pull/6116


From ihse at openjdk.java.net  Tue Oct 26 10:54:08 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 26 Oct 2021 10:54:08 GMT
Subject: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with
 build.xml
In-Reply-To: <HoEfkGOHYtkQzgh_HXdyAY2gVCoFjOH7CwaDOciAQM4=.5990a8c3-8752-426c-9ab3-bd4566bdb103@github.com>
References: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
 <dlghvesmpNm2jxzdVRNWAdE2nbMfkRNCs3ZPxKOjNTg=.12409132-28dc-41ef-a986-d038c2a676c3@github.com>
 <HoEfkGOHYtkQzgh_HXdyAY2gVCoFjOH7CwaDOciAQM4=.5990a8c3-8752-426c-9ab3-bd4566bdb103@github.com>
Message-ID: <-C9D2xMkpT1ivkKdXzBFwORUcR8JHsIQKJAApCPP4VU=.d0b0b16f-cde4-44a7-be3d-447312972344@github.com>

On Mon, 25 Oct 2021 16:08:12 GMT, Ji?? Van?k <jvanek at openjdk.org> wrote:

>> this looks fine, please update the copyright date
>
> @mrserb  @gnu-andrew  hi! Thanx! The PR was amended.

@judovana Unfortunately you got "tricked" by @gnu-andrew 's comment into issuing a `/summary` comment, when you shouldn't have. That only makes the bug title be repeated as a summary. This is not how summaries are intented. (In fact, they are hardly used at all in the JDK project, and only to shortly describe the fix if the bug title is not descriptive enough).

I'm not sure if you can remove a summary, but I think you can by just issuing a blank `/summary` command, without any contents.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6068


From ihse at openjdk.java.net  Tue Oct 26 10:54:10 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 26 Oct 2021 10:54:10 GMT
Subject: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with
 build.xml [v2]
In-Reply-To: <k7_O_pqswvMmicaO0nmPzI6tjeMyO2PvM7Re0CD0XxQ=.3a15b66b-9c34-458f-8d57-29bdec377421@github.com>
References: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
 <k7_O_pqswvMmicaO0nmPzI6tjeMyO2PvM7Re0CD0XxQ=.3a15b66b-9c34-458f-8d57-29bdec377421@github.com>
Message-ID: <zkj51qZXgoJb70IfwW0OE_T4HtDvCGli_5svQaeiaR0=.ef986370-6108-4736-9890-93ba53d4881d@github.com>

On Tue, 26 Oct 2021 08:25:35 GMT, Ji?? Van?k <jvanek at openjdk.org> wrote:

>> The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
>> lacking the dist directory. This patch is fixing it. Note, that
>> build.xml have correct paths
>
> Ji?? Van?k has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

I can sponsor the PR once this is done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6068


From jvanek at openjdk.java.net  Tue Oct 26 11:16:12 2021
From: jvanek at openjdk.java.net (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=)
Date: Tue, 26 Oct 2021 11:16:12 GMT
Subject: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with
 build.xml [v2]
In-Reply-To: <k7_O_pqswvMmicaO0nmPzI6tjeMyO2PvM7Re0CD0XxQ=.3a15b66b-9c34-458f-8d57-29bdec377421@github.com>
References: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
 <k7_O_pqswvMmicaO0nmPzI6tjeMyO2PvM7Re0CD0XxQ=.3a15b66b-9c34-458f-8d57-29bdec377421@github.com>
Message-ID: <GTNIkrGUxyucqzThAmC_rdqttkLlQQFfjOUwDYNBLDA=.25dc7f82-4fe6-4aad-8f61-0b2caa49be9b@github.com>

On Tue, 26 Oct 2021 08:25:35 GMT, Ji?? Van?k <jvanek at openjdk.org> wrote:

>> The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
>> lacking the dist directory. This patch is fixing it. Note, that
>> build.xml have correct paths
>
> Ji?? Van?k has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Attmept done. Looks like the summary is there already once. Thanx again.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6068


From dholmes at openjdk.java.net  Tue Oct 26 12:31:09 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 26 Oct 2021 12:31:09 GMT
Subject: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with
 build.xml [v2]
In-Reply-To: <GTNIkrGUxyucqzThAmC_rdqttkLlQQFfjOUwDYNBLDA=.25dc7f82-4fe6-4aad-8f61-0b2caa49be9b@github.com>
References: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
 <k7_O_pqswvMmicaO0nmPzI6tjeMyO2PvM7Re0CD0XxQ=.3a15b66b-9c34-458f-8d57-29bdec377421@github.com>
 <GTNIkrGUxyucqzThAmC_rdqttkLlQQFfjOUwDYNBLDA=.25dc7f82-4fe6-4aad-8f61-0b2caa49be9b@github.com>
Message-ID: <m1aSXLejVpeUxKdsSq9Pb4bGzpn6-wwsr_sDVRZqBVY=.c6476632-48ea-4aba-83e6-6158a99f37fa@github.com>

On Tue, 26 Oct 2021 11:13:19 GMT, Ji?? Van?k <jvanek at openjdk.org> wrote:

>> Ji?? Van?k has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> Attmept done. Looks like the summary is there already once. Thanx again.

@judovana please do not use "force push" in a PR as it makes the review process very difficult and can leave orphaned comments. You can simply push additional changes after the initial commit. The skara tooling with flatten all commits into one single, properly formulated, commit that will actually be pushed to the OpenJDK repo. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6068


From jvanek at openjdk.java.net  Tue Oct 26 12:35:12 2021
From: jvanek at openjdk.java.net (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=)
Date: Tue, 26 Oct 2021 12:35:12 GMT
Subject: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with
 build.xml [v2]
In-Reply-To: <m1aSXLejVpeUxKdsSq9Pb4bGzpn6-wwsr_sDVRZqBVY=.c6476632-48ea-4aba-83e6-6158a99f37fa@github.com>
References: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
 <k7_O_pqswvMmicaO0nmPzI6tjeMyO2PvM7Re0CD0XxQ=.3a15b66b-9c34-458f-8d57-29bdec377421@github.com>
 <GTNIkrGUxyucqzThAmC_rdqttkLlQQFfjOUwDYNBLDA=.25dc7f82-4fe6-4aad-8f61-0b2caa49be9b@github.com>
 <m1aSXLejVpeUxKdsSq9Pb4bGzpn6-wwsr_sDVRZqBVY=.c6476632-48ea-4aba-83e6-6158a99f37fa@github.com>
Message-ID: <7EbGPWzdTUmeob-jPI8KCFgKBFDUC10h4u8E4IzwFb0=.bbc7285f-62d1-4bc6-b295-9840be833ed5@github.com>

On Tue, 26 Oct 2021 12:27:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Attmept done. Looks like the summary is there already once. Thanx again.
>
> @judovana please do not use "force push" in a PR as it makes the review process very difficult and can leave orphaned comments. You can simply push additional changes after the initial commit. The skara tooling with flatten all commits into one single, properly formulated, commit that will actually be pushed to the OpenJDK repo. Thanks.

thanx @dholmes-ora , will do

-------------

PR: https://git.openjdk.java.net/jdk/pull/6068


From duke at openjdk.java.net  Tue Oct 26 14:01:30 2021
From: duke at openjdk.java.net (Rolf van Kleef)
Date: Tue, 26 Oct 2021 14:01:30 GMT
Subject: RFR: JDK-8275923: Override the LPR path using a system property
Message-ID: <IhKxuLB4R8_X2tgTTCUJCABGEdJp7qvEUcRT0FdvWQY=.11fdcbdd-bf4c-48b4-8392-98055e17bf67@github.com>

On some select systems, the LPR binary may be placed elsewhere (for example at `/app/bin/lpr`). For that reason, we need to be able to override this value. This proposal also allows overriding the LP's path, as it could experience similar difficulties.

-------------

Commit messages:
 - Override the LPR path using a system property

Changes: https://git.openjdk.java.net/jdk/pull/6052/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6052&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275923
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6052.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6052/head:pull/6052

PR: https://git.openjdk.java.net/jdk/pull/6052


From ihse at openjdk.java.net  Tue Oct 26 14:01:30 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 26 Oct 2021 14:01:30 GMT
Subject: RFR: JDK-8275923: Override the LPR path using a system property
In-Reply-To: <IhKxuLB4R8_X2tgTTCUJCABGEdJp7qvEUcRT0FdvWQY=.11fdcbdd-bf4c-48b4-8392-98055e17bf67@github.com>
References: <IhKxuLB4R8_X2tgTTCUJCABGEdJp7qvEUcRT0FdvWQY=.11fdcbdd-bf4c-48b4-8392-98055e17bf67@github.com>
Message-ID: <RRcbLzxToa9UkVsMU8t98mQh0E0hEGuJslpKdZivtiA=.cd5820be-d9b7-42a0-943a-51fc03aaeab0@github.com>

On Wed, 20 Oct 2021 20:38:17 GMT, Rolf van Kleef <duke at openjdk.java.net> wrote:

> On some select systems, the LPR binary may be placed elsewhere (for example at `/app/bin/lpr`). For that reason, we need to be able to override this value. This proposal also allows overriding the LP's path, as it could experience similar difficulties.

Hi @rhbvkleef,

This PR is not going to be noticed by anyone who can review it. Please send an email to the relevant mailing lists (in this case client-dev at openjdk.java.net) to raise a discussion and, hopefully, have someone sponsor this PR.

Sorry it's client-libs-dev at openjdk.java.net.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6052


From duke at openjdk.java.net  Tue Oct 26 14:01:30 2021
From: duke at openjdk.java.net (Rolf van Kleef)
Date: Tue, 26 Oct 2021 14:01:30 GMT
Subject: RFR: JDK-8275923: Override the LPR path using a system property
In-Reply-To: <RRcbLzxToa9UkVsMU8t98mQh0E0hEGuJslpKdZivtiA=.cd5820be-d9b7-42a0-943a-51fc03aaeab0@github.com>
References: <IhKxuLB4R8_X2tgTTCUJCABGEdJp7qvEUcRT0FdvWQY=.11fdcbdd-bf4c-48b4-8392-98055e17bf67@github.com>
 <RRcbLzxToa9UkVsMU8t98mQh0E0hEGuJslpKdZivtiA=.cd5820be-d9b7-42a0-943a-51fc03aaeab0@github.com>
Message-ID: <jZ9bkKLynuCeyk9ysJeEH4uRKEixq1w3HsJ9EB1Eye8=.37dbfa39-4bda-4450-987d-9b5e9b7c8521@github.com>

On Thu, 21 Oct 2021 23:31:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> On some select systems, the LPR binary may be placed elsewhere (for example at `/app/bin/lpr`). For that reason, we need to be able to override this value. This proposal also allows overriding the LP's path, as it could experience similar difficulties.
>
> Hi @rhbvkleef,
> 
> This PR is not going to be noticed by anyone who can review it. Please send an email to the relevant mailing lists (in this case client-dev at openjdk.java.net) to raise a discussion and, hopefully, have someone sponsor this PR.

@magicus 

> in this case client-dev at openjdk.java.net

That mailing list doesn't exist.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6052


From ant at openjdk.java.net  Tue Oct 26 15:27:23 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Tue, 26 Oct 2021 15:27:23 GMT
Subject: Integrated: 8275819: [TableRowAccessibility accessibilityChildren]
 method is ineffective
In-Reply-To: <HyEBVOJtMpIhHE-bQzWs_06Gg3DU8w9JHIW39yAT-68=.171ba533-0b45-41d0-b024-e25bdc8b36d0@github.com>
References: <HyEBVOJtMpIhHE-bQzWs_06Gg3DU8w9JHIW39yAT-68=.171ba533-0b45-41d0-b024-e25bdc8b36d0@github.com>
Message-ID: <yBh1Tk9rrzCcfTng5kaf23kUXCHPuXEvbXEIfWR5tj4=.a128de60-d0e9-4725-8223-d82444fcd170@github.com>

On Fri, 22 Oct 2021 18:29:01 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> Retrieve only cells for a particular table row when requested, not the whole table.

This pull request has now been integrated.

Changeset: b98ed550
Author:    Anton Tarasov <ant at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b98ed55060b5f3b7832ec28064b04577e3725cc2
Stats:     101 lines in 2 files changed: 71 ins; 13 del; 17 mod

8275819: [TableRowAccessibility accessibilityChildren] method is ineffective

Reviewed-by: pbansal, kizune

-------------

PR: https://git.openjdk.java.net/jdk/pull/6085


From ant at openjdk.java.net  Tue Oct 26 15:30:25 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Tue, 26 Oct 2021 15:30:25 GMT
Subject: Integrated: 8275809: crash in [CommonComponentAccessibility
 getCAccessible:withEnv:]
In-Reply-To: <X3K_hgrMAbmWMUdptB22Nsxi0T4r9U5A-4NKtAMsTSM=.b4a95a97-7a6b-4132-94f0-3e876a10cd3a@github.com>
References: <X3K_hgrMAbmWMUdptB22Nsxi0T4r9U5A-4NKtAMsTSM=.b4a95a97-7a6b-4132-94f0-3e876a10cd3a@github.com>
Message-ID: <nMYZITYkzj6RgGZiq2mpDt81dWaTt4m_ecldYgJjfu4=.b0fc81fb-0518-44e6-b46c-91ea3a1cdb1a@github.com>

On Fri, 22 Oct 2021 16:47:24 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> Adding a JNI weak ref check. There's a couple of other similar places in the code where a JNI weak ref is checked for null, in the rest of the code we pass such refs to java where they are checked for null. So, I was not able to eye catch any other similar place in the a11y code where such check is also required.

This pull request has now been integrated.

Changeset: 7c88a59b
Author:    Anton Tarasov <ant at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7c88a59b7bca50061f120a1cf2c1d4457a1d741b
Stats:     22 lines in 1 file changed: 7 ins; 5 del; 10 mod

8275809: crash in [CommonComponentAccessibility getCAccessible:withEnv:]

Reviewed-by: kizune, pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/6083


From ant at openjdk.java.net  Tue Oct 26 15:51:48 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Tue, 26 Oct 2021 15:51:48 GMT
Subject: RFR: 8275720: CommonComponentAccessibility.createWithParent
 isWrapped causes mem leak [v2]
In-Reply-To: <TlyyL4OvaG8rPWGgx3GTG5-zBF8URNxTargyF3CVsQA=.3bb05eb6-4a10-4828-8f4a-e11d41090a82@github.com>
References: <TlyyL4OvaG8rPWGgx3GTG5-zBF8URNxTargyF3CVsQA=.3bb05eb6-4a10-4828-8f4a-e11d41090a82@github.com>
Message-ID: <UPu7TrQAtROVEmxJ_Qtef67YIwsluIYLInyfCdQmihU=.a09f6749-8704-4a9e-a149-5c9bb2475283@github.com>

> This is a reimplementation of the `isWrapped` logic in the method:
> 
> `+[CommonComponentAccessibility createWithParent:accessible:role:index:withEnv:withView:isWrapped:]`
> 
> The `isWrapped` arg was used to create an a11y element which is wrapped into an object that does not have direct peer in Java (like `ListRowAccessibility`, `TableRowAccessibility`). The problem is that such objects leak, because when the wrapped element is created (`isWrapped == YES`), the native pointer to the element is rewritten in the associated java peer (the `accessible` arg) and the element object is then released via the `CFRetainedResource` mechanism. However the wrapping object (`ListRowAccessibility`, `TableRowAccessibility`) is never released.
> 
> This fix proposes a dedicated class for creating such paired objects, where a wrapper object releases its wrapped child when the deallocation is triggered by garbage collecting the associated java peer.

Anton Tarasov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into JDK-8275720
 - 8275720: CommonComponentAccessibility.createWithParent isWrapped causes mem leak

-------------

Changes: https://git.openjdk.java.net/jdk/pull/6081/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6081&range=01
  Stats: 186 lines in 10 files changed: 109 ins; 52 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6081.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6081/head:pull/6081

PR: https://git.openjdk.java.net/jdk/pull/6081


From ant at openjdk.java.net  Tue Oct 26 15:51:52 2021
From: ant at openjdk.java.net (Anton Tarasov)
Date: Tue, 26 Oct 2021 15:51:52 GMT
Subject: Integrated: 8275720: CommonComponentAccessibility.createWithParent
 isWrapped causes mem leak
In-Reply-To: <TlyyL4OvaG8rPWGgx3GTG5-zBF8URNxTargyF3CVsQA=.3bb05eb6-4a10-4828-8f4a-e11d41090a82@github.com>
References: <TlyyL4OvaG8rPWGgx3GTG5-zBF8URNxTargyF3CVsQA=.3bb05eb6-4a10-4828-8f4a-e11d41090a82@github.com>
Message-ID: <ie9h4i1xS_HrgfOhZ_Yw55z8O0mzhH5nTS69EHkCbPI=.17856831-ca5a-4e7f-b7b2-e6106512ae55@github.com>

On Fri, 22 Oct 2021 16:02:32 GMT, Anton Tarasov <ant at openjdk.org> wrote:

> This is a reimplementation of the `isWrapped` logic in the method:
> 
> `+[CommonComponentAccessibility createWithParent:accessible:role:index:withEnv:withView:isWrapped:]`
> 
> The `isWrapped` arg was used to create an a11y element which is wrapped into an object that does not have direct peer in Java (like `ListRowAccessibility`, `TableRowAccessibility`). The problem is that such objects leak, because when the wrapped element is created (`isWrapped == YES`), the native pointer to the element is rewritten in the associated java peer (the `accessible` arg) and the element object is then released via the `CFRetainedResource` mechanism. However the wrapping object (`ListRowAccessibility`, `TableRowAccessibility`) is never released.
> 
> This fix proposes a dedicated class for creating such paired objects, where a wrapper object releases its wrapped child when the deallocation is triggered by garbage collecting the associated java peer.

This pull request has now been integrated.

Changeset: 574f8903
Author:    Anton Tarasov <ant at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/574f8903ee1f74bdf7154d670d96c36d94b38b4d
Stats:     186 lines in 10 files changed: 109 ins; 52 del; 25 mod

8275720: CommonComponentAccessibility.createWithParent isWrapped causes mem leak

Reviewed-by: kizune, pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/6081


From jdv at openjdk.java.net  Tue Oct 26 16:32:21 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 26 Oct 2021 16:32:21 GMT
Subject: RFR: 8275689: [TESTBUG] Use color tolerance only for XRender in
 BlitRotateClippedArea test
Message-ID: <EbZO4L1JOyiKBhRKFMTZw2CMaFsKFDOlinHEYGfIRTc=.163b98e6-28e3-42e9-8513-a43bcd98e769@github.com>

This is follow up change after : https://bugs.openjdk.java.net/browse/JDK-8255724

Now color tolerance is only added for Linux(XRender is default pipeline in Linux and Solaris is not supported anymore). So I am using jdk.test.lib.Platform to determine which OS we are running on. CI run on all platforms is green.

-------------

Commit messages:
 - 8275689: [TESTBUG] Use color tolerance only for XRender in BlitRotateClippedArea test

Changes: https://git.openjdk.java.net/jdk/pull/6119/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6119&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275689
  Stats: 30 lines in 1 file changed: 19 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6119.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6119/head:pull/6119

PR: https://git.openjdk.java.net/jdk/pull/6119


From jdv at openjdk.java.net  Tue Oct 26 16:32:21 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 26 Oct 2021 16:32:21 GMT
Subject: RFR: 8275689: [TESTBUG] Use color tolerance only for XRender in
 BlitRotateClippedArea test
In-Reply-To: <EbZO4L1JOyiKBhRKFMTZw2CMaFsKFDOlinHEYGfIRTc=.163b98e6-28e3-42e9-8513-a43bcd98e769@github.com>
References: <EbZO4L1JOyiKBhRKFMTZw2CMaFsKFDOlinHEYGfIRTc=.163b98e6-28e3-42e9-8513-a43bcd98e769@github.com>
Message-ID: <KvO2sthLTNcUZKtGxko85p5-eA3ZUbeRPzuoimIetxY=.860b4aeb-f3cd-4cba-8f87-bf4aa8bbac91@github.com>

On Tue, 26 Oct 2021 16:24:35 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This is follow up change after : https://bugs.openjdk.java.net/browse/JDK-8255724
> 
> Now color tolerance is only added for Linux(XRender is default pipeline in Linux and Solaris is not supported anymore). So I am using jdk.test.lib.Platform to determine which OS we are running on. CI run on all platforms is green.

@mrserb Please review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6119


From andrew at openjdk.java.net  Tue Oct 26 16:55:23 2021
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 26 Oct 2021 16:55:23 GMT
Subject: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with
 build.xml [v2]
In-Reply-To: <k7_O_pqswvMmicaO0nmPzI6tjeMyO2PvM7Re0CD0XxQ=.3a15b66b-9c34-458f-8d57-29bdec377421@github.com>
References: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
 <k7_O_pqswvMmicaO0nmPzI6tjeMyO2PvM7Re0CD0XxQ=.3a15b66b-9c34-458f-8d57-29bdec377421@github.com>
Message-ID: <xVB9AHqMWDzPBUvi1E87k7BMfUhfJiddi5xxo1oRSWA=.9e5c1af5-d46b-47ff-9fbb-e799c510b5fb@github.com>

On Tue, 26 Oct 2021 08:25:35 GMT, Ji?? Van?k <jvanek at openjdk.org> wrote:

>> The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
>> lacking the dist directory. This patch is fixing it. Note, that
>> build.xml have correct paths
>
> Ji?? Van?k has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Marked as reviewed by andrew (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6068


From jvanek at openjdk.java.net  Tue Oct 26 16:58:14 2021
From: jvanek at openjdk.java.net (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=)
Date: Tue, 26 Oct 2021 16:58:14 GMT
Subject: Integrated: 8275872: Sync J2DBench run and analyze Makefile targets
 with build.xml
In-Reply-To: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
References: <vxyStovZggFQbFMnMLPuCy3rAPz93wqOYEDIT2rNi6c=.bde2ea7c-9c97-4dc4-8ef6-a07ac10bc3c4@github.com>
Message-ID: <FSWlOWhbQTa00S-vRQKWSsGnDKTxlxpWO9wSTHqRAJQ=.74fdedd9-f14e-480b-95e7-4e5291b173f3@github.com>

On Thu, 21 Oct 2021 17:04:08 GMT, Ji?? Van?k <jvanek at openjdk.org> wrote:

> The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
> lacking the dist directory. This patch is fixing it. Note, that
> build.xml have correct paths

This pull request has now been integrated.

Changeset: f1f5e269
Author:    Ji?? Van?k <jvanek at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f1f5e2690cb93c07eb8be96a4cbfbf140e8a15e0
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8275872: Sync J2DBench run and analyze Makefile targets with build.xml

Reviewed-by: ihse, andrew

-------------

PR: https://git.openjdk.java.net/jdk/pull/6068


From azvegint at openjdk.java.net  Tue Oct 26 18:21:25 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 26 Oct 2021 18:21:25 GMT
Subject: RFR: 8202926: Test
 java/awt/Focus/WindowUpdateFocusabilityTest/WindowUpdateFocusabilityTest.html
 fails
Message-ID: <otck3U7WgVtQQgHxoT6SQq69XN5ppvd5D5dSp0_9K7k=.378e59fd-6059-41d3-a793-63c9b7525f46@github.com>

The test is still failing on Ubuntu 16.04 (`window1` and `window2` are not placed in front, so they are not receiving events).

Looks like this was fixed in later releases. I've manually checked this test on Ubuntu 18.04, 20.04, 21.04 and they are not affected. 

We can remove the test from the problem list since we are no longer supporting Ubuntu 16.04.

Automated testing is also green.

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/6121/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6121&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8202926
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6121.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6121/head:pull/6121

PR: https://git.openjdk.java.net/jdk/pull/6121


From serb at openjdk.java.net  Tue Oct 26 19:17:12 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 26 Oct 2021 19:17:12 GMT
Subject: RFR: 8275689: [TESTBUG] Use color tolerance only for XRender in
 BlitRotateClippedArea test
In-Reply-To: <EbZO4L1JOyiKBhRKFMTZw2CMaFsKFDOlinHEYGfIRTc=.163b98e6-28e3-42e9-8513-a43bcd98e769@github.com>
References: <EbZO4L1JOyiKBhRKFMTZw2CMaFsKFDOlinHEYGfIRTc=.163b98e6-28e3-42e9-8513-a43bcd98e769@github.com>
Message-ID: <RwUNlSca91szH6m1JQGV8b-2KdwfH3J4_Z-aqWFXHiM=.a6649a4e-030a-44f9-867a-face619a1420@github.com>

On Tue, 26 Oct 2021 16:24:35 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This is follow up change after : https://bugs.openjdk.java.net/browse/JDK-8255724
> 
> Now color tolerance is only added for Linux(XRender is default pipeline in Linux and Solaris is not supported anymore). So I am using jdk.test.lib.Platform to determine which OS we are running on. CI run on all platforms is green.

test/jdk/java/awt/image/DrawImage/BlitRotateClippedArea.java line 109:

> 107:     private static void validate(BufferedImage gold, BufferedImage img)
> 108:             throws IOException {
> 109:         if (!Platform.isLinux()) {

I think it will pass on Linux even if the X11 or OGL pipeline is used. So probably some check of the graphics config class name(XRGraphicsConfig?) will work?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6119


From serb at openjdk.java.net  Tue Oct 26 19:19:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 26 Oct 2021 19:19:08 GMT
Subject: RFR: 8202926: Test
 java/awt/Focus/WindowUpdateFocusabilityTest/WindowUpdateFocusabilityTest.html
 fails
In-Reply-To: <otck3U7WgVtQQgHxoT6SQq69XN5ppvd5D5dSp0_9K7k=.378e59fd-6059-41d3-a793-63c9b7525f46@github.com>
References: <otck3U7WgVtQQgHxoT6SQq69XN5ppvd5D5dSp0_9K7k=.378e59fd-6059-41d3-a793-63c9b7525f46@github.com>
Message-ID: <OwbIcEVdb1jY0x96veusWE7_8lDe4OrYQvwtLzNDz0o=.36f7dacf-d59e-4c7c-8596-8eca879a3b63@github.com>

On Tue, 26 Oct 2021 18:14:59 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The test is still failing on Ubuntu 16.04 (`window1` and `window2` are not placed in front, so they are not receiving events).
> 
> Looks like this was fixed in later releases. I've manually checked this test on Ubuntu 18.04, 20.04, 21.04 and they are not affected. 
> 
> We can remove the test from the problem list since we are no longer supporting Ubuntu 16.04.
> 
> Automated testing is also green.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6121


From rolf at vankleef.me  Tue Oct 26 14:02:12 2021
From: rolf at vankleef.me (Rolf van Kleef)
Date: Tue, 26 Oct 2021 14:02:12 +0000
Subject: Fwd: Re: Allow overriding lp and lpr binary paths in PSPrintJob
In-Reply-To: <27641ac4c8556d5d105d654e667c2d44@vankleef.me>
References: <27641ac4c8556d5d105d654e667c2d44@vankleef.me>
 <5b3bd9a9-38da-aa8a-b061-c4b89bdd1331@oracle.com>
 <667978336fa7b5f2deb7f892e8d289c7@vankleef.me>
Message-ID: <1a2a34853fcf3ca501ac94553189f1e4@vankleef.me>

> Well ..
> 
> 1) Please read the comment the bots added to your PR.
> There are steps you need to take before we can even look at your contribution.
> 
> 2) PRs need a JBS bug ID else the bots will still reject it.
> You'll need to submit an RFE at bugreport.java.com and go from there.

I have submitted a bug, and added a bug ID to the PR. The only remaining requirement appears to e
acquiring a review.

> 3) I understand your problem up to a point but we'd need to think about the proposed solution
> and why your Linux doesn't put lpr in the standard place. There could be legitimate
> security concerns about allowing such an over-ride.
> Perhaps you need a port of OpenJDK to that distro which you don't name ?

This specifically concerns Flatpak, where it is entirely non-trivial to place files outside of the
/app directory. I would be interested to hear about these aforementioned security concerns.
Presumably if someone is able to set system properties, there are bigger problems?

I am very open to discussing alternative solutions.

> -phil
> 
> On 10/22/21 5:42 AM, Rolf van Kleef wrote:
> 
>> I am not sure about whether this is the correct list for this, or whether this is an appropriate
>> message for this list, but I have been told to send an email here regarding a PR I submitted on
>> GitHub.
>> 
>> I recently ran into trouble with printing on Linux, where the lpr binary was on a non-standard path
>> (not in /usr/bin/lpr). After looking in the code, I found out that this path cannot be overridden.
>> It seems that such paths should be able to be overriden, and so, I propose to add a system property
>> named "sun.print.lprPath" and "sun.print.lpPath" to override these paths. See the PR below.
>> 
>> https://github.com/openjdk/jdk/pull/6052
>> 
>> Regards,
>> Rolf van Kleef


From prr at openjdk.java.net  Tue Oct 26 19:57:08 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 26 Oct 2021 19:57:08 GMT
Subject: RFR: JDK-8275923: Override the LPR path using a system property
In-Reply-To: <IhKxuLB4R8_X2tgTTCUJCABGEdJp7qvEUcRT0FdvWQY=.11fdcbdd-bf4c-48b4-8392-98055e17bf67@github.com>
References: <IhKxuLB4R8_X2tgTTCUJCABGEdJp7qvEUcRT0FdvWQY=.11fdcbdd-bf4c-48b4-8392-98055e17bf67@github.com>
Message-ID: <khtXDfqJUS9qzKN4im4OO4sXqoPMHBxZmoLb1xo6FOk=.991e572e-6fec-4a66-9ccd-2aba8385ff6b@github.com>

On Wed, 20 Oct 2021 20:38:17 GMT, Rolf van Kleef <duke at openjdk.java.net> wrote:

> On some select systems, the LPR binary may be placed elsewhere (for example at `/app/bin/lpr`). For that reason, we need to be able to override this value. This proposal also allows overriding the LP's path, as it could experience similar difficulties.

This needs a CSR since it introduces a new interface.
I also think we should consider if the hard coded path were always tried first and only if it doesn't exist would
we try the property .. 
then we'd name the property appropriately, eg
-Dsun.print.lprFallbackCommand=/app/foo/lpr
"Command" not "Path".

I will also check with the team that assesses secure coding etc to ask what they think.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6052


From kizune at openjdk.java.net  Wed Oct 27 01:02:23 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 27 Oct 2021 01:02:23 GMT
Subject: RFR: 8196017:
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
Message-ID: <wnm-YKKA9gtMKq75lwgp0FuCT4VbvaC_Fh1eJC3krR8=.4d08ec64-7140-4559-b051-987e3bea0a27@github.com>

The problem here is that due to the approximation of the coordinates when converting
to and from screen cordinate system on screen with 125% magnification 
two things can happen:
1. New mouse position calculated can be 149/149 which is the same as the starting position
and system can refuse to generate new mouse event which causes false positive of the test
since second mouse motion listener was never called;
2. Even if event is generated the resulting reported coordinates can differ by 1 pixel
in any of the directions;

To solve it i moved away the target point to make sure that move event always generated and
comparing expected and actual coordinates with approximation of +/- 1 pixel.

-------------

Commit messages:
 - 8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails

Changes: https://git.openjdk.java.net/jdk/pull/6128/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6128&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8196017
  Stats: 22 lines in 2 files changed: 7 ins; 6 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6128.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6128/head:pull/6128

PR: https://git.openjdk.java.net/jdk/pull/6128


From serb at openjdk.java.net  Wed Oct 27 01:44:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 27 Oct 2021 01:44:15 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac
In-Reply-To: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
Message-ID: <qZBrkUct8L1m6PuPuQeAxhUucuRLhsOM1bq7bu3HNgE=.616c4ffa-b9f0-4a72-99a7-4f971746e9dc@github.com>

On Mon, 25 Oct 2021 12:23:15 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Moved Swing component modification to the EDT.
> Increased wait time for popup to show up.
> Made checking variabled volatile.
> Generic code cleanup.
> Removed the test from ProblemList.txt

test/jdk/javax/swing/JPopupMenu/4634626/bug4634626.java line 201:

> 199:             robo.waitForIdle();
> 200:             try {
> 201:                 SwingUtilities.invokeAndWait(() -> someText.setInheritsPopupMenu(false));

Looks like the "commonPopup.isVisible()" and the "btnPopup.isVisible()" below also accessed on non-EDT

-------------

PR: https://git.openjdk.java.net/jdk/pull/6104


From serb at openjdk.java.net  Wed Oct 27 01:55:13 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 27 Oct 2021 01:55:13 GMT
Subject: RFR: 8275851: Deproblemlist
 open/test/jdk/javax/swing/JComponent/6683775/bug6683775.java
In-Reply-To: <LAjI8RJuX_7Z7gJnDRGSbtPm_0mACnIJQktvapGFf-8=.3632723f-6712-42ba-aee4-a471922bad44@github.com>
References: <LAjI8RJuX_7Z7gJnDRGSbtPm_0mACnIJQktvapGFf-8=.3632723f-6712-42ba-aee4-a471922bad44@github.com>
Message-ID: <kEu1qQOg9G_c8fvB2ssmGfXCkUe79cGJBok3vuIIP5s=.d5eae96b-c2e9-41b0-8029-106c246f0c03@github.com>

On Mon, 25 Oct 2021 06:47:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was problemlisted long time back by JDK-8193211 but it is passing now..Modified testFrame access in EDT and dispose in finally block for better safeguard. Problemlisted test was marked for 8u so did not close it..
> Several iterations of the test pass in all platforms in mainline..

test/jdk/javax/swing/JComponent/6683775/bug6683775.java line 89:

> 87: 
> 88:         } finally {
> 89:             SwingUtilities.invokeAndWait(testFrame::dispose);

I think we should dispose the "backgroundFrame" as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6097


From azvegint at openjdk.java.net  Wed Oct 27 02:01:11 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 27 Oct 2021 02:01:11 GMT
Subject: Integrated: 8202926: Test
 java/awt/Focus/WindowUpdateFocusabilityTest/WindowUpdateFocusabilityTest.html
 fails
In-Reply-To: <otck3U7WgVtQQgHxoT6SQq69XN5ppvd5D5dSp0_9K7k=.378e59fd-6059-41d3-a793-63c9b7525f46@github.com>
References: <otck3U7WgVtQQgHxoT6SQq69XN5ppvd5D5dSp0_9K7k=.378e59fd-6059-41d3-a793-63c9b7525f46@github.com>
Message-ID: <UV8RhGicyej4lPw2XBZIDvIsf1Zq3HWZQANrbIxUtzI=.f8705ab6-86d5-448e-8450-286b2bdf1fe2@github.com>

On Tue, 26 Oct 2021 18:14:59 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The test is still failing on Ubuntu 16.04 (`window1` and `window2` are not placed in front, so they are not receiving events).
> 
> Looks like this was fixed in later releases. I've manually checked this test on Ubuntu 18.04, 20.04, 21.04 and they are not affected. 
> 
> We can remove the test from the problem list since we are no longer supporting Ubuntu 16.04.
> 
> Automated testing is also green.

This pull request has now been integrated.

Changeset: d98b7c25
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d98b7c25910d38ac644838f59cb41ecd131c87a9
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8202926: Test java/awt/Focus/WindowUpdateFocusabilityTest/WindowUpdateFocusabilityTest.html fails

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/6121


From psadhukhan at openjdk.java.net  Wed Oct 27 05:03:30 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Oct 2021 05:03:30 GMT
Subject: RFR: 8275851: Deproblemlist
 open/test/jdk/javax/swing/JComponent/6683775/bug6683775.java [v2]
In-Reply-To: <LAjI8RJuX_7Z7gJnDRGSbtPm_0mACnIJQktvapGFf-8=.3632723f-6712-42ba-aee4-a471922bad44@github.com>
References: <LAjI8RJuX_7Z7gJnDRGSbtPm_0mACnIJQktvapGFf-8=.3632723f-6712-42ba-aee4-a471922bad44@github.com>
Message-ID: <4dbvy4rHk33GlhtazIKZiTtyb3WlGkq-Mf-6sNCcljA=.1a31147d-9556-46a5-ab09-77c2f75da845@github.com>

> Test was problemlisted long time back by JDK-8193211 but it is passing now..Modified testFrame access in EDT and dispose in finally block for better safeguard. Problemlisted test was marked for 8u so did not close it..
> Several iterations of the test pass in all platforms in mainline..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Review fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6097/files
  - new: https://git.openjdk.java.net/jdk/pull/6097/files/a87fe250..757d1e7a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6097&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6097&range=00-01

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6097.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6097/head:pull/6097

PR: https://git.openjdk.java.net/jdk/pull/6097


From psadhukhan at openjdk.java.net  Wed Oct 27 05:03:31 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Oct 2021 05:03:31 GMT
Subject: RFR: 8275851: Deproblemlist
 open/test/jdk/javax/swing/JComponent/6683775/bug6683775.java [v2]
In-Reply-To: <kEu1qQOg9G_c8fvB2ssmGfXCkUe79cGJBok3vuIIP5s=.d5eae96b-c2e9-41b0-8029-106c246f0c03@github.com>
References: <LAjI8RJuX_7Z7gJnDRGSbtPm_0mACnIJQktvapGFf-8=.3632723f-6712-42ba-aee4-a471922bad44@github.com>
 <kEu1qQOg9G_c8fvB2ssmGfXCkUe79cGJBok3vuIIP5s=.d5eae96b-c2e9-41b0-8029-106c246f0c03@github.com>
Message-ID: <Ei5Rxrw77_cm70CExxLe2hZdLZEzEO5mVJ_I6tojre0=.e5d21ca3-96f9-42f6-b6fa-a0ab523bdeee@github.com>

On Wed, 27 Oct 2021 01:52:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> test/jdk/javax/swing/JComponent/6683775/bug6683775.java line 89:
> 
>> 87: 
>> 88:         } finally {
>> 89:             SwingUtilities.invokeAndWait(testFrame::dispose);
> 
> I think we should dispose the "backgroundFrame" as well.

ok

-------------

PR: https://git.openjdk.java.net/jdk/pull/6097


From kizune at openjdk.java.net  Wed Oct 27 05:15:32 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 27 Oct 2021 05:15:32 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac [v2]
In-Reply-To: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
Message-ID: <HLIZqD2uCSFmxiLAnHXbTunMPvU78dCWzmydCKR7ZYI=.394e573e-a859-47e4-92cb-91d6f7f000b5@github.com>

> Moved Swing component modification to the EDT.
> Increased wait time for popup to show up.
> Made checking variabled volatile.
> Generic code cleanup.
> Removed the test from ProblemList.txt

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Moving access to the popup visibility status to EDT

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6104/files
  - new: https://git.openjdk.java.net/jdk/pull/6104/files/1977c961..f409cf19

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6104&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6104&range=00-01

  Stats: 16 lines in 1 file changed: 14 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6104.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6104/head:pull/6104

PR: https://git.openjdk.java.net/jdk/pull/6104


From kizune at openjdk.java.net  Wed Oct 27 05:15:33 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 27 Oct 2021 05:15:33 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac [v2]
In-Reply-To: <qZBrkUct8L1m6PuPuQeAxhUucuRLhsOM1bq7bu3HNgE=.616c4ffa-b9f0-4a72-99a7-4f971746e9dc@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
 <qZBrkUct8L1m6PuPuQeAxhUucuRLhsOM1bq7bu3HNgE=.616c4ffa-b9f0-4a72-99a7-4f971746e9dc@github.com>
Message-ID: <RvWR5_E6CdBJIp-qB4VOZoeAjWJ4Mxkoazj35OAssn4=.83ad2ab3-5842-4547-aa4b-b2b9ea7071bd@github.com>

On Wed, 27 Oct 2021 01:41:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moving access to the popup visibility status to EDT
>
> test/jdk/javax/swing/JPopupMenu/4634626/bug4634626.java line 201:
> 
>> 199:             robo.waitForIdle();
>> 200:             try {
>> 201:                 SwingUtilities.invokeAndWait(() -> someText.setInheritsPopupMenu(false));
> 
> Looks like the "commonPopup.isVisible()" and the "btnPopup.isVisible()" below also accessed on non-EDT

You are right, fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6104


From psadhukhan at openjdk.java.net  Wed Oct 27 05:24:14 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Oct 2021 05:24:14 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac [v2]
In-Reply-To: <HLIZqD2uCSFmxiLAnHXbTunMPvU78dCWzmydCKR7ZYI=.394e573e-a859-47e4-92cb-91d6f7f000b5@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
 <HLIZqD2uCSFmxiLAnHXbTunMPvU78dCWzmydCKR7ZYI=.394e573e-a859-47e4-92cb-91d6f7f000b5@github.com>
Message-ID: <iuWNGEIB1XeIFzKZJ8tVaAWwOVrkxDdSfR9uOg3BmPw=.5b2a4907-224c-4bfc-afab-97f158ba75b4@github.com>

On Wed, 27 Oct 2021 05:15:32 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Moved Swing component modification to the EDT.
>> Increased wait time for popup to show up.
>> Made checking variabled volatile.
>> Generic code cleanup.
>> Removed the test from ProblemList.txt
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moving access to the popup visibility status to EDT

test/jdk/javax/swing/JPopupMenu/4634626/bug4634626.java line 56:

> 54: 
> 55:     public static JFrame mainFrame = new JFrame("Bug4634626");
> 56:     public JPanel contentPane = new JPanel();

I guess all swing component creation also needs to be in EDT

-------------

PR: https://git.openjdk.java.net/jdk/pull/6104


From psadhukhan at openjdk.java.net  Wed Oct 27 05:24:15 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Oct 2021 05:24:15 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac [v2]
In-Reply-To: <iuWNGEIB1XeIFzKZJ8tVaAWwOVrkxDdSfR9uOg3BmPw=.5b2a4907-224c-4bfc-afab-97f158ba75b4@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
 <HLIZqD2uCSFmxiLAnHXbTunMPvU78dCWzmydCKR7ZYI=.394e573e-a859-47e4-92cb-91d6f7f000b5@github.com>
 <iuWNGEIB1XeIFzKZJ8tVaAWwOVrkxDdSfR9uOg3BmPw=.5b2a4907-224c-4bfc-afab-97f158ba75b4@github.com>
Message-ID: <-wjkwScXO_5VvlFJ-BfaS_3WTzhUd3CqP02cWH3iuLA=.06e63805-4193-4f9f-b89e-c43b58376392@github.com>

On Wed, 27 Oct 2021 05:18:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moving access to the popup visibility status to EDT
>
> test/jdk/javax/swing/JPopupMenu/4634626/bug4634626.java line 56:
> 
>> 54: 
>> 55:     public static JFrame mainFrame = new JFrame("Bug4634626");
>> 56:     public JPanel contentPane = new JPanel();
> 
> I guess all swing component creation also needs to be in EDT

I guess most of init() also should be in EDT as it works on swing components

-------------

PR: https://git.openjdk.java.net/jdk/pull/6104


From jdv at openjdk.java.net  Wed Oct 27 07:11:34 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 27 Oct 2021 07:11:34 GMT
Subject: RFR: 8275689: [TESTBUG] Use color tolerance only for XRender in
 BlitRotateClippedArea test [v2]
In-Reply-To: <EbZO4L1JOyiKBhRKFMTZw2CMaFsKFDOlinHEYGfIRTc=.163b98e6-28e3-42e9-8513-a43bcd98e769@github.com>
References: <EbZO4L1JOyiKBhRKFMTZw2CMaFsKFDOlinHEYGfIRTc=.163b98e6-28e3-42e9-8513-a43bcd98e769@github.com>
Message-ID: <Uk_1UFn4YnEFQt7qryHgeHsHprJIc1_Iw00sbaXTt9I=.5702502a-2a67-4883-adb8-29c39fc26797@github.com>

> This is follow up change after : https://bugs.openjdk.java.net/browse/JDK-8255724
> 
> Now color tolerance is only added for Linux(XRender is default pipeline in Linux and Solaris is not supported anymore). So I am using jdk.test.lib.Platform to determine which OS we are running on. CI run on all platforms is green.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Use class name to verify Graphics configuration

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6119/files
  - new: https://git.openjdk.java.net/jdk/pull/6119/files/792d73f4..376a4dec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6119&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6119&range=00-01

  Stats: 13 lines in 1 file changed: 1 ins; 6 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6119.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6119/head:pull/6119

PR: https://git.openjdk.java.net/jdk/pull/6119


From jdv at openjdk.java.net  Wed Oct 27 07:11:35 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 27 Oct 2021 07:11:35 GMT
Subject: RFR: 8275689: [TESTBUG] Use color tolerance only for XRender in
 BlitRotateClippedArea test [v2]
In-Reply-To: <RwUNlSca91szH6m1JQGV8b-2KdwfH3J4_Z-aqWFXHiM=.a6649a4e-030a-44f9-867a-face619a1420@github.com>
References: <EbZO4L1JOyiKBhRKFMTZw2CMaFsKFDOlinHEYGfIRTc=.163b98e6-28e3-42e9-8513-a43bcd98e769@github.com>
 <RwUNlSca91szH6m1JQGV8b-2KdwfH3J4_Z-aqWFXHiM=.a6649a4e-030a-44f9-867a-face619a1420@github.com>
Message-ID: <bZ05paV3CEx9daX_rUQfYkVDxDFLkWKqRPwAdb1TRkQ=.b0d6affd-19fb-451a-b1c7-a417a52aa4a8@github.com>

On Tue, 26 Oct 2021 19:13:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use class name to verify Graphics configuration
>
> test/jdk/java/awt/image/DrawImage/BlitRotateClippedArea.java line 109:
> 
>> 107:     private static void validate(BufferedImage gold, BufferedImage img)
>> 108:             throws IOException {
>> 109:         if (!Platform.isLinux()) {
> 
> I think it will pass even on Linux if the X11 or OGL pipeline is used. So probably some check of the graphics config class name(XRGraphicsConfig?) will work?

I think in current supported platforms by default it should go XRender on linux unless we specify it to use other pipelines by -Dsun.java2d.XXX=true. But to be safe it is better to confirm with class name.

I have update the code to use class name and verified that we are getting appropriate class names in all platforms.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6119


From thomas.stuefe at gmail.com  Wed Oct 27 07:31:10 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 27 Oct 2021 09:31:10 +0200
Subject: Allow overriding lp and lpr binary paths in PSPrintJob
In-Reply-To: <1a2a34853fcf3ca501ac94553189f1e4@vankleef.me>
References: <5b3bd9a9-38da-aa8a-b061-c4b89bdd1331@oracle.com>
 <667978336fa7b5f2deb7f892e8d289c7@vankleef.me>
 <27641ac4c8556d5d105d654e667c2d44@vankleef.me>
 <1a2a34853fcf3ca501ac94553189f1e4@vankleef.me>
Message-ID: <CAA-vtUw+ecDZcgr95i73fNutRs-oTOVqBcm2u_91-e5nng9oEg@mail.gmail.com>

Hi Rolf,

On Tue, Oct 26, 2021 at 9:30 PM Rolf van Kleef <rolf at vankleef.me> wrote:

> > Well ..
> >
> > 1) Please read the comment the bots added to your PR.
> > There are steps you need to take before we can even look at your
> contribution.
> >
> > 2) PRs need a JBS bug ID else the bots will still reject it.
> > You'll need to submit an RFE at bugreport.java.com and go from there.
>
> I have submitted a bug, and added a bug ID to the PR. The only remaining
> requirement appears to e
> acquiring a review.
>
> > 3) I understand your problem up to a point but we'd need to think about
> the proposed solution
> > and why your Linux doesn't put lpr in the standard place. There could be
> legitimate
> > security concerns about allowing such an over-ride.
> > Perhaps you need a port of OpenJDK to that distro which you don't name ?
>
> This specifically concerns Flatpak, where it is entirely non-trivial to
> place files outside of the
> /app directory. I would be interested to hear about these aforementioned
> security concerns.
> Presumably if someone is able to set system properties, there are bigger
> problems?
>
>
Even so, no reason to make things even easier for an attacker.

Like Phil, I would feel better with a different solution. Does it really
have to be freely configurable, can we not assume some sort of standard
path? And why do we need this on Non-Linux platforms?

This also increases the test surface, and it would be good to have a
regression test.

Cheers, Thomas


From psadhukhan at openjdk.java.net  Wed Oct 27 08:08:09 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Oct 2021 08:08:09 GMT
Subject: RFR: 8213120:
 java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java
 fails on mac10.13
In-Reply-To: <8-cSc7Vq-p03stE6abJjft-s9P24pO8uw93L1-_xcGc=.07109ca1-f79d-44a4-bd62-c0824383c627@github.com>
References: <8-cSc7Vq-p03stE6abJjft-s9P24pO8uw93L1-_xcGc=.07109ca1-f79d-44a4-bd62-c0824383c627@github.com>
Message-ID: <EdCDYYGtHGC8AOp3evTiRC-6vieYK7x-RERoTW1-OjQ=.cf9384c6-a377-42f0-a459-b2baa67ebd46@github.com>

On Tue, 26 Oct 2021 09:41:50 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Looks like this test was failing in one local system in JDK12 and it was problemlisted.
> I ran this test multiple times in our CI systems it doesnt fail.
> Made modifications to move test window to the middle of the screen and added autodelay for robot. Tested in our CI systems with modifications and test run is green.

It will be better to dispose frame in finally block. Also, better to use BUTTON1_DOWN_MASK instead of deprecated BUTTON1_MASK

-------------

PR: https://git.openjdk.java.net/jdk/pull/6116


From kizune at openjdk.java.net  Wed Oct 27 08:25:13 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 27 Oct 2021 08:25:13 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac [v2]
In-Reply-To: <-wjkwScXO_5VvlFJ-BfaS_3WTzhUd3CqP02cWH3iuLA=.06e63805-4193-4f9f-b89e-c43b58376392@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
 <HLIZqD2uCSFmxiLAnHXbTunMPvU78dCWzmydCKR7ZYI=.394e573e-a859-47e4-92cb-91d6f7f000b5@github.com>
 <iuWNGEIB1XeIFzKZJ8tVaAWwOVrkxDdSfR9uOg3BmPw=.5b2a4907-224c-4bfc-afab-97f158ba75b4@github.com>
 <-wjkwScXO_5VvlFJ-BfaS_3WTzhUd3CqP02cWH3iuLA=.06e63805-4193-4f9f-b89e-c43b58376392@github.com>
Message-ID: <LWKJpTQBsu5IU3UVwA2p4itK5PQ7YlRLjbVKwo1SwZs=.7d675aa9-35d2-4691-9a28-907143cb4e8f@github.com>

On Wed, 27 Oct 2021 05:21:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/JPopupMenu/4634626/bug4634626.java line 56:
>> 
>>> 54: 
>>> 55:     public static JFrame mainFrame = new JFrame("Bug4634626");
>>> 56:     public JPanel contentPane = new JPanel();
>> 
>> I guess all swing component creation also needs to be in EDT
>
> I guess most of init() also should be in EDT as it works on swing components

> I guess all swing component creation also needs to be in EDT

I do not think that manipulation of non-realized components on main thread is an issue so i would leave it as is.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6104


From rolf at vankleef.me  Wed Oct 27 08:39:14 2021
From: rolf at vankleef.me (Rolf van Kleef)
Date: Wed, 27 Oct 2021 08:39:14 +0000
Subject: Allow overriding lp and lpr binary paths in PSPrintJob
In-Reply-To: <b1ae9999-0985-10a7-b388-cf8083e80dde@oracle.com>
References: <b1ae9999-0985-10a7-b388-cf8083e80dde@oracle.com>
 <5b3bd9a9-38da-aa8a-b061-c4b89bdd1331@oracle.com>
 <667978336fa7b5f2deb7f892e8d289c7@vankleef.me>
 <27641ac4c8556d5d105d654e667c2d44@vankleef.me>
Message-ID: <5132b7404389c2827d92dc6cc240c847@vankleef.me>

Hi,

October 26, 2021 9:45 PM, "Philip Race" <philip.race at oracle.com> wrote:

> Hi,
> Could you sign up for the mailing list ? I keep having to manually process these
> which is work as well as delay ..

I have now done that.

> And the one for this seems to have gone AWOL, not sure what happened with mailman.

I'm afraid that was my mistake. I failed to hit "reply to all", and instead replied just
to you. Sorry!

> 
> Comments below.
> 
> On 10/26/21 7:01 AM, Rolf van Kleef wrote:
> 
>> October 22, 2021 7:05 PM, "Philip Race" <philip.race at oracle.com> wrote:
>> 
>>> Well ..
>>> 
>>> 1) Please read the comment the bots added to your PR.
>>> There are steps you need to take before we can even look at your contribution.
>>> 
>>> 2) PRs need a JBS bug ID else the bots will still reject it.
>>> You'll need to submit an RFE at bugreport.java.com and go from there.
>> 
>> I have submitted a bug, and added a bug ID to the PR. The only remaining requirement appears to e
>> acquiring a review.
> 
> Mostly .. although this actually needs an approved CSR too since it introduces a new "interface"

I see. Would looking up the binary on $PATH still require this?

>>>> 3) I understand your problem up to a point but we'd need to think about the proposed solution
>>> and why your Linux doesn't put lpr in the standard place. There could be legitimate
>>> security concerns about allowing such an over-ride.
>>> Perhaps you need a port of OpenJDK to that distro which you don't name ?
>> 
>> This specifically concerns Flatpak, where it is entirely non-trivial to place files outside of the
>> /app directory. I would be interested to hear about these aforementioned security concerns.
> 
> I see (sort of) I only recently heard of Flatpak.
> 
> I guess this also means it maybe isn't enough (even if it were OK, which I doubt it is)
> to expect that "lpr" be available on the path as a fallback to /usr/bin/lpr ?

This would be enough for Flatpak. We have full control over the path.

>> Presumably if someone is able to set system properties, there are bigger problems?
> 
> Not entirely disagreeing .. but we've had to deal with issues in the past where
> the security team had concerns with things that are sufficiently similar I'd need to get their OK

I see

>> I am very open to discussing alternative solutions.
> 
> Me too .. if I could think of any.
> Maybe we can FIRST try /usr/bin/lpr and only look at the property if the command doesn't exist ..
> That might make the security team happier because you'd need to be able to remove things
> in /usr/bin and if someone can do that then you REALLY have problems.

That makes sense. I'll suggest a new change where /usr/bin/lpr is tried first, and then the binary is
looked for on the $PATH.

> -phil.
> 
>>> -phil
>>> 
>>> On 10/22/21 5:42 AM, Rolf van Kleef wrote:
>> 
>> I am not sure about whether this is the correct list for this, or whether this is an appropriate
>> message for this list, but I have been told to send an email here regarding a PR I submitted on
>> GitHub.
>> 
>> I recently ran into trouble with printing on Linux, where the lpr binary was on a non-standard path
>> (not in /usr/bin/lpr). After looking in the code, I found out that this path cannot be overridden.
>> It seems that such paths should be able to be overriden, and so, I propose to add a system property
>> named "sun.print.lprPath" and "sun.print.lpPath" to override these paths. See the PR below.
>> 
>> https://github.com/openjdk/jdk/pull/6052
>> 
>> Regards,
>> Rolf van Kleef


From rolf at vankleef.me  Wed Oct 27 08:43:16 2021
From: rolf at vankleef.me (Rolf van Kleef)
Date: Wed, 27 Oct 2021 08:43:16 +0000
Subject: Allow overriding lp and lpr binary paths in PSPrintJob
In-Reply-To: <CAA-vtUw+ecDZcgr95i73fNutRs-oTOVqBcm2u_91-e5nng9oEg@mail.gmail.com>
References: <CAA-vtUw+ecDZcgr95i73fNutRs-oTOVqBcm2u_91-e5nng9oEg@mail.gmail.com>
 <5b3bd9a9-38da-aa8a-b061-c4b89bdd1331@oracle.com>
 <667978336fa7b5f2deb7f892e8d289c7@vankleef.me>
 <27641ac4c8556d5d105d654e667c2d44@vankleef.me>
 <1a2a34853fcf3ca501ac94553189f1e4@vankleef.me>
Message-ID: <7c7b1714288e09658bf1c8376a0d3bd3@vankleef.me>

Hi Thomas,

October 27, 2021 9:31 AM, "Thomas St?fe" <thomas.stuefe at gmail.com> wrote:

> Hi Rolf,
> 
> On Tue, Oct 26, 2021 at 9:30 PM Rolf van Kleef <rolf at vankleef.me> wrote:
> 
>>> Well ..
>>> 
>>> 1) Please read the comment the bots added to your PR.
>>> There are steps you need to take before we can even look at your contribution.
>>> 
>>> 2) PRs need a JBS bug ID else the bots will still reject it.
>>> You'll need to submit an RFE at bugreport.java.com and go from there.
>> 
>> I have submitted a bug, and added a bug ID to the PR. The only remaining requirement appears to e
>> acquiring a review.
>> 
>>> 3) I understand your problem up to a point but we'd need to think about the proposed solution
>>> and why your Linux doesn't put lpr in the standard place. There could be legitimate
>>> security concerns about allowing such an over-ride.
>>> Perhaps you need a port of OpenJDK to that distro which you don't name ?
>> 
>> This specifically concerns Flatpak, where it is entirely non-trivial to place files outside of the
>> /app directory. I would be interested to hear about these aforementioned security concerns.
>> Presumably if someone is able to set system properties, there are bigger problems?
> 
> Even so, no reason to make things even easier for an attacker.
> 
> Like Phil, I would feel better with a different solution. Does it really have to be freely
> configurable, can we not assume some sort of standard path? And why do we need this on Non-Linux
> platforms?

Why we need it on non-linux platforms? I'm not sure. I thought it would be reasonable to allow changing
both. Perhaps that was a mistake.

With regards to a different solution, first attempting /usr/bin/lpr and then looking up the binary on
$PATH seems like a reasonable alternative. That's what I will propose next.

> This also increases the test surface, and it would be good to have a regression test.

I agree. I'll include one.

> Cheers, Thomas


From jdv at openjdk.java.net  Wed Oct 27 08:47:35 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 27 Oct 2021 08:47:35 GMT
Subject: RFR: 8213120:
 java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java
 fails on mac10.13 [v2]
In-Reply-To: <8-cSc7Vq-p03stE6abJjft-s9P24pO8uw93L1-_xcGc=.07109ca1-f79d-44a4-bd62-c0824383c627@github.com>
References: <8-cSc7Vq-p03stE6abJjft-s9P24pO8uw93L1-_xcGc=.07109ca1-f79d-44a4-bd62-c0824383c627@github.com>
Message-ID: <z7WE2LcJyPOMJa-nNBhUlS54I_ZxeFPUqSLnEa3RZO4=.cb869368-29fc-40ad-a71a-642e36cbd5e2@github.com>

> Looks like this test was failing in one local system in JDK12 and it was problemlisted.
> I ran this test multiple times in our CI systems it doesnt fail.
> Made modifications to move test window to the middle of the screen and added autodelay for robot. Tested in our CI systems with modifications and test run is green.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Use BUTTON1_DOWN_MASK

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6116/files
  - new: https://git.openjdk.java.net/jdk/pull/6116/files/c8483bcd..83ffd591

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6116&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6116&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6116.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6116/head:pull/6116

PR: https://git.openjdk.java.net/jdk/pull/6116


From jdv at openjdk.java.net  Wed Oct 27 08:47:36 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 27 Oct 2021 08:47:36 GMT
Subject: RFR: 8213120:
 java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java
 fails on mac10.13 [v2]
In-Reply-To: <EdCDYYGtHGC8AOp3evTiRC-6vieYK7x-RERoTW1-OjQ=.cf9384c6-a377-42f0-a459-b2baa67ebd46@github.com>
References: <8-cSc7Vq-p03stE6abJjft-s9P24pO8uw93L1-_xcGc=.07109ca1-f79d-44a4-bd62-c0824383c627@github.com>
 <EdCDYYGtHGC8AOp3evTiRC-6vieYK7x-RERoTW1-OjQ=.cf9384c6-a377-42f0-a459-b2baa67ebd46@github.com>
Message-ID: <vxsgF_z6asrvOpKsrAJf_Cu-3gMBr3An-jm2N3zM_Ts=.2df08e50-f9d7-471c-b0c6-bfa4ddad9609@github.com>

On Wed, 27 Oct 2021 08:05:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It will be better to dispose frame in finally block. Also, better to use BUTTON1_DOWN_MASK instead of deprecated BUTTON1_MASK

@prsadhuk we explicitly call dispose() if any of test cases fail. So test should not leave unwanted window. I have update test to use BUTTON1_DOWN_MASK

-------------

PR: https://git.openjdk.java.net/jdk/pull/6116


From psadhukhan at openjdk.java.net  Wed Oct 27 09:02:10 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Oct 2021 09:02:10 GMT
Subject: RFR: 8213120:
 java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java
 fails on mac10.13 [v2]
In-Reply-To: <z7WE2LcJyPOMJa-nNBhUlS54I_ZxeFPUqSLnEa3RZO4=.cb869368-29fc-40ad-a71a-642e36cbd5e2@github.com>
References: <8-cSc7Vq-p03stE6abJjft-s9P24pO8uw93L1-_xcGc=.07109ca1-f79d-44a4-bd62-c0824383c627@github.com>
 <z7WE2LcJyPOMJa-nNBhUlS54I_ZxeFPUqSLnEa3RZO4=.cb869368-29fc-40ad-a71a-642e36cbd5e2@github.com>
Message-ID: <HPfxbvh4H-0Do27SRnB353sEEbqHhFp9cwvVo3lIlbc=.49fee721-f176-4eba-9064-52985cd872e8@github.com>

On Wed, 27 Oct 2021 08:47:35 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Looks like this test was failing in one local system in JDK12 and it was problemlisted.
>> I ran this test multiple times in our CI systems it doesnt fail.
>> Made modifications to move test window to the middle of the screen and added autodelay for robot. Tested in our CI systems with modifications and test run is green.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use BUTTON1_DOWN_MASK

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6116


From jdv at openjdk.java.net  Wed Oct 27 09:33:17 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 27 Oct 2021 09:33:17 GMT
Subject: Integrated: 8213120:
 java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java
 fails on mac10.13
In-Reply-To: <8-cSc7Vq-p03stE6abJjft-s9P24pO8uw93L1-_xcGc=.07109ca1-f79d-44a4-bd62-c0824383c627@github.com>
References: <8-cSc7Vq-p03stE6abJjft-s9P24pO8uw93L1-_xcGc=.07109ca1-f79d-44a4-bd62-c0824383c627@github.com>
Message-ID: <oun4WQiNp47MRtlq9v1HkJx_Xd_FllMiY0cS7aG5Vz0=.194d4fdd-5b0f-4e41-870b-62da620521e5@github.com>

On Tue, 26 Oct 2021 09:41:50 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Looks like this test was failing in one local system in JDK12 and it was problemlisted.
> I ran this test multiple times in our CI systems it doesnt fail.
> Made modifications to move test window to the middle of the screen and added autodelay for robot. Tested in our CI systems with modifications and test run is green.

This pull request has now been integrated.

Changeset: 2f979ecb
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2f979ecb5b642d04ad280687de76a6ee46818b35
Stats:     7 lines in 2 files changed: 2 ins; 1 del; 4 mod

8213120: java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java fails on mac10.13

Reviewed-by: psadhukhan

-------------

PR: https://git.openjdk.java.net/jdk/pull/6116


From serb at openjdk.java.net  Wed Oct 27 10:13:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 27 Oct 2021 10:13:15 GMT
Subject: RFR: 8275689: [TESTBUG] Use color tolerance only for XRender in
 BlitRotateClippedArea test [v2]
In-Reply-To: <Uk_1UFn4YnEFQt7qryHgeHsHprJIc1_Iw00sbaXTt9I=.5702502a-2a67-4883-adb8-29c39fc26797@github.com>
References: <EbZO4L1JOyiKBhRKFMTZw2CMaFsKFDOlinHEYGfIRTc=.163b98e6-28e3-42e9-8513-a43bcd98e769@github.com>
 <Uk_1UFn4YnEFQt7qryHgeHsHprJIc1_Iw00sbaXTt9I=.5702502a-2a67-4883-adb8-29c39fc26797@github.com>
Message-ID: <mzknbn60EKqKDXlQTuYaR0Oeo6vDtCAQ0lOCdy5LCFE=.436b0a61-b6d2-4525-ab07-f9157578c06b@github.com>

On Wed, 27 Oct 2021 07:11:34 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> This is follow up change after : https://bugs.openjdk.java.net/browse/JDK-8255724
>> 
>> Now color tolerance is only added for Linux(XRender is default pipeline in Linux and Solaris is not supported anymore). So I am using jdk.test.lib.Platform to determine which OS we are running on. CI run on all platforms is green.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use class name to verify Graphics configuration

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6119


From serb at openjdk.java.net  Wed Oct 27 10:15:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 27 Oct 2021 10:15:10 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac [v2]
In-Reply-To: <LWKJpTQBsu5IU3UVwA2p4itK5PQ7YlRLjbVKwo1SwZs=.7d675aa9-35d2-4691-9a28-907143cb4e8f@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
 <HLIZqD2uCSFmxiLAnHXbTunMPvU78dCWzmydCKR7ZYI=.394e573e-a859-47e4-92cb-91d6f7f000b5@github.com>
 <iuWNGEIB1XeIFzKZJ8tVaAWwOVrkxDdSfR9uOg3BmPw=.5b2a4907-224c-4bfc-afab-97f158ba75b4@github.com>
 <-wjkwScXO_5VvlFJ-BfaS_3WTzhUd3CqP02cWH3iuLA=.06e63805-4193-4f9f-b89e-c43b58376392@github.com>
 <LWKJpTQBsu5IU3UVwA2p4itK5PQ7YlRLjbVKwo1SwZs=.7d675aa9-35d2-4691-9a28-907143cb4e8f@github.com>
Message-ID: <JATrFwDsIpI4Oz0lpq8ZGftMT8oRK24rW5rvX7s99dc=.19988ef5-f5e3-417b-aaec-78511b6b2e52@github.com>

On Wed, 27 Oct 2021 08:22:05 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> I guess most of init() also should be in EDT as it works on swing components
>
>> I guess all swing component creation also needs to be in EDT
> 
> I do not think that manipulation of non-realized components on main thread is an issue so i would leave it as is.

Unfortunately the creation should be dine on EDT as well

-------------

PR: https://git.openjdk.java.net/jdk/pull/6104


From serb at openjdk.java.net  Wed Oct 27 10:20:12 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 27 Oct 2021 10:20:12 GMT
Subject: RFR: 8275851: Deproblemlist
 open/test/jdk/javax/swing/JComponent/6683775/bug6683775.java [v2]
In-Reply-To: <4dbvy4rHk33GlhtazIKZiTtyb3WlGkq-Mf-6sNCcljA=.1a31147d-9556-46a5-ab09-77c2f75da845@github.com>
References: <LAjI8RJuX_7Z7gJnDRGSbtPm_0mACnIJQktvapGFf-8=.3632723f-6712-42ba-aee4-a471922bad44@github.com>
 <4dbvy4rHk33GlhtazIKZiTtyb3WlGkq-Mf-6sNCcljA=.1a31147d-9556-46a5-ab09-77c2f75da845@github.com>
Message-ID: <T4exPdAD3e3-7BMQmrckiAUCEsOYoqqZpdiJ_UikmDE=.be869834-36ea-48c5-97e8-77e859d0fc6a@github.com>

On Wed, 27 Oct 2021 05:03:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test was problemlisted long time back by JDK-8193211 but it is passing now..Modified testFrame access in EDT and dispose in finally block for better safeguard. Problemlisted test was marked for 8u so did not close it..
>> Several iterations of the test pass in all platforms in mainline..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6097


From jdv at openjdk.java.net  Wed Oct 27 10:25:20 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 27 Oct 2021 10:25:20 GMT
Subject: Integrated: 8275689: [TESTBUG] Use color tolerance only for XRender in
 BlitRotateClippedArea test
In-Reply-To: <EbZO4L1JOyiKBhRKFMTZw2CMaFsKFDOlinHEYGfIRTc=.163b98e6-28e3-42e9-8513-a43bcd98e769@github.com>
References: <EbZO4L1JOyiKBhRKFMTZw2CMaFsKFDOlinHEYGfIRTc=.163b98e6-28e3-42e9-8513-a43bcd98e769@github.com>
Message-ID: <f5WXI1quBEf6Y4Nd9yJMVraOhogt4eK_G_BrD5xcuh4=.0dd2cc07-0c93-49c0-b229-514b9b3ee001@github.com>

On Tue, 26 Oct 2021 16:24:35 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This is follow up change after : https://bugs.openjdk.java.net/browse/JDK-8255724
> 
> Now color tolerance is only added for Linux(XRender is default pipeline in Linux and Solaris is not supported anymore). So I am using jdk.test.lib.Platform to determine which OS we are running on. CI run on all platforms is green.

This pull request has now been integrated.

Changeset: b3f45f86
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b3f45f868d9c91d630a118e43cef54cdb3216fd0
Stats:     32 lines in 1 file changed: 15 ins; 1 del; 16 mod

8275689: [TESTBUG] Use color tolerance only for XRender in BlitRotateClippedArea test

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/6119


From psadhukhan at openjdk.java.net  Wed Oct 27 10:29:18 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Oct 2021 10:29:18 GMT
Subject: Integrated: 8275851: Deproblemlist
 open/test/jdk/javax/swing/JComponent/6683775/bug6683775.java
In-Reply-To: <LAjI8RJuX_7Z7gJnDRGSbtPm_0mACnIJQktvapGFf-8=.3632723f-6712-42ba-aee4-a471922bad44@github.com>
References: <LAjI8RJuX_7Z7gJnDRGSbtPm_0mACnIJQktvapGFf-8=.3632723f-6712-42ba-aee4-a471922bad44@github.com>
Message-ID: <6NsclJlOVxNTlvTxxlL4xLV05_PhQaDlre8nkcbdIjY=.e577a17a-f16c-4c29-ad91-d60477e62e4d@github.com>

On Mon, 25 Oct 2021 06:47:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was problemlisted long time back by JDK-8193211 but it is passing now..Modified testFrame access in EDT and dispose in finally block for better safeguard. Problemlisted test was marked for 8u so did not close it..
> Several iterations of the test pass in all platforms in mainline..

This pull request has now been integrated.

Changeset: 485d6586
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/485d65865ea8af3f7275e9aa8b75057326486a4d
Stats:     35 lines in 2 files changed: 9 ins; 2 del; 24 mod

8275851: Deproblemlist open/test/jdk/javax/swing/JComponent/6683775/bug6683775.java

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/6097


From kizune at openjdk.java.net  Wed Oct 27 10:31:12 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 27 Oct 2021 10:31:12 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac [v2]
In-Reply-To: <JATrFwDsIpI4Oz0lpq8ZGftMT8oRK24rW5rvX7s99dc=.19988ef5-f5e3-417b-aaec-78511b6b2e52@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
 <HLIZqD2uCSFmxiLAnHXbTunMPvU78dCWzmydCKR7ZYI=.394e573e-a859-47e4-92cb-91d6f7f000b5@github.com>
 <iuWNGEIB1XeIFzKZJ8tVaAWwOVrkxDdSfR9uOg3BmPw=.5b2a4907-224c-4bfc-afab-97f158ba75b4@github.com>
 <-wjkwScXO_5VvlFJ-BfaS_3WTzhUd3CqP02cWH3iuLA=.06e63805-4193-4f9f-b89e-c43b58376392@github.com>
 <LWKJpTQBsu5IU3UVwA2p4itK5PQ7YlRLjbVKwo1SwZs=.7d675aa9-35d2-4691-9a28-907143cb4e8f@github.com>
 <JATrFwDsIpI4Oz0lpq8ZGftMT8oRK24rW5rvX7s99dc=.19988ef5-f5e3-417b-aaec-78511b6b2e52@github.com>
Message-ID: <QZaEezk_LS7j1hyv732-dWx4kN1uUkgYQPnZ45LDTVs=.1b223259-7907-4d92-b56a-16223e2ade3f@github.com>

On Wed, 27 Oct 2021 10:11:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Unfortunately the creation should be dine on EDT as well

Why? Neither component or frame has peers assigned, not like their status is being changed by another thread and they do not receive any events from EDT yet. Then what is the reason for moving component creation to EDT?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6104


From psadhukhan at openjdk.java.net  Wed Oct 27 12:53:26 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Oct 2021 12:53:26 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
Message-ID: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>

As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
It was seen from the logs that we have color mismatch in these tests.

For example, in PressedIcon test, we had following log

----------System.out:(1/75)----------
color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
----------System.err:(13/842)----------
java.lang.RuntimeException: Colors is different for scale=1!
	at PressedIconTest.main(PressedIconTest.java:97)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:833)

and JInternalFrame test, we had 
----------System.err:(15/939)----------
FRAME_COLOR Red: 255; Green: 200; Blue: 0
Pixel color Red: 55; Green: 55; Blue: 55
java.lang.RuntimeException: Internal frame is not correctly dragged!
	at bug8069348.main(bug8069348.java:96)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:833)

where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.

The awt tests that are failing seems to have different root cause and will be handled separately.

-------------

Commit messages:
 - 8276058: Some swing test fails on specific CI macos system
 - 8276058: Some swing test fails on specific CI macos system

Changes: https://git.openjdk.java.net/jdk/pull/6140/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6140&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276058
  Stats: 104 lines in 3 files changed: 59 ins; 7 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6140.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6140/head:pull/6140

PR: https://git.openjdk.java.net/jdk/pull/6140


From prr at openjdk.java.net  Wed Oct 27 16:42:21 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Oct 2021 16:42:21 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
In-Reply-To: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
Message-ID: <kfD-pJbZjCoAtLMsqMlGmciVDifPgUNmLSk2px5Xpn4=.1d63d0e8-2b55-4010-b5de-f34b5842fb4b@github.com>

On Wed, 27 Oct 2021 12:42:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
> It was seen from the logs that we have color mismatch in these tests.
> 
> For example, in PressedIcon test, we had following log
> 
> ----------System.out:(1/75)----------
> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
> ----------System.err:(13/842)----------
> java.lang.RuntimeException: Colors is different for scale=1!
> 	at PressedIconTest.main(PressedIconTest.java:97)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> 
> and JInternalFrame test, we had 
> ----------System.err:(15/939)----------
> FRAME_COLOR Red: 255; Green: 200; Blue: 0
> Pixel color Red: 55; Green: 55; Blue: 55
> java.lang.RuntimeException: Internal frame is not correctly dragged!
> 	at bug8069348.main(bug8069348.java:96)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> 
> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
> 
> The awt tests that are failing seems to have different root cause and will be handled separately.

test/jdk/javax/swing/JButton/8151303/PressedIconTest.java line 88:

> 86:         robot.waitForIdle();
> 87:         Color color = robot.getPixelColor(centerX-10, centerY-10);
> 88: 

So the problematic pattern is a mouse move to the location from which you subsequently capture a pixel?
I can see how on a compositing window manager that might be an issue as the cursor is part of the window
whereas on old X11 it isn't part of the root window .. but why isn't this ALWAYS an issue on macOS ?

I wonder how many other tests have the same issue ?

And is an offset of 10 enough ? Its a bit arbitrary and cursors could be a larger shape or different orientation ..

test/jdk/javax/swing/JButton/8151303/PressedIconTest.java line 93:

> 91:         BufferedImage img = robot.createScreenCapture(screen);
> 92:         javax.imageio.ImageIO.write(img, "png", new java.io.File("image.png"));
> 93: 

Are we writing the image or any other type of file  in the CWD in other tests ? 
Shouldn't this use TESTCLASSES or something like that ?

test/jdk/javax/swing/JButton/8151303/PressedIconTest.java line 107:

> 105:             throw new RuntimeException("Colors is different for scale=2!");
> 106:         }
> 107:         System.out.println("Test Passed");

Hmm .. the test tags are
 * @run main/othervm  PressedIconTest
 * @run main/othervm -Dsun.java2d.uiScale=2 PressedIconTest

What if the default scale is 2 ? 
Or on Windows it could be 1.25 ?
I don't see anything that restricts this test to macOS.

If you are going to explicitly test for 1 and 2 here, shouldn't we explicitly set it ?

And if you aren't then the test here needs to do something based on the actual scale.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From azvegint at openjdk.java.net  Wed Oct 27 17:42:16 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 27 Oct 2021 17:42:16 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
In-Reply-To: <kfD-pJbZjCoAtLMsqMlGmciVDifPgUNmLSk2px5Xpn4=.1d63d0e8-2b55-4010-b5de-f34b5842fb4b@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <kfD-pJbZjCoAtLMsqMlGmciVDifPgUNmLSk2px5Xpn4=.1d63d0e8-2b55-4010-b5de-f34b5842fb4b@github.com>
Message-ID: <Dwm3QY0eYzXm3ytAws8g8NKPyfgCt2CkT3567EbHNE8=.65fb2b26-67d2-4496-a1f4-5dcf6fecc441@github.com>

On Wed, 27 Oct 2021 16:33:27 GMT, Phil Race <prr at openjdk.org> wrote:

>> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
>> It was seen from the logs that we have color mismatch in these tests.
>> 
>> For example, in PressedIcon test, we had following log
>> 
>> ----------System.out:(1/75)----------
>> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
>> ----------System.err:(13/842)----------
>> java.lang.RuntimeException: Colors is different for scale=1!
>> 	at PressedIconTest.main(PressedIconTest.java:97)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> and JInternalFrame test, we had 
>> ----------System.err:(15/939)----------
>> FRAME_COLOR Red: 255; Green: 200; Blue: 0
>> Pixel color Red: 55; Green: 55; Blue: 55
>> java.lang.RuntimeException: Internal frame is not correctly dragged!
>> 	at bug8069348.main(bug8069348.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
>> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
>> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
>> 
>> The awt tests that are failing seems to have different root cause and will be handled separately.
>
> test/jdk/javax/swing/JButton/8151303/PressedIconTest.java line 88:
> 
>> 86:         robot.waitForIdle();
>> 87:         Color color = robot.getPixelColor(centerX-10, centerY-10);
>> 88: 
> 
> So the problematic pattern is a mouse move to the location from which you subsequently capture a pixel?
> I can see how on a compositing window manager that might be an issue as the cursor is part of the window
> whereas on old X11 it isn't part of the root window .. but why isn't this ALWAYS an issue on macOS ?
> 
> I wonder how many other tests have the same issue ?
> 
> And is an offset of 10 enough ? Its a bit arbitrary and cursors could be a larger shape or different orientation ..

Robot doesn't capture a cursor, we have a `Robot#createScreenCapture` spec which clearly says that:

> Creates an image containing pixels read from the screen.  
> **This image does not include the mouse cursor.**

Both `Robot#createScreenCapture` and `Robot#getPixelColor` are using the same `CRobot#nativeGetScreenPixels` method for getting pixel data.


<details>
  <summary>So the mouse cursor should not affect `Robot#getPixelColor`, this is easy to check on practice</summary>  


import javax.imageio.ImageIO;
import java.awt.AWTException;
import java.awt.Color;
import java.awt.Frame;
import java.awt.Rectangle;
import java.awt.Robot;
import java.awt.image.BufferedImage;
import java.io.File;
import java.io.IOException;

public class CursorTest {
    public static void main(String[] args) throws AWTException, IOException {
        Robot robot = new Robot();

        Frame frame = new Frame();
        frame.setBackground(Color.red);
        frame.setUndecorated(true);

        Rectangle rectangle = new Rectangle(100,100,50,50);
        frame.setBounds(rectangle);
        frame.setVisible(true);

        robot.waitForIdle();
        robot.delay(1000);
        robot.mouseMove(rectangle.x + 5, rectangle.y + 5);
        robot.waitForIdle();

        System.err.println("Moved");
        robot.waitForIdle();
        robot.delay(3000);

        System.err.println("Starting");

        BufferedImage screenCapture = robot.createScreenCapture(rectangle);
        ImageIO.write(screenCapture, "png", new File("/tmp/out.png"));

        for (int i = rectangle.x; i < rectangle.x + rectangle.width; i++) {
            for (int j = rectangle.y; j < rectangle.y + rectangle.height; j++) {
                Color pixelColor = robot.getPixelColor(i, j);
                if (!pixelColor.equals(Color.red)) {
                    System.err.println(pixelColor);
                    frame.dispose();
                    throw new RuntimeException("Unexpected pixel color " + pixelColor);
                }
            }
        }

        System.err.println("Finished");
        frame.dispose();
    }
}

  
</details>

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From prr at openjdk.java.net  Wed Oct 27 17:58:10 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Oct 2021 17:58:10 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
In-Reply-To: <Dwm3QY0eYzXm3ytAws8g8NKPyfgCt2CkT3567EbHNE8=.65fb2b26-67d2-4496-a1f4-5dcf6fecc441@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <kfD-pJbZjCoAtLMsqMlGmciVDifPgUNmLSk2px5Xpn4=.1d63d0e8-2b55-4010-b5de-f34b5842fb4b@github.com>
 <Dwm3QY0eYzXm3ytAws8g8NKPyfgCt2CkT3567EbHNE8=.65fb2b26-67d2-4496-a1f4-5dcf6fecc441@github.com>
Message-ID: <SxnjuoL7SNi9GdM_Oc94Ikj4IyDxX57CnHGZarrLvvk=.bf8f6d95-2156-4ef2-b05d-1c495fd4f869@github.com>

On Wed, 27 Oct 2021 17:39:04 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> test/jdk/javax/swing/JButton/8151303/PressedIconTest.java line 88:
>> 
>>> 86:         robot.waitForIdle();
>>> 87:         Color color = robot.getPixelColor(centerX-10, centerY-10);
>>> 88: 
>> 
>> So the problematic pattern is a mouse move to the location from which you subsequently capture a pixel?
>> I can see how on a compositing window manager that might be an issue as the cursor is part of the window
>> whereas on old X11 it isn't part of the root window .. but why isn't this ALWAYS an issue on macOS ?
>> 
>> I wonder how many other tests have the same issue ?
>> 
>> And is an offset of 10 enough ? Its a bit arbitrary and cursors could be a larger shape or different orientation ..
>
> Robot doesn't capture a cursor, we have a `Robot#createScreenCapture` spec which clearly says that:
> 
>> Creates an image containing pixels read from the screen.  
>> **This image does not include the mouse cursor.**
> 
> Both `Robot#createScreenCapture` and `Robot#getPixelColor` are using the same `CRobot#nativeGetScreenPixels` method for getting pixel data.
> 
> 
> <details>
>   <summary>So the mouse cursor should not affect `Robot#getPixelColor`, this is easy to check on practice</summary>  
> 
> 
> import javax.imageio.ImageIO;
> import java.awt.AWTException;
> import java.awt.Color;
> import java.awt.Frame;
> import java.awt.Rectangle;
> import java.awt.Robot;
> import java.awt.image.BufferedImage;
> import java.io.File;
> import java.io.IOException;
> 
> public class CursorTest {
>     public static void main(String[] args) throws AWTException, IOException {
>         Robot robot = new Robot();
> 
>         Frame frame = new Frame();
>         frame.setBackground(Color.red);
>         frame.setUndecorated(true);
> 
>         Rectangle rectangle = new Rectangle(100,100,50,50);
>         frame.setBounds(rectangle);
>         frame.setVisible(true);
> 
>         robot.waitForIdle();
>         robot.delay(1000);
>         robot.mouseMove(rectangle.x + 5, rectangle.y + 5);
>         robot.waitForIdle();
> 
>         System.err.println("Moved");
>         robot.waitForIdle();
>         robot.delay(3000);
> 
>         System.err.println("Starting");
> 
>         BufferedImage screenCapture = robot.createScreenCapture(rectangle);
>         ImageIO.write(screenCapture, "png", new File("/tmp/out.png"));
> 
>         for (int i = rectangle.x; i < rectangle.x + rectangle.width; i++) {
>             for (int j = rectangle.y; j < rectangle.y + rectangle.height; j++) {
>                 Color pixelColor = robot.getPixelColor(i, j);
>                 if (!pixelColor.equals(Color.red)) {
>                     System.err.println(pixelColor);
>                     frame.dispose();
>                     throw new RuntimeException("Unexpected pixel color " + pixelColor);
>                 }
>             }
>         }
> 
>         System.err.println("Finished");
>         frame.dispose();
>     }
> }
> 
>   
> </details>

Ok .. yet Prasanta said it did ..
"The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to."

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Thu Oct 28 01:28:12 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Oct 2021 01:28:12 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
In-Reply-To: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
Message-ID: <fH88FC-8Epa8qOVzE7cf2B8z7Wq3S_YdG66c8EBiln8=.4325f2d2-40ba-4bd0-97ef-f002650f32bc@github.com>

On Wed, 27 Oct 2021 12:42:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
> It was seen from the logs that we have color mismatch in these tests.
> 
> For example, in PressedIcon test, we had following log
> 
> ----------System.out:(1/75)----------
> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
> ----------System.err:(13/842)----------
> java.lang.RuntimeException: Colors is different for scale=1!
> 	at PressedIconTest.main(PressedIconTest.java:97)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> 
> and JInternalFrame test, we had 
> ----------System.err:(15/939)----------
> FRAME_COLOR Red: 255; Green: 200; Blue: 0
> Pixel color Red: 55; Green: 55; Blue: 55
> java.lang.RuntimeException: Internal frame is not correctly dragged!
> 	at bug8069348.main(bug8069348.java:96)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> 
> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
> 
> The awt tests that are failing seems to have different root cause and will be handled separately.

Since it is unlikely to be the issue related to the cursor, it will be better to check what could be root cause. Is it possible that CI system is configured in some different way as others? Th 55/55/55 color looks similar to the background of the app in the dark mode in macOS, could it be the reason?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Thu Oct 28 01:40:13 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Oct 2021 01:40:13 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac [v2]
In-Reply-To: <QZaEezk_LS7j1hyv732-dWx4kN1uUkgYQPnZ45LDTVs=.1b223259-7907-4d92-b56a-16223e2ade3f@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
 <HLIZqD2uCSFmxiLAnHXbTunMPvU78dCWzmydCKR7ZYI=.394e573e-a859-47e4-92cb-91d6f7f000b5@github.com>
 <iuWNGEIB1XeIFzKZJ8tVaAWwOVrkxDdSfR9uOg3BmPw=.5b2a4907-224c-4bfc-afab-97f158ba75b4@github.com>
 <-wjkwScXO_5VvlFJ-BfaS_3WTzhUd3CqP02cWH3iuLA=.06e63805-4193-4f9f-b89e-c43b58376392@github.com>
 <LWKJpTQBsu5IU3UVwA2p4itK5PQ7YlRLjbVKwo1SwZs=.7d675aa9-35d2-4691-9a28-907143cb4e8f@github.com>
 <JATrFwDsIpI4Oz0lpq8ZGftMT8oRK24rW5rvX7s99dc=.19988ef5-f5e3-417b-aaec-78511b6b2e52@github.com>
 <QZaEezk_LS7j1hyv732-dWx4kN1uUkgYQPnZ45LDTVs=.1b223259-7907-4d92-b56a-16223e2ade3f@github.com>
Message-ID: <heJOJRZAjuc5zyQOFfUSBjJP-_payL4OGCINgxSCiPM=.d63032aa-7da9-48e0-ae9f-0387dfd05772@github.com>

On Wed, 27 Oct 2021 10:28:32 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Unfortunately the creation should be dine on EDT as well
>
>> Unfortunately the creation should be dine on EDT as well
> 
> Why? Neither component or frame has peers assigned, not like their status is being changed by another thread and they do not receive any events from EDT yet. Then what is the reason for moving component creation to EDT?

It does not relate to the peers(actually peers and awt components can be used on different threads), it is just a requirement for the Swing library all its api should be used only on the EDT, otherwise too many things can go wrong, which includes the simple visibility across the threads, and more complex out of order events execution - when you created a component on main thread it can post an event to EDT, and that event will be executed in parallel with your code on main.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6104


From kizune at openjdk.java.net  Thu Oct 28 02:01:08 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 28 Oct 2021 02:01:08 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac [v2]
In-Reply-To: <heJOJRZAjuc5zyQOFfUSBjJP-_payL4OGCINgxSCiPM=.d63032aa-7da9-48e0-ae9f-0387dfd05772@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
 <HLIZqD2uCSFmxiLAnHXbTunMPvU78dCWzmydCKR7ZYI=.394e573e-a859-47e4-92cb-91d6f7f000b5@github.com>
 <iuWNGEIB1XeIFzKZJ8tVaAWwOVrkxDdSfR9uOg3BmPw=.5b2a4907-224c-4bfc-afab-97f158ba75b4@github.com>
 <-wjkwScXO_5VvlFJ-BfaS_3WTzhUd3CqP02cWH3iuLA=.06e63805-4193-4f9f-b89e-c43b58376392@github.com>
 <LWKJpTQBsu5IU3UVwA2p4itK5PQ7YlRLjbVKwo1SwZs=.7d675aa9-35d2-4691-9a28-907143cb4e8f@github.com>
 <JATrFwDsIpI4Oz0lpq8ZGftMT8oRK24rW5rvX7s99dc=.19988ef5-f5e3-417b-aaec-78511b6b2e52@github.com>
 <QZaEezk_LS7j1hyv732-dWx4kN1uUkgYQPnZ45LDTVs=.1b223259-7907-4d92-b56a-16223e2ade3f@github.com>
 <heJOJRZAjuc5zyQOFfUSBjJP-_payL4OGCINgxSCiPM=.d63032aa-7da9-48e0-ae9f-0387dfd05772@github.com>
Message-ID: <dbyc94TD-RfkOyT3f0UlvsdYym7FPR6tRzbKSh7huTU=.dc68ddeb-7a7c-498d-99c1-ee89fe733e43@github.com>

On Thu, 28 Oct 2021 01:36:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Unfortunately the creation should be dine on EDT as well
>> 
>> Why? Neither component or frame has peers assigned, not like their status is being changed by another thread and they do not receive any events from EDT yet. Then what is the reason for moving component creation to EDT?
>
> It does not relate to the peers(actually peers and awt components can be used on different threads), it is just a requirement for the Swing library all its api should be used only on the EDT, otherwise too many things can go wrong, which includes the simple visibility across the threads, and more complex out of order events execution - when you created a component on main thread it can post an event to EDT, and that event will be executed in parallel with your code on main.

Creation of component like instantiation? That seems to be wrong. We always had the notion of realized component vs non-realized. Before component is added to the realized container or becomes realized on its own it should not post any events on EDT. What possibly can newly created JButton want to do do with EDT? How does the instantiation on one thread can cause problem on another thread if it does not interact with that thread until later on which constitutes the Happens Before scenario. Or did we just threw the realized vs non-realized concept out of the window? If so does not it renders all the Swing code written before that change functionally incompatible and generally unstable? I have so many questions now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6104


From prr at openjdk.java.net  Thu Oct 28 03:16:17 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 28 Oct 2021 03:16:17 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
In-Reply-To: <fH88FC-8Epa8qOVzE7cf2B8z7Wq3S_YdG66c8EBiln8=.4325f2d2-40ba-4bd0-97ef-f002650f32bc@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <fH88FC-8Epa8qOVzE7cf2B8z7Wq3S_YdG66c8EBiln8=.4325f2d2-40ba-4bd0-97ef-f002650f32bc@github.com>
Message-ID: <Kl4ULB5Vn4lMf5Kf0FYM01xOwgLrmQydUrrmQSyXfiA=.342ae452-81c1-4940-a56f-a0c2a4d0fdf3@github.com>

On Thu, 28 Oct 2021 01:25:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>Since it is unlikely to be the issue related to the cursor, 
>it will be better to check what could be root cause. 

Well .. the cursor issue is a suggestion for root cause [*] Do you have any other ideas ? I mean other than ...

>  Is it possible that CI system is configured in some different way as others? 

Not that I can see and definitely not dark mode. Permanent light mode.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From psadhukhan at openjdk.java.net  Thu Oct 28 06:37:42 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 28 Oct 2021 06:37:42 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
In-Reply-To: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
Message-ID: <ViWvik3hBBvSMxjo9WBEFCBrIqM1Flm2HyPPDaOKcRg=.af641dbf-3bff-40ac-b139-e8b873fb90e9@github.com>

On Wed, 27 Oct 2021 12:42:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
> It was seen from the logs that we have color mismatch in these tests.
> 
> For example, in PressedIcon test, we had following log
> 
> ----------System.out:(1/75)----------
> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
> ----------System.err:(13/842)----------
> java.lang.RuntimeException: Colors is different for scale=1!
> 	at PressedIconTest.main(PressedIconTest.java:97)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> 
> and JInternalFrame test, we had 
> ----------System.err:(15/939)----------
> FRAME_COLOR Red: 255; Green: 200; Blue: 0
> Pixel color Red: 55; Green: 55; Blue: 55
> java.lang.RuntimeException: Internal frame is not correctly dragged!
> 	at bug8069348.main(bug8069348.java:96)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> 
> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
> 
> The awt tests that are failing seems to have different root cause and will be handled separately.

awt test fix also added

FullScreenInsets fails with incorrect pixel so added tolerance
----------System.err:(15/899)----------
Incorrect pixel at 298x246 : ff00fe00 ,expected : ff00ff00
Incorrect pixel at 298x246 : fffe0000 ,expected : ffff0000
java.lang.RuntimeException: Test failed
	at FullScreenInsets.main(FullScreenInsets.java:93)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:833)

MakeWindowAlwaysOnTop  fails with same root cause so used same swing tactics of x-10, y-10
----------System.out:(1/39)----------
Color = java.awt.Color[r=55,g=55,b=55]
----------System.err:(13/909)----------
java.lang.RuntimeException: Test FAILED: unknown window is on top of the frame
	at MakeWindowAlwaysOnTop.main(MakeWindowAlwaysOnTop.java:120)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:833)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From psadhukhan at openjdk.java.net  Thu Oct 28 06:37:40 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 28 Oct 2021 06:37:40 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
Message-ID: <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>

> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
> It was seen from the logs that we have color mismatch in these tests.
> 
> For example, in PressedIcon test, we had following log
> 
> ----------System.out:(1/75)----------
> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
> ----------System.err:(13/842)----------
> java.lang.RuntimeException: Colors is different for scale=1!
> 	at PressedIconTest.main(PressedIconTest.java:97)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> 
> and JInternalFrame test, we had 
> ----------System.err:(15/939)----------
> FRAME_COLOR Red: 255; Green: 200; Blue: 0
> Pixel color Red: 55; Green: 55; Blue: 55
> java.lang.RuntimeException: Internal frame is not correctly dragged!
> 	at bug8069348.main(bug8069348.java:96)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> 
> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
> 
> The awt tests that are failing seems to have different root cause and will be handled separately.

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - awt test fix added
 - awt test fix added

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6140/files
  - new: https://git.openjdk.java.net/jdk/pull/6140/files/cf3fc29f..077eb520

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6140&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6140&range=00-01

  Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6140.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6140/head:pull/6140

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Thu Oct 28 08:14:12 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Oct 2021 08:14:12 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
In-Reply-To: <Kl4ULB5Vn4lMf5Kf0FYM01xOwgLrmQydUrrmQSyXfiA=.342ae452-81c1-4940-a56f-a0c2a4d0fdf3@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <fH88FC-8Epa8qOVzE7cf2B8z7Wq3S_YdG66c8EBiln8=.4325f2d2-40ba-4bd0-97ef-f002650f32bc@github.com>
 <Kl4ULB5Vn4lMf5Kf0FYM01xOwgLrmQydUrrmQSyXfiA=.342ae452-81c1-4940-a56f-a0c2a4d0fdf3@github.com>
Message-ID: <3zAKQMPRO0Pp6KRVYWEJybgBAE8uy6wff1w5klsLEuE=.24bdd200-e7de-4d88-bbf7-9c3ea57bf3f1@github.com>

On Thu, 28 Oct 2021 03:13:21 GMT, Phil Race <prr at openjdk.org> wrote:

> Well .. the cursor issue is a suggestion for root cause [*] Do you have any other ideas ? I mean other than ...

As noted above our spec mention that the cursor should not be present on the screenshot, and we use the appropriate native API to achieve this. It is hard to say why it does not work, but since the problem is consistent which is great, then the best way to investigate it is by connecting to the system and debugging the problem.

 * Since in some cases the getPixelColor() method is used it could be related to the https://github.com/openjdk/jdk/pull/5864, where I have proved that this method may return the garbage instead of correct data. Without that fix the usage of that method is UB. But as mentioned in some other JBS, it may not be enough, probably some other bugs exist.
 * Maybe it is a timing issue like this https://github.com/openjdk/jdk/pull/5373 but in OGL this time and we draw a garbage for a moment when we did a screenshot.
 * it could also be related to the video card, so on some systems, we use one code path and the other on another system. By using metal we can prove that the bug is in the robot. And by using the native app we can prove is a bug in the robot implementation or not.
 * It also could be related to the system DPI/screen resolution, how it will work if the test will run using scale=1?

> The awt tests that are failing seems to have different root cause and will be handled separately.

In general, it does not look like a test issue, more like a product bug. So the root cause of this particular issue should be investigated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From myano at openjdk.java.net  Thu Oct 28 08:27:44 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Thu, 28 Oct 2021 08:27:44 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
Message-ID: <m03hRl4ZShG3fKMPO25xNatS9-rCp8Wpgg2Sg_YdfRA=.3528be36-1593-4153-b55d-caf57678eeac@github.com>

> Could you please review the 8275715 bug fixes?
> 
> I think D3DScreenUpdateManager posts unnecessary PaintEvent during processing PaintEvent. When the validate method is called from createGraphics, repaintPeerTarget should not be called.

Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:

  8275715: D3D pipeline processes multiple PaintEvent at initial drawing

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6064/files
  - new: https://git.openjdk.java.net/jdk/pull/6064/files/fcf36233..26dcc7b4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6064&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6064&range=00-01

  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6064.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6064/head:pull/6064

PR: https://git.openjdk.java.net/jdk/pull/6064


From myano at openjdk.java.net  Thu Oct 28 08:27:51 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Thu, 28 Oct 2021 08:27:51 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <-hj0v7RZ0HPpP9GND5csZsZ1Vz7oxaufOAC0-ZygtwM=.6a5ae7a8-52d6-4e3e-a166-2fae2c23dbe0@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <-hj0v7RZ0HPpP9GND5csZsZ1Vz7oxaufOAC0-ZygtwM=.6a5ae7a8-52d6-4e3e-a166-2fae2c23dbe0@github.com>
Message-ID: <cTqTWZsK6uJI_Kw9nUymKQnYxxzWBRrk52qJAKpAc9I=.18f7dffd-3ebe-4bd0-bc2f-d61b55437036@github.com>

On Sat, 23 Oct 2021 19:40:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8275715: D3D pipeline processes multiple PaintEvent at initial drawing
>
> src/java.desktop/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java line 455:
> 
>> 453:                             rq.unlock();
>> 454:                         }
>> 455:                     } else if (!validate(sd, true)) {
> 
> The comment below says that "the surface will also trigger a repaint", will it be possible we will trigger it inside validate here and then later inside "replaceSurfaceDataLater"?

Yes, this run() is called on "D3D Screen Updater" thread. It is reasonable that a new PaintEvent is posted when SurfaceData is replaced on this thread. I would limit posting new PaintEvent via createGraphics() only.

> test/jdk/sun/java2d/DirectX/MultiPaintEventTest/MultiPaintEventTest.java line 36:
> 
>> 34: public class MultiPaintEventTest extends Canvas {
>> 35: 
>> 36:     private int count = 0;
> 
> Some synchronization is needed, the field is updated on EDT and checked on the main thread.

I fixed a test as it was pointed out to me.

> test/jdk/sun/java2d/DirectX/MultiPaintEventTest/MultiPaintEventTest.java line 75:
> 
>> 73:                 throw new RuntimeException("Processed unnecessary paint().");
>> 74:             }
>> 75:         } catch (InterruptedException ex) {
> 
> Do not ignore an exception

I fixed a test as it was pointed out to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6064


From serb at openjdk.java.net  Thu Oct 28 09:00:17 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Oct 2021 09:00:17 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac [v2]
In-Reply-To: <dbyc94TD-RfkOyT3f0UlvsdYym7FPR6tRzbKSh7huTU=.dc68ddeb-7a7c-498d-99c1-ee89fe733e43@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
 <HLIZqD2uCSFmxiLAnHXbTunMPvU78dCWzmydCKR7ZYI=.394e573e-a859-47e4-92cb-91d6f7f000b5@github.com>
 <iuWNGEIB1XeIFzKZJ8tVaAWwOVrkxDdSfR9uOg3BmPw=.5b2a4907-224c-4bfc-afab-97f158ba75b4@github.com>
 <-wjkwScXO_5VvlFJ-BfaS_3WTzhUd3CqP02cWH3iuLA=.06e63805-4193-4f9f-b89e-c43b58376392@github.com>
 <LWKJpTQBsu5IU3UVwA2p4itK5PQ7YlRLjbVKwo1SwZs=.7d675aa9-35d2-4691-9a28-907143cb4e8f@github.com>
 <JATrFwDsIpI4Oz0lpq8ZGftMT8oRK24rW5rvX7s99dc=.19988ef5-f5e3-417b-aaec-78511b6b2e52@github.com>
 <QZaEezk_LS7j1hyv732-dWx4kN1uUkgYQPnZ45LDTVs=.1b223259-7907-4d92-b56a-16223e2ade3f@github.com>
 <heJOJRZAjuc5zyQOFfUSBjJP-_payL4OGCINgxSCiPM=.d63032aa-7da9-48e0-ae9f-0387dfd05772@github.com>
 <dbyc94TD-RfkOyT3f0UlvsdYym7FPR6tRzbKSh7huTU=.dc68ddeb-7a7c-498d-99c1-ee89fe733e43@github.com>
Message-ID: <J3wXoI0OYewaHmn0-dErydBDLZFxBo-kRBRI9mWBHs8=.8f210c19-a0f2-4652-837a-d44c66f5888e@github.com>

On Thu, 28 Oct 2021 01:58:33 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Creation of component like instantiation?

Yes, every access to the Swing components:
https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/package-summary.html

> That seems to be wrong. We always had the notion of realized component vs non-realized. Before a component is added to the realized container or becomes realized on its own it should not post any events on EDT. 

I think that was changed 15 years ago or so somewhere before the release of the JDK5 the spec was updated:
https://bugs.openjdk.java.net/browse/JDK-5042754?focusedCommentId=12216623&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12216623

And the text about "realized component" was removed from the tutorial somewhere in 2004, so we even do not use this term.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6104


From serb at openjdk.java.net  Thu Oct 28 09:07:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Oct 2021 09:07:14 GMT
Subject: RFR: 8275715: D3D pipeline processes multiple PaintEvent at
 initial drawing [v2]
In-Reply-To: <cTqTWZsK6uJI_Kw9nUymKQnYxxzWBRrk52qJAKpAc9I=.18f7dffd-3ebe-4bd0-bc2f-d61b55437036@github.com>
References: <U_TCA7H0bZg-RIFiKMEwQtigLzgEi1N6uOAVDE7lOI4=.64ded3df-54c2-487f-8607-83fe329eed69@github.com>
 <-hj0v7RZ0HPpP9GND5csZsZ1Vz7oxaufOAC0-ZygtwM=.6a5ae7a8-52d6-4e3e-a166-2fae2c23dbe0@github.com>
 <cTqTWZsK6uJI_Kw9nUymKQnYxxzWBRrk52qJAKpAc9I=.18f7dffd-3ebe-4bd0-bc2f-d61b55437036@github.com>
Message-ID: <aZX6pJkrGOTYLlAHRl9WlEGtoahiInx4QzelDWpV2b0=.c9a736f9-5dd5-4382-8513-94a0233105dc@github.com>

On Thu, 28 Oct 2021 08:24:46 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> src/java.desktop/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java line 455:
>> 
>>> 453:                             rq.unlock();
>>> 454:                         }
>>> 455:                     } else if (!validate(sd, true)) {
>> 
>> The comment below says that "the surface will also trigger a repaint", will it be possible we will trigger it inside validate here and then later inside "replaceSurfaceDataLater"?
>
> Yes, this run() is called on "D3D Screen Updater" thread. It is reasonable that a new PaintEvent is posted when SurfaceData is replaced on this thread. I would limit posting new PaintEvent via createGraphics() only.

Probably I should clarify my question, you added a parameter to the validate method and pass the "true" so the "validate" method will post a paint event, but just a few lines below there is a comment that the next code line "sd.getPeer().replaceSurfaceDataLater();" also will post an event. Is the comment outdated, or we will post two of them?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6064


From kizune at openjdk.java.net  Thu Oct 28 09:24:09 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 28 Oct 2021 09:24:09 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac [v2]
In-Reply-To: <J3wXoI0OYewaHmn0-dErydBDLZFxBo-kRBRI9mWBHs8=.8f210c19-a0f2-4652-837a-d44c66f5888e@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
 <HLIZqD2uCSFmxiLAnHXbTunMPvU78dCWzmydCKR7ZYI=.394e573e-a859-47e4-92cb-91d6f7f000b5@github.com>
 <iuWNGEIB1XeIFzKZJ8tVaAWwOVrkxDdSfR9uOg3BmPw=.5b2a4907-224c-4bfc-afab-97f158ba75b4@github.com>
 <-wjkwScXO_5VvlFJ-BfaS_3WTzhUd3CqP02cWH3iuLA=.06e63805-4193-4f9f-b89e-c43b58376392@github.com>
 <LWKJpTQBsu5IU3UVwA2p4itK5PQ7YlRLjbVKwo1SwZs=.7d675aa9-35d2-4691-9a28-907143cb4e8f@github.com>
 <JATrFwDsIpI4Oz0lpq8ZGftMT8oRK24rW5rvX7s99dc=.19988ef5-f5e3-417b-aaec-78511b6b2e52@github.com>
 <QZaEezk_LS7j1hyv732-dWx4kN1uUkgYQPnZ45LDTVs=.1b223259-7907-4d92-b56a-16223e2ade3f@github.com>
 <heJOJRZAjuc5zyQOFfUSBjJP-_payL4OGCINgxSCiPM=.d63032aa-7da9-48e0-ae9f-0387dfd05772@github.com>
 <dbyc94TD-RfkOyT3f0UlvsdYym7FPR6tRzbKSh7huTU=.dc68ddeb-7a7c-498d-99c1-ee89fe733e43@github.com>
 <J3wXoI0OYewaHmn0-dErydBDLZFxBo-kRBRI9mWBHs8=.8f210c19-a0f2-4652-837a-d44c66f5888e@github.com>
Message-ID: <oOgwINMz6qMCCdMZzXR7CRmz5TSjtHCe6677q9o_hC4=.fa6541aa-142a-4f7b-b853-f34ec43ceaf8@github.com>

On Thu, 28 Oct 2021 08:57:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I think that was changed 15 years ago or so somewhere before the release of the JDK5 the spec was updated

Ok, i will fix that in this particular test for the sake of getting a closure on it but it seems wrong to me on so many levels. And it is no surprise so many automated Swing tests are failing intermittently  - they were written according the old notion of the Swing component lifecycle and was never updated to reflect the backwards incompatible change we accidentally did. Shame. But that's a topic to discuss and dig deeper later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6104


From myano at openjdk.java.net  Thu Oct 28 09:38:33 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Thu, 28 Oct 2021 09:38:33 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException
Message-ID: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>

Could you please review the 8262297 bug fixes?

In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.

-------------

Commit messages:
 - 8262297: ImageIO.write() method will throw IndexOutOfBoundsException

Changes: https://git.openjdk.java.net/jdk/pull/6151/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6151&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262297
  Stats: 96 lines in 4 files changed: 71 ins; 0 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6151.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6151/head:pull/6151

PR: https://git.openjdk.java.net/jdk/pull/6151


From kizune at openjdk.java.net  Thu Oct 28 09:47:44 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 28 Oct 2021 09:47:44 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac [v3]
In-Reply-To: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
Message-ID: <ofIFdTzW7sfrx6RG3JohvCLh4fNbWjM1KnnCaf1TywA=.3941f3bd-593a-40b1-b464-09f5896dc608@github.com>

> Moved Swing component modification to the EDT.
> Increased wait time for popup to show up.
> Made checking variabled volatile.
> Generic code cleanup.
> Removed the test from ProblemList.txt

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Moved components instantiation to the EDT

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6104/files
  - new: https://git.openjdk.java.net/jdk/pull/6104/files/f409cf19..1f69582f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6104&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6104&range=01-02

  Stats: 55 lines in 1 file changed: 19 ins; 10 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6104.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6104/head:pull/6104

PR: https://git.openjdk.java.net/jdk/pull/6104


From psadhukhan at openjdk.java.net  Thu Oct 28 12:58:28 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 28 Oct 2021 12:58:28 GMT
Subject: RFR: 8276110: Problemlist javax/swing/JMenu/4515762/bug4515762.java
 for macos12
Message-ID: <e7mLrblnj_y839clx36-ALBTPLeCVLdlR6xLGBe93LQ=.032b7b72-3ebe-4b1f-bb92-4139584e099a@github.com>

javax/swing/JMenu/4515762/bug4515762.java is failing in macos12 due to same root cause as in JDK-8273520 and JDK-8273506 so problemlist it till it is fixed.

-------------

Commit messages:
 - 8276110: Problemlist javax/swing/JMenu/4515762/bug4515762.java for macos12
 - 8276110: Problemlist javax/swing/JMenu/4515762/bug4515762.java for macos12

Changes: https://git.openjdk.java.net/jdk/pull/6155/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6155&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276110
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6155.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6155/head:pull/6155

PR: https://git.openjdk.java.net/jdk/pull/6155


From azvegint at openjdk.java.net  Thu Oct 28 13:32:26 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 28 Oct 2021 13:32:26 GMT
Subject: RFR: 8079267: [TEST_BUG] Test
 java/awt/Frame/MiscUndecorated/RepaintTest.java fails
Message-ID: <D3GP12GLPR9xzPb5FWN42g_HZkqUTUKdgBabiiJOECA=.800914e0-274f-405a-becd-fdd1a9271d1c@github.com>

This test does not fail on Windows and does fail on Linux. 

After de-iconification we expect to see the button focused:
![image](https://user-images.githubusercontent.com/77687766/139171852-54413dba-d58a-46d4-ab83-59d93868e287.png)

Actual look:
![image](https://user-images.githubusercontent.com/77687766/139171775-80e64e58-c49d-489a-8fe0-fb0640fc3be9.png)

Button loses focus on `frame.to Front()` call, after its removal test passes. There is an [open issue](https://bugs.openjdk.java.net/browse/JDK-7156130) for this.


Some cleanup was also made. Testing is green for all platforms.


I am unable to reproduce [8266244 / macosx-aarch64](https://bugs.openjdk.java.net/browse/JDK-8266244), however it is not removed from the problem list due to its intermittent nature which needs more time to investigate.

-------------

Commit messages:
 - linux fix
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/6157/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6157&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8079267
  Stats: 47 lines in 2 files changed: 14 ins; 24 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6157.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6157/head:pull/6157

PR: https://git.openjdk.java.net/jdk/pull/6157


From azvegint at openjdk.java.net  Thu Oct 28 13:44:14 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 28 Oct 2021 13:44:14 GMT
Subject: RFR: 8276110: Problemlist
 javax/swing/JMenu/4515762/bug4515762.java for macos12
In-Reply-To: <e7mLrblnj_y839clx36-ALBTPLeCVLdlR6xLGBe93LQ=.032b7b72-3ebe-4b1f-bb92-4139584e099a@github.com>
References: <e7mLrblnj_y839clx36-ALBTPLeCVLdlR6xLGBe93LQ=.032b7b72-3ebe-4b1f-bb92-4139584e099a@github.com>
Message-ID: <RhL3OG6Azfxob-6KQSriijxhysGMJIjy_6loVUSRZvY=.48075687-0be9-46f5-a3d5-ab24ec82ba85@github.com>

On Thu, 28 Oct 2021 12:47:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/JMenu/4515762/bug4515762.java is failing in macos12 due to same root cause as in JDK-8273520 and JDK-8273506 so problemlist it till it is fixed.

Marked as reviewed by azvegint (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6155


From alanb at openjdk.java.net  Thu Oct 28 14:33:14 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 28 Oct 2021 14:33:14 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException
In-Reply-To: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
Message-ID: <0OrjZzeb7XifWJIH2jmrFAXflWPbagiJN7QvT8LA7XU=.dfb665f3-70c7-40c6-ba19-5b945337c446@github.com>

On Thu, 28 Oct 2021 09:29:13 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the 8262297 bug fixes?
> 
> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.

src/java.base/share/classes/java/io/RandomAccessFile.java line 558:

> 556:      * @throws     IndexOutOfBoundsException If {@code off} is negative,
> 557:      *             {@code len} is negative, or {@code len} is greater than
> 558:      *             {@code b.length - off}

The IOOBE is specified in the super interface, it's just not shown in the javadoc because it's a runtime exception. So I think what you want here is:

@throws IndexOutOfBoundsException  {@inheritDoc}

-------------

PR: https://git.openjdk.java.net/jdk/pull/6151


From psadhukhan at openjdk.java.net  Thu Oct 28 15:41:19 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 28 Oct 2021 15:41:19 GMT
Subject: Integrated: 8276110: Problemlist
 javax/swing/JMenu/4515762/bug4515762.java for macos12
In-Reply-To: <e7mLrblnj_y839clx36-ALBTPLeCVLdlR6xLGBe93LQ=.032b7b72-3ebe-4b1f-bb92-4139584e099a@github.com>
References: <e7mLrblnj_y839clx36-ALBTPLeCVLdlR6xLGBe93LQ=.032b7b72-3ebe-4b1f-bb92-4139584e099a@github.com>
Message-ID: <Vk57FlZq8qBATcg48C9VRFRi2ji0n1U7oVswnnxLyyY=.c4deaee8-0a00-4cad-9c19-ebac5125a570@github.com>

On Thu, 28 Oct 2021 12:47:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax/swing/JMenu/4515762/bug4515762.java is failing in macos12 due to same root cause as in JDK-8273520 and JDK-8273506 so problemlist it till it is fixed.

This pull request has now been integrated.

Changeset: c92f2305
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c92f23055724d2df462f64fc51e57f5a13f679bb
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8276110: Problemlist javax/swing/JMenu/4515762/bug4515762.java for macos12

Reviewed-by: azvegint

-------------

PR: https://git.openjdk.java.net/jdk/pull/6155


From kizune at openjdk.java.net  Thu Oct 28 17:11:25 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 28 Oct 2021 17:11:25 GMT
Subject: RFR: 8169474: KeyCharTest: Wrong number of key events: 0
Message-ID: <1fyY3RSMw8l0Xjcq3JFZ88qM7ert_bmJcnXPuW9qmNw=.09e8d110-40bd-4654-a268-40033ab93340@github.com>

When i reproduced the test failures locally on Ubuntu 18 it seems like AWT Frame
that appeared on the screen had not received focus and keyboard events went to the
Window Manager which ignored them for having no meaning in the current context.
Added explicit toFront and requestFocus calls so window gets focused.

-------------

Commit messages:
 - 8169474: KeyCharTest: Wrong number of key events: 0

Changes: https://git.openjdk.java.net/jdk/pull/6161/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6161&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8169474
  Stats: 34 lines in 2 files changed: 25 ins; 5 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6161.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6161/head:pull/6161

PR: https://git.openjdk.java.net/jdk/pull/6161


From psadhukhan at openjdk.java.net  Thu Oct 28 18:53:15 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 28 Oct 2021 18:53:15 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
Message-ID: <F4yU8VqKbDhyDAB3GDlwAP25jo8tSgbu9k9TlEirPWM=.ef54c9dc-10f8-487d-af0c-42e940dd1624@github.com>

On Thu, 28 Oct 2021 06:37:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
>> It was seen from the logs that we have color mismatch in these tests.
>> 
>> For example, in PressedIcon test, we had following log
>> 
>> ----------System.out:(1/75)----------
>> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
>> ----------System.err:(13/842)----------
>> java.lang.RuntimeException: Colors is different for scale=1!
>> 	at PressedIconTest.main(PressedIconTest.java:97)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> and JInternalFrame test, we had 
>> ----------System.err:(15/939)----------
>> FRAME_COLOR Red: 255; Green: 200; Blue: 0
>> Pixel color Red: 55; Green: 55; Blue: 55
>> java.lang.RuntimeException: Internal frame is not correctly dragged!
>> 	at bug8069348.main(bug8069348.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
>> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
>> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
>> 
>> The awt tests that are failing seems to have different root cause and will be handled separately.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - awt test fix added
>  - awt test fix added

I have attached 2 screen capture in JBS taken when PressedIconTest and JInternalFrame test failed and the screenshot at least in this machine shows presence of cursor.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Thu Oct 28 19:30:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Oct 2021 19:30:10 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac [v2]
In-Reply-To: <oOgwINMz6qMCCdMZzXR7CRmz5TSjtHCe6677q9o_hC4=.fa6541aa-142a-4f7b-b853-f34ec43ceaf8@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
 <HLIZqD2uCSFmxiLAnHXbTunMPvU78dCWzmydCKR7ZYI=.394e573e-a859-47e4-92cb-91d6f7f000b5@github.com>
 <iuWNGEIB1XeIFzKZJ8tVaAWwOVrkxDdSfR9uOg3BmPw=.5b2a4907-224c-4bfc-afab-97f158ba75b4@github.com>
 <-wjkwScXO_5VvlFJ-BfaS_3WTzhUd3CqP02cWH3iuLA=.06e63805-4193-4f9f-b89e-c43b58376392@github.com>
 <LWKJpTQBsu5IU3UVwA2p4itK5PQ7YlRLjbVKwo1SwZs=.7d675aa9-35d2-4691-9a28-907143cb4e8f@github.com>
 <JATrFwDsIpI4Oz0lpq8ZGftMT8oRK24rW5rvX7s99dc=.19988ef5-f5e3-417b-aaec-78511b6b2e52@github.com>
 <QZaEezk_LS7j1hyv732-dWx4kN1uUkgYQPnZ45LDTVs=.1b223259-7907-4d92-b56a-16223e2ade3f@github.com>
 <heJOJRZAjuc5zyQOFfUSBjJP-_payL4OGCINgxSCiPM=.d63032aa-7da9-48e0-ae9f-0387dfd05772@github.com>
 <dbyc94TD-RfkOyT3f0UlvsdYym7FPR6tRzbKSh7huTU=.dc68ddeb-7a7c-498d-99c1-ee89fe733e43@github.com>
 <J3wXoI0OYewaHmn0-dErydBDLZFxBo-kRBRI9mWBHs8=.8f210c19-a0f2-4652-837a-d44c66f5888e@github.com>
 <oOgwINMz6qMCCdMZzXR7CRmz5TSjtHCe667
 7q9o_hC4=.fa6541aa-142a-4f7b-b853-f34ec43ceaf8@github.com>
Message-ID: <EgoTPAifwXFieY6s52ai9R_hCdCPg1G4Ni3Yen3SaRM=.f43e5a58-3eca-4e5d-9042-1836a4e6025a@github.com>

On Thu, 28 Oct 2021 09:21:27 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>>> Creation of component like instantiation?
>> 
>> Yes, every access to the Swing components:
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/package-summary.html
>> 
>>> That seems to be wrong. We always had the notion of realized component vs non-realized. Before a component is added to the realized container or becomes realized on its own it should not post any events on EDT. 
>> 
>> I think that was changed 15 years ago or so somewhere before the release of the JDK5 the spec was updated:
>> https://bugs.openjdk.java.net/browse/JDK-5042754?focusedCommentId=12216623&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12216623
>> 
>> And the text about "realized component" was removed from the thread Swing tutorial somewhere in 2004, so we even do not use this term.
>
>> I think that was changed 15 years ago or so somewhere before the release of the JDK5 the spec was updated
> 
> Ok, i will fix that in this particular test for the sake of getting a closure on it but it seems wrong to me on so many levels. And it is no surprise so many automated Swing tests are failing intermittently  - they were written according the old notion of the Swing component lifecycle and was never updated to reflect the backwards incompatible change we accidentally did. Shame. But that's a topic to discuss and dig deeper later.

We did not change the behavior of the Swing, it works the same before and after that spec update. That tests were broken from the beginning and this is why they are unstable, and this is why the requirements were changed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6104


From serb at openjdk.java.net  Thu Oct 28 19:34:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Oct 2021 19:34:14 GMT
Subject: RFR: 8079267: [TEST_BUG] Test
 java/awt/Frame/MiscUndecorated/RepaintTest.java fails
In-Reply-To: <D3GP12GLPR9xzPb5FWN42g_HZkqUTUKdgBabiiJOECA=.800914e0-274f-405a-becd-fdd1a9271d1c@github.com>
References: <D3GP12GLPR9xzPb5FWN42g_HZkqUTUKdgBabiiJOECA=.800914e0-274f-405a-becd-fdd1a9271d1c@github.com>
Message-ID: <B6se0Xs0Ms3eMhij7LOguI1Q21aYgYU_7JAs9JYjjh4=.8e7531cf-fef8-49c8-b5fa-f89c434a16d2@github.com>

On Thu, 28 Oct 2021 13:24:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test does not fail on Windows and does fail on Linux. 
> 
> After de-iconification we expect to see the button focused:
> ![image](https://user-images.githubusercontent.com/77687766/139171852-54413dba-d58a-46d4-ab83-59d93868e287.png)
> 
> Actual look:
> ![image](https://user-images.githubusercontent.com/77687766/139171775-80e64e58-c49d-489a-8fe0-fb0640fc3be9.png)
> 
> Button loses focus on `frame.to Front()` call, after its removal test passes. There is an [open issue](https://bugs.openjdk.java.net/browse/JDK-7156130) for this.
> 
> 
> Some cleanup was also made. Testing is green for all platforms.
> 
> 
> I am unable to reproduce [8266244 / macosx-aarch64](https://bugs.openjdk.java.net/browse/JDK-8266244), however it is not removed from the problem list due to its intermittent nature which needs more time to investigate.

test/jdk/ProblemList.txt line 264:

> 262: java/awt/Component/SetEnabledPerformance/SetEnabledPerformance.java 8165863 macosx-all
> 263: java/awt/Clipboard/HTMLTransferTest/HTMLTransferTest.java 8017454 macosx-all
> 264: java/awt/Frame/MiscUndecorated/RepaintTest.java 8266244 macosx-aarch64

What is the reason for the failure on macOS aarch64?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6157


From azvegint at openjdk.java.net  Thu Oct 28 20:29:28 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 28 Oct 2021 20:29:28 GMT
Subject: RFR: 6854300: [TEST_BUG]
 java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java fails in
 jdk6u14 & jdk7
Message-ID: <iz42ZewWVcIUIceWpXSSPpeFHd1aMd38D9vVtWuZLxw=.f65d3bb9-0165-45e2-80f8-a5c8ce20597f@github.com>

Test trying to call `button.getLocationOnScreen()` when its frame not yet fully configured, so the obtained button location is shifted by window's height. 

Waiting a bit after `setVisible()` call fixes the issue. Some cleanup was made also. Testing is green on all platforms.

-------------

Commit messages:
 - EDT
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/6164/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6164&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-6854300
  Stats: 61 lines in 2 files changed: 32 ins; 4 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6164.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6164/head:pull/6164

PR: https://git.openjdk.java.net/jdk/pull/6164


From azvegint at openjdk.java.net  Thu Oct 28 20:37:10 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 28 Oct 2021 20:37:10 GMT
Subject: RFR: 8079267: [TEST_BUG] Test
 java/awt/Frame/MiscUndecorated/RepaintTest.java fails
In-Reply-To: <B6se0Xs0Ms3eMhij7LOguI1Q21aYgYU_7JAs9JYjjh4=.8e7531cf-fef8-49c8-b5fa-f89c434a16d2@github.com>
References: <D3GP12GLPR9xzPb5FWN42g_HZkqUTUKdgBabiiJOECA=.800914e0-274f-405a-becd-fdd1a9271d1c@github.com>
 <B6se0Xs0Ms3eMhij7LOguI1Q21aYgYU_7JAs9JYjjh4=.8e7531cf-fef8-49c8-b5fa-f89c434a16d2@github.com>
Message-ID: <_3Dd-Lu4kXUlKNCNdNR_qcn1CaTgaNDF3dzGDJQIB5c=.be241c10-df7e-489a-9984-0bdd3446b446@github.com>

On Thu, 28 Oct 2021 19:30:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This test does not fail on Windows and does fail on Linux. 
>> 
>> After de-iconification we expect to see the button focused:
>> ![image](https://user-images.githubusercontent.com/77687766/139171852-54413dba-d58a-46d4-ab83-59d93868e287.png)
>> 
>> Actual look:
>> ![image](https://user-images.githubusercontent.com/77687766/139171775-80e64e58-c49d-489a-8fe0-fb0640fc3be9.png)
>> 
>> Button loses focus on `frame.to Front()` call, after its removal test passes. There is an [open issue](https://bugs.openjdk.java.net/browse/JDK-7156130) for this.
>> 
>> 
>> Some cleanup was also made. Testing is green for all platforms.
>> 
>> 
>> I am unable to reproduce [8266244 / macosx-aarch64](https://bugs.openjdk.java.net/browse/JDK-8266244), however it is not removed from the problem list due to its intermittent nature which needs more time to investigate.
>
> test/jdk/ProblemList.txt line 264:
> 
>> 262: java/awt/Component/SetEnabledPerformance/SetEnabledPerformance.java 8165863 macosx-all
>> 263: java/awt/Clipboard/HTMLTransferTest/HTMLTransferTest.java 8017454 macosx-all
>> 264: java/awt/Frame/MiscUndecorated/RepaintTest.java 8266244 macosx-aarch64
> 
> What is the reason for the failure on macOS aarch64?

It seems that it is the same that described by @prsadhuk in #6140 - cursor presence on screenshot:

![image](https://user-images.githubusercontent.com/77687766/139330827-ab54cfbe-2053-4f9a-91cd-75aee76c300e.png)
![image](https://user-images.githubusercontent.com/77687766/139330844-13d44fb0-e72f-465d-90dd-ce706505b4ee.png)

However it did fail for me only for original test before modifications, and didn't fail after, but I think it still need more investigation under a separate bug.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6157


From serb at openjdk.java.net  Thu Oct 28 20:58:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Oct 2021 20:58:14 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <F4yU8VqKbDhyDAB3GDlwAP25jo8tSgbu9k9TlEirPWM=.ef54c9dc-10f8-487d-af0c-42e940dd1624@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <F4yU8VqKbDhyDAB3GDlwAP25jo8tSgbu9k9TlEirPWM=.ef54c9dc-10f8-487d-af0c-42e940dd1624@github.com>
Message-ID: <46QtApU1aiyRjJvHPwcGpctT4URN7U0dSChovFST-6s=.04e735b7-4539-4c61-8714-d0358edb1742@github.com>

On Thu, 28 Oct 2021 18:50:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I have attached 2 screen capture in JBS taken when PressedIconTest and JInternalFrame test failed and the screenshot at least in this machine shows presence of cursor.

So maybe something was changed in the native API? It looks like a tck issue that breaks the specified behavior. Is it happen only on this system? Could it be related to the cursor configuration in the settings, size/visibility/scale etc?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From prr at openjdk.java.net  Thu Oct 28 21:19:13 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 28 Oct 2021 21:19:13 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <46QtApU1aiyRjJvHPwcGpctT4URN7U0dSChovFST-6s=.04e735b7-4539-4c61-8714-d0358edb1742@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <F4yU8VqKbDhyDAB3GDlwAP25jo8tSgbu9k9TlEirPWM=.ef54c9dc-10f8-487d-af0c-42e940dd1624@github.com>
 <46QtApU1aiyRjJvHPwcGpctT4URN7U0dSChovFST-6s=.04e735b7-4539-4c61-8714-d0358edb1742@github.com>
Message-ID: <pwNJSSq7Mj6RXMtiWpeEHYfWprWRTEvh2W1G6P9VecI=.6ddc0a7d-f7ce-46cb-af7a-7840e8b81a57@github.com>

On Thu, 28 Oct 2021 20:54:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I have attached 2 screen capture in JBS taken when PressedIconTest and JInternalFrame test failed and the screenshot at least in this machine shows presence of cursor.
> 
> So maybe something was changed in the native API? It looks like a tck issue that breaks the specified behavior. Is it happen only on this system? Could it be related to the cursor configuration in the settings, size/visibility/scale etc?

See the comment I just added to https://bugs.openjdk.java.net/browse/JDK-8252813.

It still needs verification to see if it affects the macOS API used. But it seems probable something like that is going on.
Regardless I think we may need to revise the Robot spec a little ... I don't know why it is so insistent that the cursor is NOT captured since it seems something outside control of the Robot ..

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Thu Oct 28 21:19:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Oct 2021 21:19:14 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
Message-ID: <ZS1nSwBIxPyP3bnE9Dnu42oMLiMOnFSPr5z-YCTyKeg=.7ce5419d-fb32-49ec-9091-4362bf27f91d@github.com>

On Thu, 28 Oct 2021 06:37:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
>> It was seen from the logs that we have color mismatch in these tests.
>> 
>> For example, in PressedIcon test, we had following log
>> 
>> ----------System.out:(1/75)----------
>> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
>> ----------System.err:(13/842)----------
>> java.lang.RuntimeException: Colors is different for scale=1!
>> 	at PressedIconTest.main(PressedIconTest.java:97)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> and JInternalFrame test, we had 
>> ----------System.err:(15/939)----------
>> FRAME_COLOR Red: 255; Green: 200; Blue: 0
>> Pixel color Red: 55; Green: 55; Blue: 55
>> java.lang.RuntimeException: Internal frame is not correctly dragged!
>> 	at bug8069348.main(bug8069348.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
>> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
>> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
>> 
>> The awt tests that are failing seems to have different root cause and will be handled separately.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - awt test fix added
>  - awt test fix added

Yes looks like it is related to the cursor size in the settings
Settings->Accessibility->Display->Cursor tab->Increase the size of the cursor to large.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Thu Oct 28 21:29:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Oct 2021 21:29:15 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
Message-ID: <-OOs7jpKcklS1zxdRi4enwb84KhlZRthVMLpu0QfCVM=.bf73e7c7-3261-4372-b606-34710f32871e@github.com>

On Thu, 28 Oct 2021 06:37:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
>> It was seen from the logs that we have color mismatch in these tests.
>> 
>> For example, in PressedIcon test, we had following log
>> 
>> ----------System.out:(1/75)----------
>> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
>> ----------System.err:(13/842)----------
>> java.lang.RuntimeException: Colors is different for scale=1!
>> 	at PressedIconTest.main(PressedIconTest.java:97)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> and JInternalFrame test, we had 
>> ----------System.err:(15/939)----------
>> FRAME_COLOR Red: 255; Green: 200; Blue: 0
>> Pixel color Red: 55; Green: 55; Blue: 55
>> java.lang.RuntimeException: Internal frame is not correctly dragged!
>> 	at bug8069348.main(bug8069348.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
>> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
>> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
>> 
>> The awt tests that are failing seems to have different root cause and will be handled separately.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - awt test fix added
>  - awt test fix added

I think we should report this to Apple.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From prr at openjdk.java.net  Thu Oct 28 21:34:11 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 28 Oct 2021 21:34:11 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <ZS1nSwBIxPyP3bnE9Dnu42oMLiMOnFSPr5z-YCTyKeg=.7ce5419d-fb32-49ec-9091-4362bf27f91d@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <ZS1nSwBIxPyP3bnE9Dnu42oMLiMOnFSPr5z-YCTyKeg=.7ce5419d-fb32-49ec-9091-4362bf27f91d@github.com>
Message-ID: <ByNb2x5CGHFfEWuRMz0y2SmfXEmAKqTajI7Gk_KhLtg=.cc9f6943-3781-4fd6-865c-a3b84591f4a5@github.com>

On Thu, 28 Oct 2021 21:15:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Yes looks like it is related to the cursor size in the settings
> Settings->Accessibility->Display->Cursor tab->Increase the size of the cursor to large.

Sorry, not following ..  do you mean you think the cursor is captured when it is enlarged ?
Like somehow a software cursor is used that is painted in a different way so that it always show up ?
But the screen captures in the bug report seem to show a small cursor and the above A11Y setting on the
test system has Cursor Size: Normal (ie the very minimum of the slider)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Thu Oct 28 21:41:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Oct 2021 21:41:10 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <ByNb2x5CGHFfEWuRMz0y2SmfXEmAKqTajI7Gk_KhLtg=.cc9f6943-3781-4fd6-865c-a3b84591f4a5@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <ZS1nSwBIxPyP3bnE9Dnu42oMLiMOnFSPr5z-YCTyKeg=.7ce5419d-fb32-49ec-9091-4362bf27f91d@github.com>
 <ByNb2x5CGHFfEWuRMz0y2SmfXEmAKqTajI7Gk_KhLtg=.cc9f6943-3781-4fd6-865c-a3b84591f4a5@github.com>
Message-ID: <2TSmUh8J2Vk13tRv3JG_Ae7CVEWY2TNdSelws96XMcY=.0b06ec21-0b2c-42d9-9177-f3bde154d06f@github.com>

On Thu, 28 Oct 2021 21:30:46 GMT, Phil Race <prr at openjdk.org> wrote:

> Sorry, not following .. do you mean you think the cursor is captured when it is enlarged ? Like somehow a software cursor is used that is painted in a different way so that it always show up ? But the screen captures in the bug report seem to show a small cursor and the above A11Y setting on the test system has Cursor Size: Normal (ie the very minimum of the slider)

I can confirm that the changing the size of the cursor on that setting page can change the visibility of the cursor on the screenshot. If the cursor is "small" then it is completely invisible, if the cursor size is changed above some threshold it became visible on the screenshot. So it might be a case when on that system the default cursor is bigger that the threshold.

> BTW when accessing the test system remotely it seems that A11Y feature is disabled. The slider has no effect.

So probably the local settings is not default/changed, and what is shown on the setting you see is for remote view?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From prr at openjdk.java.net  Thu Oct 28 21:41:10 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 28 Oct 2021 21:41:10 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <2TSmUh8J2Vk13tRv3JG_Ae7CVEWY2TNdSelws96XMcY=.0b06ec21-0b2c-42d9-9177-f3bde154d06f@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <ZS1nSwBIxPyP3bnE9Dnu42oMLiMOnFSPr5z-YCTyKeg=.7ce5419d-fb32-49ec-9091-4362bf27f91d@github.com>
 <ByNb2x5CGHFfEWuRMz0y2SmfXEmAKqTajI7Gk_KhLtg=.cc9f6943-3781-4fd6-865c-a3b84591f4a5@github.com>
 <2TSmUh8J2Vk13tRv3JG_Ae7CVEWY2TNdSelws96XMcY=.0b06ec21-0b2c-42d9-9177-f3bde154d06f@github.com>
Message-ID: <X6e9jSQBV1wZcxgaBIUIV2P0icMjOp3-Ome_9V_6zx8=.dc503bb8-1099-4473-a8e4-c63388f814e2@github.com>

On Thu, 28 Oct 2021 21:35:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Sorry, not following .. do you mean you think the cursor is captured when it is enlarged ? Like somehow a software cursor is used that is painted in a different way so that it always show up ? But the screen captures in the bug report seem to show a small cursor and the above A11Y setting on the test system has Cursor Size: Normal (ie the very minimum of the slider)
> 
> I can confirm that the changing the size of the cursor on that setting page can change the visibility of the cursor on the screenshot. If the cursor is "small" then it is completely invisible, if the cursor size is changed above some threshold it became visible on the screenshot. So it might be a case when on that system the default cursor is bigger that the threshold.

Hmm .. well it is at the minimum right now. So throw that one in the bag of things that can go wrong .. but I'm not currently seeing it set to anything except absolute minimum,
But we could change it manually and see if that toggles whether the unmodified tests pass or fail .. 

The mechanism by which any of these things suddenly happen and then suddenly go away is really unclear to me ..
but at least it makes sense that these can persist across reboots

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From prr at openjdk.java.net  Thu Oct 28 21:50:16 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 28 Oct 2021 21:50:16 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <2TSmUh8J2Vk13tRv3JG_Ae7CVEWY2TNdSelws96XMcY=.0b06ec21-0b2c-42d9-9177-f3bde154d06f@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <ZS1nSwBIxPyP3bnE9Dnu42oMLiMOnFSPr5z-YCTyKeg=.7ce5419d-fb32-49ec-9091-4362bf27f91d@github.com>
 <ByNb2x5CGHFfEWuRMz0y2SmfXEmAKqTajI7Gk_KhLtg=.cc9f6943-3781-4fd6-865c-a3b84591f4a5@github.com>
 <2TSmUh8J2Vk13tRv3JG_Ae7CVEWY2TNdSelws96XMcY=.0b06ec21-0b2c-42d9-9177-f3bde154d06f@github.com>
Message-ID: <7C7tuGkysRIpLMLHvkmdgHWrtL9t3SJNTapDm_Vt6uo=.282c47d8-6756-440f-8cba-90b3933dd865@github.com>

On Thu, 28 Oct 2021 21:38:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > BTW when accessing the test system remotely it seems that A11Y feature is disabled. The slider has no effect.
> 
> So probably the local settings is not default/changed, and what is shown on the setting you see is for remote view?

Well I can move the slider so I think I am seeing the REAL setting but it just doesn't get used in screen sharing mode

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Thu Oct 28 21:57:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Oct 2021 21:57:09 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
Message-ID: <cAjuekoGHQeLj-hohq4Dh1TbeAaA2yPzQtBa1_Rkekk=.230eb3e5-d6a0-4b98-b87a-d80a335cef7d@github.com>

On Thu, 28 Oct 2021 06:37:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
>> It was seen from the logs that we have color mismatch in these tests.
>> 
>> For example, in PressedIcon test, we had following log
>> 
>> ----------System.out:(1/75)----------
>> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
>> ----------System.err:(13/842)----------
>> java.lang.RuntimeException: Colors is different for scale=1!
>> 	at PressedIconTest.main(PressedIconTest.java:97)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> and JInternalFrame test, we had 
>> ----------System.err:(15/939)----------
>> FRAME_COLOR Red: 255; Green: 200; Blue: 0
>> Pixel color Red: 55; Green: 55; Blue: 55
>> java.lang.RuntimeException: Internal frame is not correctly dragged!
>> 	at bug8069348.main(bug8069348.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
>> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
>> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
>> 
>> The awt tests that are failing seems to have different root cause and will be handled separately.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - awt test fix added
>  - awt test fix added

I tried it on the other macOS system, this time aarch64. And the cursor is visible there even if the size is set to small.
So it will be good to report this to Apple, looks like a regression.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Thu Oct 28 22:06:13 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Oct 2021 22:06:13 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
Message-ID: <B_0ljepvxN7Wf-6CQ1JX2ECCzA2UZIsxMpD0DtnfiQM=.2e70fa49-73ab-42a9-9e9e-a68786fabb47@github.com>

On Thu, 28 Oct 2021 06:37:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
>> It was seen from the logs that we have color mismatch in these tests.
>> 
>> For example, in PressedIcon test, we had following log
>> 
>> ----------System.out:(1/75)----------
>> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
>> ----------System.err:(13/842)----------
>> java.lang.RuntimeException: Colors is different for scale=1!
>> 	at PressedIconTest.main(PressedIconTest.java:97)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> and JInternalFrame test, we had 
>> ----------System.err:(15/939)----------
>> FRAME_COLOR Red: 255; Green: 200; Blue: 0
>> Pixel color Red: 55; Green: 55; Blue: 55
>> java.lang.RuntimeException: Internal frame is not correctly dragged!
>> 	at bug8069348.main(bug8069348.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
>> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
>> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
>> 
>> The awt tests that are failing seems to have different root cause and will be handled separately.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - awt test fix added
>  - awt test fix added

Looks like sometimes the cursor may be rendered in the framebuffer and sometimes not:
https://developer.apple.com/documentation/coregraphics/1541804-cgcursorisdrawninframebuffer?language=objc

> (The cursor could exist in an overlay plane or a similar mechanism that puts pixels on-screen without altering framebuffer content.) If the cursor is drawn in the framebuffer, it is read back along with window data.

Maybe we should wrap the taking screenshot by the CGDisplayHideCursor/CGDisplayShowCursor.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Thu Oct 28 22:20:12 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Oct 2021 22:20:12 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
Message-ID: <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>

On Thu, 28 Oct 2021 06:37:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
>> It was seen from the logs that we have color mismatch in these tests.
>> 
>> For example, in PressedIcon test, we had following log
>> 
>> ----------System.out:(1/75)----------
>> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
>> ----------System.err:(13/842)----------
>> java.lang.RuntimeException: Colors is different for scale=1!
>> 	at PressedIconTest.main(PressedIconTest.java:97)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> and JInternalFrame test, we had 
>> ----------System.err:(15/939)----------
>> FRAME_COLOR Red: 255; Green: 200; Blue: 0
>> Pixel color Red: 55; Green: 55; Blue: 55
>> java.lang.RuntimeException: Internal frame is not correctly dragged!
>> 	at bug8069348.main(bug8069348.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
>> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
>> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
>> 
>> The awt tests that are failing seems to have different root cause and will be handled separately.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - awt test fix added
>  - awt test fix added

Confirm that the CGDisplayHideCursor/CGDisplayShowCursor solves the problem on my side, I'll prepare the patch. I think it should be backported to all old trains.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Thu Oct 28 22:35:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Oct 2021 22:35:09 GMT
Subject: RFR: 6854300: [TEST_BUG]
 java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java fails in
 jdk6u14 & jdk7
In-Reply-To: <iz42ZewWVcIUIceWpXSSPpeFHd1aMd38D9vVtWuZLxw=.f65d3bb9-0165-45e2-80f8-a5c8ce20597f@github.com>
References: <iz42ZewWVcIUIceWpXSSPpeFHd1aMd38D9vVtWuZLxw=.f65d3bb9-0165-45e2-80f8-a5c8ce20597f@github.com>
Message-ID: <r6hpUTvd1Pi_WIbSjmv5IlQWiifdKCGPl7BloNXzroc=.d9d4b7a9-29ad-4f13-84bc-0a0fa7fb83a6@github.com>

On Thu, 28 Oct 2021 20:20:04 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Test trying to call `button.getLocationOnScreen()` when its frame not yet fully configured, so the obtained button location is shifted by window's height. 
> 
> Waiting a bit after `setVisible()` call fixes the issue. Some cleanup was made also. Testing is green on all platforms.

test/jdk/java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java line 97:

> 95:         r.delay(1000);
> 96: 
> 97:         Point centerA = new Point(comp.getLocationOnScreen().x + comp.getWidth() / 2,

I think the comp.getLocationOnScreen() should be moved to the EDT, and probably that will solve the problem even w/o delay?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6164


From azvegint at openjdk.java.net  Fri Oct 29 01:24:41 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 29 Oct 2021 01:24:41 GMT
Subject: RFR: 6854300: [TEST_BUG]
 java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java fails in
 jdk6u14 & jdk7 [v2]
In-Reply-To: <iz42ZewWVcIUIceWpXSSPpeFHd1aMd38D9vVtWuZLxw=.f65d3bb9-0165-45e2-80f8-a5c8ce20597f@github.com>
References: <iz42ZewWVcIUIceWpXSSPpeFHd1aMd38D9vVtWuZLxw=.f65d3bb9-0165-45e2-80f8-a5c8ce20597f@github.com>
Message-ID: <NvcaFx63hqMRUhw8uMSD4iVe7N157gMb2ySKXxQ-6eM=.76495962-fd72-486c-9942-b2acec279492@github.com>

> Test trying to call `button.getLocationOnScreen()` when its frame not yet fully configured, so the obtained button location is shifted by window's height. 
> 
> Waiting a bit after `setVisible()` call fixes the issue. Some cleanup was made also. Testing is green on all platforms.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  more EDT

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6164/files
  - new: https://git.openjdk.java.net/jdk/pull/6164/files/43506150..be592ef9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6164&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6164&range=00-01

  Stats: 23 lines in 1 file changed: 10 ins; 2 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6164.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6164/head:pull/6164

PR: https://git.openjdk.java.net/jdk/pull/6164


From azvegint at openjdk.java.net  Fri Oct 29 01:34:12 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 29 Oct 2021 01:34:12 GMT
Subject: RFR: 6854300: [TEST_BUG]
 java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java fails in
 jdk6u14 & jdk7 [v2]
In-Reply-To: <r6hpUTvd1Pi_WIbSjmv5IlQWiifdKCGPl7BloNXzroc=.d9d4b7a9-29ad-4f13-84bc-0a0fa7fb83a6@github.com>
References: <iz42ZewWVcIUIceWpXSSPpeFHd1aMd38D9vVtWuZLxw=.f65d3bb9-0165-45e2-80f8-a5c8ce20597f@github.com>
 <r6hpUTvd1Pi_WIbSjmv5IlQWiifdKCGPl7BloNXzroc=.d9d4b7a9-29ad-4f13-84bc-0a0fa7fb83a6@github.com>
Message-ID: <gX0AlmKQxcEGfDVpZhDPehaV7fYpJD6cMLT2ySdsGXw=.e9bbb355-0115-4bfc-aa63-a554e67d255b@github.com>

On Thu, 28 Oct 2021 22:32:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more EDT
>
> test/jdk/java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java line 97:
> 
>> 95:         r.delay(1000);
>> 96: 
>> 97:         Point centerA = new Point(comp.getLocationOnScreen().x + comp.getWidth() / 2,
> 
> I think the comp.getLocationOnScreen() should be moved to the EDT, and probably that will solve the problem even w/o delay?

Done. 
Actually it will pass if you add `waitForIdle()` to the unmodified test, the delay was added just for safety.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6164


From prr at openjdk.java.net  Fri Oct 29 03:52:14 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Oct 2021 03:52:14 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
Message-ID: <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>

On Thu, 28 Oct 2021 22:17:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Confirm that the CGDisplayHideCursor/CGDisplayShowCursor solves the problem on my side, I'll prepare the patch. I think it should be backported to all old trains.

Well .. if you think that's what's needed I suggest you ask the fixer if they'd prefer to do that themselves first as the owner of this issue. 

Whoever does it there's a bunch of testing needed to validate it including testing  both the cursor size and the screen capture option

As to the suggestion although Robot is 99% used for testing and no tester will care at the cursor blinking off and on again I know there are cases where people have used it for other things and I don't know how long it takes to capture the screen of a 5K retina display. I would want to be very sure it is necessary to sacrifice usability by invoking this on all Robot API calls to compensate for the as yet not understood cases where this is happening even though it should not be. The "spec" issue can be handled by an update there.  We can even add new API to request (not guarantee) that the cursor be hidden.

Regardless, there's value in the test updates, although my existing comments on the specifics there still stand.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Fri Oct 29 04:34:18 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Oct 2021 04:34:18 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
 <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
Message-ID: <dKp8Ea_6Il-4VLaaT3kQfGonJpS7w-LuMWFWPa9Ut1c=.93395110-55ef-4d2d-8815-b79a7f2af6ed@github.com>

On Fri, 29 Oct 2021 03:49:04 GMT, Phil Race <prr at openjdk.org> wrote:

> Well .. if you think that's what's needed I suggest you ask the fixer if they'd prefer to do that themselves first as the owner of this issue.

This issue is broader than the cursor, not sure that the test which needs a "tolerance" will be fixed by the hidden cursor. So the cursor is a separate part and could be fixed and especially tested separately. I am still not sure why some of the tests do not work as-is and we need to tweak the scale/tolerance/etc. probably that also some kind of bugs.

> Whoever does it there's a bunch of testing needed to validate it including testing both the cursor size and the screen capture option

Sure, I will run some of the combinations and something can be covered by the mach5.

> As to the suggestion although Robot is 99% used for testing and no tester will care at the cursor blinking off and on again I know there are cases where people have used it for other things and I don't know how long it takes to capture the screen of a 5K retina display. I would want to be very sure it is necessary to sacrifice usability by invoking this on all Robot API calls to compensate for the as yet not understood cases where this is happening even though it should not be. The "spec" issue can be handled by an update there. We can even add new API to request (not guarantee) that the cursor be hidden.

We cannot update the spec in the update releases, and the new behavior could be considered as a regression from x64 to aarch64. But yes the possible change of performance should be considered and measured.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Fri Oct 29 04:37:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Oct 2021 04:37:10 GMT
Subject: RFR: 6854300: [TEST_BUG]
 java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java fails in
 jdk6u14 & jdk7 [v2]
In-Reply-To: <NvcaFx63hqMRUhw8uMSD4iVe7N157gMb2ySKXxQ-6eM=.76495962-fd72-486c-9942-b2acec279492@github.com>
References: <iz42ZewWVcIUIceWpXSSPpeFHd1aMd38D9vVtWuZLxw=.f65d3bb9-0165-45e2-80f8-a5c8ce20597f@github.com>
 <NvcaFx63hqMRUhw8uMSD4iVe7N157gMb2ySKXxQ-6eM=.76495962-fd72-486c-9942-b2acec279492@github.com>
Message-ID: <IsI-tAtwZxL1KymA7d2lNf7D5iJ8-yr3Oc8Hfrf9YHY=.e366eac2-4b1d-44fd-84d1-efb1f90a48ec@github.com>

On Fri, 29 Oct 2021 01:24:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Test trying to call `button.getLocationOnScreen()` when its frame not yet fully configured, so the obtained button location is shifted by window's height. 
>> 
>> Waiting a bit after `setVisible()` call fixes the issue. Some cleanup was made also. Testing is green on all platforms.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more EDT

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6164


From psadhukhan at openjdk.java.net  Fri Oct 29 04:46:13 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 29 Oct 2021 04:46:13 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
 <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
Message-ID: <7tTf3myTJV-fC3OHL1XkeZXXKQj7zq1NFGQ_Hr5_7es=.f22c1949-4b7b-47a1-bd61-ea74cd603a23@github.com>

On Fri, 29 Oct 2021 03:49:04 GMT, Phil Race <prr at openjdk.org> wrote:

> Regardless, there's value in the test updates, although my existing comments on the specifics there still stand.

Should I pursue with the test updates with this PR as it seems it can be addressed by product change? I am not sure what specifics needs to be addressed...Are the below ones the one?

> And is an offset of 10 enough ? Its a bit arbitrary and cursors could be a larger shape or different orientation

SInce I am going in opposite direction of cursor by using (-10,-10) I guess it should be ok since normally cursor as shown in the screencapture, even if enlarged, willnot encroach on (-10, -10) area unless it's a inverted cursor wihch I am not sure exist or not.

> Shouldn't this use TESTCLASSES or something like that ?

We have used the same way of ImageIO.write() in jtreg tests

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From kizune at openjdk.java.net  Fri Oct 29 05:13:16 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 29 Oct 2021 05:13:16 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac [v2]
In-Reply-To: <EgoTPAifwXFieY6s52ai9R_hCdCPg1G4Ni3Yen3SaRM=.f43e5a58-3eca-4e5d-9042-1836a4e6025a@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
 <HLIZqD2uCSFmxiLAnHXbTunMPvU78dCWzmydCKR7ZYI=.394e573e-a859-47e4-92cb-91d6f7f000b5@github.com>
 <iuWNGEIB1XeIFzKZJ8tVaAWwOVrkxDdSfR9uOg3BmPw=.5b2a4907-224c-4bfc-afab-97f158ba75b4@github.com>
 <-wjkwScXO_5VvlFJ-BfaS_3WTzhUd3CqP02cWH3iuLA=.06e63805-4193-4f9f-b89e-c43b58376392@github.com>
 <LWKJpTQBsu5IU3UVwA2p4itK5PQ7YlRLjbVKwo1SwZs=.7d675aa9-35d2-4691-9a28-907143cb4e8f@github.com>
 <JATrFwDsIpI4Oz0lpq8ZGftMT8oRK24rW5rvX7s99dc=.19988ef5-f5e3-417b-aaec-78511b6b2e52@github.com>
 <QZaEezk_LS7j1hyv732-dWx4kN1uUkgYQPnZ45LDTVs=.1b223259-7907-4d92-b56a-16223e2ade3f@github.com>
 <heJOJRZAjuc5zyQOFfUSBjJP-_payL4OGCINgxSCiPM=.d63032aa-7da9-48e0-ae9f-0387dfd05772@github.com>
 <dbyc94TD-RfkOyT3f0UlvsdYym7FPR6tRzbKSh7huTU=.dc68ddeb-7a7c-498d-99c1-ee89fe733e43@github.com>
 <J3wXoI0OYewaHmn0-dErydBDLZFxBo-kRBRI9mWBHs8=.8f210c19-a0f2-4652-837a-d44c66f5888e@github.com>
 <oOgwINMz6qMCCdMZzXR7CRmz5TSjtHCe667
 7q9o_hC4=.fa6541aa-142a-4f7b-b853-f34ec43ceaf8@github.com>
 <EgoTPAifwXFieY6s52ai9R_hCdCPg1G4Ni3Yen3SaRM=.f43e5a58-3eca-4e5d-9042-1836a4e6025a@github.com>
Message-ID: <ukXLXl8d_EE54fqnDAkKsu1mHakLGewfmRDECqEKUFk=.dbcf27d0-b6d5-4bb2-b562-c1a9ca7ae4dd@github.com>

On Thu, 28 Oct 2021 19:27:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> I think that was changed 15 years ago or so somewhere before the release of the JDK5 the spec was updated
>> 
>> Ok, i will fix that in this particular test for the sake of getting a closure on it but it seems wrong to me on so many levels. And it is no surprise so many automated Swing tests are failing intermittently  - they were written according the old notion of the Swing component lifecycle and was never updated to reflect the backwards incompatible change we accidentally did. Shame. But that's a topic to discuss and dig deeper later.
>
> We did not change the behavior of the Swing, it works the same before and after that spec update. That tests were broken from the beginning and this is why they are unstable, and this is why the requirements were changed.

You contradict yourself. There were a concept of cold and hot times in component life cycle called non-realized and realized component. It was specified. Test were written according the specification. Failing to follow specification would have considered a bug. Some of the projects were relying on that concept. User code were relying on that concept because they were taught by us and by tutorials officially approved and endorsed by us. Then tests started failing, customers started submitting bugs and we discovered that that is because we do not follow specification we wrote. The bugs were reported against specific version and they were not present in the previous version - means the bugs were results of our changes - remember, that was at the times when there were virtually no external contribution so whatever caused the specification break was our deed. And instead of fixing it we gave up and changed specification. This is a definition of backward incompatible change and in my opini
 on pure "we can not fix this bug, let's call it a feature" approach.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6104


From prr at openjdk.java.net  Fri Oct 29 05:26:11 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Oct 2021 05:26:11 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <dKp8Ea_6Il-4VLaaT3kQfGonJpS7w-LuMWFWPa9Ut1c=.93395110-55ef-4d2d-8815-b79a7f2af6ed@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
 <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
 <dKp8Ea_6Il-4VLaaT3kQfGonJpS7w-LuMWFWPa9Ut1c=.93395110-55ef-4d2d-8815-b79a7f2af6ed@github.com>
Message-ID: <a3j0biwB6OX1N_kvwoJqs-fmxedQokoRrQ-fXkGjJ24=.8681a694-5f89-4a8b-a8eb-032c2e0fb1a8@github.com>

On Fri, 29 Oct 2021 04:31:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This issue is broader than the cursor, not sure that the test which needs a "tolerance" will be fixed by the hidden cursor. So the cursor is a separate part and could be fixed and especially tested separately. I am still not sure why some of the tests do not work as-is and we need to tweak the scale/tolerance/etc. probably that also some kind of bugs.

Broader ? Please expand since the change you suggest is only about the cursor

The test part of the fix has multiple stability improvements, and there's no reason to throw that out.
And moving the pixel capture position to a more safe position is fine too. I just think that -10 isn't sa\fe enough.

> We cannot update the spec in the update releases, 

I am so new to this .. it never occurred :-)


> and the new behavior could be considered as a regression from x64 to aarch64. 

Who mentioned aarch64 ?
Are you referring to you proposed change. I don't see the aarch64 connection anywhere
FWIW the actual hardware on which this was seen is (I think) a 2013 Mac Pro running 10.15.7

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Fri Oct 29 05:42:12 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Oct 2021 05:42:12 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <a3j0biwB6OX1N_kvwoJqs-fmxedQokoRrQ-fXkGjJ24=.8681a694-5f89-4a8b-a8eb-032c2e0fb1a8@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
 <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
 <dKp8Ea_6Il-4VLaaT3kQfGonJpS7w-LuMWFWPa9Ut1c=.93395110-55ef-4d2d-8815-b79a7f2af6ed@github.com>
 <a3j0biwB6OX1N_kvwoJqs-fmxedQokoRrQ-fXkGjJ24=.8681a694-5f89-4a8b-a8eb-032c2e0fb1a8@github.com>
Message-ID: <A5GshhqI9WjWtrDmFo1A4zkpW_RKlqU-LSJfyVsBsHo=.3bbbab9e-031b-47a1-8ecc-e84e11d726d8@github.com>

On Fri, 29 Oct 2021 05:23:39 GMT, Phil Race <prr at openjdk.org> wrote:

> Broader ? Please expand since the change you suggest is only about the cursor

This issue JDK-8276058 is broader than the cursor, related, this is why I would like to exclude it from it.

> The test part of the fix has multiple stability improvements, and there's no reason to throw that out. And moving the pixel capture position to a more safe position is fine too. I just think that -10 isn't sa\fe enough.

Sure, I have no comments about the changes related to stability, but there are suspicious cases like using tolerance.

> Who mentioned aarch64 ? Are you referring to you proposed change. I don't see the aarch64 connection anywhere FWIW the actual hardware on which this was seen is (I think) a 2013 Mac Pro running 10.15.7

I have mentioned that a few comments above, on aarch64 the cursor is always present on the screenshot, unlike x64. both systems are "similar".

BTW I have found that the built-in screencapture tool has the ability to take a screenshot with and w/o cursor, so probably there is a way to specify that as well via some public API. Or maybe it is so fast that the cursor flickering is invisible.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Fri Oct 29 05:47:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Oct 2021 05:47:10 GMT
Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the
 java.util.logging
In-Reply-To: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
References: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
Message-ID: <GUSC53KVMDq7M34RiKj6SD7YztQdG8HUGgcvtp8kzOo=.75242db1-5065-4733-b9c3-26757f35e69c@github.com>

On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> At the time Java supported applets and webstart, a special mechanism for launching various applications in one JVM was used to reduce memory usage and each application was isolated from each other.
> 
> This isolation was implemented via ThreadGroups where each application created its own thread group and all data for the application was stored in the context of its own group.
> 
> Some parts of the JDK used ThreadGroups directly, others used special classes like sun.awt.AppContext.
> 
> Such sandboxing became useless since the plugin and webstart are no longer supported and were removed in jdk11.
> 
> Note that this is just a first step for the overall cleanup, here is my plan:
> 1. Cleanup the usage of AppContext in the ?java.util.logging.LogManager" class in the java.base module.
> 2. Cleanup the usage of TheadGroup in the JavaSound
> 3. Cleanup the usage of TheadGroup in the JavaBeans
> 4. Cleanup the usage of AppContext in the Swing
> 5. Cleanup the usage of AppContext in the AWT
> 6. Delete the AppContext class.
> 
> The current PR is for the first step. So this is the request to delete the usage of AppContext in the LogManager and related tests.
> 
> Tested by tier1/tier2/tier3 and jdk_desktop tests.

Does anybody have any other suggestions?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5326


From serb at openjdk.java.net  Fri Oct 29 05:53:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Oct 2021 05:53:09 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac [v2]
In-Reply-To: <ukXLXl8d_EE54fqnDAkKsu1mHakLGewfmRDECqEKUFk=.dbcf27d0-b6d5-4bb2-b562-c1a9ca7ae4dd@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
 <HLIZqD2uCSFmxiLAnHXbTunMPvU78dCWzmydCKR7ZYI=.394e573e-a859-47e4-92cb-91d6f7f000b5@github.com>
 <iuWNGEIB1XeIFzKZJ8tVaAWwOVrkxDdSfR9uOg3BmPw=.5b2a4907-224c-4bfc-afab-97f158ba75b4@github.com>
 <-wjkwScXO_5VvlFJ-BfaS_3WTzhUd3CqP02cWH3iuLA=.06e63805-4193-4f9f-b89e-c43b58376392@github.com>
 <LWKJpTQBsu5IU3UVwA2p4itK5PQ7YlRLjbVKwo1SwZs=.7d675aa9-35d2-4691-9a28-907143cb4e8f@github.com>
 <JATrFwDsIpI4Oz0lpq8ZGftMT8oRK24rW5rvX7s99dc=.19988ef5-f5e3-417b-aaec-78511b6b2e52@github.com>
 <QZaEezk_LS7j1hyv732-dWx4kN1uUkgYQPnZ45LDTVs=.1b223259-7907-4d92-b56a-16223e2ade3f@github.com>
 <heJOJRZAjuc5zyQOFfUSBjJP-_payL4OGCINgxSCiPM=.d63032aa-7da9-48e0-ae9f-0387dfd05772@github.com>
 <dbyc94TD-RfkOyT3f0UlvsdYym7FPR6tRzbKSh7huTU=.dc68ddeb-7a7c-498d-99c1-ee89fe733e43@github.com>
 <J3wXoI0OYewaHmn0-dErydBDLZFxBo-kRBRI9mWBHs8=.8f210c19-a0f2-4652-837a-d44c66f5888e@github.com>
 <oOgwINMz6qMCCdMZzXR7CRmz5TSjtHCe667
 7q9o_hC4=.fa6541aa-142a-4f7b-b853-f34ec43ceaf8@github.com>
 <EgoTPAifwXFieY6s52ai9R_hCdCPg1G4Ni3Yen3SaRM=.f43e5a58-3eca-4e5d-9042-1836a4e6025a@github.com>
 <ukXLXl8d_EE54fqnDAkKsu1mHakLGewfmRDECqEKUFk=.dbcf27d0-b6d5-4bb2-b562-c1a9ca7ae4dd@github.com>
Message-ID: <p8sZu6Dl8bVsiyttK2pG62aJe-8Uu_bpJuO_6fdgpKk=.a1728ccf-d22e-4ac5-b5c3-cec1f50abbb5@github.com>

On Fri, 29 Oct 2021 05:10:29 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> We did not change the behavior of the Swing, it works the same before and after that spec update. That tests were broken from the beginning and this is why they are unstable, and this is why the requirements were changed.
>
> You contradict yourself. There were a concept of cold and hot times in component life cycle called non-realized and realized component. It was specified. Test were written according the specification. Failing to follow specification would have considered a bug. Some of the projects were relying on that concept. User code were relying on that concept because they were taught by us and by tutorials officially approved and endorsed by us. Then tests started failing, customers started submitting bugs and we discovered that that is because we do not follow specification we wrote. The bugs were reported against specific version and they were not present in the previous version - means the bugs were results of our changes - remember, that was at the times when there were virtually no external contribution so whatever caused the specification break was our deed. And instead of fixing it we gave up and changed specification. This is a definition of backward incompatible change and in my opi
 nion pure "we can not fix this bug, let's call it a feature" approach.

The Swing never claims that it is thread-safe, and the one who added a notion about the safeness of manipulation of the Swing components from the different threads to the tutorial was just wrong. That was not part of the spec. And it is a good thing that the people realized that mistake and fixed it early than later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6104


From serb at openjdk.java.net  Fri Oct 29 05:54:12 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Oct 2021 05:54:12 GMT
Subject: RFR: 8225122: Test AncestorResized.java fails when Windows desktop
 is scaled.
In-Reply-To: <RpQ6WwN1Jij_T58MH9EULh0eIRetNQWcCpTW_GFJpZ0=.a581b4c7-0f17-44cd-9e6d-e980be66bf7a@github.com>
References: <RpQ6WwN1Jij_T58MH9EULh0eIRetNQWcCpTW_GFJpZ0=.a581b4c7-0f17-44cd-9e6d-e980be66bf7a@github.com>
Message-ID: <JF6GhzNfc5EM9rS5IrhcH3C6At87C3jz6KAR9bH0Xn4=.9485e9f1-d6da-40b7-a13f-c2b5b9da64ca@github.com>

On Mon, 27 Sep 2021 03:33:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This test depends on the next windows UI performance option:
> ?Show window contents while dragging?, see https://answers.microsoft.com/en-us/windows/forum/all/in-windows-7-how-do-i-show-window-contents-while/18e3aee2-bcc7-4005-a45d-c5613cf6eb3c
> 
> In the default configuration, the windows may decide that the system is slow and this option should be disabled. I have found that this usually happens in the virtual environment.
> 
> When that option is disabled the resize events have come when the user completes the resize, before that the only border "rectangle" is moved.
> 
> This fix changes the test to release the mouse and complete the resize, and only after that checks the result.
> 
> Also, some old machinery is removed.

Does anybody have any other suggestions?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5711


From serb at openjdk.java.net  Fri Oct 29 05:54:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Oct 2021 05:54:15 GMT
Subject: RFR: 8264666: Reuse Math.multiplyExact/addExact in the
 LCMSImageLayout class
In-Reply-To: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
Message-ID: <4F7ustUr38gNRvOtALjpZPnjM4AUOD727iiVdqE0hII=.836d6fe8-9a3a-4988-9398-f73679708983@github.com>

On Fri, 2 Apr 2021 23:02:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> - The hand-crafted methods for addition and multiplication are replaced by the "Math" versions.
> - Cleanup: the usage of do/while(false) is removed

not now

-------------

PR: https://git.openjdk.java.net/jdk/pull/3333


From serb at openjdk.java.net  Fri Oct 29 05:55:16 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Oct 2021 05:55:16 GMT
Subject: RFR: 8274939: Incorrect size of the pixel storage is used by the
 robot on macOS
In-Reply-To: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
References: <SYyLM7IAq7eJfnsXtfIIQsztrKKjmPPQsyCqR0ONz2Q=.d1f54552-393b-4a4d-885e-38e3326ef230@github.com>
Message-ID: <PHAV_vKtHoIQIZttkQ3vXpWJ65z4l8KfFkJ1Zdkm2N8=.03f11f61-0fc6-4b6f-b62f-ae312f1e8e53@github.com>

On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In JDK 9 the native code for the robot class was reworked to get an access to the HiDPI quality screenshots. So we allocate the data storage for the HiDPI quality and then request the best quality from the macOS.
> 
> It works fine if the user request the screenshot of some area, since we properly scale this area. Unfortunately it does not work well if the user request only one pixel, in this case we allocate the array of one element and does not multiply the size by the scale, so if the system scale is 2 then the macOS returns the 2x2 pixels, which does not fit properly to the array of one element. This can be checked by the Xcheck:jni option which produce fatal error in this case.
> 
> Solution is to allocate the storage of the proper size 1 * scale * 1 * scale

Does anybody have some comments or suggestions? I would like to fix this before adding more changes to the robot code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5864


From serb at openjdk.java.net  Fri Oct 29 05:57:13 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Oct 2021 05:57:13 GMT
Subject: RFR: 8273831: PrintServiceLookup spawns 2 threads in the current
 classloader, getting orphaned
In-Reply-To: <eXuUD3WLjn4xv-R9bL_xU0tXyZV3HVNLpliZLBX9yFM=.1398debc-971a-4013-bbef-17e388a944d5@github.com>
References: <eXuUD3WLjn4xv-R9bL_xU0tXyZV3HVNLpliZLBX9yFM=.1398debc-971a-4013-bbef-17e388a944d5@github.com>
Message-ID: <YmX5P3GK6kX8d1nqtK3vKiEkzVB5-T-QoUSlZnI1G1I=.36e34b75-ab32-47c5-a4b8-1e2dc3353f1e@github.com>

On Thu, 14 Oct 2021 05:43:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The PrintServiceLookupProvider can spawn 2 threads on WIndows and one thread on Linux. These threads are connected to the classloader of the web application.  During undeployment the app classloader gets removed together with the two orphaned threads by the Tomcat. 
> 
> Looks like the tomcat has special machinery to workaround such threads:
> https://cwiki.apache.org/confluence/display/tomcat/MemoryLeakProtection#MemoryLeakProtection-cclThreadSpawnedByJRE
> But it should be updated each time we add/update/rename the threads in the JDK. So JreMemoryLeakPreventionListener can be updated to solve this problem, but it will be good to reset the ref to the app class loader as we usually do for our internal threads. 
> 
> The change updates threads to use the root thread group and null context class loader.
> 
> A similar pattern is used here:
> https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.desktop/share/classes/com/sun/imageio/stream/StreamCloser.java#L89
> 
> @aivanov-jdk please take a look

Does anybody have some comments and/or suggestions?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5939


From prr at openjdk.java.net  Fri Oct 29 05:59:13 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Oct 2021 05:59:13 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <7tTf3myTJV-fC3OHL1XkeZXXKQj7zq1NFGQ_Hr5_7es=.f22c1949-4b7b-47a1-bd61-ea74cd603a23@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
 <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
 <7tTf3myTJV-fC3OHL1XkeZXXKQj7zq1NFGQ_Hr5_7es=.f22c1949-4b7b-47a1-bd61-ea74cd603a23@github.com>
Message-ID: <660weY84Lc9H6G0busF4XnbpBNC9luk_ijaPRjMjm7k=.500aafdc-a86b-4e13-99f9-d2d23b60625c@github.com>

On Fri, 29 Oct 2021 04:43:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > Regardless, there's value in the test updates, although my existing comments on the specifics there still stand.
> 
> Should I pursue with the test updates with this PR as it seems it can be addressed by product change? 

Yes.

I am not sure what specifics needs to be addressed...Are the below ones the one?

Whatever I wrote !
> 
> > And is an offset of 10 enough ? Its a bit arbitrary and cursors could be a larger shape or different orientation
> 
> SInce I am going in opposite direction of cursor by using (-10,-10) I guess it should be ok since normally cursor as shown in the screencapture, even if enlarged, willnot encroach on (-10, -10) area unless it's a inverted cursor wihch I am not sure exist or not.

So your assumption is the cursor is an arrow. It could be an X .. in which case your fix won't work of ots
anywhere near a 45 degree slope.
There's no 100% answer but a larger offset is better and parametrised like
// move away from cursor
OFFSET-X = -10
OFFSET_Y = -20
or  adding code that moves the cursor to window (0,0) before screen captutre .. 
> 
> > Shouldn't this use TESTCLASSES or something like that ?
> 
> We have used the same way of ImageIO.write() in jtreg tests

OK ..doesn't mean its right  please check with jtreg devs etc ..

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From psadhukhan at openjdk.java.net  Fri Oct 29 05:59:13 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 29 Oct 2021 05:59:13 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <A5GshhqI9WjWtrDmFo1A4zkpW_RKlqU-LSJfyVsBsHo=.3bbbab9e-031b-47a1-8ecc-e84e11d726d8@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
 <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
 <dKp8Ea_6Il-4VLaaT3kQfGonJpS7w-LuMWFWPa9Ut1c=.93395110-55ef-4d2d-8815-b79a7f2af6ed@github.com>
 <a3j0biwB6OX1N_kvwoJqs-fmxedQokoRrQ-fXkGjJ24=.8681a694-5f89-4a8b-a8eb-032c2e0fb1a8@github.com>
 <A5GshhqI9WjWtrDmFo1A4zkpW_RKlqU-LSJfyVsBsHo=.3bbbab9e-031b-47a1-8ecc-e84e11d726d8@github.com>
Message-ID: <GdWXn-rCxXKj4dTDC_VI59CMg79-xih_7TYCgNj18JI=.a8f0e537-489b-45eb-a2cf-d1ec74d29afc@github.com>

On Fri, 29 Oct 2021 05:38:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> but there are suspicious cases like using tolerance.

We have same test failure in macos-aarch64 in JDK-8266245 and I guess tolerance level of 5 should not be an issue. I was told earlier tolerance level of upto 15 should be acceptable..

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From psadhukhan at openjdk.java.net  Fri Oct 29 05:59:14 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 29 Oct 2021 05:59:14 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <660weY84Lc9H6G0busF4XnbpBNC9luk_ijaPRjMjm7k=.500aafdc-a86b-4e13-99f9-d2d23b60625c@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
 <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
 <7tTf3myTJV-fC3OHL1XkeZXXKQj7zq1NFGQ_Hr5_7es=.f22c1949-4b7b-47a1-bd61-ea74cd603a23@github.com>
 <660weY84Lc9H6G0busF4XnbpBNC9luk_ijaPRjMjm7k=.500aafdc-a86b-4e13-99f9-d2d23b60625c@github.com>
Message-ID: <BYSexNR1LJOaz7wpTGmBRre2abUZcrUxenAcs86FnD4=.b4f465ad-979f-4f9e-9797-69a77f7d8f9a@github.com>

On Fri, 29 Oct 2021 05:49:27 GMT, Phil Race <prr at openjdk.org> wrote:

> So your assumption is the cursor is an arrow. It could be an X .. in which case your fix won't work of ots

Can't we add instructions additionally similar to what we have in our test wiki to only have default arrow cursor. Also, since it is passing in this specific system and other CI platforms so it seems it's default anyway..

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From prr at openjdk.java.net  Fri Oct 29 05:59:14 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Oct 2021 05:59:14 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <A5GshhqI9WjWtrDmFo1A4zkpW_RKlqU-LSJfyVsBsHo=.3bbbab9e-031b-47a1-8ecc-e84e11d726d8@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
 <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
 <dKp8Ea_6Il-4VLaaT3kQfGonJpS7w-LuMWFWPa9Ut1c=.93395110-55ef-4d2d-8815-b79a7f2af6ed@github.com>
 <a3j0biwB6OX1N_kvwoJqs-fmxedQokoRrQ-fXkGjJ24=.8681a694-5f89-4a8b-a8eb-032c2e0fb1a8@github.com>
 <A5GshhqI9WjWtrDmFo1A4zkpW_RKlqU-LSJfyVsBsHo=.3bbbab9e-031b-47a1-8ecc-e84e11d726d8@github.com>
Message-ID: <pOxO9aN7a717Ql5ZXw7Jegr913RuYmxo98uX8gQsTgk=.75355d95-6067-4a1b-8f1a-6bd96768bcec@github.com>

On Fri, 29 Oct 2021 05:38:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Broader ? Please expand since the change you suggest is only about the cursor
> 
> This issue JDK-8276058 is broader than the cursor, related, this is why I would like to exclude it from it.

Still not explained. Broader why ?
> 
> > The test part of the fix has multiple stability improvements, and there's no reason to throw that out. And moving the pixel capture position to a more safe position is fine too. I just think that -10 isn't sa\fe enough.
> 
> Sure, I have no comments about the changes related to stability, but there are suspicious cases like using tolerance.

meaning -10 .. yes .. we can and should tweak that and if there's still an issue deal with it as it arises
> 
> > Who mentioned aarch64 ? Are you referring to you proposed change. I don't see the aarch64 connection anywhere FWIW the actual hardware on which this was seen is (I think) a 2013 Mac Pro running 10.15.7
> 
> I have mentioned that a few comments above, on aarch64 the cursor is always present on the screenshot, unlike x64. both systems are "similar".

I missed that but these failures are NOT seen on aarch64. If it was a feature there we'd have seen it.
We've tested on M1 imac and M1 macmini -- no problem. 
> 
> BTW I have found that the built-in screencapture tool has the ability to take a screenshot with and w/o cursor, so probably there is a way to specify that as well via some public API. Or maybe it is so fast that the cursor flickering is invisible.

I pointed that out earlier .. even before you raised the cursor size issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Fri Oct 29 06:04:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Oct 2021 06:04:10 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <GdWXn-rCxXKj4dTDC_VI59CMg79-xih_7TYCgNj18JI=.a8f0e537-489b-45eb-a2cf-d1ec74d29afc@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
 <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
 <dKp8Ea_6Il-4VLaaT3kQfGonJpS7w-LuMWFWPa9Ut1c=.93395110-55ef-4d2d-8815-b79a7f2af6ed@github.com>
 <a3j0biwB6OX1N_kvwoJqs-fmxedQokoRrQ-fXkGjJ24=.8681a694-5f89-4a8b-a8eb-032c2e0fb1a8@github.com>
 <A5GshhqI9WjWtrDmFo1A4zkpW_RKlqU-LSJfyVsBsHo=.3bbbab9e-031b-47a1-8ecc-e84e11d726d8@github.com>
 <GdWXn-rCxXKj4dTDC_VI59CMg79-xih_7TYCgNj18JI=.a8f0e537-489b-45eb-a2cf-d1ec74d29afc@github.com>
Message-ID: <k0W7DAQaMQG7hGoQqcgRvGSSofJQMliN8flIReU2tec=.050926db-ab5f-4243-a1a9-c2490fa181c2@github.com>

On Fri, 29 Oct 2021 05:49:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> We have same test failure in macos-aarch64 in JDK-8266245 and I guess tolerance level of 5 should not be an issue. I was told earlier tolerance level of upto 15 should be acceptable..

I do not like the tolerance approaches in general until we do not recognize the root cause of the wrong color. There were many cases in the past when the people said the issue was caused by the "broken driver"/"some non-default configuration"/ etc...etc. But in reality, the problem was caused by our code when we use the wrong color composite/ the wrong color profile/etc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Fri Oct 29 06:38:24 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Oct 2021 06:38:24 GMT
Subject: RFR: 8196017:
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
In-Reply-To: <wnm-YKKA9gtMKq75lwgp0FuCT4VbvaC_Fh1eJC3krR8=.4d08ec64-7140-4559-b051-987e3bea0a27@github.com>
References: <wnm-YKKA9gtMKq75lwgp0FuCT4VbvaC_Fh1eJC3krR8=.4d08ec64-7140-4559-b051-987e3bea0a27@github.com>
Message-ID: <hmXQnpW3WHN3zyKaYiVac87tk6BFlJSXu-2zA3z9Fj4=.3c89d006-976e-4520-90e3-dc52efb0d9b3@github.com>

On Wed, 27 Oct 2021 00:52:10 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> The problem here is that due to the approximation of the coordinates when converting
> to and from screen cordinate system on screen with 125% magnification 
> two things can happen:
> 1. New mouse position calculated can be 149/149 which is the same as the starting position
> and system can refuse to generate new mouse event which causes false positive of the test
> since second mouse motion listener was never called;
> 2. Even if event is generated the resulting reported coordinates can differ by 1 pixel
> in any of the directions;
> 
> To solve it i moved away the target point to make sure that move event always generated and
> comparing expected and actual coordinates with approximation of +/- 1 pixel.

I have tried to run this test on macOS as a standalone code, and it hangs. The second frame is never disposed and still visible on the screen, not sure why.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6128


From psadhukhan at openjdk.java.net  Fri Oct 29 06:43:38 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 29 Oct 2021 06:43:38 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v3]
In-Reply-To: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
Message-ID: <QhVV8XEk1m7hFhnnzwp4A1WnF-Yv1nqT8nMyrI1zS4M=.50a380db-f2b7-4965-a367-75e5eeb31515@github.com>

> As per JDK-8252813, some tests fails recurringly in CI macos system. This is an attempt to fix the swing tests.
> It was seen from the logs that we have color mismatch in these tests.
> 
> For example, in PressedIcon test, we had following log
> 
> ----------System.out:(1/75)----------
> color java.awt.Color[r=55,g=55,b=55] COLOR_1Xjava.awt.Color[r=255,g=0,b=0]
> ----------System.err:(13/842)----------
> java.lang.RuntimeException: Colors is different for scale=1!
> 	at PressedIconTest.main(PressedIconTest.java:97)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> 
> and JInternalFrame test, we had 
> ----------System.err:(15/939)----------
> FRAME_COLOR Red: 255; Green: 200; Blue: 0
> Pixel color Red: 55; Green: 55; Blue: 55
> java.lang.RuntimeException: Internal frame is not correctly dragged!
> 	at bug8069348.main(bug8069348.java:96)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:833)
> 
> where color is obtained as 55,55,55 instead of required color. The png image generated at failure also did not reveal anything abnormal apart from presence of mouse cursor around the same area where the getPixelColor location is pointing to. And since mouse cursor is also grayish black, it seems robot was wrongly picking up cursor pixels instead of background color.
> Modified tests to use location.x-10, location.y-10 to obtain the pixel color. It does not hamper the test as the whole area around the location is coloured with same color in the test so getting pixel color from a bit wide of the centre will not affect the test.
> Modified swing tests are passing in the affected system and also in other macos systems and platforms. Link in JBS.
> 
> The awt tests that are failing seems to have different root cause and will be handled separately.

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - Review fix
 - Fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6140/files
  - new: https://git.openjdk.java.net/jdk/pull/6140/files/077eb520..67ee7b3d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6140&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6140&range=01-02

  Stats: 36 lines in 6 files changed: 21 ins; 7 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6140.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6140/head:pull/6140

PR: https://git.openjdk.java.net/jdk/pull/6140


From prr at openjdk.java.net  Fri Oct 29 06:43:40 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Oct 2021 06:43:40 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <k0W7DAQaMQG7hGoQqcgRvGSSofJQMliN8flIReU2tec=.050926db-ab5f-4243-a1a9-c2490fa181c2@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
 <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
 <dKp8Ea_6Il-4VLaaT3kQfGonJpS7w-LuMWFWPa9Ut1c=.93395110-55ef-4d2d-8815-b79a7f2af6ed@github.com>
 <a3j0biwB6OX1N_kvwoJqs-fmxedQokoRrQ-fXkGjJ24=.8681a694-5f89-4a8b-a8eb-032c2e0fb1a8@github.com>
 <A5GshhqI9WjWtrDmFo1A4zkpW_RKlqU-LSJfyVsBsHo=.3bbbab9e-031b-47a1-8ecc-e84e11d726d8@github.com>
 <GdWXn-rCxXKj4dTDC_VI59CMg79-xih_7TYCgNj18JI=.a8f0e537-489b-45eb-a2cf-d1ec74d29afc@github.com>
 <k0W7DAQaMQG7hGoQqcgRvGSSofJQMliN8flIReU2tec=.050926db-ab5f-4243-a1a9-c2490fa181c2@github.com>
Message-ID: <0agnOLkQHumYCInfMx7P__sKaP9fp5MsncxCdujxWh0=.98073ee0-9af5-4f27-90b1-6b0815179025@github.com>

On Fri, 29 Oct 2021 06:00:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > We have same test failure in macos-aarch64 in JDK-8266245 and I guess tolerance level of 5 should not be an issue. I was told earlier tolerance level of upto 15 should be acceptable..
> 
> I do not like the tolerance approaches in general until we do not recognize the root cause of the wrong color. There were many cases in the past when the people said the issue was caused by the "broken driver"/"some non-default configuration"/ etc...etc. But in reality, the problem was caused by our code when we use the wrong color composite/ the wrong color profile/etc.

ah colour tolerance. We should not need that here. Should be an exact match

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From psadhukhan at openjdk.java.net  Fri Oct 29 06:43:41 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 29 Oct 2021 06:43:41 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <0agnOLkQHumYCInfMx7P__sKaP9fp5MsncxCdujxWh0=.98073ee0-9af5-4f27-90b1-6b0815179025@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
 <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
 <dKp8Ea_6Il-4VLaaT3kQfGonJpS7w-LuMWFWPa9Ut1c=.93395110-55ef-4d2d-8815-b79a7f2af6ed@github.com>
 <a3j0biwB6OX1N_kvwoJqs-fmxedQokoRrQ-fXkGjJ24=.8681a694-5f89-4a8b-a8eb-032c2e0fb1a8@github.com>
 <A5GshhqI9WjWtrDmFo1A4zkpW_RKlqU-LSJfyVsBsHo=.3bbbab9e-031b-47a1-8ecc-e84e11d726d8@github.com>
 <GdWXn-rCxXKj4dTDC_VI59CMg79-xih_7TYCgNj18JI=.a8f0e537-489b-45eb-a2cf-d1ec74d29afc@github.com>
 <k0W7DAQaMQG7hGoQqcgRvGSSofJQMliN8flIReU2tec=.050926db-ab5f-4243-a1a9-c2490fa181c2@github.com>
 <0agnOLkQHumYCInfMx7P__sKaP9fp5MsncxCdujxWh0=.98073ee0-9af5-4f27-90b1-6b0815179025@github.com>
Message-ID: <tHuYqVIkalgcT294XR7qElCGa4UNDqV98o9iJC_lKjQ=.cb157907-8c69-484c-ab4b-1ff6cb6decdc@github.com>

On Fri, 29 Oct 2021 06:06:31 GMT, Phil Race <prr at openjdk.org> wrote:

> 
> 
> > > We have same test failure in macos-aarch64 in JDK-8266245 and I guess tolerance level of 5 should not be an issue. I was told earlier tolerance level of upto 15 should be acceptable..
> > 
> > 
> > I do not like the tolerance approaches in general until we do not recognize the root cause of the wrong color. There were many cases in the past when the people said the issue was caused by the "broken driver"/"some non-default configuration"/ etc...etc. But in reality, the problem was caused by our code when we use the wrong color composite/ the wrong color profile/etc.
> 
> ah colour tolerance. We should not need that here. Should be an exact match

OK. I see this test is problemlisted for windows,linux,mac-aarch64 maybe we can problemlist for macos-all too with 8266245  as the main bug.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From psadhukhan at openjdk.java.net  Fri Oct 29 06:43:42 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 29 Oct 2021 06:43:42 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <660weY84Lc9H6G0busF4XnbpBNC9luk_ijaPRjMjm7k=.500aafdc-a86b-4e13-99f9-d2d23b60625c@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
 <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
 <7tTf3myTJV-fC3OHL1XkeZXXKQj7zq1NFGQ_Hr5_7es=.f22c1949-4b7b-47a1-bd61-ea74cd603a23@github.com>
 <660weY84Lc9H6G0busF4XnbpBNC9luk_ijaPRjMjm7k=.500aafdc-a86b-4e13-99f9-d2d23b60625c@github.com>
Message-ID: <C5WJbb_hPttjG6G_wq32jeewFvLKSy9OJ8wtwHGRoU0=.5f111a7d-69d6-431f-b4b5-f5ac9c362bd5@github.com>

On Fri, 29 Oct 2021 05:49:27 GMT, Phil Race <prr at openjdk.org> wrote:

> 
> 
>         Shouldn't this use TESTCLASSES or something like that ?
> 
>     We have used the same way of ImageIO.write() in jtreg tests
> 
> OK ..doesn't mean its right please check with jtreg devs etc ..

If it's not right, then we have to change at so many files..All files uses the same approach so I followed...Where to ask? not sure about jtreg devs contact?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Fri Oct 29 06:43:44 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Oct 2021 06:43:44 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <pOxO9aN7a717Ql5ZXw7Jegr913RuYmxo98uX8gQsTgk=.75355d95-6067-4a1b-8f1a-6bd96768bcec@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
 <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
 <dKp8Ea_6Il-4VLaaT3kQfGonJpS7w-LuMWFWPa9Ut1c=.93395110-55ef-4d2d-8815-b79a7f2af6ed@github.com>
 <a3j0biwB6OX1N_kvwoJqs-fmxedQokoRrQ-fXkGjJ24=.8681a694-5f89-4a8b-a8eb-032c2e0fb1a8@github.com>
 <A5GshhqI9WjWtrDmFo1A4zkpW_RKlqU-LSJfyVsBsHo=.3bbbab9e-031b-47a1-8ecc-e84e11d726d8@github.com>
 <pOxO9aN7a717Ql5ZXw7Jegr913RuYmxo98uX8gQsTgk=.75355d95-6067-4a1b-8f1a-6bd96768bcec@github.com>
Message-ID: <mS6AfN7CH0Z-c0mIUd1VhQdxYud-jjPv_EsrwWTqN54=.dc43a00c-982e-4ee6-b0b1-e02a69291549@github.com>

On Fri, 29 Oct 2021 05:56:06 GMT, Phil Race <prr at openjdk.org> wrote:

> I pointed that out earlier .. even before you raised the cursor size issue.

Missed that, and still cannot find it by searching the discussion above, I probably need to rest

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From psadhukhan at openjdk.java.net  Fri Oct 29 06:43:45 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 29 Oct 2021 06:43:45 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <mS6AfN7CH0Z-c0mIUd1VhQdxYud-jjPv_EsrwWTqN54=.dc43a00c-982e-4ee6-b0b1-e02a69291549@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
 <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
 <dKp8Ea_6Il-4VLaaT3kQfGonJpS7w-LuMWFWPa9Ut1c=.93395110-55ef-4d2d-8815-b79a7f2af6ed@github.com>
 <a3j0biwB6OX1N_kvwoJqs-fmxedQokoRrQ-fXkGjJ24=.8681a694-5f89-4a8b-a8eb-032c2e0fb1a8@github.com>
 <A5GshhqI9WjWtrDmFo1A4zkpW_RKlqU-LSJfyVsBsHo=.3bbbab9e-031b-47a1-8ecc-e84e11d726d8@github.com>
 <pOxO9aN7a717Ql5ZXw7Jegr913RuYmxo98uX8gQsTgk=.75355d95-6067-4a1b-8f1a-6bd96768bcec@github.com>
 <mS6AfN7CH0Z-c0mIUd1VhQdxYud-jjPv_EsrwWTqN54=.dc43a00c-982e-4ee6-b0b1-e02a69291549@github.com>
Message-ID: <ALs6x7q-rxQqyklVbTAleHUdnNZSJTA-3-h6XRF5zXc=.eb8233f8-722d-427d-a5be-8524738739fc@github.com>

On Fri, 29 Oct 2021 06:11:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> 
> 
> > I pointed that out earlier .. even before you raised the cursor size issue.
> 
> Missed that, and still cannot find it by searching the discussion above, I probably need to rest

It was added as part of https://bugs.openjdk.java.net/browse/JDK-8252813 comment mentionedin this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Fri Oct 29 07:03:13 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Oct 2021 07:03:13 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <ALs6x7q-rxQqyklVbTAleHUdnNZSJTA-3-h6XRF5zXc=.eb8233f8-722d-427d-a5be-8524738739fc@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
 <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
 <dKp8Ea_6Il-4VLaaT3kQfGonJpS7w-LuMWFWPa9Ut1c=.93395110-55ef-4d2d-8815-b79a7f2af6ed@github.com>
 <a3j0biwB6OX1N_kvwoJqs-fmxedQokoRrQ-fXkGjJ24=.8681a694-5f89-4a8b-a8eb-032c2e0fb1a8@github.com>
 <A5GshhqI9WjWtrDmFo1A4zkpW_RKlqU-LSJfyVsBsHo=.3bbbab9e-031b-47a1-8ecc-e84e11d726d8@github.com>
 <pOxO9aN7a717Ql5ZXw7Jegr913RuYmxo98uX8gQsTgk=.75355d95-6067-4a1b-8f1a-6bd96768bcec@github.com>
 <mS6AfN7CH0Z-c0mIUd1VhQdxYud-jjPv_EsrwWTqN54=.dc43a00c-982e-4ee6-b0b1-e02a69291549@github.com>
 <ALs6x7q-rxQqyklVbTAleHUdnNZSJTA-3-h6XRF5zXc=.eb8233f8-722d-427d-a5be-8524738739fc@github.com>
Message-ID: <brqOhMJXjddG9QYQzgj1qSoZFae3WJd5r5JmmpYOPRM=.4d3808fb-74cf-4048-a921-4a02a9f1395e@github.com>

On Fri, 29 Oct 2021 06:41:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It was added as part of https://bugs.openjdk.java.net/browse/JDK-8252813 comment mentionedin this PR.

So it is even a different bug =(..
Looks like that comment was about using some shortcuts and options, I was talking about using "screencapture" tool in the command line and just passing or skipping the -C option, so it is easy to check how the cursor behaves during screen capture.
So I think the best next step is to report it to Apple as I suggested and get some feedback.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From prr at openjdk.java.net  Fri Oct 29 07:03:13 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Oct 2021 07:03:13 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <ALs6x7q-rxQqyklVbTAleHUdnNZSJTA-3-h6XRF5zXc=.eb8233f8-722d-427d-a5be-8524738739fc@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
 <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
 <dKp8Ea_6Il-4VLaaT3kQfGonJpS7w-LuMWFWPa9Ut1c=.93395110-55ef-4d2d-8815-b79a7f2af6ed@github.com>
 <a3j0biwB6OX1N_kvwoJqs-fmxedQokoRrQ-fXkGjJ24=.8681a694-5f89-4a8b-a8eb-032c2e0fb1a8@github.com>
 <A5GshhqI9WjWtrDmFo1A4zkpW_RKlqU-LSJfyVsBsHo=.3bbbab9e-031b-47a1-8ecc-e84e11d726d8@github.com>
 <pOxO9aN7a717Ql5ZXw7Jegr913RuYmxo98uX8gQsTgk=.75355d95-6067-4a1b-8f1a-6bd96768bcec@github.com>
 <mS6AfN7CH0Z-c0mIUd1VhQdxYud-jjPv_EsrwWTqN54=.dc43a00c-982e-4ee6-b0b1-e02a69291549@github.com>
 <ALs6x7q-rxQqyklVbTAleHUdnNZSJTA-3-h6XRF5zXc=.eb8233f8-722d-427d-a5be-8524738739fc@github.com>
Message-ID: <o07u5I6L3-iiVUNwW_TnnF_38DnwAZO_NwI4fiAuR3s=.f0e29743-c4d3-43b2-b82d-f28bc72e2084@github.com>

On Fri, 29 Oct 2021 06:41:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > I pointed that out earlier .. even before you raised the cursor size issue.
> 
> Missed that, and still cannot find it by searching the discussion above, I probably need to rest

I had written (above many hours ago) -

See the comment I just added to https://bugs.openjdk.java.net/browse/JDK-8252813.

It still needs verification to see if it affects the macOS API used. But it seems probable something like that is going on.
Regardless I think we may need to revise the Robot spec a little ...  I don't know why it is so insistent that the cursor is NOT captured since it seems something outside control of the Robot ..

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From prr at openjdk.java.net  Fri Oct 29 07:03:13 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Oct 2021 07:03:13 GMT
Subject: RFR: 8276058: Some swing test fails on specific CI macos system
 [v2]
In-Reply-To: <brqOhMJXjddG9QYQzgj1qSoZFae3WJd5r5JmmpYOPRM=.4d3808fb-74cf-4048-a921-4a02a9f1395e@github.com>
References: <MMoyBnlu-gaVqSvFR0_kTsmMd33gnfhOYkFojF5Rx88=.6e841f93-f021-4933-8772-a2e8728610dc@github.com>
 <b0ykIN6hbXWngO6AEQ0wTW3QdwJSj2AXHEhb2L3sSD0=.1a23c852-43fa-4b4b-a415-b87f0b014104@github.com>
 <THBHP3Th4y1YTluEC9ggpcNmmMbxmzw0Llwj4VPokvU=.a9f1b7b0-d372-4b51-b3f6-146a3cdff1da@github.com>
 <RBK6dQOG_IMERMy_QjW1PYaKVkIUi3sUTUcIR3ljwNI=.c434a87c-ca48-47f0-8ad1-4ceee8f84ac7@github.com>
 <dKp8Ea_6Il-4VLaaT3kQfGonJpS7w-LuMWFWPa9Ut1c=.93395110-55ef-4d2d-8815-b79a7f2af6ed@github.com>
 <a3j0biwB6OX1N_kvwoJqs-fmxedQokoRrQ-fXkGjJ24=.8681a694-5f89-4a8b-a8eb-032c2e0fb1a8@github.com>
 <A5GshhqI9WjWtrDmFo1A4zkpW_RKlqU-LSJfyVsBsHo=.3bbbab9e-031b-47a1-8ecc-e84e11d726d8@github.com>
 <pOxO9aN7a717Ql5ZXw7Jegr913RuYmxo98uX8gQsTgk=.75355d95-6067-4a1b-8f1a-6bd96768bcec@github.com>
 <mS6AfN7CH0Z-c0mIUd1VhQdxYud-jjPv_EsrwWTqN54=.dc43a00c-982e-4ee6-b0b1-e02a69291549@github.com>
 <ALs6x7q-rxQqyklVbTAleHUdnNZSJTA-3-h6XRF5zXc=.eb8233f8-722d-427d-a5be-8524738739fc@github.com>
 <brqOhMJXjddG9QYQzgj1qSoZFae3WJd5r5J
 mmpYOPRM=.4d3808fb-74cf-4048-a921-4a02a9f1395e@github.com>
Message-ID: <BlLetcx0Xmmi4THrtyhioaD1NF8r8hQHneEG0ArfAc8=.c85cb824-8f0a-4748-ac58-e3ad69489a8d@github.com>

On Fri, 29 Oct 2021 06:56:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > It was added as part of https://bugs.openjdk.java.net/browse/JDK-8252813 comment mentionedin this PR.
> 
> So it is even a different bug =(.. Looks like that comment was about using some shortcuts and options, I was talking about using "screencapture" tool in the command line and just passing or skipping the -C option, so it is easy to check how the cursor behaves during screen capture. So I think the best next step is to report it to Apple as I suggested and get some feedback.

- No it is the same thing - the shorcut was just the mechanism to pull up the settings dialog.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6140


From serb at openjdk.java.net  Fri Oct 29 07:08:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Oct 2021 07:08:10 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException
In-Reply-To: <0OrjZzeb7XifWJIH2jmrFAXflWPbagiJN7QvT8LA7XU=.dfb665f3-70c7-40c6-ba19-5b945337c446@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <0OrjZzeb7XifWJIH2jmrFAXflWPbagiJN7QvT8LA7XU=.dfb665f3-70c7-40c6-ba19-5b945337c446@github.com>
Message-ID: <_OEX7MVVvmpNuJ_huZyibp5iboMLLQAtsfi9Y5NAWnA=.2185e9c7-e33e-4308-a805-8acfaee39e1c@github.com>

On Thu, 28 Oct 2021 14:30:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Could you please review the 8262297 bug fixes?
>> 
>> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.
>
> src/java.base/share/classes/java/io/RandomAccessFile.java line 558:
> 
>> 556:      * @throws     IndexOutOfBoundsException If {@code off} is negative,
>> 557:      *             {@code len} is negative, or {@code len} is greater than
>> 558:      *             {@code b.length - off}
> 
> The IOOBE is specified in the super interface, it's just not shown in the javadoc because it's a runtime exception. So I think what you want here is:
> 
> @throws IndexOutOfBoundsException  {@inheritDoc}

Unfortunately the parent class does not specify this exception via javadoc tags like "@throws IndexOutOfBoundsException", but instead just describe it in the method description

should we fix it separately from the imageio fix?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6151


From alanb at openjdk.java.net  Fri Oct 29 07:16:14 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 29 Oct 2021 07:16:14 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException
In-Reply-To: <_OEX7MVVvmpNuJ_huZyibp5iboMLLQAtsfi9Y5NAWnA=.2185e9c7-e33e-4308-a805-8acfaee39e1c@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <0OrjZzeb7XifWJIH2jmrFAXflWPbagiJN7QvT8LA7XU=.dfb665f3-70c7-40c6-ba19-5b945337c446@github.com>
 <_OEX7MVVvmpNuJ_huZyibp5iboMLLQAtsfi9Y5NAWnA=.2185e9c7-e33e-4308-a805-8acfaee39e1c@github.com>
Message-ID: <qIp7X9Q1_K7UY3ahGLv4fXFFKSU4dBQssU8YWPKQ7Bg=.22b421d7-c0d7-476b-85c5-00b8e4e7d34a@github.com>

On Fri, 29 Oct 2021 07:01:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Unfortunately the parent class does not specify this exception via javadoc tags like "@throws IndexOutOfBoundsException", but instead just describe it in the method description
> 
> should we fix it separately from the imageio fix?

Yes, it might be better to separate them because we'll like need a CSR if we are missing @throws in a few places.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6151


From prr at openjdk.java.net  Fri Oct 29 07:35:11 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Oct 2021 07:35:11 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException
In-Reply-To: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
Message-ID: <3wcxnoPDynz6rpC7AkYvZyJhxPVMiVCS3j-ZTmuHuh4=.de6ee1b1-baa6-4015-b22a-089ad70af582@github.com>

On Thu, 28 Oct 2021 09:29:13 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the 8262297 bug fixes?
> 
> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.

This needs looking at closely .. I don't know what's best but the imaging APIs are very exception heavy because of the arrays, indices, you name it that they consume. Most of the time its probably best for an IIO user to just get an IIOException wrapping the original cause. But there could be exceptions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6151


From serb at openjdk.java.net  Fri Oct 29 08:54:13 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Oct 2021 08:54:13 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac [v3]
In-Reply-To: <ofIFdTzW7sfrx6RG3JohvCLh4fNbWjM1KnnCaf1TywA=.3941f3bd-593a-40b1-b464-09f5896dc608@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
 <ofIFdTzW7sfrx6RG3JohvCLh4fNbWjM1KnnCaf1TywA=.3941f3bd-593a-40b1-b464-09f5896dc608@github.com>
Message-ID: <3Kl9kbCTfV4xFoIU-NPqX-hfv4BeRZunSNBBuZf8OjM=.6bbb1e5c-2558-4a31-a6df-fac8a8da429d@github.com>

On Thu, 28 Oct 2021 09:47:44 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Moved Swing component modification to the EDT.
>> Increased wait time for popup to show up.
>> Made checking variabled volatile.
>> Generic code cleanup.
>> Removed the test from ProblemList.txt
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved components instantiation to the EDT

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6104


From psadhukhan at openjdk.java.net  Fri Oct 29 09:04:12 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 29 Oct 2021 09:04:12 GMT
Subject: RFR: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac [v3]
In-Reply-To: <ofIFdTzW7sfrx6RG3JohvCLh4fNbWjM1KnnCaf1TywA=.3941f3bd-593a-40b1-b464-09f5896dc608@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
 <ofIFdTzW7sfrx6RG3JohvCLh4fNbWjM1KnnCaf1TywA=.3941f3bd-593a-40b1-b464-09f5896dc608@github.com>
Message-ID: <U3bQZXNvWiKBtU_jC4VANaR-JpYmsDeu4zwhbuM2hvw=.f66b4578-0821-471e-ba81-a38b3deb2f8a@github.com>

On Thu, 28 Oct 2021 09:47:44 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Moved Swing component modification to the EDT.
>> Increased wait time for popup to show up.
>> Made checking variabled volatile.
>> Generic code cleanup.
>> Removed the test from ProblemList.txt
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved components instantiation to the EDT

test/jdk/javax/swing/JPopupMenu/4634626/bug4634626.java line 124:

> 122:                 popButton.setComponentPopupMenu(btnPopup);
> 123:                 popButton.setComponentPopupMenu(null);
> 124:             } catch (Exception ex) {

setComponentPopupMenu spec doesn't throw any Exception so I guess we can remove this try block. Anyway init() signature have "throws" signature

-------------

PR: https://git.openjdk.java.net/jdk/pull/6104


From kizune at openjdk.java.net  Fri Oct 29 09:24:29 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 29 Oct 2021 09:24:29 GMT
Subject: RFR: 8196017:
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails [v2]
In-Reply-To: <wnm-YKKA9gtMKq75lwgp0FuCT4VbvaC_Fh1eJC3krR8=.4d08ec64-7140-4559-b051-987e3bea0a27@github.com>
References: <wnm-YKKA9gtMKq75lwgp0FuCT4VbvaC_Fh1eJC3krR8=.4d08ec64-7140-4559-b051-987e3bea0a27@github.com>
Message-ID: <oM6I9fx4ZINh_b2ttlDfcBRV3g1AfBwYEFuVVHYy9no=.665db928-2842-462b-bcb8-6f623a39becd@github.com>

> The problem here is that due to the approximation of the coordinates when converting
> to and from screen cordinate system on screen with 125% magnification 
> two things can happen:
> 1. New mouse position calculated can be 149/149 which is the same as the starting position
> and system can refuse to generate new mouse event which causes false positive of the test
> since second mouse motion listener was never called;
> 2. Even if event is generated the resulting reported coordinates can differ by 1 pixel
> in any of the directions;
> 
> To solve it i moved away the target point to make sure that move event always generated and
> comparing expected and actual coordinates with approximation of +/- 1 pixel.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Protect from second mouse move image invocation.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6128/files
  - new: https://git.openjdk.java.net/jdk/pull/6128/files/7a74a153..7dc23067

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6128&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6128&range=00-01

  Stats: 4 lines in 1 file changed: 3 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6128.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6128/head:pull/6128

PR: https://git.openjdk.java.net/jdk/pull/6128


From kizune at openjdk.java.net  Fri Oct 29 09:24:30 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 29 Oct 2021 09:24:30 GMT
Subject: RFR: 8196017:
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
In-Reply-To: <hmXQnpW3WHN3zyKaYiVac87tk6BFlJSXu-2zA3z9Fj4=.3c89d006-976e-4520-90e3-dc52efb0d9b3@github.com>
References: <wnm-YKKA9gtMKq75lwgp0FuCT4VbvaC_Fh1eJC3krR8=.4d08ec64-7140-4559-b051-987e3bea0a27@github.com>
 <hmXQnpW3WHN3zyKaYiVac87tk6BFlJSXu-2zA3z9Fj4=.3c89d006-976e-4520-90e3-dc52efb0d9b3@github.com>
Message-ID: <TTmkbDrcIgizyJFzUgAcRLpcgm6DsJ9DuEn-V9uEouY=.631b4c98-90b0-44ab-8cd7-f8e6dd58d4a9@github.com>

On Fri, 29 Oct 2021 06:34:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I have tried to run this test on macOS as a standalone code, and it hangs. The second frame is never disposed and still visible on the screen, not sure why.

Yep, it works fine running from JavaTest but hangs when running from IDE, looks like extra mouseMove event being generated and we create extra frame. Luckily, that's easy to fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6128


From myano at openjdk.java.net  Fri Oct 29 09:32:14 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 29 Oct 2021 09:32:14 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException
In-Reply-To: <qIp7X9Q1_K7UY3ahGLv4fXFFKSU4dBQssU8YWPKQ7Bg=.22b421d7-c0d7-476b-85c5-00b8e4e7d34a@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <0OrjZzeb7XifWJIH2jmrFAXflWPbagiJN7QvT8LA7XU=.dfb665f3-70c7-40c6-ba19-5b945337c446@github.com>
 <_OEX7MVVvmpNuJ_huZyibp5iboMLLQAtsfi9Y5NAWnA=.2185e9c7-e33e-4308-a805-8acfaee39e1c@github.com>
 <qIp7X9Q1_K7UY3ahGLv4fXFFKSU4dBQssU8YWPKQ7Bg=.22b421d7-c0d7-476b-85c5-00b8e4e7d34a@github.com>
Message-ID: <8My9Dw1ePGmnvCilFii5I7GWt3YjwW8kiDL2xATr4pU=.d6e738c4-a7a7-4f44-8458-272e40fe96fe@github.com>

On Fri, 29 Oct 2021 07:13:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Unfortunately the parent class does not specify this exception via javadoc tags like "@throws IndexOutOfBoundsException", but instead just describe it in the method description
>> 
>> should we fix it separately from the imageio fix?
>
>> Unfortunately the parent class does not specify this exception via javadoc tags like "@throws IndexOutOfBoundsException", but instead just describe it in the method description
>> 
>> should we fix it separately from the imageio fix?
> 
> Yes, it might be better to separate them because we'll like need a CSR if we are missing @throws in a few places.

I understood to separate javadoc fix. I will remove the javadoc fix from this PR and issue another Bug ID.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6151


From myano at openjdk.java.net  Fri Oct 29 09:36:37 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 29 Oct 2021 09:36:37 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v2]
In-Reply-To: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
Message-ID: <lF81OlMpNiQGv1Xa3KbRbZ78ge_0XTCXiFRWjf4iygE=.4bca2e40-255f-4a8d-b6b5-8d1f23d0fd87@github.com>

> Could you please review the 8262297 bug fixes?
> 
> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.

Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:

  8262297: ImageIO.write() method will throw IndexOutOfBoundsException

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6151/files
  - new: https://git.openjdk.java.net/jdk/pull/6151/files/d6a652fa..08b54fff

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6151&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6151&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6151.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6151/head:pull/6151

PR: https://git.openjdk.java.net/jdk/pull/6151


From alanb at openjdk.java.net  Fri Oct 29 09:50:12 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 29 Oct 2021 09:50:12 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v2]
In-Reply-To: <8My9Dw1ePGmnvCilFii5I7GWt3YjwW8kiDL2xATr4pU=.d6e738c4-a7a7-4f44-8458-272e40fe96fe@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <0OrjZzeb7XifWJIH2jmrFAXflWPbagiJN7QvT8LA7XU=.dfb665f3-70c7-40c6-ba19-5b945337c446@github.com>
 <_OEX7MVVvmpNuJ_huZyibp5iboMLLQAtsfi9Y5NAWnA=.2185e9c7-e33e-4308-a805-8acfaee39e1c@github.com>
 <qIp7X9Q1_K7UY3ahGLv4fXFFKSU4dBQssU8YWPKQ7Bg=.22b421d7-c0d7-476b-85c5-00b8e4e7d34a@github.com>
 <8My9Dw1ePGmnvCilFii5I7GWt3YjwW8kiDL2xATr4pU=.d6e738c4-a7a7-4f44-8458-272e40fe96fe@github.com>
Message-ID: <GuBHsz12dvBW1T7a_cb2GlGaT59oXm0L98SZzHV7sgc=.d8ccf508-1719-45b7-908c-72c76c24632d@github.com>

On Fri, 29 Oct 2021 09:28:57 GMT, Masanori Yano <myano at openjdk.org> wrote:

>>> Unfortunately the parent class does not specify this exception via javadoc tags like "@throws IndexOutOfBoundsException", but instead just describe it in the method description
>>> 
>>> should we fix it separately from the imageio fix?
>> 
>> Yes, it might be better to separate them because we'll like need a CSR if we are missing @throws in a few places.
>
> I understood to separate javadoc fix. I will remove the javadoc fix from this PR and issue another Bug ID.

Thanks, this means this PR will be image I/O only so I'll remove the core-libs label.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6151


From aivanov at openjdk.java.net  Fri Oct 29 09:52:09 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 29 Oct 2021 09:52:09 GMT
Subject: RFR: 8273831: PrintServiceLookup spawns 2 threads in the current
 classloader, getting orphaned
In-Reply-To: <eXuUD3WLjn4xv-R9bL_xU0tXyZV3HVNLpliZLBX9yFM=.1398debc-971a-4013-bbef-17e388a944d5@github.com>
References: <eXuUD3WLjn4xv-R9bL_xU0tXyZV3HVNLpliZLBX9yFM=.1398debc-971a-4013-bbef-17e388a944d5@github.com>
Message-ID: <wG4LTv1th8JmfFXPmt_lz6b24xXV7WcfDGUXvxoh4gk=.73f8110a-b525-4e3f-8670-dad38af40141@github.com>

On Thu, 14 Oct 2021 05:43:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The PrintServiceLookupProvider can spawn 2 threads on WIndows and one thread on Linux. These threads are connected to the classloader of the web application.  During undeployment the app classloader gets removed together with the two orphaned threads by the Tomcat. 
> 
> Looks like the tomcat has special machinery to workaround such threads:
> https://cwiki.apache.org/confluence/display/tomcat/MemoryLeakProtection#MemoryLeakProtection-cclThreadSpawnedByJRE
> But it should be updated each time we add/update/rename the threads in the JDK. So JreMemoryLeakPreventionListener can be updated to solve this problem, but it will be good to reset the ref to the app class loader as we usually do for our internal threads. 
> 
> The change updates threads to use the root thread group and null context class loader.
> 
> A similar pattern is used here:
> https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.desktop/share/classes/com/sun/imageio/stream/StreamCloser.java#L89
> 
> @aivanov-jdk please take a look

Marked as reviewed by aivanov (Reviewer).

Sorry for my delayed review, looks good to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5939


From kizune at openjdk.java.net  Fri Oct 29 11:47:14 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 29 Oct 2021 11:47:14 GMT
Subject: Integrated: 8017175: [TESTBUG]
 javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac
In-Reply-To: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
References: <_IIovninCEO2wwm6PpO-_nq1m3fhe9ADeUw_IiZckM8=.b69b0941-1240-4785-bec6-0117ed8f30bc@github.com>
Message-ID: <ywcUSyWOFug1CnxZ0YRJlIFhBIYwOwYjyeTkB5-CWVE=.ce1edb3c-2983-4111-ac85-b48c4ef8d5b3@github.com>

On Mon, 25 Oct 2021 12:23:15 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Moved Swing component modification to the EDT.
> Increased wait time for popup to show up.
> Made checking variabled volatile.
> Generic code cleanup.
> Removed the test from ProblemList.txt

This pull request has now been integrated.

Changeset: 4c3491bf
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4c3491bfa5f296b80c56a37cb4fffd6497323ac2
Stats:     114 lines in 2 files changed: 53 ins; 14 del; 47 mod

8017175: [TESTBUG] javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/6104


From azvegint at openjdk.java.net  Fri Oct 29 13:09:13 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 29 Oct 2021 13:09:13 GMT
Subject: Integrated: 6854300: [TEST_BUG]
 java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java fails in
 jdk6u14 & jdk7
In-Reply-To: <iz42ZewWVcIUIceWpXSSPpeFHd1aMd38D9vVtWuZLxw=.f65d3bb9-0165-45e2-80f8-a5c8ce20597f@github.com>
References: <iz42ZewWVcIUIceWpXSSPpeFHd1aMd38D9vVtWuZLxw=.f65d3bb9-0165-45e2-80f8-a5c8ce20597f@github.com>
Message-ID: <nJ-wOnIvrEeYGx-sLdqL7r6lmJ3IwlDv-5EjSozz6Os=.a69a9746-0316-4554-907f-96bce094387f@github.com>

On Thu, 28 Oct 2021 20:20:04 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Test trying to call `button.getLocationOnScreen()` when its frame not yet fully configured, so the obtained button location is shifted by window's height. 
> 
> Waiting a bit after `setVisible()` call fixes the issue. Some cleanup was made also. Testing is green on all platforms.

This pull request has now been integrated.

Changeset: a1ec4f96
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a1ec4f961841fe0b580c32b37c77e3906ba66966
Stats:     84 lines in 2 files changed: 37 ins; 1 del; 46 mod

6854300: [TEST_BUG] java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java fails in jdk6u14 & jdk7

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/6164


From mchung at openjdk.java.net  Fri Oct 29 16:35:23 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 29 Oct 2021 16:35:23 GMT
Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the
 java.util.logging
In-Reply-To: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
References: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
Message-ID: <DHI5YMCid9Tv-5Fd4KuFDA6i8GXIn0t5FJRGciK3KIE=.76d5b585-ec04-4d7e-8364-e2f07d888df4@github.com>

On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> At the time Java supported applets and webstart, a special mechanism for launching various applications in one JVM was used to reduce memory usage and each application was isolated from each other.
> 
> This isolation was implemented via ThreadGroups where each application created its own thread group and all data for the application was stored in the context of its own group.
> 
> Some parts of the JDK used ThreadGroups directly, others used special classes like sun.awt.AppContext.
> 
> Such sandboxing became useless since the plugin and webstart are no longer supported and were removed in jdk11.
> 
> Note that this is just a first step for the overall cleanup, here is my plan:
> 1. Cleanup the usage of AppContext in the ?java.util.logging.LogManager" class in the java.base module.
> 2. Cleanup the usage of TheadGroup in the JavaSound
> 3. Cleanup the usage of TheadGroup in the JavaBeans
> 4. Cleanup the usage of AppContext in the Swing
> 5. Cleanup the usage of AppContext in the AWT
> 6. Delete the AppContext class.
> 
> The current PR is for the first step. So this is the request to delete the usage of AppContext in the LogManager and related tests.
> 
> Tested by tier1/tier2/tier3 and jdk_desktop tests.

The change looks okay.   My suggestion is to get 1-6 all ready to push around the same time.  It's okay to have separate JBS issues and PRs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5326


From prr at openjdk.java.net  Fri Oct 29 16:50:12 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Oct 2021 16:50:12 GMT
Subject: RFR: 8262297: ImageIO.write() method will throw
 IndexOutOfBoundsException [v2]
In-Reply-To: <lF81OlMpNiQGv1Xa3KbRbZ78ge_0XTCXiFRWjf4iygE=.4bca2e40-255f-4a8d-b6b5-8d1f23d0fd87@github.com>
References: <vszp4geaJoxkN4AubUKf-6xRLVPDWm29RP7x913jFKk=.95722585-a157-4f36-b15e-bce51f4a5900@github.com>
 <lF81OlMpNiQGv1Xa3KbRbZ78ge_0XTCXiFRWjf4iygE=.4bca2e40-255f-4a8d-b6b5-8d1f23d0fd87@github.com>
Message-ID: <0OV-4vyqgUJWui7IfJ5VuqLjrD7WYmHRiv7-xYSW-DQ=.ade14fff-9c56-47c5-9954-bbb6eef539ad@github.com>

On Fri, 29 Oct 2021 09:36:37 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Could you please review the 8262297 bug fixes?
>> 
>> In this case, ImageIO.write() should throw java.io.IOException rather than java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and wrapped in IIOException in ImageIO.write() with this fix. In addition, IndexOutOfBoundsException is not expected to throw by RandomAccessFile#write() according to its API specification. So it should be fixed.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8262297: ImageIO.write() method will throw IndexOutOfBoundsException

I am not sure that this is the right thing at all here. You need to dig deeper.
- If Image I/O reads the png and constructs a BufferedImage, then that BufferedImage ought to be valid.
- If a valid image is written I would NOT expect an exception so catching it isn't the answer, fixing it is.

- If the image being read is "truncated" so that the BufferedImage isn't valid, why was there no exception from read ?
- If we do have an invalid BufferedImage then, in that case, we may indeed expect that write might throw an exception which needs to be caught but IIOBE is just one thing that could go wrong, isn't it ?

So for me this starts with the read, and a proper explanation of what happens there, and then an explanation as to what is wrong with the BufferedImage. I have no interest in slapping a sticking plaster on the observed symptom. It needs to be root cause explained and fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6151


From duke at openjdk.java.net  Fri Oct 29 20:02:27 2021
From: duke at openjdk.java.net (Alisen Chung)
Date: Fri, 29 Oct 2021 20:02:27 GMT
Subject: RFR: 8159451: [TEST_BUG]
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java
Message-ID: <spn83vBFx_i1HAc9XDeWfwu2EozpYl4eMGHnX3WXhqM=.ef1ba9ba-1605-4d96-bdec-f41bf702686f@github.com>

Added more time to test, removed pixel check during EmbeddedFrame test from OverlappingTestBase.

-------------

Commit messages:
 - removed from ProblemList
 - 8159451: [TEST_BUG] java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java

Changes: https://git.openjdk.java.net/jdk/pull/6177/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6177&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8159451
  Stats: 6 lines in 3 files changed: 3 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6177.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6177/head:pull/6177

PR: https://git.openjdk.java.net/jdk/pull/6177


From prr at openjdk.java.net  Fri Oct 29 21:33:14 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Oct 2021 21:33:14 GMT
Subject: RFR: 8159451: [TEST_BUG]
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java
In-Reply-To: <spn83vBFx_i1HAc9XDeWfwu2EozpYl4eMGHnX3WXhqM=.ef1ba9ba-1605-4d96-bdec-f41bf702686f@github.com>
References: <spn83vBFx_i1HAc9XDeWfwu2EozpYl4eMGHnX3WXhqM=.ef1ba9ba-1605-4d96-bdec-f41bf702686f@github.com>
Message-ID: <ExePjnN8Y5CtQhQeAG7v_cJWbB9cOfkfJdpBZeR0K_c=.15aa272b-d54d-41f6-a5ac-48c7f9063409@github.com>

On Fri, 29 Oct 2021 19:54:47 GMT, Alisen Chung <duke at openjdk.java.net> wrote:

> Added more time to test, removed pixel check during EmbeddedFrame test from OverlappingTestBase.

The bug says
This test just need more time to go. 
Provided JDK-8158801 is fixed. 

but that bug isn't fixed ..

test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java line 145:

> 143:         }
> 144: 
> 145:         if(currentAwtControl == null) { System.out.println("t"); }

Is this a left over debugging statement ?

test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 359:

> 357:     private static boolean isValidForPixelCheck(Component component) {
> 358:         if ((component instanceof java.awt.Scrollbar)
> 359:                 || (isMac && ((component instanceof java.awt.Button) || (component == null)))) {

"removed pixel check during EmbeddedFrame test from OverlappingTestBase."

Well you presumably can't pixel check a null component, but why is it null ?
It seems like a test issue for it to be null. Can you explain how this happens ?

Also if this code *were* to stay it would be better formatted like
 if ((component instanceof java.awt.Scrollbar) ||
      (isMac && ((component instanceof java.awt.Button) ||
      (component == null))))
 {

-------------

PR: https://git.openjdk.java.net/jdk/pull/6177


From serb at openjdk.java.net  Sat Oct 30 01:24:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 30 Oct 2021 01:24:06 GMT
Subject: RFR: 8196017:
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails [v2]
In-Reply-To: <oM6I9fx4ZINh_b2ttlDfcBRV3g1AfBwYEFuVVHYy9no=.665db928-2842-462b-bcb8-6f623a39becd@github.com>
References: <wnm-YKKA9gtMKq75lwgp0FuCT4VbvaC_Fh1eJC3krR8=.4d08ec64-7140-4559-b051-987e3bea0a27@github.com>
 <oM6I9fx4ZINh_b2ttlDfcBRV3g1AfBwYEFuVVHYy9no=.665db928-2842-462b-bcb8-6f623a39becd@github.com>
Message-ID: <i6dOBryh--xu_Dz_Kts5iSOQZft1qqhCr-uSJcZwvcE=.cbbcac62-3b66-4480-a15c-80d4a4698bca@github.com>

On Fri, 29 Oct 2021 09:24:29 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> The problem here is that due to the approximation of the coordinates when converting
>> to and from screen cordinate system on screen with 125% magnification 
>> two things can happen:
>> 1. New mouse position calculated can be 149/149 which is the same as the starting position
>> and system can refuse to generate new mouse event which causes false positive of the test
>> since second mouse motion listener was never called;
>> 2. Even if event is generated the resulting reported coordinates can differ by 1 pixel
>> in any of the directions;
>> 
>> To solve it i moved away the target point to make sure that move event always generated and
>> comparing expected and actual coordinates with approximation of +/- 1 pixel.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Protect from second mouse move image invocation.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6128


From serb at openjdk.java.net  Sat Oct 30 09:08:20 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 30 Oct 2021 09:08:20 GMT
Subject: Integrated: 8273831: PrintServiceLookup spawns 2 threads in the
 current classloader, getting orphaned
In-Reply-To: <eXuUD3WLjn4xv-R9bL_xU0tXyZV3HVNLpliZLBX9yFM=.1398debc-971a-4013-bbef-17e388a944d5@github.com>
References: <eXuUD3WLjn4xv-R9bL_xU0tXyZV3HVNLpliZLBX9yFM=.1398debc-971a-4013-bbef-17e388a944d5@github.com>
Message-ID: <WpG2oYXNvItWkJ2wN3N4hJKwLyrf5hDF6fJl4c5RLLE=.8e112091-9184-4d52-a0a0-3a7e398a1cda@github.com>

On Thu, 14 Oct 2021 05:43:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The PrintServiceLookupProvider can spawn 2 threads on WIndows and one thread on Linux. These threads are connected to the classloader of the web application.  During undeployment the app classloader gets removed together with the two orphaned threads by the Tomcat. 
> 
> Looks like the tomcat has special machinery to workaround such threads:
> https://cwiki.apache.org/confluence/display/tomcat/MemoryLeakProtection#MemoryLeakProtection-cclThreadSpawnedByJRE
> But it should be updated each time we add/update/rename the threads in the JDK. So JreMemoryLeakPreventionListener can be updated to solve this problem, but it will be good to reset the ref to the app class loader as we usually do for our internal threads. 
> 
> The change updates threads to use the root thread group and null context class loader.
> 
> A similar pattern is used here:
> https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.desktop/share/classes/com/sun/imageio/stream/StreamCloser.java#L89
> 
> @aivanov-jdk please take a look

This pull request has now been integrated.

Changeset: 68756782
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/687567822a5380fb7d8c5b54ae548b2a5c848187
Stats:     120 lines in 3 files changed: 104 ins; 3 del; 13 mod

8273831: PrintServiceLookup spawns 2 threads in the current classloader, getting orphaned

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/5939


From kizune at openjdk.java.net  Sat Oct 30 10:04:14 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 30 Oct 2021 10:04:14 GMT
Subject: Integrated: 8196017:
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
In-Reply-To: <wnm-YKKA9gtMKq75lwgp0FuCT4VbvaC_Fh1eJC3krR8=.4d08ec64-7140-4559-b051-987e3bea0a27@github.com>
References: <wnm-YKKA9gtMKq75lwgp0FuCT4VbvaC_Fh1eJC3krR8=.4d08ec64-7140-4559-b051-987e3bea0a27@github.com>
Message-ID: <D5I_uVztmxbM2nqoWEEKK2AF2mhI5RLp_gmCFa2zIHk=.e2b4f391-5a85-45a4-9211-919f62bc3a90@github.com>

On Wed, 27 Oct 2021 00:52:10 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> The problem here is that due to the approximation of the coordinates when converting
> to and from screen cordinate system on screen with 125% magnification 
> two things can happen:
> 1. New mouse position calculated can be 149/149 which is the same as the starting position
> and system can refuse to generate new mouse event which causes false positive of the test
> since second mouse motion listener was never called;
> 2. Even if event is generated the resulting reported coordinates can differ by 1 pixel
> in any of the directions;
> 
> To solve it i moved away the target point to make sure that move event always generated and
> comparing expected and actual coordinates with approximation of +/- 1 pixel.

This pull request has now been integrated.

Changeset: b7104ba9
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b7104ba9a9006ab65e08ea9d7db22e72611ed07c
Stats:     24 lines in 2 files changed: 9 ins; 6 del; 9 mod

8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/6128


From prr at openjdk.java.net  Sat Oct 30 20:39:47 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 30 Oct 2021 20:39:47 GMT
Subject: RFR: 8269806: Emoji rendering on Linux
In-Reply-To: <qcjJ6wJ4El89VZNwzIU8LywwPW7r5D5u62u3hy7HsbI=.edc043f7-011f-4996-a083-28c21e7a36ce@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <qcjJ6wJ4El89VZNwzIU8LywwPW7r5D5u62u3hy7HsbI=.edc043f7-011f-4996-a083-28c21e7a36ce@github.com>
Message-ID: <POqrJCtqfzFUsi8QJu7FLSc1JFhuSS0WmGMYnDpwLHQ=.a6beca24-90ba-43b3-a69c-e4326efb74a6@github.com>

On Sun, 22 Aug 2021 00:42:26 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>
> @prrace could you take a look, please?

@YaaZ nothing has really happened here in > 2 months. When can we expect an update ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798


From duke at openjdk.java.net  Sun Oct 31 07:37:09 2021
From: duke at openjdk.java.net (Hiroshi Miura)
Date: Sun, 31 Oct 2021 07:37:09 GMT
Subject: RFR: 8269806: Emoji rendering on Linux
In-Reply-To: <hfPNfnz8B7BCt0AWvE6a5oy-eDvDJdEDlNjghA2a5Fs=.c8e56fdd-2592-4f18-9859-4b68477681aa@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <hfPNfnz8B7BCt0AWvE6a5oy-eDvDJdEDlNjghA2a5Fs=.c8e56fdd-2592-4f18-9859-4b68477681aa@github.com>
Message-ID: <Zl2JlxUYyhiCBmbr5ESW_KTc74jiXkz6_1bjzm_boAk=.5b525cbc-86d5-4098-869e-6b3fe7fa7a38@github.com>

On Mon, 23 Aug 2021 04:51:56 GMT, Phil Race <prr at openjdk.org> wrote:

> "Noto Color Emoji" may not be available on all Linuxes and for whatever reason your update makes the test fail on Mac.

@YaaZ Any progress do you have? As Linux user I'd like to help if I can.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798