From prr at openjdk.java.net  Wed Jun  1 04:36:36 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 1 Jun 2022 04:36:36 GMT
Subject: RFR: 8287609: Add null-check for tagsArray returned from
 CTFontCopyAvailableTables
In-Reply-To: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
References: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
Message-ID: <fV-0gOSYx5OcCaGCi-9hh6XhuAHRJ4vPyWZ6AXGfI6s=.85792cb7-ee7b-4e71-bd9a-b7671b4d1e95@github.com>

On Tue, 31 May 2022 23:39:09 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

> `CTFontCopyAvailableTables` can return null, which causes subsequent call to `CFArrayGetCount` to crash with SEGFAULT, just added a null-check.

Where do you read it can return null ?

https://developer.apple.com/documentation/coretext/1510774-ctfontcopyavailabletables?language=objc

says nothing ..

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

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


From duke at openjdk.java.net  Wed Jun  1 04:48:34 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 1 Jun 2022 04:48:34 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v3]
In-Reply-To: <DpvmclypIcCDXli-qMUwP9HpCimQ8JoEbEJXs6d-Nv4=.0c99e50c-3c26-492a-95cc-aa9b5302e861@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <1-qMJRwjJVXF7BSrl5NCpoR9KMRBirtjJY--Kr6JueU=.e4a087a3-a7bb-4a93-a6ad-4a26954de78e@github.com>
 <DpvmclypIcCDXli-qMUwP9HpCimQ8JoEbEJXs6d-Nv4=.0c99e50c-3c26-492a-95cc-aa9b5302e861@github.com>
Message-ID: <OgNizPtHLfftJ4PQtfTabyjvKu5p2-hKaO9SDIwOQpg=.af5401da-1c2d-4112-b114-c42a5a7d9007@github.com>

On Tue, 31 May 2022 11:30:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I wonder why the test is Windows-specific if it allows changing Look and Feels.
> 
> The only Look and Feel which ignores the background is Nimbus, other L&Fs on Windows at least paint the yellow and green background. As such, the test can be run on other platforms.
> 
> Was the original bug in Windows Look and Feel? If so, you may want to make it the default L&F.
> 
> The instructions don't mention anything about other Look and Feels. Does the tester have to verify each presented L&F?

I think the test was in windows which I might have retained the os type, will check and confirm once. The tester have to verify with each L&F for left margin check.

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

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


From psadhukhan at openjdk.java.net  Wed Jun  1 05:12:32 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 1 Jun 2022 05:12:32 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF
In-Reply-To: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
Message-ID: <WuleJPzWOE8qculhkz1S7FD1FNCRsws3QKQwPqOJLqQ=.fcd4c4ba-1805-43e2-85d5-e5401f1e47f9@github.com>

On Tue, 31 May 2022 08:14:14 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> The tooltip displays accelerated string along with the toooltip string. The feature is implemented and applicable for Metal Look and Feel only. Hence the test is updated for Metal Look and Feel by hard wiring it in the code. Updated the test from manual to automatic.

Changes requested by psadhukhan (Reviewer).

test/jdk/javax/swing/JToolTip/bug5047379.java line 54:

> 52: 
> 53: public class bug5047379 {
> 54:     static volatile boolean isTooltipAdded;

This is only set but never checked anywhere.. if it's not needed, it needs to be removed..

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

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


From duke at openjdk.java.net  Wed Jun  1 05:30:23 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 1 Jun 2022 05:30:23 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF [v2]
In-Reply-To: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
Message-ID: <HGu1Mq4x4nQ7xlW8yB74G4MFGPDuAfpnv8G3B9qdBq0=.81d0bc65-201a-438a-b1a1-0d78336ce287@github.com>

> The tooltip displays accelerated string along with the toooltip string. The feature is implemented and applicable for Metal Look and Feel only. Hence the test is updated for Metal Look and Feel by hard wiring it in the code. Updated the test from manual to automatic.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Removed unused parameter isTooltipAdded

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8952/files
  - new: https://git.openjdk.java.net/jdk/pull/8952/files/79f2d58f..6d147703

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

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

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


From duke at openjdk.java.net  Wed Jun  1 05:30:24 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 1 Jun 2022 05:30:24 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF [v2]
In-Reply-To: <WuleJPzWOE8qculhkz1S7FD1FNCRsws3QKQwPqOJLqQ=.fcd4c4ba-1805-43e2-85d5-e5401f1e47f9@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
 <WuleJPzWOE8qculhkz1S7FD1FNCRsws3QKQwPqOJLqQ=.fcd4c4ba-1805-43e2-85d5-e5401f1e47f9@github.com>
Message-ID: <IzP68RmQeuUoTpTX2uvbM3VQ2fLhcMh-JdSwwBJc-3g=.9e96b087-bc28-4427-a02c-654f8901d22d@github.com>

On Wed, 1 Jun 2022 05:07:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unused parameter isTooltipAdded
>
> test/jdk/javax/swing/JToolTip/bug5047379.java line 54:
> 
>> 52: 
>> 53: public class bug5047379 {
>> 54:     static volatile boolean isTooltipAdded;
> 
> This is only set but never checked anywhere.. if it's not needed, it needs to be removed..

Yeah, removed it.

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

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


From duke at openjdk.java.net  Wed Jun  1 05:35:29 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 1 Jun 2022 05:35:29 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v3]
In-Reply-To: <OgNizPtHLfftJ4PQtfTabyjvKu5p2-hKaO9SDIwOQpg=.af5401da-1c2d-4112-b114-c42a5a7d9007@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <1-qMJRwjJVXF7BSrl5NCpoR9KMRBirtjJY--Kr6JueU=.e4a087a3-a7bb-4a93-a6ad-4a26954de78e@github.com>
 <DpvmclypIcCDXli-qMUwP9HpCimQ8JoEbEJXs6d-Nv4=.0c99e50c-3c26-492a-95cc-aa9b5302e861@github.com>
 <OgNizPtHLfftJ4PQtfTabyjvKu5p2-hKaO9SDIwOQpg=.af5401da-1c2d-4112-b114-c42a5a7d9007@github.com>
Message-ID: <bawffD0qA8VOw8J0YI7r7NmggrjgCi22GC8cGWwaM00=.7bd09b07-c3e8-4768-8bd7-e97f274e5563@github.com>

On Wed, 1 Jun 2022 04:45:12 GMT, Tejesh R <duke at openjdk.java.net> wrote:

> > I wonder why the test is Windows-specific if it allows changing Look and Feels.
> > The only Look and Feel which ignores the background is Nimbus, other L&Fs on Windows at least paint the yellow and green background. As such, the test can be run on other platforms.
> > Was the original bug in Windows Look and Feel? If so, you may want to make it the default L&F.
> > The instructions don't mention anything about other Look and Feels. Does the tester have to verify each presented L&F?
> 
> I think the test was in windows which I might have retained the os type, will check and confirm once. The tester have to verify with each L&F for left margin check.

Yeah, it was only for Motif and Windows before, so I have retained it for only windows os.

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

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


From duke at openjdk.java.net  Wed Jun  1 05:40:29 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 1 Jun 2022 05:40:29 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v3]
In-Reply-To: <DpvmclypIcCDXli-qMUwP9HpCimQ8JoEbEJXs6d-Nv4=.0c99e50c-3c26-492a-95cc-aa9b5302e861@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <1-qMJRwjJVXF7BSrl5NCpoR9KMRBirtjJY--Kr6JueU=.e4a087a3-a7bb-4a93-a6ad-4a26954de78e@github.com>
 <DpvmclypIcCDXli-qMUwP9HpCimQ8JoEbEJXs6d-Nv4=.0c99e50c-3c26-492a-95cc-aa9b5302e861@github.com>
Message-ID: <zUGWUHEcSSTpRowcN_UkfuhU0ZmBNIQVkEgH3xbd4V8=.49f12f17-0641-4622-a94c-7145004404df@github.com>

On Tue, 31 May 2022 11:15:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Updated based on review comments
>>  - Added headful key
>
> test/jdk/javax/swing/JRadioButton/bug4380543.java line 106:
> 
>> 104: 
>> 105:             lookAndFeelMaps.put(sMapKey, sLnF);
>> 106:         }
> 
> Suggestion:
> 
>         for (UIManager.LookAndFeelInfo look : lookAndFeel) {
>             lookAndFeelMaps.put(look.getName(), look.getClassName());
>         }
> 
> 
> I guess I mentioned it earlier. I think this way is cleaner and more user-friendly: the user will see the name of the Look and Feel rather than part of its class name.
> 
> The local variables `sLnF` and `sMapKey` declared above the look become unnecessary in this case.
> 
> If you use `LinkedHashMap`, the order of the L&Fs will be preserved the map will be iterated for creating the buttons.

The reason for doing this was to use the same key for button creation (name of button) and then to link that with the button action, so changing this will affect other logics.

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

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


From psadhukhan at openjdk.java.net  Wed Jun  1 05:41:34 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 1 Jun 2022 05:41:34 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF [v2]
In-Reply-To: <HGu1Mq4x4nQ7xlW8yB74G4MFGPDuAfpnv8G3B9qdBq0=.81d0bc65-201a-438a-b1a1-0d78336ce287@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
 <HGu1Mq4x4nQ7xlW8yB74G4MFGPDuAfpnv8G3B9qdBq0=.81d0bc65-201a-438a-b1a1-0d78336ce287@github.com>
Message-ID: <HqELMFrAk-s_LBIy5t58cP_hyenZF3CIHI6f-VIg1No=.a71ae0e6-0d94-4c3d-b2e3-85c32b577769@github.com>

On Wed, 1 Jun 2022 05:30:23 GMT, Tejesh R <duke at openjdk.java.net> wrote:

>> The tooltip displays accelerated string along with the toooltip string. The feature is implemented and applicable for Metal Look and Feel only. Hence the test is updated for Metal Look and Feel by hard wiring it in the code. Updated the test from manual to automatic.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused parameter isTooltipAdded

Marked as reviewed by psadhukhan (Reviewer).

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

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


From duke at openjdk.java.net  Wed Jun  1 06:00:34 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 1 Jun 2022 06:00:34 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v4]
In-Reply-To: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
Message-ID: <BPd77K5HjZdYVu_lGYJFVRT8UHqqGLKdCMl74t0BeGk=.78ead183-e30b-46b7-a5f5-efc3b4cdfd3c@github.com>

> Added test for checking setMargin() of JRadioButton.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8721/files
  - new: https://git.openjdk.java.net/jdk/pull/8721/files/3001e8a8..5d4adb7f

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

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

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


From duke at openjdk.java.net  Wed Jun  1 06:00:36 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 1 Jun 2022 06:00:36 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton
In-Reply-To: <w-N9ytS13mlt4CGJuadTJ2BFczwlmBj95CacAy8Tf10=.2f756d1a-1c9f-4fa6-88a0-b0f0bef9646d@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <o6j5dwmYpJlo_22zZ0fLTGp1XIuLqPNo4z5qvfzoMBE=.0fd419ad-18d6-4b15-8d04-fcd428f8c0ae@github.com>
 <XF2url1JVausRVpW0MIehVcRV9xjRqVtKNWTBaKnIc8=.3d6fb3b4-a1dd-44a4-ac09-2504612e166a@github.com>
 <w-N9ytS13mlt4CGJuadTJ2BFczwlmBj95CacAy8Tf10=.2f756d1a-1c9f-4fa6-88a0-b0f0bef9646d@github.com>
Message-ID: <C3--YClboaIwxTdeGkKOnxt7gu1dyrTAdCE1eBxoRq0=.ec040c49-9a5a-4c50-bb9f-77f2807139d2@github.com>

On Tue, 24 May 2022 10:36:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Just an idea for discussion: I remember that we added some support for the manual tests, kind of framework or something. Probably it will be useful to reuse when we add "new" tests? https://bugs.openjdk.java.net/browse/JDK-8283803
>> 
>> Means you are suggesting to use the passfailFrame?
>
>> > Just an idea for discussion: I remember that we added some support for the manual tests, kind of framework or something. Probably it will be useful to reuse when we add "new" tests? https://bugs.openjdk.java.net/browse/JDK-8283803
>> 
>> Means you are suggesting to use the passfailFrame?
> 
> Why not? The framework allows you to re-use the functionality for creating the UI and for handling Pass/Fail buttons instead of creating your own.

Updated @aivanov-jdk .

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

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


From aghaisas at openjdk.java.net  Wed Jun  1 06:50:32 2022
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 1 Jun 2022 06:50:32 GMT
Subject: RFR: 8287453: RenderPerfTest incorrectly measures performance
In-Reply-To: <wEJU4wOns8RLkOUhbVKhGkJYXhSOGzj5XVmfHU7m-w4=.8256294e-2fb9-4636-901a-3e026759288e@github.com>
References: <EcLzMlD3pS991VN6A0XLff6wNdifZUPFDBovCl_33Fc=.db2d3f25-c79e-46e3-9a6d-a5822ae2ab07@github.com>
 <LRHwSv2Leb1k8KDxBNObYmgzOy5Mk6Zv77CquWP10vY=.8805ba75-dc9f-41d0-bbf8-940070260d71@github.com>
 <wEJU4wOns8RLkOUhbVKhGkJYXhSOGzj5XVmfHU7m-w4=.8256294e-2fb9-4636-901a-3e026759288e@github.com>
Message-ID: <oHuv5uRwCtGgS09wLPM_GCB9X0LssBmtdGitzb9lK7c=.123eab42-1b10-4098-9b35-a45d4df297dd@github.com>

On Tue, 31 May 2022 15:28:34 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> > Is it only a test stabilization fix? or were you able to uncover any performance issue (either with OpenGL or with Metal pipeline) with this change? Can you please provide before/after numbers?
> 
> Initially it was a stabilization fix. However, I've found couple of issues: missing frames (I have minimal test case and here is the issue [JDK-8287600](https://bugs.openjdk.java.net/browse/JDK-8287600) ) and low performance in some test cases comparing with OGL. I've attached the results to this issue.

Thanks for providing the performance numbers in JBS and filing the issue for missing frame.

Another bug needs to be filed for tests having lower performance with the Metal pipeline as compared to OpenGL pipeline.
It's a surprise that the modified RenderPerf test shows considerable performance difference (whereas J2DBench tests show difference only in some cases)

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

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


From duke at openjdk.java.net  Wed Jun  1 08:26:33 2022
From: duke at openjdk.java.net (Nikita Gubarkov)
Date: Wed, 1 Jun 2022 08:26:33 GMT
Subject: RFR: 8287609: Add null-check for tagsArray returned from
 CTFontCopyAvailableTables
In-Reply-To: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
References: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
Message-ID: <tCSdKB0YdC94BCRLVkbQPt2_kD5s6GBoKTFUnPazmvo=.daca6d54-0f3c-4e3e-ab09-9db725824010@github.com>

On Tue, 31 May 2022 23:39:09 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

> `CTFontCopyAvailableTables` can return null, which causes subsequent call to `CFArrayGetCount` to crash with SEGFAULT, just added a null-check.

I didn't find anything in documentation too, but it does return null, I checked with a debugger

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

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


From smandalika at openjdk.java.net  Wed Jun  1 08:37:35 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 1 Jun 2022 08:37:35 GMT
Subject: RFR: 8285305: Create an automated test for JDK-4495286 [v3]
In-Reply-To: <ITRsSdwqqLK58_e-fgtaUZB8BWs88dwPrMkkSq48hvs=.456b44b7-f90f-41e5-9c8f-9442c62ad374@github.com>
References: <tfMcUiiqM3zbwahwkdBXMSFXcHiCqyZoRJLZgekkagQ=.5392b0b4-bd49-400a-8bf0-aef5f1354d6e@github.com>
 <ITRsSdwqqLK58_e-fgtaUZB8BWs88dwPrMkkSq48hvs=.456b44b7-f90f-41e5-9c8f-9442c62ad374@github.com>
Message-ID: <dcMtItx1zgdj-ghfUCGernyMSsAvDajA1EGb5y340ks=.65977664-1f64-4624-abb3-5d07684c873e@github.com>

On Wed, 18 May 2022 08:20:47 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4495286](https://bugs.openjdk.java.net/browse/JDK-4495286)
>> 
>> AccessibleJTable.setAccessibleSelction should select rows/cols when cell selection.
>> When cell selection is not enabled, there is no way, using
>> accessibility, to select rows or columns. It seems logical that selecting a cell
>> using accessibility should have the same effect as clicking on a cell with the
>> mouse. That is, if row or column selection is enabled, then selecting a cell
>> should instead cause the row or column to be selected.
>>  The proposed test verifies that the above behavior is fixed.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (40) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: moved the file directly under the a11y folder

Hi! Can someone please take a look at this PR and provide their valuable feedback ?

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

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


From smandalika at openjdk.java.net  Wed Jun  1 08:38:48 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 1 Jun 2022 08:38:48 GMT
Subject: RFR: 8284524: Create an automated test for JDK-4422362 [v3]
In-Reply-To: <ASMCKuK4Ur54E_sI13yc-5J9BZlH8thmHe5a8fWwxYI=.6160ccaf-36b9-4838-bb6a-a845840fc5d8@github.com>
References: <Zc6TLIeUCxotLqICjVkZF4g1hUTkdB7mANhMull6Qzc=.14959182-424c-42f6-979f-7d6eeb266dfb@github.com>
 <ASMCKuK4Ur54E_sI13yc-5J9BZlH8thmHe5a8fWwxYI=.6160ccaf-36b9-4838-bb6a-a845840fc5d8@github.com>
Message-ID: <EEAgqstf8U_tgTczjiiNm2DmkWCxjSGdqb8yP_oN3Io=.08d66765-b626-4eb4-8d17-9d5e20c3675f@github.com>

On Wed, 18 May 2022 08:38:49 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422362](https://bugs.openjdk.java.net/browse/JDK-4422362)
>> 
>> The BoundedRangeModel components (JScrollBar, JSlider, JProgressBar) return
>> BoundedRangeModel.getMaximum() from getMaximumAccessibleValue() in their
>> AccessibleValue implementation.
>> The real maximum value (due to the constraints on BoundedRangeModel) is
>> model.getMaximum() - model.getExtent().
>> 
>> The test verifies that the above is adhered to as expected.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: Fixed File location path.

Hi! Can someone please take a look at this PR and provide their valuable feedback ?

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

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


From smandalika at openjdk.java.net  Wed Jun  1 08:38:47 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 1 Jun 2022 08:38:47 GMT
Subject: RFR: 8284767: Create an automated test for JDK-4422535 [v3]
In-Reply-To: <3rXFVh7JvLK-ycYNRlmK8tTqTpmrs7GuF0lxiaO78kQ=.9f972f36-f57f-4cf1-a2d8-58feba441f71@github.com>
References: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
 <3rXFVh7JvLK-ycYNRlmK8tTqTpmrs7GuF0lxiaO78kQ=.9f972f36-f57f-4cf1-a2d8-58feba441f71@github.com>
Message-ID: <vWyVc5jFeRaa9Cy9V8ViORriYYczUeqFwG6vWXknGb4=.6a5788b4-aa56-4fbb-9e00-ca587fc92bc3@github.com>

On Wed, 18 May 2022 08:37:03 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422535](https://bugs.openjdk.java.net/browse/JDK-4422535)
>> AccessibleValue implementation only accept Integers
>> The AccessibleValue implementations of the following components:
>> 
>> java.awt.Scrollbar
>> javax.swing.AbstractButton
>> javax.swing.JInternalFrame
>> javax.swing.JSplitPane
>> javax.swing.JScrollBar
>> javax.swing.JProgressBar
>> javax.swing.JSlider
>> 
>> require the argument to setCurrentAccessibleValue(Number) to be an Integer, else they completely ignore it - it returns a false indicating that the value has not been set by the return value, but they cannot know the reason for that).
>> 
>> The test verifies that for each of the above components, the AccessibleValue is set when it is set to a Number (Float, Double, long etc) and not just for an Integer.
>> 
>> his review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: Fixed File location path.

Hi! Can someone please take a look at this PR and provide their valuable feedback ?

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

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


From smandalika at openjdk.java.net  Wed Jun  1 08:39:40 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 1 Jun 2022 08:39:40 GMT
Subject: RFR: 8285373: Create an automated test for JDK-4702233 [v2]
In-Reply-To: <z0o-FHmf-wr2qSy6UnFl-Ti8k67x5Gyqdz6kvoeJvx4=.5890d850-6b28-4de0-9d4c-eeb22d6744f8@github.com>
References: <zrkWQo-BoTq0XlQX_0_-CwnPIKkCge6wW8E5EqLAYRs=.2345ef0a-25eb-414c-ade6-de10d49d2bbe@github.com>
 <z0o-FHmf-wr2qSy6UnFl-Ti8k67x5Gyqdz6kvoeJvx4=.5890d850-6b28-4de0-9d4c-eeb22d6744f8@github.com>
Message-ID: <MJEbeNebNpe9amKUoc_FuURNwaphTfOxA7TQBEodmiY=.9c0c4e21-3dcd-4849-b32f-a9fbba12a52b@github.com>

On Fri, 29 Apr 2022 14:11:41 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4702233](https://bugs.openjdk.java.net/browse/JDK-4702233)
>> 
>> Several new AccessibleRole and AccessibleRelation constants are needed in those classes in the java.accessibility package. These new contants codify additions made in the GNOME, Netscape, and UNO (StarOffice) accessibility APIs.
>> StarOffice 6.1 and GNOME accessibility require new role, state and relation
>> constants in the javax.accessibility package. The existing constants are
>> inadequate for providing accessibility to StarOffice and GNOME applications
>> as required by Section 508.
>> 
>> Solution
>> --------
>> Define new constants in the javax.accessibility package.
>> AccessibleRelation
>> AccessibleRoles
>> AccessibleState
>> AccessibleAction
>> AccessibleContext
>> 
>> The test validates the public fields of the above AccessibleConstants.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing CopyRight Header

Hi! Can someone please take a look at this PR and provide their valuable feedback ?

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

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


From avu at openjdk.java.net  Wed Jun  1 09:48:33 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 1 Jun 2022 09:48:33 GMT
Subject: RFR: 8287453: RenderPerfTest incorrectly measures performance
In-Reply-To: <oHuv5uRwCtGgS09wLPM_GCB9X0LssBmtdGitzb9lK7c=.123eab42-1b10-4098-9b35-a45d4df297dd@github.com>
References: <EcLzMlD3pS991VN6A0XLff6wNdifZUPFDBovCl_33Fc=.db2d3f25-c79e-46e3-9a6d-a5822ae2ab07@github.com>
 <LRHwSv2Leb1k8KDxBNObYmgzOy5Mk6Zv77CquWP10vY=.8805ba75-dc9f-41d0-bbf8-940070260d71@github.com>
 <wEJU4wOns8RLkOUhbVKhGkJYXhSOGzj5XVmfHU7m-w4=.8256294e-2fb9-4636-901a-3e026759288e@github.com>
 <oHuv5uRwCtGgS09wLPM_GCB9X0LssBmtdGitzb9lK7c=.123eab42-1b10-4098-9b35-a45d4df297dd@github.com>
Message-ID: <UTQ7d9Mf-RMFCxEhetM-_Xh4lYTzpP-m32cdXTewWjw=.0ed36191-9a95-477a-afe3-6aaf364e0fd3@github.com>

On Wed, 1 Jun 2022 06:46:40 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> > > Is it only a test stabilization fix? or were you able to uncover any performance issue (either with OpenGL or with Metal pipeline) with this change? Can you please provide before/after numbers?
> > 
> > 
> > Initially it was a stabilization fix. However, I've found couple of issues: missing frames (I have minimal test case and here is the issue [JDK-8287600](https://bugs.openjdk.java.net/browse/JDK-8287600) ) and low performance in some test cases comparing with OGL. I've attached the results to this issue.
> 
> Thanks for providing the performance numbers in JBS and filing the issue for missing frame.
> 
> Another bug needs to be filed for tests having lower performance with the Metal pipeline as compared to OpenGL pipeline. It's a surprise that the modified RenderPerf test shows considerable performance difference (whereas J2DBench tests show difference only in some cases)

Yes, it was a surprise. We've enabled metal in EAP of our IDEs and got some complains about the performance. So, I've decided to revise our measurements. I have fixes for the problems above, but they are not complete yet. (still fighting with some regressions)

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

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


From avu at openjdk.java.net  Wed Jun  1 09:50:51 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 1 Jun 2022 09:50:51 GMT
Subject: Integrated: 8287453: RenderPerfTest incorrectly measures performance
In-Reply-To: <EcLzMlD3pS991VN6A0XLff6wNdifZUPFDBovCl_33Fc=.db2d3f25-c79e-46e3-9a6d-a5822ae2ab07@github.com>
References: <EcLzMlD3pS991VN6A0XLff6wNdifZUPFDBovCl_33Fc=.db2d3f25-c79e-46e3-9a6d-a5822ae2ab07@github.com>
Message-ID: <HmGg5Shg7EhJja4nCjmPR5mH4dzc_htRl8lNylWAujI=.8525987a-7617-46e1-913d-4a819399b5a9@github.com>

On Fri, 27 May 2022 18:58:12 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Improved RenderPerfTest:
>   - removed RenderPerfLCD.java (we have LCD tests in RenderPerfTest.java)
>   - corrected and simplified test logic
>   - added timeout on low performant rendering
>   - used several markers to recover from missing frames
>   - protected measurements from multiple paint invocations

This pull request has now been integrated.

Changeset: 48f19e43
Author:    Alexey Ushakov <avu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/48f19e43c5ceeed6b8f714fc921566f9260c78db
Stats:     478 lines in 4 files changed: 34 ins; 402 del; 42 mod

8287453: RenderPerfTest incorrectly measures performance

Reviewed-by: prr

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

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


From duke at openjdk.java.net  Wed Jun  1 10:04:31 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 1 Jun 2022 10:04:31 GMT
Subject: RFR: JDK-8287261: [macos] JList Focus Ring color doesn't follow
 Accent color changes on macOS
In-Reply-To: <m7Go1P8BVJLcyEarJLHiwHUsBKeQ5GnxvHmoKYnfmXo=.8851e019-707c-455a-9a02-249ea8ab2681@github.com>
References: <m7Go1P8BVJLcyEarJLHiwHUsBKeQ5GnxvHmoKYnfmXo=.8851e019-707c-455a-9a02-249ea8ab2681@github.com>
Message-ID: <EFYTFZObcKZ7un_zQ0GcXXKVdWrxf5NZOi1i07NzPmc=.e45e1dae-7f5c-45e4-8174-a7cf97e168d5@github.com>

On Wed, 25 May 2022 23:40:59 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> With the proposed fix, JList's focus ring color follows accent color changes. Previously the focus ring for JList was not prominently visible and did not follow accent color changes.
> 
> While investing a similar issue related to JTable (https://github.com/openjdk/jdk/pull/7768#discussion_r839813517), it was observed that List.focusCellHighlightBorder was using the cellFocusRing color as well. This PR extends the focus ring accent color changes to JLists. 
> 
> Related issues: [JDK-7124282](https://bugs.openjdk.java.net/browse/JDK-7124282) , [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243)
> 
> ####    Summary of changes
> 
> -  focusCellHighlightBorder in `AquaLookAndFeel` changed which is used for cell border for lists and tables
> -  code related to on-the-fly focus ring color refactored into a separate method (`changeFocusRingColor()`) for re-usability 
> -  `changeFocusRingColor()` called when PropertyChangeEvent == FRAME_ACTIVE_PROPERTY and the frame gains focus, instead of calling in individual `swapSelectionColors` in `AquaFocusHandler.java`
> - Common test added - `CellFocusRingTest`, which tests for both cases - Tables & Lists. 
> 
> **Before and After screenshots of JList** _(Screenshots from SwingSet2 demo)_
> 
> ![Screen Shot 2022-05-25 at 3 55 49 PM](https://user-images.githubusercontent.com/95945681/170382727-54ed155b-6f08-4c75-8657-89c15764e1cd.png)

test/jdk/javax/swing/JTable/CellFocusRingTest.java line 60:

> 58:         if (errorLog.isEmpty()) {
> 59:             System.out.println("Test passed !!");
> 60:         }

`} else {` Can be in same line. (Applies to other places also)

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

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


From duke at openjdk.java.net  Wed Jun  1 10:11:39 2022
From: duke at openjdk.java.net (Tejesh R)
Date: Wed, 1 Jun 2022 10:11:39 GMT
Subject: RFR: JDK-8287261: [macos] JList Focus Ring color doesn't follow
 Accent color changes on macOS
In-Reply-To: <m7Go1P8BVJLcyEarJLHiwHUsBKeQ5GnxvHmoKYnfmXo=.8851e019-707c-455a-9a02-249ea8ab2681@github.com>
References: <m7Go1P8BVJLcyEarJLHiwHUsBKeQ5GnxvHmoKYnfmXo=.8851e019-707c-455a-9a02-249ea8ab2681@github.com>
Message-ID: <jsOeD9XWdvem1u9HmFnc6G0yjrOs_KwJU1CzbchbIcc=.cc0c3ed4-8787-4c00-9069-752378eaeaf2@github.com>

On Wed, 25 May 2022 23:40:59 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> With the proposed fix, JList's focus ring color follows accent color changes. Previously the focus ring for JList was not prominently visible and did not follow accent color changes.
> 
> While investing a similar issue related to JTable (https://github.com/openjdk/jdk/pull/7768#discussion_r839813517), it was observed that List.focusCellHighlightBorder was using the cellFocusRing color as well. This PR extends the focus ring accent color changes to JLists. 
> 
> Related issues: [JDK-7124282](https://bugs.openjdk.java.net/browse/JDK-7124282) , [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243)
> 
> ####    Summary of changes
> 
> -  focusCellHighlightBorder in `AquaLookAndFeel` changed which is used for cell border for lists and tables
> -  code related to on-the-fly focus ring color refactored into a separate method (`changeFocusRingColor()`) for re-usability 
> -  `changeFocusRingColor()` called when PropertyChangeEvent == FRAME_ACTIVE_PROPERTY and the frame gains focus, instead of calling in individual `swapSelectionColors` in `AquaFocusHandler.java`
> - Common test added - `CellFocusRingTest`, which tests for both cases - Tables & Lists. 
> 
> **Before and After screenshots of JList** _(Screenshots from SwingSet2 demo)_
> 
> ![Screen Shot 2022-05-25 at 3 55 49 PM](https://user-images.githubusercontent.com/95945681/170382727-54ed155b-6f08-4c75-8657-89c15764e1cd.png)

test/jdk/javax/swing/JTable/CellFocusRingTest.java line 85:

> 83:         }
> 84: 
> 85:         if (UIManager.getDefaults().get("CellFocus.color") != null

if (UIManager.getDefaults().get("CellFocus.color") != null
                && UIManager.getDefaults().get("CellFocus.color")
                instanceof Color)

can be changed into 

        if (UIManager.getDefaults().get("CellFocus.color")
                instanceof Color)

Since if the object is null then `instanceof` returns false.

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

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


From prr at openjdk.java.net  Wed Jun  1 15:16:38 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 1 Jun 2022 15:16:38 GMT
Subject: RFR: 8287609: macOS: SIGSEGV at [CoreFoundation] CFArrayGetCount /
 sun.font.CFont.getTableBytesNative
In-Reply-To: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
References: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
Message-ID: <zhwmO2jL9qbZ5vUJ1h-csk8vNo5wNvgws9rPMw4KMbU=.5e718846-7424-4a5c-a7fd-77acb798df64@github.com>

On Tue, 31 May 2022 23:39:09 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

> `CTFontCopyAvailableTables` can return null, which causes subsequent call to `CFArrayGetCount` to crash with SEGFAULT, just added a null-check.

All supported font formats on macOS have such tables, so it must be something else.
I don't see how it can fail unless there is something wrong with the CTFont that
would have been previously signalled or we have a bad font handle, or there is a bad table entry.
There's no way to tell from the stack trace. 
So this fixes the symptom (temporarily, since it leaves the caller to deal with not being
able to get the tables it expects are there) but doesn't explain why it happens.

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

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


From aivanov at openjdk.java.net  Wed Jun  1 16:34:44 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 1 Jun 2022 16:34:44 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v4]
In-Reply-To: <BPd77K5HjZdYVu_lGYJFVRT8UHqqGLKdCMl74t0BeGk=.78ead183-e30b-46b7-a5f5-efc3b4cdfd3c@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <BPd77K5HjZdYVu_lGYJFVRT8UHqqGLKdCMl74t0BeGk=.78ead183-e30b-46b7-a5f5-efc3b4cdfd3c@github.com>
Message-ID: <KLaHd-f0_bx7YZRE4vrRHrdzLwgg61aBpgBu7X4Q06s=.cf65e394-802c-4940-b402-08bb96fa3003@github.com>

On Wed, 1 Jun 2022 06:00:34 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Added test for checking setMargin() of JRadioButton.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Changes requested by aivanov (Reviewer).

Shall the test be located in  
`test/jdk/javax/swing/JRadioButton/4380543/bug4380543.java`  
instead of  
`test/jdk/javax/swing/JRadioButton/bug4380543.java` ?

Usually, there's been a folder with bugid (`/4380543/`) for each test. Do we use the flat layout now?

test/jdk/javax/swing/JRadioButton/bug4380543.java line 62:

> 60:             "(insets set to 20 on all 4 sides)." +
> 61:             "\n 3. If Left insets(margins) appear Empty, press Fail, " +
> 62:             "else press Pass.";

You should add an explicit step to verify rendering in different Look-and-Feels by clicking the buttons.

test/jdk/javax/swing/JRadioButton/bug4380543.java line 102:

> 100:             sLnFName = sLnFName.trim();
> 101: 
> 102:             lookAndFeelMap.put(sLnFName, sLnFClassName);

Why don't you want to use `look.getName()` instead of doing the magic to extract what resembles the name from the class?

test/jdk/javax/swing/JRadioButton/bug4380543.java line 126:

> 124: 
> 125:         for (Map.Entry<String, String> mapElement : lookAndFeelMap.entrySet()) {
> 126:             String btnName = mapElement.getKey();

This can be further simplified: you don't use the value, you use only the key, so the for-loop could iterate over `lookAndFeelMap.keySet()`.

In fact, you can avoid the map altogether if you use the class name as the action name:


UIManager.LookAndFeelInfo[] lookAndFeel = UIManager.getInstalledLookAndFeels();
for (UIManager.LookAndFeelInfo look : lookAndFeel) {
    JButton btn = new JButton(look.getName());
    btn.setActionCommand(look.getClassName());
    btn.addActionListener(this);
    p.add(btn);
}


In this case, `initMap` and `lookAndFeelMap` should be removed.

The listener should be updated:


public void actionPerformed(ActionEvent e) {
    setLookAndFeel(e.getActionCommand());
    SwingUtilities.updateComponentTreeUI(this);
}

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

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


From honkar at openjdk.java.net  Wed Jun  1 16:38:33 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Wed, 1 Jun 2022 16:38:33 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v4]
In-Reply-To: <KLaHd-f0_bx7YZRE4vrRHrdzLwgg61aBpgBu7X4Q06s=.cf65e394-802c-4940-b402-08bb96fa3003@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <BPd77K5HjZdYVu_lGYJFVRT8UHqqGLKdCMl74t0BeGk=.78ead183-e30b-46b7-a5f5-efc3b4cdfd3c@github.com>
 <KLaHd-f0_bx7YZRE4vrRHrdzLwgg61aBpgBu7X4Q06s=.cf65e394-802c-4940-b402-08bb96fa3003@github.com>
Message-ID: <inqwY6uHTSczUgoVcntLUOStCc8k7IfdP4elYZHXxsA=.7f0ea7ae-71d4-454b-a5f4-46a3c75b25a7@github.com>

On Wed, 1 Jun 2022 16:29:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Shall the test be located in `test/jdk/javax/swing/JRadioButton/4380543/bug4380543.java` instead of `test/jdk/javax/swing/JRadioButton/bug4380543.java` ?
> 
> Usually, there's been a folder with bugid (`/4380543/`) for each test. Do we use the flat layout now?

@aivanov-jdk Recently we have started to use the latter and remove the extra folder (`/4380543/`)

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

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


From honkar at openjdk.java.net  Wed Jun  1 16:58:33 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Wed, 1 Jun 2022 16:58:33 GMT
Subject: RFR: JDK-8287261: [macos] JList Focus Ring color doesn't follow
 Accent color changes on macOS
In-Reply-To: <jsOeD9XWdvem1u9HmFnc6G0yjrOs_KwJU1CzbchbIcc=.cc0c3ed4-8787-4c00-9069-752378eaeaf2@github.com>
References: <m7Go1P8BVJLcyEarJLHiwHUsBKeQ5GnxvHmoKYnfmXo=.8851e019-707c-455a-9a02-249ea8ab2681@github.com>
 <jsOeD9XWdvem1u9HmFnc6G0yjrOs_KwJU1CzbchbIcc=.cc0c3ed4-8787-4c00-9069-752378eaeaf2@github.com>
Message-ID: <HLn8XiMr_GgdsC4KrIeWBt-QYDQMy7AcuuSjJwi5Ehg=.6d21859f-f70e-40b6-8b08-85de0a611dc8@github.com>

On Wed, 1 Jun 2022 10:08:37 GMT, Tejesh R <tr at openjdk.org> wrote:

>> With the proposed fix, JList's focus ring color follows accent color changes. Previously the focus ring for JList was not prominently visible and did not follow accent color changes.
>> 
>> While investing a similar issue related to JTable (https://github.com/openjdk/jdk/pull/7768#discussion_r839813517), it was observed that List.focusCellHighlightBorder was using the cellFocusRing color as well. This PR extends the focus ring accent color changes to JLists. 
>> 
>> Related issues: [JDK-7124282](https://bugs.openjdk.java.net/browse/JDK-7124282) , [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243)
>> 
>> ####    Summary of changes
>> 
>> -  focusCellHighlightBorder in `AquaLookAndFeel` changed which is used for cell border for lists and tables
>> -  code related to on-the-fly focus ring color refactored into a separate method (`changeFocusRingColor()`) for re-usability 
>> -  `changeFocusRingColor()` called when PropertyChangeEvent == FRAME_ACTIVE_PROPERTY and the frame gains focus, instead of calling in individual `swapSelectionColors` in `AquaFocusHandler.java`
>> - Common test added - `CellFocusRingTest`, which tests for both cases - Tables & Lists. 
>> 
>> **Before and After screenshots of JList** _(Screenshots from SwingSet2 demo)_
>> 
>> ![Screen Shot 2022-05-25 at 3 55 49 PM](https://user-images.githubusercontent.com/95945681/170382727-54ed155b-6f08-4c75-8657-89c15764e1cd.png)
>
> test/jdk/javax/swing/JTable/CellFocusRingTest.java line 85:
> 
>> 83:         }
>> 84: 
>> 85:         if (UIManager.getDefaults().get("CellFocus.color") != null
> 
> if (UIManager.getDefaults().get("CellFocus.color") != null
>                 && UIManager.getDefaults().get("CellFocus.color")
>                 instanceof Color)
> 
> can be changed into 
> 
>         if (UIManager.getDefaults().get("CellFocus.color")
>                 instanceof Color)
> 
> Since if the object is null then `instanceof` returns false.

@TejeshR13 The second half of the condition is executed only if  `"CellFocus.color" != null` (due to and conditional)

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

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


From aivanov at openjdk.java.net  Wed Jun  1 17:13:34 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 1 Jun 2022 17:13:34 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v3]
In-Reply-To: <bawffD0qA8VOw8J0YI7r7NmggrjgCi22GC8cGWwaM00=.7bd09b07-c3e8-4768-8bd7-e97f274e5563@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <1-qMJRwjJVXF7BSrl5NCpoR9KMRBirtjJY--Kr6JueU=.e4a087a3-a7bb-4a93-a6ad-4a26954de78e@github.com>
 <DpvmclypIcCDXli-qMUwP9HpCimQ8JoEbEJXs6d-Nv4=.0c99e50c-3c26-492a-95cc-aa9b5302e861@github.com>
 <OgNizPtHLfftJ4PQtfTabyjvKu5p2-hKaO9SDIwOQpg=.af5401da-1c2d-4112-b114-c42a5a7d9007@github.com>
 <bawffD0qA8VOw8J0YI7r7NmggrjgCi22GC8cGWwaM00=.7bd09b07-c3e8-4768-8bd7-e97f274e5563@github.com>
Message-ID: <EJVvh3aTA5gUF3tFwuYT6o6ngxwMoYbbgkHrwWQOgFc=.cc6e06a4-f840-4267-8791-1be4aa7ea6fa@github.com>

On Wed, 1 Jun 2022 05:32:27 GMT, Tejesh R <tr at openjdk.org> wrote:

> > > I wonder why the test is Windows-specific if it allows changing Look and Feels.
> > > The only Look and Feel which ignores the background is Nimbus, other L&Fs on Windows at least paint the yellow and green background. As such, the test can be run on other platforms.
> > > Was the original bug in Windows Look and Feel? If so, you may want to make it the default L&F.
> > > The instructions don't mention anything about other Look and Feels. Does the tester have to verify each presented L&F?
> > 
> > 
> > I think the test was in windows which I might have retained the os type, will check and confirm once. The tester have to verify with each L&F for left margin check.
> 
> Yeah, it was only for Motif and Windows before, so I have retained it for only windows os.

I can see no reason why the test is for Windows only.

The original bug [JDK-4380543](https://bugs.openjdk.java.net/browse/JDK-4380543) lists all the operating systems as affected. Then [JDK-8134640](https://bugs.openjdk.java.net/browse/JDK-8134640) asked to support all Look-and-Feels, which somewhat implies other platforms should also be tested.

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

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


From prr at openjdk.java.net  Wed Jun  1 17:21:35 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 1 Jun 2022 17:21:35 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF [v2]
In-Reply-To: <HGu1Mq4x4nQ7xlW8yB74G4MFGPDuAfpnv8G3B9qdBq0=.81d0bc65-201a-438a-b1a1-0d78336ce287@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
 <HGu1Mq4x4nQ7xlW8yB74G4MFGPDuAfpnv8G3B9qdBq0=.81d0bc65-201a-438a-b1a1-0d78336ce287@github.com>
Message-ID: <qRpGrYIx-GH0_5bPk9K6CBpv6w2DA2wFd_8S05a11aM=.61ddc633-e4ba-412f-94d5-afe0625a5e28@github.com>

On Wed, 1 Jun 2022 05:30:23 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The tooltip displays accelerated string along with the toooltip string. The feature is implemented and applicable for Metal Look and Feel only. Hence the test is updated for Metal Look and Feel by hard wiring it in the code. Updated the test from manual to automatic.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused parameter isTooltipAdded

Marked as reviewed by prr (Reviewer).

test/jdk/javax/swing/JToolTip/bug5047379.java line 137:

> 135:         text += "The word \\\"TEXT\\\" and then \\\"CTRL-B\\\"\\n\"\t\t";
> 136:         text += "\n";
> 137: 

"Mouse is hover over button B for the ToolTip to appear." ?
Harmless to have this message but even though no one will be there to read it (usually)
it would be nice for it to read properly.

Please fix before pushing.
How about "The mouse will hover over button B so the ToolTip will appear." ?

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

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


From aivanov at openjdk.java.net  Wed Jun  1 17:41:35 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 1 Jun 2022 17:41:35 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v4]
In-Reply-To: <inqwY6uHTSczUgoVcntLUOStCc8k7IfdP4elYZHXxsA=.7f0ea7ae-71d4-454b-a5f4-46a3c75b25a7@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <BPd77K5HjZdYVu_lGYJFVRT8UHqqGLKdCMl74t0BeGk=.78ead183-e30b-46b7-a5f5-efc3b4cdfd3c@github.com>
 <KLaHd-f0_bx7YZRE4vrRHrdzLwgg61aBpgBu7X4Q06s=.cf65e394-802c-4940-b402-08bb96fa3003@github.com>
 <inqwY6uHTSczUgoVcntLUOStCc8k7IfdP4elYZHXxsA=.7f0ea7ae-71d4-454b-a5f4-46a3c75b25a7@github.com>
Message-ID: <BFV53rTpa5ga23UuxvzrIDHQl-yDq9AmMa5OVaN3hbI=.21630449-11b3-4101-93b6-d6b8e195f0a9@github.com>

On Wed, 1 Jun 2022 16:35:01 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> > Shall the test be located in `test/jdk/javax/swing/JRadioButton/4380543/bug4380543.java` instead of `test/jdk/javax/swing/JRadioButton/bug4380543.java` ?
> > Usually, there's been a folder with bugid (`/4380543/`) for each test. Do we use the flat layout now?
> 
> @aivanov-jdk Recently we have started to use the latter and remove the extra folder (`/4380543/`)

Thank you for clarification, Harshitha.

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

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


From prr at openjdk.java.net  Wed Jun  1 17:43:38 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 1 Jun 2022 17:43:38 GMT
Subject: RFR: 8286481: Exception printed to stdout on Windows when storing
 transparent image in clipboard
In-Reply-To: <PMPU9OzvBtCWpj0uYATUGfR0raSP42yQN1yiqLutiNk=.16ea65c9-0ee7-4ca7-a52b-3c5fcba8f484@github.com>
References: <PMPU9OzvBtCWpj0uYATUGfR0raSP42yQN1yiqLutiNk=.16ea65c9-0ee7-4ca7-a52b-3c5fcba8f484@github.com>
Message-ID: <ycTGSGoahBrn-qnEOEVA033z5chvKj2iToNIA8sk870=.af8df893-a566-4881-8f09-7442909d4091@github.com>

On Tue, 24 May 2022 16:54:55 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Removed stacktrace from WClipboard

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.java.net  Wed Jun  1 17:47:21 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 1 Jun 2022 17:47:21 GMT
Subject: RFR: 8286846:
 test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on mac
 aarch64
In-Reply-To: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com>
References: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com>
Message-ID: <L9uyIuMq0pX4JFxKDJA_5LrWn30zSKWdPNMtlB4fSvw=.7fe5c43c-9c58-452e-8345-5340ab1c8a48@github.com>

On Tue, 24 May 2022 08:28:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing intermiitently in iMac M1 system owing to minimalistic color difference of 1 
> 
> x 13 y 0 refRGB ffeeeeee customRGB ffefeeee
> x 0 y 0 refRGB ffefefef customRGB ffefeeef
> 
> 
> so added color tolerance check. 
> Also, added other stability fixes..
> Several iteration of test passed in intended M1 and x64 system.

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.java.net  Wed Jun  1 17:47:21 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 1 Jun 2022 17:47:21 GMT
Subject: RFR: 8286846:
 test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on mac
 aarch64
In-Reply-To: <A6N83T7vnuRXo7N4aHvZqIAHdR1j5tGdmKWnfHswL6o=.1db1c55d-cb18-42d5-9725-996929c44dc3@github.com>
References: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com>
 <uLledbc9sMcPZpjkbQ7P8uFvUtzC8et-ivNPKJK1NyY=.5b1b01e9-b10e-4ada-8cdc-ff7979bdbe63@github.com>
 <yGQUUpbB8HCsfJDq5uJ-nv3kCZ8n7vJr7wa8jGju6VA=.1021dcf0-f109-4b53-b124-879c10328e39@github.com>
 <A6N83T7vnuRXo7N4aHvZqIAHdR1j5tGdmKWnfHswL6o=.1db1c55d-cb18-42d5-9725-996929c44dc3@github.com>
Message-ID: <n2oJL-eAVCw79Z7BWYcOykjHJO1K0RnTXMe2UpJiWnY=.b6024fe2-0d43-4ac8-89e5-9e920c02d960@github.com>

On Mon, 30 May 2022 07:15:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Yes for standalone testing for which I also removed dependancy on jtreg Platform class
>
> Any reviewers please?

I prefer .toLoweCase().startsWith("mac") since the OS is called "macOS" not "macOS X" but that's just me ..

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

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


From prr at openjdk.java.net  Wed Jun  1 17:52:34 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 1 Jun 2022 17:52:34 GMT
Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray
 [v3]
In-Reply-To: <UWwEMift6h_AIxKxKymzR7Lo8bs82zDSGgsc_u-UQw4=.dedb3a0d-8cfb-4aa2-917b-8c4dbf01c239@github.com>
References: <KbpNZ7Yzxx6cUu_DQI5QawOSz2BfkC02EgzR28gUiyU=.3c2abcd2-54ba-4eea-803d-d04a611df9ed@github.com>
 <UWwEMift6h_AIxKxKymzR7Lo8bs82zDSGgsc_u-UQw4=.dedb3a0d-8cfb-4aa2-917b-8c4dbf01c239@github.com>
Message-ID: <vJANpCH0GAvTep9V6WFbhbjZiMZySiFzL3mVuQkqxh4=.df6561d7-b216-4242-a216-a430df959d06@github.com>

On Fri, 27 May 2022 20:48:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> **WTrayIconPeer**: removed duplicate call to `popupParent.dispose()` that might cause NPE (it looks `popupParent` cannot be `null`); organised imports.
>> 
>> **SystemTray**: removed redundant initialisers; replaced sized array with empty array in `toArray` call; dropped `newValue != null` chained with `equals`.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use method reference in setSystemTrayAccessor instead of anonymous class

Marked as reviewed by prr (Reviewer).

> If method reference is used, the code becomes much shorter:
> 
> ```java
>         AWTAccessor.setSystemTrayAccessor(SystemTray::firePropertyChange);
> ```
> 
> What do others think?

I am sure this code pre-dates method references, but if updating something then using method references is perfectly OK.

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

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


From honkar at openjdk.java.net  Wed Jun  1 17:53:32 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Wed, 1 Jun 2022 17:53:32 GMT
Subject: RFR: 8286846:
 test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on mac
 aarch64
In-Reply-To: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com>
References: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com>
Message-ID: <jbzHnAjO-qLjyOFtcIGL2a-ppuPLevetPz7nE4XObDs=.fd247836-3580-488f-a925-60cbdb690e3c@github.com>

On Tue, 24 May 2022 08:28:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing intermiitently in iMac M1 system owing to minimalistic color difference of 1 
> 
> x 13 y 0 refRGB ffeeeeee customRGB ffefeeee
> x 0 y 0 refRGB ffefefef customRGB ffefeeef
> 
> 
> so added color tolerance check. 
> Also, added other stability fixes..
> Several iteration of test passed in intended M1 and x64 system.

Marked as reviewed by honkar (Author).

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

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


From prr at openjdk.java.net  Wed Jun  1 17:56:31 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 1 Jun 2022 17:56:31 GMT
Subject: RFR: 8213531: Test javax/swing/border/TestTitledBorderLeak.java
 fails [v3]
In-Reply-To: <DjbGwJyR1BYwfCO-zgm_P7KC-aC0_o-X5vN4v2tp-Nc=.da494719-d808-4ff9-8bb6-e54db65e2fe7@github.com>
References: <Njia7F66IINfJqmT-OBEOXwoNbmPHh7ZuOHWzq2ZZLE=.228e4222-fbbb-45bc-9f02-cec6edaeb91d@github.com>
 <DjbGwJyR1BYwfCO-zgm_P7KC-aC0_o-X5vN4v2tp-Nc=.da494719-d808-4ff9-8bb6-e54db65e2fe7@github.com>
Message-ID: <c6PJ0GCdhL8JjePHsUV8crnnDk5v29Thq9XBkTOpsks=.16d81e4d-a72a-4186-839b-89bada999a6d@github.com>

On Sat, 28 May 2022 08:41:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test was failing in linux citing `java.lang.RuntimeException: Expected Total TitledBorder to be freed : 10 Freed 9 `
>> As per the fix done in JDK-8204963 http://hg.openjdk.java.net/jdk/jdk/rev/cd7d2f9154fd
>> there was no platform specific code done for the fix and logs in `TitledBorder.installPropertyChangeListeners` shows it was called 10 times for the test but `CleanerFactory.cleaner().register` action was only called 9 times in linux causing it to fail.
>> 
>> Modified the test to not show the frame which cause the problem to go away and also it can still be used as 8204963 regression test as it still fails without the fix and pass with it. Modified test has passed in all platforms for several iterations.
>> 
>> Also removed the deprecated `System.runFinalization`
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made test headless

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.java.net  Wed Jun  1 18:04:37 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 1 Jun 2022 18:04:37 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v4]
In-Reply-To: <BFV53rTpa5ga23UuxvzrIDHQl-yDq9AmMa5OVaN3hbI=.21630449-11b3-4101-93b6-d6b8e195f0a9@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <BPd77K5HjZdYVu_lGYJFVRT8UHqqGLKdCMl74t0BeGk=.78ead183-e30b-46b7-a5f5-efc3b4cdfd3c@github.com>
 <KLaHd-f0_bx7YZRE4vrRHrdzLwgg61aBpgBu7X4Q06s=.cf65e394-802c-4940-b402-08bb96fa3003@github.com>
 <inqwY6uHTSczUgoVcntLUOStCc8k7IfdP4elYZHXxsA=.7f0ea7ae-71d4-454b-a5f4-46a3c75b25a7@github.com>
 <BFV53rTpa5ga23UuxvzrIDHQl-yDq9AmMa5OVaN3hbI=.21630449-11b3-4101-93b6-d6b8e195f0a9@github.com>
Message-ID: <yM3FXEyoJTejhkKUhm1vf79-H9e-tgch259oDLqRaJc=.404d02bf-68d8-4fd5-9861-0f17aac49824@github.com>

On Wed, 1 Jun 2022 17:37:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > Shall the test be located in `test/jdk/javax/swing/JRadioButton/4380543/bug4380543.java` instead of `test/jdk/javax/swing/JRadioButton/bug4380543.java` ?
> > > Usually, there's been a folder with bugid (`/4380543/`) for each test. Do we use the flat layout now?
> > 
> > 
> > @aivanov-jdk Recently we have started to use the latter and remove the extra folder (`/4380543/`)
> 
> Thank you for clarification, Harshitha.

Yes, blame (?) me :-) 
We may not always remember to point it out but it is what we want.
I've never seen the point in an extra level of folder except when the test is composed of multiple files all unique to the test.
I also request that new tests not be given names like bug87654321.java but instead be named in a way that you can tell what they are supposed to be testing like in this case something like RadioButtonMarginTest.java

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

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


From duke at openjdk.java.net  Wed Jun  1 18:09:26 2022
From: duke at openjdk.java.net (Nikita Gubarkov)
Date: Wed, 1 Jun 2022 18:09:26 GMT
Subject: RFR: 8287609: macOS: SIGSEGV at [CoreFoundation] CFArrayGetCount /
 sun.font.CFont.getTableBytesNative
In-Reply-To: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
References: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
Message-ID: <DrAtcZhGp0hD82z2_27vC7ascehDTuLNKoTLbLuItJM=.51d626af-8c51-4d37-bbfc-945dfa6da35a@github.com>

On Tue, 31 May 2022 23:39:09 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

> `CTFontCopyAvailableTables` can return null, which causes subsequent call to `CFArrayGetCount` to crash with SEGFAULT, just added a null-check.

<img width="1391" alt="Screen Shot 2022-06-01 at 8 20 04 PM" src="https://user-images.githubusercontent.com/9004656/171468848-58612bb1-6432-4c76-a13c-054e7f97f6d6.png">
It looks for a "maxp" table which is absent for this font. If you look down the stack, it's trying to find units per em and if we return NULL, then it just falls back to upem=1000 (libharfbuzz/hb-ot-head-table.hh:53):


/* If no valid head table found, assume 1000, which matches typical Type1 usage. */
return 16 <= upem && upem <= 16384 ? upem : 1000;


And as I can see, nobody expects `getTableBytesNative` to always return a table, it's perfectly fine to return NULL when it's not found. The only question is why `CTFontCopyAvailableTables` returns NULL - font handle looks OK as you can see on the screenshot.

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

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


From prr at openjdk.java.net  Wed Jun  1 18:38:38 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 1 Jun 2022 18:38:38 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v4]
In-Reply-To: <GfNe4SPaVPHLXSdSKAQpG5niCBbh9-AA6EylBsForNQ=.7d5d28de-68db-4ab9-979c-00bffbfabe90@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <GfNe4SPaVPHLXSdSKAQpG5niCBbh9-AA6EylBsForNQ=.7d5d28de-68db-4ab9-979c-00bffbfabe90@github.com>
Message-ID: <pj2AY_45bxMDpHOaah4wEhFQLDu4iFpFxfHofNBLMCs=.9a25ac10-a5b6-414f-b7a0-9159258c37f5@github.com>

On Tue, 31 May 2022 22:08:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed print statements.

src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java line 27:

> 25: package javax.swing.text.html;
> 26: 
> 27: import sun.swing.SwingUtilities2;

Hmm .. there's no change in this file except for import clean up.
Ordinarily I'd say revert but I can see it was quite a chunk ..

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1123:

> 1121:          */
> 1122:         public void handleComment(char[] data, int pos) {
> 1123:             System.out.println("HTMLEditorKit");

And this one ?

src/java.desktop/share/classes/javax/swing/text/html/parser/DocumentParser.java line 34:

> 32: import javax.swing.text.SimpleAttributeSet;
> 33: import javax.swing.text.html.HTML;
> 34: import javax.swing.text.html.HTMLEditorKit;

Then there's these changes. OK .. too much .. let's just revert all the files that are import only changes.

test/jdk/javax/swing/text/html/parser/HtmlTagParserTest.java line 1:

> 1: import java.awt.Dimension;

where's the GPL header on this test ?

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

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


From prr at openjdk.java.net  Wed Jun  1 18:38:38 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 1 Jun 2022 18:38:38 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v4]
In-Reply-To: <pj2AY_45bxMDpHOaah4wEhFQLDu4iFpFxfHofNBLMCs=.9a25ac10-a5b6-414f-b7a0-9159258c37f5@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <GfNe4SPaVPHLXSdSKAQpG5niCBbh9-AA6EylBsForNQ=.7d5d28de-68db-4ab9-979c-00bffbfabe90@github.com>
 <pj2AY_45bxMDpHOaah4wEhFQLDu4iFpFxfHofNBLMCs=.9a25ac10-a5b6-414f-b7a0-9159258c37f5@github.com>
Message-ID: <_9URMX51lIIW9m37eSAVuX88OTBbxTWM-EJY1NXdz58=.2bd3fc59-fd07-4a2b-a4b6-bc55616d0eba@github.com>

On Wed, 1 Jun 2022 18:33:06 GMT, Phil Race <prr at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed print statements.
>
> src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java line 27:
> 
>> 25: package javax.swing.text.html;
>> 26: 
>> 27: import sun.swing.SwingUtilities2;
> 
> Hmm .. there's no change in this file except for import clean up.
> Ordinarily I'd say revert but I can see it was quite a chunk ..

update .. please revert .. I guess the IDE can re-do this when we touch it next

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

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


From honkar at openjdk.java.net  Wed Jun  1 19:40:34 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Wed, 1 Jun 2022 19:40:34 GMT
Subject: RFR: JDK-8287261: [macos] JList Focus Ring color doesn't follow
 Accent color changes on macOS [v2]
In-Reply-To: <m7Go1P8BVJLcyEarJLHiwHUsBKeQ5GnxvHmoKYnfmXo=.8851e019-707c-455a-9a02-249ea8ab2681@github.com>
References: <m7Go1P8BVJLcyEarJLHiwHUsBKeQ5GnxvHmoKYnfmXo=.8851e019-707c-455a-9a02-249ea8ab2681@github.com>
Message-ID: <Mhi36CMVtntJZOkDMIc6fCc2sy8m0X4sFIqXKye7bRs=.4c8279d5-e89c-49ee-9e4d-54da79c8700a@github.com>

> With the proposed fix, JList's focus ring color follows accent color changes. Previously the focus ring for JList was not prominently visible and did not follow accent color changes.
> 
> While investing a similar issue related to JTable (https://github.com/openjdk/jdk/pull/7768#discussion_r839813517), it was observed that List.focusCellHighlightBorder was using the cellFocusRing color as well. This PR extends the focus ring accent color changes to JLists. 
> 
> Related issues: [JDK-7124282](https://bugs.openjdk.java.net/browse/JDK-7124282) , [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243)
> 
> ####    Summary of changes
> 
> -  focusCellHighlightBorder in `AquaLookAndFeel` changed which is used for cell border for lists and tables
> -  code related to on-the-fly focus ring color refactored into a separate method (`changeFocusRingColor()`) for re-usability 
> -  `changeFocusRingColor()` called when PropertyChangeEvent == FRAME_ACTIVE_PROPERTY and the frame gains focus, instead of calling in individual `swapSelectionColors` in `AquaFocusHandler.java`
> - Common test added - `CellFocusRingTest`, which tests for both cases - Tables & Lists. 
> 
> **Before and After screenshots of JList** _(Screenshots from SwingSet2 demo)_
> 
> ![Screen Shot 2022-05-25 at 3 55 49 PM](https://user-images.githubusercontent.com/95945681/170382727-54ed155b-6f08-4c75-8657-89c15764e1cd.png)

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  removed redundant null checks in test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8896/files
  - new: https://git.openjdk.java.net/jdk/pull/8896/files/54e54719..e98484fe

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

  Stats: 110 lines in 2 files changed: 40 ins; 55 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8896.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8896/head:pull/8896

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


From honkar at openjdk.java.net  Wed Jun  1 19:40:36 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Wed, 1 Jun 2022 19:40:36 GMT
Subject: RFR: JDK-8287261: [macos] JList Focus Ring color doesn't follow
 Accent color changes on macOS [v2]
In-Reply-To: <HLn8XiMr_GgdsC4KrIeWBt-QYDQMy7AcuuSjJwi5Ehg=.6d21859f-f70e-40b6-8b08-85de0a611dc8@github.com>
References: <m7Go1P8BVJLcyEarJLHiwHUsBKeQ5GnxvHmoKYnfmXo=.8851e019-707c-455a-9a02-249ea8ab2681@github.com>
 <jsOeD9XWdvem1u9HmFnc6G0yjrOs_KwJU1CzbchbIcc=.cc0c3ed4-8787-4c00-9069-752378eaeaf2@github.com>
 <HLn8XiMr_GgdsC4KrIeWBt-QYDQMy7AcuuSjJwi5Ehg=.6d21859f-f70e-40b6-8b08-85de0a611dc8@github.com>
Message-ID: <Vjyl3VBZUbWkqlNbovEkXmqzLOXF3Xp2XvyAYx_j7XA=.7e033d48-a7bd-41d5-9e1d-5423d0b84bc2@github.com>

On Wed, 1 Jun 2022 16:54:43 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/swing/JTable/CellFocusRingTest.java line 85:
>> 
>>> 83:         }
>>> 84: 
>>> 85:         if (UIManager.getDefaults().get("CellFocus.color") != null
>> 
>> if (UIManager.getDefaults().get("CellFocus.color") != null
>>                 && UIManager.getDefaults().get("CellFocus.color")
>>                 instanceof Color)
>> 
>> can be changed into 
>> 
>>         if (UIManager.getDefaults().get("CellFocus.color")
>>                 instanceof Color)
>> 
>> Since if the object is null then `instanceof` returns false.
>
> @TejeshR13 Your suggestion was to remove redundant null check. Correct, this is a better way to shorten the condition. Will have the changes done in the next commit.

Updated PR with changes

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

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


From avu at openjdk.java.net  Wed Jun  1 20:29:59 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 1 Jun 2022 20:29:59 GMT
Subject: RFR: 8287600: AA Ovals not rendered under metal
Message-ID: <XZl-tJGUpOqvDVtGhsG3k0sogD0IwWwjKFkfXuMgKIQ=.0aa9c8c2-3915-4b0b-8949-cb31f0affdf2@github.com>

Commit command buffer after MTL_OP_MASK_OP operation

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

Commit messages:
 - 8287600: AA Ovals not rendered under metal

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

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


From prr at openjdk.java.net  Wed Jun  1 20:54:20 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 1 Jun 2022 20:54:20 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v6]
In-Reply-To: <bY1l-V3cTfTzvkTbDCmA1BK8yOXm6EmcEvb0mSvAIVc=.7ea0dc3f-c3a5-4071-8830-797b31ba2286@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <bY1l-V3cTfTzvkTbDCmA1BK8yOXm6EmcEvb0mSvAIVc=.7ea0dc3f-c3a5-4071-8830-797b31ba2286@github.com>
Message-ID: <J0hcAhJxvJG8B1YWxNKbR7XnilWiHzXdWlCxDywi1aU=.5ef2a55e-1ac5-4b67-b091-d348a61f6c5f@github.com>

On Sat, 28 May 2022 03:41:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added UTF-8 korean fallback

Something weird is going on .. 
Malgun is now not appearing in the font menu of Font2DTest when I use  ko + UTF-8 !?
It appears if I use -Dfile.encoding=ko instead.

Something we are doing is hiding it.

Also can you attach the source of your test to JBS !

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

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


From aturbanov at openjdk.java.net  Wed Jun  1 20:55:34 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 1 Jun 2022 20:55:34 GMT
Subject: RFR: 8284672: Collapse identical catch branches in java.desktop
 [v2]
In-Reply-To: <sHkXMpkUXAG5rkkJnednTmISoY4Li2RNOFQcf6zytQ8=.1afdaf08-c759-4ef7-b11c-b63b3d983e04@github.com>
References: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
 <sHkXMpkUXAG5rkkJnednTmISoY4Li2RNOFQcf6zytQ8=.1afdaf08-c759-4ef7-b11c-b63b3d983e04@github.com>
Message-ID: <Qhm51ibMOoE-vKp1zECWtwEQhExJ5jQOQxtI1aEn6sA=.fa1de9e0-b7ce-4b05-ad49-38f036a6bbb0@github.com>

On Wed, 27 Apr 2022 04:40:29 GMT, Phil Race <prr at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8284672: Collapse identical catch branches in java.desktop
>>   fix formatting
>
> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java line 610:
> 
>> 608:                     }
>> 609:                 } catch (MalformedURLException ex) {
>> 610:                     // OK to just ignore. We'll use a fallback theme.
> 
> subclass of IOException I suppose

Yes. `MalformedURLException extends IOException`

> src/java.desktop/share/classes/com/sun/media/sound/DLSSoundbankReader.java line 50:
> 
>> 48:         try {
>> 49:             return new DLSSoundbank(url);
>> 50:         } catch (IOException e) {
> 
> So how can this method throw the declared IOException ?
> Hmm I suppose the API super-class declares it is

Yep. Inherited throws section from a super method

> src/java.desktop/share/classes/com/sun/media/sound/SF2SoundbankReader.java line 50:
> 
>> 48:         try {
>> 49:             return new SF2Soundbank(url);
>> 50:         } catch (IOException e) {
> 
> same here

Yeah. I think it makes sense to amend behavior here and not catch IOException. Callers should be ready for it.

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

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


From aturbanov at openjdk.java.net  Wed Jun  1 20:55:30 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 1 Jun 2022 20:55:30 GMT
Subject: RFR: 8284672: Collapse identical catch branches in java.desktop
 [v2]
In-Reply-To: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
References: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
Message-ID: <TLLG7XM4wV1Q7douly657vwd36dod5qUFMICnl7wpJc=.982c2ba7-cfed-43cb-a68d-4077b07bf4f7@github.com>

> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types".
> It simplifies code. Reduces duplication.
> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement

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

  8284672: Collapse identical catch branches in java.desktop
  fix formatting

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8154/files
  - new: https://git.openjdk.java.net/jdk/pull/8154/files/bc19ec42..66906b3c

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

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

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


From serb at openjdk.java.net  Wed Jun  1 23:17:35 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 1 Jun 2022 23:17:35 GMT
Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray
 [v3]
In-Reply-To: <aqs63xmcMgf9j6Xeni7pnO92ylQb-NijP8rXZmSxhJc=.a177c6f2-8cf4-4508-a654-514ced365158@github.com>
References: <KbpNZ7Yzxx6cUu_DQI5QawOSz2BfkC02EgzR28gUiyU=.3c2abcd2-54ba-4eea-803d-d04a611df9ed@github.com>
 <lDGxeWeYDdowZ7jpQTrawRBVrMwkgQ0edJAiagSi5Ic=.0951f5d8-20ec-464a-b088-a65ce68fd4f4@github.com>
 <Xd4CzrPr1AsWVUqE8H1sQh7rhDxwNpzONJmU6GC2GXo=.f5ad4c02-8ba8-40e4-8747-61d4cf265ec0@github.com>
 <HwzaK7Njmx3c0YvB_1bSh0LyGO9Baxb_STHAkjlJRz4=.6a15c920-5c57-4eab-ac55-81210acfbc68@github.com>
 <qtbLqKoaHcQ3GJVFSyXoNl_gH3MQNjs108Q0sMKA7-8=.8f17c05e-7b73-4ccd-90c6-1baa6808107a@github.com>
 <pwZkx94UwE7kuUEwsqyQCaCs_ZbxkWima6yMJ1xZCPs=.8efccb89-50bb-48a9-aa82-cee4d744e78d@github.com>
 <Uhg45FWYFo_B7Sq6foqI5-9XB3rGcT6TjdFrCoJqRSI=.d3db6fb8-0a13-4c16-abbc-382561b49c66@github.com>
 <bMMLXijtdz77iocU87ImhIIMy1DYacYxvZ_rgAPkcSM=.6f9a8003-b6b7-433a-aa02-90cd27257957@github.com>
 <qthngcip1goWBnZ3wuFo_a0V3tgDdd3nTJ4UKR8BbTo=.b703ffc6-7609-42fa-8ea9-cf0e39727a24@github.com>
 <aqs63xmcMgf9j6Xeni7pnO92ylQb-NijP8rXZmSxhJc=.a177c6f2-8cf4-4508-a654-514ced365158@github.com>
Message-ID: <MKq3xRtF0NXWZaxuVAkzcl62g36EKKIdwO3Fr5DDids=.fb2869d4-960f-4130-91a6-652792612791@github.com>

On Tue, 24 May 2022 11:16:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It also has a functional implication, in the old code  the "size" on a Vector is called outside of the lock. So the resulted array after "icons.toArray" can be bigger than the number of icons. This is similar to this:
>> https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/classes/javax/sound/midi/Sequence.java#L281
>> I think that race can even be triggered by the new test.
>
> I remember IDEs used to suggest using correctly sized arrays in the calls to `toArray`. Now they suggest using zero-sized array.
> 
> My idea was to resolve the warning raised by the IDE to reduce the number of yellow highlights on the file outline.
> 
> I agree the performance gain if any is negligible in this case: we don't expect many icons, probably no more than 3.

The IDE warning was changed based on the article above. Did you have a chance to reproduce a possible race caused by data change after the size() was called?

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

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


From serb at openjdk.java.net  Wed Jun  1 23:55:20 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 1 Jun 2022 23:55:20 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
Message-ID: <ms8g1-XqOxHCBTQIO8vyRbli10-TE_m1rjaJhDPf1AM=.281afbc5-bf1a-427a-9dd8-3476db10b7e1@github.com>

On Fri, 27 May 2022 18:02:51 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Detect the situation where we do need to perform interpolation during ImageIcon
>> painting and set a hint to the rendering to perform bicubic approximation so
>> image details are preserved during transition.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use small icon pointer for icons less than 24 pixels wide - this way we
>   get the 16x16 icon which is better for scaling purposes.

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 987:

> 985:                 size = 16;
> 986:             }
> 987:             hres = pIcon->Extract(szBuf, index, &hIcon, &hIconSmall, size);

Looking into this change I assume that the reason why the windows "ignores" the requested size of 16x16 was that we request the size 16x16 but after that used the large icon only which is 32x32 by default, is it correct?

The last parameter of [this](https://docs.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-iextracticonw-extract) method:
>nIconSize
The desired size of the icon, in pixels. The low word contains the size of the large icon, and the high word contains the size of the small icon. The size specified can be the width or height. The width of an icon always equals its height.

Do we need to update the size value and take into account the low/hi sizes?

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 993:

> 991:             } else {
> 992:                 fn_DestroyIcon((HICON)hIconSmall);
> 993:             }

Does it mean that we will extract all images except on the sides twice? for 16x16 we will extract 16x16 and 32x32 on the next iteration for 32x32 we will extract 32x32 and 64x64?

Can we try to do that via different API: https://devblogs.microsoft.com/oldnewthing/20140501-00/?p=1103 probably it will work better?

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

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


From serb at openjdk.java.net  Thu Jun  2 00:12:30 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Jun 2022 00:12:30 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <8vrDNTJTPocLihty5ZMoBaqGEX23B4gXxis8TtBvuZ8=.5700255b-33a0-4b17-bbb2-523f5a19e9c8@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
 <8vrDNTJTPocLihty5ZMoBaqGEX23B4gXxis8TtBvuZ8=.5700255b-33a0-4b17-bbb2-523f5a19e9c8@github.com>
Message-ID: <pUMmlnzsQYsXWupnuut2VWEs2pHDHZdpqas9MngxlQY=.b6ede20b-e114-426e-94f7-8853c215c249@github.com>

On Fri, 27 May 2022 18:12:59 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> On 10000 iterations the difference is measurable in tens of milliseconds between test runs. On 100000 iterations test execution with BICUBIC approximation is noticeable (like test run takes more than a second longer).

Not an ideal benchmark but it shows that the bicubic is ~200 times slower.

public static void main(String[] args) {
        var gc =
                GraphicsEnvironment.getLocalGraphicsEnvironment()
                                                  .getDefaultScreenDevice()
                                                  .getDefaultConfiguration();
        var vi = gc.createCompatibleVolatileImage(50, 50,
                                                  Transparency.TRANSLUCENT);
        var bi = new BufferedImage(50,50,BufferedImage.TYPE_INT_ARGB);
        Graphics2D g2d = vi.createGraphics();
        g2d.scale(2,2);
        test(bi, g2d);// warmup
        test(bi, g2d);
        g2d.setRenderingHint(RenderingHints.KEY_INTERPOLATION,
                             RenderingHints.VALUE_INTERPOLATION_BICUBIC);
        test(bi, g2d);// warmup
        test(bi, g2d);
    }

    private static void test(BufferedImage bi, Graphics2D g2d) {
        long start = System.nanoTime();
        for (int i = 0; i < 1000; ++i) {
            g2d.drawImage(bi, null, 0, 0);
        }
        long time = System.nanoTime() - start;
        System.out.println("Time: " + time);
    }

Time: 21313400
Time: 4036200
Time: 1140613100
Time: 839499200

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

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


From serb at openjdk.java.net  Thu Jun  2 00:39:27 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Jun 2022 00:39:27 GMT
Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray
 [v3]
In-Reply-To: <MKq3xRtF0NXWZaxuVAkzcl62g36EKKIdwO3Fr5DDids=.fb2869d4-960f-4130-91a6-652792612791@github.com>
References: <KbpNZ7Yzxx6cUu_DQI5QawOSz2BfkC02EgzR28gUiyU=.3c2abcd2-54ba-4eea-803d-d04a611df9ed@github.com>
 <lDGxeWeYDdowZ7jpQTrawRBVrMwkgQ0edJAiagSi5Ic=.0951f5d8-20ec-464a-b088-a65ce68fd4f4@github.com>
 <Xd4CzrPr1AsWVUqE8H1sQh7rhDxwNpzONJmU6GC2GXo=.f5ad4c02-8ba8-40e4-8747-61d4cf265ec0@github.com>
 <HwzaK7Njmx3c0YvB_1bSh0LyGO9Baxb_STHAkjlJRz4=.6a15c920-5c57-4eab-ac55-81210acfbc68@github.com>
 <qtbLqKoaHcQ3GJVFSyXoNl_gH3MQNjs108Q0sMKA7-8=.8f17c05e-7b73-4ccd-90c6-1baa6808107a@github.com>
 <pwZkx94UwE7kuUEwsqyQCaCs_ZbxkWima6yMJ1xZCPs=.8efccb89-50bb-48a9-aa82-cee4d744e78d@github.com>
 <Uhg45FWYFo_B7Sq6foqI5-9XB3rGcT6TjdFrCoJqRSI=.d3db6fb8-0a13-4c16-abbc-382561b49c66@github.com>
 <bMMLXijtdz77iocU87ImhIIMy1DYacYxvZ_rgAPkcSM=.6f9a8003-b6b7-433a-aa02-90cd27257957@github.com>
 <qthngcip1goWBnZ3wuFo_a0V3tgDdd3nTJ4UKR8BbTo=.b703ffc6-7609-42fa-8ea9-cf0e39727a24@github.com>
 <aqs63xmcMgf9j6Xeni7pnO92ylQb-NijP8rXZmSxhJc=.a177c6f2-8cf4-4508-a654-514ced365158@github.com>
 <MKq3xRtF0NXWZaxuVAkzcl62g36EKKIdwO3
 Fr5DDids=.fb2869d4-960f-4130-91a6-652792612791@github.com>
Message-ID: <X9rNJalr7kqhZepLcDju-cOyEvRsZmZjblcJyHpT6LM=.e0f90c83-ca18-42f1-9568-b1a403c289d3@github.com>

On Wed, 1 Jun 2022 23:13:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I remember IDEs used to suggest using correctly sized arrays in the calls to `toArray`. Now they suggest using zero-sized array.
>> 
>> My idea was to resolve the warning raised by the IDE to reduce the number of yellow highlights on the file outline.
>> 
>> I agree the performance gain if any is negligible in this case: we don't expect many icons, probably no more than 3.
>
> The IDE warning was changed based on the article above. Did you have a chance to reproduce a possible race caused by data change after the size() was called?

I can reproduce it by this code example:

class Scratch {

    static volatile Throwable failed;
    static volatile long endtime;

    public static void main(String[] args) throws Exception {
        if (!SystemTray.isSupported()) {
            return; // passed if SystemTray is not supported
        }
        SystemTray st = SystemTray.getSystemTray();

        endtime = System.nanoTime() + TimeUnit.SECONDS.toNanos(5);

        Thread thread1 = new Thread(() -> {
            while (!isComplete()) {
                try {
                    st.add(new TrayIcon(new BufferedImage(10, 10,
                                                          BufferedImage.TYPE_INT_ARGB)));
                } catch (AWTException e) {
                    failed = e;
                }
            }
        });
        Thread thread2 = new Thread(() -> {
            while (!isComplete()) {
                try {
                    st.add(new TrayIcon(new BufferedImage(10, 10,
                                                          BufferedImage.TYPE_INT_ARGB)));
                } catch (AWTException e) {
                    failed = e;
                }
            }
        });
        Thread thread3 = new Thread(() -> {
            while (!isComplete()) {
                TrayIcon[] icons = st.getTrayIcons();
                if (icons.length > 0) {
                    st.remove(icons[0]);
                }
            }
        });
        Thread thread4 = new Thread(() -> {
            while (!isComplete()) {
                TrayIcon[] icons = st.getTrayIcons();
                if (icons.length > 0 && icons[icons.length - 1] == null) {
                    failed = new RuntimeException(
                            "icon is null:" + Arrays.toString(icons));
                }
            }
        });
        thread1.start();
        thread2.start();
        thread3.start();
        thread4.start();
        thread1.join();
        thread2.join();
        thread3.join();
        thread4.join();
        for (TrayIcon icon : st.getTrayIcons()) {
            st.remove(icon); // cleanup
        }
        if (failed != null) {
            System.err.println("Test failed");
            throw new RuntimeException(failed);
        }
    }

    private static boolean isComplete() {
        return endtime - System.nanoTime() < 0 || failed != null;
    }
}

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

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


From serb at openjdk.java.net  Thu Jun  2 00:39:27 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Jun 2022 00:39:27 GMT
Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray
 [v3]
In-Reply-To: <X9rNJalr7kqhZepLcDju-cOyEvRsZmZjblcJyHpT6LM=.e0f90c83-ca18-42f1-9568-b1a403c289d3@github.com>
References: <KbpNZ7Yzxx6cUu_DQI5QawOSz2BfkC02EgzR28gUiyU=.3c2abcd2-54ba-4eea-803d-d04a611df9ed@github.com>
 <lDGxeWeYDdowZ7jpQTrawRBVrMwkgQ0edJAiagSi5Ic=.0951f5d8-20ec-464a-b088-a65ce68fd4f4@github.com>
 <Xd4CzrPr1AsWVUqE8H1sQh7rhDxwNpzONJmU6GC2GXo=.f5ad4c02-8ba8-40e4-8747-61d4cf265ec0@github.com>
 <HwzaK7Njmx3c0YvB_1bSh0LyGO9Baxb_STHAkjlJRz4=.6a15c920-5c57-4eab-ac55-81210acfbc68@github.com>
 <qtbLqKoaHcQ3GJVFSyXoNl_gH3MQNjs108Q0sMKA7-8=.8f17c05e-7b73-4ccd-90c6-1baa6808107a@github.com>
 <pwZkx94UwE7kuUEwsqyQCaCs_ZbxkWima6yMJ1xZCPs=.8efccb89-50bb-48a9-aa82-cee4d744e78d@github.com>
 <Uhg45FWYFo_B7Sq6foqI5-9XB3rGcT6TjdFrCoJqRSI=.d3db6fb8-0a13-4c16-abbc-382561b49c66@github.com>
 <bMMLXijtdz77iocU87ImhIIMy1DYacYxvZ_rgAPkcSM=.6f9a8003-b6b7-433a-aa02-90cd27257957@github.com>
 <qthngcip1goWBnZ3wuFo_a0V3tgDdd3nTJ4UKR8BbTo=.b703ffc6-7609-42fa-8ea9-cf0e39727a24@github.com>
 <aqs63xmcMgf9j6Xeni7pnO92ylQb-NijP8rXZmSxhJc=.a177c6f2-8cf4-4508-a654-514ced365158@github.com>
 <MKq3xRtF0NXWZaxuVAkzcl62g36EKKIdwO3
 Fr5DDids=.fb2869d4-960f-4130-91a6-652792612791@github.com>
 <X9rNJalr7kqhZepLcDju-cOyEvRsZmZjblcJyHpT6LM=.e0f90c83-ca18-42f1-9568-b1a403c289d3@github.com>
Message-ID: <1zmgKAKgBzh5-I4aGlM0Egx64C-Fv3r2Yhl5R0Mu5ho=.c67c08aa-8d49-4550-9e07-505a93be3840@github.com>

On Thu, 2 Jun 2022 00:32:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The IDE warning was changed based on the article above. Did you have a chance to reproduce a possible race caused by data change after the size() was called?
>
> I can reproduce it by this code example:
> 
> class Scratch {
> 
>     static volatile Throwable failed;
>     static volatile long endtime;
> 
>     public static void main(String[] args) throws Exception {
>         if (!SystemTray.isSupported()) {
>             return; // passed if SystemTray is not supported
>         }
>         SystemTray st = SystemTray.getSystemTray();
> 
>         endtime = System.nanoTime() + TimeUnit.SECONDS.toNanos(5);
> 
>         Thread thread1 = new Thread(() -> {
>             while (!isComplete()) {
>                 try {
>                     st.add(new TrayIcon(new BufferedImage(10, 10,
>                                                           BufferedImage.TYPE_INT_ARGB)));
>                 } catch (AWTException e) {
>                     failed = e;
>                 }
>             }
>         });
>         Thread thread2 = new Thread(() -> {
>             while (!isComplete()) {
>                 try {
>                     st.add(new TrayIcon(new BufferedImage(10, 10,
>                                                           BufferedImage.TYPE_INT_ARGB)));
>                 } catch (AWTException e) {
>                     failed = e;
>                 }
>             }
>         });
>         Thread thread3 = new Thread(() -> {
>             while (!isComplete()) {
>                 TrayIcon[] icons = st.getTrayIcons();
>                 if (icons.length > 0) {
>                     st.remove(icons[0]);
>                 }
>             }
>         });
>         Thread thread4 = new Thread(() -> {
>             while (!isComplete()) {
>                 TrayIcon[] icons = st.getTrayIcons();
>                 if (icons.length > 0 && icons[icons.length - 1] == null) {
>                     failed = new RuntimeException(
>                             "icon is null:" + Arrays.toString(icons));
>                 }
>             }
>         });
>         thread1.start();
>         thread2.start();
>         thread3.start();
>         thread4.start();
>         thread1.join();
>         thread2.join();
>         thread3.join();
>         thread4.join();
>         for (TrayIcon icon : st.getTrayIcons()) {
>             st.remove(icon); // cleanup
>         }
>         if (failed != null) {
>             System.err.println("Test failed");
>             throw new RuntimeException(failed);
>         }
>     }
> 
>     private static boolean isComplete() {
>         return endtime - System.nanoTime() < 0 || failed != null;
>     }
> }

BTW I think that the usage of 
`return icons.toArray(EMPTY_TRAY_ARRAY);`
is slower than any of other cases: presized or zero. So if we would like to use a similar pattern the zero version is better.

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

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


From serb at openjdk.java.net  Thu Jun  2 00:46:33 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Jun 2022 00:46:33 GMT
Subject: RFR: 8285305: Create an automated test for JDK-4495286 [v3]
In-Reply-To: <ITRsSdwqqLK58_e-fgtaUZB8BWs88dwPrMkkSq48hvs=.456b44b7-f90f-41e5-9c8f-9442c62ad374@github.com>
References: <tfMcUiiqM3zbwahwkdBXMSFXcHiCqyZoRJLZgekkagQ=.5392b0b4-bd49-400a-8bf0-aef5f1354d6e@github.com>
 <ITRsSdwqqLK58_e-fgtaUZB8BWs88dwPrMkkSq48hvs=.456b44b7-f90f-41e5-9c8f-9442c62ad374@github.com>
Message-ID: <RO8VNI6yTyEz6o9_4Sba2JmHy4zesUbFdRJ-cJllZPo=.19eb0492-22b4-4fda-b9b2-b447357098cc@github.com>

On Wed, 18 May 2022 08:20:47 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4495286](https://bugs.openjdk.java.net/browse/JDK-4495286)
>> 
>> AccessibleJTable.setAccessibleSelction should select rows/cols when cell selection.
>> When cell selection is not enabled, there is no way, using
>> accessibility, to select rows or columns. It seems logical that selecting a cell
>> using accessibility should have the same effect as clicking on a cell with the
>> mouse. That is, if row or column selection is enabled, then selecting a cell
>> should instead cause the row or column to be selected.
>>  The proposed test verifies that the above behavior is fixed.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (40) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: moved the file directly under the a11y folder

Looks fine, please confirm that mach5 is green.

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

Marked as reviewed by serb (Reviewer).

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


From serb at openjdk.java.net  Thu Jun  2 00:50:40 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Jun 2022 00:50:40 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF [v2]
In-Reply-To: <HGu1Mq4x4nQ7xlW8yB74G4MFGPDuAfpnv8G3B9qdBq0=.81d0bc65-201a-438a-b1a1-0d78336ce287@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
 <HGu1Mq4x4nQ7xlW8yB74G4MFGPDuAfpnv8G3B9qdBq0=.81d0bc65-201a-438a-b1a1-0d78336ce287@github.com>
Message-ID: <OFHuZmUdn9LD5XjN1kH8M5DgQ3TTs5FgX8QDtFo2F1E=.824dd117-3b89-4d6d-8b2f-14b31fe7c340@github.com>

On Wed, 1 Jun 2022 05:30:23 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The tooltip displays accelerated string along with the toooltip string. The feature is implemented and applicable for Metal Look and Feel only. Hence the test is updated for Metal Look and Feel by hard wiring it in the code. Updated the test from manual to automatic.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused parameter isTooltipAdded

I think this feature was implemented someday for some L&Fs and then deleted. please double-check the history of releated bugs/files.

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

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


From serb at openjdk.java.net  Thu Jun  2 00:57:30 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Jun 2022 00:57:30 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF [v2]
In-Reply-To: <OFHuZmUdn9LD5XjN1kH8M5DgQ3TTs5FgX8QDtFo2F1E=.824dd117-3b89-4d6d-8b2f-14b31fe7c340@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
 <HGu1Mq4x4nQ7xlW8yB74G4MFGPDuAfpnv8G3B9qdBq0=.81d0bc65-201a-438a-b1a1-0d78336ce287@github.com>
 <OFHuZmUdn9LD5XjN1kH8M5DgQ3TTs5FgX8QDtFo2F1E=.824dd117-3b89-4d6d-8b2f-14b31fe7c340@github.com>
Message-ID: <3Z0TE9KWfpoFwVC8KCYi9DX7Lef8j-VmW_PB9bUd8Ko=.90847f16-5042-422e-a15d-e492fb3bb3f7@github.com>

On Thu, 2 Jun 2022 00:48:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I think this feature was implemented someday for some L&Fs and then deleted. please double-check the history of releated bugs/files.

Hmm, I thought this is a produce fix since it has a CSR in the description. The test for metal is fine.

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

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


From honkar at openjdk.java.net  Thu Jun  2 00:57:33 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Thu, 2 Jun 2022 00:57:33 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF [v2]
In-Reply-To: <HGu1Mq4x4nQ7xlW8yB74G4MFGPDuAfpnv8G3B9qdBq0=.81d0bc65-201a-438a-b1a1-0d78336ce287@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
 <HGu1Mq4x4nQ7xlW8yB74G4MFGPDuAfpnv8G3B9qdBq0=.81d0bc65-201a-438a-b1a1-0d78336ce287@github.com>
Message-ID: <fiYyDIe27LwF_GJPZgYyU9rpgUVbMANJuEZD26opzJg=.441039aa-5fde-4bf8-9406-dc28cff7ebaa@github.com>

On Wed, 1 Jun 2022 05:30:23 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The tooltip displays accelerated string along with the toooltip string. The feature is implemented and applicable for Metal Look and Feel only. Hence the test is updated for Metal Look and Feel by hard wiring it in the code. Updated the test from manual to automatic.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused parameter isTooltipAdded

test/jdk/javax/swing/JToolTip/bug5047379.java line 173:

> 171:         frame.setVisible(true);
> 172:     }
> 173: };

Extra semi colon at the end

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

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


From serb at openjdk.java.net  Thu Jun  2 00:58:19 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Jun 2022 00:58:19 GMT
Subject: RFR: JDK-8287261: [macos] JList Focus Ring color doesn't follow
 Accent color changes on macOS [v2]
In-Reply-To: <Mhi36CMVtntJZOkDMIc6fCc2sy8m0X4sFIqXKye7bRs=.4c8279d5-e89c-49ee-9e4d-54da79c8700a@github.com>
References: <m7Go1P8BVJLcyEarJLHiwHUsBKeQ5GnxvHmoKYnfmXo=.8851e019-707c-455a-9a02-249ea8ab2681@github.com>
 <Mhi36CMVtntJZOkDMIc6fCc2sy8m0X4sFIqXKye7bRs=.4c8279d5-e89c-49ee-9e4d-54da79c8700a@github.com>
Message-ID: <0qBB8EiFX2jC8stWm73ILBjH9b4n5ejPaH1F1xtS1W0=.1eb0f8d4-4458-4957-a460-4acc6bba77bd@github.com>

On Wed, 1 Jun 2022 19:40:34 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> With the proposed fix, JList's focus ring color follows accent color changes. Previously the focus ring for JList was not prominently visible and did not follow accent color changes.
>> 
>> While investing a similar issue related to JTable (https://github.com/openjdk/jdk/pull/7768#discussion_r839813517), it was observed that List.focusCellHighlightBorder was using the cellFocusRing color as well. This PR extends the focus ring accent color changes to JLists. 
>> 
>> Related issues: [JDK-7124282](https://bugs.openjdk.java.net/browse/JDK-7124282) , [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243)
>> 
>> ####    Summary of changes
>> 
>> -  focusCellHighlightBorder in `AquaLookAndFeel` changed which is used for cell border for lists and tables
>> -  code related to on-the-fly focus ring color refactored into a separate method (`changeFocusRingColor()`) for re-usability 
>> -  `changeFocusRingColor()` called when PropertyChangeEvent == FRAME_ACTIVE_PROPERTY and the frame gains focus, instead of calling in individual `swapSelectionColors` in `AquaFocusHandler.java`
>> - Common test added - `CellFocusRingTest`, which tests for both cases - Tables & Lists. 
>> 
>> **Before and After screenshots of JList** _(Screenshots from SwingSet2 demo)_
>> 
>> ![Screen Shot 2022-05-25 at 3 55 49 PM](https://user-images.githubusercontent.com/95945681/170382727-54ed155b-6f08-4c75-8657-89c15764e1cd.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed redundant null checks in test

Can you please double check how the native applications/components look when the colors are "similar".

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

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


From honkar at openjdk.java.net  Thu Jun  2 01:06:31 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Thu, 2 Jun 2022 01:06:31 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF [v2]
In-Reply-To: <HGu1Mq4x4nQ7xlW8yB74G4MFGPDuAfpnv8G3B9qdBq0=.81d0bc65-201a-438a-b1a1-0d78336ce287@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
 <HGu1Mq4x4nQ7xlW8yB74G4MFGPDuAfpnv8G3B9qdBq0=.81d0bc65-201a-438a-b1a1-0d78336ce287@github.com>
Message-ID: <K_YsCAXl8Sdm-cX3ibQgOu_ws_TYuitcT72JGnbappU=.213a480f-338f-4254-bd0e-2aa1c0ed1bd2@github.com>

On Wed, 1 Jun 2022 05:30:23 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The tooltip displays accelerated string along with the toooltip string. The feature is implemented and applicable for Metal Look and Feel only. Hence the test is updated for Metal Look and Feel by hard wiring it in the code. Updated the test from manual to automatic.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused parameter isTooltipAdded

test/jdk/javax/swing/JToolTip/bug5047379.java line 28:

> 26:    @summary Checks that Tooltips are rendered properly for Metal Look and Feel
> 27:    @library ../regtesthelpers
> 28:    @build Util

@TejeshR13 Can you please crosscheck the regtesthelpers & Util path. I'm unable to run it as jtreg test

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

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


From serb at openjdk.java.net  Thu Jun  2 01:17:20 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Jun 2022 01:17:20 GMT
Subject: RFR: 8213531: Test javax/swing/border/TestTitledBorderLeak.java
 fails [v2]
In-Reply-To: <3cFgKe1kh2sMLag9N4n4xEAR2Z9ZyGqc514s4aBbM6Q=.3b0fb8bf-a295-48af-910c-424012dc4307@github.com>
References: <Njia7F66IINfJqmT-OBEOXwoNbmPHh7ZuOHWzq2ZZLE=.228e4222-fbbb-45bc-9f02-cec6edaeb91d@github.com>
 <7f6imhO_fmNXVejmC3boQyV0uNjoHOJCiVzetcCOHpY=.b2d95eab-e3f7-45db-83ad-92e91e3a5585@github.com>
 <b1x5axDbRrDpEYidpd3JDn4TzGDS5W0WLO6dmgD-7pM=.c345f63d-9fce-467e-ac17-5eded94e891d@github.com>
 <l-wljOb1XLtUlzTA3e6rlSAyoMRKq4hOjEhcLzu1djw=.c4dca941-592a-4219-863f-5f11cf232752@github.com>
 <UqBJJVMgH5HQude_jW97hQXC49BTjNIXtS0F_toTDRA=.626ce0f8-c432-4648-bc6b-f7dd3d04e593@github.com>
 <3cFgKe1kh2sMLag9N4n4xEAR2Z9ZyGqc514s4aBbM6Q=.3b0fb8bf-a295-48af-910c-424012dc4307@github.com>
Message-ID: <23mfmnzwJlgwfXwmOSVrtzuU_PXPynI1XCiuNlSwRuE=.86cc6ee5-63a6-4383-932d-aa76513ce57e@github.com>

On Thu, 26 May 2022 07:49:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Even if we remove TitledBorder code from the test and only keep JFrame, then also I see

So it means that the last visible but already disposed frame is sitting in the memory/leaked and this test catch that, isn't it?

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

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


From serb at openjdk.java.net  Thu Jun  2 01:20:32 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Jun 2022 01:20:32 GMT
Subject: RFR: 8285373: Create an automated test for JDK-4702233 [v2]
In-Reply-To: <z0o-FHmf-wr2qSy6UnFl-Ti8k67x5Gyqdz6kvoeJvx4=.5890d850-6b28-4de0-9d4c-eeb22d6744f8@github.com>
References: <zrkWQo-BoTq0XlQX_0_-CwnPIKkCge6wW8E5EqLAYRs=.2345ef0a-25eb-414c-ade6-de10d49d2bbe@github.com>
 <z0o-FHmf-wr2qSy6UnFl-Ti8k67x5Gyqdz6kvoeJvx4=.5890d850-6b28-4de0-9d4c-eeb22d6744f8@github.com>
Message-ID: <5vdop4nnA8Yq5zZCRTBwfleB4Q24R5SOYhVn-EFJwH4=.d63b8ab8-60f1-45bb-9443-062857981350@github.com>

On Fri, 29 Apr 2022 14:11:41 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4702233](https://bugs.openjdk.java.net/browse/JDK-4702233)
>> 
>> Several new AccessibleRole and AccessibleRelation constants are needed in those classes in the java.accessibility package. These new contants codify additions made in the GNOME, Netscape, and UNO (StarOffice) accessibility APIs.
>> StarOffice 6.1 and GNOME accessibility require new role, state and relation
>> constants in the javax.accessibility package. The existing constants are
>> inadequate for providing accessibility to StarOffice and GNOME applications
>> as required by Section 508.
>> 
>> Solution
>> --------
>> Define new constants in the javax.accessibility package.
>> AccessibleRelation
>> AccessibleRoles
>> AccessibleState
>> AccessibleAction
>> AccessibleContext
>> 
>> The test validates the public fields of the above AccessibleConstants.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing CopyRight Header

Marked as reviewed by serb (Reviewer).

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

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


From tr at openjdk.java.net  Thu Jun  2 02:33:19 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Thu, 2 Jun 2022 02:33:19 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF [v2]
In-Reply-To: <3Z0TE9KWfpoFwVC8KCYi9DX7Lef8j-VmW_PB9bUd8Ko=.90847f16-5042-422e-a15d-e492fb3bb3f7@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
 <HGu1Mq4x4nQ7xlW8yB74G4MFGPDuAfpnv8G3B9qdBq0=.81d0bc65-201a-438a-b1a1-0d78336ce287@github.com>
 <OFHuZmUdn9LD5XjN1kH8M5DgQ3TTs5FgX8QDtFo2F1E=.824dd117-3b89-4d6d-8b2f-14b31fe7c340@github.com>
 <3Z0TE9KWfpoFwVC8KCYi9DX7Lef8j-VmW_PB9bUd8Ko=.90847f16-5042-422e-a15d-e492fb3bb3f7@github.com>
Message-ID: <Xm0vZD_b5uLdRp9by2EWRXNQbptCSfoEF0-_0NLU7Po=.07f47e9b-7c7d-4f10-aeb2-824418d3833d@github.com>

On Thu, 2 Jun 2022 00:51:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I think this feature was implemented someday for some L&Fs and then deleted. please double-check the history of releated bugs/files.
> 
> Hmm, I thought this is a produce fix since it has a CSR in the description. The test for metal is fine.

Yeah @mrserb , but I didn't integrate it, I had moved the feature to ToolTipUI, but based on review suggestions, it was decided that the feature better be in metal alone. So just updated the test for metal alone here.

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

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


From psadhukhan at openjdk.java.net  Thu Jun  2 03:43:33 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 2 Jun 2022 03:43:33 GMT
Subject: Integrated: 8213531: Test javax/swing/border/TestTitledBorderLeak.java
 fails
In-Reply-To: <Njia7F66IINfJqmT-OBEOXwoNbmPHh7ZuOHWzq2ZZLE=.228e4222-fbbb-45bc-9f02-cec6edaeb91d@github.com>
References: <Njia7F66IINfJqmT-OBEOXwoNbmPHh7ZuOHWzq2ZZLE=.228e4222-fbbb-45bc-9f02-cec6edaeb91d@github.com>
Message-ID: <zL3JHNPFA_ItekRQGpjr3B8nrBpKI0lfI9P4890Chxs=.91147dad-a812-4926-b948-045e0f689268@github.com>

On Thu, 28 Apr 2022 11:59:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing in linux citing `java.lang.RuntimeException: Expected Total TitledBorder to be freed : 10 Freed 9 `
> As per the fix done in JDK-8204963 http://hg.openjdk.java.net/jdk/jdk/rev/cd7d2f9154fd
> there was no platform specific code done for the fix and logs in `TitledBorder.installPropertyChangeListeners` shows it was called 10 times for the test but `CleanerFactory.cleaner().register` action was only called 9 times in linux causing it to fail.
> 
> Modified the test to not show the frame which cause the problem to go away and also it can still be used as 8204963 regression test as it still fails without the fix and pass with it. Modified test has passed in all platforms for several iterations.
> 
> Also removed the deprecated `System.runFinalization`

This pull request has now been integrated.

Changeset: 07d24509
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/07d24509a68cc06f062b8249f207bc0d2148c79b
Stats:     89 lines in 2 files changed: 16 ins; 61 del; 12 mod

8213531: Test javax/swing/border/TestTitledBorderLeak.java fails

Reviewed-by: prr

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

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


From psadhukhan at openjdk.java.net  Thu Jun  2 03:44:27 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 2 Jun 2022 03:44:27 GMT
Subject: Integrated: 8286846:
 test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on mac
 aarch64
In-Reply-To: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com>
References: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com>
Message-ID: <ucZyN2StuXegzRozeKwt0qkz_90afDwakel03b3HRXs=.1ec73e20-360e-4c51-a9d7-234ec4d938e2@github.com>

On Tue, 24 May 2022 08:28:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing intermiitently in iMac M1 system owing to minimalistic color difference of 1 
> 
> x 13 y 0 refRGB ffeeeeee customRGB ffefeeee
> x 0 y 0 refRGB ffefefef customRGB ffefeeef
> 
> 
> so added color tolerance check. 
> Also, added other stability fixes..
> Several iteration of test passed in intended M1 and x64 system.

This pull request has now been integrated.

Changeset: d7341ae4
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d7341ae42e11fd08508c5f9c67c09c44b62da59b
Stats:     38 lines in 1 file changed: 20 ins; 8 del; 10 mod

8286846: test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on mac aarch64

Reviewed-by: tr, prr, honkar

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

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


From psadhukhan at openjdk.java.net  Thu Jun  2 03:58:46 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 2 Jun 2022 03:58:46 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v6]
In-Reply-To: <J0hcAhJxvJG8B1YWxNKbR7XnilWiHzXdWlCxDywi1aU=.5ef2a55e-1ac5-4b67-b091-d348a61f6c5f@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <bY1l-V3cTfTzvkTbDCmA1BK8yOXm6EmcEvb0mSvAIVc=.7ea0dc3f-c3a5-4071-8830-797b31ba2286@github.com>
 <J0hcAhJxvJG8B1YWxNKbR7XnilWiHzXdWlCxDywi1aU=.5ef2a55e-1ac5-4b67-b091-d348a61f6c5f@github.com>
Message-ID: <dgbWODBHh_ogZ4w1WMqjieu2mStXbu_aLL1SqPB-n90=.8e401989-0bfd-460b-9c57-d48c975332c0@github.com>

On Wed, 1 Jun 2022 20:50:47 GMT, Phil Race <prr at openjdk.org> wrote:

> Also can you attach the source of your test to JBS !

I have attached.

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

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


From psadhukhan at openjdk.java.net  Thu Jun  2 04:23:32 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 2 Jun 2022 04:23:32 GMT
Subject: RFR: 8213531: Test javax/swing/border/TestTitledBorderLeak.java
 fails [v3]
In-Reply-To: <DjbGwJyR1BYwfCO-zgm_P7KC-aC0_o-X5vN4v2tp-Nc=.da494719-d808-4ff9-8bb6-e54db65e2fe7@github.com>
References: <Njia7F66IINfJqmT-OBEOXwoNbmPHh7ZuOHWzq2ZZLE=.228e4222-fbbb-45bc-9f02-cec6edaeb91d@github.com>
 <DjbGwJyR1BYwfCO-zgm_P7KC-aC0_o-X5vN4v2tp-Nc=.da494719-d808-4ff9-8bb6-e54db65e2fe7@github.com>
Message-ID: <hvHKjwQF2yDRNvyAPrBoJHHiBprzX6Sav7kAcObikYo=.438292e9-af1b-4376-85ee-7927af95b33e@github.com>

On Sat, 28 May 2022 08:41:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test was failing in linux citing `java.lang.RuntimeException: Expected Total TitledBorder to be freed : 10 Freed 9 `
>> As per the fix done in JDK-8204963 http://hg.openjdk.java.net/jdk/jdk/rev/cd7d2f9154fd
>> there was no platform specific code done for the fix and logs in `TitledBorder.installPropertyChangeListeners` shows it was called 10 times for the test but `CleanerFactory.cleaner().register` action was only called 9 times in linux causing it to fail.
>> 
>> Modified the test to not show the frame which cause the problem to go away and also it can still be used as 8204963 regression test as it still fails without the fix and pass with it. Modified test has passed in all platforms for several iterations.
>> 
>> Also removed the deprecated `System.runFinalization`
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made test headless

Have raised JDK-8287707 for JFrame leak but it is seem playing around with Thread.sleep, the freed count varies from 7-9 so it can be a test issue too.

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

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


From tr at openjdk.java.net  Thu Jun  2 04:43:31 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Thu, 2 Jun 2022 04:43:31 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF [v3]
In-Reply-To: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
Message-ID: <AypPI9xJrFDbMP-IKhIxx0NrKyZqAFcj8wFtzADKew0=.a585a93b-6a90-4604-bd00-f7e16b4aedb4@github.com>

> The tooltip displays accelerated string along with the toooltip string. The feature is implemented and applicable for Metal Look and Feel only. Hence the test is updated for Metal Look and Feel by hard wiring it in the code. Updated the test from manual to automatic.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8952/files
  - new: https://git.openjdk.java.net/jdk/pull/8952/files/6d147703..8f86a17a

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

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

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


From tr at openjdk.java.net  Thu Jun  2 04:43:34 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Thu, 2 Jun 2022 04:43:34 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF [v2]
In-Reply-To: <K_YsCAXl8Sdm-cX3ibQgOu_ws_TYuitcT72JGnbappU=.213a480f-338f-4254-bd0e-2aa1c0ed1bd2@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
 <HGu1Mq4x4nQ7xlW8yB74G4MFGPDuAfpnv8G3B9qdBq0=.81d0bc65-201a-438a-b1a1-0d78336ce287@github.com>
 <K_YsCAXl8Sdm-cX3ibQgOu_ws_TYuitcT72JGnbappU=.213a480f-338f-4254-bd0e-2aa1c0ed1bd2@github.com>
Message-ID: <YvXZ4KKHEsqCIbOh0rWtaJzNGg9m4mK4mAG0jUplaaI=.a3c5d12b-5b86-48fb-8da8-763bd5e4a961@github.com>

On Thu, 2 Jun 2022 01:02:43 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unused parameter isTooltipAdded
>
> test/jdk/javax/swing/JToolTip/bug5047379.java line 28:
> 
>> 26:    @summary Checks that Tooltips are rendered properly for Metal Look and Feel
>> 27:    @library ../regtesthelpers
>> 28:    @build Util
> 
> @TejeshR13 Can you please crosscheck the regtesthelpers & Util path. I'm unable to run it as jtreg test

One directory up which will land to _swing_ folder, and then to _regtesthelpers_ folder for `Util.java.`. The same path works fine for me.

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

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


From tr at openjdk.java.net  Thu Jun  2 04:43:36 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Thu, 2 Jun 2022 04:43:36 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF [v2]
In-Reply-To: <qRpGrYIx-GH0_5bPk9K6CBpv6w2DA2wFd_8S05a11aM=.61ddc633-e4ba-412f-94d5-afe0625a5e28@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
 <HGu1Mq4x4nQ7xlW8yB74G4MFGPDuAfpnv8G3B9qdBq0=.81d0bc65-201a-438a-b1a1-0d78336ce287@github.com>
 <qRpGrYIx-GH0_5bPk9K6CBpv6w2DA2wFd_8S05a11aM=.61ddc633-e4ba-412f-94d5-afe0625a5e28@github.com>
Message-ID: <MyJTIa_E95ymIyeyZl68IrzEnR4_qZoLbnEoX8XpZys=.888291ac-bb7f-4913-ad3b-6910b3afb5d4@github.com>

On Wed, 1 Jun 2022 17:17:34 GMT, Phil Race <prr at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unused parameter isTooltipAdded
>
> test/jdk/javax/swing/JToolTip/bug5047379.java line 137:
> 
>> 135:         text += "The word \\\"TEXT\\\" and then \\\"CTRL-B\\\"\\n\"\t\t";
>> 136:         text += "\n";
>> 137: 
> 
> "Mouse is hover over button B for the ToolTip to appear." ?
> Harmless to have this message but even though no one will be there to read it (usually)
> it would be nice for it to read properly.
> 
> Please fix before pushing.
> How about "The mouse will hover over button B so the ToolTip will appear." ?

Updated.

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

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


From tr at openjdk.java.net  Thu Jun  2 04:51:36 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Thu, 2 Jun 2022 04:51:36 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v4]
In-Reply-To: <yM3FXEyoJTejhkKUhm1vf79-H9e-tgch259oDLqRaJc=.404d02bf-68d8-4fd5-9861-0f17aac49824@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <BPd77K5HjZdYVu_lGYJFVRT8UHqqGLKdCMl74t0BeGk=.78ead183-e30b-46b7-a5f5-efc3b4cdfd3c@github.com>
 <KLaHd-f0_bx7YZRE4vrRHrdzLwgg61aBpgBu7X4Q06s=.cf65e394-802c-4940-b402-08bb96fa3003@github.com>
 <inqwY6uHTSczUgoVcntLUOStCc8k7IfdP4elYZHXxsA=.7f0ea7ae-71d4-454b-a5f4-46a3c75b25a7@github.com>
 <BFV53rTpa5ga23UuxvzrIDHQl-yDq9AmMa5OVaN3hbI=.21630449-11b3-4101-93b6-d6b8e195f0a9@github.com>
 <yM3FXEyoJTejhkKUhm1vf79-H9e-tgch259oDLqRaJc=.404d02bf-68d8-4fd5-9861-0f17aac49824@github.com>
Message-ID: <gva5QFHDzusgs_YifCNau8KjXZOdh0bPUmRhjF3p2_A=.9ba82f10-8397-4d5a-8d7e-6dc312f17efe@github.com>

On Wed, 1 Jun 2022 18:00:44 GMT, Phil Race <prr at openjdk.org> wrote:

> > > > Shall the test be located in `test/jdk/javax/swing/JRadioButton/4380543/bug4380543.java` instead of `test/jdk/javax/swing/JRadioButton/bug4380543.java` ?
> > > > Usually, there's been a folder with bugid (`/4380543/`) for each test. Do we use the flat layout now?
> > > 
> > > 
> > > @aivanov-jdk Recently we have started to use the latter and remove the extra folder (`/4380543/`)
> > 
> > 
> > Thank you for clarification, Harshitha.
> 
> Yes, blame (?) me :-) We may not always remember to point it out but it is what we want. I've never seen the point in an extra level of folder except when the test is composed of multiple files all unique to the test. I also request that new tests not be given names like bug87654321.java but instead be named in a way that you can tell what they are supposed to be testing like in this case something like RadioButtonMarginTest.java

Sure @prrace , will rename the test. Harshitha also suggested that previously, I thought of retaining for this test.

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

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


From tr at openjdk.java.net  Thu Jun  2 05:02:15 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Thu, 2 Jun 2022 05:02:15 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF [v4]
In-Reply-To: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
Message-ID: <Z00tCs__ecJ0YAeAE-2Pcug1A87A-pZNQuAkDvXIrvs=.7cf56c3a-3a2a-4c8e-9882-aede344dfb06@github.com>

> The tooltip displays accelerated string along with the toooltip string. The feature is implemented and applicable for Metal Look and Feel only. Hence the test is updated for Metal Look and Feel by hard wiring it in the code. Updated the test from manual to automatic.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Test file rename

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8952/files
  - new: https://git.openjdk.java.net/jdk/pull/8952/files/8f86a17a..6af6f31c

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

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

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


From psadhukhan at openjdk.java.net  Thu Jun  2 05:05:25 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 2 Jun 2022 05:05:25 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v4]
In-Reply-To: <gva5QFHDzusgs_YifCNau8KjXZOdh0bPUmRhjF3p2_A=.9ba82f10-8397-4d5a-8d7e-6dc312f17efe@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <BPd77K5HjZdYVu_lGYJFVRT8UHqqGLKdCMl74t0BeGk=.78ead183-e30b-46b7-a5f5-efc3b4cdfd3c@github.com>
 <KLaHd-f0_bx7YZRE4vrRHrdzLwgg61aBpgBu7X4Q06s=.cf65e394-802c-4940-b402-08bb96fa3003@github.com>
 <inqwY6uHTSczUgoVcntLUOStCc8k7IfdP4elYZHXxsA=.7f0ea7ae-71d4-454b-a5f4-46a3c75b25a7@github.com>
 <BFV53rTpa5ga23UuxvzrIDHQl-yDq9AmMa5OVaN3hbI=.21630449-11b3-4101-93b6-d6b8e195f0a9@github.com>
 <yM3FXEyoJTejhkKUhm1vf79-H9e-tgch259oDLqRaJc=.404d02bf-68d8-4fd5-9861-0f17aac49824@github.com>
 <gva5QFHDzusgs_YifCNau8KjXZOdh0bPUmRhjF3p2_A=.9ba82f10-8397-4d5a-8d7e-6dc312f17efe@github.com>
Message-ID: <QMztWQ5aEdimf3ynbsWMAzy2ybbsgCw53Nq7LaMkB_8=.2cf2cf6c-d1dd-480c-8f1e-4187cfc4fa6c@github.com>

On Thu, 2 Jun 2022 04:48:09 GMT, Tejesh R <tr at openjdk.org> wrote:

> > > > > Shall the test be located in `test/jdk/javax/swing/JRadioButton/4380543/bug4380543.java` instead of `test/jdk/javax/swing/JRadioButton/bug4380543.java` ?
> > > > > Usually, there's been a folder with bugid (`/4380543/`) for each test. Do we use the flat layout now?
> > > > 
> > > > 
> > > > @aivanov-jdk Recently we have started to use the latter and remove the extra folder (`/4380543/`)
> > > 
> > > 
> > > Thank you for clarification, Harshitha.
> > 
> > 
> > Yes, blame (?) me :-) We may not always remember to point it out but it is what we want. I've never seen the point in an extra level of folder except when the test is composed of multiple files all unique to the test. I also request that new tests not be given names like bug87654321.java but instead be named in a way that you can tell what they are supposed to be testing like in this case something like RadioButtonMarginTest.java
> 
> Sure @prrace , will rename the test. Harshitha also suggested that previously, I thought of retaining for this test.

But it's not a new test. I guess you are moving it from closed to open, right? 
and recent PRs prefer keeping the same name to view the history of the test..
I dont object to it but we should be consistent..

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

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


From tr at openjdk.java.net  Thu Jun  2 05:29:32 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Thu, 2 Jun 2022 05:29:32 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v3]
In-Reply-To: <EJVvh3aTA5gUF3tFwuYT6o6ngxwMoYbbgkHrwWQOgFc=.cc6e06a4-f840-4267-8791-1be4aa7ea6fa@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <1-qMJRwjJVXF7BSrl5NCpoR9KMRBirtjJY--Kr6JueU=.e4a087a3-a7bb-4a93-a6ad-4a26954de78e@github.com>
 <DpvmclypIcCDXli-qMUwP9HpCimQ8JoEbEJXs6d-Nv4=.0c99e50c-3c26-492a-95cc-aa9b5302e861@github.com>
 <OgNizPtHLfftJ4PQtfTabyjvKu5p2-hKaO9SDIwOQpg=.af5401da-1c2d-4112-b114-c42a5a7d9007@github.com>
 <bawffD0qA8VOw8J0YI7r7NmggrjgCi22GC8cGWwaM00=.7bd09b07-c3e8-4768-8bd7-e97f274e5563@github.com>
 <EJVvh3aTA5gUF3tFwuYT6o6ngxwMoYbbgkHrwWQOgFc=.cc6e06a4-f840-4267-8791-1be4aa7ea6fa@github.com>
Message-ID: <uh_IJbsCLtsun-H_9PHCMKXQe9LCtKEEmJuJ9o6ewZA=.48a008b1-f9f3-4bdc-a7ba-4e987a34c108@github.com>

On Wed, 1 Jun 2022 17:09:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > > I wonder why the test is Windows-specific if it allows changing Look and Feels.
> > > > The only Look and Feel which ignores the background is Nimbus, other L&Fs on Windows at least paint the yellow and green background. As such, the test can be run on other platforms.
> > > > Was the original bug in Windows Look and Feel? If so, you may want to make it the default L&F.
> > > > The instructions don't mention anything about other Look and Feels. Does the tester have to verify each presented L&F?
> > > 
> > > 
> > > I think the test was in windows which I might have retained the os type, will check and confirm once. The tester have to verify with each L&F for left margin check.
> > 
> > 
> > Yeah, it was only for Motif and Windows before, so I have retained it for only windows os.
> 
> I can see no reason why the test is for Windows only.
> 
> The original bug [JDK-4380543](https://bugs.openjdk.java.net/browse/JDK-4380543) lists all the operating systems as affected. Then [JDK-8134640](https://bugs.openjdk.java.net/browse/JDK-8134640) asked to support all Look-and-Feels, which somewhat implies other platforms should also be tested.

Ok. Since this PR is about the movement of test from closed to open, I would like to retain it for Windows alone @aivanov-jdk as the bug fix [JDK-8134640](https://bugs.openjdk.java.net/browse/JDK-8134640) has been taken care for windows. Will surely plan for other L&F in sometime.

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

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


From tr at openjdk.java.net  Thu Jun  2 06:03:16 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Thu, 2 Jun 2022 06:03:16 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF [v5]
In-Reply-To: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
Message-ID: <fPBcPnqtKUfav_dSeZ2SpHIXghuYH74czgeEZRCAeZY=.39a68bbd-40ee-45db-9c20-17960f177197@github.com>

> The tooltip displays accelerated string along with the toooltip string. The feature is implemented and applicable for Metal Look and Feel only. Hence the test is updated for Metal Look and Feel by hard wiring it in the code. Updated the test from manual to automatic.

Tejesh R 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:

  Unused imports removed

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8952/files
  - new: https://git.openjdk.java.net/jdk/pull/8952/files/6af6f31c..6e914c30

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

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

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


From aivanov at openjdk.java.net  Thu Jun  2 07:50:26 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 2 Jun 2022 07:50:26 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v4]
In-Reply-To: <yM3FXEyoJTejhkKUhm1vf79-H9e-tgch259oDLqRaJc=.404d02bf-68d8-4fd5-9861-0f17aac49824@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <BPd77K5HjZdYVu_lGYJFVRT8UHqqGLKdCMl74t0BeGk=.78ead183-e30b-46b7-a5f5-efc3b4cdfd3c@github.com>
 <KLaHd-f0_bx7YZRE4vrRHrdzLwgg61aBpgBu7X4Q06s=.cf65e394-802c-4940-b402-08bb96fa3003@github.com>
 <inqwY6uHTSczUgoVcntLUOStCc8k7IfdP4elYZHXxsA=.7f0ea7ae-71d4-454b-a5f4-46a3c75b25a7@github.com>
 <BFV53rTpa5ga23UuxvzrIDHQl-yDq9AmMa5OVaN3hbI=.21630449-11b3-4101-93b6-d6b8e195f0a9@github.com>
 <yM3FXEyoJTejhkKUhm1vf79-H9e-tgch259oDLqRaJc=.404d02bf-68d8-4fd5-9861-0f17aac49824@github.com>
Message-ID: <Ta_1w8Rxf9uLEhqusUn65TuxZjfgdo5gtlLgzOi92JA=.369b1e7b-0099-4644-b048-e828c0d5497c@github.com>

On Wed, 1 Jun 2022 18:00:44 GMT, Phil Race <prr at openjdk.org> wrote:

>>> > Shall the test be located in `test/jdk/javax/swing/JRadioButton/4380543/bug4380543.java` instead of `test/jdk/javax/swing/JRadioButton/bug4380543.java` ?
>>> > Usually, there's been a folder with bugid (`/4380543/`) for each test. Do we use the flat layout now?
>>> 
>>> @aivanov-jdk Recently we have started to use the latter and remove the extra folder (`/4380543/`)
>> 
>> Thank you for clarification, Harshitha.
>
>> > > Shall the test be located in `test/jdk/javax/swing/JRadioButton/4380543/bug4380543.java` instead of `test/jdk/javax/swing/JRadioButton/bug4380543.java` ?
>> > > Usually, there's been a folder with bugid (`/4380543/`) for each test. Do we use the flat layout now?
>> > 
>> > 
>> > @aivanov-jdk Recently we have started to use the latter and remove the extra folder (`/4380543/`)
>> 
>> Thank you for clarification, Harshitha.
> 
> Yes, blame (?) me :-) 
> We may not always remember to point it out but it is what we want.
> I've never seen the point in an extra level of folder except when the test is composed of multiple files all unique to the test.
> I also request that new tests not be given names like bug87654321.java but instead be named in a way that you can tell what they are supposed to be testing like in this case something like RadioButtonMarginTest.java

> > Sure @prrace , will rename the test. Harshitha also suggested that previously, I thought of retaining for this test.
> 
> But it's not a new test. I guess you are moving it from closed to open, right? and recent PRs prefer keeping the same name to view the history of the test.. I dont object to it but we should be consistent..

I agree. Although I can't find many references to it in JBS, keeping the current name seems to be a better option than renaming. On the other hand, it's a manual test so it doesn't have the history in the automated test runs.

I'm for keeping the current test name.

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

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


From aivanov at openjdk.java.net  Thu Jun  2 07:54:24 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 2 Jun 2022 07:54:24 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v3]
In-Reply-To: <uh_IJbsCLtsun-H_9PHCMKXQe9LCtKEEmJuJ9o6ewZA=.48a008b1-f9f3-4bdc-a7ba-4e987a34c108@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <1-qMJRwjJVXF7BSrl5NCpoR9KMRBirtjJY--Kr6JueU=.e4a087a3-a7bb-4a93-a6ad-4a26954de78e@github.com>
 <DpvmclypIcCDXli-qMUwP9HpCimQ8JoEbEJXs6d-Nv4=.0c99e50c-3c26-492a-95cc-aa9b5302e861@github.com>
 <OgNizPtHLfftJ4PQtfTabyjvKu5p2-hKaO9SDIwOQpg=.af5401da-1c2d-4112-b114-c42a5a7d9007@github.com>
 <bawffD0qA8VOw8J0YI7r7NmggrjgCi22GC8cGWwaM00=.7bd09b07-c3e8-4768-8bd7-e97f274e5563@github.com>
 <EJVvh3aTA5gUF3tFwuYT6o6ngxwMoYbbgkHrwWQOgFc=.cc6e06a4-f840-4267-8791-1be4aa7ea6fa@github.com>
 <uh_IJbsCLtsun-H_9PHCMKXQe9LCtKEEmJuJ9o6ewZA=.48a008b1-f9f3-4bdc-a7ba-4e987a34c108@github.com>
Message-ID: <vCWsJ3850UniF5tUXXl1I1uX8uEGsluaJIks3pROF2k=.a4773cb0-8159-4d4c-ae4c-3254c53a53b5@github.com>

On Thu, 2 Jun 2022 05:25:54 GMT, Tejesh R <tr at openjdk.org> wrote:

> > I can see no reason why the test is for Windows only.
> >
> > The original bug [JDK-4380543](https://bugs.openjdk.java.net/browse/JDK-4380543) lists all the operating systems as affected. Then [JDK-8134640](https://bugs.openjdk.java.net/browse/JDK-8134640) asked to support all Look-and-Feels, which somewhat implies other platforms should also be tested.
> 
> Ok. Since this PR is about the movement of test from closed to open, I would like to retain it for Windows alone @aivanov-jdk as the bug fix [JDK-8134640](https://bugs.openjdk.java.net/browse/JDK-8134640) has been taken care for windows. Will surely plan for other L&F in sometime.

Why can't we make it run on other platforms here?

All it takes is removing `@requires (os.family == "windows")`. Well, obviously, you have to run it on macOS and Linux to make sure it works as expected.

I think doing it right now is more than reasonable compared to submitting a new issue just to remove the OS restriction and going through the code review.

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

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


From mvs at openjdk.java.net  Thu Jun  2 08:14:23 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 2 Jun 2022 08:14:23 GMT
Subject: RFR: 8286822: Write a test to check the DND functionality between
 two InternalFrames [v2]
In-Reply-To: <cX5w-Rq6SET6AM8VbW_1bCOUgZ3dyXKayoIhaK-Gm8k=.9fb40e39-0b93-4118-b52e-c04305e3811b@github.com>
References: <cX5w-Rq6SET6AM8VbW_1bCOUgZ3dyXKayoIhaK-Gm8k=.9fb40e39-0b93-4118-b52e-c04305e3811b@github.com>
Message-ID: <thGtniWtm9mKXwzfB5DnnFEs_pyl2yBiCSag5tdz2XU=.5f4bd190-b333-4319-b614-8664634ad45d@github.com>

> This test verifies that dragging from one InternalFrame and a drop target in another InternalFrame functions properly.
> This fix moves an unstable closed applet based test to open regression based java test, but updated to be more comprehensive with some stabilisation improvements. The closed test was creating noise in CI as it often fails in Windows platform, especially in Windows 11.
> 
> Testing:
> 1. Tested using mach5 20 times per platform and got all Pass.
> 2. Tested using mach5 5 times specifically on Windows 11 and got all Pass.

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Following the process to convert a closed test to open, created a PR in closed space and got it reviewed, now updating this open PR

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8753/files
  - new: https://git.openjdk.java.net/jdk/pull/8753/files/7d00c305..aeb3edb1

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

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

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


From mvs at openjdk.java.net  Thu Jun  2 08:14:23 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 2 Jun 2022 08:14:23 GMT
Subject: RFR: 8286822: Write a test to check the DND functionality between
 two InternalFrames [v2]
In-Reply-To: <98d4QKHKLIaozF4R_bRk78e-ibxr7_ot6NBPbnqEw8U=.e4290fae-2a18-41cb-824c-a61541c4b27a@github.com>
References: <cX5w-Rq6SET6AM8VbW_1bCOUgZ3dyXKayoIhaK-Gm8k=.9fb40e39-0b93-4118-b52e-c04305e3811b@github.com>
 <98d4QKHKLIaozF4R_bRk78e-ibxr7_ot6NBPbnqEw8U=.e4290fae-2a18-41cb-824c-a61541c4b27a@github.com>
Message-ID: <c81DXxFMAMnH8AbV71uz0knL5EOvtT3ALWFzn0LmUdw=.6b091bda-125a-4cf9-8a44-7c9bb1cd5fc4@github.com>

On Fri, 20 May 2022 07:51:28 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Following the process to convert a closed test to open, created a PR in closed space and got it reviewed, now updating this open PR
>
> test/jdk/java/awt/dnd/DropTargetInInternalFrameTest.java line 244:
> 
>> 242:         private final Dimension preferredDimension = new Dimension(200, 100);
>> 243:         private final CountDownLatch dropLatch;
>> 244:         private volatile int calledMethods = 0;
> 
> Any reason for changing calledMethods to volatile?

In order to get the updated data all the time, as this variable will be updated from EDT and the value will be read from main thread also.

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

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


From aivanov at openjdk.java.net  Thu Jun  2 08:10:35 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 2 Jun 2022 08:10:35 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v3]
In-Reply-To: <vCWsJ3850UniF5tUXXl1I1uX8uEGsluaJIks3pROF2k=.a4773cb0-8159-4d4c-ae4c-3254c53a53b5@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <1-qMJRwjJVXF7BSrl5NCpoR9KMRBirtjJY--Kr6JueU=.e4a087a3-a7bb-4a93-a6ad-4a26954de78e@github.com>
 <DpvmclypIcCDXli-qMUwP9HpCimQ8JoEbEJXs6d-Nv4=.0c99e50c-3c26-492a-95cc-aa9b5302e861@github.com>
 <OgNizPtHLfftJ4PQtfTabyjvKu5p2-hKaO9SDIwOQpg=.af5401da-1c2d-4112-b114-c42a5a7d9007@github.com>
 <bawffD0qA8VOw8J0YI7r7NmggrjgCi22GC8cGWwaM00=.7bd09b07-c3e8-4768-8bd7-e97f274e5563@github.com>
 <EJVvh3aTA5gUF3tFwuYT6o6ngxwMoYbbgkHrwWQOgFc=.cc6e06a4-f840-4267-8791-1be4aa7ea6fa@github.com>
 <uh_IJbsCLtsun-H_9PHCMKXQe9LCtKEEmJuJ9o6ewZA=.48a008b1-f9f3-4bdc-a7ba-4e987a34c108@github.com>
 <vCWsJ3850UniF5tUXXl1I1uX8uEGsluaJIks3pROF2k=.a4773cb0-8159-4d4c-ae4c-3254c53a53b5@github.com>
Message-ID: <VGoKwe49y9AtpfVrNMPQyk5lC-mhMRxpXo4NB3Tkyj0=.5084e1ca-5a03-4af2-961f-bc58275be738@github.com>

On Thu, 2 Jun 2022 07:51:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> > > > I wonder why the test is Windows-specific if it allows changing Look and Feels.
>>> > > > The only Look and Feel which ignores the background is Nimbus, other L&Fs on Windows at least paint the yellow and green background. As such, the test can be run on other platforms.
>>> > > > Was the original bug in Windows Look and Feel? If so, you may want to make it the default L&F.
>>> > > > The instructions don't mention anything about other Look and Feels. Does the tester have to verify each presented L&F?
>>> > > 
>>> > > 
>>> > > I think the test was in windows which I might have retained the os type, will check and confirm once. The tester have to verify with each L&F for left margin check.
>>> > 
>>> > 
>>> > Yeah, it was only for Motif and Windows before, so I have retained it for only windows os.
>>> 
>>> I can see no reason why the test is for Windows only.
>>> 
>>> The original bug [JDK-4380543](https://bugs.openjdk.java.net/browse/JDK-4380543) lists all the operating systems as affected. Then [JDK-8134640](https://bugs.openjdk.java.net/browse/JDK-8134640) asked to support all Look-and-Feels, which somewhat implies other platforms should also be tested.
>> 
>> Ok. Since this PR is about the movement of test from closed to open, I would like to retain it for Windows alone @aivanov-jdk as the bug fix [JDK-8134640](https://bugs.openjdk.java.net/browse/JDK-8134640) has been taken care for windows. Will surely plan for other L&F in sometime.
>
>> > I can see no reason why the test is for Windows only.
>> >
>> > The original bug [JDK-4380543](https://bugs.openjdk.java.net/browse/JDK-4380543) lists all the operating systems as affected. Then [JDK-8134640](https://bugs.openjdk.java.net/browse/JDK-8134640) asked to support all Look-and-Feels, which somewhat implies other platforms should also be tested.
>> 
>> Ok. Since this PR is about the movement of test from closed to open, I would like to retain it for Windows alone @aivanov-jdk as the bug fix [JDK-8134640](https://bugs.openjdk.java.net/browse/JDK-8134640) has been taken care for windows. Will surely plan for other L&F in sometime.
> 
> Why can't we make it run on other platforms here?
> 
> All it takes is removing `@requires (os.family == "windows")`. Well, obviously, you have to run it on macOS and Linux to make sure it works as expected.
> 
> I think doing it right now is more than reasonable compared to submitting a new issue just to remove the OS restriction and going through the code review.

> > > @aivanov-jdk Recently we have started to use the latter and remove the extra folder (`/4380543/`)
> > 
> > Thank you for clarification, Harshitha.
> 
> Yes, blame (?) me :-)
> We may not always remember to point it out but it is what we want.

I see. I noticed it in recent code reviews, so I wanted to clarify.

> I've never seen the point in an extra level of folder except when the test is composed of multiple files all unique to the test.

I agree to some extent? When using an IDE to compile and run a test, a separate folder is quite convenient: add it as test source, and you're done. When there are many tests in one folder, it could result in compilation errors. Some tests declare the same class names, a number of manual tests have `Sysout` class, and thus it causes duplicate class names, which makes it impossible to run a test right from IDE unless you take additional steps to resolve or prevent compilation errors.

On the other hand, the shorter filesystem tree is easier to navigate. As such, flatter structure is the way to go.

> I also request that new tests not be given names like bug87654321.java but instead be named in a way that you can tell what they are supposed to be testing like in this case something like RadioButtonMarginTest.java

Descriptive names are easier to remember and to refer to, they give you an idea of what test does when you see a failure. With a bugid, you have to open the test source or the bug in JBS for getting that info.

I fully support meaningful, descriptive names for new tests.

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

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


From aivanov at openjdk.java.net  Thu Jun  2 08:21:19 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 2 Jun 2022 08:21:19 GMT
Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray
 [v3]
In-Reply-To: <1zmgKAKgBzh5-I4aGlM0Egx64C-Fv3r2Yhl5R0Mu5ho=.c67c08aa-8d49-4550-9e07-505a93be3840@github.com>
References: <KbpNZ7Yzxx6cUu_DQI5QawOSz2BfkC02EgzR28gUiyU=.3c2abcd2-54ba-4eea-803d-d04a611df9ed@github.com>
 <lDGxeWeYDdowZ7jpQTrawRBVrMwkgQ0edJAiagSi5Ic=.0951f5d8-20ec-464a-b088-a65ce68fd4f4@github.com>
 <Xd4CzrPr1AsWVUqE8H1sQh7rhDxwNpzONJmU6GC2GXo=.f5ad4c02-8ba8-40e4-8747-61d4cf265ec0@github.com>
 <HwzaK7Njmx3c0YvB_1bSh0LyGO9Baxb_STHAkjlJRz4=.6a15c920-5c57-4eab-ac55-81210acfbc68@github.com>
 <qtbLqKoaHcQ3GJVFSyXoNl_gH3MQNjs108Q0sMKA7-8=.8f17c05e-7b73-4ccd-90c6-1baa6808107a@github.com>
 <pwZkx94UwE7kuUEwsqyQCaCs_ZbxkWima6yMJ1xZCPs=.8efccb89-50bb-48a9-aa82-cee4d744e78d@github.com>
 <Uhg45FWYFo_B7Sq6foqI5-9XB3rGcT6TjdFrCoJqRSI=.d3db6fb8-0a13-4c16-abbc-382561b49c66@github.com>
 <bMMLXijtdz77iocU87ImhIIMy1DYacYxvZ_rgAPkcSM=.6f9a8003-b6b7-433a-aa02-90cd27257957@github.com>
 <qthngcip1goWBnZ3wuFo_a0V3tgDdd3nTJ4UKR8BbTo=.b703ffc6-7609-42fa-8ea9-cf0e39727a24@github.com>
 <aqs63xmcMgf9j6Xeni7pnO92ylQb-NijP8rXZmSxhJc=.a177c6f2-8cf4-4508-a654-514ced365158@github.com>
 <MKq3xRtF0NXWZaxuVAkzcl62g36EKKIdwO3
 Fr5DDids=.fb2869d4-960f-4130-91a6-652792612791@github.com>
 <X9rNJalr7kqhZepLcDju-cOyEvRsZmZjblcJyHpT6LM=.e0f90c83-ca18-42f1-9568-b1a403c289d3@github.com>
 <1zmgKAKgBzh5-I4aGlM0Egx64C-Fv3r2Yhl5R0Mu5ho=.c67c08aa-8d49-4550-9e07-505a93be3840@github.com>
Message-ID: <sfFWg8ct9AB9VriUa7nhTsaUF3qtgsftNSGReHXzfb8=.817b4ec7-27c7-48ce-aada-bddf11cb7d8a@github.com>

On Thu, 2 Jun 2022 00:36:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> BTW I think that the usage of
> `return icons.toArray(EMPTY_TRAY_ARRAY);`
> is slower than any of other cases: presized or zero. So if we would like to use a similar pattern the zero version is better.

Why is it? It's the same as `icons.toArray(new TrayIcon[0])` without creating a new zero-sized array.

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

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


From mvs at openjdk.java.net  Thu Jun  2 08:33:21 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Thu, 2 Jun 2022 08:33:21 GMT
Subject: RFR: 8286772:
 java/awt/dnd/DropTargetInInternalFrameTest/DropTargetInInternalFrameTest.html
 times out and fails in Windows
In-Reply-To: <PGMTWR0G_tLjvfH_XCuaDSD9P-M2DVfaS4zc5qf7vfo=.23b9d4bb-0a75-4891-8264-02b8edbd2030@github.com>
References: <cX5w-Rq6SET6AM8VbW_1bCOUgZ3dyXKayoIhaK-Gm8k=.9fb40e39-0b93-4118-b52e-c04305e3811b@github.com>
 <f3uVusmbF5zu0-7kxcdaTKJvcN6gVR5dxUZGXcL24-g=.fa62f699-3ede-464e-ab83-162ac8fab492@github.com>
 <g9PvPJ8hQpb0z6qixQBQANpRaahUbRRqNHyk6AQYJM0=.ca7eb193-3f84-45d6-a3ea-6d4a861dec02@github.com>
 <PGMTWR0G_tLjvfH_XCuaDSD9P-M2DVfaS4zc5qf7vfo=.23b9d4bb-0a75-4891-8264-02b8edbd2030@github.com>
Message-ID: <YsAryO6KlsaGU4D-u-29IKVJDWcnYvhCRPNm0UYh8r4=.e564ae12-913d-4c44-8c56-40376f99f2ae@github.com>

On Thu, 19 May 2022 16:15:05 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> > > I dont see an internal PR to remove the applet based closed test. Also why https://bugs.openjdk.java.net/browse/JDK-8286822 is created as enhancement ?
> > > If this test is failing intermittently how many times we have seen this test fail? Like out of 20 times how many times it will fail on Windows 11? This will help us understand how many times we need to test updated test.
> > 
> > 
> > I will create an Internal PR to remove the closed test after this PR is integrated(for now I have created a closed bug to track this JDK-8286772). This test is added as a new test in open space, that's why JDK-8286822 was created as an enhancement. This test was failing 1/20 times in Windows 10, but it was failing almost 100% on Windows 11 before the fix. I have attached the failed mach5 runs also in the bug as a confidential comment.
> 
> We dont create 2 separate JBS ID's for opening up closed test case. Opening up of test case and deleting closed test case should be handled in single JBS bug ID. Opening up a regression test case should not be handled as enhancement. We add so many of these regression tests as part of normal bugs along with product change.

I have corrected this, now handling everything in a single bug [JDK-8286772](https://bugs.openjdk.java.net/browse/JDK-8286772).

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

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


From tr at openjdk.java.net  Thu Jun  2 09:14:30 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Thu, 2 Jun 2022 09:14:30 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v4]
In-Reply-To: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
Message-ID: <Aamzvc-xdKCForWoGV_E4xtJR5Ds87g4DrK2xgbLiEE=.17a30df7-9355-4ba6-8999-f18c38a72bea@github.com>

> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.

Tejesh R 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 14 additional commits since the last revision:

 - Updated based on review comments
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_6429812
 - JTREG Tags updation
 - Removal of White space
 - Updated based on review comments and Added Test case TableRenderTest.java
 - header object set
 - Merge remote-tracking branch 'upstream/master' into branch_6429812
 - Merge remote-tracking branch 'upstream/master'
 - Merge branch 'master' of github.com:TejeshR13/jdk
 - Merge branch 'openjdk:master' into master
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/a89bbd0c...98c2aab2

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8830/files
  - new: https://git.openjdk.java.net/jdk/pull/8830/files/f7b44322..98c2aab2

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

  Stats: 104546 lines in 1509 files changed: 41748 ins; 52654 del; 10144 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8830.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8830/head:pull/8830

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


From tr at openjdk.java.net  Thu Jun  2 09:41:36 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Thu, 2 Jun 2022 09:41:36 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v5]
In-Reply-To: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
Message-ID: <7Uq-_ddkYEjUIh6J-HSTdwLg9ghrbPEHtgDVHaK3ArM=.a0535b58-02df-4ee8-97ea-755e66e530e3@github.com>

> Added test for checking setMargin() of JRadioButton.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Removed windows specific jtreg

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8721/files
  - new: https://git.openjdk.java.net/jdk/pull/8721/files/5d4adb7f..43cbe746

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

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

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


From tr at openjdk.java.net  Thu Jun  2 09:41:37 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Thu, 2 Jun 2022 09:41:37 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v3]
In-Reply-To: <vCWsJ3850UniF5tUXXl1I1uX8uEGsluaJIks3pROF2k=.a4773cb0-8159-4d4c-ae4c-3254c53a53b5@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <1-qMJRwjJVXF7BSrl5NCpoR9KMRBirtjJY--Kr6JueU=.e4a087a3-a7bb-4a93-a6ad-4a26954de78e@github.com>
 <DpvmclypIcCDXli-qMUwP9HpCimQ8JoEbEJXs6d-Nv4=.0c99e50c-3c26-492a-95cc-aa9b5302e861@github.com>
 <OgNizPtHLfftJ4PQtfTabyjvKu5p2-hKaO9SDIwOQpg=.af5401da-1c2d-4112-b114-c42a5a7d9007@github.com>
 <bawffD0qA8VOw8J0YI7r7NmggrjgCi22GC8cGWwaM00=.7bd09b07-c3e8-4768-8bd7-e97f274e5563@github.com>
 <EJVvh3aTA5gUF3tFwuYT6o6ngxwMoYbbgkHrwWQOgFc=.cc6e06a4-f840-4267-8791-1be4aa7ea6fa@github.com>
 <uh_IJbsCLtsun-H_9PHCMKXQe9LCtKEEmJuJ9o6ewZA=.48a008b1-f9f3-4bdc-a7ba-4e987a34c108@github.com>
 <vCWsJ3850UniF5tUXXl1I1uX8uEGsluaJIks3pROF2k=.a4773cb0-8159-4d4c-ae4c-3254c53a53b5@github.com>
Message-ID: <L4E8RuU864hXgXvsCfXip_M7NSYWXvIDfma5WJNuG3Y=.9a0091a8-f219-4cfd-956d-2a7d9c6681e8@github.com>

On Thu, 2 Jun 2022 07:51:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > I can see no reason why the test is for Windows only.
> > > The original bug [JDK-4380543](https://bugs.openjdk.java.net/browse/JDK-4380543) lists all the operating systems as affected. Then [JDK-8134640](https://bugs.openjdk.java.net/browse/JDK-8134640) asked to support all Look-and-Feels, which somewhat implies other platforms should also be tested.
> > 
> > 
> > Ok. Since this PR is about the movement of test from closed to open, I would like to retain it for Windows alone @aivanov-jdk as the bug fix [JDK-8134640](https://bugs.openjdk.java.net/browse/JDK-8134640) has been taken care for windows. Will surely plan for other L&F in sometime.
> 
> Why can't we make it run on other platforms here?
> 
> All it takes is removing `@requires (os.family == "windows")`. Well, obviously, you have to run it on macOS and Linux to make sure it works as expected.
> 
> I think doing it right now is more than reasonable compared to submitting a new issue just to remove the OS restriction and going through the code review.

Sorry, had really misunderstood what you had meant, removing os specific is a great idea. Thank you @aivanov-jdk .

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

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


From avu at openjdk.java.net  Thu Jun  2 09:53:26 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Thu, 2 Jun 2022 09:53:26 GMT
Subject: RFR: 8287453: RenderPerfTest incorrectly measures performance
In-Reply-To: <UTQ7d9Mf-RMFCxEhetM-_Xh4lYTzpP-m32cdXTewWjw=.0ed36191-9a95-477a-afe3-6aaf364e0fd3@github.com>
References: <EcLzMlD3pS991VN6A0XLff6wNdifZUPFDBovCl_33Fc=.db2d3f25-c79e-46e3-9a6d-a5822ae2ab07@github.com>
 <LRHwSv2Leb1k8KDxBNObYmgzOy5Mk6Zv77CquWP10vY=.8805ba75-dc9f-41d0-bbf8-940070260d71@github.com>
 <wEJU4wOns8RLkOUhbVKhGkJYXhSOGzj5XVmfHU7m-w4=.8256294e-2fb9-4636-901a-3e026759288e@github.com>
 <oHuv5uRwCtGgS09wLPM_GCB9X0LssBmtdGitzb9lK7c=.123eab42-1b10-4098-9b35-a45d4df297dd@github.com>
 <UTQ7d9Mf-RMFCxEhetM-_Xh4lYTzpP-m32cdXTewWjw=.0ed36191-9a95-477a-afe3-6aaf364e0fd3@github.com>
Message-ID: <Ke3VfrYzYcz4X1bBQe-_Js0yt9oOMZKeEcsdD07hAys=.ecbe2201-5f78-4f49-8475-efb48af08494@github.com>

On Wed, 1 Jun 2022 09:45:32 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Another bug needs to be filed for tests having lower performance with the Metal pipeline as compared to OpenGL pipeline.

I've filed [JDK-8287694](https://bugs.openjdk.java.net/browse/JDK-8287694)

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

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


From tr at openjdk.java.net  Thu Jun  2 12:25:18 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Thu, 2 Jun 2022 12:25:18 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v5]
In-Reply-To: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
Message-ID: <nphz1L3zr5ekPo2eFwmUHFX4pqFJCXxBMhafQFBbaZM=.169d1930-586d-4064-a5bb-fa2439ae1d50@github.com>

> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Changed from manual to Automatic Test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8830/files
  - new: https://git.openjdk.java.net/jdk/pull/8830/files/98c2aab2..1ac4d7b5

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

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

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


From tr at openjdk.java.net  Thu Jun  2 13:06:36 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Thu, 2 Jun 2022 13:06:36 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v6]
In-Reply-To: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
Message-ID: <DD3NzuVtRnf8sSbitIRSa7VOwY_OS5MadXRT_qDJZd0=.45fd3abd-372a-4b7a-9019-7c1e97b8c46d@github.com>

> Added test for checking setMargin() of JRadioButton.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8721/files
  - new: https://git.openjdk.java.net/jdk/pull/8721/files/43cbe746..97aaa1b2

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

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

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


From psadhukhan at openjdk.java.net  Thu Jun  2 13:27:26 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 2 Jun 2022 13:27:26 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v6]
In-Reply-To: <J0hcAhJxvJG8B1YWxNKbR7XnilWiHzXdWlCxDywi1aU=.5ef2a55e-1ac5-4b67-b091-d348a61f6c5f@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <bY1l-V3cTfTzvkTbDCmA1BK8yOXm6EmcEvb0mSvAIVc=.7ea0dc3f-c3a5-4071-8830-797b31ba2286@github.com>
 <J0hcAhJxvJG8B1YWxNKbR7XnilWiHzXdWlCxDywi1aU=.5ef2a55e-1ac5-4b67-b091-d348a61f6c5f@github.com>
Message-ID: <QMFGmxw9-_yA4NAnPuyOfbYoxWgbZMqx1hsxVNxPUPM=.c3180d55-6812-4482-824a-0eb253a0252d@github.com>

On Wed, 1 Jun 2022 20:50:47 GMT, Phil Race <prr at openjdk.org> wrote:

> Malgun is now not appearing in the font menu of Font2DTest when I use ko + UTF-8 !?
> It appears if I use -Dfile.encoding=ko instead

Are you implying it used to appear earlier? with what configuration or patch?
It is same for me but I haven't run Font2DTest earlier with this patch so could not say if it used to work without file.encoding=ko. 
It seems to not appear even with -Duser.language=ko -Duser.country=KR -Dfile.encoding=ko. I also tried adding "ko" to 8285308  fix but to no avail.

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

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


From kizune at openjdk.java.net  Thu Jun  2 14:10:36 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 2 Jun 2022 14:10:36 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <pUMmlnzsQYsXWupnuut2VWEs2pHDHZdpqas9MngxlQY=.b6ede20b-e114-426e-94f7-8853c215c249@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
 <8vrDNTJTPocLihty5ZMoBaqGEX23B4gXxis8TtBvuZ8=.5700255b-33a0-4b17-bbb2-523f5a19e9c8@github.com>
 <pUMmlnzsQYsXWupnuut2VWEs2pHDHZdpqas9MngxlQY=.b6ede20b-e114-426e-94f7-8853c215c249@github.com>
Message-ID: <eVISQfZrqHrS2l3skGYunPYJeSwk2PcpQCwaQ5VPXgI=.7738456a-70ca-42d6-8c56-587bc664c68c@github.com>

On Thu, 2 Jun 2022 00:08:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Time: 21313400
> Time: 4036200
> Time: 1140613100
> Time: 839499200

These are some extreme numbers, on my system it is more like 8 to 10 times slower depending on the run:
Time: 13250900
Time: 10126200
Time: 113548000
Time: 113630100

But still - the question is: how big the difference will be in the real application, knowing that we only apply this hint to a small minority of the cases and difference for single repaint (which is cached and not like we re-draw it continuously) so can we neglect the performance variation to achieve better visual result? I think the answer is yes, we are trying to mimic the system behavior and on modern systems the icons in native applications do look much better then what we produce.

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

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


From aghaisas at openjdk.java.net  Thu Jun  2 14:23:27 2022
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 2 Jun 2022 14:23:27 GMT
Subject: RFR: 8287600: AA Ovals not rendered under metal
In-Reply-To: <XZl-tJGUpOqvDVtGhsG3k0sogD0IwWwjKFkfXuMgKIQ=.0aa9c8c2-3915-4b0b-8949-cb31f0affdf2@github.com>
References: <XZl-tJGUpOqvDVtGhsG3k0sogD0IwWwjKFkfXuMgKIQ=.0aa9c8c2-3915-4b0b-8949-cb31f0affdf2@github.com>
Message-ID: <x-PAhE3Fe_RjJlb9Z1ujPIIzKccdwifF7nuaw-qbDnk=.7a9dba2a-27c6-4d19-84fd-6c02b09be8a3@github.com>

On Wed, 1 Jun 2022 20:21:40 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Commit command buffer after MTL_OP_MASK_OP operation

All test run is fine with this change.

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

Marked as reviewed by aghaisas (Committer).

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


From tr at openjdk.java.net  Thu Jun  2 15:32:11 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Thu, 2 Jun 2022 15:32:11 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v7]
In-Reply-To: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
Message-ID: <5X_sWM6JdbzBhbh1jHzg-03IgrQ6_A3VpudPIPdmW28=.dca81bba-fa38-4e30-bd07-860ef793155c@github.com>

> Added test for checking setMargin() of JRadioButton.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Removed whitespaces

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8721/files
  - new: https://git.openjdk.java.net/jdk/pull/8721/files/97aaa1b2..79dd0e14

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8721&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8721&range=05-06

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

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


From tr at openjdk.java.net  Thu Jun  2 16:04:32 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Thu, 2 Jun 2022 16:04:32 GMT
Subject: RFR: JDK-8287261: [macos] JList Focus Ring color doesn't follow
 Accent color changes on macOS [v2]
In-Reply-To: <Mhi36CMVtntJZOkDMIc6fCc2sy8m0X4sFIqXKye7bRs=.4c8279d5-e89c-49ee-9e4d-54da79c8700a@github.com>
References: <m7Go1P8BVJLcyEarJLHiwHUsBKeQ5GnxvHmoKYnfmXo=.8851e019-707c-455a-9a02-249ea8ab2681@github.com>
 <Mhi36CMVtntJZOkDMIc6fCc2sy8m0X4sFIqXKye7bRs=.4c8279d5-e89c-49ee-9e4d-54da79c8700a@github.com>
Message-ID: <muPFWg1zcIuiZBJIb-WMdiwYmBMi5G27Frxgod-QoM4=.c32c333e-db91-4fbe-91b1-f6bd1b0ffd62@github.com>

On Wed, 1 Jun 2022 19:40:34 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> With the proposed fix, JList's focus ring color follows accent color changes. Previously the focus ring for JList was not prominently visible and did not follow accent color changes.
>> 
>> While investing a similar issue related to JTable (https://github.com/openjdk/jdk/pull/7768#discussion_r839813517), it was observed that List.focusCellHighlightBorder was using the cellFocusRing color as well. This PR extends the focus ring accent color changes to JLists. 
>> 
>> Related issues: [JDK-7124282](https://bugs.openjdk.java.net/browse/JDK-7124282) , [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243)
>> 
>> ####    Summary of changes
>> 
>> -  focusCellHighlightBorder in `AquaLookAndFeel` changed which is used for cell border for lists and tables
>> -  code related to on-the-fly focus ring color refactored into a separate method (`changeFocusRingColor()`) for re-usability 
>> -  `changeFocusRingColor()` called when PropertyChangeEvent == FRAME_ACTIVE_PROPERTY and the frame gains focus, instead of calling in individual `swapSelectionColors` in `AquaFocusHandler.java`
>> - Common test added - `CellFocusRingTest`, which tests for both cases - Tables & Lists. 
>> 
>> **Before and After screenshots of JList** _(Screenshots from SwingSet2 demo)_
>> 
>> ![Screen Shot 2022-05-25 at 3 55 49 PM](https://user-images.githubusercontent.com/95945681/170382727-54ed155b-6f08-4c75-8657-89c15764e1cd.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed redundant null checks in test

Marked as reviewed by tr (Author).

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

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


From asemenov at openjdk.java.net  Thu Jun  2 16:14:35 2022
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Thu, 2 Jun 2022 16:14:35 GMT
Subject: RFR: 8287740 NSAccessibilityShowMenuAction not working for text
 editors
Message-ID: <ih2ncVe2WAcD_nsvq0Paoik3urPoMhxwtD_2Gapgnc8=.51f59891-ce8b-4ecc-a3f1-f059abfa0e1b@github.com>

The NSAccessibilityShouMinuAction action does not show the menu for the text element. 
Steps to reproduce: 
1. redefine the accessible context with the addition of the toggle popup action; 
2. run on macOS with VoiceOver enabled; 
3. try to call the context menu in the editor by pressing vo+shift+m.

@azuev-java please review.

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

Commit messages:
 - 8287740 NSAccessibilityShowMenuAction not working for text editors

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

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


From honkar at openjdk.java.net  Thu Jun  2 17:21:23 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Thu, 2 Jun 2022 17:21:23 GMT
Subject: RFR: JDK-8287261: [macos] JList Focus Ring color doesn't follow
 Accent color changes on macOS [v2]
In-Reply-To: <0qBB8EiFX2jC8stWm73ILBjH9b4n5ejPaH1F1xtS1W0=.1eb0f8d4-4458-4957-a460-4acc6bba77bd@github.com>
References: <m7Go1P8BVJLcyEarJLHiwHUsBKeQ5GnxvHmoKYnfmXo=.8851e019-707c-455a-9a02-249ea8ab2681@github.com>
 <Mhi36CMVtntJZOkDMIc6fCc2sy8m0X4sFIqXKye7bRs=.4c8279d5-e89c-49ee-9e4d-54da79c8700a@github.com>
 <0qBB8EiFX2jC8stWm73ILBjH9b4n5ejPaH1F1xtS1W0=.1eb0f8d4-4458-4957-a460-4acc6bba77bd@github.com>
Message-ID: <UX6GL-WbE9glwUkgeS-IWJ1Hkm2U6hQ5pvngCgcbnVo=.ad162d80-eff5-4209-bded-32779e523a54@github.com>

On Thu, 2 Jun 2022 00:55:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Can you please double check how the native applications/components look when the colors are "similar".

@mrserb There are different variations in the native applications -

On Reminders App the background color remains the same (light gray) irrespective of changes in accent color.
<img width="474" alt="Screen Shot 2022-06-02 at 9 54 06 AM" src="https://user-images.githubusercontent.com/95945681/171683525-142cbcef-7e16-4808-b7aa-d79079832646.png">

On edit mode it changes to -
<img width="474" alt="Screen Shot 2022-06-02 at 9 59 20 AM" src="https://user-images.githubusercontent.com/95945681/171684166-9fd757b5-0b3c-4fee-9631-4a7d702945f2.png">

Under notification settings - the background color changes with accent color but it doesn't have a focus ring.

<img width="333" alt="Screen Shot 2022-06-02 at 10 03 13 AM" src="https://user-images.githubusercontent.com/95945681/171684797-d5aec141-c3cf-4534-960c-979c3cf19b7f.png">

At present a focus ring is added to JLists, but since it is almost the same color as the background it is not visible. To keep it consistent with JTable changes, the ring color is made brighter and prominent. Please let me know your suggestion or thoughts on the changes.

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

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


From kizune at openjdk.java.net  Thu Jun  2 17:30:36 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 2 Jun 2022 17:30:36 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <GPzIIvLxz-v5hjtHLPCqEmpMn0dyJybVfPhQbVtMvKM=.517d28de-1197-4f4b-97da-7f7109c6df0d@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <rWCyzbxnTraucb96bdEvdDEv7Dx0SdlW0ur1RFoTzMA=.0c697691-3dba-476b-80ac-2a8f0306cf80@github.com>
 <ykpowK0z6aNXzTun2818uIhiF1V-VIF5ZTzmWtaGKDk=.ebb3750e-f8f0-4e81-9358-be6a6618e259@github.com>
 <GPzIIvLxz-v5hjtHLPCqEmpMn0dyJybVfPhQbVtMvKM=.517d28de-1197-4f4b-97da-7f7109c6df0d@github.com>
Message-ID: <394ZKlHeBY6tayJABl4zkng4n2g5Yb_zb3iJIsVTUXc=.bfae05cb-6d3e-4b8d-93d6-03f87d1b10a3@github.com>

On Wed, 16 Mar 2022 05:36:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> This might be a rookie question:
>>> 
>>> When it comes to modifying and restoring a Graphics, I've seen two common patterns: A. Call `newG = g.create()` and later `newG.dispose()` B. Call `g.setX(newValue)` and then call `g.setX(oldValue)` later
>>> 
>>> Is there guidance on when to use which? Or is one always preferred?
>> 
>> Usually i follow the rule of minimal action. When i need to set a lot of hints that needs to be later unrolled such as changing graphics coordinates and such - i'm creating a new Graphics. When i only need to manipulate a single hint and it can easily be unrolled - i am using the same object. In this case i'm changing just a single hint.
>
> I am not sure that this is the right place to change the hints.
> If we want to always scale the icon using the bicubic interpolation then it is better to do it where we call the paintIcon() method in some jcomponent(this probably may be configured by some option - similar to the text antialisaing). But it will affect performance since the bicubic is much slower.
> 
> But before discussing this shared code change could you please provide some info on why it worked fine before? Why we try to downscale the image and do not get an exact size from the native.

The reason for the issue to manifest is that due to the high resolution icon fix on Windows we are returning a multiresolution image now and the new code that fetches the icons for some icons returns 32x32 icon no matter what resolution is requested so we ended up with an 16x16 multiresolution icon with only variant available 32x32 so icon painter is doing the scaling. One of the possible solutions i considered is to interpolate the icon in the process of creation but that will only hide the problem because you see - in my test i was able to reproduce the scaling problem without the Windows code, simply by wrapping the larger icon into smaller MultiResolutionIcon. And i do not think that changing hints in every component is a good idea - because it will require these components to be much more aware of the icon's internal mechanic which is not a great idea. And taking into consuderation that we only enable bicubic interpolation for icons that really require it - when icon does not ha
 ve a resolution variant that fits the current icon's size - it should not be a serious performance impact. In majority of the cases interpolation is not required.

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

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


From kizune at openjdk.java.net  Thu Jun  2 17:30:39 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 2 Jun 2022 17:30:39 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <ms8g1-XqOxHCBTQIO8vyRbli10-TE_m1rjaJhDPf1AM=.281afbc5-bf1a-427a-9dd8-3476db10b7e1@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
 <ms8g1-XqOxHCBTQIO8vyRbli10-TE_m1rjaJhDPf1AM=.281afbc5-bf1a-427a-9dd8-3476db10b7e1@github.com>
Message-ID: <DeqLg0CSyiHoE-Ao6Ct0ii0LdAS3jpbJd48IF30Rcls=.75c71c01-8136-4d2b-9f7b-ee701a7a24db@github.com>

On Wed, 1 Jun 2022 23:44:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Do we need to update the size value and take into account the low/hi sizes?

Not exactly, the issue is that for some files (but just for some of them) this call ignores the  high icon size parameter and always returns the set of small and large icons as 16x16 plus 32x32. For the rest of the files it returns 16x16 and the requested size. If low size is not set it is assumed to be 16x16 so we can omit setting it.

> Does it mean that we will extract all images except on the sides twice? for 16x16 we will extract 16x16 and 32x32 on the next iteration for 32x32 we will extract 32x32 and 64x64?

No, on the next iteration we will extract 16x16 and 64x64. So on each iteration we are going to extract additionally 16x16 icon and if size is 24 or more than we will ignore it. Since all the icons requested are cached that will not cause any performance degradation.

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

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


From kizune at openjdk.java.net  Thu Jun  2 17:30:43 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 2 Jun 2022 17:30:43 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <JwSc0m39F3Fq8zZn27a77G166ydpKoExnQqHObthslM=.bd8445fc-9b59-4ca5-843b-6b89a8fcbee2@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <JwSc0m39F3Fq8zZn27a77G166ydpKoExnQqHObthslM=.bd8445fc-9b59-4ca5-843b-6b89a8fcbee2@github.com>
Message-ID: <3REYfBcQCMQm54PRhxHa4ZKtz1Xtvse9p2T_48Xfgmc=.2bbc334d-77e6-40ff-8ce6-d3fad161560a@github.com>

On Mon, 14 Mar 2022 02:29:47 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use small icon pointer for icons less than 24 pixels wide - this way we
>>   get the 16x16 icon which is better for scaling purposes.
>
> test/jdk/javax/swing/ImageIcon/MultiResolutionImageIcon.java line 127:
> 
>> 125:         return null;
>> 126:     }
>> 127: }
> 
> This test reads a little strange to me. (I'm not an official openjdk reviewer, though, so feel free to disregard.)
> 
> If I run this test with the existing ImageIcon class it creates an image that resembles:
> ![image](https://user-images.githubusercontent.com/7669569/158093894-be7a73c6-6936-4725-bb09-cd054a2dccc2.png)
> 
> If I run this test with the revised code it creates an image that resembles:
> ![image](https://user-images.githubusercontent.com/7669569/158093939-bffc62c7-7a5c-4b0e-b71e-710c5049daf6.png)
> 
> Based on the changes in ImageIcon: I only expected to see changes related to rendering hints. (That is: I expected to see differences in antialiasing and scaling artifacts.)
> 
> Would you mind if I proposed a different test?

Well, the difference in the images generated is the demonstration of how significant parts of the original image gets lost during the rendering. Not sure why you think this test is not valid.

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

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


From kizune at openjdk.java.net  Thu Jun  2 18:15:35 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 2 Jun 2022 18:15:35 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <DeqLg0CSyiHoE-Ao6Ct0ii0LdAS3jpbJd48IF30Rcls=.75c71c01-8136-4d2b-9f7b-ee701a7a24db@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
 <ms8g1-XqOxHCBTQIO8vyRbli10-TE_m1rjaJhDPf1AM=.281afbc5-bf1a-427a-9dd8-3476db10b7e1@github.com>
 <DeqLg0CSyiHoE-Ao6Ct0ii0LdAS3jpbJd48IF30Rcls=.75c71c01-8136-4d2b-9f7b-ee701a7a24db@github.com>
Message-ID: <3Dse5Mi4Lsodr2ytpTSGqNaRLiUcp4928refltpwCGw=.d3c9d1e7-8954-4356-badf-dcd2f8209fbf@github.com>

On Thu, 2 Jun 2022 17:26:49 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 993:
>> 
>>> 991:             } else {
>>> 992:                 fn_DestroyIcon((HICON)hIconSmall);
>>> 993:             }
>> 
>> Does it mean that we will extract all images except on the sides twice? for 16x16 we will extract 16x16 and 32x32 on the next iteration for 32x32 we will extract 32x32 and 64x64?
>> 
>> Can we try to do that via different API: https://devblogs.microsoft.com/oldnewthing/20140501-00/?p=1103 probably it will work better?
>
>> Does it mean that we will extract all images except on the sides twice? for 16x16 we will extract 16x16 and 32x32 on the next iteration for 32x32 we will extract 32x32 and 64x64?
> 
> No, on the next iteration we will extract 16x16 and 64x64. So on each iteration we are going to extract additionally 16x16 icon and if size is 24 or more than we will ignore it. Since all the icons requested are cached that will not cause any performance degradation.

> Can we try to do that via different API: https://devblogs.microsoft.com/oldnewthing/20140501-00/?p=1103 probably it will work better?

No, during initial implementation i tried it and it worked even worse and less stable.

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

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


From azvegint at openjdk.java.net  Thu Jun  2 20:19:50 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 2 Jun 2022 20:19:50 GMT
Subject: RFR: 8273573: [macos12] ActionListenerCalledTwiceTest.java fails on
 macOS 12
Message-ID: <mx87EX5GSQH8vynwviPWaJ_Sm9-aaArJyt1pEq3zp9U=.54e10297-5a40-49d4-93ec-e2dab902b95f@github.com>

This test was failing consistently on same machines and at the same time as #8532.

Test failure is also no longer reproducible after #8320 fix.

This is macOS only test, so corresponding `@requires os.family` tag was added. Testing is green.

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

Commit messages:
 - os.family
 - initial

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

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


From bourges.laurent at gmail.com  Thu Jun  2 20:48:25 2022
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 2 Jun 2022 22:48:25 +0200
Subject: Any interest in JDK-8264999 (stroke miter edge case in
 Marlin)
In-Reply-To: <CAKjRUT6XjXmY_O_qsPLYZ4XELgnFf71_Dr4C5vEUj-UqqFu_5g@mail.gmail.com>
References: <em956b4aed-8eed-4621-88ac-4433c897d3cd@4e48b9a9.com>
 <CAKjRUT5=CsuyXP2QPPYYdH5YRPKDJ_xopAb0vEJ-v8CVKhjQhA@mail.gmail.com>
 <em4b3d4ab2-f324-4bdf-b221-36f35f807324@4e48b9a9.com>
 <CAKjRUT6vcEPciK+X9J9ZEU_Fcv3Z_i-N_KwUrRo8g3WsPR_6yg@mail.gmail.com>
 <CAKjRUT62cVDTfF4HW_LRywqo5dQt7HTeoQ+hJFk9h_8szs8fBg@mail.gmail.com>
 <CAKjRUT6XjXmY_O_qsPLYZ4XELgnFf71_Dr4C5vEUj-UqqFu_5g@mail.gmail.com>
Message-ID: <CAKjRUT54LYwseYDKLwMzbbTvVeGiiEOO=i_OUm7tDbE2Y06i7Q@mail.gmail.com>

Jeremy,

I hope you are doing well.

As jdk9 rdp1 is next week, do you plan this bug to be ready for this short
window or not ?

Laurent

Le dim. 29 mai 2022, 09:31, Laurent Bourg?s <bourges.laurent at gmail.com> a
?crit :

> One more general comment on this bug:
> what is expected when lineTo() does not change last point after all other
> possible operations ?
> - lineTo, lineto (this bug)
> - quadTo, lineto
> - cubicTo, lineto
> - moveto, lineto: point (ok)
> - close, lineto(star: equiv to close, move start, lineto start: point
> start (ok ?)
>
> If any drawing operation in progress (lineto, quadto, curveto), then skip
> repeated end point is the specified behaviour.
>
> Laurent
>
> Le mer. 25 mai 2022, 08:57, Laurent Bourg?s <bourges.laurent at gmail.com> a
> ?crit :
>
>> In Stroker, this lines seems causing the problem:
>>
>> https://github.com/openjdk/jdk/blob/a0cccb54791d954bf08da5aac9b9794e370617c8/src/java.desktop/share/classes/sun/java2d/marlin/Stroker.java#L568
>>
>> If delta is 0, then tangent is (1, 0) !
>> Should be:
>> If drawOp was lineTo and delta is 0, return (skip).
>>
>> I wonder if there are other renderer suffering the same problem.
>> Phil, how could we generalize this kind of path operation filtering ?
>>
>> My 2 cents,
>> Laurent
>>
>> Le mer. 25 mai 2022, 08:15, Laurent Bourg?s <bourges.laurent at gmail.com>
>> a ?crit :
>>
>>> Jeremy,
>>>
>>> Probably your fix could be plugged in marlin pathTo() :
>>>
>>> https://github.com/openjdk/jdk/blob/742644e291039e4f2f30cf80718669c06da5809c/src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java#L768
>>>
>>> Or in Stroker lineTo...
>>>
>>> Laurent
>>>
>>> Le mar. 24 mai 2022, 22:55, Jeremy Wood <mickleness at gmail.com> a ?crit :
>>>
>>>> I may still move it in the Stroker classes. There are a few other
>>>> things
>>>> I want to look at, too. This is a very rough draft I put together in
>>>> under an hour; I just wanted to make sure it was worth pursuing before
>>>> I
>>>> put more time into it.
>>>>
>>>>   - Jeremy
>>>>
>>>>
>>>> ------ Original Message ------
>>>> From "Laurent Bourg?s" <bourges.laurent at gmail.com>
>>>> To "Jeremy Wood" <mickleness at gmail.com>
>>>> Cc client-libs-dev at openjdk.java.net
>>>> Date 5/24/2022 4:35:21 PM
>>>> Subject Re: Any interest in JDK-8264999 (stroke miter edge case in
>>>> Marlin)
>>>>
>>>> >Thanks Jereremy for the notification I was not aware of this one.
>>>> >
>>>> >I wonder if the problem should be fixed inside the marlin renderer
>>>> >Stroker that should ignore such useless lineTo...
>>>> >
>>>> >I will read your code and try to figure out potential causes in
>>>> stroker
>>>> >and give you my feedback.
>>>> >
>>>> >Laurent
>>>> >
>>>> >Le mar. 24 mai 2022, 19:52, Jeremy Wood <mickleness at gmail.com> a
>>>> ?crit
>>>> >:
>>>> >>This is a P3 ticket currently assigned to Philip Race:
>>>> >>https://bugs.openjdk.java.net/browse/JDK-8264999
>>>> >>
>>>> >>If I put together a PR: Is anyone available/willing to help review it?
>>>> >>
>>>> >>I made a rough draft
>>>> >><
>>>> https://github.com/openjdk/jdk/compare/master...mickleness:JDK-8264999?expand=1
>>>> >
>>>> >>of a potential solution last night. I can continue to work on this,
>>>> or
>>>> >>I
>>>> >>can move on if the interest isn?t there.
>>>> >>
>>>> >>(No urgency at all.)
>>>> >>
>>>> >>Regards,
>>>> >>   - Jeremy
>>>> >><https://>
>>>>
>>>


From mickleness at gmail.com  Thu Jun  2 21:35:57 2022
From: mickleness at gmail.com (Jeremy Wood)
Date: Thu, 02 Jun 2022 21:35:57 +0000
Subject: Any interest in JDK-8264999 (stroke miter edge case in Marlin)
In-Reply-To: <CAKjRUT54LYwseYDKLwMzbbTvVeGiiEOO=i_OUm7tDbE2Y06i7Q@mail.gmail.com>
References: <em956b4aed-8eed-4621-88ac-4433c897d3cd@4e48b9a9.com>
 <CAKjRUT5=CsuyXP2QPPYYdH5YRPKDJ_xopAb0vEJ-v8CVKhjQhA@mail.gmail.com>
 <em4b3d4ab2-f324-4bdf-b221-36f35f807324@4e48b9a9.com>
 <CAKjRUT6vcEPciK+X9J9ZEU_Fcv3Z_i-N_KwUrRo8g3WsPR_6yg@mail.gmail.com>
 <CAKjRUT62cVDTfF4HW_LRywqo5dQt7HTeoQ+hJFk9h_8szs8fBg@mail.gmail.com>
 <CAKjRUT6XjXmY_O_qsPLYZ4XELgnFf71_Dr4C5vEUj-UqqFu_5g@mail.gmail.com>
 <CAKjRUT54LYwseYDKLwMzbbTvVeGiiEOO=i_OUm7tDbE2Y06i7Q@mail.gmail.com>
Message-ID: <em2349b285-c3ce-4077-8edd-ec5dabc7200c@0b4679bb.com>

Laurent,

I made a very modest PR here:

https://github.com/openjdk/jdk/pull/8943

I wasn?t aware there was a deadline coming up; thanks for letting me 
know.

This passes my current test, but depending on code review feedback it?s 
hard to predict if this will be ready by next week.

  - Jeremy

------ Original Message ------
>From "Laurent Bourg?s" <bourges.laurent at gmail.com>
To "Jeremy Wood" <mickleness at gmail.com>
Cc client-libs-dev at openjdk.java.net
Date 6/2/2022 4:48:25 PM
Subject Re: Re[2]: Any interest in JDK-8264999 (stroke miter edge case 
in Marlin)

>Jeremy,
>
>I hope you are doing well.
>
>As jdk9 rdp1 is next week, do you plan this bug to be ready for this 
>short window or not ?
>
>Laurent
>
>Le dim. 29 mai 2022, 09:31, Laurent Bourg?s <bourges.laurent at gmail.com> 
>a ?crit :
>>One more general comment on this bug:
>>what is expected when lineTo() does not change last point after all 
>>other possible operations ?
>>- lineTo, lineto (this bug)
>>- quadTo, lineto
>>- cubicTo, lineto
>>- moveto, lineto: point (ok)
>>- close, lineto(star: equiv to close, move start, lineto start: point 
>>start (ok ?)
>>
>>If any drawing operation in progress (lineto, quadto, curveto), then 
>>skip repeated end point is the specified behaviour.
>>
>>Laurent
>>
>>Le mer. 25 mai 2022, 08:57, Laurent Bourg?s 
>><bourges.laurent at gmail.com> a ?crit :
>>>In Stroker, this lines seems causing the problem:
>>>https://github.com/openjdk/jdk/blob/a0cccb54791d954bf08da5aac9b9794e370617c8/src/java.desktop/share/classes/sun/java2d/marlin/Stroker.java#L568
>>>
>>>If delta is 0, then tangent is (1, 0) !
>>>Should be:
>>>If drawOp was lineTo and delta is 0, return (skip).
>>>
>>>I wonder if there are other renderer suffering the same problem.
>>>Phil, how could we generalize this kind of path operation filtering ?
>>>
>>>My 2 cents,
>>>Laurent
>>>
>>>Le mer. 25 mai 2022, 08:15, Laurent Bourg?s 
>>><bourges.laurent at gmail.com> a ?crit :
>>>>Jeremy,
>>>>
>>>>Probably your fix could be plugged in marlin pathTo() :
>>>>https://github.com/openjdk/jdk/blob/742644e291039e4f2f30cf80718669c06da5809c/src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java#L768
>>>>
>>>>Or in Stroker lineTo...
>>>>
>>>>Laurent
>>>>
>>>>Le mar. 24 mai 2022, 22:55, Jeremy Wood <mickleness at gmail.com> a 
>>>>?crit :
>>>>>I may still move it in the Stroker classes. There are a few other 
>>>>>things
>>>>>I want to look at, too. This is a very rough draft I put together 
>>>>>in
>>>>>under an hour; I just wanted to make sure it was worth pursuing 
>>>>>before I
>>>>>put more time into it.
>>>>>
>>>>>   - Jeremy
>>>>>
>>>>>
>>>>>------ Original Message ------
>>>>>From "Laurent Bourg?s" <bourges.laurent at gmail.com>
>>>>>To "Jeremy Wood" <mickleness at gmail.com>
>>>>>Cc client-libs-dev at openjdk.java.net
>>>>>Date 5/24/2022 4:35:21 PM
>>>>>Subject Re: Any interest in JDK-8264999 (stroke miter edge case in
>>>>>Marlin)
>>>>>
>>>>> >Thanks Jereremy for the notification I was not aware of this one.
>>>>> >
>>>>> >I wonder if the problem should be fixed inside the marlin renderer
>>>>> >Stroker that should ignore such useless lineTo...
>>>>> >
>>>>> >I will read your code and try to figure out potential causes in 
>>>>>stroker
>>>>> >and give you my feedback.
>>>>> >
>>>>> >Laurent
>>>>> >
>>>>> >Le mar. 24 mai 2022, 19:52, Jeremy Wood <mickleness at gmail.com> a 
>>>>>?crit
>>>>> >:
>>>>> >>This is a P3 ticket currently assigned to Philip Race:
>>>>> >>https://bugs.openjdk.java.net/browse/JDK-8264999
>>>>> >>
>>>>> >>If I put together a PR: Is anyone available/willing to help 
>>>>>review it?
>>>>> >>
>>>>> >>I made a rough draft
>>>>> >><https://github.com/openjdk/jdk/compare/master...mickleness:JDK-8264999?expand=1>
>>>>> >>of a potential solution last night. I can continue to work on 
>>>>>this, or
>>>>> >>I
>>>>> >>can move on if the interest isn?t there.
>>>>> >>
>>>>> >>(No urgency at all.)
>>>>> >>
>>>>> >>Regards,
>>>>> >>   - Jeremy
>>>>> >><https://>

From serb at openjdk.java.net  Thu Jun  2 21:51:33 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Jun 2022 21:51:33 GMT
Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray
 [v3]
In-Reply-To: <sfFWg8ct9AB9VriUa7nhTsaUF3qtgsftNSGReHXzfb8=.817b4ec7-27c7-48ce-aada-bddf11cb7d8a@github.com>
References: <KbpNZ7Yzxx6cUu_DQI5QawOSz2BfkC02EgzR28gUiyU=.3c2abcd2-54ba-4eea-803d-d04a611df9ed@github.com>
 <lDGxeWeYDdowZ7jpQTrawRBVrMwkgQ0edJAiagSi5Ic=.0951f5d8-20ec-464a-b088-a65ce68fd4f4@github.com>
 <Xd4CzrPr1AsWVUqE8H1sQh7rhDxwNpzONJmU6GC2GXo=.f5ad4c02-8ba8-40e4-8747-61d4cf265ec0@github.com>
 <HwzaK7Njmx3c0YvB_1bSh0LyGO9Baxb_STHAkjlJRz4=.6a15c920-5c57-4eab-ac55-81210acfbc68@github.com>
 <qtbLqKoaHcQ3GJVFSyXoNl_gH3MQNjs108Q0sMKA7-8=.8f17c05e-7b73-4ccd-90c6-1baa6808107a@github.com>
 <pwZkx94UwE7kuUEwsqyQCaCs_ZbxkWima6yMJ1xZCPs=.8efccb89-50bb-48a9-aa82-cee4d744e78d@github.com>
 <Uhg45FWYFo_B7Sq6foqI5-9XB3rGcT6TjdFrCoJqRSI=.d3db6fb8-0a13-4c16-abbc-382561b49c66@github.com>
 <bMMLXijtdz77iocU87ImhIIMy1DYacYxvZ_rgAPkcSM=.6f9a8003-b6b7-433a-aa02-90cd27257957@github.com>
 <qthngcip1goWBnZ3wuFo_a0V3tgDdd3nTJ4UKR8BbTo=.b703ffc6-7609-42fa-8ea9-cf0e39727a24@github.com>
 <aqs63xmcMgf9j6Xeni7pnO92ylQb-NijP8rXZmSxhJc=.a177c6f2-8cf4-4508-a654-514ced365158@github.com>
 <MKq3xRtF0NXWZaxuVAkzcl62g36EKKIdwO3
 Fr5DDids=.fb2869d4-960f-4130-91a6-652792612791@github.com>
 <X9rNJalr7kqhZepLcDju-cOyEvRsZmZjblcJyHpT6LM=.e0f90c83-ca18-42f1-9568-b1a403c289d3@github.com>
 <1zmgKAKgBzh5-I4aGlM0Egx64C-Fv3r2Yhl5R0Mu5ho=.c67c08aa-8d49-4550-9e07-505a93be3840@github.com>
 <sfFWg8ct9AB9VriUa7nhTsaUF3qtgsftNSGReHXzfb8=.817b4ec7-27c7-48ce-aada-bddf11cb7d8a@github.com>
Message-ID: <5SH_KFNr0P2qlV7JwxrkYrnNDYgm3JiUv8izisiLZmI=.a3abcf0f-3fa8-4ee6-b6a5-0e3e3e3a85ef@github.com>

On Thu, 2 Jun 2022 08:18:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> BTW I think that the usage of 
>> `return icons.toArray(EMPTY_TRAY_ARRAY);`
>> is slower than any of other cases: presized or zero. So if we would like to use a similar pattern the zero version is better.
>
>> BTW I think that the usage of
>> `return icons.toArray(EMPTY_TRAY_ARRAY);`
>> is slower than any of other cases: presized or zero. So if we would like to use a similar pattern the zero version is better.
> 
> Why is it? It's the same as `icons.toArray(new TrayIcon[0])` without creating a new zero-sized array.

It should be checked of course, but in zero case the size is known by the compiler not sure that in the cached case it can make the same optimizations. The article above said the cached case is a "marginal improvement over new Foo[0]"

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

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


From serb at openjdk.java.net  Thu Jun  2 21:53:32 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Jun 2022 21:53:32 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <3Dse5Mi4Lsodr2ytpTSGqNaRLiUcp4928refltpwCGw=.d3c9d1e7-8954-4356-badf-dcd2f8209fbf@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
 <ms8g1-XqOxHCBTQIO8vyRbli10-TE_m1rjaJhDPf1AM=.281afbc5-bf1a-427a-9dd8-3476db10b7e1@github.com>
 <DeqLg0CSyiHoE-Ao6Ct0ii0LdAS3jpbJd48IF30Rcls=.75c71c01-8136-4d2b-9f7b-ee701a7a24db@github.com>
 <3Dse5Mi4Lsodr2ytpTSGqNaRLiUcp4928refltpwCGw=.d3c9d1e7-8954-4356-badf-dcd2f8209fbf@github.com>
Message-ID: <hl8lDVSGj2qwmGkMMWQdyOPmjb7JaMQubQEHq42lndA=.9620b494-085b-4b4e-a5b1-e42a9a99061b@github.com>

On Thu, 2 Jun 2022 18:12:26 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>>> Does it mean that we will extract all images except on the sides twice? for 16x16 we will extract 16x16 and 32x32 on the next iteration for 32x32 we will extract 32x32 and 64x64?
>> 
>> No, on the next iteration we will extract 16x16 and 64x64. So on each iteration we are going to extract additionally 16x16 icon and if size is 24 or more than we will ignore it. Since all the icons requested are cached that will not cause any performance degradation.
>
>> Can we try to do that via different API: https://devblogs.microsoft.com/oldnewthing/20140501-00/?p=1103 probably it will work better?
> 
> No, during initial implementation i tried it and it worked even worse and less stable.

But can we use it as a backup if the system does not return the expected size on the initial/current call?

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

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


From bourges.laurent at gmail.com  Thu Jun  2 22:00:50 2022
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 3 Jun 2022 00:00:50 +0200
Subject: Any interest in JDK-8264999 (stroke miter edge case in
 Marlin)
In-Reply-To: <em2349b285-c3ce-4077-8edd-ec5dabc7200c@0b4679bb.com>
References: <em956b4aed-8eed-4621-88ac-4433c897d3cd@4e48b9a9.com>
 <CAKjRUT5=CsuyXP2QPPYYdH5YRPKDJ_xopAb0vEJ-v8CVKhjQhA@mail.gmail.com>
 <em4b3d4ab2-f324-4bdf-b221-36f35f807324@4e48b9a9.com>
 <CAKjRUT6vcEPciK+X9J9ZEU_Fcv3Z_i-N_KwUrRo8g3WsPR_6yg@mail.gmail.com>
 <CAKjRUT62cVDTfF4HW_LRywqo5dQt7HTeoQ+hJFk9h_8szs8fBg@mail.gmail.com>
 <CAKjRUT6XjXmY_O_qsPLYZ4XELgnFf71_Dr4C5vEUj-UqqFu_5g@mail.gmail.com>
 <CAKjRUT54LYwseYDKLwMzbbTvVeGiiEOO=i_OUm7tDbE2Y06i7Q@mail.gmail.com>
 <em2349b285-c3ce-4077-8edd-ec5dabc7200c@0b4679bb.com>
Message-ID: <CAKjRUT6=5CusEbZVx4wLTds_M=i9r5VoC8MhqAXXyFf9rxLNXQ@mail.gmail.com>

Hi Jeremy,

I quickly tested my modified path with the extra condition and noticed so
difference in my tests + fixed the original reproducer code.

It is quite trivial ~ 3 lines in Stroker so it seems doable to release this
fix on time.

I will look at your test code and see how to test few more cases :
quad(..., end) + lineto(end) and cubicto(..., end) + lineto(end).

Anyway this looks good to fix.

Let's see if phil or anybody else has a slot for a simple review next week.

Roadmap:
https://openjdk.org/projects/jdk/19/

Deadline for integration is june 9th.

Cheers,
Laurent

Le jeu. 2 juin 2022, 23:36, Jeremy Wood <mickleness at gmail.com> a ?crit :

> Laurent,
>
> I made a very modest PR here:
>
> https://github.com/openjdk/jdk/pull/8943
>
> I wasn?t aware there was a deadline coming up; thanks for letting me
> know.
>
> This passes my current test, but depending on code review feedback it?s
> hard to predict if this will be ready by next week.
>
>   - Jeremy
>
> ------ Original Message ------
> From "Laurent Bourg?s" <bourges.laurent at gmail.com>
> To "Jeremy Wood" <mickleness at gmail.com>
> Cc client-libs-dev at openjdk.java.net
> Date 6/2/2022 4:48:25 PM
> Subject Re: Re[2]: Any interest in JDK-8264999 (stroke miter edge case
> in Marlin)
>
> >Jeremy,
> >
> >I hope you are doing well.
> >
> >As jdk9 rdp1 is next week, do you plan this bug to be ready for this
> >short window or not ?
> >
> >Laurent
> >
> >Le dim. 29 mai 2022, 09:31, Laurent Bourg?s <bourges.laurent at gmail.com>
> >a ?crit :
> >>One more general comment on this bug:
> >>what is expected when lineTo() does not change last point after all
> >>other possible operations ?
> >>- lineTo, lineto (this bug)
> >>- quadTo, lineto
> >>- cubicTo, lineto
> >>- moveto, lineto: point (ok)
> >>- close, lineto(star: equiv to close, move start, lineto start: point
> >>start (ok ?)
> >>
> >>If any drawing operation in progress (lineto, quadto, curveto), then
> >>skip repeated end point is the specified behaviour.
> >>
> >>Laurent
> >>
> >>Le mer. 25 mai 2022, 08:57, Laurent Bourg?s
> >><bourges.laurent at gmail.com> a ?crit :
> >>>In Stroker, this lines seems causing the problem:
> >>>
> https://github.com/openjdk/jdk/blob/a0cccb54791d954bf08da5aac9b9794e370617c8/src/java.desktop/share/classes/sun/java2d/marlin/Stroker.java#L568
> >>>
> >>>If delta is 0, then tangent is (1, 0) !
> >>>Should be:
> >>>If drawOp was lineTo and delta is 0, return (skip).
> >>>
> >>>I wonder if there are other renderer suffering the same problem.
> >>>Phil, how could we generalize this kind of path operation filtering ?
> >>>
> >>>My 2 cents,
> >>>Laurent
> >>>
> >>>Le mer. 25 mai 2022, 08:15, Laurent Bourg?s
> >>><bourges.laurent at gmail.com> a ?crit :
> >>>>Jeremy,
> >>>>
> >>>>Probably your fix could be plugged in marlin pathTo() :
> >>>>
> https://github.com/openjdk/jdk/blob/742644e291039e4f2f30cf80718669c06da5809c/src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java#L768
> >>>>
> >>>>Or in Stroker lineTo...
> >>>>
> >>>>Laurent
> >>>>
> >>>>Le mar. 24 mai 2022, 22:55, Jeremy Wood <mickleness at gmail.com> a
> >>>>?crit :
> >>>>>I may still move it in the Stroker classes. There are a few other
> >>>>>things
> >>>>>I want to look at, too. This is a very rough draft I put together
> >>>>>in
> >>>>>under an hour; I just wanted to make sure it was worth pursuing
> >>>>>before I
> >>>>>put more time into it.
> >>>>>
> >>>>>   - Jeremy
> >>>>>
> >>>>>
> >>>>>------ Original Message ------
> >>>>>From "Laurent Bourg?s" <bourges.laurent at gmail.com>
> >>>>>To "Jeremy Wood" <mickleness at gmail.com>
> >>>>>Cc client-libs-dev at openjdk.java.net
> >>>>>Date 5/24/2022 4:35:21 PM
> >>>>>Subject Re: Any interest in JDK-8264999 (stroke miter edge case in
> >>>>>Marlin)
> >>>>>
> >>>>> >Thanks Jereremy for the notification I was not aware of this one.
> >>>>> >
> >>>>> >I wonder if the problem should be fixed inside the marlin renderer
> >>>>> >Stroker that should ignore such useless lineTo...
> >>>>> >
> >>>>> >I will read your code and try to figure out potential causes in
> >>>>>stroker
> >>>>> >and give you my feedback.
> >>>>> >
> >>>>> >Laurent
> >>>>> >
> >>>>> >Le mar. 24 mai 2022, 19:52, Jeremy Wood <mickleness at gmail.com> a
> >>>>>?crit
> >>>>> >:
> >>>>> >>This is a P3 ticket currently assigned to Philip Race:
> >>>>> >>https://bugs.openjdk.java.net/browse/JDK-8264999
> >>>>> >>
> >>>>> >>If I put together a PR: Is anyone available/willing to help
> >>>>>review it?
> >>>>> >>
> >>>>> >>I made a rough draft
> >>>>> >><
> https://github.com/openjdk/jdk/compare/master...mickleness:JDK-8264999?expand=1
> >
> >>>>> >>of a potential solution last night. I can continue to work on
> >>>>>this, or
> >>>>> >>I
> >>>>> >>can move on if the interest isn?t there.
> >>>>> >>
> >>>>> >>(No urgency at all.)
> >>>>> >>
> >>>>> >>Regards,
> >>>>> >>   - Jeremy
> >>>>> >><https://>
>


From bourges.laurent at gmail.com  Thu Jun  2 22:07:26 2022
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 3 Jun 2022 00:07:26 +0200
Subject: Any interest in JDK-8264999 (stroke miter edge case in
 Marlin)
In-Reply-To: <CAKjRUT6=5CusEbZVx4wLTds_M=i9r5VoC8MhqAXXyFf9rxLNXQ@mail.gmail.com>
References: <em956b4aed-8eed-4621-88ac-4433c897d3cd@4e48b9a9.com>
 <CAKjRUT5=CsuyXP2QPPYYdH5YRPKDJ_xopAb0vEJ-v8CVKhjQhA@mail.gmail.com>
 <em4b3d4ab2-f324-4bdf-b221-36f35f807324@4e48b9a9.com>
 <CAKjRUT6vcEPciK+X9J9ZEU_Fcv3Z_i-N_KwUrRo8g3WsPR_6yg@mail.gmail.com>
 <CAKjRUT62cVDTfF4HW_LRywqo5dQt7HTeoQ+hJFk9h_8szs8fBg@mail.gmail.com>
 <CAKjRUT6XjXmY_O_qsPLYZ4XELgnFf71_Dr4C5vEUj-UqqFu_5g@mail.gmail.com>
 <CAKjRUT54LYwseYDKLwMzbbTvVeGiiEOO=i_OUm7tDbE2Y06i7Q@mail.gmail.com>
 <em2349b285-c3ce-4077-8edd-ec5dabc7200c@0b4679bb.com>
 <CAKjRUT6=5CusEbZVx4wLTds_M=i9r5VoC8MhqAXXyFf9rxLNXQ@mail.gmail.com>
Message-ID: <CAKjRUT6EwosyowHwaEK7HzNYox17v3OBaQHc7N77sa5fopVBYw@mail.gmail.com>

Sorry, I corrected 2 typo error:

I quickly tested my modified patch with the extra condition and noticed no
difference in my tests + fixed the original reproducer code.

Laurent

Le ven. 3 juin 2022, 00:00, Laurent Bourg?s <bourges.laurent at gmail.com> a
?crit :

> Hi Jeremy,
>
> I quickly tested my modified path with the extra condition and noticed so
> difference in my tests + fixed the original reproducer code.
>
> It is quite trivial ~ 3 lines in Stroker so it seems doable to release
> this fix on time.
>
> I will look at your test code and see how to test few more cases :
> quad(..., end) + lineto(end) and cubicto(..., end) + lineto(end).
>
> Anyway this looks good to fix.
>
> Let's see if phil or anybody else has a slot for a simple review next week.
>
> Roadmap:
> https://openjdk.org/projects/jdk/19/
>
> Deadline for integration is june 9th.
>
> Cheers,
> Laurent
>
> Le jeu. 2 juin 2022, 23:36, Jeremy Wood <mickleness at gmail.com> a ?crit :
>
>> Laurent,
>>
>> I made a very modest PR here:
>>
>> https://github.com/openjdk/jdk/pull/8943
>>
>> I wasn?t aware there was a deadline coming up; thanks for letting me
>> know.
>>
>> This passes my current test, but depending on code review feedback it?s
>> hard to predict if this will be ready by next week.
>>
>>   - Jeremy
>>
>> ------ Original Message ------
>> From "Laurent Bourg?s" <bourges.laurent at gmail.com>
>> To "Jeremy Wood" <mickleness at gmail.com>
>> Cc client-libs-dev at openjdk.java.net
>> Date 6/2/2022 4:48:25 PM
>> Subject Re: Re[2]: Any interest in JDK-8264999 (stroke miter edge case
>> in Marlin)
>>
>> >Jeremy,
>> >
>> >I hope you are doing well.
>> >
>> >As jdk9 rdp1 is next week, do you plan this bug to be ready for this
>> >short window or not ?
>> >
>> >Laurent
>> >
>> >Le dim. 29 mai 2022, 09:31, Laurent Bourg?s <bourges.laurent at gmail.com>
>> >a ?crit :
>> >>One more general comment on this bug:
>> >>what is expected when lineTo() does not change last point after all
>> >>other possible operations ?
>> >>- lineTo, lineto (this bug)
>> >>- quadTo, lineto
>> >>- cubicTo, lineto
>> >>- moveto, lineto: point (ok)
>> >>- close, lineto(star: equiv to close, move start, lineto start: point
>> >>start (ok ?)
>> >>
>> >>If any drawing operation in progress (lineto, quadto, curveto), then
>> >>skip repeated end point is the specified behaviour.
>> >>
>> >>Laurent
>> >>
>> >>Le mer. 25 mai 2022, 08:57, Laurent Bourg?s
>> >><bourges.laurent at gmail.com> a ?crit :
>> >>>In Stroker, this lines seems causing the problem:
>> >>>
>> https://github.com/openjdk/jdk/blob/a0cccb54791d954bf08da5aac9b9794e370617c8/src/java.desktop/share/classes/sun/java2d/marlin/Stroker.java#L568
>> >>>
>> >>>If delta is 0, then tangent is (1, 0) !
>> >>>Should be:
>> >>>If drawOp was lineTo and delta is 0, return (skip).
>> >>>
>> >>>I wonder if there are other renderer suffering the same problem.
>> >>>Phil, how could we generalize this kind of path operation filtering ?
>> >>>
>> >>>My 2 cents,
>> >>>Laurent
>> >>>
>> >>>Le mer. 25 mai 2022, 08:15, Laurent Bourg?s
>> >>><bourges.laurent at gmail.com> a ?crit :
>> >>>>Jeremy,
>> >>>>
>> >>>>Probably your fix could be plugged in marlin pathTo() :
>> >>>>
>> https://github.com/openjdk/jdk/blob/742644e291039e4f2f30cf80718669c06da5809c/src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java#L768
>> >>>>
>> >>>>Or in Stroker lineTo...
>> >>>>
>> >>>>Laurent
>> >>>>
>> >>>>Le mar. 24 mai 2022, 22:55, Jeremy Wood <mickleness at gmail.com> a
>> >>>>?crit :
>> >>>>>I may still move it in the Stroker classes. There are a few other
>> >>>>>things
>> >>>>>I want to look at, too. This is a very rough draft I put together
>> >>>>>in
>> >>>>>under an hour; I just wanted to make sure it was worth pursuing
>> >>>>>before I
>> >>>>>put more time into it.
>> >>>>>
>> >>>>>   - Jeremy
>> >>>>>
>> >>>>>
>> >>>>>------ Original Message ------
>> >>>>>From "Laurent Bourg?s" <bourges.laurent at gmail.com>
>> >>>>>To "Jeremy Wood" <mickleness at gmail.com>
>> >>>>>Cc client-libs-dev at openjdk.java.net
>> >>>>>Date 5/24/2022 4:35:21 PM
>> >>>>>Subject Re: Any interest in JDK-8264999 (stroke miter edge case in
>> >>>>>Marlin)
>> >>>>>
>> >>>>> >Thanks Jereremy for the notification I was not aware of this one.
>> >>>>> >
>> >>>>> >I wonder if the problem should be fixed inside the marlin renderer
>> >>>>> >Stroker that should ignore such useless lineTo...
>> >>>>> >
>> >>>>> >I will read your code and try to figure out potential causes in
>> >>>>>stroker
>> >>>>> >and give you my feedback.
>> >>>>> >
>> >>>>> >Laurent
>> >>>>> >
>> >>>>> >Le mar. 24 mai 2022, 19:52, Jeremy Wood <mickleness at gmail.com> a
>> >>>>>?crit
>> >>>>> >:
>> >>>>> >>This is a P3 ticket currently assigned to Philip Race:
>> >>>>> >>https://bugs.openjdk.java.net/browse/JDK-8264999
>> >>>>> >>
>> >>>>> >>If I put together a PR: Is anyone available/willing to help
>> >>>>>review it?
>> >>>>> >>
>> >>>>> >>I made a rough draft
>> >>>>> >><
>> https://github.com/openjdk/jdk/compare/master...mickleness:JDK-8264999?expand=1
>> >
>> >>>>> >>of a potential solution last night. I can continue to work on
>> >>>>>this, or
>> >>>>> >>I
>> >>>>> >>can move on if the interest isn?t there.
>> >>>>> >>
>> >>>>> >>(No urgency at all.)
>> >>>>> >>
>> >>>>> >>Regards,
>> >>>>> >>   - Jeremy
>> >>>>> >><https://>
>>
>


From serb at openjdk.java.net  Thu Jun  2 22:12:35 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Jun 2022 22:12:35 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <eVISQfZrqHrS2l3skGYunPYJeSwk2PcpQCwaQ5VPXgI=.7738456a-70ca-42d6-8c56-587bc664c68c@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
 <8vrDNTJTPocLihty5ZMoBaqGEX23B4gXxis8TtBvuZ8=.5700255b-33a0-4b17-bbb2-523f5a19e9c8@github.com>
 <pUMmlnzsQYsXWupnuut2VWEs2pHDHZdpqas9MngxlQY=.b6ede20b-e114-426e-94f7-8853c215c249@github.com>
 <eVISQfZrqHrS2l3skGYunPYJeSwk2PcpQCwaQ5VPXgI=.7738456a-70ca-42d6-8c56-587bc664c68c@github.com>
Message-ID: <eBTujBRRSRRUzqzuzVrfabH8GiHkeoDESDMIDPhDa_U=.80047aae-790c-4384-8936-642d9304041d@github.com>

On Thu, 2 Jun 2022 14:08:31 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> > Time: 21313400
> > Time: 4036200
> > Time: 1140613100
> > Time: 839499200
> 
> These are some extreme numbers, on my system it is more like 8 to 10 times slower depending on the run: Time: 13250900 Time: 10126200 Time: 113548000 Time: 113630100

It depends on the native accelerated rendering pipeline implementation, which does not support bicubic and do it in on software loops.

> But still - the question is: how big the difference will be in the real application, knowing that we only apply this hint to a small minority of the cases and difference for single repaint (which is cached and not like we re-draw it continuously) so can we neglect the performance variation to achieve better visual result?

The same question could be asked about all other the icons, why we should upscale/downscale by using the bicubic only the MRI images. The same issue may occur for other icons. For example the FileSystemView.getSystemIcon() may return the icon stored in the "FileView.directoryIcon" UI property. Or the user may create its own image, etc. The reason was about performance. The problem right now is that the user cannot select the "good" appearance if he wants, unlike the text antialiasing. My suggestion is to add a UI property which we discussed above.

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

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


From serb at openjdk.java.net  Thu Jun  2 22:19:36 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Jun 2022 22:19:36 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <hl8lDVSGj2qwmGkMMWQdyOPmjb7JaMQubQEHq42lndA=.9620b494-085b-4b4e-a5b1-e42a9a99061b@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
 <ms8g1-XqOxHCBTQIO8vyRbli10-TE_m1rjaJhDPf1AM=.281afbc5-bf1a-427a-9dd8-3476db10b7e1@github.com>
 <DeqLg0CSyiHoE-Ao6Ct0ii0LdAS3jpbJd48IF30Rcls=.75c71c01-8136-4d2b-9f7b-ee701a7a24db@github.com>
 <3Dse5Mi4Lsodr2ytpTSGqNaRLiUcp4928refltpwCGw=.d3c9d1e7-8954-4356-badf-dcd2f8209fbf@github.com>
 <hl8lDVSGj2qwmGkMMWQdyOPmjb7JaMQubQEHq42lndA=.9620b494-085b-4b4e-a5b1-e42a9a99061b@github.com>
Message-ID: <14w5H3NqVoh17cITByBhbUSlXUvf1o6C5_te0W0KSig=.0e13f718-4ad2-4194-875b-3d8cc4f0f950@github.com>

On Thu, 2 Jun 2022 21:50:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Can we try to do that via different API: https://devblogs.microsoft.com/oldnewthing/20140501-00/?p=1103 probably it will work better?
>> 
>> No, during initial implementation i tried it and it worked even worse and less stable.
>
> But can we use it as a backup if the system does not return the expected size on the initial/current call?

> > Does it mean that we will extract all images except on the sides twice? for 16x16 we will extract 16x16 and 32x32 on the next iteration for 32x32 we will extract 32x32 and 64x64?
> 
> No, on the next iteration we will extract 16x16 and 64x64. So on each iteration we are going to extract additionally 16x16 icon and if size is 24 or more than we will ignore it. Since all the icons requested are cached that will not cause any performance degradation.

Where it is specified that the size of the small icon will be the same and the size of the large will grow? Probably it is related to the size property where we did not set the size of the small icon?

I still do not see a reason why we cannot request the exact size of the image from the windows, so if the small icon and the screen scale is 1.25 we can try to extract 20x20

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

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


From serb at openjdk.java.net  Thu Jun  2 22:33:39 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Jun 2022 22:33:39 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v5]
In-Reply-To: <nphz1L3zr5ekPo2eFwmUHFX4pqFJCXxBMhafQFBbaZM=.169d1930-586d-4064-a5bb-fa2439ae1d50@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <nphz1L3zr5ekPo2eFwmUHFX4pqFJCXxBMhafQFBbaZM=.169d1930-586d-4064-a5bb-fa2439ae1d50@github.com>
Message-ID: <em-Y087aJnsNKz-eDpXVNEZPXScEnlvGxGhnvA_Ktv8=.36bcea55-d010-4f59-bc1e-495d7228fe97@github.com>

On Thu, 2 Jun 2022 12:25:18 GMT, Tejesh R <tr at openjdk.org> wrote:

>> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed from manual to Automatic Test

I see that the bug description has a test case which produce this exception. There are these lines on the stack:

	at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116)
	at java.awt.Container.paint(Container.java:1978)
	at java.awt.Window.paint(Window.java:3906)

So your automatic test may override the paint method and catch an exception there. The main method will check some flags at the end. You can also repaint the window a few times to make sure it is painted. Can we iterate all installed L&F? It seems the test does not have any windows specific code.

I think that the rendering to the BufferedImage as suggested by @aivanov-jdk should work as well.

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

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


From prr at openjdk.java.net  Thu Jun  2 23:10:23 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 2 Jun 2022 23:10:23 GMT
Subject: RFR: 8287600: AA Ovals not rendered under metal
In-Reply-To: <XZl-tJGUpOqvDVtGhsG3k0sogD0IwWwjKFkfXuMgKIQ=.0aa9c8c2-3915-4b0b-8949-cb31f0affdf2@github.com>
References: <XZl-tJGUpOqvDVtGhsG3k0sogD0IwWwjKFkfXuMgKIQ=.0aa9c8c2-3915-4b0b-8949-cb31f0affdf2@github.com>
Message-ID: <aMG-3PgHtW9rAJXhjhnb6jlCyfg6ngNCVchWOr7FSks=.cfd4e464-9b99-48bd-8da9-af3864dda64b@github.com>

On Wed, 1 Jun 2022 20:21:40 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Commit command buffer after MTL_OP_MASK_OP operation

Doesn't seem specific to ovals .. [why] was nothing else affected ?

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

Marked as reviewed by prr (Reviewer).

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


From prr at openjdk.java.net  Thu Jun  2 23:30:30 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 2 Jun 2022 23:30:30 GMT
Subject: RFR: 8287609: macOS: SIGSEGV at [CoreFoundation] CFArrayGetCount /
 sun.font.CFont.getTableBytesNative
In-Reply-To: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
References: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
Message-ID: <EVD5w9FAWrZwlg1Wn4gml7rKoC_hm7cGFiV7GB6b6rs=.301c4a9e-6f96-4838-965a-20f2b6a54b84@github.com>

On Tue, 31 May 2022 23:39:09 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

> `CTFontCopyAvailableTables` can return null, which causes subsequent call to `CFArrayGetCount` to crash with SEGFAULT, just added a null-check.

It looks for a "maxp" table which is absent for this font.

Are you sure ? I know that is what we are looking for but we call an API to get all tables without
specifying any particular table so maOS doesn't know ... 

And that is a REQUIRED table per opentype + apple truetype
https://docs.microsoft.com/en-us/typography/opentype/spec/otff#font-tables
https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6.html
In shared code we throw an exception if we don't find it and you'd see this if you used the dynamic font loading APIs
and if it were installed on Windows or Linux we'd ignore the font.
I'm a bit surprised we get this far on mac without it - or that it isn't rejected by virtually every app.

Of course getTableBytesNative isn't guaranteed to return a table because you could ask for the 'abcd' table .. 
But that macOS API didn't ask for a specific table, it just returned null for ALL tables because  .... ? 
Seems to me that there's at the least a macOS documentation deficiency but I'm not sure you've found the answer
to my question.

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

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


From avu at openjdk.java.net  Thu Jun  2 23:53:38 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Thu, 2 Jun 2022 23:53:38 GMT
Subject: RFR: 8287600: AA Ovals not rendered under metal
In-Reply-To: <aMG-3PgHtW9rAJXhjhnb6jlCyfg6ngNCVchWOr7FSks=.cfd4e464-9b99-48bd-8da9-af3864dda64b@github.com>
References: <XZl-tJGUpOqvDVtGhsG3k0sogD0IwWwjKFkfXuMgKIQ=.0aa9c8c2-3915-4b0b-8949-cb31f0affdf2@github.com>
 <aMG-3PgHtW9rAJXhjhnb6jlCyfg6ngNCVchWOr7FSks=.cfd4e464-9b99-48bd-8da9-af3864dda64b@github.com>
Message-ID: <U3-I20jDJPoVDEYIqzBwGmf0f58XWTMgwCUPo4bK3Ts=.5582bb25-6ca2-4369-af25-c06e8a57396b@github.com>

On Thu, 2 Jun 2022 23:07:37 GMT, Phil Race <prr at openjdk.org> wrote:

> Doesn't seem specific to ovals .. [why] was nothing else affected ?

Yes, you're right it's not only ovals. I've mentioned them because of my reproducer. The following missing frames also was caused by this problem:

LinGrad3RotatedOvalAA : 9,15 FPS - 1 frame(s) skipped
LinGradRotatedOvalAA : 11,73 FPS - 1 frame(s) skipped
RadGrad3RotatedOvalAA : 11,05 FPS - 1 frame(s) skipped
RotatedOvalAA : 10,76 FPS - 1 frame(s) skipped

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

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


From avu at openjdk.java.net  Thu Jun  2 23:53:40 2022
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Thu, 2 Jun 2022 23:53:40 GMT
Subject: Integrated: 8287600: AA Ovals not rendered under metal
In-Reply-To: <XZl-tJGUpOqvDVtGhsG3k0sogD0IwWwjKFkfXuMgKIQ=.0aa9c8c2-3915-4b0b-8949-cb31f0affdf2@github.com>
References: <XZl-tJGUpOqvDVtGhsG3k0sogD0IwWwjKFkfXuMgKIQ=.0aa9c8c2-3915-4b0b-8949-cb31f0affdf2@github.com>
Message-ID: <aau0D1bKpaRbseZPLewXlU5lhuEx4U_N_pPce8pzgPw=.f91b45b3-6705-4a40-8f67-bd8b46b0b401@github.com>

On Wed, 1 Jun 2022 20:21:40 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Commit command buffer after MTL_OP_MASK_OP operation

This pull request has now been integrated.

Changeset: cbaeb00f
Author:    Alexey Ushakov <avu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cbaeb00fcea7fb8942838610c2d68e27d290fb58
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8287600: AA Ovals not rendered under metal

Reviewed-by: aghaisas, prr

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

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


From honkar at openjdk.java.net  Fri Jun  3 00:14:22 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Fri, 3 Jun 2022 00:14:22 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF [v5]
In-Reply-To: <fPBcPnqtKUfav_dSeZ2SpHIXghuYH74czgeEZRCAeZY=.39a68bbd-40ee-45db-9c20-17960f177197@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
 <fPBcPnqtKUfav_dSeZ2SpHIXghuYH74czgeEZRCAeZY=.39a68bbd-40ee-45db-9c20-17960f177197@github.com>
Message-ID: <OsGrc9MBQ3uNjqgUP1Hhj3NCuWXMxYvIwTgjznXpPpU=.5157d88a-5521-4d3e-9eb4-559f804fc366@github.com>

On Thu, 2 Jun 2022 06:03:16 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The tooltip displays accelerated string along with the toooltip string. The feature is implemented and applicable for Metal Look and Feel only. Hence the test is updated for Metal Look and Feel by hard wiring it in the code. Updated the test from manual to automatic.
>
> Tejesh R 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:
> 
>   Unused imports removed

Marked as reviewed by honkar (Author).

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

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


From psadhukhan at openjdk.java.net  Fri Jun  3 03:29:27 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 3 Jun 2022 03:29:27 GMT
Subject: RFR: 8273573: [macos12] ActionListenerCalledTwiceTest.java fails
 on macOS 12
In-Reply-To: <mx87EX5GSQH8vynwviPWaJ_Sm9-aaArJyt1pEq3zp9U=.54e10297-5a40-49d4-93ec-e2dab902b95f@github.com>
References: <mx87EX5GSQH8vynwviPWaJ_Sm9-aaArJyt1pEq3zp9U=.54e10297-5a40-49d4-93ec-e2dab902b95f@github.com>
Message-ID: <TKEAog5S7jPTqZ5kBFULDiHl2AcYgDMwh7AFb-POcms=.2f717268-bc2e-4a3b-b6a8-e172ce90ff0d@github.com>

On Thu, 2 Jun 2022 20:12:01 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test was failing consistently on same machines and at the same time as #8532.
> 
> Test failure is also no longer reproducible after #8320 fix.
> 
> This is macOS only test, so corresponding `@requires os.family` tag was added. Testing is green.

I guess you can remove @author, @modules and also jtreg "Platform" dependency by using System.getProperty("os.name") and update the copyright year

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

Marked as reviewed by psadhukhan (Reviewer).

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


From psadhukhan at openjdk.java.net  Fri Jun  3 03:50:25 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 3 Jun 2022 03:50:25 GMT
Subject: RFR: 8273573: [macos12] ActionListenerCalledTwiceTest.java fails
 on macOS 12
In-Reply-To: <mx87EX5GSQH8vynwviPWaJ_Sm9-aaArJyt1pEq3zp9U=.54e10297-5a40-49d4-93ec-e2dab902b95f@github.com>
References: <mx87EX5GSQH8vynwviPWaJ_Sm9-aaArJyt1pEq3zp9U=.54e10297-5a40-49d4-93ec-e2dab902b95f@github.com>
Message-ID: <X2WbjhddX6fxvJ2fCh3UmGtqV0kmIM5qIiFrReZBTAg=.a01473a1-f119-4597-a557-2f5fcf179e8c@github.com>

On Thu, 2 Jun 2022 20:12:01 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test was failing consistently on same machines and at the same time as #8532.
> 
> Test failure is also no longer reproducible after #8320 fix.
> 
> This is macOS only test, so corresponding `@requires os.family` tag was added. Testing is green.

However, there are some observations in the JBS by @prrace regarding the test which have not been handled


Also I noticed that the test doesn't exit. It appears that the call to

Desktop.getDesktop().setDefaultMenuBar(bar);

is effectively creating another visible window so the AWT thread doesn't exit.

Adding this line below allows the test to exit and should be added to the test
            SwingUtilities.invokeAndWait(() -> Desktop.getDesktop().setDefaultMenuBar(null));

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

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


From kizune at openjdk.java.net  Fri Jun  3 05:16:31 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 3 Jun 2022 05:16:31 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <14w5H3NqVoh17cITByBhbUSlXUvf1o6C5_te0W0KSig=.0e13f718-4ad2-4194-875b-3d8cc4f0f950@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
 <ms8g1-XqOxHCBTQIO8vyRbli10-TE_m1rjaJhDPf1AM=.281afbc5-bf1a-427a-9dd8-3476db10b7e1@github.com>
 <DeqLg0CSyiHoE-Ao6Ct0ii0LdAS3jpbJd48IF30Rcls=.75c71c01-8136-4d2b-9f7b-ee701a7a24db@github.com>
 <3Dse5Mi4Lsodr2ytpTSGqNaRLiUcp4928refltpwCGw=.d3c9d1e7-8954-4356-badf-dcd2f8209fbf@github.com>
 <hl8lDVSGj2qwmGkMMWQdyOPmjb7JaMQubQEHq42lndA=.9620b494-085b-4b4e-a5b1-e42a9a99061b@github.com>
 <14w5H3NqVoh17cITByBhbUSlXUvf1o6C5_te0W0KSig=.0e13f718-4ad2-4194-875b-3d8cc4f0f950@github.com>
Message-ID: <kbyTvN6HV-1DIJxW56O1TRk9sBEhlUEb_ghDoSXF2Mg=.2cc95f11-bc7f-4282-af92-e9619f575895@github.com>

On Thu, 2 Jun 2022 22:15:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I still do not see a reason why we cannot request the exact size of the image from the windows, so if the small icon and the screen scale is 1.25 we can try to extract 20x20

Because for some files - and we can not predict which files these are - function will always return set of 16x16 and 32x32 icons - no matter what we request. For the icons that return proper sizes we do request exact sizes and use them.

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

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


From kizune at openjdk.java.net  Fri Jun  3 05:16:32 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 3 Jun 2022 05:16:32 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <kbyTvN6HV-1DIJxW56O1TRk9sBEhlUEb_ghDoSXF2Mg=.2cc95f11-bc7f-4282-af92-e9619f575895@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
 <ms8g1-XqOxHCBTQIO8vyRbli10-TE_m1rjaJhDPf1AM=.281afbc5-bf1a-427a-9dd8-3476db10b7e1@github.com>
 <DeqLg0CSyiHoE-Ao6Ct0ii0LdAS3jpbJd48IF30Rcls=.75c71c01-8136-4d2b-9f7b-ee701a7a24db@github.com>
 <3Dse5Mi4Lsodr2ytpTSGqNaRLiUcp4928refltpwCGw=.d3c9d1e7-8954-4356-badf-dcd2f8209fbf@github.com>
 <hl8lDVSGj2qwmGkMMWQdyOPmjb7JaMQubQEHq42lndA=.9620b494-085b-4b4e-a5b1-e42a9a99061b@github.com>
 <14w5H3NqVoh17cITByBhbUSlXUvf1o6C5_te0W0KSig=.0e13f718-4ad2-4194-875b-3d8cc4f0f950@github.com>
 <kbyTvN6HV-1DIJxW56O1TRk9sBEhlUEb_ghDoSXF2Mg=.2cc95f11-bc7f-4282-af92-e9619f575895@github.com>
Message-ID: <Nes5fFygjwIKFa6lnzNk-FtIsJNTV7eu2Tu87wwKrKI=.6142730c-ff27-4800-9a3b-3651542be6e6@github.com>

On Fri, 3 Jun 2022 05:12:05 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>>> > Does it mean that we will extract all images except on the sides twice? for 16x16 we will extract 16x16 and 32x32 on the next iteration for 32x32 we will extract 32x32 and 64x64?
>>> 
>>> No, on the next iteration we will extract 16x16 and 64x64. So on each iteration we are going to extract additionally 16x16 icon and if size is 24 or more than we will ignore it. Since all the icons requested are cached that will not cause any performance degradation.
>> 
>> Where it is specified that the size of the small icon will be the same and the size of the large will grow? Probably it is related to the size property where we did not set the size of the small icon?
>> 
>> I still do not see a reason why we cannot request the exact size of the image from the windows, so if the small icon and the screen scale is 1.25 we can try to extract 20x20
>
>> I still do not see a reason why we cannot request the exact size of the image from the windows, so if the small icon and the screen scale is 1.25 we can try to extract 20x20
> 
> Because for some files - and we can not predict which files these are - function will always return set of 16x16 and 32x32 icons - no matter what we request. For the icons that return proper sizes we do request exact sizes and use them.

> But can we use it as a backup if the system does not return the expected size on the initial/current call?

No, because in case when current implementation returns bad results this function also returns incorrect results so it is hardly a backup.

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

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


From kizune at openjdk.java.net  Fri Jun  3 05:27:26 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 3 Jun 2022 05:27:26 GMT
Subject: RFR: 8287740 NSAccessibilityShowMenuAction not working for text
 editors
In-Reply-To: <ih2ncVe2WAcD_nsvq0Paoik3urPoMhxwtD_2Gapgnc8=.51f59891-ce8b-4ecc-a3f1-f059abfa0e1b@github.com>
References: <ih2ncVe2WAcD_nsvq0Paoik3urPoMhxwtD_2Gapgnc8=.51f59891-ce8b-4ecc-a3f1-f059abfa0e1b@github.com>
Message-ID: <bZGa8RkoJjZSQC4NDs-tpXemPgAQn6HVZdRbpyrdYL4=.fad5839e-55ed-4e94-9c10-2c0fc9aa93b3@github.com>

On Thu, 2 Jun 2022 16:07:37 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The NSAccessibilityShouMinuAction action does not show the menu for the text element. 
> Steps to reproduce: 
> 1. redefine the accessible context with the addition of the toggle popup action; 
> 2. run on macOS with VoiceOver enabled; 
> 3. try to call the context menu in the editor by pressing vo+shift+m.
> 
> @azuev-java please review.

Looks good.

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

Marked as reviewed by kizune (Reviewer).

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


From serb at openjdk.java.net  Fri Jun  3 05:35:27 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 3 Jun 2022 05:35:27 GMT
Subject: RFR: 8273573: [macos12] ActionListenerCalledTwiceTest.java fails
 on macOS 12
In-Reply-To: <mx87EX5GSQH8vynwviPWaJ_Sm9-aaArJyt1pEq3zp9U=.54e10297-5a40-49d4-93ec-e2dab902b95f@github.com>
References: <mx87EX5GSQH8vynwviPWaJ_Sm9-aaArJyt1pEq3zp9U=.54e10297-5a40-49d4-93ec-e2dab902b95f@github.com>
Message-ID: <dsbM1k451RXjNC1kUGC-u7we47FHsPWBOHowfDJic2Y=.2e67aaf4-3892-4f9d-a4e1-801253f30c6c@github.com>

On Thu, 2 Jun 2022 20:12:01 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test was failing consistently on same machines and at the same time as #8532.
> 
> Test failure is also no longer reproducible after #8320 fix.
> 
> This is macOS only test, so corresponding `@requires os.family` tag was added. Testing is green.

Marked as reviewed by serb (Reviewer).

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

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


From tr at openjdk.java.net  Fri Jun  3 05:42:32 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Fri, 3 Jun 2022 05:42:32 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v5]
In-Reply-To: <em-Y087aJnsNKz-eDpXVNEZPXScEnlvGxGhnvA_Ktv8=.36bcea55-d010-4f59-bc1e-495d7228fe97@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <nphz1L3zr5ekPo2eFwmUHFX4pqFJCXxBMhafQFBbaZM=.169d1930-586d-4064-a5bb-fa2439ae1d50@github.com>
 <em-Y087aJnsNKz-eDpXVNEZPXScEnlvGxGhnvA_Ktv8=.36bcea55-d010-4f59-bc1e-495d7228fe97@github.com>
Message-ID: <IzjbL_QwjK3W9XEzzDKbgBS9OxzSIyEz4e6jf3obbPo=.2547629d-1493-426b-8ce2-355200d2f4b6@github.com>

On Thu, 2 Jun 2022 22:29:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I see that the bug description has a test case which produce this exception. There are these lines on the stack:
> 
> ```
> 	at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116)
> 	at java.awt.Container.paint(Container.java:1978)
> 	at java.awt.Window.paint(Window.java:3906)
> ```
> 
> So your automatic test may override the paint method and catch an exception there. The main method will check some flags at the end. You can also repaint the window a few times to make sure it is painted. Can we iterate all installed L&F? It seems the test does not have any windows specific code.
> 
> I think that the rendering to the BufferedImage as suggested by @aivanov-jdk should work as well.

Yeah sure @mrserb , will test it on other L&F. I think rendering to the BufferedImage might not invoke NPE, so just wanted to retain the same flow as the bug was raised. Anyhow will try to play around and see if it works.

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

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


From serb at openjdk.java.net  Fri Jun  3 05:44:34 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 3 Jun 2022 05:44:34 GMT
Subject: RFR: 8287740 NSAccessibilityShowMenuAction not working for text
 editors
In-Reply-To: <ih2ncVe2WAcD_nsvq0Paoik3urPoMhxwtD_2Gapgnc8=.51f59891-ce8b-4ecc-a3f1-f059abfa0e1b@github.com>
References: <ih2ncVe2WAcD_nsvq0Paoik3urPoMhxwtD_2Gapgnc8=.51f59891-ce8b-4ecc-a3f1-f059abfa0e1b@github.com>
Message-ID: <yXbBGj1FKO3CF5CdHVRrXwoYRWiuRTqblcc9B9QYGBk=.138bd62f-5c18-46c1-93d1-4fc44ef550c4@github.com>

On Thu, 2 Jun 2022 16:07:37 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The NSAccessibilityShouMinuAction action does not show the menu for the text element. 
> Steps to reproduce: 
> 1. redefine the accessible context with the addition of the toggle popup action; 
> 2. run on macOS with VoiceOver enabled; 
> 3. try to call the context menu in the editor by pressing vo+shift+m.
> 
> @azuev-java please review.

test/jdk/java/awt/a11y/AccessibleActionsTest.java line 100:

> 98:     AccessibleComponentTest.INSTRUCTIONS = "INSTRUCTIONS:\n"
> 99:             + "Check a11y show context menu in editable JTextArea.\n\n"
> 100:             + "Turn screen reader on and press Tab to move to the text area and vo+shif+m.\n\n"

Just a small nit, can we use the same style of instructions, the previous tests use a separate text to press the VO shortcuts, here it could be something like this:
"Turn screen reader on and press Tab to move to the text area"
"Perform the VO action "Open a shortcut menu" (VO+Shift+m)\n\n"

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

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


From tr at openjdk.java.net  Fri Jun  3 05:46:17 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Fri, 3 Jun 2022 05:46:17 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v5]
In-Reply-To: <IzjbL_QwjK3W9XEzzDKbgBS9OxzSIyEz4e6jf3obbPo=.2547629d-1493-426b-8ce2-355200d2f4b6@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <nphz1L3zr5ekPo2eFwmUHFX4pqFJCXxBMhafQFBbaZM=.169d1930-586d-4064-a5bb-fa2439ae1d50@github.com>
 <em-Y087aJnsNKz-eDpXVNEZPXScEnlvGxGhnvA_Ktv8=.36bcea55-d010-4f59-bc1e-495d7228fe97@github.com>
 <IzjbL_QwjK3W9XEzzDKbgBS9OxzSIyEz4e6jf3obbPo=.2547629d-1493-426b-8ce2-355200d2f4b6@github.com>
Message-ID: <n2FROHnyee2XFCYd90LAzZ1-3v-Fs-aI6kiMsaJ7OLA=.fb9adffb-9789-4965-bc73-f8438c2e9b48@github.com>

On Fri, 3 Jun 2022 05:38:42 GMT, Tejesh R <tr at openjdk.org> wrote:

> > I see that the bug description has a test case which produce this exception. There are these lines on the stack:
> > ```
> > 	at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116)
> > 	at java.awt.Container.paint(Container.java:1978)
> > 	at java.awt.Window.paint(Window.java:3906)
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > So your automatic test may override the paint method and catch an exception there. The main method will check some flags at the end. You can also repaint the window a few times to make sure it is painted. Can we iterate all installed L&F? It seems the test does not have any windows specific code.
> > I think that the rendering to the BufferedImage as suggested by @aivanov-jdk should work as well.
> 
> Yeah sure @mrserb , will test it on other L&F. I think rendering to the BufferedImage might not invoke NPE, so just wanted to retain the same flow as the bug was raised. Anyhow will try to play around and see if it works.

No issue in other L&F. Issue exists only in Windows L&F.

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

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


From serb at openjdk.java.net  Fri Jun  3 05:55:47 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 3 Jun 2022 05:55:47 GMT
Subject: RFR: 8287761: Make the logging of J2DBench stable
Message-ID: <dXUeMfLx_fERRN6JpzwellzmpnZUxp6rKiRPbpRQ7ZE=.dacf83dd-b313-44f0-a7d2-224904381597@github.com>

Currently, the logging of the J2DBench differs from run to run. Each time the order of the parameters is random.

For example:
First run: `with to Default Frame, bounce, 1x1, SrcOver, ident, !extraalpha, !xormode, !clip, Default, from transvolimg translucent, !touchsrc, Nearest neighbor`
Next run: `with SrcOver, bounce, Nearest neighbor, ident, !touchsrc, to CompatImage(Opaque), Default, 1x1, !xormode, !clip, from bmcompatimg bitmask, !extraalpha
`
The root cause is that the options are stored in the Hashtable and printed in the "random" order. 

The fix replaces the usage of Hashtable by the LinkedHashMap. The code is tested on jdk1.7 and -source/-target 1.4

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

Commit messages:
 - 8287761: Make the logging of J2DBench stable

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

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


From smandalika at openjdk.java.net  Fri Jun  3 06:30:39 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 3 Jun 2022 06:30:39 GMT
Subject: RFR: JDK-8282777: Create a Regression test for JDK-4515031 [v5]
In-Reply-To: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
References: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
Message-ID: <BVCD4gNV3rTpaqk1S43fzc0fOouyyufn9invWOlhIzY=.4e63cebf-a501-4942-8bba-d75785094191@github.com>

> Create a Regression test for [JDK-4515031](https://bugs.openjdk.java.net/browse/JDK-4515031)
> 
> The issue indicates the need for a a getAccessibleDescription being implemented for the JFileChooser.
> The test added verifies the same.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Review comment fixed: removed redundant rbot code.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7738/files
  - new: https://git.openjdk.java.net/jdk/pull/7738/files/2dc9771d..194e4dbc

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

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

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


From smandalika at openjdk.java.net  Fri Jun  3 06:36:17 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 3 Jun 2022 06:36:17 GMT
Subject: RFR: JDK-8282777: Create a Regression test for JDK-4515031 [v6]
In-Reply-To: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
References: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
Message-ID: <f7hBFNUDXcwMeTleH7PQsUE8sKq1MmTumY9FvONoFUA=.7c8b4a15-c1aa-41b8-9636-72de021c965f@github.com>

> Create a Regression test for [JDK-4515031](https://bugs.openjdk.java.net/browse/JDK-4515031)
> 
> The issue indicates the need for a a getAccessibleDescription being implemented for the JFileChooser.
> The test added verifies the same.
> This review is for migrating tests from a closed test suite to open.

Srinivas Mandalika 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:

  Review comment fixed: removed redundant robot code.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7738/files
  - new: https://git.openjdk.java.net/jdk/pull/7738/files/194e4dbc..02705d15

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

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

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


From tr at openjdk.java.net  Fri Jun  3 07:42:18 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Fri, 3 Jun 2022 07:42:18 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF [v5]
In-Reply-To: <fPBcPnqtKUfav_dSeZ2SpHIXghuYH74czgeEZRCAeZY=.39a68bbd-40ee-45db-9c20-17960f177197@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
 <fPBcPnqtKUfav_dSeZ2SpHIXghuYH74czgeEZRCAeZY=.39a68bbd-40ee-45db-9c20-17960f177197@github.com>
Message-ID: <nR4bPcli2_URwQzKz8hnrjRpzBR4YF-loorxz6dGaFg=.0f7db780-e152-4799-9daa-78d1593826fc@github.com>

On Thu, 2 Jun 2022 06:03:16 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The tooltip displays accelerated string along with the toooltip string. The feature is implemented and applicable for Metal Look and Feel only. Hence the test is updated for Metal Look and Feel by hard wiring it in the code. Updated the test from manual to automatic.
>
> Tejesh R 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:
> 
>   Unused imports removed

https://mach5.us.oracle.com/mdash/jobs/Tejesh-jdk-20220603-0433-33053953?search=result.status:PASSED

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

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


From tr at openjdk.java.net  Fri Jun  3 07:49:39 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Fri, 3 Jun 2022 07:49:39 GMT
Subject: Integrated: 8233477: : [Win LAF]The tooltip doesn't display correctly
 in Win LAF
In-Reply-To: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
Message-ID: <Iamx6NNmtkaHsjv_rH7Lbb0x8sfTMKvJ5UMB4_wLNRM=.b5bc0a82-a619-4c97-9a21-0d5c38cd955f@github.com>

On Tue, 31 May 2022 08:14:14 GMT, Tejesh R <tr at openjdk.org> wrote:

> The tooltip displays accelerated string along with the toooltip string. The feature is implemented and applicable for Metal Look and Feel only. Hence the test is updated for Metal Look and Feel by hard wiring it in the code. Updated the test from manual to automatic.

This pull request has now been integrated.

Changeset: 407abf5d
Author:    Tejesh R <tr at openjdk.org>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/407abf5d65af918e6d9bfed1f4cc7d4cfd74ce24
Stats:     170 lines in 1 file changed: 170 ins; 0 del; 0 mod

8233477: [Win LAF]The tooltip doesn't display correctly in Win LAF

Reviewed-by: psadhukhan, prr, honkar

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

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


From psadhukhan at openjdk.java.net  Fri Jun  3 09:54:49 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 3 Jun 2022 09:54:49 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed
Message-ID: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>

Test is failing in iMac CI systems owing to color difference of 1

`x 0 y 0 rgb1: fff0f0f0 rgb2: fff0eff0`

Added minor color tolerance check. CI testing is green

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

Commit messages:
 - 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java failed

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

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


From azvegint at openjdk.java.net  Fri Jun  3 10:06:21 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 3 Jun 2022 10:06:21 GMT
Subject: RFR: 8273573: [macos12] ActionListenerCalledTwiceTest.java fails
 on macOS 12 [v2]
In-Reply-To: <mx87EX5GSQH8vynwviPWaJ_Sm9-aaArJyt1pEq3zp9U=.54e10297-5a40-49d4-93ec-e2dab902b95f@github.com>
References: <mx87EX5GSQH8vynwviPWaJ_Sm9-aaArJyt1pEq3zp9U=.54e10297-5a40-49d4-93ec-e2dab902b95f@github.com>
Message-ID: <RpLJZluogF3Z0CgEFDbs5DvAfsz20CRsCOkpvZ4_o00=.2dcccd3e-c51c-4e1d-9a91-888dddeba7ea@github.com>

> This test was failing consistently on same machines and at the same time as #8532.
> 
> Test failure is also no longer reproducible after #8320 fix.
> 
> This is macOS only test, so corresponding `@requires os.family` tag was added. Testing is green.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  clean up

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9003/files
  - new: https://git.openjdk.java.net/jdk/pull/9003/files/9dd14689..71917376

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

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

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


From azvegint at openjdk.java.net  Fri Jun  3 10:06:22 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 3 Jun 2022 10:06:22 GMT
Subject: RFR: 8273573: [macos12] ActionListenerCalledTwiceTest.java fails
 on macOS 12
In-Reply-To: <X2WbjhddX6fxvJ2fCh3UmGtqV0kmIM5qIiFrReZBTAg=.a01473a1-f119-4597-a557-2f5fcf179e8c@github.com>
References: <mx87EX5GSQH8vynwviPWaJ_Sm9-aaArJyt1pEq3zp9U=.54e10297-5a40-49d4-93ec-e2dab902b95f@github.com>
 <X2WbjhddX6fxvJ2fCh3UmGtqV0kmIM5qIiFrReZBTAg=.a01473a1-f119-4597-a557-2f5fcf179e8c@github.com>
Message-ID: <_gd4zdzPopcsmauV9G5hoOc9CO6_Inm_2NmG4HCp_gU=.d80cd415-9262-4c5c-9f03-65ae452ac6e3@github.com>

On Fri, 3 Jun 2022 03:47:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> However, there are some observations in the JBS by @prrace regarding the test which have not been handled
> 
> ```
> Also I noticed that the test doesn't exit. It appears that the call to
> 
> Desktop.getDesktop().setDefaultMenuBar(bar);
> 
> is effectively creating another visible window so the AWT thread doesn't exit.
> 
> Adding this line below allows the test to exit and should be added to the test
>             SwingUtilities.invokeAndWait(() -> Desktop.getDesktop().setDefaultMenuBar(null)); 
> ```

BTW this affects only running test in a standalone mode, jtreg handles this. 
But it may be a bad example, so updated.


> I guess you can remove @author, @modules and also jtreg "Platform" dependency by using System.getProperty("os.name") and update the copyright year

Sure, but initially it was just a removal from problemlist.

Updated.

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

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


From tr at openjdk.java.net  Fri Jun  3 10:27:20 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Fri, 3 Jun 2022 10:27:20 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v6]
In-Reply-To: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
Message-ID: <yxA8epduGPo9040PSJ-1pQ0VsX7TNvi-tmWIK_weKYg=.91d62a94-7043-4796-9507-71250ce6ce2b@github.com>

> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Simplified the Test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8830/files
  - new: https://git.openjdk.java.net/jdk/pull/8830/files/1ac4d7b5..391e49f1

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

  Stats: 88 lines in 1 file changed: 25 ins; 57 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8830.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8830/head:pull/8830

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


From asemenov at openjdk.java.net  Fri Jun  3 10:35:22 2022
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Fri, 3 Jun 2022 10:35:22 GMT
Subject: RFR: 8287740 NSAccessibilityShowMenuAction not working for text
 editors [v2]
In-Reply-To: <ih2ncVe2WAcD_nsvq0Paoik3urPoMhxwtD_2Gapgnc8=.51f59891-ce8b-4ecc-a3f1-f059abfa0e1b@github.com>
References: <ih2ncVe2WAcD_nsvq0Paoik3urPoMhxwtD_2Gapgnc8=.51f59891-ce8b-4ecc-a3f1-f059abfa0e1b@github.com>
Message-ID: <QugjB8dd7ZXTQnmHghSo6iSX4uU03uaJx_0WALVm-fU=.3bc084d0-21eb-4b29-a113-644f1ddd1e02@github.com>

> The NSAccessibilityShouMinuAction action does not show the menu for the text element. 
> Steps to reproduce: 
> 1. redefine the accessible context with the addition of the toggle popup action; 
> 2. run on macOS with VoiceOver enabled; 
> 3. try to call the context menu in the editor by pressing vo+shift+m.
> 
> @azuev-java please review.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  Just a small nit, can we use the same style of instructions, the previous tests use a separate text to press the VO shortcuts, here it could be something like this:
  "Turn screen reader on and press Tab to move to the text area"
  "Perform the VO action "Open a shortcut menu" (VO+Shift+m)\n\n"

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8997/files
  - new: https://git.openjdk.java.net/jdk/pull/8997/files/50601c12..5f217525

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

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

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


From asemenov at openjdk.java.net  Fri Jun  3 10:35:22 2022
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Fri, 3 Jun 2022 10:35:22 GMT
Subject: RFR: 8287740 NSAccessibilityShowMenuAction not working for text
 editors [v2]
In-Reply-To: <yXbBGj1FKO3CF5CdHVRrXwoYRWiuRTqblcc9B9QYGBk=.138bd62f-5c18-46c1-93d1-4fc44ef550c4@github.com>
References: <ih2ncVe2WAcD_nsvq0Paoik3urPoMhxwtD_2Gapgnc8=.51f59891-ce8b-4ecc-a3f1-f059abfa0e1b@github.com>
 <yXbBGj1FKO3CF5CdHVRrXwoYRWiuRTqblcc9B9QYGBk=.138bd62f-5c18-46c1-93d1-4fc44ef550c4@github.com>
Message-ID: <nFeJZFjC40qugq19-bQKI9UaS548zji2IOc_PmjxNTc=.5acf6a14-aca2-46b7-bc15-0eeac2fa8937@github.com>

On Fri, 3 Jun 2022 05:41:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Just a small nit, can we use the same style of instructions, the previous tests use a separate text to press the VO shortcuts, here it could be something like this:
>>   "Turn screen reader on and press Tab to move to the text area"
>>   "Perform the VO action "Open a shortcut menu" (VO+Shift+m)\n\n"
>
> test/jdk/java/awt/a11y/AccessibleActionsTest.java line 100:
> 
>> 98:     AccessibleComponentTest.INSTRUCTIONS = "INSTRUCTIONS:\n"
>> 99:             + "Check a11y show context menu in editable JTextArea.\n\n"
>> 100:             + "Turn screen reader on and press Tab to move to the text area and vo+shif+m.\n\n"
> 
> Just a small nit, can we use the same style of instructions, the previous tests use a separate text to press the VO shortcuts, here it could be something like this:
> "Turn screen reader on and press Tab to move to the text area"
> "Perform the VO action "Open a shortcut menu" (VO+Shift+m)\n\n"

done

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

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


From duke at openjdk.java.net  Fri Jun  3 11:45:25 2022
From: duke at openjdk.java.net (Nikita Gubarkov)
Date: Fri, 3 Jun 2022 11:45:25 GMT
Subject: RFR: 8287609: macOS: SIGSEGV at [CoreFoundation] CFArrayGetCount /
 sun.font.CFont.getTableBytesNative
In-Reply-To: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
References: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
Message-ID: <rJrOTUPP786AAuiR25UdeIwx7jGXwoanD1RidrkUWwk=.a02be96a-c5ac-490f-8b6e-79f6f3d3bcc3@github.com>

On Tue, 31 May 2022 23:39:09 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

> `CTFontCopyAvailableTables` can return null, which causes subsequent call to `CFArrayGetCount` to crash with SEGFAULT, just added a null-check.

Sorry for the confusion, "maxp" being absent was only my assumption: `CTFontCopyTable` returned NULL for it, but I cannot be 100% sure about what's going on here, given that `CTFontCopyAvailableTables` doesn't even return anything.
BTW I see that `CTFontCopyAvailableTables` return type is marked as nullable, though conditions when it can be null are not specified.

So this is a very old font and I couldn't even find a tool which could edit it or at least parse and see what's inside, CoreText API is not very helpful as well. But the thing is: we can actually render this font, problems begins when we try to do a full layout, so in my opinion, adding this null-check is okay, we're just not doing anything useful in our layout code instead of crashing :).

And also if I'm not missing something, my change doesn't affect any behavior other that fixing the crash, look:
1. When I debugged it, I found around 5 or something calls to `getTableBytesNative` where it could crash, but the only table required by spec was "maxp" - I assume when asking for non-required table, callers already handle NULL case.
2. Caller uses "maxp" table to calculate upem (and falls back to 1000 if there's no such table) and set font scale (libharfbuzz/hb-font.cc:1512):

font->x_scale = font->y_scale = hb_face_get_upem (face);

3. But this scale is then overwritten anyway, so it doesn't even matter that we didn't find "maxp" table at all (libfontmanager/hb-jdk-font.cc:410):

hb_font_set_scale (font,
                  HBFloatToFixed(jdkFontInfo->ptSize*jdkFontInfo->devScale),
                  HBFloatToFixed(jdkFontInfo->ptSize*jdkFontInfo->devScale));


So it looks like there's really no behavior changed other than not crashing. In my tests text is properly rendered with `Font.layoutGlyphVector` being visually identical to `Font.createGlyphVector`.

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

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


From aghaisas at openjdk.java.net  Fri Jun  3 11:54:27 2022
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 3 Jun 2022 11:54:27 GMT
Subject: RFR: 8287761: Make the logging of J2DBench stable
In-Reply-To: <dXUeMfLx_fERRN6JpzwellzmpnZUxp6rKiRPbpRQ7ZE=.dacf83dd-b313-44f0-a7d2-224904381597@github.com>
References: <dXUeMfLx_fERRN6JpzwellzmpnZUxp6rKiRPbpRQ7ZE=.dacf83dd-b313-44f0-a7d2-224904381597@github.com>
Message-ID: <DL0Nd2sRru1ZyrIW0T2kNNEiAM2wU0un15KYGF_RXro=.5a1dd738-609a-44d4-9b87-e13241e25ed5@github.com>

On Fri, 3 Jun 2022 05:30:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Currently, the logging of the J2DBench differs from run to run. Each time the order of the parameters is random.
> 
> For example:
> First run: `with to Default Frame, bounce, 1x1, SrcOver, ident, !extraalpha, !xormode, !clip, Default, from transvolimg translucent, !touchsrc, Nearest neighbor`
> Next run: `with SrcOver, bounce, Nearest neighbor, ident, !touchsrc, to CompatImage(Opaque), Default, 1x1, !xormode, !clip, from bmcompatimg bitmask, !extraalpha
> `
> The root cause is that the options are stored in the Hashtable and printed in the "random" order. 
> 
> The fix replaces the usage of Hashtable by the LinkedHashMap. The code is tested on jdk1.7 and -source/-target 1.4

This is a good fix.

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

Marked as reviewed by aghaisas (Committer).

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


From mvs at openjdk.java.net  Fri Jun  3 14:59:40 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 3 Jun 2022 14:59:40 GMT
Subject: RFR: 8286772:
 java/awt/dnd/DropTargetInInternalFrameTest/DropTargetInInternalFrameTest.html
 times out and fails in Windows [v2]
In-Reply-To: <thGtniWtm9mKXwzfB5DnnFEs_pyl2yBiCSag5tdz2XU=.5f4bd190-b333-4319-b614-8664634ad45d@github.com>
References: <cX5w-Rq6SET6AM8VbW_1bCOUgZ3dyXKayoIhaK-Gm8k=.9fb40e39-0b93-4118-b52e-c04305e3811b@github.com>
 <thGtniWtm9mKXwzfB5DnnFEs_pyl2yBiCSag5tdz2XU=.5f4bd190-b333-4319-b614-8664634ad45d@github.com>
Message-ID: <bxi_MF4n22jBcM27ZGZiMkKbMXVyoxviLgvHE1BdvgY=.4be6c31e-ce82-4abb-af4a-18fd64d6a388@github.com>

On Thu, 2 Jun 2022 08:14:23 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> This test verifies that dragging from one InternalFrame and a drop target in another InternalFrame functions properly.
>> This fix moves an unstable closed applet based test to open regression based java test, but updated to be more comprehensive with some stabilisation improvements. The closed test was creating noise in CI as it often fails in Windows platform, especially in Windows 11.
>> 
>> Testing:
>> 1. Tested using mach5 20 times per platform and got all Pass.
>> 2. Tested using mach5 5 times specifically on Windows 11 and got all Pass.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Following the process to convert a closed test to open, created a PR in closed space and got it reviewed, now updating this open PR

Any volunteers please?

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

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


From tr at openjdk.java.net  Fri Jun  3 15:08:33 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Fri, 3 Jun 2022 15:08:33 GMT
Subject: RFR: 8286772:
 java/awt/dnd/DropTargetInInternalFrameTest/DropTargetInInternalFrameTest.html
 times out and fails in Windows [v2]
In-Reply-To: <c81DXxFMAMnH8AbV71uz0knL5EOvtT3ALWFzn0LmUdw=.6b091bda-125a-4cf9-8a44-7c9bb1cd5fc4@github.com>
References: <cX5w-Rq6SET6AM8VbW_1bCOUgZ3dyXKayoIhaK-Gm8k=.9fb40e39-0b93-4118-b52e-c04305e3811b@github.com>
 <98d4QKHKLIaozF4R_bRk78e-ibxr7_ot6NBPbnqEw8U=.e4290fae-2a18-41cb-824c-a61541c4b27a@github.com>
 <c81DXxFMAMnH8AbV71uz0knL5EOvtT3ALWFzn0LmUdw=.6b091bda-125a-4cf9-8a44-7c9bb1cd5fc4@github.com>
Message-ID: <33GXTH-QORnvEhncqt9YXVfG2m3ceo6KNXljqD7qxiY=.591c818c-9adb-4af4-ad30-8585fcfda995@github.com>

On Thu, 2 Jun 2022 08:11:20 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> test/jdk/java/awt/dnd/DropTargetInInternalFrameTest.java line 244:
>> 
>>> 242:         private final Dimension preferredDimension = new Dimension(200, 100);
>>> 243:         private final CountDownLatch dropLatch;
>>> 244:         private volatile int calledMethods = 0;
>> 
>> Any reason for changing calledMethods to volatile?
>
> In order to get the updated data all the time, as this variable will be updated from EDT and the value will be read from main thread also.

I meant was it causing an issue in the previous test (before updating the test)?

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

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


From mvs at openjdk.java.net  Fri Jun  3 15:08:35 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Fri, 3 Jun 2022 15:08:35 GMT
Subject: RFR: 8286772:
 java/awt/dnd/DropTargetInInternalFrameTest/DropTargetInInternalFrameTest.html
 times out and fails in Windows [v2]
In-Reply-To: <33GXTH-QORnvEhncqt9YXVfG2m3ceo6KNXljqD7qxiY=.591c818c-9adb-4af4-ad30-8585fcfda995@github.com>
References: <cX5w-Rq6SET6AM8VbW_1bCOUgZ3dyXKayoIhaK-Gm8k=.9fb40e39-0b93-4118-b52e-c04305e3811b@github.com>
 <98d4QKHKLIaozF4R_bRk78e-ibxr7_ot6NBPbnqEw8U=.e4290fae-2a18-41cb-824c-a61541c4b27a@github.com>
 <c81DXxFMAMnH8AbV71uz0knL5EOvtT3ALWFzn0LmUdw=.6b091bda-125a-4cf9-8a44-7c9bb1cd5fc4@github.com>
 <33GXTH-QORnvEhncqt9YXVfG2m3ceo6KNXljqD7qxiY=.591c818c-9adb-4af4-ad30-8585fcfda995@github.com>
Message-ID: <Z44H9Oq2-uHiY9_fIpawCFStuF8pi8isPBsVQopiotU=.d0fa5b9f-4d96-4979-b023-7132cb6d7eef@github.com>

On Fri, 3 Jun 2022 15:04:02 GMT, Tejesh R <tr at openjdk.org> wrote:

>> In order to get the updated data all the time, as this variable will be updated from EDT and the value will be read from main thread also.
>
> I meant was it causing an issue in the previous test (before updating the test)?

I think this was not causing any issues on the previous test.

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

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


From aivanov at openjdk.java.net  Fri Jun  3 15:12:41 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 3 Jun 2022 15:12:41 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v6]
In-Reply-To: <yxA8epduGPo9040PSJ-1pQ0VsX7TNvi-tmWIK_weKYg=.91d62a94-7043-4796-9507-71250ce6ce2b@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <yxA8epduGPo9040PSJ-1pQ0VsX7TNvi-tmWIK_weKYg=.91d62a94-7043-4796-9507-71250ce6ce2b@github.com>
Message-ID: <P6vT7J3tP2rT7IyhtsYD-nTWOzcLt6Q7Cv-SjuDtPy8=.876dc167-3cfd-488a-b75b-dd1618e52a7a@github.com>

On Fri, 3 Jun 2022 10:27:20 GMT, Tejesh R <tr at openjdk.org> wrote:

>> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified the Test

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JTableHeader/TableRendererTest.java line 46:

> 44: import javax.swing.table.TableCellRenderer;
> 45: 
> 46: public class TableRendererTest{

A space between the name and opening brace, please.

test/jdk/javax/swing/JTableHeader/TableRendererTest.java line 50:

> 48:     static JFrame frame = null;
> 49:     private static JScrollPane jScrollPane = null;
> 50:     private static JTable table = null;

Assigning `null` explicitly is not required. A field will always be initialised to its default value, which is `null` for reference types.

Neither `jScrollPane` nor `table` are used outside of `initialize`, convert them to local variables.

test/jdk/javax/swing/JTableHeader/TableRendererTest.java line 61:

> 59:                     Thread.currentThread().setUncaughtExceptionHandler(new ExceptionCheck());
> 60:                     initialize();
> 61:                     //Adding the Test Frame to handle dispose

This comment is a left-over from previous version.

test/jdk/javax/swing/JTableHeader/TableRendererTest.java line 66:

> 64:                 }
> 65:             }
> 66:         });

The try-catch block is unnecessary, we expect no exception, please remove it.

I suggest using a lambda expression instead of anonymous class.

test/jdk/javax/swing/JTableHeader/TableRendererTest.java line 76:

> 74:         }
> 75:         System.out.println("Test Pass!");
> 76:         frame.dispose();

Dispose of the frame before you check for the status. Plus, you have to call dispose on EDT.

I suggest saving the caught exception and re-throwing it here directly or as the cause to `RuntimeException`.

Something like this:


        SwingUtilities.invokeAndWait(frame::dispose);

        if (exception.get() != null) {
            throw new RuntimeException("Test Case Failed. NPE raised!",
                                       exception.get());
        }
        System.out.println("Test Passed");


where `exception` is


    private static final AtomicReference<Throwable> exception =
            new AtomicReference<>();

test/jdk/javax/swing/JTableHeader/TableRendererTest.java line 84:

> 82:         table = new JTable(new MyModel());
> 83:         jScrollPane = new JScrollPane();
> 84:         jScrollPane.setBounds(new java.awt.Rectangle(0,0,350,618));

Suggestion:

        jScrollPane.setBounds(0, 0, 350, 618);

You can pass the parameters directly without creating `Rectangle`. Spaces after commas, please.

test/jdk/javax/swing/JTableHeader/TableRendererTest.java line 102:

> 100:     static class ExceptionCheck implements Thread.UncaughtExceptionHandler {
> 101:         public void uncaughtException(Thread t, Throwable e)
> 102:         {

Put the opening brace on the same line as the declaration, please.

Please add `@Override` annotation to this method and to methods in `MyModel` and `DecoratedHeaderRenderer`.

test/jdk/javax/swing/JTableHeader/TableRendererTest.java line 129:

> 127:         public Component getTableCellRendererComponent(JTable table, Object value, boolean isSelected, boolean hasFocus, int row, int column) {
> 128:             return render.getTableCellRendererComponent(table, value, isSelected, hasFocus, row, column);
> 129:         }

I suggest breaking these long lines. You can list parameters as in the interface declaration:
https://github.com/openjdk/jdk/blob/3789983e89c9de252ef546a1b98a732a7d066650/src/java.desktop/share/classes/javax/swing/table/TableCellRenderer.java#L94-L96

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

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


From aivanov at openjdk.java.net  Fri Jun  3 15:12:47 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 3 Jun 2022 15:12:47 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v4]
In-Reply-To: <Aamzvc-xdKCForWoGV_E4xtJR5Ds87g4DrK2xgbLiEE=.17a30df7-9355-4ba6-8999-f18c38a72bea@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <Aamzvc-xdKCForWoGV_E4xtJR5Ds87g4DrK2xgbLiEE=.17a30df7-9355-4ba6-8999-f18c38a72bea@github.com>
Message-ID: <v_dgY9EktZ3fO-KVaWat1WxCIjY52LfHKSRFT63kW8Q=.fc9fc980-bbaf-451c-8366-3571b6c83420@github.com>

On Thu, 2 Jun 2022 09:14:30 GMT, Tejesh R <tr at openjdk.org> wrote:

>> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.
>
> Tejesh R 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 14 additional commits since the last revision:
> 
>  - Updated based on review comments
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_6429812
>  - JTREG Tags updation
>  - Removal of White space
>  - Updated based on review comments and Added Test case TableRenderTest.java
>  - header object set
>  - Merge remote-tracking branch 'upstream/master' into branch_6429812
>  - Merge remote-tracking branch 'upstream/master'
>  - Merge branch 'master' of github.com:TejeshR13/jdk
>  - Merge branch 'openjdk:master' into master
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/56ca5e28...98c2aab2

test/jdk/javax/swing/JTableHeader/TableRendererTest.java line 29:

> 27:    @library /java/awt/regtesthelpers
> 28:    @build PassFailJFrame
> 29:    @summary Test to check if table is printed without NPE

Suggestion:

   @summary Test to check if table is painted without NPE

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

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


From aivanov at openjdk.java.net  Fri Jun  3 15:24:37 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 3 Jun 2022 15:24:37 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v5]
In-Reply-To: <n2FROHnyee2XFCYd90LAzZ1-3v-Fs-aI6kiMsaJ7OLA=.fb9adffb-9789-4965-bc73-f8438c2e9b48@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <nphz1L3zr5ekPo2eFwmUHFX4pqFJCXxBMhafQFBbaZM=.169d1930-586d-4064-a5bb-fa2439ae1d50@github.com>
 <em-Y087aJnsNKz-eDpXVNEZPXScEnlvGxGhnvA_Ktv8=.36bcea55-d010-4f59-bc1e-495d7228fe97@github.com>
 <IzjbL_QwjK3W9XEzzDKbgBS9OxzSIyEz4e6jf3obbPo=.2547629d-1493-426b-8ce2-355200d2f4b6@github.com>
 <n2FROHnyee2XFCYd90LAzZ1-3v-Fs-aI6kiMsaJ7OLA=.fb9adffb-9789-4965-bc73-f8438c2e9b48@github.com>
Message-ID: <Uf051bpeZcPwBFTCF85sG1FPnItUjxtN9SfmBauyGDU=.ed749e21-e592-46c2-9939-d1985cab8bd4@github.com>

On Fri, 3 Jun 2022 05:42:38 GMT, Tejesh R <tr at openjdk.org> wrote:

> I see that the bug description has a test case which produce this exception. There are these lines on the stack:
> 
> ```
> 	at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116)
> 	at java.awt.Container.paint(Container.java:1978)
> 	at java.awt.Window.paint(Window.java:3906)
> ```
> 
> So your automatic test may override the paint method and catch an exception there. The main method will check some flags at the end.

@TejeshR13's latest version installs `UncaughtExceptionHandler` to see whether any exception occurs on EDT.

> Can we iterate all installed L&F? It seems the test does not have any windows specific code.

It's Windows-specific because NPE is thrown on Windows only. However, testing other L&Fs makes sense to ensure it doesn't happen there either.

 
> I think that the rendering to the BufferedImage as suggested by @aivanov-jdk should work as well.

In theory only. I was unable to make the table paint with its header to `BufferedImage`. The component isn't laid out until it's added to peered top-level. If you know how to make it paint as if in the frame, I'd welcome it. At this point, painting to `BufferedImage` doesn't reproduce the NPE.

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

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


From aivanov at openjdk.java.net  Fri Jun  3 15:42:33 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 3 Jun 2022 15:42:33 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v5]
In-Reply-To: <Uf051bpeZcPwBFTCF85sG1FPnItUjxtN9SfmBauyGDU=.ed749e21-e592-46c2-9939-d1985cab8bd4@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <nphz1L3zr5ekPo2eFwmUHFX4pqFJCXxBMhafQFBbaZM=.169d1930-586d-4064-a5bb-fa2439ae1d50@github.com>
 <em-Y087aJnsNKz-eDpXVNEZPXScEnlvGxGhnvA_Ktv8=.36bcea55-d010-4f59-bc1e-495d7228fe97@github.com>
 <IzjbL_QwjK3W9XEzzDKbgBS9OxzSIyEz4e6jf3obbPo=.2547629d-1493-426b-8ce2-355200d2f4b6@github.com>
 <n2FROHnyee2XFCYd90LAzZ1-3v-Fs-aI6kiMsaJ7OLA=.fb9adffb-9789-4965-bc73-f8438c2e9b48@github.com>
 <Uf051bpeZcPwBFTCF85sG1FPnItUjxtN9SfmBauyGDU=.ed749e21-e592-46c2-9939-d1985cab8bd4@github.com>
Message-ID: <Zuyi0XtZsbW07htrvinNQdniRMRjqgXbdVoxbockqFk=.7738aa62-f9c4-4f1e-8c68-a1f49a69dd8f@github.com>

On Fri, 3 Jun 2022 15:21:02 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > I think that the rendering to the BufferedImage as suggested by @aivanov-jdk should work as well.
> 
> In theory only. I was unable to make the table paint with its header to `BufferedImage`. The component isn't laid out until it's added to peered top-level. If you know how to make it paint as if in the frame, I'd welcome it. At this point, painting to `BufferedImage` doesn't reproduce the NPE.

I haven't been trying hard enough.

Painting *the header* to buffered image throws the NPE.

The test could be as simple as this:


        Dimension size = header.getPreferredSize();
        header.setSize(size);
        // Create the image and graphics
        header.paint(g2d);


You have to explicitly set size to the header.

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

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


From kizune at openjdk.java.net  Fri Jun  3 15:51:05 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 3 Jun 2022 15:51:05 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip
Message-ID: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>

Add try/catch clause to ignore an exception since it is harmless for we isolated
the massge data before passing it ro processor.
Add test case.

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

Commit messages:
 - 8282578: AIOOBE in javax.sound.sampled.Clip

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

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


From aivanov at openjdk.java.net  Fri Jun  3 16:01:42 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 3 Jun 2022 16:01:42 GMT
Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in
 Win LAF [v5]
In-Reply-To: <fPBcPnqtKUfav_dSeZ2SpHIXghuYH74czgeEZRCAeZY=.39a68bbd-40ee-45db-9c20-17960f177197@github.com>
References: <R8g-GFAEVkT01yaKEQ9dc2EEn3pWR_c5v1O6Ko0T0JU=.1d32932f-d4f3-4844-8c57-95a82ee7a289@github.com>
 <fPBcPnqtKUfav_dSeZ2SpHIXghuYH74czgeEZRCAeZY=.39a68bbd-40ee-45db-9c20-17960f177197@github.com>
Message-ID: <UQTyrISydS-d8QB8BpzySRFwgxSLpbszCAgRNEYio2Y=.1ba6596e-92ff-437b-8d5f-d808570ee7dd@github.com>

On Thu, 2 Jun 2022 06:03:16 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The tooltip displays accelerated string along with the toooltip string. The feature is implemented and applicable for Metal Look and Feel only. Hence the test is updated for Metal Look and Feel by hard wiring it in the code. Updated the test from manual to automatic.
>
> Tejesh R 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:
> 
>   Unused imports removed

test/jdk/javax/swing/JToolTip/bug5047379.java line 77:

> 75: 
> 76:     static void handleToolTip() throws Exception {
> 77:         SwingUtilities.updateComponentTreeUI(frame);

This should be called on EDT, shouldn't it?

test/jdk/javax/swing/JToolTip/bug5047379.java line 88:

> 86:                     MetalToolTipUI toolTipObj = (MetalToolTipUI) MetalToolTipUI.createUI(tooltip);
> 87: 
> 88:                     if (tooltip == null) {

Perhaps, the check for null should go before `createUI` with a null object?

test/jdk/javax/swing/JToolTip/bug5047379.java line 94:

> 92: 
> 93:                 } catch (Exception e) {
> 94:                     throw new RuntimeException(e);

Do you expect any other exception but those you throw yourself to fail the test?

test/jdk/javax/swing/JToolTip/bug5047379.java line 133:

> 131:         text += "ToolTip will appear. Here is what should show\t\t\n";
> 132:         text += "The word \\\"TEXT\\\" and then \\\"CTRL-B\\\"\\n\"\t\t";
> 133:         text += "\n";

Why are there two tabs in the end of each line.

Why can't you use static string concatenation? Or a text block?

Creating the string by `text += "literal"` isn't an efficient way.

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

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


From vdyakov at openjdk.java.net  Fri Jun  3 16:46:43 2022
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Fri, 3 Jun 2022 16:46:43 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip
In-Reply-To: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
Message-ID: <O7smcPZZDbVhBsDg7FSWWjK-7OV35lWC59oDezaPDk4=.f3d1c6da-47fc-4972-bb25-07ef606dc58c@github.com>

On Fri, 3 Jun 2022 15:43:39 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add try/catch clause to ignore an exception since it is harmless for we isolated
> the massge data before passing it ro processor.
> Add test case.

@azvegint @prrace please review

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

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


From achung at openjdk.java.net  Fri Jun  3 18:51:40 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Fri, 3 Jun 2022 18:51:40 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v20]
In-Reply-To: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
Message-ID: <ExCTNbF_0spuHyslkce8T3H0Ez5zGI6UOGRe3rFz4jk=.e2acdd91-fef3-418e-9d48-4fa177167782@github.com>

> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:

 - don't reset transform if it contains a non-scale transformation
 - updated test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7449/files
  - new: https://git.openjdk.java.net/jdk/pull/7449/files/935ec438..1d6ac075

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=18-19

  Stats: 278 lines in 3 files changed: 10 ins; 261 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449

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


From aivanov at openjdk.java.net  Fri Jun  3 18:53:35 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 3 Jun 2022 18:53:35 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v7]
In-Reply-To: <5X_sWM6JdbzBhbh1jHzg-03IgrQ6_A3VpudPIPdmW28=.dca81bba-fa38-4e30-bd07-860ef793155c@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <5X_sWM6JdbzBhbh1jHzg-03IgrQ6_A3VpudPIPdmW28=.dca81bba-fa38-4e30-bd07-860ef793155c@github.com>
Message-ID: <gA25yYYhbfsFrl0WiiwJggW1m2jzqC1oc7LsBS9kZTM=.5dcb5dd1-6d24-4eb4-9849-4861dd2f7564@github.com>

On Thu, 2 Jun 2022 15:32:11 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Added test for checking setMargin() of JRadioButton.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed whitespaces

Except for the minor comments, it looks good now.

test/jdk/javax/swing/JRadioButton/bug4380543.java line 59:

> 57:                   Verify only with those L&F where Margin is Visible.
> 58:                3. If Left insets(margins) appear Empty, press Fail,
> 59:                   else press Pass.

Suggestion:

               1. Check if the Left inset(margin) is set visually
                  similar to other three sides around Radio Button
                   and CheckBox (insets set to 20 on all 4 sides).
               2. Rendering depends on OS and supported Look and Feels.
                  Verify only with those L&F where margins are visible.
               3. If Left inset(margin) appears too small, press Fail,
                  else press Pass.


I think _left inset_ or _margin_ is better ? it's one instance.

You may want to add an additional space to all the lines without numbers to visually align the text to the start of the text after the number. I assume this is why you have an extra space before ?and?.

test/jdk/javax/swing/JRadioButton/bug4380543.java line 83:

> 81: 
> 82: class testFrame extends JFrame implements ActionListener {
> 83:     public testFrame() {

Class names should start with a capital letter.

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

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


From aivanov at openjdk.java.net  Fri Jun  3 19:07:33 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 3 Jun 2022 19:07:33 GMT
Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray
 [v3]
In-Reply-To: <5SH_KFNr0P2qlV7JwxrkYrnNDYgm3JiUv8izisiLZmI=.a3abcf0f-3fa8-4ee6-b6a5-0e3e3e3a85ef@github.com>
References: <KbpNZ7Yzxx6cUu_DQI5QawOSz2BfkC02EgzR28gUiyU=.3c2abcd2-54ba-4eea-803d-d04a611df9ed@github.com>
 <lDGxeWeYDdowZ7jpQTrawRBVrMwkgQ0edJAiagSi5Ic=.0951f5d8-20ec-464a-b088-a65ce68fd4f4@github.com>
 <Xd4CzrPr1AsWVUqE8H1sQh7rhDxwNpzONJmU6GC2GXo=.f5ad4c02-8ba8-40e4-8747-61d4cf265ec0@github.com>
 <HwzaK7Njmx3c0YvB_1bSh0LyGO9Baxb_STHAkjlJRz4=.6a15c920-5c57-4eab-ac55-81210acfbc68@github.com>
 <qtbLqKoaHcQ3GJVFSyXoNl_gH3MQNjs108Q0sMKA7-8=.8f17c05e-7b73-4ccd-90c6-1baa6808107a@github.com>
 <pwZkx94UwE7kuUEwsqyQCaCs_ZbxkWima6yMJ1xZCPs=.8efccb89-50bb-48a9-aa82-cee4d744e78d@github.com>
 <Uhg45FWYFo_B7Sq6foqI5-9XB3rGcT6TjdFrCoJqRSI=.d3db6fb8-0a13-4c16-abbc-382561b49c66@github.com>
 <bMMLXijtdz77iocU87ImhIIMy1DYacYxvZ_rgAPkcSM=.6f9a8003-b6b7-433a-aa02-90cd27257957@github.com>
 <qthngcip1goWBnZ3wuFo_a0V3tgDdd3nTJ4UKR8BbTo=.b703ffc6-7609-42fa-8ea9-cf0e39727a24@github.com>
 <aqs63xmcMgf9j6Xeni7pnO92ylQb-NijP8rXZmSxhJc=.a177c6f2-8cf4-4508-a654-514ced365158@github.com>
 <MKq3xRtF0NXWZaxuVAkzcl62g36EKKIdwO3
 Fr5DDids=.fb2869d4-960f-4130-91a6-652792612791@github.com>
 <X9rNJalr7kqhZepLcDju-cOyEvRsZmZjblcJyHpT6LM=.e0f90c83-ca18-42f1-9568-b1a403c289d3@github.com>
 <1zmgKAKgBzh5-I4aGlM0Egx64C-Fv3r2Yhl5R0Mu5ho=.c67c08aa-8d49-4550-9e07-505a93be3840@github.com>
 <sfFWg8ct9AB9VriUa7nhTsaUF3qtgsftNSGReHXzfb8=.817b4ec7-27c7-48ce-aada-bddf11cb7d8a@github.com>
 <5SH_KFNr0P2qlV7JwxrkYrnNDYgm3JiUv8izisiLZmI=.a3abcf0f-3fa8-4ee6-b6a5-0e3e3e3a85ef@github.com>
Message-ID: <3Hb09vfkmzijTchm1zvhozHITFTREY71gaUEmHOUHBg=.db21f888-45d0-4a51-a8f5-030f1f533faa@github.com>

On Thu, 2 Jun 2022 21:48:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> BTW I think that the usage of
>>> `return icons.toArray(EMPTY_TRAY_ARRAY);`
>>> is slower than any of other cases: presized or zero. So if we would like to use a similar pattern the zero version is better.
>> 
>> Why is it? It's the same as `icons.toArray(new TrayIcon[0])` without creating a new zero-sized array.
>
> It should be checked of course, but in zero case the size is known by the compiler not sure that in the cached case it can make the same optimizations. The article above said the cached case is a "marginal improvement over new Foo[0]"

I'm unsure if the Java compiler performs any optimisations here. The called `toArray` verifies the size first, and it's the same size either way, which is zero.

If there were no pre-allocated array, I wouldn't bother with a cached copy. But we have one. One less object to be allocated and to be garbage-collected.

Since the number of the icons is unlikely to become large, I doubt there'll be any noticeable difference.

As your sample above demonstrates, the old code could return an array with a null element in it. This is resolved by the new code.

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

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


From dnguyen at openjdk.java.net  Fri Jun  3 19:14:39 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Fri, 3 Jun 2022 19:14:39 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v5]
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <spOiRrWEV5wzbL43wbasxgzAGE4vwuG_FLk_LV4392Q=.6e2237a4-10dd-41df-adf1-721ca7676684@github.com>

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

Damon Nguyen has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch '8012675/htmlTagParserDocChange' of github.com:DamonGuy/jdk into 8012675/htmlTagParserDocChange
 - Reverted all files. Added test.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7446/files
  - new: https://git.openjdk.java.net/jdk/pull/7446/files/63a29983..b6ddb3cd

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

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

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


From dnguyen at openjdk.java.net  Fri Jun  3 19:24:38 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Fri, 3 Jun 2022 19:24:38 GMT
Subject: RFR: 8286481: Exception printed to stdout on Windows when storing
 transparent image in clipboard
In-Reply-To: <PMPU9OzvBtCWpj0uYATUGfR0raSP42yQN1yiqLutiNk=.16ea65c9-0ee7-4ca7-a52b-3c5fcba8f484@github.com>
References: <PMPU9OzvBtCWpj0uYATUGfR0raSP42yQN1yiqLutiNk=.16ea65c9-0ee7-4ca7-a52b-3c5fcba8f484@github.com>
Message-ID: <PJFXaVKm0DZFf21VCYDjGP5cz8jb6T5r_OISMU5zhVA=.bf8fd458-2cfe-4d5b-8e41-8500d47c51f7@github.com>

On Tue, 24 May 2022 16:54:55 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Removed stacktrace from WClipboard

Marked as reviewed by dnguyen (Author).

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

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


From dnguyen at openjdk.java.net  Fri Jun  3 19:51:24 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Fri, 3 Jun 2022 19:51:24 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v6]
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <BsyJT3M11JDdmSJlreCjV7LvZD5y44Au40rAYPNWlRE=.fdd4649c-fa84-4bbb-b789-04ce855af5b7@github.com>

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Removed print statement. Removed test.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7446/files
  - new: https://git.openjdk.java.net/jdk/pull/7446/files/b6ddb3cd..d587f995

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

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

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


From dnguyen at openjdk.java.net  Fri Jun  3 19:58:24 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Fri, 3 Jun 2022 19:58:24 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v7]
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <EpXyd9zjzOV-YPYAnRij-ic59FvbC-LRbacuw2j95jM=.a9d0e9cc-a752-4c10-949f-d87dad6e0b45@github.com>

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert import changes.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7446/files
  - new: https://git.openjdk.java.net/jdk/pull/7446/files/d587f995..852a93f3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7446&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7446&range=05-06

  Stats: 46 lines in 2 files changed: 6 ins; 32 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7446.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7446/head:pull/7446

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


From prr at openjdk.java.net  Fri Jun  3 20:04:45 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 3 Jun 2022 20:04:45 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v20]
In-Reply-To: <ExCTNbF_0spuHyslkce8T3H0Ez5zGI6UOGRe3rFz4jk=.e2acdd91-fef3-418e-9d48-4fa177167782@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <ExCTNbF_0spuHyslkce8T3H0Ez5zGI6UOGRe3rFz4jk=.e2acdd91-fef3-418e-9d48-4fa177167782@github.com>
Message-ID: <ThUz9yqyPFNHCiWQ-7Ja4FazrIhDZckmK_8WL9oI5ZQ=.e73d91cc-7734-4300-8705-8af63de50e40@github.com>

On Fri, 3 Jun 2022 18:51:40 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - don't reset transform if it contains a non-scale transformation
>  - updated test

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 163:

> 161:             at = g2d.getTransform();
> 162:             oldStk = g2d.getStroke();
> 163:             if((at.getType() & AffineTransform.TYPE_MASK_SCALE) != 0) {

if((at.getType() & AffineTransform.TYPE_MASK_SCALE) != 0)

getType() returns a mask of set bits. 

You don't want to check that SCALE is set, you want to check that ROTATION and TRANSLATE are NOT set.

Something like 

if (at.getType() & ~(TYPE_MASK_TRANSLATION | TYPE_MASK_ROTATION) == 0)) {

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

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


From prr at openjdk.java.net  Fri Jun  3 20:50:42 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 3 Jun 2022 20:50:42 GMT
Subject: RFR: 8287609: macOS: SIGSEGV at [CoreFoundation] CFArrayGetCount /
 sun.font.CFont.getTableBytesNative
In-Reply-To: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
References: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
Message-ID: <FMZogd9cf0kEuNtr7KO-Y2_Uq5rnwj0pC7mCRN-ouRA=.4e3b7a58-b760-4980-8a1a-fd701d7332ba@github.com>

On Tue, 31 May 2022 23:39:09 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

> `CTFontCopyAvailableTables` can return null, which causes subsequent call to `CFArrayGetCount` to crash with SEGFAULT, just added a null-check.

Marked as reviewed by prr (Reviewer).

oh my gosh .. it is a font designed for PRE-macOSX . meaning mac. so it is an ATM font with a resource fork and current macOS
still lets you install it which is a real surprise to me. That's why there are no tables. 
OK I can see why this fix is needed

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

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


From serb at openjdk.java.net  Fri Jun  3 21:03:31 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 3 Jun 2022 21:03:31 GMT
Subject: RFR: 8287740 NSAccessibilityShowMenuAction not working for text
 editors [v2]
In-Reply-To: <QugjB8dd7ZXTQnmHghSo6iSX4uU03uaJx_0WALVm-fU=.3bc084d0-21eb-4b29-a113-644f1ddd1e02@github.com>
References: <ih2ncVe2WAcD_nsvq0Paoik3urPoMhxwtD_2Gapgnc8=.51f59891-ce8b-4ecc-a3f1-f059abfa0e1b@github.com>
 <QugjB8dd7ZXTQnmHghSo6iSX4uU03uaJx_0WALVm-fU=.3bc084d0-21eb-4b29-a113-644f1ddd1e02@github.com>
Message-ID: <khSg_XTL19mk1Y8wRUccgUG24_Mxpzyh0VO4QSS7RHI=.f7421125-2556-42f0-8215-cdb0e0e97f04@github.com>

On Fri, 3 Jun 2022 10:35:22 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The NSAccessibilityShouMinuAction action does not show the menu for the text element. 
>> Steps to reproduce: 
>> 1. redefine the accessible context with the addition of the toggle popup action; 
>> 2. run on macOS with VoiceOver enabled; 
>> 3. try to call the context menu in the editor by pressing vo+shift+m.
>> 
>> @azuev-java please review.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Just a small nit, can we use the same style of instructions, the previous tests use a separate text to press the VO shortcuts, here it could be something like this:
>   "Turn screen reader on and press Tab to move to the text area"
>   "Perform the VO action "Open a shortcut menu" (VO+Shift+m)\n\n"

Marked as reviewed by serb (Reviewer).

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

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


From prr at openjdk.java.net  Fri Jun  3 21:17:19 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 3 Jun 2022 21:17:19 GMT
Subject: RFR: 8287102: ImageReaderSpi.canDecodeInput() for standard plugins
 should return false if a stream is too short [v2]
In-Reply-To: <B2WQkmKYOFwJdddzhBYfL7LcgJ_Dkv2K-oCjfdt3NTE=.0884a849-4552-4001-803a-533cb517d734@github.com>
References: <HWo4z7xc-wtfCRJpDkzAJIUkxAr4geGrcQZpir1CIZo=.d2ca4cc2-946e-40a5-b733-543856f9f6ef@github.com>
 <ydnQYmg1hUtvv2q1v36IY5y1o-oWSs7PmWVnHu8teVQ=.eb6c400b-a501-4bbd-96f8-a14fa6051bd8@github.com>
 <B2WQkmKYOFwJdddzhBYfL7LcgJ_Dkv2K-oCjfdt3NTE=.0884a849-4552-4001-803a-533cb517d734@github.com>
Message-ID: <6fem9k8EG4WVoU7XDtJUp_PWPkvpox8KlvMDqs8DgME=.5856f776-f7a0-4418-a06d-b8b3f28df3d4@github.com>

On Thu, 26 May 2022 11:43:07 GMT, Martin Desruisseaux <duke at openjdk.java.net> wrote:

> As a minor note, in `com.sun.imageio.plugins.common.ReaderUtil` class the `readMultiByteInteger(ImageInputStream)` method is used only by `WBMPImageReader`. Would it be worth to move (in a separated pull request) that method in `WBMPImageReader` for saving a few bytes in the common case where WBMP format is not used?

I'd be inclined to leave it as a common utility .. someone  else might need it in the future.

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

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


From serb at openjdk.java.net  Fri Jun  3 21:18:31 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 3 Jun 2022 21:18:31 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip
In-Reply-To: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
Message-ID: <hSDQ-CJ_WMWw5iXu0jeR9pYVXaKGmUGKGtVyBhYv9dg=.3bf56018-8021-4bd8-957b-e12d3f6977a8@github.com>

On Fri, 3 Jun 2022 15:43:39 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add try/catch clause to ignore an exception since it is harmless for we isolated
> the massge data before passing it ro processor.
> Add test case.

Probably it is better to check the data length for each sys message and discard it if the data is too small? Ignoring all possible AIOOBE  from this large method which calls many other large methods from SoftVoice/SoftTuning may hide some other bugs.

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

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


From duke at openjdk.java.net  Fri Jun  3 21:21:35 2022
From: duke at openjdk.java.net (Martin Desruisseaux)
Date: Fri, 3 Jun 2022 21:21:35 GMT
Subject: Integrated: 8287102: ImageReaderSpi.canDecodeInput() for standard
 plugins should return false if a stream is too short
In-Reply-To: <HWo4z7xc-wtfCRJpDkzAJIUkxAr4geGrcQZpir1CIZo=.d2ca4cc2-946e-40a5-b733-543856f9f6ef@github.com>
References: <HWo4z7xc-wtfCRJpDkzAJIUkxAr4geGrcQZpir1CIZo=.d2ca4cc2-946e-40a5-b733-543856f9f6ef@github.com>
Message-ID: <TCMX_3PqNAUiRAnBeFSlXU2GM-M62tF3JbRH8Q1EzAI=.5330ba0f-84d3-4464-8dae-5193f2dc66d2@github.com>

On Fri, 13 May 2022 12:23:24 GMT, Martin Desruisseaux <duke at openjdk.java.net> wrote:

> Invoking `ImageReaderSpi.canDecodeInput(Object)` with a stream having less than 8 bytes causes an `EOFException` to be thrown instead of returning `false`. This is caused by BMP, WBMP, GIF, PNG and TIFF reader implementations assuming that those bytes always exist and not checking EOF conditions. The JPEG reader is not impacted.
> 
> The `CanDecodeTest` class in this pull request reproduces the problem and verifies that the patch solves it. The changes in `canDecodeInput(Object)` method bodies are:
> 
> * Use `ImageInputStream.read()` instead of `readByte()` and check for -1 (EOF) return value.
> * Replace `ImageInputStream.readFully(byte[])` calls by a private `tryReadFully` method.

This pull request has now been integrated.

Changeset: a7e07fdb
Author:    Martin Desruisseaux <martin.desruisseaux at geomatys.com>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a7e07fdbc104f668a03d88330e30dbaeb7b43719
Stats:     150 lines in 8 files changed: 129 ins; 9 del; 12 mod

8287102: ImageReaderSpi.canDecodeInput() for standard plugins should return false if a stream is too short

Reviewed-by: prr

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

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


From prr at openjdk.java.net  Fri Jun  3 21:22:14 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 3 Jun 2022 21:22:14 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip
In-Reply-To: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
Message-ID: <1Dmfuzix9Bl_6qwPiUSwYo2t1tdaFZkbCZKUGf9tWKg=.fc928c00-b970-4a54-af9e-5bfc40941819@github.com>

On Fri, 3 Jun 2022 15:43:39 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add try/catch clause to ignore an exception since it is harmless for we isolated
> the massge data before passing it ro processor.
> Add test case.

Marked as reviewed by prr (Reviewer).

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

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


From serb at openjdk.java.net  Fri Jun  3 21:23:33 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 3 Jun 2022 21:23:33 GMT
Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray
 [v3]
In-Reply-To: <UWwEMift6h_AIxKxKymzR7Lo8bs82zDSGgsc_u-UQw4=.dedb3a0d-8cfb-4aa2-917b-8c4dbf01c239@github.com>
References: <KbpNZ7Yzxx6cUu_DQI5QawOSz2BfkC02EgzR28gUiyU=.3c2abcd2-54ba-4eea-803d-d04a611df9ed@github.com>
 <UWwEMift6h_AIxKxKymzR7Lo8bs82zDSGgsc_u-UQw4=.dedb3a0d-8cfb-4aa2-917b-8c4dbf01c239@github.com>
Message-ID: <vaUn97i5Z7iMDIiKvi_f9mAdtPUkaxcr5Rp-yOKq_gU=.dcd64c48-cb8c-4e04-bea6-bd43d9065220@github.com>

On Fri, 27 May 2022 20:48:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> **WTrayIconPeer**: removed duplicate call to `popupParent.dispose()` that might cause NPE (it looks `popupParent` cannot be `null`); organised imports.
>> 
>> **SystemTray**: removed redundant initialisers; replaced sized array with empty array in `toArray` call; dropped `newValue != null` chained with `equals`.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use method reference in setSystemTrayAccessor instead of anonymous class

Marked as reviewed by serb (Reviewer).

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

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


From smandalika at openjdk.java.net  Fri Jun  3 21:29:58 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 3 Jun 2022 21:29:58 GMT
Subject: Integrated: 8285373: Create an automated test for JDK-4702233
In-Reply-To: <zrkWQo-BoTq0XlQX_0_-CwnPIKkCge6wW8E5EqLAYRs=.2345ef0a-25eb-414c-ade6-de10d49d2bbe@github.com>
References: <zrkWQo-BoTq0XlQX_0_-CwnPIKkCge6wW8E5EqLAYRs=.2345ef0a-25eb-414c-ade6-de10d49d2bbe@github.com>
Message-ID: <KmsbwIDJ57QkrGO2pSsJLC4s4LmYMf-xW72o9_DF3VA=.b24b9ba4-7bba-4d80-82a7-dce43f76b79d@github.com>

On Thu, 21 Apr 2022 15:54:02 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create an automated test for [JDK-4702233](https://bugs.openjdk.java.net/browse/JDK-4702233)
> 
> Several new AccessibleRole and AccessibleRelation constants are needed in those classes in the java.accessibility package. These new contants codify additions made in the GNOME, Netscape, and UNO (StarOffice) accessibility APIs.
> StarOffice 6.1 and GNOME accessibility require new role, state and relation
> constants in the javax.accessibility package. The existing constants are
> inadequate for providing accessibility to StarOffice and GNOME applications
> as required by Section 508.
> 
> Solution
> --------
> Define new constants in the javax.accessibility package.
> AccessibleRelation
> AccessibleRoles
> AccessibleState
> AccessibleAction
> AccessibleContext
> 
> The test validates the public fields of the above AccessibleConstants.
> 
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

This pull request has now been integrated.

Changeset: 6f526e1b
Author:    Srinivas Mandalika <smandalika at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6f526e1bc3e0af4189fbb7d3b48d614717f266b0
Stats:     415 lines in 6 files changed: 415 ins; 0 del; 0 mod

8285373: Create an automated test for JDK-4702233

Reviewed-by: serb

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

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


From prr at openjdk.java.net  Fri Jun  3 21:32:39 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 3 Jun 2022 21:32:39 GMT
Subject: RFR: 8287761: Make the logging of J2DBench stable
In-Reply-To: <dXUeMfLx_fERRN6JpzwellzmpnZUxp6rKiRPbpRQ7ZE=.dacf83dd-b313-44f0-a7d2-224904381597@github.com>
References: <dXUeMfLx_fERRN6JpzwellzmpnZUxp6rKiRPbpRQ7ZE=.dacf83dd-b313-44f0-a7d2-224904381597@github.com>
Message-ID: <vXyCvrnx1daBsqZmfkx8WwP2-63fq9dxkAFSondLjoY=.c867e62e-4029-4ccd-be09-0673152c7a6c@github.com>

On Fri, 3 Jun 2022 05:30:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Currently, the logging of the J2DBench differs from run to run. Each time the order of the parameters is random.
> 
> For example:
> First run: `with to Default Frame, bounce, 1x1, SrcOver, ident, !extraalpha, !xormode, !clip, Default, from transvolimg translucent, !touchsrc, Nearest neighbor`
> Next run: `with SrcOver, bounce, Nearest neighbor, ident, !touchsrc, to CompatImage(Opaque), Default, 1x1, !xormode, !clip, from bmcompatimg bitmask, !extraalpha
> `
> The root cause is that the options are stored in the Hashtable and printed in the "random" order. 
> 
> The fix replaces the usage of Hashtable by the LinkedHashMap. The code is tested on jdk1.7 and -source/-target 1.4

Marked as reviewed by prr (Reviewer).

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

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


From asemenov at openjdk.java.net  Fri Jun  3 21:32:45 2022
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Fri, 3 Jun 2022 21:32:45 GMT
Subject: Integrated: 8287740 NSAccessibilityShowMenuAction not working for text
 editors
In-Reply-To: <ih2ncVe2WAcD_nsvq0Paoik3urPoMhxwtD_2Gapgnc8=.51f59891-ce8b-4ecc-a3f1-f059abfa0e1b@github.com>
References: <ih2ncVe2WAcD_nsvq0Paoik3urPoMhxwtD_2Gapgnc8=.51f59891-ce8b-4ecc-a3f1-f059abfa0e1b@github.com>
Message-ID: <UWa8m7i-gnRHlUmTRfuyxPlujMg2YQWHrFxXiy2266U=.02f973a0-1790-4f07-b139-00c54ccb4813@github.com>

On Thu, 2 Jun 2022 16:07:37 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The NSAccessibilityShouMinuAction action does not show the menu for the text element. 
> Steps to reproduce: 
> 1. redefine the accessible context with the addition of the toggle popup action; 
> 2. run on macOS with VoiceOver enabled; 
> 3. try to call the context menu in the editor by pressing vo+shift+m.
> 
> @azuev-java please review.

This pull request has now been integrated.

Changeset: b6cdfd68
Author:    Artem Semenov <asemenov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b6cdfd685d0cea308b15558e2dc607a680c89dc0
Stats:     107 lines in 2 files changed: 98 ins; 6 del; 3 mod

8287740: NSAccessibilityShowMenuAction not working for text editors

Reviewed-by: kizune, serb

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

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


From smandalika at openjdk.java.net  Fri Jun  3 21:32:54 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Fri, 3 Jun 2022 21:32:54 GMT
Subject: Integrated: 8285305: Create an automated test for JDK-4495286
In-Reply-To: <tfMcUiiqM3zbwahwkdBXMSFXcHiCqyZoRJLZgekkagQ=.5392b0b4-bd49-400a-8bf0-aef5f1354d6e@github.com>
References: <tfMcUiiqM3zbwahwkdBXMSFXcHiCqyZoRJLZgekkagQ=.5392b0b4-bd49-400a-8bf0-aef5f1354d6e@github.com>
Message-ID: <ewHpsrg9oD5tOjL6Ker-dVK-_X3h6EtO4lWjTgRVDhs=.9f9f3874-7c26-40d9-9cb7-6ff2acd6e62e@github.com>

On Thu, 21 Apr 2022 10:51:18 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create an automated test for [JDK-4495286](https://bugs.openjdk.java.net/browse/JDK-4495286)
> 
> AccessibleJTable.setAccessibleSelction should select rows/cols when cell selection.
> When cell selection is not enabled, there is no way, using
> accessibility, to select rows or columns. It seems logical that selecting a cell
> using accessibility should have the same effect as clicking on a cell with the
> mouse. That is, if row or column selection is enabled, then selecting a cell
> should instead cause the row or column to be selected.
>  The proposed test verifies that the above behavior is fixed.
> 
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (40) on windows-x64, linux-x64 and macos-x64.

This pull request has now been integrated.

Changeset: 25e9901a
Author:    Srinivas Mandalika <smandalika at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/25e9901aeacd45f8baec6d1e52a6823e7f087fa3
Stats:     173 lines in 1 file changed: 173 ins; 0 del; 0 mod

8285305: Create an automated test for JDK-4495286

Reviewed-by: serb

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

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


From serb at openjdk.java.net  Fri Jun  3 21:48:37 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 3 Jun 2022 21:48:37 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <Nes5fFygjwIKFa6lnzNk-FtIsJNTV7eu2Tu87wwKrKI=.6142730c-ff27-4800-9a3b-3651542be6e6@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
 <ms8g1-XqOxHCBTQIO8vyRbli10-TE_m1rjaJhDPf1AM=.281afbc5-bf1a-427a-9dd8-3476db10b7e1@github.com>
 <DeqLg0CSyiHoE-Ao6Ct0ii0LdAS3jpbJd48IF30Rcls=.75c71c01-8136-4d2b-9f7b-ee701a7a24db@github.com>
 <3Dse5Mi4Lsodr2ytpTSGqNaRLiUcp4928refltpwCGw=.d3c9d1e7-8954-4356-badf-dcd2f8209fbf@github.com>
 <hl8lDVSGj2qwmGkMMWQdyOPmjb7JaMQubQEHq42lndA=.9620b494-085b-4b4e-a5b1-e42a9a99061b@github.com>
 <14w5H3NqVoh17cITByBhbUSlXUvf1o6C5_te0W0KSig=.0e13f718-4ad2-4194-875b-3d8cc4f0f950@github.com>
 <kbyTvN6HV-1DIJxW56O1TRk9sBEhlUEb_ghDoSXF2Mg=.2cc95f11-bc7f-4282-af92-e9619f575895@github.com>
 <Nes5fFygjwIKFa6lnzNk-FtIsJNTV7eu2Tu87wwKrKI=.6142730c-ff27-4800-9a3b-3651542be6e6@github.com>
Message-ID: <EMnVzwnT_PlmJzvLJyfonDXzzFGnTBD018biUqIwl0o=.cbdbea2c-c0fd-4c72-a5b8-078cbb506e18@github.com>

On Fri, 3 Jun 2022 05:13:25 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>>> I still do not see a reason why we cannot request the exact size of the image from the windows, so if the small icon and the screen scale is 1.25 we can try to extract 20x20
>> 
>> Because for some files - and we can not predict which files these are - function will always return set of 16x16 and 32x32 icons - no matter what we request. For the icons that return proper sizes we do request exact sizes and use them.
>
>> But can we use it as a backup if the system does not return the expected size on the initial/current call?
> 
> No, because in case when current implementation returns bad results this function also returns incorrect results so it is hardly a backup.

> Because for some files - and we can not predict which files these are - function will always return set of 16x16 and 32x32 icons - no matter what we request. For the icons that return proper sizes we do request exact sizes and use them.

How do we request the proper size for the example above when the scale is 1.25 and the "small" image? The requested size should be 20x20 but we will request 16x16 or 32x32 and then upscale/downscale, no?

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

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


From serb at openjdk.java.net  Fri Jun  3 21:52:53 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 3 Jun 2022 21:52:53 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <EMnVzwnT_PlmJzvLJyfonDXzzFGnTBD018biUqIwl0o=.cbdbea2c-c0fd-4c72-a5b8-078cbb506e18@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
 <ms8g1-XqOxHCBTQIO8vyRbli10-TE_m1rjaJhDPf1AM=.281afbc5-bf1a-427a-9dd8-3476db10b7e1@github.com>
 <DeqLg0CSyiHoE-Ao6Ct0ii0LdAS3jpbJd48IF30Rcls=.75c71c01-8136-4d2b-9f7b-ee701a7a24db@github.com>
 <3Dse5Mi4Lsodr2ytpTSGqNaRLiUcp4928refltpwCGw=.d3c9d1e7-8954-4356-badf-dcd2f8209fbf@github.com>
 <hl8lDVSGj2qwmGkMMWQdyOPmjb7JaMQubQEHq42lndA=.9620b494-085b-4b4e-a5b1-e42a9a99061b@github.com>
 <14w5H3NqVoh17cITByBhbUSlXUvf1o6C5_te0W0KSig=.0e13f718-4ad2-4194-875b-3d8cc4f0f950@github.com>
 <kbyTvN6HV-1DIJxW56O1TRk9sBEhlUEb_ghDoSXF2Mg=.2cc95f11-bc7f-4282-af92-e9619f575895@github.com>
 <Nes5fFygjwIKFa6lnzNk-FtIsJNTV7eu2Tu87wwKrKI=.6142730c-ff27-4800-9a3b-3651542be6e6@github.com>
 <EMnVzwnT_PlmJzvLJyfonDXzzFGnTBD018biUqIwl0o=.cbdbea2c-c0fd-4c72-a5b8-078cbb506e18@github.com>
Message-ID: <vd6hL784lg90KIH5z5LqDcljCew_dC0QakUZWP-qoz8=.840cbedc-7898-4dab-ad62-24a4755c0f3c@github.com>

On Fri, 3 Jun 2022 21:46:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> But can we use it as a backup if the system does not return the expected size on the initial/current call?
>> 
>> No, because in case when current implementation returns bad results this function also returns incorrect results so it is hardly a backup.
>
>> Because for some files - and we can not predict which files these are - function will always return set of 16x16 and 32x32 icons - no matter what we request. For the icons that return proper sizes we do request exact sizes and use them.
> 
> How do we request the proper size for the example above when the scale is 1.25 and the "small" image? The requested size should be 20x20 but we will request 16x16 or 32x32 and then upscale/downscale, no?

> No, because in case when current implementation returns bad results this function also returns incorrect results so it is hardly a backup.

Are you sure? That article said the opposite and suggest to use SHDefExtractIcon if the simple extract fails. Probably we should recheck why it does not work for your old testing it seems this should be even faster since it read only one image instead of small+large.

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

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


From prr at openjdk.java.net  Fri Jun  3 22:00:39 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 3 Jun 2022 22:00:39 GMT
Subject: RFR: 8287148: Avoid redundant HashMap.containsKey calls in
 ExtendedKeyCodes.getExtendedKeyCodeForChar
In-Reply-To: <DTYBlJe3IMRnobVw1vCsNFLwd0z-gRhY6K1XyDeAS74=.6e9872b6-9020-439f-aacb-0127ffd9bcbd@github.com>
References: <DTYBlJe3IMRnobVw1vCsNFLwd0z-gRhY6K1XyDeAS74=.6e9872b6-9020-439f-aacb-0127ffd9bcbd@github.com>
Message-ID: <VQSmLhHci84evPDOtR4jDs41e4s25CYYUTuufuRvcDA=.ca4802ae-4fa1-47ca-bae7-c3a716daf640@github.com>

On Sat, 30 Apr 2022 18:58:56 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `sun.awt.ExtendedKeyCodes#regularKeyCodesMap` contains only non-null values. It means we can replace containsKey+get with get+null check.
> It's clearer and a bit faster.

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.java.net  Fri Jun  3 22:06:32 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 3 Jun 2022 22:06:32 GMT
Subject: RFR: 8286772:
 java/awt/dnd/DropTargetInInternalFrameTest/DropTargetInInternalFrameTest.html
 times out and fails in Windows [v2]
In-Reply-To: <thGtniWtm9mKXwzfB5DnnFEs_pyl2yBiCSag5tdz2XU=.5f4bd190-b333-4319-b614-8664634ad45d@github.com>
References: <cX5w-Rq6SET6AM8VbW_1bCOUgZ3dyXKayoIhaK-Gm8k=.9fb40e39-0b93-4118-b52e-c04305e3811b@github.com>
 <thGtniWtm9mKXwzfB5DnnFEs_pyl2yBiCSag5tdz2XU=.5f4bd190-b333-4319-b614-8664634ad45d@github.com>
Message-ID: <5txou_r0ig3IY-bl5q_HQF5GNW1dHgCvIiY3hSKs_PE=.ac80ac5e-a2c9-498c-aa96-a2a69102cd09@github.com>

On Thu, 2 Jun 2022 08:14:23 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> This test verifies that dragging from one InternalFrame and a drop target in another InternalFrame functions properly.
>> This fix moves an unstable closed applet based test to open regression based java test, but updated to be more comprehensive with some stabilisation improvements. The closed test was creating noise in CI as it often fails in Windows platform, especially in Windows 11.
>> 
>> Testing:
>> 1. Tested using mach5 20 times per platform and got all Pass.
>> 2. Tested using mach5 5 times specifically on Windows 11 and got all Pass.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Following the process to convert a closed test to open, created a PR in closed space and got it reviewed, now updating this open PR

Marked as reviewed by prr (Reviewer).

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

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


From jiefu at openjdk.java.net  Sat Jun  4 00:53:08 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 4 Jun 2022 00:53:08 GMT
Subject: RFR: 8287826:
 javax/accessibility/4702233/AccessiblePropertiesTest.java fails to compile
Message-ID: <43SoscLYHfNSo1xai-v8SGp-ue-IQ94yYp8HNsbhkNU=.309cdd6c-d9bc-492f-bd90-215e5eb9ea0a@github.com>

Hi all,

Please review this trivial change which fixes the compile failure of AccessiblePropertiesTest.java .
Thanks.

Best regards,
Jie

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

Commit messages:
 - 8287826: javax/accessibility/4702233/AccessiblePropertiesTest.java fails to compile

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

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


From dcubed at openjdk.java.net  Sat Jun  4 02:45:35 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 4 Jun 2022 02:45:35 GMT
Subject: RFR: 8287826:
 javax/accessibility/4702233/AccessiblePropertiesTest.java fails to compile
In-Reply-To: <43SoscLYHfNSo1xai-v8SGp-ue-IQ94yYp8HNsbhkNU=.309cdd6c-d9bc-492f-bd90-215e5eb9ea0a@github.com>
References: <43SoscLYHfNSo1xai-v8SGp-ue-IQ94yYp8HNsbhkNU=.309cdd6c-d9bc-492f-bd90-215e5eb9ea0a@github.com>
Message-ID: <ezxHUmjSLrLu0aTqsw3ENHH2SXr_fOVXtqowKTA5480=.4a2d3ddc-e5a3-4719-9631-8a1fb7380519@github.com>

On Sat, 4 Jun 2022 00:40:19 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial change which fixes the compile failure of AccessiblePropertiesTest.java .
> Thanks.
> 
> Best regards,
> Jie

Thumbs up. This is a trivial fix.

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

Marked as reviewed by dcubed (Reviewer).

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


From jiefu at openjdk.java.net  Sat Jun  4 02:54:25 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 4 Jun 2022 02:54:25 GMT
Subject: RFR: 8287826:
 javax/accessibility/4702233/AccessiblePropertiesTest.java fails to compile
In-Reply-To: <ezxHUmjSLrLu0aTqsw3ENHH2SXr_fOVXtqowKTA5480=.4a2d3ddc-e5a3-4719-9631-8a1fb7380519@github.com>
References: <43SoscLYHfNSo1xai-v8SGp-ue-IQ94yYp8HNsbhkNU=.309cdd6c-d9bc-492f-bd90-215e5eb9ea0a@github.com>
 <ezxHUmjSLrLu0aTqsw3ENHH2SXr_fOVXtqowKTA5480=.4a2d3ddc-e5a3-4719-9631-8a1fb7380519@github.com>
Message-ID: <MnRHUVWvsKhglXpMCC8MjOZydjPlrwuPL6WA3QuZtxs=.0df97129-35e2-47ca-8b01-454f05040cbc@github.com>

On Sat, 4 Jun 2022 02:42:37 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Thumbs up. This is a trivial fix.

Thanks @dcubed-ojdk for your review.

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

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


From jiefu at openjdk.java.net  Sat Jun  4 02:54:26 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 4 Jun 2022 02:54:26 GMT
Subject: Integrated: 8287826:
 javax/accessibility/4702233/AccessiblePropertiesTest.java fails to compile
In-Reply-To: <43SoscLYHfNSo1xai-v8SGp-ue-IQ94yYp8HNsbhkNU=.309cdd6c-d9bc-492f-bd90-215e5eb9ea0a@github.com>
References: <43SoscLYHfNSo1xai-v8SGp-ue-IQ94yYp8HNsbhkNU=.309cdd6c-d9bc-492f-bd90-215e5eb9ea0a@github.com>
Message-ID: <uc81lHSuEyXUvpxHApQwwFwc-LjvkBc64KNjBkEKckg=.f6ad0248-3e70-4fa7-831b-f12357beadee@github.com>

On Sat, 4 Jun 2022 00:40:19 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial change which fixes the compile failure of AccessiblePropertiesTest.java .
> Thanks.
> 
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: 005a3303
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/005a330387b8ee1179d1be31b53ea2c5d49c32f8
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8287826: javax/accessibility/4702233/AccessiblePropertiesTest.java fails to compile

Reviewed-by: dcubed

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

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


From mvs at openjdk.java.net  Sat Jun  4 03:04:33 2022
From: mvs at openjdk.java.net (Manukumar V S)
Date: Sat, 4 Jun 2022 03:04:33 GMT
Subject: Integrated: 8286772:
 java/awt/dnd/DropTargetInInternalFrameTest/DropTargetInInternalFrameTest.html
 times out and fails in Windows
In-Reply-To: <cX5w-Rq6SET6AM8VbW_1bCOUgZ3dyXKayoIhaK-Gm8k=.9fb40e39-0b93-4118-b52e-c04305e3811b@github.com>
References: <cX5w-Rq6SET6AM8VbW_1bCOUgZ3dyXKayoIhaK-Gm8k=.9fb40e39-0b93-4118-b52e-c04305e3811b@github.com>
Message-ID: <p6tBz3zWens8seZCWM2bdYQ_XV74k9X0gtIO2t7APqc=.d582f09d-ffb3-4fbf-8ad7-89bf398d5d71@github.com>

On Tue, 17 May 2022 15:52:03 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> This test verifies that dragging from one InternalFrame and a drop target in another InternalFrame functions properly.
> This fix moves an unstable closed applet based test to open regression based java test, but updated to be more comprehensive with some stabilisation improvements. The closed test was creating noise in CI as it often fails in Windows platform, especially in Windows 11.
> 
> Testing:
> 1. Tested using mach5 20 times per platform and got all Pass.
> 2. Tested using mach5 5 times specifically on Windows 11 and got all Pass.

This pull request has now been integrated.

Changeset: d76c1089
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Abdul Kolarkunnu <akolarkunnu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d76c1089efc8816c6f804b78371e62e697fc62c5
Stats:     380 lines in 1 file changed: 380 ins; 0 del; 0 mod

8286772: java/awt/dnd/DropTargetInInternalFrameTest/DropTargetInInternalFrameTest.html times out and fails in Windows

Reviewed-by: prr

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

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


From kizune at openjdk.java.net  Sat Jun  4 13:49:31 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 4 Jun 2022 13:49:31 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip
In-Reply-To: <hSDQ-CJ_WMWw5iXu0jeR9pYVXaKGmUGKGtVyBhYv9dg=.3bf56018-8021-4bd8-957b-e12d3f6977a8@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
 <hSDQ-CJ_WMWw5iXu0jeR9pYVXaKGmUGKGtVyBhYv9dg=.3bf56018-8021-4bd8-957b-e12d3f6977a8@github.com>
Message-ID: <hJKregnwC6kfeRcCw6c3OU05BSD1ets4VkR5zEbfry0=.e34f1506-f9d6-4790-b2ab-c90def1a6b69@github.com>

On Fri, 3 Jun 2022 21:15:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Probably it is better to check the data length for each sys message and discard it if the data is too small? Ignoring all possible AIOOBE from this large method which calls many other large methods from SoftVoice/SoftTuning may hide some other bugs.

No, because determining the correct length of the message will require basically to parse it all, the correct length could be  a 2 bytes or hundreds of bytes - in order to determine we have to process the message completely.

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

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


From serb at openjdk.java.net  Sat Jun  4 20:54:52 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 4 Jun 2022 20:54:52 GMT
Subject: RFR: 8287824: The MTPerLineTransformValidation tests has a typo in the
 @run tag
Message-ID: <bznH03ISadsqccOeSj8BR-oXncD2fTAGuzYTOwXESh8=.4490fbcc-f2c7-4ef9-bafa-e145baea71aa@github.com>

The typo in the  `@run` tag is fixed.

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

Commit messages:
 - 8287824: The MTPerLineTransformValidation tests has a typo in the @run tag

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

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


From serb at openjdk.java.net  Sat Jun  4 21:02:25 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 4 Jun 2022 21:02:25 GMT
Subject: RFR: 8282578: AIOOBE in javax.sound.sampled.Clip
In-Reply-To: <hJKregnwC6kfeRcCw6c3OU05BSD1ets4VkR5zEbfry0=.e34f1506-f9d6-4790-b2ab-c90def1a6b69@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
 <hSDQ-CJ_WMWw5iXu0jeR9pYVXaKGmUGKGtVyBhYv9dg=.3bf56018-8021-4bd8-957b-e12d3f6977a8@github.com>
 <hJKregnwC6kfeRcCw6c3OU05BSD1ets4VkR5zEbfry0=.e34f1506-f9d6-4790-b2ab-c90def1a6b69@github.com>
Message-ID: <HkBW-K9aJnwgjW1gZPxzXzor5h7MJP-c9KOLR_xsmG0=.45d520e9-55a2-4bd1-9306-032e5de15500@github.com>

On Sat, 4 Jun 2022 13:46:10 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> No, because determining the correct length of the message will require basically to parse it all, the correct length could be a 2 bytes or hundreds of bytes - in order to determine we have to process the message completely.

There are 64 usages of `data` in that method most of them use constants like 1/2/3 and other usages are in the loops, both can be easily checked. There is also code like ` int[] destinations = new int[(data.length - 7) / 2];` which could cause the NegativeArrayException, or probably some others. It s better to check the out of bands access before access than to have a try/catch block for 300 lines of code.

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

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


From serb at openjdk.java.net  Sat Jun  4 21:06:35 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 4 Jun 2022 21:06:35 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed
In-Reply-To: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
Message-ID: <pHVMQIlzsVw8yAxvmRUlfrJBA8woRT9CR9BcYqeiEOw=.4366ed2a-b7ff-4ac3-8073-95488f02ddaa@github.com>

On Fri, 3 Jun 2022 09:46:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test is failing in iMac CI systems owing to color difference of 1
> 
> `x 0 y 0 rgb1: fff0f0f0 rgb2: fff0eff0`
> 
> Added minor color tolerance check. CI testing is green

This test does not check the resulted color against the golden value. It validates the same area of the window which is captured twice, so even monitor color profile cannot affect it. Why do we have a difference of 1? Is it an issue in the rendering or robot?

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

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


From jsensene at gmail.com  Sun Jun  5 00:10:56 2022
From: jsensene at gmail.com (Justin Senseney)
Date: Sat, 4 Jun 2022 20:10:56 -0400
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v7]
In-Reply-To: <5X_sWM6JdbzBhbh1jHzg-03IgrQ6_A3VpudPIPdmW28=.dca81bba-fa38-4e30-bd07-860ef793155c@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <5X_sWM6JdbzBhbh1jHzg-03IgrQ6_A3VpudPIPdmW28=.dca81bba-fa38-4e30-bd07-860ef793155c@github.com>
Message-ID: <CAE8j5wsTHZtDUgpr-y0Pgpns9L6dg291V+bJjgymA6r10PVydg@mail.gmail.com>

Please unsubscribe me from your mailing list

On Sat, Jun 4, 2022, 20:01 Tejesh R <tr at openjdk.java.net> wrote:

> > Added test for checking setMargin() of JRadioButton.
>
> Tejesh R has updated the pull request incrementally with one additional
> commit since the last revision:
>
>   Removed whitespaces
>
> -------------
>
> Changes:
>   - all: https://git.openjdk.java.net/jdk/pull/8721/files
>   - new:
> https://git.openjdk.java.net/jdk/pull/8721/files/97aaa1b2..79dd0e14
>
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8721&range=06
>  - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8721&range=05-06
>
>   Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
>   Patch: https://git.openjdk.java.net/jdk/pull/8721.diff
>   Fetch: git fetch https://git.openjdk.java.net/jdk
> pull/8721/head:pull/8721
>
> PR: https://git.openjdk.java.net/jdk/pull/8721
>


From iris at openjdk.java.net  Sun Jun  5 03:14:14 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Sun, 5 Jun 2022 03:14:14 GMT
Subject: RFR: 8287824: The MTPerLineTransformValidation tests has a typo in
 the @run tag
In-Reply-To: <bznH03ISadsqccOeSj8BR-oXncD2fTAGuzYTOwXESh8=.4490fbcc-f2c7-4ef9-bafa-e145baea71aa@github.com>
References: <bznH03ISadsqccOeSj8BR-oXncD2fTAGuzYTOwXESh8=.4490fbcc-f2c7-4ef9-bafa-e145baea71aa@github.com>
Message-ID: <mSpgJZipsbD8nv-Z95sSVh0lNQyxv8328Xnwykxf5ZI=.671c75ca-1731-4b7e-9036-71a98d84c2d3@github.com>

On Sat, 4 Jun 2022 07:59:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The typo in the  `@run` tag is fixed.

Marked as reviewed by iris (Reviewer).

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

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


From duke at openjdk.java.net  Sun Jun  5 06:38:36 2022
From: duke at openjdk.java.net (Nikita Gubarkov)
Date: Sun, 5 Jun 2022 06:38:36 GMT
Subject: RFR: 8287609: macOS: SIGSEGV at [CoreFoundation] CFArrayGetCount /
 sun.font.CFont.getTableBytesNative
In-Reply-To: <FMZogd9cf0kEuNtr7KO-Y2_Uq5rnwj0pC7mCRN-ouRA=.4e3b7a58-b760-4980-8a1a-fd701d7332ba@github.com>
References: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
 <FMZogd9cf0kEuNtr7KO-Y2_Uq5rnwj0pC7mCRN-ouRA=.4e3b7a58-b760-4980-8a1a-fd701d7332ba@github.com>
Message-ID: <X93Q6dK_paO_toT0QZ353ZdQ8gifdvqNALRIpdLkxx8=.e4a32597-c676-48d8-975a-70bf72b987b9@github.com>

On Fri, 3 Jun 2022 20:48:28 GMT, Phil Race <prr at openjdk.org> wrote:

>> `CTFontCopyAvailableTables` can return null, which causes subsequent call to `CFArrayGetCount` to crash with SEGFAULT, just added a null-check.
>
> oh my gosh .. it is a font designed for PRE-macOSX . meaning mac. so it is an ATM font with a resource fork and current macOS
> still lets you install it which is a real surprise to me. That's why there are no tables. 
> OK I can see why this fix is needed

@prrace could you sponsor this, please? And also I believe this should be backported, but I don't know what the process is, where can I read about it?

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

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


From duke at openjdk.java.net  Sun Jun  5 15:38:33 2022
From: duke at openjdk.java.net (Nikita Gubarkov)
Date: Sun, 5 Jun 2022 15:38:33 GMT
Subject: Integrated: 8287609: macOS: SIGSEGV at [CoreFoundation]
 CFArrayGetCount / sun.font.CFont.getTableBytesNative
In-Reply-To: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
References: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
Message-ID: <rplwE7HXi4iaGOljqDjPB_wgE-v2rpSIvM4dLJpC73Q=.1217599e-0f06-4f4a-9be9-7029f4ebc1b6@github.com>

On Tue, 31 May 2022 23:39:09 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

> `CTFontCopyAvailableTables` can return null, which causes subsequent call to `CFArrayGetCount` to crash with SEGFAULT, just added a null-check.

This pull request has now been integrated.

Changeset: 8c460b04
Author:    Nikita Gubarkov <nikita.gubarkov at jetbrains.com>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8c460b043e1cbaf1f2d74958033bb24dea66a390
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8287609: macOS: SIGSEGV at [CoreFoundation] CFArrayGetCount / sun.font.CFont.getTableBytesNative

Reviewed-by: prr

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

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


From prr at openjdk.java.net  Sun Jun  5 15:41:35 2022
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 5 Jun 2022 15:41:35 GMT
Subject: RFR: 8287609: macOS: SIGSEGV at [CoreFoundation] CFArrayGetCount /
 sun.font.CFont.getTableBytesNative
In-Reply-To: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
References: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
Message-ID: <ALhs4xV4daoPB_o150gAHH-e7B-e0_FC65Vyp_UpnbU=.3ce981ad-0ba7-4e48-a395-537b5b3cb971@github.com>

On Tue, 31 May 2022 23:39:09 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

> `CTFontCopyAvailableTables` can return null, which causes subsequent call to `CFArrayGetCount` to crash with SEGFAULT, just added a null-check.

how do to backports is documented here : https://wiki.openjdk.java.net/display/SKARA/Backports
but the wiki is down for maintenance so you'll need to wait for it to be back up to read it.

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

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


From prr at openjdk.java.net  Sun Jun  5 15:49:20 2022
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 5 Jun 2022 15:49:20 GMT
Subject: RFR: 8287824: The MTPerLineTransformValidation tests has a typo in
 the @run tag
In-Reply-To: <bznH03ISadsqccOeSj8BR-oXncD2fTAGuzYTOwXESh8=.4490fbcc-f2c7-4ef9-bafa-e145baea71aa@github.com>
References: <bznH03ISadsqccOeSj8BR-oXncD2fTAGuzYTOwXESh8=.4490fbcc-f2c7-4ef9-bafa-e145baea71aa@github.com>
Message-ID: <7V5dFpgfAZmP8pPh0olobyGcgL4GqRNHQwshr6TgyOM=.9ee613cb-7f48-490e-8aba-1c43f1a94172@github.com>

On Sat, 4 Jun 2022 07:59:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The typo in the  `@run` tag is fixed.

Marked as reviewed by prr (Reviewer).

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

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


From jsensene at gmail.com  Mon Jun  6 02:01:22 2022
From: jsensene at gmail.com (Justin Senseney)
Date: Sun, 5 Jun 2022 22:01:22 -0400
Subject: RFR: 8287609: Add null-check for tagsArray returned from
 CTFontCopyAvailableTables
In-Reply-To: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
References: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
Message-ID: <CAE8j5wuecGg2cYAapxFm+1nk1MG4fkGPFmd773-keqc_AjS9Cw@mail.gmail.com>

Please remove me from your database

On Sat, Jun 4, 2022, 20:20 Nikita Gubarkov <duke at openjdk.java.net> wrote:

> `CTFontCopyAvailableTables` can return null, which causes subsequent call
> to `CFArrayGetCount` to crash with SEGFAULT, just added a null-check.
>
> -------------
>
> Commit messages:
>  - 8287609: Add null-check for tagsArray returned from
> CTFontCopyAvailableTables
>
> Changes: https://git.openjdk.java.net/jdk/pull/8962/files
>  Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8962&range=00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8287609
>   Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
>   Patch: https://git.openjdk.java.net/jdk/pull/8962.diff
>   Fetch: git fetch https://git.openjdk.java.net/jdk
> pull/8962/head:pull/8962
>
> PR: https://git.openjdk.java.net/jdk/pull/8962
>


From jsensene at gmail.com  Mon Jun  6 02:01:44 2022
From: jsensene at gmail.com (Justin Senseney)
Date: Sun, 5 Jun 2022 22:01:44 -0400
Subject: RFR: 8287609: Add null-check for tagsArray returned from
 CTFontCopyAvailableTables
In-Reply-To: <fV-0gOSYx5OcCaGCi-9hh6XhuAHRJ4vPyWZ6AXGfI6s=.85792cb7-ee7b-4e71-bd9a-b7671b4d1e95@github.com>
References: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
 <fV-0gOSYx5OcCaGCi-9hh6XhuAHRJ4vPyWZ6AXGfI6s=.85792cb7-ee7b-4e71-bd9a-b7671b4d1e95@github.com>
Message-ID: <CAE8j5ws0n7ij2LBQrge5QyfD=76a5_VP2sDG44WHK3RnJuLRug@mail.gmail.com>

Please remove me from your mailing list

On Sat, Jun 4, 2022, 20:12 Phil Race <prr at openjdk.java.net> wrote:

> On Tue, 31 May 2022 23:39:09 GMT, Nikita Gubarkov <duke at openjdk.java.net>
> wrote:
>
> > `CTFontCopyAvailableTables` can return null, which causes subsequent
> call to `CFArrayGetCount` to crash with SEGFAULT, just added a null-check.
>
> Where do you read it can return null ?
>
>
> https://developer.apple.com/documentation/coretext/1510774-ctfontcopyavailabletables?language=objc
>
> says nothing ..
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/8962
>


From tr at openjdk.java.net  Mon Jun  6 05:39:27 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Mon, 6 Jun 2022 05:39:27 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v8]
In-Reply-To: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
Message-ID: <NKHC0GNeHD_sdtWcwPwPFlbTdgBYkZfvHh2PHl_PhMA=.ef6f2889-b507-4b6a-8313-3e28f5042e67@github.com>

> Added test for checking setMargin() of JRadioButton.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8721/files
  - new: https://git.openjdk.java.net/jdk/pull/8721/files/79dd0e14..4440a7b2

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

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

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


From tr at openjdk.java.net  Mon Jun  6 06:08:38 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Mon, 6 Jun 2022 06:08:38 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v9]
In-Reply-To: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
Message-ID: <4OOBCQ6QrnCUrQk6yn6Jf1fPkLzskJb8YplgqjBowi0=.89377ce9-a82f-43d4-84a4-748b7b694602@github.com>

> Added test for checking setMargin() of JRadioButton.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8721/files
  - new: https://git.openjdk.java.net/jdk/pull/8721/files/4440a7b2..73e5a4b8

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

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

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


From tr at openjdk.java.net  Mon Jun  6 06:08:42 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Mon, 6 Jun 2022 06:08:42 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v7]
In-Reply-To: <gA25yYYhbfsFrl0WiiwJggW1m2jzqC1oc7LsBS9kZTM=.5dcb5dd1-6d24-4eb4-9849-4861dd2f7564@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <5X_sWM6JdbzBhbh1jHzg-03IgrQ6_A3VpudPIPdmW28=.dca81bba-fa38-4e30-bd07-860ef793155c@github.com>
 <gA25yYYhbfsFrl0WiiwJggW1m2jzqC1oc7LsBS9kZTM=.5dcb5dd1-6d24-4eb4-9849-4861dd2f7564@github.com>
Message-ID: <47_izVz7v9Tvg7E6rEKpRF5T3ZMpEyr9ohdhBvcEm7s=.faf270f9-6cf0-4712-81e9-0f7793f2ed27@github.com>

On Fri, 3 Jun 2022 18:48:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed whitespaces
>
> test/jdk/javax/swing/JRadioButton/bug4380543.java line 59:
> 
>> 57:                   Verify only with those L&F where Margin is Visible.
>> 58:                3. If Left insets(margins) appear Empty, press Fail,
>> 59:                   else press Pass.
> 
> Suggestion:
> 
>                1. Check if the Left inset(margin) is set visually
>                   similar to other three sides around Radio Button
>                    and CheckBox (insets set to 20 on all 4 sides).
>                2. Rendering depends on OS and supported Look and Feels.
>                   Verify only with those L&F where margins are visible.
>                3. If Left inset(margin) appears too small, press Fail,
>                   else press Pass.
> 
> 
> I think _left inset_ or _margin_ is better ? it's one instance.
> 
> You may want to add an additional space to all the lines without numbers to visually align the text to the start of the text after the number. I assume this is why you have an extra space before ?and?.

Done.

> test/jdk/javax/swing/JRadioButton/bug4380543.java line 83:
> 
>> 81: 
>> 82: class testFrame extends JFrame implements ActionListener {
>> 83:     public testFrame() {
> 
> Class names should start with a capital letter.

Done.

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

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


From tr at openjdk.java.net  Mon Jun  6 06:16:16 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Mon, 6 Jun 2022 06:16:16 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v7]
In-Reply-To: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
Message-ID: <TyLnxI0qCISl-XXs4NnzZRzNM-HifZabEVtN1yDk_tQ=.9bde8b5b-5ab1-472d-99c8-8c1fddbba111@github.com>

> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8830/files
  - new: https://git.openjdk.java.net/jdk/pull/8830/files/391e49f1..ee0a1dca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8830&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8830&range=05-06

  Stats: 26 lines in 1 file changed: 6 ins; 6 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8830.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8830/head:pull/8830

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


From psadhukhan at openjdk.java.net  Mon Jun  6 06:21:46 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 6 Jun 2022 06:21:46 GMT
Subject: RFR: JDK-8287261: [macos] JList Focus Ring color doesn't follow
 Accent color changes on macOS [v2]
In-Reply-To: <Mhi36CMVtntJZOkDMIc6fCc2sy8m0X4sFIqXKye7bRs=.4c8279d5-e89c-49ee-9e4d-54da79c8700a@github.com>
References: <m7Go1P8BVJLcyEarJLHiwHUsBKeQ5GnxvHmoKYnfmXo=.8851e019-707c-455a-9a02-249ea8ab2681@github.com>
 <Mhi36CMVtntJZOkDMIc6fCc2sy8m0X4sFIqXKye7bRs=.4c8279d5-e89c-49ee-9e4d-54da79c8700a@github.com>
Message-ID: <HBKSIW9YwIjyfvvlY2582BZXArn0sLMgAzVZWjx1O80=.6994d844-ee38-42fa-a01c-8162d39a411d@github.com>

On Wed, 1 Jun 2022 19:40:34 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> With the proposed fix, JList's focus ring color follows accent color changes. Previously the focus ring for JList was not prominently visible and did not follow accent color changes.
>> 
>> While investing a similar issue related to JTable (https://github.com/openjdk/jdk/pull/7768#discussion_r839813517), it was observed that List.focusCellHighlightBorder was using the cellFocusRing color as well. This PR extends the focus ring accent color changes to JLists. 
>> 
>> Related issues: [JDK-7124282](https://bugs.openjdk.java.net/browse/JDK-7124282) , [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243)
>> 
>> ####    Summary of changes
>> 
>> -  focusCellHighlightBorder in `AquaLookAndFeel` changed which is used for cell border for lists and tables
>> -  code related to on-the-fly focus ring color refactored into a separate method (`changeFocusRingColor()`) for re-usability 
>> -  `changeFocusRingColor()` called when PropertyChangeEvent == FRAME_ACTIVE_PROPERTY and the frame gains focus, instead of calling in individual `swapSelectionColors` in `AquaFocusHandler.java`
>> - Common test added - `CellFocusRingTest`, which tests for both cases - Tables & Lists. 
>> 
>> **Before and After screenshots of JList** _(Screenshots from SwingSet2 demo)_
>> 
>> ![Screen Shot 2022-05-25 at 3 55 49 PM](https://user-images.githubusercontent.com/95945681/170382727-54ed155b-6f08-4c75-8657-89c15764e1cd.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed redundant null checks in test

In "Finder" lists, it is always gray
whereas in "Desktop and screensaver", "Extensions", "Network" lists, it follows accent color
I dont see anywhere prominent focus ring is drawn encircling the list cell in native app 
so probably we can just have our JList focused cell follow the accent color in JDK as well without any prominent ring..

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

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


From psadhukhan at openjdk.java.net  Mon Jun  6 09:50:50 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 6 Jun 2022 09:50:50 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v6]
In-Reply-To: <bY1l-V3cTfTzvkTbDCmA1BK8yOXm6EmcEvb0mSvAIVc=.7ea0dc3f-c3a5-4071-8830-797b31ba2286@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <bY1l-V3cTfTzvkTbDCmA1BK8yOXm6EmcEvb0mSvAIVc=.7ea0dc3f-c3a5-4071-8830-797b31ba2286@github.com>
Message-ID: <uvtKoH9gpLWWPWJ50yfWFp0p7T1MWHfUk9tgu7F_3fo=.bdaf38fe-e2b4-4c02-b24a-1f6ae3ef294b@github.com>

On Sat, 28 May 2022 03:41:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added UTF-8 korean fallback

I see even `Gulimche `and `Batang `are not visible without -Dfile.encoding=ko so maybe it's what is expected.

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

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


From psadhukhan at openjdk.java.net  Mon Jun  6 15:44:34 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 6 Jun 2022 15:44:34 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed [v2]
In-Reply-To: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
Message-ID: <tA6NanagDur6PgX8_CfFc2x-YgjknkKPCHJcvEmqGF0=.df8f5ac3-bdc1-488d-a79a-11dcde368be9@github.com>

> Test is failing in iMac CI systems owing to color difference of 1
> 
> `x 0 y 0 rgb1: fff0f0f0 rgb2: fff0eff0`
> 
> Added minor color tolerance check. CI testing is green

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Use RObot.createMultiResoutionCapture

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9011/files
  - new: https://git.openjdk.java.net/jdk/pull/9011/files/37b97a3d..dcc0858f

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

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

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


From psadhukhan at openjdk.java.net  Mon Jun  6 15:44:37 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 6 Jun 2022 15:44:37 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed
In-Reply-To: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
Message-ID: <6J2ZOKG-b7AMmOGiTjA8evnWaVoPMKajJviXjqWFab8=.22d7eb73-77a7-41b8-bed9-c010d188a777@github.com>

On Fri, 3 Jun 2022 09:46:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test is failing in iMac CI systems owing to color difference of 1
> 
> `x 0 y 0 rgb1: fff0f0f0 rgb2: fff0eff0`
> 
> Added minor color tolerance check. CI testing is green

Used `Robot.createMultiResolutionScreenCapture` instead of `Robot.createScreenCapture` to get proper image variant for the iMac system. 
Several iterations of the test in intended system is ok.

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

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


From azvegint at openjdk.java.net  Mon Jun  6 20:36:53 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 6 Jun 2022 20:36:53 GMT
Subject: RFR: 8273573: [macos12] ActionListenerCalledTwiceTest.java fails
 on macOS 12
In-Reply-To: <X2WbjhddX6fxvJ2fCh3UmGtqV0kmIM5qIiFrReZBTAg=.a01473a1-f119-4597-a557-2f5fcf179e8c@github.com>
References: <mx87EX5GSQH8vynwviPWaJ_Sm9-aaArJyt1pEq3zp9U=.54e10297-5a40-49d4-93ec-e2dab902b95f@github.com>
 <X2WbjhddX6fxvJ2fCh3UmGtqV0kmIM5qIiFrReZBTAg=.a01473a1-f119-4597-a557-2f5fcf179e8c@github.com>
Message-ID: <BU-mh8Zto5cLupcd9dhlGoIBI2vHAyRtWgBzi5pM6M8=.6fa9e18f-d3ec-4f02-b073-b061b4ae8f51@github.com>

On Fri, 3 Jun 2022 03:47:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This test was failing consistently on same machines and at the same time as #8532.
>> 
>> Test failure is also no longer reproducible after #8320 fix.
>> 
>> This is macOS only test, so corresponding `@requires os.family` tag was added. Testing is green.
>
> However, there are some observations in the JBS by @prrace regarding the test which have not been handled
> 
> 
> Also I noticed that the test doesn't exit. It appears that the call to
> 
> Desktop.getDesktop().setDefaultMenuBar(bar);
> 
> is effectively creating another visible window so the AWT thread doesn't exit.
> 
> Adding this line below allows the test to exit and should be added to the test
>             SwingUtilities.invokeAndWait(() -> Desktop.getDesktop().setDefaultMenuBar(null));

@prsadhuk do you have any other comments to resolve?

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

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


From dnguyen at openjdk.java.net  Mon Jun  6 20:45:46 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Mon, 6 Jun 2022 20:45:46 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v8]
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <23EzklXwXRVg1eW3r87i1NFJHvwJFxUFMujEH7N3CQw=.97ed5f39-3f0b-419d-a787-a380c95ead13@github.com>

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Changed doc text.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7446/files
  - new: https://git.openjdk.java.net/jdk/pull/7446/files/852a93f3..d2000f6a

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

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

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


From dnguyen at openjdk.java.net  Mon Jun  6 20:45:47 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Mon, 6 Jun 2022 20:45:47 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v4]
In-Reply-To: <pj2AY_45bxMDpHOaah4wEhFQLDu4iFpFxfHofNBLMCs=.9a25ac10-a5b6-414f-b7a0-9159258c37f5@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <GfNe4SPaVPHLXSdSKAQpG5niCBbh9-AA6EylBsForNQ=.7d5d28de-68db-4ab9-979c-00bffbfabe90@github.com>
 <pj2AY_45bxMDpHOaah4wEhFQLDu4iFpFxfHofNBLMCs=.9a25ac10-a5b6-414f-b7a0-9159258c37f5@github.com>
Message-ID: <AJmERiLsf08q5j8eXimP0U5dmkR-JEfEM10b0pl4jJ8=.475469c8-cc7d-4050-b052-18e1c2298b93@github.com>

On Wed, 1 Jun 2022 18:32:09 GMT, Phil Race <prr at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed print statements.
>
> src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1123:
> 
>> 1121:          */
>> 1122:         public void handleComment(char[] data, int pos) {
>> 1123:             System.out.println("HTMLEditorKit");
> 
> And this one ?

Fixed. Had some branching issues that I recently resolved. I lost track of when this was committed and had to revert back to an older commit to see this change.

> src/java.desktop/share/classes/javax/swing/text/html/parser/DocumentParser.java line 34:
> 
>> 32: import javax.swing.text.SimpleAttributeSet;
>> 33: import javax.swing.text.html.HTML;
>> 34: import javax.swing.text.html.HTMLEditorKit;
> 
> Then there's these changes. OK .. too much .. let's just revert all the files that are import only changes.

Reverted all import changes.

> test/jdk/javax/swing/text/html/parser/HtmlTagParserTest.java line 1:
> 
>> 1: import java.awt.Dimension;
> 
> where's the GPL header on this test ?

Added the header and moved the test to the HTML folder instead since I believe the process involves classes beyond just the Parser. For example, I found that the tags and unknown tags are located in the HTML class. I can move it back if it seems more appropriate since the issue requests changes to the Parser's doc only.

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

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


From dnguyen at openjdk.java.net  Mon Jun  6 20:45:48 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Mon, 6 Jun 2022 20:45:48 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v3]
In-Reply-To: <K1-HzDvH-R3UeVtkYAWAEUNdywtlQ6CuI7ubfF8Fx-8=.100cdfbd-f4a5-45ca-933f-2e242a5d944b@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <z9URv-_hXQs8mrNtl2QRzCcoe2EJ-c3SySV_Udt90hI=.df956801-b2a3-47de-b6ca-b1f6ee54c932@github.com>
 <H_-DXhYywtC68Z0J5KP3Eesx9idZMrorAWv-vAKwdvs=.f12ca7c5-d272-4ffa-b056-04b82b09d8b3@github.com>
 <K1-HzDvH-R3UeVtkYAWAEUNdywtlQ6CuI7ubfF8Fx-8=.100cdfbd-f4a5-45ca-933f-2e242a5d944b@github.com>
Message-ID: <gECCW2gmBPuaXgTdMperdZQvVqUqwqmTIp7rzEdPiH0=.4e015c96-7323-42da-b006-7025b3878ffa@github.com>

On Tue, 31 May 2022 22:53:25 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java line 73:
>> 
>>> 71:  * <p>
>>> 72:  * Unsupported tags, such as script tags, will be handled by HiddenTagView. The
>>> 73:  * tags and its contents will be displayed as editable JTextFields and JTextAreas.
>> 
>> HiddenTagView is a JDK internal class.
>> It doesn't appear anywhere in the specification of Java SE.
>> So, whatever it is you need to say, can't be written like this.
>> 
>> Also I am not sure that the PARSER has any say in the display does it ? It just hands it off to something else to decide what to do .. doesn't it ? So can it be correct to mention JTextField here ?
>> 
>> Furthermore, the mention of "editable" is pertinent.
>> I think (haven't verified) that if you are viewing a document then comments etc are hidden, but when editing it, they are visible, and that is when handleComment() matters.
>> 
>> 
>> Perhaps you want
>> Unsupported tags, such as script tags,  will be treated similarly to comments and so will be handled in the same way as these by the editor. For example it might be invisible when reviewing the document, and raw editable text when editing it.
>> 
>> You need to fact check my assumptions ..
>
> I see your points and agree that your points are valid. Parser has no part in the display and is fact handled elsewhere.
> 
> I initially had to look through and learn what each class for HTML parsing is responsible for, and Parser is meant to handle reading chars and adding the chars to a buffer to be processed elsewhere. In this case, I found the HTML contents were routed to DocumentParser. And from there, I had to trace the stack and add debugging statements to find that hidden tags were responsible for the specialized text fields and text areas that appeared. 
> 
> I'll definitely iterate on the documentation to increase clarity and remove mention of HiddenTagView.

The editor kit is responsible for delegating which tags will be displayed this way. The list of tags supported can be located in the HTML class, and it's worth noting that script tag is among the tags listed here. But, there is another list of tags in the editor kit's code which are the tags that do not have full support. Script tags are one of these tags; another example being title tags. These tags that are not fully supported, alongside unknown tags, are being passed into HiddenTagView and being displayed as such. So, I tried simplifying the doc description to state the behavior as relevant to the Parser class only. Maybe additional documentation is required in HTMLEditorKit as well?

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

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


From achung at openjdk.java.net  Mon Jun  6 20:46:03 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 6 Jun 2022 20:46:03 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v21]
In-Reply-To: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
Message-ID: <euNp0wrZUXtUM4m61GEiTkEok8f5CDRELF7yYCJWmhI=.fa2afabd-e61a-4d0c-b28c-69a76141e373@github.com>

> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

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

  skip transform is m01 or m10 is nonzero

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7449/files
  - new: https://git.openjdk.java.net/jdk/pull/7449/files/1d6ac075..8f71abac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=20
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=19-20

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

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


From serb at openjdk.java.net  Mon Jun  6 21:14:28 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 6 Jun 2022 21:14:28 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed [v2]
In-Reply-To: <tA6NanagDur6PgX8_CfFc2x-YgjknkKPCHJcvEmqGF0=.df8f5ac3-bdc1-488d-a79a-11dcde368be9@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
 <tA6NanagDur6PgX8_CfFc2x-YgjknkKPCHJcvEmqGF0=.df8f5ac3-bdc1-488d-a79a-11dcde368be9@github.com>
Message-ID: <DiaaEHludW7a2Aa3NSLZIHACxUC0hGTWWCdcRimD3VQ=.42cb8dc5-c2a9-43c9-922d-c5cc1b3b29ce@github.com>

On Mon, 6 Jun 2022 15:44:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test is failing in iMac CI systems owing to color difference of 1
>> 
>> `x 0 y 0 rgb1: fff0f0f0 rgb2: fff0eff0`
>> 
>> Added minor color tolerance check. CI testing is green
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use RObot.createMultiResoutionCapture

test/jdk/javax/swing/text/CSSBorder/6796710/bug6796710.java line 147:

> 145:         MultiResolutionImage img = robot.createMultiResolutionScreenCapture(rect);
> 146:         return (BufferedImage)img.getResolutionVariant(rect.width, rect.height);
> 147:         //return robot.createScreenCapture(rect);

Isn't the old and new code should get the same result? The old createScreenCapture always creates an image of the low dpi quality. The createMultiResolutionScreenCapture creates two images low/hi dpi, but since you request the same size "rect" the low dpi image is returned, no?

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

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


From achung at openjdk.java.net  Mon Jun  6 21:25:45 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 6 Jun 2022 21:25:45 GMT
Subject: Integrated: 8286481: Exception printed to stdout on Windows when
 storing transparent image in clipboard
In-Reply-To: <PMPU9OzvBtCWpj0uYATUGfR0raSP42yQN1yiqLutiNk=.16ea65c9-0ee7-4ca7-a52b-3c5fcba8f484@github.com>
References: <PMPU9OzvBtCWpj0uYATUGfR0raSP42yQN1yiqLutiNk=.16ea65c9-0ee7-4ca7-a52b-3c5fcba8f484@github.com>
Message-ID: <wSBf1msC521j0WvMjrBN5o5K6MNt0p_kP3C-vMByvKs=.2a3cdb65-7fca-4c97-8975-f3740309c213@github.com>

On Tue, 24 May 2022 16:54:55 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Removed stacktrace from WClipboard

This pull request has now been integrated.

Changeset: 5264881a
Author:    Alisen Chung <achung at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5264881a1528444dfefbabec6f42596810f0ce07
Stats:     7 lines in 1 file changed: 0 ins; 6 del; 1 mod

8286481: Exception printed to stdout on Windows when storing transparent image in clipboard

Reviewed-by: prr, dnguyen

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

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


From serb at openjdk.java.net  Mon Jun  6 21:28:00 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 6 Jun 2022 21:28:00 GMT
Subject: Integrated: 8287761: Make the logging of J2DBench stable
In-Reply-To: <dXUeMfLx_fERRN6JpzwellzmpnZUxp6rKiRPbpRQ7ZE=.dacf83dd-b313-44f0-a7d2-224904381597@github.com>
References: <dXUeMfLx_fERRN6JpzwellzmpnZUxp6rKiRPbpRQ7ZE=.dacf83dd-b313-44f0-a7d2-224904381597@github.com>
Message-ID: <Ja1B7eMNIyobZH92SbasfKhJRZ95QnNtSDwYvn34ing=.118cc740-32f3-468c-a52f-8edc73970dcf@github.com>

On Fri, 3 Jun 2022 05:30:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Currently, the logging of the J2DBench differs from run to run. Each time the order of the parameters is random.
> 
> For example:
> First run: `with to Default Frame, bounce, 1x1, SrcOver, ident, !extraalpha, !xormode, !clip, Default, from transvolimg translucent, !touchsrc, Nearest neighbor`
> Next run: `with SrcOver, bounce, Nearest neighbor, ident, !touchsrc, to CompatImage(Opaque), Default, 1x1, !xormode, !clip, from bmcompatimg bitmask, !extraalpha
> `
> The root cause is that the options are stored in the Hashtable and printed in the "random" order. 
> 
> The fix replaces the usage of Hashtable by the LinkedHashMap. The code is tested on jdk1.7 and -source/-target 1.4

This pull request has now been integrated.

Changeset: a277590c
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a277590c89b173fd9bc028c715564f18fe62f722
Stats:     28 lines in 2 files changed: 5 ins; 5 del; 18 mod

8287761: Make the logging of J2DBench stable

Reviewed-by: aghaisas, prr

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

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


From kizune at openjdk.java.net  Mon Jun  6 22:23:34 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 6 Jun 2022 22:23:34 GMT
Subject: RFR: 8283383: [macos] a11y : Screen magnifier shows extra characters
 (0) at the end JButton accessibility name
Message-ID: <Luft87ELZpKBREKvqL5wybzkDMkuT4f5v7E1aLhGjlE=.8d3840be-7a35-472d-b006-759402e6e3bc@github.com>

Add the accessibilityValue implementation to the affected classes to return NULL value
Reverse the default initialization of MenuItemAccessibility if no parent is specified

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

Commit messages:
 - 8283383: [macos] a11y : Screen magnifier shows extra characters (0) at the end JButton accessibility name

Changes: https://git.openjdk.java.net/jdk/pull/9044/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9044&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8283383
  Stats: 29 lines in 5 files changed: 22 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9044.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9044/head:pull/9044

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


From serb at openjdk.java.net  Mon Jun  6 22:29:15 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 6 Jun 2022 22:29:15 GMT
Subject: RFR: 8283383: [macos] a11y : Screen magnifier shows extra
 characters (0) at the end JButton accessibility name
In-Reply-To: <Luft87ELZpKBREKvqL5wybzkDMkuT4f5v7E1aLhGjlE=.8d3840be-7a35-472d-b006-759402e6e3bc@github.com>
References: <Luft87ELZpKBREKvqL5wybzkDMkuT4f5v7E1aLhGjlE=.8d3840be-7a35-472d-b006-759402e6e3bc@github.com>
Message-ID: <z63ZOp6pbpM8y3ZNOwmOjoZ0Epv6r13hXyuwsB15HmQ=.fc712f05-a33f-486a-a5a3-02c9f3c3af1a@github.com>

On Mon, 6 Jun 2022 22:14:40 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add the accessibilityValue implementation to the affected classes to return NULL value
> Reverse the default initialization of MenuItemAccessibility if no parent is specified

Marked as reviewed by serb (Reviewer).

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

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


From kizune at openjdk.java.net  Mon Jun  6 22:53:29 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 6 Jun 2022 22:53:29 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v5]
In-Reply-To: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
Message-ID: <gPhckCSfYLqj3z0YGo9YaG0wBnpCHnvDvUukGY4IDtU=.c72b20b5-3231-48b9-842f-e642b8c212e8@github.com>

> Detect the situation where we do need to perform interpolation during ImageIcon
> painting and set a hint to the rendering to perform bicubic approximation so
> image details are preserved during transition.

Alexander Zuev 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 six additional commits since the last revision:

 - - ImageIcon changes reversed
   - Removed the old test
   - Added a new windows-specific test
   - Fixed the small icon retrieval
   - If there is no exact match for requested variant create a new one from
     the closest match by scaling it with bicubic interploation
   - The new variand is cached so no real performance hit there
 - Merge remote-tracking branch 'origin/master' into JDK-8282526
 - Use small icon pointer for icons less than 24 pixels wide - this way we
   get the 16x16 icon which is better for scaling purposes.
 - Take into account scale factor;
   Create a new Graphics2D object instead of juggle the rendering hints;
 - Merge pull request #35 from azuev-java/master
   
   Merge
 - 8282526: Default icon is not painted properly
   
   Detect the situation when icon image painting requires interpolation and set the interpolation to bicubic to
   preserve the icon details as much as possible.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7805/files
  - new: https://git.openjdk.java.net/jdk/pull/7805/files/b6e099b8..bbe20e44

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

  Stats: 203856 lines in 3383 files changed: 143945 ins; 15520 del; 44391 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7805.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7805/head:pull/7805

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


From kizune at openjdk.java.net  Mon Jun  6 22:55:40 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 6 Jun 2022 22:55:40 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
Message-ID: <5TQwHRdWYkstuTYOtDyzJsbFLIAl0WNppp6COIVUSKI=.8869e869-fbe6-46ae-bb55-e6c0aa6b5db9@github.com>

On Fri, 27 May 2022 18:02:51 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Detect the situation where we do need to perform interpolation during ImageIcon
>> painting and set a hint to the rendering to perform bicubic approximation so
>> image details are preserved during transition.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use small icon pointer for icons less than 24 pixels wide - this way we
>   get the 16x16 icon which is better for scaling purposes.

Here, in the name of resolving this issue finally i have reverted the ImageIcon changes, instead i added some code that creates the properly scaled version of icon when requested variant is not available. Plus i have fixed the small icon retrieval so it is not an issue anymore.

I am not going trough all the experiments with the SHDefExtractIcon  again - at least not in this pull request. I checked and there is no performance impact at all from the latest changes on the 100% scaled screens due to the extracting an additional icon - looks like Windows extracts it anyways even if we specify null as a icon information reference - it just does not pass it down.

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

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


From serb at openjdk.java.net  Mon Jun  6 23:21:59 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 6 Jun 2022 23:21:59 GMT
Subject: Integrated: 8287824: The MTPerLineTransformValidation tests has a typo
 in the @run tag
In-Reply-To: <bznH03ISadsqccOeSj8BR-oXncD2fTAGuzYTOwXESh8=.4490fbcc-f2c7-4ef9-bafa-e145baea71aa@github.com>
References: <bznH03ISadsqccOeSj8BR-oXncD2fTAGuzYTOwXESh8=.4490fbcc-f2c7-4ef9-bafa-e145baea71aa@github.com>
Message-ID: <-jGH1Kq8DZ3AJsu66ZiWvFTyGhLuiW-DKgHeHh6qNoI=.cd134fef-7408-4105-8580-52d5d20402b2@github.com>

On Sat, 4 Jun 2022 07:59:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The typo in the  `@run` tag is fixed.

This pull request has now been integrated.

Changeset: 645be42f
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/645be42f76b8983a9096ed90caa70b5c59dd822c
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8287824: The MTPerLineTransformValidation tests has a typo in the @run tag

Reviewed-by: iris, prr

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

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


From kizune at openjdk.java.net  Mon Jun  6 23:47:15 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 6 Jun 2022 23:47:15 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v6]
In-Reply-To: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
Message-ID: <Ynva90EcdSNf7EyAxZorJNsbqjqpYZjyggv2MOPlK10=.4478324f-75ac-4b52-9d6a-695dbae8f311@github.com>

> Detect the situation where we do need to perform interpolation during ImageIcon
> painting and set a hint to the rendering to perform bicubic approximation so
> image details are preserved during transition.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Fix the line ends

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7805/files
  - new: https://git.openjdk.java.net/jdk/pull/7805/files/bbe20e44..3d177fea

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

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

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


From serb at openjdk.java.net  Tue Jun  7 05:19:39 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 7 Jun 2022 05:19:39 GMT
Subject: RFR: 8287876: The recently de-problemlisted TestTitledBorderLeak test
 is unstable
Message-ID: <Nchq_TbqFJEaKYS_lmFcqQwrXuOJHw2q9li8Rte9fPQ=.25d61d35-bb71-4be2-ba07-25163d0c8502@github.com>

This is an update of the test which was de-problemlisted [here](https://github.com/openjdk/jdk/pull/8450).

Looks like the initial root cause of the issue was related to the last disposed frame which for some reason was not deleted from the memory, for that issue, the [next](https://bugs.openjdk.org/browse/JDK-8287707) bug was reported.
But that change also replaced the usage of weak references by the Runtime.getRuntime().freeMemory() which is not stable enough to verify the leak - its return values vary a lot.

This change returns the usage of weak references and tests only one instance of TitledBorder which is enough to verify the old [bug](https://bugs.openjdk.org/browse/JDK-8204963).

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

Commit messages:
 - Update TestTitledBorderLeak.java
 - 8287876: The recently de-problemlisted TestTitledBorderLeak test is unstable

Changes: https://git.openjdk.java.net/jdk/pull/9051/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9051&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287876
  Stats: 37 lines in 1 file changed: 7 ins; 6 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9051.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9051/head:pull/9051

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


From psadhukhan at openjdk.java.net  Tue Jun  7 07:45:10 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 7 Jun 2022 07:45:10 GMT
Subject: RFR: 8273573: [macos12] ActionListenerCalledTwiceTest.java fails
 on macOS 12 [v2]
In-Reply-To: <RpLJZluogF3Z0CgEFDbs5DvAfsz20CRsCOkpvZ4_o00=.2dcccd3e-c51c-4e1d-9a91-888dddeba7ea@github.com>
References: <mx87EX5GSQH8vynwviPWaJ_Sm9-aaArJyt1pEq3zp9U=.54e10297-5a40-49d4-93ec-e2dab902b95f@github.com>
 <RpLJZluogF3Z0CgEFDbs5DvAfsz20CRsCOkpvZ4_o00=.2dcccd3e-c51c-4e1d-9a91-888dddeba7ea@github.com>
Message-ID: <wzu9pImlKXT1kag5GfCDdsfWHscH1HHBRRTOq52az3Q=.5c55a664-02ee-47e1-9b0c-68c1459a6831@github.com>

On Fri, 3 Jun 2022 10:06:21 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This test was failing consistently on same machines and at the same time as #8532.
>> 
>> Test failure is also no longer reproducible after #8320 fix.
>> 
>> This is macOS only test, so corresponding `@requires os.family` tag was added. Testing is green.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up

I thought I already approved..

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

Marked as reviewed by psadhukhan (Reviewer).

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


From psadhukhan at openjdk.java.net  Tue Jun  7 07:49:14 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 7 Jun 2022 07:49:14 GMT
Subject: RFR: 8287876: The recently de-problemlisted TestTitledBorderLeak
 test is unstable
In-Reply-To: <Nchq_TbqFJEaKYS_lmFcqQwrXuOJHw2q9li8Rte9fPQ=.25d61d35-bb71-4be2-ba07-25163d0c8502@github.com>
References: <Nchq_TbqFJEaKYS_lmFcqQwrXuOJHw2q9li8Rte9fPQ=.25d61d35-bb71-4be2-ba07-25163d0c8502@github.com>
Message-ID: <8D-1Utwpuzg037hn3MkQBlD2JNQdDBNfNSjMRD93jtk=.cac32941-edad-4664-a5d3-69f6db9cb9e0@github.com>

On Tue, 7 Jun 2022 04:15:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is an update of the test which was de-problemlisted [here](https://github.com/openjdk/jdk/pull/8450).
> 
> Looks like the initial root cause of the issue was related to the last disposed frame which for some reason was not deleted from the memory, for that issue, the [next](https://bugs.openjdk.org/browse/JDK-8287707) bug was reported.
> But that change also replaced the usage of weak references by the Runtime.getRuntime().freeMemory() which is not stable enough to verify the leak - its return values vary a lot.
> 
> This change returns the usage of weak references and tests only one instance of TitledBorder which is enough to verify the old [bug](https://bugs.openjdk.org/browse/JDK-8204963).

Marked as reviewed by psadhukhan (Reviewer).

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

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


From psadhukhan at openjdk.java.net  Tue Jun  7 09:04:06 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 7 Jun 2022 09:04:06 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed [v2]
In-Reply-To: <DiaaEHludW7a2Aa3NSLZIHACxUC0hGTWWCdcRimD3VQ=.42cb8dc5-c2a9-43c9-922d-c5cc1b3b29ce@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
 <tA6NanagDur6PgX8_CfFc2x-YgjknkKPCHJcvEmqGF0=.df8f5ac3-bdc1-488d-a79a-11dcde368be9@github.com>
 <DiaaEHludW7a2Aa3NSLZIHACxUC0hGTWWCdcRimD3VQ=.42cb8dc5-c2a9-43c9-922d-c5cc1b3b29ce@github.com>
Message-ID: <ktVuNTIc6nLToUQ_l5AzNF99gWK--71qUQDK3OVwHlo=.2e927921-6504-4f86-86b3-92fba42e7bc5@github.com>

On Mon, 6 Jun 2022 21:11:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use RObot.createMultiResoutionCapture
>
> test/jdk/javax/swing/text/CSSBorder/6796710/bug6796710.java line 147:
> 
>> 145:         MultiResolutionImage img = robot.createMultiResolutionScreenCapture(rect);
>> 146:         return (BufferedImage)img.getResolutionVariant(rect.width, rect.height);
>> 147:         //return robot.createScreenCapture(rect);
> 
> Isn't the old and new code should get the same result? The old createScreenCapture always creates an image of the low dpi quality. The createMultiResolutionScreenCapture creates two images low/hi dpi, but since you request the same size "rect" the low dpi image is returned, no?

Maybe it's different in iMac systems..I dont have access to this system to analyse further nor do I have much knowledge on this 2D/awt multiresolution image side of things..

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

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


From alexey.ivanov at oracle.com  Tue Jun  7 10:41:47 2022
From: alexey.ivanov at oracle.com (Aleksei Ivanov)
Date: Tue, 7 Jun 2022 11:41:47 +0100
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v7]
In-Reply-To: <CAE8j5wsTHZtDUgpr-y0Pgpns9L6dg291V+bJjgymA6r10PVydg@mail.gmail.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <5X_sWM6JdbzBhbh1jHzg-03IgrQ6_A3VpudPIPdmW28=.dca81bba-fa38-4e30-bd07-860ef793155c@github.com>
 <CAE8j5wsTHZtDUgpr-y0Pgpns9L6dg291V+bJjgymA6r10PVydg@mail.gmail.com>
Message-ID: <64d22e74-9627-07b1-7bf5-39b12d22cc19@oracle.com>

Hi Justin,

To unsubscribe from any OpenJDK mailing lists, go to its page; for 
client-libs-dev, go to:

https://mail.openjdk.java.net/mailman/listinfo/client-libs-dev

Scroll to the bottom of the page, enter your email address in the 
section "To unsubscribe from client-libs-dev?" and click "Unsubscribe or 
edit options". Follow the instructions in the message you receive.

On 05/06/2022 01:10, Justin Senseney wrote:
> Please unsubscribe me from your mailing list
-- 
Regards,
Alexey


From aivanov at openjdk.java.net  Tue Jun  7 10:50:23 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Jun 2022 10:50:23 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v9]
In-Reply-To: <4OOBCQ6QrnCUrQk6yn6Jf1fPkLzskJb8YplgqjBowi0=.89377ce9-a82f-43d4-84a4-748b7b694602@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <4OOBCQ6QrnCUrQk6yn6Jf1fPkLzskJb8YplgqjBowi0=.89377ce9-a82f-43d4-84a4-748b7b694602@github.com>
Message-ID: <me-dtjh0QjFUZky-yVb5nieASMz7ZjehXB9Yo4DRxd8=.212c1976-ca13-436f-8323-71f133582aba@github.com>

On Mon, 6 Jun 2022 06:08:38 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Added test for checking setMargin() of JRadioButton.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JRadioButton/bug4380543.java line 58:

> 56:                2. Rendering depends on OS and supported Look and Feels.
> 57:                   Verify only with those L&F where margins are visible.
> 58:                3. If Left inset(margin) appear too small, press Fail,

Suggestion:

               3. If Left inset(margin) appears too small, press Fail,

test/jdk/javax/swing/JRadioButton/bug4380543.java line 72:

> 70:                     //Adding the Test Frame to handle dispose
> 71:                     passFailJFrame.addTestFrame(testObj);
> 72:                     passFailJFrame.positionTestFrame(testObj, PassFailJFrame.Position.HORIZONTAL);

This was correct: you're calling static methods; such methods should not be called _via an instance variable_ but via the class name. Alternatively, you can static-import these methods.

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

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


From tr at openjdk.java.net  Tue Jun  7 11:09:54 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Tue, 7 Jun 2022 11:09:54 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v9]
In-Reply-To: <me-dtjh0QjFUZky-yVb5nieASMz7ZjehXB9Yo4DRxd8=.212c1976-ca13-436f-8323-71f133582aba@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <4OOBCQ6QrnCUrQk6yn6Jf1fPkLzskJb8YplgqjBowi0=.89377ce9-a82f-43d4-84a4-748b7b694602@github.com>
 <me-dtjh0QjFUZky-yVb5nieASMz7ZjehXB9Yo4DRxd8=.212c1976-ca13-436f-8323-71f133582aba@github.com>
Message-ID: <jsb51Z7kIBHAB6zVWHHLjWbhK7eDW93J3p3JbSI8lRY=.7b86534b-519e-4f9f-8b6c-5b487c3da76a@github.com>

On Tue, 7 Jun 2022 10:47:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> test/jdk/javax/swing/JRadioButton/bug4380543.java line 72:
> 
>> 70:                     //Adding the Test Frame to handle dispose
>> 71:                     passFailJFrame.addTestFrame(testObj);
>> 72:                     passFailJFrame.positionTestFrame(testObj, PassFailJFrame.Position.HORIZONTAL);
> 
> This was correct: you're calling static methods; such methods should not be called _via an instance variable_ but via the class name. Alternatively, you can static-import these methods.

I think it wouldn't make any difference calling static methods via an instance variable or directly with class name.

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

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


From tr at openjdk.java.net  Tue Jun  7 11:19:10 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Tue, 7 Jun 2022 11:19:10 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v10]
In-Reply-To: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
Message-ID: <bJiTUCROYh6PFBP1tXi9fj0Hm5ZGJMRpjGrvXZXWk8E=.1e39cce5-d0c9-4fed-b291-f3be4a08fb84@github.com>

> Added test for checking setMargin() of JRadioButton.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8721/files
  - new: https://git.openjdk.java.net/jdk/pull/8721/files/73e5a4b8..96cb967a

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

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

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


From tr at openjdk.java.net  Tue Jun  7 11:19:14 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Tue, 7 Jun 2022 11:19:14 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v9]
In-Reply-To: <me-dtjh0QjFUZky-yVb5nieASMz7ZjehXB9Yo4DRxd8=.212c1976-ca13-436f-8323-71f133582aba@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <4OOBCQ6QrnCUrQk6yn6Jf1fPkLzskJb8YplgqjBowi0=.89377ce9-a82f-43d4-84a4-748b7b694602@github.com>
 <me-dtjh0QjFUZky-yVb5nieASMz7ZjehXB9Yo4DRxd8=.212c1976-ca13-436f-8323-71f133582aba@github.com>
Message-ID: <Ko7necSHbBzzdzAP-oPc8UpFZGga4LK5ETAX_wN5sdQ=.2cf5bd53-144a-4f3c-9140-4fa662b9e90d@github.com>

On Tue, 7 Jun 2022 10:46:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> test/jdk/javax/swing/JRadioButton/bug4380543.java line 58:
> 
>> 56:                2. Rendering depends on OS and supported Look and Feels.
>> 57:                   Verify only with those L&F where margins are visible.
>> 58:                3. If Left inset(margin) appear too small, press Fail,
> 
> Suggestion:
> 
>                3. If Left inset(margin) appears too small, press Fail,

Updated.

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

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


From aivanov at openjdk.java.net  Tue Jun  7 11:19:16 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Jun 2022 11:19:16 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v9]
In-Reply-To: <jsb51Z7kIBHAB6zVWHHLjWbhK7eDW93J3p3JbSI8lRY=.7b86534b-519e-4f9f-8b6c-5b487c3da76a@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <4OOBCQ6QrnCUrQk6yn6Jf1fPkLzskJb8YplgqjBowi0=.89377ce9-a82f-43d4-84a4-748b7b694602@github.com>
 <me-dtjh0QjFUZky-yVb5nieASMz7ZjehXB9Yo4DRxd8=.212c1976-ca13-436f-8323-71f133582aba@github.com>
 <jsb51Z7kIBHAB6zVWHHLjWbhK7eDW93J3p3JbSI8lRY=.7b86534b-519e-4f9f-8b6c-5b487c3da76a@github.com>
Message-ID: <9CE5QA5NON4uk4Gl-vI2h6h2Al5BQAxaCgKcnhlcTSw=.e930f390-54bb-4f98-9ed7-911a27cd271c@github.com>

On Tue, 7 Jun 2022 11:06:06 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/javax/swing/JRadioButton/bug4380543.java line 72:
>> 
>>> 70:                     //Adding the Test Frame to handle dispose
>>> 71:                     passFailJFrame.addTestFrame(testObj);
>>> 72:                     passFailJFrame.positionTestFrame(testObj, PassFailJFrame.Position.HORIZONTAL);
>> 
>> This was correct: you're calling static methods; such methods should not be called _via an instance variable_ but via the class name. Alternatively, you can static-import these methods.
>
> I think it wouldn't make any difference calling static methods via an instance variable or directly with class name.

Yes, the same method would be called. Yet the difference is in the semantics: the instance variable isn't used when calling a static method, it can be null and it doesn't throw NullPointerException in this case.

The IDE raises a warning for such a usage. _You should use class name when calling static methods._ It's just cleaner: the reader would see right away it's a static method (without relying on the IDE syntax highlighting) rather than an instance method.

Please revert these two lines to using the class name to call the static methods.

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

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


From tr at openjdk.java.net  Tue Jun  7 11:19:16 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Tue, 7 Jun 2022 11:19:16 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v9]
In-Reply-To: <9CE5QA5NON4uk4Gl-vI2h6h2Al5BQAxaCgKcnhlcTSw=.e930f390-54bb-4f98-9ed7-911a27cd271c@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <4OOBCQ6QrnCUrQk6yn6Jf1fPkLzskJb8YplgqjBowi0=.89377ce9-a82f-43d4-84a4-748b7b694602@github.com>
 <me-dtjh0QjFUZky-yVb5nieASMz7ZjehXB9Yo4DRxd8=.212c1976-ca13-436f-8323-71f133582aba@github.com>
 <jsb51Z7kIBHAB6zVWHHLjWbhK7eDW93J3p3JbSI8lRY=.7b86534b-519e-4f9f-8b6c-5b487c3da76a@github.com>
 <9CE5QA5NON4uk4Gl-vI2h6h2Al5BQAxaCgKcnhlcTSw=.e930f390-54bb-4f98-9ed7-911a27cd271c@github.com>
Message-ID: <AMLldO6vcKFJjR02fX7oVcmVsDsd34pZg25907SVyQg=.28591d25-8d93-4692-83f2-acdfff06d5ae@github.com>

On Tue, 7 Jun 2022 11:11:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I think it wouldn't make any difference calling static methods via an instance variable or directly with class name.
>
> Yes, the same method would be called. Yet the difference is in the semantics: the instance variable isn't used when calling a static method, it can be null and it doesn't throw NullPointerException in this case.
> 
> The IDE raises a warning for such a usage. _You should use class name when calling static methods._ It's just cleaner: the reader would see right away it's a static method (without relying on the IDE syntax highlighting) rather than an instance method.
> 
> Please revert these two lines to using the class name to call the static methods.

Yeah sure, updated.

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

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


From serb at openjdk.java.net  Tue Jun  7 11:36:52 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 7 Jun 2022 11:36:52 GMT
Subject: RFR: 8287876: The recently de-problemlisted TestTitledBorderLeak
 test is unstable [v2]
In-Reply-To: <Nchq_TbqFJEaKYS_lmFcqQwrXuOJHw2q9li8Rte9fPQ=.25d61d35-bb71-4be2-ba07-25163d0c8502@github.com>
References: <Nchq_TbqFJEaKYS_lmFcqQwrXuOJHw2q9li8Rte9fPQ=.25d61d35-bb71-4be2-ba07-25163d0c8502@github.com>
Message-ID: <eCcO4tClD2CMx-hFM0Voz2xAw9vRnC7cWXFy_OqHtnw=.2e9a776d-e393-487d-8bd6-0f7275753237@github.com>

> This is an update of the test which was de-problemlisted [here](https://github.com/openjdk/jdk/pull/8450).
> 
> Looks like the initial root cause of the issue was related to the last disposed frame which for some reason was not deleted from the memory, for that issue, the [next](https://bugs.openjdk.org/browse/JDK-8287707) bug was reported.
> But that change also replaced the usage of weak references by the Runtime.getRuntime().freeMemory() which is not stable enough to verify the leak - its return values vary a lot.
> 
> This change returns the usage of weak references and tests only one instance of TitledBorder which is enough to verify the old [bug](https://bugs.openjdk.org/browse/JDK-8204963).

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  Smaller version

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9051/files
  - new: https://git.openjdk.java.net/jdk/pull/9051/files/da1a82c9..125bf43d

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

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

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


From serb at openjdk.java.net  Tue Jun  7 11:40:11 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 7 Jun 2022 11:40:11 GMT
Subject: RFR: 8287876: The recently de-problemlisted TestTitledBorderLeak
 test is unstable
In-Reply-To: <Nchq_TbqFJEaKYS_lmFcqQwrXuOJHw2q9li8Rte9fPQ=.25d61d35-bb71-4be2-ba07-25163d0c8502@github.com>
References: <Nchq_TbqFJEaKYS_lmFcqQwrXuOJHw2q9li8Rte9fPQ=.25d61d35-bb71-4be2-ba07-25163d0c8502@github.com>
Message-ID: <m8qzVB2mSIB4d_0fitM4JLa9Zg4FziKlIxP7t0BnjvI=.24e80cb4-2f37-4ff1-80e0-27a3db9b709b@github.com>

On Tue, 7 Jun 2022 04:15:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is an update of the test which was de-problemlisted [here](https://github.com/openjdk/jdk/pull/8450).
> 
> Looks like the initial root cause of the issue was related to the last disposed frame which for some reason was not deleted from the memory, for that issue, the [next](https://bugs.openjdk.org/browse/JDK-8287707) bug was reported.
> But that change also replaced the usage of weak references by the Runtime.getRuntime().freeMemory() which is not stable enough to verify the leak - its return values vary a lot.
> 
> This change returns the usage of weak references and tests only one instance of TitledBorder which is enough to verify the old [bug](https://bugs.openjdk.org/browse/JDK-8204963).

I have found that the simpler version of the test can be used to verify that old bug. the patch is updated.

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

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


From aivanov at openjdk.java.net  Tue Jun  7 11:47:27 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Jun 2022 11:47:27 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v7]
In-Reply-To: <TyLnxI0qCISl-XXs4NnzZRzNM-HifZabEVtN1yDk_tQ=.9bde8b5b-5ab1-472d-99c8-8c1fddbba111@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <TyLnxI0qCISl-XXs4NnzZRzNM-HifZabEVtN1yDk_tQ=.9bde8b5b-5ab1-472d-99c8-8c1fddbba111@github.com>
Message-ID: <weJSinXPDfJybJkmjGTOuY27jkY_z0G_SIJuvOdRwqs=.42d62b33-c6f2-4f23-a102-2a4f47f10b2a@github.com>

On Mon, 6 Jun 2022 06:16:16 GMT, Tejesh R <tr at openjdk.org> wrote:

>> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JTableHeader/TableRendererTest.java line 31:

> 29:    @summary Test to check if table is printed without NPE
> 30:    @run main TableRendererTest
> 31: */

Could you move the test tags below the imports?

Most new tests follow this style and I find it more convenient when viewing the test source in the IDE, the test tags aren't collapsed this way.

Please add asterisk at the beginning of each line. It should look like this:


/*
 * @test
 * @bug
 */


To follow the common style of Java block comments and test tags in the majority of files.

Please do not use `/**` as the first comment: it's not a Javadoc comment to avoid warning about the unknown javadoc tags.

test/jdk/javax/swing/JTableHeader/TableRendererTest.java line 47:

> 45: import javax.swing.table.TableCellRenderer;
> 46: 
> 47: public class TableRendererTest{

I suggest making the name more specific: `TableHeaderRendererTest` or `TableHeaderRendererNPETest`.

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

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


From tr at openjdk.java.net  Tue Jun  7 11:58:01 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Tue, 7 Jun 2022 11:58:01 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v8]
In-Reply-To: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
Message-ID: <0vsbn9QEPTr3O4e2thstKM8odT046_I55Fb9SsdbYHQ=.2077175e-36a8-4b27-8bbd-0692698f0a78@github.com>

> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments and File name changed

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8830/files
  - new: https://git.openjdk.java.net/jdk/pull/8830/files/ee0a1dca..89b4cadb

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

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

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


From tr at openjdk.java.net  Tue Jun  7 12:01:06 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Tue, 7 Jun 2022 12:01:06 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v7]
In-Reply-To: <weJSinXPDfJybJkmjGTOuY27jkY_z0G_SIJuvOdRwqs=.42d62b33-c6f2-4f23-a102-2a4f47f10b2a@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <TyLnxI0qCISl-XXs4NnzZRzNM-HifZabEVtN1yDk_tQ=.9bde8b5b-5ab1-472d-99c8-8c1fddbba111@github.com>
 <weJSinXPDfJybJkmjGTOuY27jkY_z0G_SIJuvOdRwqs=.42d62b33-c6f2-4f23-a102-2a4f47f10b2a@github.com>
Message-ID: <42hBfmtBK9lnQia_cNqCyeHx_rJPhZwtcSqVzEtXHOg=.944be4ff-08da-4928-80cf-742c99746750@github.com>

On Tue, 7 Jun 2022 11:42:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> test/jdk/javax/swing/JTableHeader/TableRendererTest.java line 31:
> 
>> 29:    @summary Test to check if table is printed without NPE
>> 30:    @run main TableRendererTest
>> 31: */
> 
> Could you move the test tags below the imports?
> 
> Most new tests follow this style and I find it more convenient when viewing the test source in the IDE, the test tags aren't collapsed this way.
> 
> Please add asterisk at the beginning of each line. It should look like this:
> 
> 
> /*
>  * @test
>  * @bug
>  */
> 
> 
> To follow the common style of Java block comments and test tags in the majority of files.
> 
> Please do not use `/**` as the first comment: it's not a Javadoc comment to avoid warning about the unknown javadoc tags.

Updated.

> test/jdk/javax/swing/JTableHeader/TableRendererTest.java line 47:
> 
>> 45: import javax.swing.table.TableCellRenderer;
>> 46: 
>> 47: public class TableRendererTest{
> 
> I suggest making the name more specific: `TableHeaderRendererTest` or `TableHeaderRendererNPETest`.

Updated.

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

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


From aivanov at openjdk.java.net  Tue Jun  7 12:31:16 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Jun 2022 12:31:16 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v10]
In-Reply-To: <bJiTUCROYh6PFBP1tXi9fj0Hm5ZGJMRpjGrvXZXWk8E=.1e39cce5-d0c9-4fed-b291-f3be4a08fb84@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <bJiTUCROYh6PFBP1tXi9fj0Hm5ZGJMRpjGrvXZXWk8E=.1e39cce5-d0c9-4fed-b291-f3be4a08fb84@github.com>
Message-ID: <eLwJtd9cyZ8wbzLao0d8EGlD8FVWxidt_v9oF6lfoDM=.66456be8-0d93-4360-96e2-eba3cdd1bf4f@github.com>

On Tue, 7 Jun 2022 11:19:10 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Added test for checking setMargin() of JRadioButton.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/JRadioButton/bug4380543.java line 58:

> 56:                2. Rendering depends on OS and supported Look and Feels.
> 57:                   Verify only with those L&F where margins are visible.
> 58:                3. If Left inset(margin) appears too small, press Fail,

Suggestion:

               3. If the Left inset(margin) appears too small, press Fail,

I guess the article is missing here.

It may be missing in the first item too: ??around *the* Radio Button??

test/jdk/javax/swing/JRadioButton/bug4380543.java line 94:

> 92:         JRadioButton rb  = new JRadioButton("JRadioButton");
> 93:         rb.setMargin(new Insets(20, 20, 20, 20));
> 94:         rb.setBackground(Color.green);

In the new code, we should use uppercase color constants, I guess.

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

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


From aivanov at openjdk.java.net  Tue Jun  7 12:48:08 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Jun 2022 12:48:08 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v8]
In-Reply-To: <0vsbn9QEPTr3O4e2thstKM8odT046_I55Fb9SsdbYHQ=.2077175e-36a8-4b27-8bbd-0692698f0a78@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <0vsbn9QEPTr3O4e2thstKM8odT046_I55Fb9SsdbYHQ=.2077175e-36a8-4b27-8bbd-0692698f0a78@github.com>
Message-ID: <ILMGG3F17K6uE0m9_hqCtsUQssZ23UOc1dHKhwfDFO4=.5b601a40-3f83-4e51-bf9c-5cb3ed4aaaa4@github.com>

On Tue, 7 Jun 2022 11:58:01 GMT, Tejesh R <tr at openjdk.org> wrote:

>> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments and File name changed

It looks good now.

What's left is to ensure it passes when run headless. It should just work on Windows.

Can we address @mrserb's concern and extend the test be run on other platforms and with all L&Fs?

test/jdk/javax/swing/JTableHeader/TableHeaderRendererTest.java line 40:

> 38:  * @bug 6429812
> 39:  * @requires (os.family == "windows")
> 40:  * @summary Test to check if table is printed without NPE

Suggestion:

 * @summary Test to check if table header is painted without NPE

Nothing is printed in this test case.

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

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


From tr at openjdk.java.net  Tue Jun  7 13:34:21 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Tue, 7 Jun 2022 13:34:21 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v8]
In-Reply-To: <ILMGG3F17K6uE0m9_hqCtsUQssZ23UOc1dHKhwfDFO4=.5b601a40-3f83-4e51-bf9c-5cb3ed4aaaa4@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <0vsbn9QEPTr3O4e2thstKM8odT046_I55Fb9SsdbYHQ=.2077175e-36a8-4b27-8bbd-0692698f0a78@github.com>
 <ILMGG3F17K6uE0m9_hqCtsUQssZ23UOc1dHKhwfDFO4=.5b601a40-3f83-4e51-bf9c-5cb3ed4aaaa4@github.com>
Message-ID: <Yn3MHl6YUT2rrHIybv-C5jlcIl0Up_F39TMPBjFZImA=.e568d055-3339-4258-8aae-0912fa2cc526@github.com>

On Tue, 7 Jun 2022 12:44:43 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> It looks good now.
> 
> What's left is to ensure it passes when run headless. It should just work on Windows.
> 
> Can we address @mrserb's concern and extend the test be run on other platforms and with all L&Fs?

Yeah sure.

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

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


From tr at openjdk.java.net  Tue Jun  7 13:40:57 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Tue, 7 Jun 2022 13:40:57 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v11]
In-Reply-To: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
Message-ID: <c0xI1cV7Pw-CKCUv34S0HK_kFgTQpRZGywuVn_32CvE=.d1931328-d782-4666-bcf2-90a0f3cef020@github.com>

> Added test for checking setMargin() of JRadioButton.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8721/files
  - new: https://git.openjdk.java.net/jdk/pull/8721/files/96cb967a..631e6e2a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8721&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8721&range=09-10

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

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


From tr at openjdk.java.net  Tue Jun  7 13:40:58 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Tue, 7 Jun 2022 13:40:58 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v10]
In-Reply-To: <eLwJtd9cyZ8wbzLao0d8EGlD8FVWxidt_v9oF6lfoDM=.66456be8-0d93-4360-96e2-eba3cdd1bf4f@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <bJiTUCROYh6PFBP1tXi9fj0Hm5ZGJMRpjGrvXZXWk8E=.1e39cce5-d0c9-4fed-b291-f3be4a08fb84@github.com>
 <eLwJtd9cyZ8wbzLao0d8EGlD8FVWxidt_v9oF6lfoDM=.66456be8-0d93-4360-96e2-eba3cdd1bf4f@github.com>
Message-ID: <EZjZWXBmnFMUfO-1U7K8fkh3mAUIdM5NPwABDJfl-PQ=.fac90273-4bb7-4eea-93ba-7d6a49e1977c@github.com>

On Tue, 7 Jun 2022 12:27:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> test/jdk/javax/swing/JRadioButton/bug4380543.java line 94:
> 
>> 92:         JRadioButton rb  = new JRadioButton("JRadioButton");
>> 93:         rb.setMargin(new Insets(20, 20, 20, 20));
>> 94:         rb.setBackground(Color.green);
> 
> In the new code, we should use uppercase color constants, I guess.

Updated.

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

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


From azvegint at openjdk.java.net  Tue Jun  7 13:57:52 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 7 Jun 2022 13:57:52 GMT
Subject: RFR: 8273573: [macos12] ActionListenerCalledTwiceTest.java fails
 on macOS 12 [v2]
In-Reply-To: <wzu9pImlKXT1kag5GfCDdsfWHscH1HHBRRTOq52az3Q=.5c55a664-02ee-47e1-9b0c-68c1459a6831@github.com>
References: <mx87EX5GSQH8vynwviPWaJ_Sm9-aaArJyt1pEq3zp9U=.54e10297-5a40-49d4-93ec-e2dab902b95f@github.com>
 <RpLJZluogF3Z0CgEFDbs5DvAfsz20CRsCOkpvZ4_o00=.2dcccd3e-c51c-4e1d-9a91-888dddeba7ea@github.com>
 <wzu9pImlKXT1kag5GfCDdsfWHscH1HHBRRTOq52az3Q=.5c55a664-02ee-47e1-9b0c-68c1459a6831@github.com>
Message-ID: <h05o6hD4tVMeMTRS3lZgE_4YCeZvZBOju_YpLK0Np3E=.ecacbeed-d25c-437a-b8d3-4fd73a9e0ee9@github.com>

On Tue, 7 Jun 2022 07:41:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I thought I already approved..

Sure, it was, but it differs significantly from the approved version. Thanks.

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

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


From azvegint at openjdk.java.net  Tue Jun  7 14:01:04 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 7 Jun 2022 14:01:04 GMT
Subject: Integrated: 8273573: [macos12] ActionListenerCalledTwiceTest.java
 fails on macOS 12
In-Reply-To: <mx87EX5GSQH8vynwviPWaJ_Sm9-aaArJyt1pEq3zp9U=.54e10297-5a40-49d4-93ec-e2dab902b95f@github.com>
References: <mx87EX5GSQH8vynwviPWaJ_Sm9-aaArJyt1pEq3zp9U=.54e10297-5a40-49d4-93ec-e2dab902b95f@github.com>
Message-ID: <Vsoz0xp_JBn8_PJ3iSyz_Ta2oXOraQESK1s1mGE7ejM=.c7d65764-78d8-4f2e-925b-c9212b069c22@github.com>

On Thu, 2 Jun 2022 20:12:01 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This test was failing consistently on same machines and at the same time as #8532.
> 
> Test failure is also no longer reproducible after #8320 fix.
> 
> This is macOS only test, so corresponding `@requires os.family` tag was added. Testing is green.

This pull request has now been integrated.

Changeset: 1499e5ea
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1499e5eac0cad3745495baeda7b5f9157647ebe9
Stats:     30 lines in 2 files changed: 9 ins; 4 del; 17 mod

8273573: [macos12] ActionListenerCalledTwiceTest.java fails on macOS 12

Reviewed-by: psadhukhan, serb

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

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


From psadhukhan at openjdk.java.net  Tue Jun  7 14:57:06 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 7 Jun 2022 14:57:06 GMT
Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic
 available not used by GUI elements even though available without Korean
 Language Pack [v6]
In-Reply-To: <uvtKoH9gpLWWPWJ50yfWFp0p7T1MWHfUk9tgu7F_3fo=.bdaf38fe-e2b4-4c02-b24a-1f6ae3ef294b@github.com>
References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com>
 <bY1l-V3cTfTzvkTbDCmA1BK8yOXm6EmcEvb0mSvAIVc=.7ea0dc3f-c3a5-4071-8830-797b31ba2286@github.com>
 <uvtKoH9gpLWWPWJ50yfWFp0p7T1MWHfUk9tgu7F_3fo=.bdaf38fe-e2b4-4c02-b24a-1f6ae3ef294b@github.com>
Message-ID: <PUiHZ2tPlWIKDzLvKi6oOPJnEJsocjhmxCKsxGksRCs=.cdaeeb9b-d3d9-471d-b80a-c28fdabb682c@github.com>

On Mon, 6 Jun 2022 09:48:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I see even `Gulimche `and `Batang `are not visible without -Dfile.encoding=ko so maybe it's what is expected.

Malgun Gothic is visible without user.language=ko and user.country=KR in command line (of course without -Dfile.encoding=ko)

OTOH, if we specify user.language=ja and user.country=JP, `MS Mincho` `MS Gothic` japanese font does not appear so maybe it is expected and not weird.

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

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


From aivanov at openjdk.java.net  Tue Jun  7 15:33:10 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Jun 2022 15:33:10 GMT
Subject: RFR: 8286620: Create regression test for verifying setMargin() of
 JRadioButton [v11]
In-Reply-To: <c0xI1cV7Pw-CKCUv34S0HK_kFgTQpRZGywuVn_32CvE=.d1931328-d782-4666-bcf2-90a0f3cef020@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
 <c0xI1cV7Pw-CKCUv34S0HK_kFgTQpRZGywuVn_32CvE=.d1931328-d782-4666-bcf2-90a0f3cef020@github.com>
Message-ID: <DmRjXCNeNAAlOwRIvVPZpnrkV868kTZykY_fpdDM4Go=.e6bbb3ee-cb0c-45f3-8497-e627a5b80fbf@github.com>

On Tue, 7 Jun 2022 13:40:57 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Added test for checking setMargin() of JRadioButton.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.java.net  Tue Jun  7 15:44:13 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Jun 2022 15:44:13 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes [v4]
In-Reply-To: <elb291CEaz1C9fY4_1Md9urOqwoyoKeaU2LPPyCHBsQ=.ba5e0960-5334-4f55-86a4-062367d4e745@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
 <0oxxlnAHynu4eIJIE8cMzXJlpU7I_CF1kBk4IYSN3YY=.e8b93bca-4b06-4a70-82db-aa608d6bb350@github.com>
 <elb291CEaz1C9fY4_1Md9urOqwoyoKeaU2LPPyCHBsQ=.ba5e0960-5334-4f55-86a4-062367d4e745@github.com>
Message-ID: <COceTcQMBADg_v9ovZhkTJW6ovilOr-aycdglAcFVmI=.e5bd847e-f270-48e9-aaa7-03719e0ca233@github.com>

On Wed, 23 Feb 2022 21:34:29 GMT, Emmanuel Bourg <duke at openjdk.java.net> wrote:

>> Emmanuel Bourg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Test case for the window icon update on DPI change (Java generic font names are usually capitalized)
>>  - Test case for the window icon update on DPI change (dispose the frame after a timeout on the EDT)
>
> Just tested on macOS 12 with a non Retina screen and OpenJDK 8: the icon displayed in the dock when the test frame is minimized is the 32x32 one. If I add more icons to the list, it picks the biggest one, up to 128x128. Bigger icons are ignored.
> 
> The issue observed on Windows doesn't really transpose to macOS, I think I'll revert the change to `LWWindowPeer`.

This is a good change, especially for Windows. It's a pity @ebourg hasn't integrated it.

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

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


From duke at openjdk.java.net  Tue Jun  7 15:44:15 2022
From: duke at openjdk.java.net (duke)
Date: Tue, 7 Jun 2022 15:44:15 GMT
Subject: Withdrawn: 8276849: Refresh the window icon on graphics configuration
 changes
In-Reply-To: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
Message-ID: <jBMZLRuOHhAXLzq8yDdM2PRQPQkQVAC8ecElMEsKHKQ=.8035ac4c-baea-43dd-871e-89dcc129515e@github.com>

On Sun, 31 Oct 2021 08:21:58 GMT, Emmanuel Bourg <duke at openjdk.java.net> wrote:

> When a list of icons is set on a window, the most appropiate icon is selected depending on the graphics configuration. But if the graphics configuration changes (because the window is moved to a different screen, or because the DPI settings of the screen is changed), the frame icon isn't updated.
> 
> Here is an example illustrating the issue:
> 
>     public static void main(String[] args) throws Exception {
>         SwingUtilities.invokeLater(() -> {
>             JFrame frame = new JFrame("Window Icon Test");
>             frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>             frame.setSize(400, 300);
>             frame.setVisible(true);
> 
>             List<Image> images = new ArrayList<>();
>             for (int size = 16; size <= 32; size++) {
>                 // create an image displaying the size used
>                 BufferedImage image = new BufferedImage(size, size, BufferedImage.TYPE_INT_ARGB);
>                 Graphics2D g = image.createGraphics();
>                 g.setFont(new Font("dialog", Font.BOLD, 12));
>                 g.setColor(Color.BLACK);
>                 g.drawString(String.valueOf(size), 0, size - (size - g.getFont().getSize()) / 2);
>                 images.add(image);
>             }
> 
>             frame.setIconImages(images);
>         });
>     }
> 
> On Windows if the screen scaling is set to 100% the 16x16 icon is picked from the list. If the scaling of the screen is set to 150% while the application is running, the 16x16 icon is upscaled and looks blurry.
> 
> A way to work around this issue is to listen for graphics configuration changes with:
> 
>     frame.addPropertyChangeListener("graphicsConfiguration", event -> frame.setIconImages(frame.getIconImages()));
> 
> 
> Ideally this should be done automatically by the JDK. Maybe the `WindowPeer` could call `updateIconImages()` when `updateGraphicsData()` or `displayChanged()` is invoked?

This pull request has been closed without being integrated.

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

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


From tr at openjdk.java.net  Tue Jun  7 15:53:08 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Tue, 7 Jun 2022 15:53:08 GMT
Subject: Integrated: 8286620: Create regression test for verifying setMargin()
 of JRadioButton
In-Reply-To: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
References: <lYNgJmX-RoGoLU6R8oYMdcggVZfSkUkE9l2-XQNVl5A=.91d7ed27-8c19-42a3-a2da-f05e8c4c15b8@github.com>
Message-ID: <MZm3ei29gaD7jpgmgjIGahoFoxEfkoFUdkmxyS_VSAU=.fc924f93-07a8-4c2c-82a7-019c22086b41@github.com>

On Mon, 16 May 2022 06:45:04 GMT, Tejesh R <tr at openjdk.org> wrote:

> Added test for checking setMargin() of JRadioButton.

This pull request has now been integrated.

Changeset: 67f1bd7f
Author:    Tejesh R <tr at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/67f1bd7ff1bb218fd6de9ef1e957f729013e133c
Stats:     135 lines in 1 file changed: 135 ins; 0 del; 0 mod

8286620: Create regression test for verifying setMargin() of JRadioButton

Reviewed-by: jdv, honkar, aivanov

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

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


From aivanov at openjdk.java.net  Tue Jun  7 19:19:38 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Jun 2022 19:19:38 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated
In-Reply-To: <Owl-7L83KR54vuXtemNAEZ8rvwijD2BOXHA2zAVpON0=.7f35f198-6bc9-4a7e-8135-e5fa8d0d281c@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <XxLXIIQ5Ic7DgNJaLk4xFDNI6zqN8nR1NzxzGkBcZV4=.31c29356-fa7d-40aa-a0b3-6681d8f70555@github.com>
 <Owl-7L83KR54vuXtemNAEZ8rvwijD2BOXHA2zAVpON0=.7f35f198-6bc9-4a7e-8135-e5fa8d0d281c@github.com>
Message-ID: <CXASw6UIqqXW9pQRhLUPlYms3JuDDI4PpVFE8QP6oH4=.5cad77d5-b556-4e99-a384-828e1549ea7c@github.com>

On Fri, 11 Mar 2022 23:19:19 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> So I wrote a test with a JEditorPane loading HTML from a file, but couldn't get HTML buttons to render properly in JEditorPane. I wanted HTML buttons to test a foo function encased in script tags in my HTML file to see if script tags are parsed or just ignored via a proper test.

Swing does not support plain `button` type, only `submit` and `reset`.
https://github.com/openjdk/jdk/blob/ec4fb47b90c9737dfdc285ebe98367a221c90c79/src/java.desktop/share/classes/javax/swing/text/html/FormView.java#L257-L257

This is why the button isn't rendered. It may be due to the fact that there's no way to associate a handler for button click because scripts aren't supported.

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

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


From aivanov at openjdk.java.net  Tue Jun  7 19:19:40 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Jun 2022 19:19:40 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v3]
In-Reply-To: <gECCW2gmBPuaXgTdMperdZQvVqUqwqmTIp7rzEdPiH0=.4e015c96-7323-42da-b006-7025b3878ffa@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <z9URv-_hXQs8mrNtl2QRzCcoe2EJ-c3SySV_Udt90hI=.df956801-b2a3-47de-b6ca-b1f6ee54c932@github.com>
 <H_-DXhYywtC68Z0J5KP3Eesx9idZMrorAWv-vAKwdvs=.f12ca7c5-d272-4ffa-b056-04b82b09d8b3@github.com>
 <K1-HzDvH-R3UeVtkYAWAEUNdywtlQ6CuI7ubfF8Fx-8=.100cdfbd-f4a5-45ca-933f-2e242a5d944b@github.com>
 <gECCW2gmBPuaXgTdMperdZQvVqUqwqmTIp7rzEdPiH0=.4e015c96-7323-42da-b006-7025b3878ffa@github.com>
Message-ID: <Zw4A4VvySY5HB8Tcwo62GKgfysJZO-4T3qFL_udSDo4=.e68f81c9-32d6-4936-8925-f5ff0ff1c94e@github.com>

On Mon, 6 Jun 2022 16:28:22 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> I see your points and agree that your points are valid. Parser has no part in the display and is fact handled elsewhere.
>> 
>> I initially had to look through and learn what each class for HTML parsing is responsible for, and Parser is meant to handle reading chars and adding the chars to a buffer to be processed elsewhere. In this case, I found the HTML contents were routed to DocumentParser. And from there, I had to trace the stack and add debugging statements to find that hidden tags were responsible for the specialized text fields and text areas that appeared. 
>> 
>> I'll definitely iterate on the documentation to increase clarity and remove mention of HiddenTagView.
>
> The editor kit is responsible for delegating which tags will be displayed this way. The list of tags supported can be located in the HTML class, and it's worth noting that script tag is among the tags listed here. But, there is another list of tags in the editor kit's code which are the tags that do not have full support. Script tags are one of these tags; another example being title tags. These tags that are not fully supported, alongside unknown tags, are being passed into HiddenTagView and being displayed as such. So, I tried simplifying the doc description to state the behavior as relevant to the Parser class only. Maybe additional documentation is required in HTMLEditorKit as well?

Do we want to say anything about them being hidden when editable is set to false?

If I add the following line to the test:

jep.setEditable(false);

Then the script tags are hidden from view.

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

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


From aivanov at openjdk.java.net  Tue Jun  7 19:19:45 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Jun 2022 19:19:45 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v8]
In-Reply-To: <23EzklXwXRVg1eW3r87i1NFJHvwJFxUFMujEH7N3CQw=.97ed5f39-3f0b-419d-a787-a380c95ead13@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <23EzklXwXRVg1eW3r87i1NFJHvwJFxUFMujEH7N3CQw=.97ed5f39-3f0b-419d-a787-a380c95ead13@github.com>
Message-ID: <xP3nv-MtjCNZUeHCAq-s7KFgq8IW-JEz6HN0OztNPAg=.f24369b0-8fa1-4617-bbf2-530bee62f700@github.com>

On Mon, 6 Jun 2022 20:45:46 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed doc text.

test/jdk/javax/swing/text/html/HtmlTagParserTest.java line 65:

> 63:             InvocationTargetException {
> 64:         SwingUtilities.invokeAndWait(() -> {
> 65:             jep = new JEditorPane();

Suggestion:

            jep = new JEditorPane("text/html", htmlText);


It produces the same result as loading the HTML from a temporary file.

test/jdk/javax/swing/text/html/HtmlTagParserTest.java line 83:

> 81:     }
> 82: 
> 83:     public static void main(String args[]) throws InterruptedException,

Suggestion:

    public static void main(String[] args) throws InterruptedException,


Please use Java-style array declaration.

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

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


From aivanov at openjdk.java.net  Tue Jun  7 19:23:34 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Jun 2022 19:23:34 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v4]
In-Reply-To: <AJmERiLsf08q5j8eXimP0U5dmkR-JEfEM10b0pl4jJ8=.475469c8-cc7d-4050-b052-18e1c2298b93@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <GfNe4SPaVPHLXSdSKAQpG5niCBbh9-AA6EylBsForNQ=.7d5d28de-68db-4ab9-979c-00bffbfabe90@github.com>
 <pj2AY_45bxMDpHOaah4wEhFQLDu4iFpFxfHofNBLMCs=.9a25ac10-a5b6-414f-b7a0-9159258c37f5@github.com>
 <AJmERiLsf08q5j8eXimP0U5dmkR-JEfEM10b0pl4jJ8=.475469c8-cc7d-4050-b052-18e1c2298b93@github.com>
Message-ID: <v2bakk6jOY2lH6by3zdIKHj_4DuXNL7zPQS-pyVMGpI=.114dfe44-aaef-4b27-ad17-a923acc3e4fd@github.com>

On Mon, 6 Jun 2022 16:19:18 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> test/jdk/javax/swing/text/html/parser/HtmlTagParserTest.java line 1:
>> 
>>> 1: import java.awt.Dimension;
>> 
>> where's the GPL header on this test ?
>
> Added the header and moved the test to the HTML folder instead since I believe the process involves classes beyond just the Parser. For example, I found that the tags and unknown tags are located in the HTML class. I can move it back if it seems more appropriate since the issue requests changes to the Parser's doc only.

Shall the test name be `HtmlScriptTagParserTest.java`? The test is for testing handling the `<script>` tag only.

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

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


From aturbanov at openjdk.java.net  Tue Jun  7 19:42:52 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 7 Jun 2022 19:42:52 GMT
Subject: RFR: 8287148: Avoid redundant HashMap.containsKey calls in
 ExtendedKeyCodes.getExtendedKeyCodeForChar
In-Reply-To: <DTYBlJe3IMRnobVw1vCsNFLwd0z-gRhY6K1XyDeAS74=.6e9872b6-9020-439f-aacb-0127ffd9bcbd@github.com>
References: <DTYBlJe3IMRnobVw1vCsNFLwd0z-gRhY6K1XyDeAS74=.6e9872b6-9020-439f-aacb-0127ffd9bcbd@github.com>
Message-ID: <VPpxpa3tXLmT6sruOmRX32rboVNOY443n_aaGr4BwVQ=.c25102ac-3e4d-4837-8462-152455f1c4aa@github.com>

On Sat, 30 Apr 2022 18:58:56 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `sun.awt.ExtendedKeyCodes#regularKeyCodesMap` contains only non-null values. It means we can replace containsKey+get with get+null check.
> It's clearer and a bit faster.

Thank you for review!

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

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


From aturbanov at openjdk.java.net  Tue Jun  7 19:42:53 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 7 Jun 2022 19:42:53 GMT
Subject: Integrated: 8287148: Avoid redundant HashMap.containsKey calls in
 ExtendedKeyCodes.getExtendedKeyCodeForChar
In-Reply-To: <DTYBlJe3IMRnobVw1vCsNFLwd0z-gRhY6K1XyDeAS74=.6e9872b6-9020-439f-aacb-0127ffd9bcbd@github.com>
References: <DTYBlJe3IMRnobVw1vCsNFLwd0z-gRhY6K1XyDeAS74=.6e9872b6-9020-439f-aacb-0127ffd9bcbd@github.com>
Message-ID: <Q5HSd3c89cCUvOvWGcGJKdKY5lzSkk_DlfqauuTc1Ps=.ab578b7e-c220-4916-8e6f-cb11cea73196@github.com>

On Sat, 30 Apr 2022 18:58:56 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `sun.awt.ExtendedKeyCodes#regularKeyCodesMap` contains only non-null values. It means we can replace containsKey+get with get+null check.
> It's clearer and a bit faster.

This pull request has now been integrated.

Changeset: 1aa87e00
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1aa87e0078765480bc7805e95b747addaf993cf6
Stats:     18 lines in 1 file changed: 3 ins; 5 del; 10 mod

8287148: Avoid redundant HashMap.containsKey calls in ExtendedKeyCodes.getExtendedKeyCodeForChar

Reviewed-by: prr

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

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


From honkar at openjdk.java.net  Tue Jun  7 19:52:53 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Tue, 7 Jun 2022 19:52:53 GMT
Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray
 [v3]
In-Reply-To: <UWwEMift6h_AIxKxKymzR7Lo8bs82zDSGgsc_u-UQw4=.dedb3a0d-8cfb-4aa2-917b-8c4dbf01c239@github.com>
References: <KbpNZ7Yzxx6cUu_DQI5QawOSz2BfkC02EgzR28gUiyU=.3c2abcd2-54ba-4eea-803d-d04a611df9ed@github.com>
 <UWwEMift6h_AIxKxKymzR7Lo8bs82zDSGgsc_u-UQw4=.dedb3a0d-8cfb-4aa2-917b-8c4dbf01c239@github.com>
Message-ID: <gAvX08P6HNDtbjU30kZJ4zhHF1aNbMkPaBPNrnu6FqU=.745a6070-da8a-489c-9112-f87c9716dbcf@github.com>

On Fri, 27 May 2022 20:48:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> **WTrayIconPeer**: removed duplicate call to `popupParent.dispose()` that might cause NPE (it looks `popupParent` cannot be `null`); organised imports.
>> 
>> **SystemTray**: removed redundant initialisers; replaced sized array with empty array in `toArray` call; dropped `newValue != null` chained with `equals`.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use method reference in setSystemTrayAccessor instead of anonymous class

Marked as reviewed by honkar (Author).

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

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


From dcubed at openjdk.java.net  Tue Jun  7 20:42:52 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 7 Jun 2022 20:42:52 GMT
Subject: RFR: 8287927: ProblemList
 java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on
 macosx-aarch64
Message-ID: <vRXO30sDL303_TzZY9XRmdiyNsMJxI5Q7ytX0PBF0Zk=.339a1139-495f-47ab-9bf7-558589dde27f@github.com>

A trivial fix to ProblemList java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on macosx-aarch64.

What I'd really like to is to ProblemList this test 
on Mac_OS_X_12.4 and Mac_OS_X_12.5, but two digit release values 
(M.N) did not work when I tried them a month or so ago.

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

Commit messages:
 - 8287927: ProblemList java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on macosx-aarch64

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

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


From aivanov at openjdk.java.net  Tue Jun  7 21:11:52 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Jun 2022 21:11:52 GMT
Subject: RFR: 8287927: ProblemList
 java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on
 macosx-aarch64
In-Reply-To: <vRXO30sDL303_TzZY9XRmdiyNsMJxI5Q7ytX0PBF0Zk=.339a1139-495f-47ab-9bf7-558589dde27f@github.com>
References: <vRXO30sDL303_TzZY9XRmdiyNsMJxI5Q7ytX0PBF0Zk=.339a1139-495f-47ab-9bf7-558589dde27f@github.com>
Message-ID: <O3m26p_Ym41_uMbi9wvjMxcRc5YOjfaOmi4r9_rajlo=.de75329c-2ac0-4d56-9348-1cc32653fcbb@github.com>

On Tue, 7 Jun 2022 20:33:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on macosx-aarch64.
> 
> What I'd really like to is to ProblemList this test 
> on Mac_OS_X_12.4 and Mac_OS_X_12.5, but two digit release values 
> (M.N) did not work when I tried them a month or so ago.

Marked as reviewed by aivanov (Reviewer).

I'm unsure it belongs in *hotspot-runtime*?

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

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


From dcubed at openjdk.java.net  Tue Jun  7 21:11:52 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 7 Jun 2022 21:11:52 GMT
Subject: RFR: 8287927: ProblemList
 java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on
 macosx-aarch64
In-Reply-To: <vRXO30sDL303_TzZY9XRmdiyNsMJxI5Q7ytX0PBF0Zk=.339a1139-495f-47ab-9bf7-558589dde27f@github.com>
References: <vRXO30sDL303_TzZY9XRmdiyNsMJxI5Q7ytX0PBF0Zk=.339a1139-495f-47ab-9bf7-558589dde27f@github.com>
Message-ID: <RZAlCt5jvi1VqZAN-oHBelIeo2AzZPQwOLW7uWApE38=.1450dee3-6314-46ac-94ec-23a19741c9d5@github.com>

On Tue, 7 Jun 2022 20:33:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on macosx-aarch64.
> 
> What I'd really like to is to ProblemList this test 
> on Mac_OS_X_12.4 and Mac_OS_X_12.5, but two digit release values 
> (M.N) did not work when I tried them a month or so ago.

It doesn't belong in hotspot-runtime, but I include hotspot-runtime just in
case one of my team is on-the-air and can give a quick review...

@aivanov-jdk thanks for your review.

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

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


From dcubed at openjdk.java.net  Tue Jun  7 21:11:53 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 7 Jun 2022 21:11:53 GMT
Subject: Integrated: 8287927: ProblemList
 java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on
 macosx-aarch64
In-Reply-To: <vRXO30sDL303_TzZY9XRmdiyNsMJxI5Q7ytX0PBF0Zk=.339a1139-495f-47ab-9bf7-558589dde27f@github.com>
References: <vRXO30sDL303_TzZY9XRmdiyNsMJxI5Q7ytX0PBF0Zk=.339a1139-495f-47ab-9bf7-558589dde27f@github.com>
Message-ID: <Ngg8lavvNZp7LJvD2ZAC9VMTFJJYEC8eaiXFjgfHM9s=.5afd1351-098f-402d-8343-b9dfd55cdcf9@github.com>

On Tue, 7 Jun 2022 20:33:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on macosx-aarch64.
> 
> What I'd really like to is to ProblemList this test 
> on Mac_OS_X_12.4 and Mac_OS_X_12.5, but two digit release values 
> (M.N) did not work when I tried them a month or so ago.

This pull request has now been integrated.

Changeset: b7a34f72
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b7a34f728d0653d55ef01da045c9aad4c0471143
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8287927: ProblemList java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on macosx-aarch64

Reviewed-by: aivanov

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

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


From aivanov at openjdk.java.net  Tue Jun  7 21:21:50 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Jun 2022 21:21:50 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v21]
In-Reply-To: <euNp0wrZUXtUM4m61GEiTkEok8f5CDRELF7yYCJWmhI=.fa2afabd-e61a-4d0c-b28c-69a76141e373@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <euNp0wrZUXtUM4m61GEiTkEok8f5CDRELF7yYCJWmhI=.fa2afabd-e61a-4d0c-b28c-69a76141e373@github.com>
Message-ID: <KoypcU3o2p16qOCXTEIT4ylSJZrjZ7WYOHB9K4us5Po=.658b9bde-a691-43af-842f-7002e66340d4@github.com>

On Mon, 6 Jun 2022 20:46:03 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   skip transform is m01 or m10 is nonzero

I played a bit with rotation and shear on the graphics where the panel is painted. It works as coded: the border is painted as before. If only scale is applied, the fix works well and borders are painted without any gaps and with the correct width.

There are two unused imports in the test.

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 180:

> 178:         int xtranslation;
> 179:         int ytranslation;
> 180:         if(resetTransform) {

A space between `if` and `(`, please. And at line 167 too.

test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 178:

> 176:         JFrame frame;
> 177:         JPanel contentPanel;
> 178:         JPanel childPanel;

There's no need to declare them in advance. Declare each variable where it's used for the first time.

test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 194:

> 192:             contentPanel.add(childPanel);
> 193:             childSize = childPanel.getPreferredSize();
> 194:             childPanel.setBounds(0, childSize.height * i, childSize.width, childSize.height);

Yes, the previous version was incorrect. The idea here was to calculate the preferred size only once and re-use it.


            if (childSize == null) {
                childSize = childPanel.getPreferredSize();
            }
            childPanel.setBounds(0, childSize.height * i, childSize.width, childSize.height);

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

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


From prr at openjdk.java.net  Tue Jun  7 22:24:33 2022
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 7 Jun 2022 22:24:33 GMT
Subject: RFR: 8287876: The recently de-problemlisted TestTitledBorderLeak
 test is unstable [v2]
In-Reply-To: <eCcO4tClD2CMx-hFM0Voz2xAw9vRnC7cWXFy_OqHtnw=.2e9a776d-e393-487d-8bd6-0f7275753237@github.com>
References: <Nchq_TbqFJEaKYS_lmFcqQwrXuOJHw2q9li8Rte9fPQ=.25d61d35-bb71-4be2-ba07-25163d0c8502@github.com>
 <eCcO4tClD2CMx-hFM0Voz2xAw9vRnC7cWXFy_OqHtnw=.2e9a776d-e393-487d-8bd6-0f7275753237@github.com>
Message-ID: <jThOVZLGt9XQ68X39psChWwdj68nzzEU80M7tkW4Cg0=.a2c771c1-805f-4820-8c46-8840d81d6865@github.com>

On Tue, 7 Jun 2022 11:36:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is an update of the test which was de-problemlisted [here](https://github.com/openjdk/jdk/pull/8450).
>> 
>> Looks like the initial root cause of the issue was related to the last disposed frame which for some reason was not deleted from the memory, for that issue, the [next](https://bugs.openjdk.org/browse/JDK-8287707) bug was reported.
>> But that change also replaced the usage of weak references by the Runtime.getRuntime().freeMemory() which is not stable enough to verify the leak - its return values vary a lot.
>> 
>> This change returns the usage of weak references and tests only one instance of TitledBorder which is enough to verify the old [bug](https://bugs.openjdk.org/browse/JDK-8204963).
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Smaller version

Marked as reviewed by prr (Reviewer).

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

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


From serb at openjdk.java.net  Tue Jun  7 23:14:30 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 7 Jun 2022 23:14:30 GMT
Subject: Integrated: 8287876: The recently de-problemlisted
 TestTitledBorderLeak test is unstable
In-Reply-To: <Nchq_TbqFJEaKYS_lmFcqQwrXuOJHw2q9li8Rte9fPQ=.25d61d35-bb71-4be2-ba07-25163d0c8502@github.com>
References: <Nchq_TbqFJEaKYS_lmFcqQwrXuOJHw2q9li8Rte9fPQ=.25d61d35-bb71-4be2-ba07-25163d0c8502@github.com>
Message-ID: <JxsepewBDC1Cbl_r7D58pn_abRLNDeVgjz20Kk9opwM=.f68a2f9f-2b8e-4041-aa2d-c56b90f405b4@github.com>

On Tue, 7 Jun 2022 04:15:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is an update of the test which was de-problemlisted [here](https://github.com/openjdk/jdk/pull/8450).
> 
> Looks like the initial root cause of the issue was related to the last disposed frame which for some reason was not deleted from the memory, for that issue, the [next](https://bugs.openjdk.org/browse/JDK-8287707) bug was reported.
> But that change also replaced the usage of weak references by the Runtime.getRuntime().freeMemory() which is not stable enough to verify the leak - its return values vary a lot.
> 
> This change returns the usage of weak references and tests only one instance of TitledBorder which is enough to verify the old [bug](https://bugs.openjdk.org/browse/JDK-8204963).

This pull request has now been integrated.

Changeset: bf439f8c
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bf439f8c93157a7f0e6489db2ccc56c5f7210402
Stats:     36 lines in 1 file changed: 5 ins; 18 del; 13 mod

8287876: The recently de-problemlisted TestTitledBorderLeak test is unstable

Reviewed-by: psadhukhan, prr

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

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


From tr at openjdk.java.net  Wed Jun  8 07:01:08 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Wed, 8 Jun 2022 07:01:08 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v9]
In-Reply-To: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
Message-ID: <47weR8YmzNAqgbIzbxyIjmJtYgpriT9rvke4oZ3Nd8Y=.7da8b505-ecb8-4a04-bb3d-c6ecefd1fad8@github.com>

> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated for multiple LookAndFeel

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8830/files
  - new: https://git.openjdk.java.net/jdk/pull/8830/files/89b4cadb..721b8818

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

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

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


From asemenov at openjdk.java.net  Wed Jun  8 09:56:35 2022
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Wed, 8 Jun 2022 09:56:35 GMT
Subject: RFR: 8283383: [macos] a11y : Screen magnifier shows extra
 characters (0) at the end JButton accessibility name
In-Reply-To: <Luft87ELZpKBREKvqL5wybzkDMkuT4f5v7E1aLhGjlE=.8d3840be-7a35-472d-b006-759402e6e3bc@github.com>
References: <Luft87ELZpKBREKvqL5wybzkDMkuT4f5v7E1aLhGjlE=.8d3840be-7a35-472d-b006-759402e6e3bc@github.com>
Message-ID: <ud7DEiPsOihXSbjkQPtRfVQcZ5PmKiWpGUWIzvPm2Xw=.cedc178c-f588-4a87-942e-17f16918d491@github.com>

On Mon, 6 Jun 2022 22:14:40 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add the accessibilityValue implementation to the affected classes to return NULL value
> Reverse the default initialization of MenuItemAccessibility if no parent is specified

Looks good for me. It would be good to add a regression test.

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

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


From aivanov at openjdk.java.net  Wed Jun  8 10:26:40 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 8 Jun 2022 10:26:40 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v9]
In-Reply-To: <47weR8YmzNAqgbIzbxyIjmJtYgpriT9rvke4oZ3Nd8Y=.7da8b505-ecb8-4a04-bb3d-c6ecefd1fad8@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <47weR8YmzNAqgbIzbxyIjmJtYgpriT9rvke4oZ3Nd8Y=.7da8b505-ecb8-4a04-bb3d-c6ecefd1fad8@github.com>
Message-ID: <_cprdGRBv_pvuJwvisXaHqDOmDqIZxcEhn5LyAHBK88=.8492295e-bfdc-4766-9388-53b2d1d348c6@github.com>

On Wed, 8 Jun 2022 07:01:08 GMT, Tejesh R <tr at openjdk.org> wrote:

>> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated for multiple LookAndFeel

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JTableHeader/TableHeaderRendererTest.java line 52:

> 50:         for (UIManager.LookAndFeelInfo look : lookAndFeel) {
> 51:             // initialize should not throw NullPointerException
> 52:             LnFName = look.getName();

Why not declare it here? It does not need to be a field, moreover you don't need it even as a local variable.

test/jdk/javax/swing/JTableHeader/TableHeaderRendererTest.java line 54:

> 52:             LnFName = look.getName();
> 53:             System.out.println(LnFName+ " LookAndFeel Set");
> 54:             setLookAndFeel(look.getClassName());

Setting L&F should rather be done on EDT as well, so I propose creating a `runTest` method which will encapsulate the logic of the test:


    public static void main(String[] args) throws Exception {
        SwingUtilities.invokeAndWait(TableHeaderRendererTest::runTest);
        System.out.println("Test Passed");
    }

    private static void runTest() {
        UIManager.LookAndFeelInfo[] lookAndFeel = UIManager.getInstalledLookAndFeels();
        for (UIManager.LookAndFeelInfo look : lookAndFeel) {
            System.out.println(look.getName() + " LookAndFeel Set");
            setLookAndFeel(look.getClassName());
            // initialize should not throw NullPointerException
            initialize();
        }
    }

test/jdk/javax/swing/JTableHeader/TableHeaderRendererTest.java line 114:

> 112:         }
> 113:     }
> 114:     private static void setLookAndFeel(String laf) {

Please add a blank line before the new method declaration.

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

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


From aivanov at openjdk.java.net  Wed Jun  8 10:26:43 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 8 Jun 2022 10:26:43 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v8]
In-Reply-To: <ILMGG3F17K6uE0m9_hqCtsUQssZ23UOc1dHKhwfDFO4=.5b601a40-3f83-4e51-bf9c-5cb3ed4aaaa4@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <0vsbn9QEPTr3O4e2thstKM8odT046_I55Fb9SsdbYHQ=.2077175e-36a8-4b27-8bbd-0692698f0a78@github.com>
 <ILMGG3F17K6uE0m9_hqCtsUQssZ23UOc1dHKhwfDFO4=.5b601a40-3f83-4e51-bf9c-5cb3ed4aaaa4@github.com>
Message-ID: <Ue1t65sTCRdan65EUwK5CMsJ4HXRq4QXkXnRCuMxDhI=.2486d0ce-b6e3-48a6-9b70-53bc67e221ba@github.com>

On Tue, 7 Jun 2022 12:37:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments and File name changed
>
> test/jdk/javax/swing/JTableHeader/TableHeaderRendererTest.java line 40:
> 
>> 38:  * @bug 6429812
>> 39:  * @requires (os.family == "windows")
>> 40:  * @summary Test to check if table is printed without NPE
> 
> Suggestion:
> 
>  * @summary Test to check if table header is painted without NPE
> 
> Nothing is printed in this test case.

The summary hasn't been updated yet.

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

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


From tr at openjdk.java.net  Wed Jun  8 11:04:24 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Wed, 8 Jun 2022 11:04:24 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v9]
In-Reply-To: <_cprdGRBv_pvuJwvisXaHqDOmDqIZxcEhn5LyAHBK88=.8492295e-bfdc-4766-9388-53b2d1d348c6@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <47weR8YmzNAqgbIzbxyIjmJtYgpriT9rvke4oZ3Nd8Y=.7da8b505-ecb8-4a04-bb3d-c6ecefd1fad8@github.com>
 <_cprdGRBv_pvuJwvisXaHqDOmDqIZxcEhn5LyAHBK88=.8492295e-bfdc-4766-9388-53b2d1d348c6@github.com>
Message-ID: <bAH0pEErL9GvSKHgvUoRI5KgelYt23GJNFB6FJbx4gU=.6a371e9e-c704-403a-b7d0-68339b72388d@github.com>

On Wed, 8 Jun 2022 10:12:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated for multiple LookAndFeel
>
> test/jdk/javax/swing/JTableHeader/TableHeaderRendererTest.java line 52:
> 
>> 50:         for (UIManager.LookAndFeelInfo look : lookAndFeel) {
>> 51:             // initialize should not throw NullPointerException
>> 52:             LnFName = look.getName();
> 
> Why not declare it here? It does not need to be a field, moreover you don't need it even as a local variable.

Yeah, had a different thought about that before, later didn't change it. Will update.

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

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


From tr at openjdk.java.net  Wed Jun  8 11:11:44 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Wed, 8 Jun 2022 11:11:44 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v10]
In-Reply-To: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
Message-ID: <XnDTchLm5hwZbELax7JpD9-4J6mvNpwQ49lMRjC6Hp4=.c728314d-278f-4693-baeb-4bbe32c541ad@github.com>

> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8830/files
  - new: https://git.openjdk.java.net/jdk/pull/8830/files/721b8818..fbcd51cf

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

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

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


From aivanov at openjdk.java.net  Wed Jun  8 11:28:32 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 8 Jun 2022 11:28:32 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v10]
In-Reply-To: <XnDTchLm5hwZbELax7JpD9-4J6mvNpwQ49lMRjC6Hp4=.c728314d-278f-4693-baeb-4bbe32c541ad@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <XnDTchLm5hwZbELax7JpD9-4J6mvNpwQ49lMRjC6Hp4=.c728314d-278f-4693-baeb-4bbe32c541ad@github.com>
Message-ID: <yLN5HbiAds7qRjH5hCKHyQeOR5_DC2mhdUNhV9aTCgE=.f6b3c235-2a62-4eb1-9d6b-148f0894edad@github.com>

On Wed, 8 Jun 2022 11:11:44 GMT, Tejesh R <tr at openjdk.org> wrote:

>> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Looks good now.

Please update the copyright year WindowsTableHeaderUI and optionally organise imports.

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

Changes requested by aivanov (Reviewer).

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


From tr at openjdk.java.net  Wed Jun  8 11:28:33 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Wed, 8 Jun 2022 11:28:33 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v10]
In-Reply-To: <yLN5HbiAds7qRjH5hCKHyQeOR5_DC2mhdUNhV9aTCgE=.f6b3c235-2a62-4eb1-9d6b-148f0894edad@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <XnDTchLm5hwZbELax7JpD9-4J6mvNpwQ49lMRjC6Hp4=.c728314d-278f-4693-baeb-4bbe32c541ad@github.com>
 <yLN5HbiAds7qRjH5hCKHyQeOR5_DC2mhdUNhV9aTCgE=.f6b3c235-2a62-4eb1-9d6b-148f0894edad@github.com>
Message-ID: <Ie2YWUEIDA6eStPOtct0Yaew6VACP5vMWWw7iFtnyw0=.eecfdb2b-2b19-4057-82af-bcde885810d6@github.com>

On Wed, 8 Jun 2022 11:18:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Looks good now.
> 
> Please update the copyright year WindowsTableHeaderUI and optionally organise imports.

Copyright year.......? It's supposed to be 2022 only right.......?

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

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


From aivanov at openjdk.java.net  Wed Jun  8 11:28:34 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 8 Jun 2022 11:28:34 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v10]
In-Reply-To: <Ie2YWUEIDA6eStPOtct0Yaew6VACP5vMWWw7iFtnyw0=.eecfdb2b-2b19-4057-82af-bcde885810d6@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <XnDTchLm5hwZbELax7JpD9-4J6mvNpwQ49lMRjC6Hp4=.c728314d-278f-4693-baeb-4bbe32c541ad@github.com>
 <yLN5HbiAds7qRjH5hCKHyQeOR5_DC2mhdUNhV9aTCgE=.f6b3c235-2a62-4eb1-9d6b-148f0894edad@github.com>
 <Ie2YWUEIDA6eStPOtct0Yaew6VACP5vMWWw7iFtnyw0=.eecfdb2b-2b19-4057-82af-bcde885810d6@github.com>
Message-ID: <XrTHjgoqX3ZNHxslxmU9J68t3AKxbzzHAoYVj2Ll3p8=.ab92d0ac-9a7d-4ecc-a982-fc767e673a99@github.com>

On Wed, 8 Jun 2022 11:20:56 GMT, Tejesh R <tr at openjdk.org> wrote:

> > Looks good now.
> > Please update the copyright year WindowsTableHeaderUI and optionally organise imports.
> 
> Copyright year.......?

Yes, currently the first line in `WindowsTableHeaderUI.java`: ?Copyright (c) 1997, 2014??. It should be updated to 2022, it's the current year, isn't it?

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

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


From tr at openjdk.java.net  Wed Jun  8 11:28:35 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Wed, 8 Jun 2022 11:28:35 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v10]
In-Reply-To: <XrTHjgoqX3ZNHxslxmU9J68t3AKxbzzHAoYVj2Ll3p8=.ab92d0ac-9a7d-4ecc-a982-fc767e673a99@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <XnDTchLm5hwZbELax7JpD9-4J6mvNpwQ49lMRjC6Hp4=.c728314d-278f-4693-baeb-4bbe32c541ad@github.com>
 <yLN5HbiAds7qRjH5hCKHyQeOR5_DC2mhdUNhV9aTCgE=.f6b3c235-2a62-4eb1-9d6b-148f0894edad@github.com>
 <Ie2YWUEIDA6eStPOtct0Yaew6VACP5vMWWw7iFtnyw0=.eecfdb2b-2b19-4057-82af-bcde885810d6@github.com>
 <XrTHjgoqX3ZNHxslxmU9J68t3AKxbzzHAoYVj2Ll3p8=.ab92d0ac-9a7d-4ecc-a982-fc767e673a99@github.com>
Message-ID: <ynNNdauB_SUX081lWwdUbHXzmZ5cnhV_EauFZS-67ag=.820441dd-1fed-48c1-b86c-1729e179fa2b@github.com>

On Wed, 8 Jun 2022 11:23:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > Looks good now.
> > > Please update the copyright year WindowsTableHeaderUI and optionally organise imports.
> > 
> > 
> > Copyright year.......?
> 
> Yes, currently the first line in `WindowsTableHeaderUI.java`: ?Copyright (c) 1997, 2014??. It should be updated to 2022, it's the current year, isn't it?

Yup, will do it.

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

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


From tr at openjdk.java.net  Wed Jun  8 11:40:25 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Wed, 8 Jun 2022 11:40:25 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v11]
In-Reply-To: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
Message-ID: <WerSTSy5DTqSYkz9M1BWNxT0VzbA6osx6xJEnaYHT9g=.3424a2b3-6d45-489c-aa50-972c549a2290@github.com>

> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8830/files
  - new: https://git.openjdk.java.net/jdk/pull/8830/files/fbcd51cf..a3c73b5b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8830&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8830&range=09-10

  Stats: 30 lines in 2 files changed: 17 ins; 6 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8830.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8830/head:pull/8830

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


From aivanov at openjdk.java.net  Wed Jun  8 11:44:36 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 8 Jun 2022 11:44:36 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v11]
In-Reply-To: <WerSTSy5DTqSYkz9M1BWNxT0VzbA6osx6xJEnaYHT9g=.3424a2b3-6d45-489c-aa50-972c549a2290@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <WerSTSy5DTqSYkz9M1BWNxT0VzbA6osx6xJEnaYHT9g=.3424a2b3-6d45-489c-aa50-972c549a2290@github.com>
Message-ID: <AdFgENG6jEi_PCOASFOi2CUr8iXLRqOZweiPwmBTrSg=.5ebcd96b-2ce5-47cc-945b-43b055a2548f@github.com>

On Wed, 8 Jun 2022 11:40:25 GMT, Tejesh R <tr at openjdk.org> wrote:

>> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Changes requested by aivanov (Reviewer).

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTableHeaderUI.java line 2:

> 1: /*
> 2:  * Copyright (c) 1997, 2014, 2022, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 1997, 2022, Oracle and/or its affiliates. All rights reserved.

Nope, you don't add another year, you just modify the second year to the current one.

If the file has only one year, then you add the second one.

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

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


From dmarkov at openjdk.java.net  Wed Jun  8 12:27:24 2022
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Wed, 8 Jun 2022 12:27:24 GMT
Subject: RFR: 8283383: [macos] a11y : Screen magnifier shows extra
 characters (0) at the end JButton accessibility name
In-Reply-To: <Luft87ELZpKBREKvqL5wybzkDMkuT4f5v7E1aLhGjlE=.8d3840be-7a35-472d-b006-759402e6e3bc@github.com>
References: <Luft87ELZpKBREKvqL5wybzkDMkuT4f5v7E1aLhGjlE=.8d3840be-7a35-472d-b006-759402e6e3bc@github.com>
Message-ID: <R0rQ8MrJVyL--hLGvrXkbFrufFcMCN1eMDAgWtSpo8s=.6f654a86-fcd2-4d34-9347-09b0fff5cf90@github.com>

On Mon, 6 Jun 2022 22:14:40 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add the accessibilityValue implementation to the affected classes to return NULL value
> Reverse the default initialization of MenuItemAccessibility if no parent is specified

Marked as reviewed by dmarkov (Reviewer).

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

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


From tr at openjdk.java.net  Wed Jun  8 14:09:24 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Wed, 8 Jun 2022 14:09:24 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v12]
In-Reply-To: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
Message-ID: <qd-_7mPrASxGie-wVGAsMEkSvZH4pdJNLk8aN7Re3OA=.3be0d782-925b-4050-9342-ef2058eaf1b7@github.com>

> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.

Tejesh R has updated the pull request incrementally with two additional commits since the last revision:

 - Updated Copyright
 - Reverting imports ordering

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8830/files
  - new: https://git.openjdk.java.net/jdk/pull/8830/files/a3c73b5b..4a5c72dd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8830&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8830&range=10-11

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

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


From kizune at openjdk.java.net  Wed Jun  8 14:48:04 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 8 Jun 2022 14:48:04 GMT
Subject: Integrated: 8283383: [macos] a11y : Screen magnifier shows extra
 characters (0) at the end JButton accessibility name
In-Reply-To: <Luft87ELZpKBREKvqL5wybzkDMkuT4f5v7E1aLhGjlE=.8d3840be-7a35-472d-b006-759402e6e3bc@github.com>
References: <Luft87ELZpKBREKvqL5wybzkDMkuT4f5v7E1aLhGjlE=.8d3840be-7a35-472d-b006-759402e6e3bc@github.com>
Message-ID: <Jr6MKeNPZLdkIyTkWxbpegMtHtDzm-tmgW_f_EvHcPo=.5c67bc25-f4e4-4b7e-8220-56fbc91cacf0@github.com>

On Mon, 6 Jun 2022 22:14:40 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add the accessibilityValue implementation to the affected classes to return NULL value
> Reverse the default initialization of MenuItemAccessibility if no parent is specified

This pull request has now been integrated.

Changeset: b021d37c
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b021d37cec557059e288d5937a73577233b0b172
Stats:     29 lines in 5 files changed: 22 ins; 0 del; 7 mod

8283383: [macos] a11y : Screen magnifier shows extra characters (0) at the end JButton accessibility name

Reviewed-by: serb, dmarkov

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

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


From aivanov at openjdk.java.net  Wed Jun  8 15:35:27 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 8 Jun 2022 15:35:27 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v12]
In-Reply-To: <qd-_7mPrASxGie-wVGAsMEkSvZH4pdJNLk8aN7Re3OA=.3be0d782-925b-4050-9342-ef2058eaf1b7@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <qd-_7mPrASxGie-wVGAsMEkSvZH4pdJNLk8aN7Re3OA=.3be0d782-925b-4050-9342-ef2058eaf1b7@github.com>
Message-ID: <QrBIcxlwN5OrAcmFVZyxM2xWnS4nkah49So27Cq217g=.b053e51d-c0bb-49d3-9f6f-9ff72c4da5a5@github.com>

On Wed, 8 Jun 2022 14:09:24 GMT, Tejesh R <tr at openjdk.org> wrote:

>> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.
>
> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updated Copyright
>  - Reverting imports ordering

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.java.net  Wed Jun  8 15:38:52 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 8 Jun 2022 15:38:52 GMT
Subject: Integrated: 8286663: Resolve IDE warnings in WTrayIconPeer and
 SystemTray
In-Reply-To: <KbpNZ7Yzxx6cUu_DQI5QawOSz2BfkC02EgzR28gUiyU=.3c2abcd2-54ba-4eea-803d-d04a611df9ed@github.com>
References: <KbpNZ7Yzxx6cUu_DQI5QawOSz2BfkC02EgzR28gUiyU=.3c2abcd2-54ba-4eea-803d-d04a611df9ed@github.com>
Message-ID: <4rYcWLOSwyPIHdYWLJoWUq1hpS81QrgxBGULoEd8T1E=.03b9c088-a52f-44c7-98fe-e688b7eda632@github.com>

On Mon, 23 May 2022 16:43:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **WTrayIconPeer**: removed duplicate call to `popupParent.dispose()` that might cause NPE (it looks `popupParent` cannot be `null`); organised imports.
> 
> **SystemTray**: removed redundant initialisers; replaced sized array with empty array in `toArray` call; dropped `newValue != null` chained with `equals`.

This pull request has now been integrated.

Changeset: a9b9831f
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a9b9831f2a88ed3b7701d402b167a096b94aeb98
Stats:     33 lines in 2 files changed: 8 ins; 14 del; 11 mod

8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray

Reviewed-by: prr, serb, honkar

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

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


From dnguyen at openjdk.java.net  Wed Jun  8 16:28:35 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Wed, 8 Jun 2022 16:28:35 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v9]
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <U_NRCbYojtWfrJkfmsCEKerXwarRbDjkNmIRI46d_i8=.3d421e1c-c022-4e1e-8bbe-1fea6d3923f8@github.com>

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Updated test.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7446/files
  - new: https://git.openjdk.java.net/jdk/pull/7446/files/d2000f6a..3eb005a3

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

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

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


From dnguyen at openjdk.java.net  Wed Jun  8 16:31:58 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Wed, 8 Jun 2022 16:31:58 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v10]
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <Mix-Pfuquo4qtb2IZtpStIoSfkX9kA1CrmvIpGq5DbM=.1cec6ef2-08ac-43d3-8f09-e9e827b2c526@github.com>

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Renamed test. Updated test again.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7446/files
  - new: https://git.openjdk.java.net/jdk/pull/7446/files/3eb005a3..bc525f5f

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

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

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


From dnguyen at openjdk.java.net  Wed Jun  8 16:31:59 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Wed, 8 Jun 2022 16:31:59 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v4]
In-Reply-To: <v2bakk6jOY2lH6by3zdIKHj_4DuXNL7zPQS-pyVMGpI=.114dfe44-aaef-4b27-ad17-a923acc3e4fd@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <GfNe4SPaVPHLXSdSKAQpG5niCBbh9-AA6EylBsForNQ=.7d5d28de-68db-4ab9-979c-00bffbfabe90@github.com>
 <pj2AY_45bxMDpHOaah4wEhFQLDu4iFpFxfHofNBLMCs=.9a25ac10-a5b6-414f-b7a0-9159258c37f5@github.com>
 <AJmERiLsf08q5j8eXimP0U5dmkR-JEfEM10b0pl4jJ8=.475469c8-cc7d-4050-b052-18e1c2298b93@github.com>
 <v2bakk6jOY2lH6by3zdIKHj_4DuXNL7zPQS-pyVMGpI=.114dfe44-aaef-4b27-ad17-a923acc3e4fd@github.com>
Message-ID: <5z3aJy22SXJnXihrcVMsiwJeOiQT-1n-euqEd2KS6gQ=.76db59b9-6f31-4276-8fec-cbaa391734e2@github.com>

On Tue, 7 Jun 2022 19:20:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Added the header and moved the test to the HTML folder instead since I believe the process involves classes beyond just the Parser. For example, I found that the tags and unknown tags are located in the HTML class. I can move it back if it seems more appropriate since the issue requests changes to the Parser's doc only.
>
> Shall the test name be `HtmlScriptTagParserTest.java`? The test is for testing handling the `<script>` tag only.

Good point. I have renamed the test.

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

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


From dnguyen at openjdk.java.net  Wed Jun  8 16:36:34 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Wed, 8 Jun 2022 16:36:34 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v8]
In-Reply-To: <xP3nv-MtjCNZUeHCAq-s7KFgq8IW-JEz6HN0OztNPAg=.f24369b0-8fa1-4617-bbf2-530bee62f700@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <23EzklXwXRVg1eW3r87i1NFJHvwJFxUFMujEH7N3CQw=.97ed5f39-3f0b-419d-a787-a380c95ead13@github.com>
 <xP3nv-MtjCNZUeHCAq-s7KFgq8IW-JEz6HN0OztNPAg=.f24369b0-8fa1-4617-bbf2-530bee62f700@github.com>
Message-ID: <FRdabJaWHSpzFDooC07jcsMn1GlOOUGvHhPx1ulE5-Q=.299f3643-fe86-4c99-9fde-128ea4546875@github.com>

On Tue, 7 Jun 2022 18:41:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed doc text.
>
> test/jdk/javax/swing/text/html/HtmlTagParserTest.java line 83:
> 
>> 81:     }
>> 82: 
>> 83:     public static void main(String args[]) throws InterruptedException,
> 
> Suggestion:
> 
>     public static void main(String[] args) throws InterruptedException,
> 
> 
> Please use Java-style array declaration.

Thanks for catching that. Also, the reasoning for the test originally using a temporary file to create HTML was to have an HTML file that could be opened itself and compared towards. I see that it's not necessary for this test, but was useful at the time. I thought it could still be useful, but this test with the HTML stored in a string is probably sufficient.

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

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


From aivanov at openjdk.java.net  Wed Jun  8 17:06:45 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 8 Jun 2022 17:06:45 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v8]
In-Reply-To: <FRdabJaWHSpzFDooC07jcsMn1GlOOUGvHhPx1ulE5-Q=.299f3643-fe86-4c99-9fde-128ea4546875@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <23EzklXwXRVg1eW3r87i1NFJHvwJFxUFMujEH7N3CQw=.97ed5f39-3f0b-419d-a787-a380c95ead13@github.com>
 <xP3nv-MtjCNZUeHCAq-s7KFgq8IW-JEz6HN0OztNPAg=.f24369b0-8fa1-4617-bbf2-530bee62f700@github.com>
 <FRdabJaWHSpzFDooC07jcsMn1GlOOUGvHhPx1ulE5-Q=.299f3643-fe86-4c99-9fde-128ea4546875@github.com>
Message-ID: <-jjNog-21ny9LRkIY7hXauc6C6ND8CFD0Cw1TnTWjh4=.cdd89469-ce33-416e-849b-6a02ffacc1a1@github.com>

On Wed, 8 Jun 2022 16:32:30 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> the reasoning for the test originally using a temporary file to create HTML was to have an HTML file that could be opened itself and compared towards. I see that it's not necessary for this test, but was useful at the time. I thought it could still be useful, but this test with the HTML stored in a string is probably sufficient.

It could still be useful. An option to the test, say `-saveHTML`, could be used to get the HTML file to open in browser.

Yet I think it's easier to run the test on its own when you're developing it, no need to define the system property.

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

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


From aivanov at openjdk.java.net  Wed Jun  8 17:06:46 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 8 Jun 2022 17:06:46 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v8]
In-Reply-To: <-jjNog-21ny9LRkIY7hXauc6C6ND8CFD0Cw1TnTWjh4=.cdd89469-ce33-416e-849b-6a02ffacc1a1@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <23EzklXwXRVg1eW3r87i1NFJHvwJFxUFMujEH7N3CQw=.97ed5f39-3f0b-419d-a787-a380c95ead13@github.com>
 <xP3nv-MtjCNZUeHCAq-s7KFgq8IW-JEz6HN0OztNPAg=.f24369b0-8fa1-4617-bbf2-530bee62f700@github.com>
 <FRdabJaWHSpzFDooC07jcsMn1GlOOUGvHhPx1ulE5-Q=.299f3643-fe86-4c99-9fde-128ea4546875@github.com>
 <-jjNog-21ny9LRkIY7hXauc6C6ND8CFD0Cw1TnTWjh4=.cdd89469-ce33-416e-849b-6a02ffacc1a1@github.com>
Message-ID: <lImjsNizT0CN_yKKdBFvuuc35hKOTDhivSE-tDFTfKI=.574d999e-8958-4861-8e70-ba6ba2481960@github.com>

On Wed, 8 Jun 2022 16:59:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Thanks for catching that. Also, the reasoning for the test originally using a temporary file to create HTML was to have an HTML file that could be opened itself and compared towards. I see that it's not necessary for this test, but was useful at the time. I thought it could still be useful, but this test with the HTML stored in a string is probably sufficient.
>
>> the reasoning for the test originally using a temporary file to create HTML was to have an HTML file that could be opened itself and compared towards. I see that it's not necessary for this test, but was useful at the time. I thought it could still be useful, but this test with the HTML stored in a string is probably sufficient.
> 
> It could still be useful. An option to the test, say `-saveHTML`, could be used to get the HTML file to open in browser.
> 
> Yet I think it's easier to run the test on its own when you're developing it, no need to define the system property.

At the same, I noticed a weird behaviour with the file. When I ran the test, class file was located in another directory but the HTML file was in the current directory. Calling `setPage` produced an exception. And `PassFailJFrame` started to behave erratically: it didn't close after clicking Pass or Fail. I didn't look into the reasons why. But it looks as bug in our manual testing framework?

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

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


From dnguyen at openjdk.java.net  Wed Jun  8 17:06:46 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Wed, 8 Jun 2022 17:06:46 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v8]
In-Reply-To: <lImjsNizT0CN_yKKdBFvuuc35hKOTDhivSE-tDFTfKI=.574d999e-8958-4861-8e70-ba6ba2481960@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <23EzklXwXRVg1eW3r87i1NFJHvwJFxUFMujEH7N3CQw=.97ed5f39-3f0b-419d-a787-a380c95ead13@github.com>
 <xP3nv-MtjCNZUeHCAq-s7KFgq8IW-JEz6HN0OztNPAg=.f24369b0-8fa1-4617-bbf2-530bee62f700@github.com>
 <FRdabJaWHSpzFDooC07jcsMn1GlOOUGvHhPx1ulE5-Q=.299f3643-fe86-4c99-9fde-128ea4546875@github.com>
 <-jjNog-21ny9LRkIY7hXauc6C6ND8CFD0Cw1TnTWjh4=.cdd89469-ce33-416e-849b-6a02ffacc1a1@github.com>
 <lImjsNizT0CN_yKKdBFvuuc35hKOTDhivSE-tDFTfKI=.574d999e-8958-4861-8e70-ba6ba2481960@github.com>
Message-ID: <7c55jqwC_OyPWyIX94odiLGrHNL7M_g1-dLX6zY-HbQ=.8b806baa-f08e-4f49-8aeb-17e7682f93cb@github.com>

On Wed, 8 Jun 2022 17:01:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> the reasoning for the test originally using a temporary file to create HTML was to have an HTML file that could be opened itself and compared towards. I see that it's not necessary for this test, but was useful at the time. I thought it could still be useful, but this test with the HTML stored in a string is probably sufficient.
>> 
>> It could still be useful. An option to the test, say `-saveHTML`, could be used to get the HTML file to open in browser.
>> 
>> Yet I think it's easier to run the test on its own when you're developing it, no need to define the system property.
>
> At the same, I noticed a weird behaviour with the file. When I ran the test, class file was located in another directory but the HTML file was in the current directory. Calling `setPage` produced an exception. And `PassFailJFrame` started to behave erratically: it didn't close after clicking Pass or Fail. I didn't look into the reasons why. But it looks as bug in our manual testing framework?

I can look into this as well. Does this exception occur with the current version without the HTML file? I have no issues on my end.

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

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


From aivanov at openjdk.java.net  Wed Jun  8 17:17:34 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 8 Jun 2022 17:17:34 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v8]
In-Reply-To: <7c55jqwC_OyPWyIX94odiLGrHNL7M_g1-dLX6zY-HbQ=.8b806baa-f08e-4f49-8aeb-17e7682f93cb@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <23EzklXwXRVg1eW3r87i1NFJHvwJFxUFMujEH7N3CQw=.97ed5f39-3f0b-419d-a787-a380c95ead13@github.com>
 <xP3nv-MtjCNZUeHCAq-s7KFgq8IW-JEz6HN0OztNPAg=.f24369b0-8fa1-4617-bbf2-530bee62f700@github.com>
 <FRdabJaWHSpzFDooC07jcsMn1GlOOUGvHhPx1ulE5-Q=.299f3643-fe86-4c99-9fde-128ea4546875@github.com>
 <-jjNog-21ny9LRkIY7hXauc6C6ND8CFD0Cw1TnTWjh4=.cdd89469-ce33-416e-849b-6a02ffacc1a1@github.com>
 <lImjsNizT0CN_yKKdBFvuuc35hKOTDhivSE-tDFTfKI=.574d999e-8958-4861-8e70-ba6ba2481960@github.com>
 <7c55jqwC_OyPWyIX94odiLGrHNL7M_g1-dLX6zY-HbQ=.8b806baa-f08e-4f49-8aeb-17e7682f93cb@github.com>
Message-ID: <ZDwMAAgqDYJXqQET8E9s7cyr_RrqHXothYje7t2lrPc=.eae71612-5b57-4904-bca5-89e2e063d7cc@github.com>

On Wed, 8 Jun 2022 17:04:17 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> At the same, I noticed a weird behaviour with the file. When I ran the test, class file was located in another directory but the HTML file was in the current directory. Calling `setPage` produced an exception. And `PassFailJFrame` started to behave erratically: it didn't close after clicking Pass or Fail. I didn't look into the reasons why. But it looks as bug in our manual testing framework?
>
> I can look into this as well. Does this exception occur with the current version without the HTML file? I have no issues on my end.

No, it didn't occur with "embedded" HTML. It occurred with your original version. I compiled the test and `PassFailJFrame` into `./build` directory (javac -d ./build <java-files>` and then ran it `java -cp ./build HtmlTagParserTest`. Since I didn't set the `test.src` property, the HTML file was saved to the current directory but the class file was in another directory, `HtmlTagParserTest.class.getResource` pointed to a non-existent file.

However, now with the button? clicking the button would likely generate an exception too.

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

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


From dnguyen at openjdk.java.net  Wed Jun  8 17:21:36 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Wed, 8 Jun 2022 17:21:36 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v8]
In-Reply-To: <ZDwMAAgqDYJXqQET8E9s7cyr_RrqHXothYje7t2lrPc=.eae71612-5b57-4904-bca5-89e2e063d7cc@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <23EzklXwXRVg1eW3r87i1NFJHvwJFxUFMujEH7N3CQw=.97ed5f39-3f0b-419d-a787-a380c95ead13@github.com>
 <xP3nv-MtjCNZUeHCAq-s7KFgq8IW-JEz6HN0OztNPAg=.f24369b0-8fa1-4617-bbf2-530bee62f700@github.com>
 <FRdabJaWHSpzFDooC07jcsMn1GlOOUGvHhPx1ulE5-Q=.299f3643-fe86-4c99-9fde-128ea4546875@github.com>
 <-jjNog-21ny9LRkIY7hXauc6C6ND8CFD0Cw1TnTWjh4=.cdd89469-ce33-416e-849b-6a02ffacc1a1@github.com>
 <lImjsNizT0CN_yKKdBFvuuc35hKOTDhivSE-tDFTfKI=.574d999e-8958-4861-8e70-ba6ba2481960@github.com>
 <7c55jqwC_OyPWyIX94odiLGrHNL7M_g1-dLX6zY-HbQ=.8b806baa-f08e-4f49-8aeb-17e7682f93cb@github.com>
 <ZDwMAAgqDYJXqQET8E9s7cyr_RrqHXothYje7t2lrPc=.eae71612-5b57-4904-bca5-89e2e063d7cc@github.com>
Message-ID: <A1pQV0H92BNBbqn1QQTXGbQEDkCaao_178lgLIdHO-A=.1c537911-808d-40d1-874e-d9424d3757dc@github.com>

On Wed, 8 Jun 2022 17:14:10 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I can look into this as well. Does this exception occur with the current version without the HTML file? I have no issues on my end.
>
> No, it didn't occur with "embedded" HTML. It occurred with your original version. I compiled the test and `PassFailJFrame` into `./build` directory (javac -d ./build <java-files>` and then ran it `java -cp ./build HtmlTagParserTest`. Since I didn't set the `test.src` property, the HTML file was saved to the current directory but the class file was in another directory, `HtmlTagParserTest.class.getResource` pointed to a non-existent file.
> 
> However, now with the button? clicking the button would likely generate an exception too.

I'll remove the button then as it's not necessary for the test. I mainly added it to demonstrate that HTML contents are rendering correctly. I'll make this change and update the doc for Parser to more explicitly explain what happens when its editable vs non-editable.

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

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


From dnguyen at openjdk.java.net  Wed Jun  8 17:39:27 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Wed, 8 Jun 2022 17:39:27 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v11]
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <bJbHXsdk-7YFNuuyuLBahcpg4XZc7xsrGYjUiUTJRng=.91a448e5-ff7b-4570-b4e2-b71f9f2b47e9@github.com>

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Updated test html. Updated Parser doc.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7446/files
  - new: https://git.openjdk.java.net/jdk/pull/7446/files/bc525f5f..c57fdc3c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7446&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7446&range=09-10

  Stats: 11 lines in 2 files changed: 5 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7446.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7446/head:pull/7446

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


From duke at openjdk.java.net  Wed Jun  8 17:46:33 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:46:33 GMT
Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int)
 [v4]
In-Reply-To: <4K3rhX2RGM_yaCKKJALcP7EplXS2pJXM8zYGNGEg-6Y=.c03f7730-b26a-459a-8d60-ea8ab9149603@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
 <zFlFjdt_WK9VyWsAxqnfhvu-MmJe1IKc7WtyBNkPE5A=.ec807db1-ad90-4e27-99d7-8a1ea145aa71@github.com>
 <S9LU83ceTWEKtLvzA4D63u3Qysv4rk6f83rZ7QvfR5E=.936ea9b1-c42b-47c7-8a98-4c8803c67fe8@github.com>
 <xW_IMRaU3A70QAxx5vnH990FVkxQnTq1EAf-F7rz3Nw=.17ca4b0e-ee2b-45bb-8cd1-c380bb6a0990@github.com>
 <4K3rhX2RGM_yaCKKJALcP7EplXS2pJXM8zYGNGEg-6Y=.c03f7730-b26a-459a-8d60-ea8ab9149603@github.com>
Message-ID: <I6KYBeCQX2UL3oyZRSoJS5kebHUgVdaeMie1rZaMmYo=.44589461-05c3-48f6-add0-9ef7fc6b7f69@github.com>

On Thu, 28 Apr 2022 16:33:48 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> I'm getting a bit tired of seeing these JDK wide changes with lots of files touched.
>> Delete all changes in desktop from this PR and re-submit them as a separate PR.
>> 
>> Also do not change J2DBench. We deliberately avoid using new API so that we can take it and
>> run it on very old JDK versions to help track regressions.
>
> @prrace
> 
>> Delete all changes in desktop from this PR and re-submit them as a separate PR.
> 
> changes to java.desktop reverted.
> 
>> Also do not change J2DBench. We deliberately avoid using new API so that we can take it and run it on very old JDK versions to help track regressions.
> 
> For J2DBench, I don't see any changes that not complicated with older jdk version for now. please recheck. thanks.

> @XenoAmess This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

comment

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

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


From lbourges at openjdk.java.net  Wed Jun  8 17:47:40 2022
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 8 Jun 2022 17:47:40 GMT
Subject: RFR: 8264999: GeneralPath.lineTo() to itself produces jagged lines
In-Reply-To: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
References: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
Message-ID: <mY2KQAUrLbR1jYKNkF1nNHuRutIWSkw087ziaPJ6fig=.716ef2a9-d819-4625-a6d1-48570698a2d4@github.com>

On Mon, 30 May 2022 01:15:01 GMT, Jeremy <duke at openjdk.java.net> wrote:

> Previously when you drew a line that moved exactly (+0, +0) with a miter stroke the Stroker class acted like a horizontal miter was appropriate. Now we abort instead, so no miter is applied.
> 
> The new unit test tests the original steps plus several variations.
> 
> I'm a little nervous about this change because it looks like someone previously considered this exact condition and implemented a different behavior. I don't think I understand the original rationale.

As mentioned in my code review, the stroker changes need one more condition: (prev == drawTo) return.

I tested this change and it fixes the bug's test code and your test code looks good.

Please update PR with the proposed change and we are good.

Deadline: tomorrow, sorry.

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

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


From aivanov at openjdk.java.net  Wed Jun  8 18:13:33 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 8 Jun 2022 18:13:33 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v8]
In-Reply-To: <A1pQV0H92BNBbqn1QQTXGbQEDkCaao_178lgLIdHO-A=.1c537911-808d-40d1-874e-d9424d3757dc@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <23EzklXwXRVg1eW3r87i1NFJHvwJFxUFMujEH7N3CQw=.97ed5f39-3f0b-419d-a787-a380c95ead13@github.com>
 <xP3nv-MtjCNZUeHCAq-s7KFgq8IW-JEz6HN0OztNPAg=.f24369b0-8fa1-4617-bbf2-530bee62f700@github.com>
 <FRdabJaWHSpzFDooC07jcsMn1GlOOUGvHhPx1ulE5-Q=.299f3643-fe86-4c99-9fde-128ea4546875@github.com>
 <-jjNog-21ny9LRkIY7hXauc6C6ND8CFD0Cw1TnTWjh4=.cdd89469-ce33-416e-849b-6a02ffacc1a1@github.com>
 <lImjsNizT0CN_yKKdBFvuuc35hKOTDhivSE-tDFTfKI=.574d999e-8958-4861-8e70-ba6ba2481960@github.com>
 <7c55jqwC_OyPWyIX94odiLGrHNL7M_g1-dLX6zY-HbQ=.8b806baa-f08e-4f49-8aeb-17e7682f93cb@github.com>
 <ZDwMAAgqDYJXqQET8E9s7cyr_RrqHXothYje7t2lrPc=.eae71612-5b57-4904-bca5-89e2e063d7cc@github.com>
 <A1pQV0H92BNBbqn1QQTXGbQEDkCaao_178lgLIdHO-A=.1c537911-808d-40d1-874e-d9424d3757dc@github.com>
Message-ID: <dLG3FG1W4RqtplO6Zq_gSSjp2K9l7mg4pktj6SxWejg=.a3616ae9-4dfa-40d0-96eb-39405e1f7efa@github.com>

On Wed, 8 Jun 2022 17:18:20 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> No, it didn't occur with "embedded" HTML. It occurred with your original version. I compiled the test and `PassFailJFrame` into `./build` directory (`javac -d ./build <java-files>` and then ran it `java -cp ./build HtmlTagParserTest`. Since I didn't set the `test.src` property, the HTML file was saved to the current directory but the class file was in another directory, `HtmlTagParserTest.class.getResource` pointed to a non-existent file.
>> 
>> However, now with the button? clicking the button would likely generate an exception too.
>
> I'll remove the button then as it's not necessary for the test. I mainly added it to demonstrate that HTML contents are rendering correctly. I'll make this change and update the doc for Parser to more explicitly explain what happens when its editable vs non-editable.

It looks good overall.

It started with `<script>` tag; the text in javadoc refers to other unknown or unsupported tags. Shall the test be expanded with an unknown tag?

Displaying two instances of `JEditorPane` where one's editable and the other isn't could be too confusing. Only editable is enough, I guess.

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

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


From achung at openjdk.java.net  Wed Jun  8 18:17:06 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 8 Jun 2022 18:17:06 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v22]
In-Reply-To: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
Message-ID: <IvNM54AZ_JlJs5p_cmg01aQ-E4JZmoMVgQu3HC3mNL0=.58e283cd-f58b-46ed-aef0-165d0b655df2@github.com>

> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

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

  made suggested changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7449/files
  - new: https://git.openjdk.java.net/jdk/pull/7449/files/8f71abac..adca6ef7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=20-21

  Stats: 14 lines in 2 files changed: 5 ins; 6 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449

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


From dnguyen at openjdk.java.net  Wed Jun  8 18:25:29 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Wed, 8 Jun 2022 18:25:29 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v12]
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <3LSOggcPj4fdDgUQSDF8estxyqjcJ86gprEuVu6JG5Q=.00946447-02d9-4bb1-824e-aedcf6a55285@github.com>

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Added unknown tag to test.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7446/files
  - new: https://git.openjdk.java.net/jdk/pull/7446/files/c57fdc3c..ac1baf92

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7446&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7446&range=10-11

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

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


From dnguyen at openjdk.java.net  Wed Jun  8 18:25:32 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Wed, 8 Jun 2022 18:25:32 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v8]
In-Reply-To: <dLG3FG1W4RqtplO6Zq_gSSjp2K9l7mg4pktj6SxWejg=.a3616ae9-4dfa-40d0-96eb-39405e1f7efa@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <23EzklXwXRVg1eW3r87i1NFJHvwJFxUFMujEH7N3CQw=.97ed5f39-3f0b-419d-a787-a380c95ead13@github.com>
 <xP3nv-MtjCNZUeHCAq-s7KFgq8IW-JEz6HN0OztNPAg=.f24369b0-8fa1-4617-bbf2-530bee62f700@github.com>
 <FRdabJaWHSpzFDooC07jcsMn1GlOOUGvHhPx1ulE5-Q=.299f3643-fe86-4c99-9fde-128ea4546875@github.com>
 <-jjNog-21ny9LRkIY7hXauc6C6ND8CFD0Cw1TnTWjh4=.cdd89469-ce33-416e-849b-6a02ffacc1a1@github.com>
 <lImjsNizT0CN_yKKdBFvuuc35hKOTDhivSE-tDFTfKI=.574d999e-8958-4861-8e70-ba6ba2481960@github.com>
 <7c55jqwC_OyPWyIX94odiLGrHNL7M_g1-dLX6zY-HbQ=.8b806baa-f08e-4f49-8aeb-17e7682f93cb@github.com>
 <ZDwMAAgqDYJXqQET8E9s7cyr_RrqHXothYje7t2lrPc=.eae71612-5b57-4904-bca5-89e2e063d7cc@github.com>
 <A1pQV0H92BNBbqn1QQTXGbQEDkCaao_178lgLIdHO-A=.1c537911-808d-40d1-874e-d9424d3757dc@github.com>
 <dLG3FG1W4RqtplO6Zq_gSSjp2K9l7mg4pktj6SxWejg=.a3616ae9-4dfa-40d0-96eb-39405e1f7efa@github.com>
Message-ID: <DCqD_1RDEHhrj1_L_tCJwwWgZw7ms9owPOXAsPgRS34=.de06bf7a-7740-47ed-8dcb-e8485a8b4011@github.com>

On Wed, 8 Jun 2022 18:10:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I'll remove the button then as it's not necessary for the test. I mainly added it to demonstrate that HTML contents are rendering correctly. I'll make this change and update the doc for Parser to more explicitly explain what happens when its editable vs non-editable.
>
> It looks good overall.
> 
> It started with `<script>` tag; the text in javadoc refers to other unknown or unsupported tags. Shall the test be expanded with an unknown tag?
> 
> Displaying two instances of `JEditorPane` where one's editable and the other isn't could be too confusing. Only editable is enough, I guess.

Sure, I added a foo tag with text inside. Behavior still displays as expected and stated in the doc.

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

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


From achung at openjdk.java.net  Wed Jun  8 18:35:32 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 8 Jun 2022 18:35:32 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v23]
In-Reply-To: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
Message-ID: <jgqo4WIaoWa4SWowp8b8my3KDhjafU6U27_KQygK4cY=.fac08812-2d2e-4cc9-a8e4-9854fa11e4ac@github.com>

> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

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

  fixed spacing

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7449/files
  - new: https://git.openjdk.java.net/jdk/pull/7449/files/adca6ef7..24d7cee3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=22
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=21-22

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

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


From prr at openjdk.java.net  Wed Jun  8 18:35:38 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 8 Jun 2022 18:35:38 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v22]
In-Reply-To: <IvNM54AZ_JlJs5p_cmg01aQ-E4JZmoMVgQu3HC3mNL0=.58e283cd-f58b-46ed-aef0-165d0b655df2@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <IvNM54AZ_JlJs5p_cmg01aQ-E4JZmoMVgQu3HC3mNL0=.58e283cd-f58b-46ed-aef0-165d0b655df2@github.com>
Message-ID: <wOEpUjGdUSfCJZIGjvcJrQ-6rClWWjYXU4Af8ObIq88=.160954b0-79e7-423c-97c6-cd6b03f288f9@github.com>

On Wed, 8 Jun 2022 18:17:06 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   made suggested changes

test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 177:

> 175:         JPanel contentPanel;
> 176:         contentPanel = new JPanel();
> 177:         contentPanel.setLayout(new BoxLayout(contentPanel, BoxLayout.Y_AXIS));

JPanel contentPanel = new JPanel();

test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 182:

> 180:         for (int i = 0; i < 4; i++) {
> 181:             JPanel childPanel;
> 182:             childPanel = new JPanel(new BorderLayout());

JPanel childPanel = new JPanel(new BorderLayout());

test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 189:

> 187: 
> 188:             contentPanel.add(childPanel);
> 189:             if(childSize == null) {

Is it your IDE settings ? You've added another case of "if(" ..

test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 218:

> 216:         if (show) {
> 217:             JFrame frame;
> 218:             frame = new JFrame("Swing Test");

JFrame frame = new JFrame("Swing Test");

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

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


From achung at openjdk.java.net  Wed Jun  8 18:37:55 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 8 Jun 2022 18:37:55 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v24]
In-Reply-To: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
Message-ID: <BF9PTJwcYmMGb5dryaR9vtYptE_-dxekSYAEi0e1vyY=.bb645b9b-af7e-457c-ada5-207ad284f5dc@github.com>

> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

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

  fixed declarations

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7449/files
  - new: https://git.openjdk.java.net/jdk/pull/7449/files/24d7cee3..325d09b4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=23
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=22-23

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

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


From prr at openjdk.java.net  Wed Jun  8 19:48:46 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 8 Jun 2022 19:48:46 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v24]
In-Reply-To: <BF9PTJwcYmMGb5dryaR9vtYptE_-dxekSYAEi0e1vyY=.bb645b9b-af7e-457c-ada5-207ad284f5dc@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <BF9PTJwcYmMGb5dryaR9vtYptE_-dxekSYAEi0e1vyY=.bb645b9b-af7e-457c-ada5-207ad284f5dc@github.com>
Message-ID: <uhKcVdHqYgruoFPYbi-AULEDwTzFv8R_JxwwdRZvEWQ=.829096dd-36d8-4c92-a7c5-2024b5a8922b@github.com>

On Wed, 8 Jun 2022 18:37:55 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed declarations

Marked as reviewed by prr (Reviewer).

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

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


From serb at openjdk.java.net  Wed Jun  8 19:55:33 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 8 Jun 2022 19:55:33 GMT
Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F [v12]
In-Reply-To: <qd-_7mPrASxGie-wVGAsMEkSvZH4pdJNLk8aN7Re3OA=.3be0d782-925b-4050-9342-ef2058eaf1b7@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
 <qd-_7mPrASxGie-wVGAsMEkSvZH4pdJNLk8aN7Re3OA=.3be0d782-925b-4050-9342-ef2058eaf1b7@github.com>
Message-ID: <yEpSJcyL2L0Y0Yuf1M6JanvHkTDZ0lVgBHIyOeO6_nQ=.1ad39035-6241-46eb-b2d8-08356f4ccac0@github.com>

On Wed, 8 Jun 2022 14:09:24 GMT, Tejesh R <tr at openjdk.org> wrote:

>> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.
>
> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updated Copyright
>  - Reverting imports ordering

Marked as reviewed by serb (Reviewer).

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

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


From aturbanov at openjdk.java.net  Wed Jun  8 21:11:14 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 8 Jun 2022 21:11:14 GMT
Subject: RFR: 8288067: Avoid redundant HashMap.containsKey call in
 Type1Font.expandAbbreviation
Message-ID: <exTMLQfyRyGxS7uX9BXbpm6L_j6I2R7I3ieI-2p_PIs=.fcac2faa-231c-4bf4-8fef-7829c0783e2e@github.com>

Instead of pair HashMap.containsKey/HashMap.get method calls, we can use single call HashMap.getOrDefault.
It's faster and clearer.

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

Commit messages:
 - [PATCH] Avoid redundant HashMap.containsKey call in Type1Font.expandAbbreviation

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

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


From aivanov at openjdk.java.net  Wed Jun  8 21:32:53 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 8 Jun 2022 21:32:53 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v24]
In-Reply-To: <BF9PTJwcYmMGb5dryaR9vtYptE_-dxekSYAEi0e1vyY=.bb645b9b-af7e-457c-ada5-207ad284f5dc@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <BF9PTJwcYmMGb5dryaR9vtYptE_-dxekSYAEi0e1vyY=.bb645b9b-af7e-457c-ada5-207ad284f5dc@github.com>
Message-ID: <ReJ6n95-BISIlqH4cA5nwYR8TRL2Iv6Qauc5lQCGTws=.7f443706-303f-4d57-ba14-af6de2809ebb@github.com>

On Wed, 8 Jun 2022 18:37:55 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed declarations

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 173:

> 171:             }
> 172:             RenderingHints rend =
> 173:                     new RenderingHints(RenderingHints.KEY_STROKE_CONTROL, RenderingHints.VALUE_STROKE_PURE);

If using `VALUE_STROKE_PURE` changes nothing, should it be removed then?

Moreover, the hints aren't applied to anything.

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 204:

> 202: 
> 203:         // Set the transform we removed earlier
> 204:         if (g instanceof Graphics2D) {

The condition should be
Suggestion:

        if (resetTransform) {


If `resetTransform` is `true`, then `g` is an instance of `Graphics2D`.

If `resetTransform` is `false`, there's nothing to restore anyway.

test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 44:

> 42:  * @bug 8279614
> 43:  * @summary The left line of the TitledBorder is not painted on 150 scale factor
> 44:  * @requires (os.family == "windows")

It's still unclear to me whether we leave the requirement for Windows only or remove it. It came up a few times but no clear decision has been taken.

The change is not Windows-specific, the test is not Windows-specific, it can be run on other platforms. However, fractional UI scales aren't supported on other platforms but Windows; at the same time, applying fractional scales to `Graphics` when painting to a `BufferedImage` is supported.

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

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


From achung at openjdk.java.net  Wed Jun  8 22:25:12 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 8 Jun 2022 22:25:12 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v25]
In-Reply-To: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
Message-ID: <5OeF1xoZhJSeVPXfYvAaLVXD4z3SJI7sUj8Mp19dQ9w=.ecb50ef6-2c7b-42cb-a6dc-95268662f56d@github.com>

> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

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

  removed rendering hints, changed condition to reapply old transform

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7449/files
  - new: https://git.openjdk.java.net/jdk/pull/7449/files/325d09b4..35e7d5a8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=24
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=23-24

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

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


From aivanov at openjdk.java.net  Wed Jun  8 22:35:45 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 8 Jun 2022 22:35:45 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v25]
In-Reply-To: <5OeF1xoZhJSeVPXfYvAaLVXD4z3SJI7sUj8Mp19dQ9w=.ecb50ef6-2c7b-42cb-a6dc-95268662f56d@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <5OeF1xoZhJSeVPXfYvAaLVXD4z3SJI7sUj8Mp19dQ9w=.ecb50ef6-2c7b-42cb-a6dc-95268662f56d@github.com>
Message-ID: <zS8XwXkeVbbqdoArRJ9hAhlynGS0vA4CYrvQWWKI_ng=.3ef2afee-03ec-4672-a8e4-6e58367f97f2@github.com>

On Wed, 8 Jun 2022 22:25:12 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed rendering hints, changed condition to reapply old transform

Looks good to me.

The question about limiting the test to Windows only is still open.

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

Marked as reviewed by aivanov (Reviewer).

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


From aivanov at openjdk.java.net  Wed Jun  8 22:45:43 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 8 Jun 2022 22:45:43 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v25]
In-Reply-To: <5OeF1xoZhJSeVPXfYvAaLVXD4z3SJI7sUj8Mp19dQ9w=.ecb50ef6-2c7b-42cb-a6dc-95268662f56d@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <5OeF1xoZhJSeVPXfYvAaLVXD4z3SJI7sUj8Mp19dQ9w=.ecb50ef6-2c7b-42cb-a6dc-95268662f56d@github.com>
Message-ID: <4p0Hu6kjL0vKi2-tDQY41slAKGYm2rPmQs9VgTWSXNc=.1e48064b-687f-46a5-a6f0-c6e9a4490468@github.com>

On Wed, 8 Jun 2022 22:25:12 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed rendering hints, changed condition to reapply old transform

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 158:

> 156:         AffineTransform at = new AffineTransform();
> 157:         Stroke oldStk = new BasicStroke();
> 158:         int stkWidth = 1;

Now the usage of these variables is restricted to the case where `resetTransform` is set to `true`. Therefore, they can be left uninitialised here; a value is assigned before it's used in all the code paths as far as I can see.

It's just a small (premature) optimisation, it avoids creating two objects. I don't insist though.

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

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


From duke at openjdk.java.net  Thu Jun  9 02:16:45 2022
From: duke at openjdk.java.net (Jeremy)
Date: Thu, 9 Jun 2022 02:16:45 GMT
Subject: RFR: 8264999: GeneralPath.lineTo() to itself produces jagged lines
 [v2]
In-Reply-To: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
References: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
Message-ID: <SN3lGFf3sEY8EDg60gRDEZYfIdNAQsOebYquyFgIC1g=.e9ca74e6-d589-4cad-9539-d7b7a64ef31e@github.com>

> Previously when you drew a line that moved exactly (+0, +0) with a miter stroke the Stroker class acted like a horizontal miter was appropriate. Now we abort instead, so no miter is applied.
> 
> The new unit test tests the original steps plus several variations.
> 
> I'm a little nervous about this change because it looks like someone previously considered this exact condition and implemented a different behavior. I don't think I understand the original rationale.

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

  JDK-8264999: GeneralPath.lineTo() to itself produces jagged lines
  
  Adding "&& prev == DRAWING_OP_TO" per Laurent's code review.
  
  I also redid the unit tests. Before this change, with the new unit tests: one scenario failed. With this change: four scenarios failed.
  
  For now I've commented out the failing tests. The failing tests are not the same as the original bug; they are related considerations we should also test against, but IMO they are not essential for the resolution of jdk-8264999.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8943/files
  - new: https://git.openjdk.java.net/jdk/pull/8943/files/7c29da9d..c7e35275

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

  Stats: 248 lines in 2 files changed: 124 ins; 26 del; 98 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8943.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8943/head:pull/8943

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


From duke at openjdk.java.net  Thu Jun  9 02:20:32 2022
From: duke at openjdk.java.net (Jeremy)
Date: Thu, 9 Jun 2022 02:20:32 GMT
Subject: RFR: 8264999: GeneralPath.lineTo() to itself produces jagged lines
 [v2]
In-Reply-To: <SN3lGFf3sEY8EDg60gRDEZYfIdNAQsOebYquyFgIC1g=.e9ca74e6-d589-4cad-9539-d7b7a64ef31e@github.com>
References: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
 <SN3lGFf3sEY8EDg60gRDEZYfIdNAQsOebYquyFgIC1g=.e9ca74e6-d589-4cad-9539-d7b7a64ef31e@github.com>
Message-ID: <y8aEp0gu6jU3vJFzR2F17OEEk0NnXB6rzk8ruv1L3Y0=.ba34ccc0-fa5f-43e0-bdef-f344b793ff42@github.com>

On Thu, 9 Jun 2022 02:16:45 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> Previously when you drew a line that moved exactly (+0, +0) with a miter stroke the Stroker class acted like a horizontal miter was appropriate. Now we abort instead, so no miter is applied.
>> 
>> The new unit test tests the original steps plus several variations.
>> 
>> I'm a little nervous about this change because it looks like someone previously considered this exact condition and implemented a different behavior. I don't think I understand the original rationale.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8264999: GeneralPath.lineTo() to itself produces jagged lines
>   
>   Adding "&& prev == DRAWING_OP_TO" per Laurent's code review.
>   
>   I also redid the unit tests. Before this change, with the new unit tests: one scenario failed. With this change: four scenarios failed.
>   
>   For now I've commented out the failing tests. The failing tests are not the same as the original bug; they are related considerations we should also test against, but IMO they are not essential for the resolution of jdk-8264999.

Sorry I must have missed that code review.

I just pushed an update with your proposal.

On further review: I was dissatisfied with the unit tests, so I rewrote them. Some fail now. (Both before and after this commit.)

I commented out the failing test scenarios in this commit. They are not strictly required to resolve this ticket, so I'm not sure what our protocol is. (We could try to resolve these unit tests now so everything passes? Or we could submit a separate ticket for the remaining scenarios? Or something else?)

I'm open to suggestions regarding next steps.

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

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


From lbourges at openjdk.java.net  Thu Jun  9 05:43:20 2022
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 9 Jun 2022 05:43:20 GMT
Subject: RFR: 8264999: GeneralPath.lineTo() to itself produces jagged lines
 [v2]
In-Reply-To: <SN3lGFf3sEY8EDg60gRDEZYfIdNAQsOebYquyFgIC1g=.e9ca74e6-d589-4cad-9539-d7b7a64ef31e@github.com>
References: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
 <SN3lGFf3sEY8EDg60gRDEZYfIdNAQsOebYquyFgIC1g=.e9ca74e6-d589-4cad-9539-d7b7a64ef31e@github.com>
Message-ID: <mq_aFfs3HCBip-3kEAug9y2Am2BFg6bBM9O-H179WHI=.79873996-2adb-4bee-a4c4-93e7f356a5f1@github.com>

On Thu, 9 Jun 2022 02:16:45 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> Previously when you drew a line that moved exactly (+0, +0) with a miter stroke the Stroker class acted like a horizontal miter was appropriate. Now we abort instead, so no miter is applied.
>> 
>> The new unit test tests the original steps plus several variations.
>> 
>> I'm a little nervous about this change because it looks like someone previously considered this exact condition and implemented a different behavior. I don't think I understand the original rationale.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8264999: GeneralPath.lineTo() to itself produces jagged lines
>   
>   Adding "&& prev == DRAWING_OP_TO" per Laurent's code review.
>   
>   I also redid the unit tests. Before this change, with the new unit tests: one scenario failed. With this change: four scenarios failed.
>   
>   For now I've commented out the failing tests. The failing tests are not the same as the original bug; they are related considerations we should also test against, but IMO they are not essential for the resolution of jdk-8264999.

I will try your test code today and see why some tests fail.

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

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


From smandalika at openjdk.java.net  Thu Jun  9 07:26:20 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 9 Jun 2022 07:26:20 GMT
Subject: RFR: 8286172: Create an automated test for JDK-4516019 [v3]
In-Reply-To: <lAQZthlNPKA2vOejKdfEJ5aLiEfifijBS8l-Y_BT3_o=.fb0d426a-c040-4647-a0f3-df848784217c@github.com>
References: <lAQZthlNPKA2vOejKdfEJ5aLiEfifijBS8l-Y_BT3_o=.fb0d426a-c040-4647-a0f3-df848784217c@github.com>
Message-ID: <Aw5nL5Bpf8WqMf6RNGaEtKDVigRB2gT7AlwzQA89YGI=.0e133a1e-72db-465d-8e2a-7d2c684b5f5c@github.com>

> Create an automated test for [JDK-4516019](https://bugs.openjdk.java.net/browse/JDK-4516019)
> 
> Clicking on the increment/decrement buttons of the spinner does not install focus on the spinner or one of its focusable children.
> 
> The test validates the same.
> 
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed: replaced sleep with robot.waitForIdle

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8546/files
  - new: https://git.openjdk.java.net/jdk/pull/8546/files/b4fef8cd..69264c7e

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

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

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


From smandalika at openjdk.java.net  Thu Jun  9 07:32:29 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 9 Jun 2022 07:32:29 GMT
Subject: RFR: 8286172: Create an automated test for JDK-4516019 [v4]
In-Reply-To: <lAQZthlNPKA2vOejKdfEJ5aLiEfifijBS8l-Y_BT3_o=.fb0d426a-c040-4647-a0f3-df848784217c@github.com>
References: <lAQZthlNPKA2vOejKdfEJ5aLiEfifijBS8l-Y_BT3_o=.fb0d426a-c040-4647-a0f3-df848784217c@github.com>
Message-ID: <qszRSkeqzMN-7mAWy2OTGqRBHjrsDgKMMIjlQkcDR80=.f13c6c67-ea7e-4e6d-b08a-6112b6404fa4@github.com>

> Create an automated test for [JDK-4516019](https://bugs.openjdk.java.net/browse/JDK-4516019)
> 
> Clicking on the increment/decrement buttons of the spinner does not install focus on the spinner or one of its focusable children.
> 
> The test validates the same.
> 
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed: replaced sleep with robot.waitForIdle

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8546/files
  - new: https://git.openjdk.java.net/jdk/pull/8546/files/69264c7e..b5dfdcd3

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

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

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


From tr at openjdk.java.net  Thu Jun  9 08:15:39 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Thu, 9 Jun 2022 08:15:39 GMT
Subject: Integrated: 6429812: NPE after calling JTable.updateUI() when using a
 header renderer + XP L&F
In-Reply-To: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
References: <me8azQB8qlNs-T_3h3i84BZqxCGxPAL6zA9VMaRDIao=.10160d21-84d1-40f4-af7b-a5df5c8d4446@github.com>
Message-ID: <u-Fg1QoMWZZGRvHCrmTULtNEfv-CWYcitWkgMA7Quos=.e96bc52b-3852-4279-8a20-5caaf8be1ce9@github.com>

On Mon, 23 May 2022 07:03:03 GMT, Tejesh R <tr at openjdk.org> wrote:

> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE.

This pull request has now been integrated.

Changeset: 5a89cb01
Author:    Tejesh R <tr at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5a89cb01bc92408648a3b59b63251ec8d0b67558
Stats:     153 lines in 2 files changed: 143 ins; 3 del; 7 mod

6429812: NPE after calling JTable.updateUI() when using a header renderer + XP L&F

Reviewed-by: aivanov, serb

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

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


From smandalika at openjdk.java.net  Thu Jun  9 08:35:39 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 9 Jun 2022 08:35:39 GMT
Subject: RFR: 8286172: Create an automated test for JDK-4516019 [v2]
In-Reply-To: <aFW6j1UoIWrkMX27AMLRFJOMUFxrgRw4Mhfej4asHG8=.decc3916-79c6-4972-b838-123cdca69ca5@github.com>
References: <lAQZthlNPKA2vOejKdfEJ5aLiEfifijBS8l-Y_BT3_o=.fb0d426a-c040-4647-a0f3-df848784217c@github.com>
 <r9LKisCDmtWcaa0i62VnKjuLgwBDEK6cuGPXa_QvCuk=.10ac7907-8b79-4328-8b3b-179588a23613@github.com>
 <aFW6j1UoIWrkMX27AMLRFJOMUFxrgRw4Mhfej4asHG8=.decc3916-79c6-4972-b838-123cdca69ca5@github.com>
Message-ID: <OCU86KXf4XnTZBc3zJTqgbFJk-WxDuR4NV3mSZNe6R4=.7eb13f55-50ef-4848-a871-d210184406ce@github.com>

On Mon, 23 May 2022 17:20:38 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Review comments fixed: Fixed file path, removed redundant sleep call etc.
>>  - Review comments fixed: Removed file under the 'bug id' folder structure
>
> test/jdk/javax/swing/JSpinner/JSpinnerFocusTest.java line 69:
> 
>> 67:         try {
>> 68:             SwingUtilities.invokeAndWait(() -> createGUI());
>> 69:             Thread.sleep(1000);
> 
> Would it be better to make robot a global variable and use Robot.waitForIdle() here? Sleeping might slow down the test unnecessarily

Fixed as suggested.

> test/jdk/javax/swing/JSpinner/JSpinnerFocusTest.java line 71:
> 
>> 69:             Thread.sleep(1000);
>> 70:             runTest();
>> 71:             Thread.sleep(1000);
> 
> same here

Fixed as suggested.

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

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


From aivanov at openjdk.java.net  Thu Jun  9 10:39:43 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 9 Jun 2022 10:39:43 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <5TQwHRdWYkstuTYOtDyzJsbFLIAl0WNppp6COIVUSKI=.8869e869-fbe6-46ae-bb55-e6c0aa6b5db9@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
 <5TQwHRdWYkstuTYOtDyzJsbFLIAl0WNppp6COIVUSKI=.8869e869-fbe6-46ae-bb55-e6c0aa6b5db9@github.com>
Message-ID: <X0jN-Xr4IdBpHoOS515GE5CoMyk41e0N5LgBEPTm0QY=.51a0cbd3-0bb0-44eb-b4a1-e6474c8bde80@github.com>

On Mon, 6 Jun 2022 22:53:11 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Here, in the name of resolving this issue finally i have reverted the ImageIcon changes, instead i added some code that creates the properly scaled version of icon when requested variant is not available.

This looks good!

> I am not going trough all the experiments with the SHDefExtractIcon again - at least not in this pull request.

I absolutely agree, not in this pull request.

However, I'm for submitting a bug or two to explore other possibilities.

> I checked and there is no performance impact at all from the latest changes on the 100% scaled screens due to the extracting an additional icon - looks like Windows extracts it anyways even if we specify null as a icon information reference - it just does not pass it down.

It could be the case. The shell may keep and likely keeps a cache of file icons for small and large icons.

Windows used to have only two sizes of icons: `SM_CXSMICON` and `SM_CXICON` which have 16 and 32 values by default; the values were even customisable via Control Panel. Modern systems deal with more sizes.

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

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


From aivanov at openjdk.java.net  Thu Jun  9 10:54:25 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 9 Jun 2022 10:54:25 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v6]
In-Reply-To: <Ynva90EcdSNf7EyAxZorJNsbqjqpYZjyggv2MOPlK10=.4478324f-75ac-4b52-9d6a-695dbae8f311@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <Ynva90EcdSNf7EyAxZorJNsbqjqpYZjyggv2MOPlK10=.4478324f-75ac-4b52-9d6a-695dbae8f311@github.com>
Message-ID: <NMl9ZMujyoEiSULY9U15liOwv5d56Iv92g80PKkEZp8=.1fde405f-3e7a-4a2c-bed0-59206f722ba7@github.com>

On Mon, 6 Jun 2022 23:47:15 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Detect the situation where we do need to perform interpolation during ImageIcon
>> painting and set a hint to the rendering to perform bicubic approximation so
>> image details are preserved during transition.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the line ends

Since `test.not` is for this test only, would `WindowsDefaultIconSizeTest.test.not` be a better name for the test file?

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

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


From aivanov at openjdk.java.net  Thu Jun  9 10:54:25 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 9 Jun 2022 10:54:25 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <DeqLg0CSyiHoE-Ao6Ct0ii0LdAS3jpbJd48IF30Rcls=.75c71c01-8136-4d2b-9f7b-ee701a7a24db@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
 <ms8g1-XqOxHCBTQIO8vyRbli10-TE_m1rjaJhDPf1AM=.281afbc5-bf1a-427a-9dd8-3476db10b7e1@github.com>
 <DeqLg0CSyiHoE-Ao6Ct0ii0LdAS3jpbJd48IF30Rcls=.75c71c01-8136-4d2b-9f7b-ee701a7a24db@github.com>
Message-ID: <Z7pF6Xu5iu5ghtVEd10lrd8VWKoT0kwGPCvQ6i2uCvU=.63b88812-b967-4ebd-a7af-d996b2f27d56@github.com>

On Thu, 2 Jun 2022 17:24:10 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> > Do we need to update the size value and take into account the low/hi sizes?
> 
> Not exactly, the issue is that for some files (but just for some of them) this call ignores the high icon size parameter and always returns the set of small and large icons as 16x16 plus 32x32. For the rest of the files it returns 16x16 and the requested size. If low size is not set it is assumed to be 16x16 so we can omit setting it.

I can't see anything about that in the documentation for [`IExtractIconW::Extract`](https://docs.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-iextracticonw-extract) which says:

`nIconSize` - The desired size of the icon, in pixels. The low word contains the size of the large icon, and the high word contains the size of the small icon.

For the return value, the documentation says, _?Returns S_OK if the function extracted the icon, or S_FALSE if the calling application should extract the icon.?_ We don't even check the return value.

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

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


From aivanov at openjdk.java.net  Thu Jun  9 10:54:26 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 9 Jun 2022 10:54:26 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v4]
In-Reply-To: <vd6hL784lg90KIH5z5LqDcljCew_dC0QakUZWP-qoz8=.840cbedc-7898-4dab-ad62-24a4755c0f3c@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <zvuAg5GgKtYFcSWimwCiTZGXBtDw6keH4pbfi1aASfQ=.16ee8788-b18a-4218-be2b-4fa9b479bfdb@github.com>
 <ms8g1-XqOxHCBTQIO8vyRbli10-TE_m1rjaJhDPf1AM=.281afbc5-bf1a-427a-9dd8-3476db10b7e1@github.com>
 <DeqLg0CSyiHoE-Ao6Ct0ii0LdAS3jpbJd48IF30Rcls=.75c71c01-8136-4d2b-9f7b-ee701a7a24db@github.com>
 <3Dse5Mi4Lsodr2ytpTSGqNaRLiUcp4928refltpwCGw=.d3c9d1e7-8954-4356-badf-dcd2f8209fbf@github.com>
 <hl8lDVSGj2qwmGkMMWQdyOPmjb7JaMQubQEHq42lndA=.9620b494-085b-4b4e-a5b1-e42a9a99061b@github.com>
 <14w5H3NqVoh17cITByBhbUSlXUvf1o6C5_te0W0KSig=.0e13f718-4ad2-4194-875b-3d8cc4f0f950@github.com>
 <kbyTvN6HV-1DIJxW56O1TRk9sBEhlUEb_ghDoSXF2Mg=.2cc95f11-bc7f-4282-af92-e9619f575895@github.com>
 <Nes5fFygjwIKFa6lnzNk-FtIsJNTV7eu2Tu87wwKrKI=.6142730c-ff27-4800-9a3b-3651542be6e6@github.com>
 <EMnVzwnT_PlmJzvLJyfonDXzzFGnTBD018biUqIwl0o=.cbdbea2c-c0fd-4c72-a5b8-078cbb506e18@github.com>
 <vd6hL784lg90KIH5z5LqDcljCew_dC0QakU
 ZWP-qoz8=.840cbedc-7898-4dab-ad62-24a4755c0f3c@github.com>
Message-ID: <4z8kuT2i0Mbdz1uANzVNocRjs0NMjrGWGikyaqsmjsw=.f8194e31-d7b9-4f1b-8ea8-204574b59e64@github.com>

On Fri, 3 Jun 2022 21:48:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Because for some files - and we can not predict which files these are - function will always return set of 16x16 and 32x32 icons - no matter what we request. For the icons that return proper sizes we do request exact sizes and use them.
>> 
>> How do we request the proper size for the example above when the scale is 1.25 and the "small" image? The requested size should be 20x20 but we will request 16x16 or 32x32 and then upscale/downscale, no?
>
>> No, because in case when current implementation returns bad results this function also returns incorrect results so it is hardly a backup.
> 
> Are you sure? That article said the opposite and suggest to use SHDefExtractIcon if the simple extract fails. Probably we should recheck why it does not work for your old testing it seems this should be even faster since it read only one image instead of small+large.

> > Can we try to do that via different API: https://devblogs.microsoft.com/oldnewthing/20140501-00/?p=1103 probably it will work better?
> 
> No, during initial implementation i tried it and it worked even worse and less stable.

I can't remember `SHDefExtractIcon` was even tried. According to the documentation for `IExtractIconW::Extract` and to [the article](https://devblogs.microsoft.com/oldnewthing/20140501-00/?p=1103), another method is to be used when `IExtractIconW::Extract` returns `S_FALSE`.

Previously, [we discussed](https://github.com/openjdk/jdk/pull/380#issuecomment-702999573) Raymond Chen's post [The format of icon resources](https://devblogs.microsoft.com/oldnewthing/20120720-00/?p=7083) and [`LookupIconIdFromDirectoryEx`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-lookupiconidfromdirectoryex) function.

> No, on the next iteration we will extract 16x16 and 64x64. So on each iteration we are going to extract additionally 16x16 icon and if size is 24 or more than we will ignore it. Since all the icons requested are cached that will not cause any performance degradation.

I must admit I still don't like this approach much, we extract 16?16 icon even when we don't need it.

Is it better to request small icon only when the size is less than 32?

I think it makes sense to submit a bug to explore using `LookupIconIdFromDirectoryEx` to extract icons so that we have the set of icons which is provided provided in the resources and avoid getting scaled icons. There should be another bug to add fallback to using `SHDefExtractIcon` for the case where `IExtractIconW::Extract` returns `S_FALSE`.

These are separate issues from the icon rendering, even though icon extraction issues revealed the problem with rendering, scaling up/down the icons to be specific.

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

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


From aivanov at openjdk.java.net  Thu Jun  9 11:00:35 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 9 Jun 2022 11:00:35 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v6]
In-Reply-To: <Ynva90EcdSNf7EyAxZorJNsbqjqpYZjyggv2MOPlK10=.4478324f-75ac-4b52-9d6a-695dbae8f311@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <Ynva90EcdSNf7EyAxZorJNsbqjqpYZjyggv2MOPlK10=.4478324f-75ac-4b52-9d6a-695dbae8f311@github.com>
Message-ID: <Aq5otebZI3L3toJ16Fz4_9O_KTSEvVAjQA0N9tfGHV8=.0daadaa0-f102-4d56-bf2e-6c2de1304ad2@github.com>

On Mon, 6 Jun 2022 23:47:15 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Detect the situation where we do need to perform interpolation during ImageIcon
>> painting and set a hint to the rendering to perform bicubic approximation so
>> image details are preserved during transition.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the line ends

Does the generic problem still exist? The one that you demonstrated with a sample image?

If the user loads an icon which has lines, the lines may disappear if the icon is scaled down. The problem could be seen with regular `ImageIcon` too, not necessarily with a `MultiResolutionImage`.

The solution is to apply BICUBIC rendering hint, which could be not as easy: the icon is likely used in a Swing component rather than rendered directly.

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

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


From mbaesken at openjdk.java.net  Thu Jun  9 11:47:06 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 9 Jun 2022 11:47:06 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling
Message-ID: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>

We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.

Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
VALID_VS_VERSIONS="2019 2017 2022"
Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

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

Commit messages:
 - JDK-8288094

Changes: https://git.openjdk.java.net/jdk/pull/9105/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9105&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288094
  Stats: 144 lines in 9 files changed: 0 ins; 131 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9105.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9105/head:pull/9105

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


From smandalika at openjdk.java.net  Thu Jun  9 12:23:36 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 9 Jun 2022 12:23:36 GMT
Subject: RFR: JDK-8282777: Create a Regression test for JDK-4515031 [v4]
In-Reply-To: <dFeJPOsPxOsqk9eJGz3QXoJLyWDnhewLIw0Ua-te6p4=.51421e06-4109-4972-9237-6f250d6d4ee1@github.com>
References: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
 <biuNRTk1cDCX9sXiuAmu8PqE-PMajJ8_rCZJRD9-0RM=.aef786ef-5583-4206-8471-0fa2f54d6237@github.com>
 <dFeJPOsPxOsqk9eJGz3QXoJLyWDnhewLIw0Ua-te6p4=.51421e06-4109-4972-9237-6f250d6d4ee1@github.com>
Message-ID: <XGR2mzsaW-ZE87Fe0aZTKKtvQotlN2TkDYgit0PO230=.109bfcb1-dfd0-40f0-89a1-c28b6a4833a1@github.com>

On Mon, 23 May 2022 17:11:24 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review Comments Fixed: Fixed File location path.
>
> test/jdk/javax/accessibility/JFileChooserAccessibleDescriptionTest.java line 89:
> 
>> 87:             robot.keyPress(KeyEvent.VK_C);
>> 88:             robot.keyRelease(KeyEvent.VK_C);
>> 89:             robot.keyRelease(KeyEvent.VK_ALT);
> 
> What is the purpose of the pressing Alt-C here? Looks like on Mac OS X it does nothing and when i comment them out the test runs in the same way as with it.

As suggested, I have removed this redundant code and verified it on the windows,mac and linux platforms to be working fine.

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

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


From smandalika at openjdk.java.net  Thu Jun  9 12:24:37 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 9 Jun 2022 12:24:37 GMT
Subject: RFR: 8284524: Create an automated test for JDK-4422362 [v3]
In-Reply-To: <ASMCKuK4Ur54E_sI13yc-5J9BZlH8thmHe5a8fWwxYI=.6160ccaf-36b9-4838-bb6a-a845840fc5d8@github.com>
References: <Zc6TLIeUCxotLqICjVkZF4g1hUTkdB7mANhMull6Qzc=.14959182-424c-42f6-979f-7d6eeb266dfb@github.com>
 <ASMCKuK4Ur54E_sI13yc-5J9BZlH8thmHe5a8fWwxYI=.6160ccaf-36b9-4838-bb6a-a845840fc5d8@github.com>
Message-ID: <F1WGwtVtUA95U34tqhJZTYmRa81vfqwd-kIKrD_qvIs=.62967bd2-0243-42b4-aaf4-fb00c5384680@github.com>

On Wed, 18 May 2022 08:38:49 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422362](https://bugs.openjdk.java.net/browse/JDK-4422362)
>> 
>> The BoundedRangeModel components (JScrollBar, JSlider, JProgressBar) return
>> BoundedRangeModel.getMaximum() from getMaximumAccessibleValue() in their
>> AccessibleValue implementation.
>> The real maximum value (due to the constraints on BoundedRangeModel) is
>> model.getMaximum() - model.getExtent().
>> 
>> The test verifies that the above is adhered to as expected.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: Fixed File location path.

Hi! Can someone please take a look at this PR and provide their valuable feedback ?

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

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


From smandalika at openjdk.java.net  Thu Jun  9 12:24:39 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Thu, 9 Jun 2022 12:24:39 GMT
Subject: RFR: 8284767: Create an automated test for JDK-4422535 [v3]
In-Reply-To: <3rXFVh7JvLK-ycYNRlmK8tTqTpmrs7GuF0lxiaO78kQ=.9f972f36-f57f-4cf1-a2d8-58feba441f71@github.com>
References: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
 <3rXFVh7JvLK-ycYNRlmK8tTqTpmrs7GuF0lxiaO78kQ=.9f972f36-f57f-4cf1-a2d8-58feba441f71@github.com>
Message-ID: <eoOuHy9nRZD5I9n6mXBNYMMM49TPQKfXhrad89iRHfo=.56d5a284-4495-4069-bf18-2b615b5bf49b@github.com>

On Wed, 18 May 2022 08:37:03 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422535](https://bugs.openjdk.java.net/browse/JDK-4422535)
>> AccessibleValue implementation only accept Integers
>> The AccessibleValue implementations of the following components:
>> 
>> java.awt.Scrollbar
>> javax.swing.AbstractButton
>> javax.swing.JInternalFrame
>> javax.swing.JSplitPane
>> javax.swing.JScrollBar
>> javax.swing.JProgressBar
>> javax.swing.JSlider
>> 
>> require the argument to setCurrentAccessibleValue(Number) to be an Integer, else they completely ignore it - it returns a false indicating that the value has not been set by the return value, but they cannot know the reason for that).
>> 
>> The test verifies that for each of the above components, the AccessibleValue is set when it is set to a Number (Float, Double, long etc) and not just for an Integer.
>> 
>> his review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: Fixed File location path.

Hi! Can someone please take a look at this PR and provide their valuable feedback ?

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

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


From aivanov at openjdk.java.net  Thu Jun  9 13:03:37 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 9 Jun 2022 13:03:37 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v6]
In-Reply-To: <NMl9ZMujyoEiSULY9U15liOwv5d56Iv92g80PKkEZp8=.1fde405f-3e7a-4a2c-bed0-59206f722ba7@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <Ynva90EcdSNf7EyAxZorJNsbqjqpYZjyggv2MOPlK10=.4478324f-75ac-4b52-9d6a-695dbae8f311@github.com>
 <NMl9ZMujyoEiSULY9U15liOwv5d56Iv92g80PKkEZp8=.1fde405f-3e7a-4a2c-bed0-59206f722ba7@github.com>
Message-ID: <HYXI7IBqy97fGFrogdI5ORlb-PLv5uudEPQTHhI03n8=.d9317233-b6a1-4044-83a5-979fe9002d4b@github.com>

On Thu, 9 Jun 2022 10:50:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Since `test.not` is for this test only, would `WindowsDefaultIconSizeTest.test.not` be a better name for the test file?

Better yet is to create the file dynamically in the test code?

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

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


From achung at openjdk.java.net  Thu Jun  9 15:33:35 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 9 Jun 2022 15:33:35 GMT
Subject: RFR: 8284767: Create an automated test for JDK-4422535 [v3]
In-Reply-To: <3rXFVh7JvLK-ycYNRlmK8tTqTpmrs7GuF0lxiaO78kQ=.9f972f36-f57f-4cf1-a2d8-58feba441f71@github.com>
References: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
 <3rXFVh7JvLK-ycYNRlmK8tTqTpmrs7GuF0lxiaO78kQ=.9f972f36-f57f-4cf1-a2d8-58feba441f71@github.com>
Message-ID: <GHinScDLWTk2jSIwULD6vJr6x-VYdc5u-xAwypv4CN0=.53598437-1f0d-41df-9196-b883a5139f07@github.com>

On Wed, 18 May 2022 08:37:03 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422535](https://bugs.openjdk.java.net/browse/JDK-4422535)
>> AccessibleValue implementation only accept Integers
>> The AccessibleValue implementations of the following components:
>> 
>> java.awt.Scrollbar
>> javax.swing.AbstractButton
>> javax.swing.JInternalFrame
>> javax.swing.JSplitPane
>> javax.swing.JScrollBar
>> javax.swing.JProgressBar
>> javax.swing.JSlider
>> 
>> require the argument to setCurrentAccessibleValue(Number) to be an Integer, else they completely ignore it - it returns a false indicating that the value has not been set by the return value, but they cannot know the reason for that).
>> 
>> The test verifies that for each of the above components, the AccessibleValue is set when it is set to a Number (Float, Double, long etc) and not just for an Integer.
>> 
>> his review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: Fixed File location path.

Marked as reviewed by achung (Author).

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

PR: https://git.openjdk.org/jdk/pull/8220


From dnguyen at openjdk.java.net  Thu Jun  9 18:15:03 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Thu, 9 Jun 2022 18:15:03 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v13]
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <fl4LtVyoXfiaQhLY3FMnaO1HtS35ZIfbKAhYNGLSQus=.74efb62e-1158-4004-8823-ba98663f1b86@github.com>

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Updated doc.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/7446/files
  - new: https://git.openjdk.org/jdk/pull/7446/files/ac1baf92..4ddb26d7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7446&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7446&range=11-12

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

PR: https://git.openjdk.org/jdk/pull/7446


From prr at openjdk.java.net  Thu Jun  9 18:47:26 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 9 Jun 2022 18:47:26 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v25]
In-Reply-To: <4p0Hu6kjL0vKi2-tDQY41slAKGYm2rPmQs9VgTWSXNc=.1e48064b-687f-46a5-a6f0-c6e9a4490468@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <5OeF1xoZhJSeVPXfYvAaLVXD4z3SJI7sUj8Mp19dQ9w=.ecb50ef6-2c7b-42cb-a6dc-95268662f56d@github.com>
 <4p0Hu6kjL0vKi2-tDQY41slAKGYm2rPmQs9VgTWSXNc=.1e48064b-687f-46a5-a6f0-c6e9a4490468@github.com>
Message-ID: <yRnCrnUxByPUfcZLJUdOcy4F-KEnkzgrkE85lDtqrDI=.b3323f8c-c9a9-4a97-831b-b36de4317ad1@github.com>

On Wed, 8 Jun 2022 22:41:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed rendering hints, changed condition to reapply old transform
>
> src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 158:
> 
>> 156:         AffineTransform at = new AffineTransform();
>> 157:         Stroke oldStk = new BasicStroke();
>> 158:         int stkWidth = 1;
> 
> Now the usage of these variables is restricted to the case where `resetTransform` is set to `true`. Therefore, they can be left uninitialised here; a value is assigned before it's used in all the code paths as far as I can see.
> 
> It's just a small (premature) optimisation, it avoids creating two objects. I don't insist though.

I'd be inclined to remove the initialisation.

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

PR: https://git.openjdk.org/jdk/pull/7449


From prr at openjdk.java.net  Thu Jun  9 18:47:29 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 9 Jun 2022 18:47:29 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v24]
In-Reply-To: <ReJ6n95-BISIlqH4cA5nwYR8TRL2Iv6Qauc5lQCGTws=.7f443706-303f-4d57-ba14-af6de2809ebb@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <BF9PTJwcYmMGb5dryaR9vtYptE_-dxekSYAEi0e1vyY=.bb645b9b-af7e-457c-ada5-207ad284f5dc@github.com>
 <ReJ6n95-BISIlqH4cA5nwYR8TRL2Iv6Qauc5lQCGTws=.7f443706-303f-4d57-ba14-af6de2809ebb@github.com>
Message-ID: <CLMBUkFJQqUOBS5CNwlmtdGl_4o63sbX8B2Bf8VssEQ=.11f01007-08d1-4a9b-ad71-370590056969@github.com>

On Wed, 8 Jun 2022 21:30:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed declarations
>
> test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 44:
> 
>> 42:  * @bug 8279614
>> 43:  * @summary The left line of the TitledBorder is not painted on 150 scale factor
>> 44:  * @requires (os.family == "windows")
> 
> It's still unclear to me whether we leave the requirement for Windows only or remove it. It came up a few times but no clear decision has been taken.
> 
> The change is not Windows-specific, the test is not Windows-specific, it can be run on other platforms. However, fractional UI scales aren't supported on other platforms but Windows; at the same time, applying fractional scales to `Graphics` when painting to a `BufferedImage` is supported.

I think it sufficient to make it Windows-specific at this time.
The BufferedImage case is extremely uncommon.
Mac is integer only and we don't have any timeline for supporting fractional scaling on Linux

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

PR: https://git.openjdk.org/jdk/pull/7449


From prr at openjdk.java.net  Thu Jun  9 19:09:08 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 9 Jun 2022 19:09:08 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v13]
In-Reply-To: <fl4LtVyoXfiaQhLY3FMnaO1HtS35ZIfbKAhYNGLSQus=.74efb62e-1158-4004-8823-ba98663f1b86@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <fl4LtVyoXfiaQhLY3FMnaO1HtS35ZIfbKAhYNGLSQus=.74efb62e-1158-4004-8823-ba98663f1b86@github.com>
Message-ID: <FWRfzHFEuF3DDOJEX21ta5XECBz9BoT3XU0j6Lmzmi0=.5c44e797-ea44-4d98-9c9c-9cca550b8c60@github.com>

On Thu, 9 Jun 2022 18:15:03 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated doc.

This looks OK. My only two quibbles are (1) Instead of "the editor" maybe you could be more precise as to what editor this means and (2) it still feels a little odd to say in the Parser doc what the "editor" does.

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/7446


From achung at openjdk.java.net  Thu Jun  9 19:11:26 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 9 Jun 2022 19:11:26 GMT
Subject: RFR: 8286172: Create an automated test for JDK-4516019 [v4]
In-Reply-To: <qszRSkeqzMN-7mAWy2OTGqRBHjrsDgKMMIjlQkcDR80=.f13c6c67-ea7e-4e6d-b08a-6112b6404fa4@github.com>
References: <lAQZthlNPKA2vOejKdfEJ5aLiEfifijBS8l-Y_BT3_o=.fb0d426a-c040-4647-a0f3-df848784217c@github.com>
 <qszRSkeqzMN-7mAWy2OTGqRBHjrsDgKMMIjlQkcDR80=.f13c6c67-ea7e-4e6d-b08a-6112b6404fa4@github.com>
Message-ID: <Doniqc04hXiXmFIKqsL-oSre0WJSNEibXzYE6OPIR0s=.5322f812-7c3b-41cb-aff1-fcf1c677713f@github.com>

On Thu, 9 Jun 2022 07:32:29 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4516019](https://bugs.openjdk.java.net/browse/JDK-4516019)
>> 
>> Clicking on the increment/decrement buttons of the spinner does not install focus on the spinner or one of its focusable children.
>> 
>> The test validates the same.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: replaced sleep with robot.waitForIdle

Marked as reviewed by achung (Author).

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

PR: https://git.openjdk.org/jdk/pull/8546


From aivanov at openjdk.java.net  Thu Jun  9 19:38:13 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 9 Jun 2022 19:38:13 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v24]
In-Reply-To: <CLMBUkFJQqUOBS5CNwlmtdGl_4o63sbX8B2Bf8VssEQ=.11f01007-08d1-4a9b-ad71-370590056969@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <BF9PTJwcYmMGb5dryaR9vtYptE_-dxekSYAEi0e1vyY=.bb645b9b-af7e-457c-ada5-207ad284f5dc@github.com>
 <ReJ6n95-BISIlqH4cA5nwYR8TRL2Iv6Qauc5lQCGTws=.7f443706-303f-4d57-ba14-af6de2809ebb@github.com>
 <CLMBUkFJQqUOBS5CNwlmtdGl_4o63sbX8B2Bf8VssEQ=.11f01007-08d1-4a9b-ad71-370590056969@github.com>
Message-ID: <NyimJOzk8mN401bAzTFFppxgmFP6P4qCP2TiuwXg6Rg=.af5cc51e-720d-488a-bf59-768fa5b2c25b@github.com>

On Thu, 9 Jun 2022 18:44:53 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 44:
>> 
>>> 42:  * @bug 8279614
>>> 43:  * @summary The left line of the TitledBorder is not painted on 150 scale factor
>>> 44:  * @requires (os.family == "windows")
>> 
>> It's still unclear to me whether we leave the requirement for Windows only or remove it. It came up a few times but no clear decision has been taken.
>> 
>> The change is not Windows-specific, the test is not Windows-specific, it can be run on other platforms. However, fractional UI scales aren't supported on other platforms but Windows; at the same time, applying fractional scales to `Graphics` when painting to a `BufferedImage` is supported.
>
> I think it sufficient to make it Windows-specific at this time.
> The BufferedImage case is extremely uncommon.
> Mac is integer only and we don't have any timeline for supporting fractional scaling on Linux

Sounds reasonable. Let's leave it Windows-specific.

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

PR: https://git.openjdk.org/jdk/pull/7449


From aivanov at openjdk.java.net  Thu Jun  9 20:27:09 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 9 Jun 2022 20:27:09 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed [v2]
In-Reply-To: <ktVuNTIc6nLToUQ_l5AzNF99gWK--71qUQDK3OVwHlo=.2e927921-6504-4f86-86b3-92fba42e7bc5@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
 <tA6NanagDur6PgX8_CfFc2x-YgjknkKPCHJcvEmqGF0=.df8f5ac3-bdc1-488d-a79a-11dcde368be9@github.com>
 <DiaaEHludW7a2Aa3NSLZIHACxUC0hGTWWCdcRimD3VQ=.42cb8dc5-c2a9-43c9-922d-c5cc1b3b29ce@github.com>
 <ktVuNTIc6nLToUQ_l5AzNF99gWK--71qUQDK3OVwHlo=.2e927921-6504-4f86-86b3-92fba42e7bc5@github.com>
Message-ID: <5a03vAMfkMnFN7maIyKNjzsv4vhED-ssWpE8jE9zacM=.cb079e84-0091-467e-a9f4-1fbaf9c1f0cb@github.com>

On Tue, 7 Jun 2022 09:00:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/text/CSSBorder/6796710/bug6796710.java line 147:
>> 
>>> 145:         MultiResolutionImage img = robot.createMultiResolutionScreenCapture(rect);
>>> 146:         return (BufferedImage)img.getResolutionVariant(rect.width, rect.height);
>>> 147:         //return robot.createScreenCapture(rect);
>> 
>> Isn't the old and new code should get the same result? The old createScreenCapture always creates an image of the low dpi quality. The createMultiResolutionScreenCapture creates two images low/hi dpi, but since you request the same size "rect" the low dpi image is returned, no?
>
> Maybe it's different in iMac systems..I dont have access to this system to analyse further nor do I have much knowledge on this 2D/awt multiresolution image side of things..

If I remember correctly, MRI will contain only one image captured by Robot, so it would return the only image it stores, which would not be scaled down if High DPI is in effect.

However, the test is supposed to run with `UIScale=1`, so this should make any difference.

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

PR: https://git.openjdk.org/jdk/pull/9011


From duke at openjdk.java.net  Thu Jun  9 20:33:06 2022
From: duke at openjdk.java.net (duke)
Date: Thu, 9 Jun 2022 20:33:06 GMT
Subject: Withdrawn: 8274082 : Wrong test case name specified in jtreg run tag
 for java/awt/print/PrinterJob/SwingUIText.java
In-Reply-To: <ZCvrnk1meFmsJa3Q5hk2onn7kUQL18cxrktRywdActc=.befc4c76-c87c-4261-8888-0cee83df9a80@github.com>
References: <ZCvrnk1meFmsJa3Q5hk2onn7kUQL18cxrktRywdActc=.befc4c76-c87c-4261-8888-0cee83df9a80@github.com>
Message-ID: <97dfegvybb_BGlb7U445uMe0Gi-ezlZn_o4WSNq40bo=.7dc81771-8ad4-4407-b21c-213a0cf33f79@github.com>

On Thu, 24 Mar 2022 20:24:35 GMT, lawrence.andrews <duke at openjdk.java.net> wrote:

> Following issues were fixed in this test 
> 1) Fixed - Parser error due to yesno in @run main/manual=yesno
> 2) Fixed Wrong test name specified in @run jtreg
> @run main/manual=yesno PrintTextTest . It should be @run main/manual=yesno SwingUIText
> 3) Instruction frame does not have 'Pass' or 'Fail' button to mark the test as Pass or Fail after verifying Text on UI and print out. 
> 4) Fixed - Test UI ( test instruction frame, UI frame and Print Dialog) just gets disposed automatically without interacting via running the test case with jtreg. 
> 
> @shurymury

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/7946


From lbourges at openjdk.java.net  Thu Jun  9 20:51:02 2022
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 9 Jun 2022 20:51:02 GMT
Subject: RFR: 8264999: GeneralPath.lineTo() to itself produces jagged lines
 [v2]
In-Reply-To: <SN3lGFf3sEY8EDg60gRDEZYfIdNAQsOebYquyFgIC1g=.e9ca74e6-d589-4cad-9539-d7b7a64ef31e@github.com>
References: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
 <SN3lGFf3sEY8EDg60gRDEZYfIdNAQsOebYquyFgIC1g=.e9ca74e6-d589-4cad-9539-d7b7a64ef31e@github.com>
Message-ID: <iQCyi5y4KIcPXe6OL1c-9-VX5pgaiboheWSCMpt1-yw=.2a828874-ca1e-4a98-a5c1-a8ea6202d099@github.com>

On Thu, 9 Jun 2022 02:16:45 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> Previously when you drew a line that moved exactly (+0, +0) with a miter stroke the Stroker class acted like a horizontal miter was appropriate. Now we abort instead, so no miter is applied.
>> 
>> The new unit test tests the original steps plus several variations.
>> 
>> I'm a little nervous about this change because it looks like someone previously considered this exact condition and implemented a different behavior. I don't think I understand the original rationale.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8264999: GeneralPath.lineTo() to itself produces jagged lines
>   
>   Adding "&& prev == DRAWING_OP_TO" per Laurent's code review.
>   
>   I also redid the unit tests. Before this change, with the new unit tests: one scenario failed. With this change: four scenarios failed.
>   
>   For now I've commented out the failing tests. The failing tests are not the same as the original bug; they are related considerations we should also test against, but IMO they are not essential for the resolution of jdk-8264999.

Jeremy,
I fixed the bug in the marlin renderer repository, see the Stroker fix:
https://github.com/bourgesl/marlin-renderer/commit/b7adf5e606ca0b809118dfe5ab85d4fcf71bd12b#diff-17283d07a3ba6855b0e01eb58cc579c0543b6fae142eb7192dbaa9c9a55e8ef0

Moreover I confirm your 4 disabled tests fail for a good reason: the expected path ignores [...] but the tested path not.
In these cases, the expected path (move only) draws nothing, but the tested path (m + ...) will draw something !
Maybe @prrace could confirm ?

Here is the passing test on my side: https://github.com/bourgesl/marlin-renderer/commit/b7adf5e606ca0b809118dfe5ab85d4fcf71bd12b#diff-38152f6e0b7e1a267ef1391ec7fea12086ce9b573a55d0bbb7f84bb7eb15170e

Please fix the Stroker as proposed, the fix looks good to me (not a reviewer)

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

PR: https://git.openjdk.org/jdk/pull/8943


From prr at openjdk.java.net  Thu Jun  9 21:59:33 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 9 Jun 2022 21:59:33 GMT
Subject: RFR: 8272998: ImageIO.read() throws incorrect exception type
Message-ID: <7P_RTUjGWttc7Wpknqa7CCPgNIssyX4xT--MjQ_R5po=.be6078e7-bb89-4b23-9b55-6d8fe93c70f6@github.com>

ImageIO.read() only documents IOException for any kind of decoding problem and since
it is a convenience API we don't want to start requiring applications to handle other RuntimeExceptions.
So in the unlikely case of some problem decoding using this API, wrap any RuntimeException in
an IIOException. This will give more stable app behaviour and still report the underlying problem.

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

Commit messages:
 - 8272998
 - 8272998

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

PR: https://git.openjdk.org/jdk/pull/9113


From duke at openjdk.java.net  Fri Jun 10 00:30:17 2022
From: duke at openjdk.java.net (Jeremy)
Date: Fri, 10 Jun 2022 00:30:17 GMT
Subject: RFR: 8264999: GeneralPath.lineTo() to itself produces jagged lines
 [v3]
In-Reply-To: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
References: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
Message-ID: <KtXkjRAh-5oI_KT65S0yCL_d_rxHNF-62mJJ1tvqSYE=.9142ccd0-83fc-4958-a49d-45667a617313@github.com>

> Previously when you drew a line that moved exactly (+0, +0) with a miter stroke the Stroker class acted like a horizontal miter was appropriate. Now we abort instead, so no miter is applied.
> 
> The new unit test tests the original steps plus several variations.
> 
> I'm a little nervous about this change because it looks like someone previously considered this exact condition and implemented a different behavior. I don't think I understand the original rationale.

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

  JDK-8264999: GeneralPath.lineTo() to itself produces jagged lines
  
  Separating "prev == DRAWING_OP_TO" condition per Laurent's code review.
  
  I also reorganized & commented on the unit test scenarios, including a few new commented out scenarios.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8943/files
  - new: https://git.openjdk.org/jdk/pull/8943/files/c7e35275..f14b5598

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

  Stats: 42 lines in 2 files changed: 32 ins; 8 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8943.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8943/head:pull/8943

PR: https://git.openjdk.org/jdk/pull/8943


From duke at openjdk.java.net  Fri Jun 10 01:24:48 2022
From: duke at openjdk.java.net (Jeremy)
Date: Fri, 10 Jun 2022 01:24:48 GMT
Subject: RFR: 8264999: GeneralPath.lineTo() to itself produces jagged lines
 [v4]
In-Reply-To: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
References: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
Message-ID: <zDQ9DQXj6qgiY0yWof30AAchwCBfEmYlyozs0Dzvv8c=.6b4629e7-7fc0-487e-9c34-32216bcfb8c6@github.com>

> Previously when you drew a line that moved exactly (+0, +0) with a miter stroke the Stroker class acted like a horizontal miter was appropriate. Now we abort instead, so no miter is applied.
> 
> The new unit test tests the original steps plus several variations.
> 
> I'm a little nervous about this change because it looks like someone previously considered this exact condition and implemented a different behavior. I don't think I understand the original rationale.

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

  JDK-8264999: GeneralPath.lineTo() to itself produces jagged lines
  
  Revising failing (commented out) scenarios.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8943/files
  - new: https://git.openjdk.org/jdk/pull/8943/files/f14b5598..328eb462

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

  Stats: 18 lines in 1 file changed: 9 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/8943.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8943/head:pull/8943

PR: https://git.openjdk.org/jdk/pull/8943


From duke at openjdk.java.net  Fri Jun 10 01:24:48 2022
From: duke at openjdk.java.net (Jeremy)
Date: Fri, 10 Jun 2022 01:24:48 GMT
Subject: RFR: 8264999: GeneralPath.lineTo() to itself produces jagged lines
 [v3]
In-Reply-To: <KtXkjRAh-5oI_KT65S0yCL_d_rxHNF-62mJJ1tvqSYE=.9142ccd0-83fc-4958-a49d-45667a617313@github.com>
References: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
 <KtXkjRAh-5oI_KT65S0yCL_d_rxHNF-62mJJ1tvqSYE=.9142ccd0-83fc-4958-a49d-45667a617313@github.com>
Message-ID: <oHFHqqVvy-h-aDOT8akOXaVRCCrcRnI75aBwd7aaonw=.93928557-e84e-4c7f-8818-20cc427a2bf8@github.com>

On Fri, 10 Jun 2022 00:30:17 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> Previously when you drew a line that moved exactly (+0, +0) with a miter stroke the Stroker class acted like a horizontal miter was appropriate. Now we abort instead, so no miter is applied.
>> 
>> The new unit test tests the original steps plus several variations.
>> 
>> I'm a little nervous about this change because it looks like someone previously considered this exact condition and implemented a different behavior. I don't think I understand the original rationale.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8264999: GeneralPath.lineTo() to itself produces jagged lines
>   
>   Separating "prev == DRAWING_OP_TO" condition per Laurent's code review.
>   
>   I also reorganized & commented on the unit test scenarios, including a few new commented out scenarios.

OK, the logic is revised as requested:

I also revised the failing scenarios (now commented out). I would be happy to discuss those further, but IMO those should not impede the resolution of this ticket.

(There is, yet again, a new disabled scenario that fails.)

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

PR: https://git.openjdk.org/jdk/pull/8943


From tr at openjdk.java.net  Fri Jun 10 05:43:49 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Fri, 10 Jun 2022 05:43:49 GMT
Subject: RFR: 8284619: javax/swing/JTable/8236907/LastVisibleRow.java failed
 with "Test Case Failed!!, Last Row not Visible!!!"
Message-ID: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>

Fix history - #7422.
The test is automatic and check if the last row is painted (Which was not happening before the fix, the last row appeared only after MouseClick operation) by capturing the last row before and after MouseClick Operation.If the both the captured images are same, then the test passes else it fails.
This Fix includes for ubuntu and macos failure, in which only the test case failed due to following reasons.

In ubuntu, the test fails due to unexpected dark line appearing on right side of last row before MouseClick operation.
In macos, the test fails since after MouseClick operation of last row, clearSelection didn't show any effect on the selected row.
The issue is intermittent and not able to reproduce it frequently. As a defensive fix, the rectangular area which is being captured is reduce for ubuntu failure and Delay is added between ClearSelection of focus and Image Capture for macos failure

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

Commit messages:
 - Updated the fix
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge branch 'master' of github.com:TejeshR13/jdk
 - Merge branch 'openjdk:master' into master
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge branch 'master' of github.com:TejeshR13/jdk
 - Initial Commit.

Changes: https://git.openjdk.org/jdk/pull/9117/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9117&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8284619
  Stats: 44 lines in 2 files changed: 2 ins; 35 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/9117.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9117/head:pull/9117

PR: https://git.openjdk.org/jdk/pull/9117


From serb at openjdk.java.net  Fri Jun 10 05:46:01 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 10 Jun 2022 05:46:01 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed [v2]
In-Reply-To: <5a03vAMfkMnFN7maIyKNjzsv4vhED-ssWpE8jE9zacM=.cb079e84-0091-467e-a9f4-1fbaf9c1f0cb@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
 <tA6NanagDur6PgX8_CfFc2x-YgjknkKPCHJcvEmqGF0=.df8f5ac3-bdc1-488d-a79a-11dcde368be9@github.com>
 <DiaaEHludW7a2Aa3NSLZIHACxUC0hGTWWCdcRimD3VQ=.42cb8dc5-c2a9-43c9-922d-c5cc1b3b29ce@github.com>
 <ktVuNTIc6nLToUQ_l5AzNF99gWK--71qUQDK3OVwHlo=.2e927921-6504-4f86-86b3-92fba42e7bc5@github.com>
 <5a03vAMfkMnFN7maIyKNjzsv4vhED-ssWpE8jE9zacM=.cb079e84-0091-467e-a9f4-1fbaf9c1f0cb@github.com>
Message-ID: <tlXy1lpQkB_Hqie3Zo7U9G4_WDA1t6AAIZduGPoBgvg=.3aa8332f-bc2a-40e4-9a45-853fa148ed7f@github.com>

On Thu, 9 Jun 2022 20:22:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Maybe it's different in iMac systems..I dont have access to this system to analyse further nor do I have much knowledge on this 2D/awt multiresolution image side of things..
>
> If I remember correctly, MRI will contain only one image captured by Robot, so it would return the only image it stores, which would not be scaled down if High DPI is in effect.
> 
> However, the test is supposed to run with `UIScale=1`, so this should make any difference.

On the HiDPI screen that MRI will have two images, and my expectation is that the image requested by the updated test and the image used before the fix should be the same.

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

PR: https://git.openjdk.org/jdk/pull/9011


From lbourges at openjdk.java.net  Fri Jun 10 05:49:01 2022
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 10 Jun 2022 05:49:01 GMT
Subject: RFR: 8264999: GeneralPath.lineTo() to itself produces jagged lines
 [v4]
In-Reply-To: <zDQ9DQXj6qgiY0yWof30AAchwCBfEmYlyozs0Dzvv8c=.6b4629e7-7fc0-487e-9c34-32216bcfb8c6@github.com>
References: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
 <zDQ9DQXj6qgiY0yWof30AAchwCBfEmYlyozs0Dzvv8c=.6b4629e7-7fc0-487e-9c34-32216bcfb8c6@github.com>
Message-ID: <XJtHGyiSKBngOgLxefaixZVKdMR4RTpY_ofKzzy6j6w=.1eb2e3f6-3404-4071-8315-1bf93a7b56d2@github.com>

On Fri, 10 Jun 2022 01:24:48 GMT, Jeremy <duke at openjdk.java.net> wrote:

>> Previously when you drew a line that moved exactly (+0, +0) with a miter stroke the Stroker class acted like a horizontal miter was appropriate. Now we abort instead, so no miter is applied.
>> 
>> The new unit test tests the original steps plus several variations.
>> 
>> I'm a little nervous about this change because it looks like someone previously considered this exact condition and implemented a different behavior. I don't think I understand the original rationale.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8264999: GeneralPath.lineTo() to itself produces jagged lines
>   
>   Revising failing (commented out) scenarios.

Concerning the test cases where the expected output is unknown, we could test java2d pipeline without antialiasing (not marlin renderer) or compare with other svg renderers like browsers or image magick (linux). 
Reference images could be generated by other tools and loaded as png images ?

Finally it is possible to compare with former Ductus AA renderer if tests are run on oracle jdk8.

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

PR: https://git.openjdk.org/jdk/pull/8943


From serb at openjdk.java.net  Fri Jun 10 05:49:08 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 10 Jun 2022 05:49:08 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v6]
In-Reply-To: <Ynva90EcdSNf7EyAxZorJNsbqjqpYZjyggv2MOPlK10=.4478324f-75ac-4b52-9d6a-695dbae8f311@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <Ynva90EcdSNf7EyAxZorJNsbqjqpYZjyggv2MOPlK10=.4478324f-75ac-4b52-9d6a-695dbae8f311@github.com>
Message-ID: <7u-yUIx7WRWwfbART_dVbKunF3D9hQlfcxfpLcnZXDM=.f0d4713d-6e8e-4a67-bacd-87e6789544ea@github.com>

On Mon, 6 Jun 2022 23:47:15 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Detect the situation where we do need to perform interpolation during ImageIcon
>> painting and set a hint to the rendering to perform bicubic approximation so
>> image details are preserved during transition.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the line ends

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1441:

> 1439:             }
> 1440:             if (retVal.getWidth(null) != w) {
> 1441:                 BufferedImage newVariant = new BufferedImage(w, w, BufferedImage.TYPE_INT_ARGB);

This version look good, just one more thought. Can we extend this approach and do not request all sizes if the user wanted only one image? So if the user will request all images we request that list from the OS, otherwise only one image will be requested and cached, what do you think?

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

PR: https://git.openjdk.org/jdk/pull/7805


From honkar at openjdk.java.net  Fri Jun 10 06:05:45 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Fri, 10 Jun 2022 06:05:45 GMT
Subject: RFR: 8265586: [windows] last button is not shown in AWT Frame with
 BorderLayout and MenuBar set.
Message-ID: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>

Due to incorrect AWT Frame inset values being returned from native code, few of the components in the frame were not being shown completely on Windows. With the proposed fix, correct insets are obtained which in turn sizes and displays the frame correctly.

The default insets obtained from the Win system was adding only `::GetSystemMetrics(SM_CXSIZEFRAME)` for **WS_THICKFRAME** and the insets were off by 6px from the expected value. `::GetSystemMetrics(SM_CXPADDEDBORDER)` is additionally added to top, bottom, left and right insets to account for the 6px. [GetSystemMetric() Document](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics)

A test case is added which checks if the actual frame size is equal to the expected frame size (frame.getSize() == frame.getPreferredSize()), thus checking if frame.pack() works as expected.

Following are before and after screenshots - 
![image](https://user-images.githubusercontent.com/95945681/172999272-981a0b07-2bd1-425c-b73d-f21f68922262.png)

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

Commit messages:
 - removed extra newline
 - AWT frame.pack fix

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

PR: https://git.openjdk.org/jdk/pull/9118


From honkar at openjdk.java.net  Fri Jun 10 06:05:46 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Fri, 10 Jun 2022 06:05:46 GMT
Subject: RFR: 8265586: [windows] last button is not shown in AWT Frame with
 BorderLayout and MenuBar set.
In-Reply-To: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
References: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
Message-ID: <D82_x0RRX-yScAZViPoxbdyBAyoaIflzwbro_3U5gWU=.3952aa60-9f69-418e-89a4-8425ee055b22@github.com>

On Fri, 10 Jun 2022 05:55:35 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Due to incorrect AWT Frame inset values being returned from native code, few of the components in the frame were not being shown completely on Windows. With the proposed fix, correct insets are obtained which in turn sizes and displays the frame correctly.
> 
> The default insets obtained from the Win system was adding only `::GetSystemMetrics(SM_CXSIZEFRAME)` for **WS_THICKFRAME** and the insets were off by 6px from the expected value. `::GetSystemMetrics(SM_CXPADDEDBORDER)` is additionally added to top, bottom, left and right insets to account for the 6px. [GetSystemMetric() Document](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics)
> 
> A test case is added which checks if the actual frame size is equal to the expected frame size (frame.getSize() == frame.getPreferredSize()), thus checking if frame.pack() works as expected.
> 
> Following are before and after screenshots - 
> ![image](https://user-images.githubusercontent.com/95945681/172999272-981a0b07-2bd1-425c-b73d-f21f68922262.png)

src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1407:

> 1405:     int extraPaddedBorderInsets = info.dwMajorVersion >= 6 ?
> 1406:      ::GetSystemMetrics(SM_CXPADDEDBORDER) : 0;
> 1407: 

The OS version check is added since **SM_CXPADDEDBORDER** metric is not supported on Win XP & 2000. If the current JDK Window target OS version is set to Windows Vista, probably this check is not required or redundant. Suggestions would be helpful as to whether to retain this check or not

![image](https://user-images.githubusercontent.com/95945681/173000377-4109fd09-f8e3-43a3-aa62-3d0c67d2ff56.png)
 
Screenshot source: [GetSystemMetrics Doc](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics)

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

PR: https://git.openjdk.org/jdk/pull/9118


From psadhukhan at openjdk.java.net  Fri Jun 10 07:15:02 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 10 Jun 2022 07:15:02 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed [v2]
In-Reply-To: <tlXy1lpQkB_Hqie3Zo7U9G4_WDA1t6AAIZduGPoBgvg=.3aa8332f-bc2a-40e4-9a45-853fa148ed7f@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
 <tA6NanagDur6PgX8_CfFc2x-YgjknkKPCHJcvEmqGF0=.df8f5ac3-bdc1-488d-a79a-11dcde368be9@github.com>
 <DiaaEHludW7a2Aa3NSLZIHACxUC0hGTWWCdcRimD3VQ=.42cb8dc5-c2a9-43c9-922d-c5cc1b3b29ce@github.com>
 <ktVuNTIc6nLToUQ_l5AzNF99gWK--71qUQDK3OVwHlo=.2e927921-6504-4f86-86b3-92fba42e7bc5@github.com>
 <5a03vAMfkMnFN7maIyKNjzsv4vhED-ssWpE8jE9zacM=.cb079e84-0091-467e-a9f4-1fbaf9c1f0cb@github.com>
 <tlXy1lpQkB_Hqie3Zo7U9G4_WDA1t6AAIZduGPoBgvg=.3aa8332f-bc2a-40e4-9a45-853fa148ed7f@github.com>
Message-ID: <ao-6NWtzk_t1ENzyEhJWkbEum-BgqncTGUPnYThyp5o=.94df6d70-15b4-4fb4-af70-13f47a355e61@github.com>

On Fri, 10 Jun 2022 05:42:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> If I remember correctly, MRI will contain only one image captured by Robot, so it would return the only image it stores, which would not be scaled down if High DPI is in effect.
>> 
>> However, the test is supposed to run with `UIScale=1`, so this should make any difference.
>
> On the HiDPI screen that MRI will have two images, and my expectation is that the image requested by the updated test and the image used before the fix should be the same.

How to find those 2 bufferedimages returned by `createMultiResolutionScreenCapture `and `createScreenCapture `are same or not apart from pixel check (which shows obviously they are not same and color differ by 1)?

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

PR: https://git.openjdk.org/jdk/pull/9011


From psadhukhan at openjdk.java.net  Fri Jun 10 07:20:13 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 10 Jun 2022 07:20:13 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed [v2]
In-Reply-To: <ao-6NWtzk_t1ENzyEhJWkbEum-BgqncTGUPnYThyp5o=.94df6d70-15b4-4fb4-af70-13f47a355e61@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
 <tA6NanagDur6PgX8_CfFc2x-YgjknkKPCHJcvEmqGF0=.df8f5ac3-bdc1-488d-a79a-11dcde368be9@github.com>
 <DiaaEHludW7a2Aa3NSLZIHACxUC0hGTWWCdcRimD3VQ=.42cb8dc5-c2a9-43c9-922d-c5cc1b3b29ce@github.com>
 <ktVuNTIc6nLToUQ_l5AzNF99gWK--71qUQDK3OVwHlo=.2e927921-6504-4f86-86b3-92fba42e7bc5@github.com>
 <5a03vAMfkMnFN7maIyKNjzsv4vhED-ssWpE8jE9zacM=.cb079e84-0091-467e-a9f4-1fbaf9c1f0cb@github.com>
 <tlXy1lpQkB_Hqie3Zo7U9G4_WDA1t6AAIZduGPoBgvg=.3aa8332f-bc2a-40e4-9a45-853fa148ed7f@github.com>
 <ao-6NWtzk_t1ENzyEhJWkbEum-BgqncTGUPnYThyp5o=.94df6d70-15b4-4fb4-af70-13f47a355e61@github.com>
Message-ID: <QT5-i3Y_xpwQfc7wiLVwoY1Nz4G6u7x62YvkrwVgQPo=.a6e825a9-b114-48d3-a0c5-62e42c93ddbe@github.com>

On Fri, 10 Jun 2022 07:11:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> On the HiDPI screen that MRI will have two images, and my expectation is that the image requested by the updated test and the image used before the fix should be the same.
>
> How to find those 2 bufferedimages returned by `createMultiResolutionScreenCapture `and `createScreenCapture `are same or not apart from pixel check (which shows obviously they are not same and color differ by 1)?

Probably we can apply the defensive fix of color tolerance as per 1st iteration ?

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

PR: https://git.openjdk.org/jdk/pull/9011


From psadhukhan at openjdk.java.net  Fri Jun 10 07:53:54 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 10 Jun 2022 07:53:54 GMT
Subject: RFR: 8284619: javax/swing/JTable/8236907/LastVisibleRow.java
 failed with "Test Case Failed!!, Last Row not Visible!!!"
In-Reply-To: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
References: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
Message-ID: <v8FKIZXBkWq4uL3lmAv9fE36PwcjS667xXIqBugTbCM=.366f5213-ffd9-4e88-a235-5d7c90fc2b65@github.com>

On Fri, 10 Jun 2022 05:35:22 GMT, Tejesh R <tr at openjdk.org> wrote:

> Fix history - #7422.
> The test is automatic and check if the last row is painted (Which was not happening before the fix, the last row appeared only after MouseClick operation) by capturing the last row before and after MouseClick Operation.If the both the captured images are same, then the test passes else it fails.
> This Fix includes for ubuntu and macos failure, in which only the test case failed due to following reasons.
> 
> In ubuntu, the test fails due to unexpected dark line appearing on right side of last row before MouseClick operation.
> In macos, the test fails since after MouseClick operation of last row, clearSelection didn't show any effect on the selected row.
> The issue is intermittent and not able to reproduce it frequently. As a defensive fix, the rectangular area which is being captured is reduce for ubuntu failure and Delay is added between ClearSelection of focus and Image Capture for macos failure

Was there any reason of calling table.setFocusable(false) in clearSelect()? We have some focus related mach5 issues in macos that crops out intermittently so maybe we should get rid of that if it's not needed.
I think just calling clearSelection() would have been enough. Can you please check?

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

PR: https://git.openjdk.org/jdk/pull/9117


From tr at openjdk.java.net  Fri Jun 10 08:50:00 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Fri, 10 Jun 2022 08:50:00 GMT
Subject: RFR: 8284619: javax/swing/JTable/8236907/LastVisibleRow.java
 failed with "Test Case Failed!!, Last Row not Visible!!!"
In-Reply-To: <v8FKIZXBkWq4uL3lmAv9fE36PwcjS667xXIqBugTbCM=.366f5213-ffd9-4e88-a235-5d7c90fc2b65@github.com>
References: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
 <v8FKIZXBkWq4uL3lmAv9fE36PwcjS667xXIqBugTbCM=.366f5213-ffd9-4e88-a235-5d7c90fc2b65@github.com>
Message-ID: <t_TVUoHbyIOyzmrywgZTp_CKPNWSnwjx6IeRAMVaBq0=.4f68c61f-05e0-4874-b436-4dc6ee7dc5d6@github.com>

On Fri, 10 Jun 2022 07:50:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Was there any reason of calling table.setFocusable(false) in clearSelect()? We have some focus related mach5 issues in macos that crops out intermittently so maybe we should get rid of that if it's not needed. I think just calling clearSelection() would have been enough. Can you please check?

Yeah, table.setFocusable(false) is added intentionally, it is added to disable the cell focus. After selection the focus remains in cell, so in order to release the focus I used it. Any alternative to this is available?

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

PR: https://git.openjdk.org/jdk/pull/9117


From psadhukhan at openjdk.java.net  Fri Jun 10 09:19:09 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 10 Jun 2022 09:19:09 GMT
Subject: RFR: 8284619: javax/swing/JTable/8236907/LastVisibleRow.java
 failed with "Test Case Failed!!, Last Row not Visible!!!"
In-Reply-To: <t_TVUoHbyIOyzmrywgZTp_CKPNWSnwjx6IeRAMVaBq0=.4f68c61f-05e0-4874-b436-4dc6ee7dc5d6@github.com>
References: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
 <v8FKIZXBkWq4uL3lmAv9fE36PwcjS667xXIqBugTbCM=.366f5213-ffd9-4e88-a235-5d7c90fc2b65@github.com>
 <t_TVUoHbyIOyzmrywgZTp_CKPNWSnwjx6IeRAMVaBq0=.4f68c61f-05e0-4874-b436-4dc6ee7dc5d6@github.com>
Message-ID: <bSkqxi6Da6_8qB6ROxfXAxx8ll4TqwteMsljk7nd-wY=.2347d1a5-804b-42df-981a-a6e674a1ec17@github.com>

On Fri, 10 Jun 2022 08:46:06 GMT, Tejesh R <tr at openjdk.org> wrote:

> > Was there any reason of calling table.setFocusable(false) in clearSelect()? We have some focus related mach5 issues in macos that crops out intermittently so maybe we should get rid of that if it's not needed. I think just calling clearSelection() would have been enough. Can you please check?
> 
> Yeah, table.setFocusable(false) is added intentionally, it is added to disable the cell focus. After selection the focus remains in cell, so in order to release the focus I used it. Any alternative to this is available?

Even if the focus remains in the cell, what was the problem? I guess the problem was the contents was not drawn initially and only was getting drawn if rowcell is clicked. So, before and after mouseclick, the bufferedimage contents should be same, I guess focus is irrelevant here.

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

PR: https://git.openjdk.org/jdk/pull/9117


From psadhukhan at openjdk.java.net  Fri Jun 10 09:29:01 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 10 Jun 2022 09:29:01 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed [v3]
In-Reply-To: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
Message-ID: <a9QjX_WeAlUcTnZy8M7rRA42JnWMJ4t0nASwoIwwVGE=.1015f5c7-0ab4-4180-a6d5-9b8c2d535d5f@github.com>

> Test is failing in iMac CI systems owing to color difference of 1
> 
> `x 0 y 0 rgb1: fff0f0f0 rgb2: fff0eff0`
> 
> Added minor color tolerance check. CI testing is green

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Add color tolerance fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9011/files
  - new: https://git.openjdk.org/jdk/pull/9011/files/dcc0858f..afd6fb93

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

  Stats: 40 lines in 1 file changed: 36 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9011.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9011/head:pull/9011

PR: https://git.openjdk.org/jdk/pull/9011


From psadhukhan at openjdk.java.net  Fri Jun 10 09:29:03 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 10 Jun 2022 09:29:03 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed [v2]
In-Reply-To: <QT5-i3Y_xpwQfc7wiLVwoY1Nz4G6u7x62YvkrwVgQPo=.a6e825a9-b114-48d3-a0c5-62e42c93ddbe@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
 <tA6NanagDur6PgX8_CfFc2x-YgjknkKPCHJcvEmqGF0=.df8f5ac3-bdc1-488d-a79a-11dcde368be9@github.com>
 <DiaaEHludW7a2Aa3NSLZIHACxUC0hGTWWCdcRimD3VQ=.42cb8dc5-c2a9-43c9-922d-c5cc1b3b29ce@github.com>
 <ktVuNTIc6nLToUQ_l5AzNF99gWK--71qUQDK3OVwHlo=.2e927921-6504-4f86-86b3-92fba42e7bc5@github.com>
 <5a03vAMfkMnFN7maIyKNjzsv4vhED-ssWpE8jE9zacM=.cb079e84-0091-467e-a9f4-1fbaf9c1f0cb@github.com>
 <tlXy1lpQkB_Hqie3Zo7U9G4_WDA1t6AAIZduGPoBgvg=.3aa8332f-bc2a-40e4-9a45-853fa148ed7f@github.com>
 <ao-6NWtzk_t1ENzyEhJWkbEum-BgqncTGUPnYThyp5o=.94df6d70-15b4-4fb4-af70-13f47a355e61@github.com>
 <QT5-i3Y_xpwQfc7wiLVwoY1Nz4G6u7x62YvkrwVgQPo=.a6e825a9-b114-48d3-a0c5-62e42c93ddbe@github.com>
Message-ID: <QbLmexy7rrNGlj2YDMpJ_-Hyc7-inp8NN1j9G3LWYIk=.8d08b952-ae4e-4042-8273-29ddd3894f8d@github.com>

On Fri, 10 Jun 2022 07:16:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> How to find those 2 bufferedimages returned by `createMultiResolutionScreenCapture `and `createScreenCapture `are same or not apart from pixel check (which shows obviously they are not same and color differ by 1)?
>
> Probably we can apply the defensive fix of color tolerance as per 1st iteration ?

It still fails once or twice with createMultiResolutionScreenCapture if the test iteration is increased, so I think color tolerance, even if defensive, is the one to go for.

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

PR: https://git.openjdk.org/jdk/pull/9011


From asemenov at openjdk.java.net  Fri Jun 10 09:33:07 2022
From: asemenov at openjdk.java.net (Artem Semenov)
Date: Fri, 10 Jun 2022 09:33:07 GMT
Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v2]
In-Reply-To: <UfBh-sr7FlTUWKOsVoL1_t28GUxWp3WRrVgxJ9gYSfw=.44b84613-dc9c-49db-add7-8c96047ef9ee@github.com>
References: <iogsScwXVmrG-QaPPqnBIyBbyc30OmKOUPLjiSKpEEs=.c76d3e64-ea3e-4560-a88a-821f25f9680b@github.com>
 <UfBh-sr7FlTUWKOsVoL1_t28GUxWp3WRrVgxJ9gYSfw=.44b84613-dc9c-49db-add7-8c96047ef9ee@github.com>
Message-ID: <qr0Io-iFodAQiXxqWFOXoyvAvPxiOJnavr3z8U_MUEk=.8d7732e6-08be-4564-890b-34abe8720b68@github.com>

On Wed, 11 May 2022 12:49:34 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> A11Y implementation on macOS has to directly call the 'JList.setSelectedIndex' method in order to request selection on an item (see 'CAccessibility.requestSelection'). The reason is that a11y API lacks appropriate method.There's only 'javax.accessibility.AccessibleSelection#addAccessibleSelection' which is mapped to 'javax.swing.JList#addSelectionInterval', it can not be used to set selected index.
>> 
>> @forantar @azuev-java @mrserb please review.
>> 
>> Please note that the new API allows you to implement a multiple selection in lists from the Java side, but I did not succeed in implementing it, because I could not determine the inclusion of the so-called "VoiceOver multiple selection mode".
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   We don't do @author tags in openjdk
>   Not 2022 ?

Just some comment so that the pull request doesn't close.

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

PR: https://git.openjdk.org/jdk/pull/8578


From tr at openjdk.java.net  Fri Jun 10 10:34:03 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Fri, 10 Jun 2022 10:34:03 GMT
Subject: RFR: 8284619: javax/swing/JTable/8236907/LastVisibleRow.java
 failed with "Test Case Failed!!, Last Row not Visible!!!"
In-Reply-To: <bSkqxi6Da6_8qB6ROxfXAxx8ll4TqwteMsljk7nd-wY=.2347d1a5-804b-42df-981a-a6e674a1ec17@github.com>
References: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
 <v8FKIZXBkWq4uL3lmAv9fE36PwcjS667xXIqBugTbCM=.366f5213-ffd9-4e88-a235-5d7c90fc2b65@github.com>
 <t_TVUoHbyIOyzmrywgZTp_CKPNWSnwjx6IeRAMVaBq0=.4f68c61f-05e0-4874-b436-4dc6ee7dc5d6@github.com>
 <bSkqxi6Da6_8qB6ROxfXAxx8ll4TqwteMsljk7nd-wY=.2347d1a5-804b-42df-981a-a6e674a1ec17@github.com>
Message-ID: <4oe9HdZrBaH58JOP1GHt9aHNWf41AiMxWYBApyfq0sQ=.083b5ccb-cee4-4978-b934-61291cf0a1d1@github.com>

On Fri, 10 Jun 2022 09:15:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > > Was there any reason of calling table.setFocusable(false) in clearSelect()? We have some focus related mach5 issues in macos that crops out intermittently so maybe we should get rid of that if it's not needed. I think just calling clearSelection() would have been enough. Can you please check?
> > 
> > 
> > Yeah, table.setFocusable(false) is added intentionally, it is added to disable the cell focus. After selection the focus remains in cell, so in order to release the focus I used it. Any alternative to this is available?
> 
> Even if the focus remains in the cell, what was the problem? I guess the problem was the contents was not drawn initially and only was getting drawn if rowcell is clicked. So, before and after mouseclick, the bufferedimage contents should be same, I guess focus is irrelevant here.

No issue with the contents drawn. Before mouseclick there wouldn't be any focus on any cell, but after mouseclick the focus will be seen on the clicked cell. In order to remove that set focus, setFocusable(false) is required. Otherwise the matching fails due to cell focus draw as rectangular border around the cell.

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

PR: https://git.openjdk.org/jdk/pull/9117


From mdoerr at openjdk.java.net  Fri Jun 10 10:53:14 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 10 Jun 2022 10:53:14 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <hhcl2DS9otR1Jql7mhvTBsiP96NUBscYl-i5zXiVIzc=.e1dee9ab-6eff-45b6-b769-8d05bc10871a@github.com>

On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

LGTM and sounds feasible.

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

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9105


From psadhukhan at openjdk.java.net  Fri Jun 10 11:26:06 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 10 Jun 2022 11:26:06 GMT
Subject: RFR: 8284619: javax/swing/JTable/8236907/LastVisibleRow.java
 failed with "Test Case Failed!!, Last Row not Visible!!!"
In-Reply-To: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
References: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
Message-ID: <EUn19zisQuwUGP11mPLF8LAuMy-vXXMVoFp5k4apD-c=.bda6b082-e4da-445e-97f2-c5ce358bd588@github.com>

On Fri, 10 Jun 2022 05:35:22 GMT, Tejesh R <tr at openjdk.org> wrote:

> Fix history - #7422.
> The test is automatic and check if the last row is painted (Which was not happening before the fix, the last row appeared only after MouseClick operation) by capturing the last row before and after MouseClick Operation.If the both the captured images are same, then the test passes else it fails.
> This Fix includes for ubuntu and macos failure, in which only the test case failed due to following reasons.
> 
> In ubuntu, the test fails due to unexpected dark line appearing on right side of last row before MouseClick operation.
> In macos, the test fails since after MouseClick operation of last row, clearSelection didn't show any effect on the selected row.
> The issue is intermittent and not able to reproduce it frequently. As a defensive fix, the rectangular area which is being captured is reduce for ubuntu failure and Delay is added between ClearSelection of focus and Image Capture for macos failure

Marked as reviewed by psadhukhan (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9117


From psadhukhan at openjdk.java.net  Fri Jun 10 11:26:08 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 10 Jun 2022 11:26:08 GMT
Subject: RFR: 8284619: javax/swing/JTable/8236907/LastVisibleRow.java
 failed with "Test Case Failed!!, Last Row not Visible!!!"
In-Reply-To: <4oe9HdZrBaH58JOP1GHt9aHNWf41AiMxWYBApyfq0sQ=.083b5ccb-cee4-4978-b934-61291cf0a1d1@github.com>
References: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
 <v8FKIZXBkWq4uL3lmAv9fE36PwcjS667xXIqBugTbCM=.366f5213-ffd9-4e88-a235-5d7c90fc2b65@github.com>
 <t_TVUoHbyIOyzmrywgZTp_CKPNWSnwjx6IeRAMVaBq0=.4f68c61f-05e0-4874-b436-4dc6ee7dc5d6@github.com>
 <bSkqxi6Da6_8qB6ROxfXAxx8ll4TqwteMsljk7nd-wY=.2347d1a5-804b-42df-981a-a6e674a1ec17@github.com>
 <4oe9HdZrBaH58JOP1GHt9aHNWf41AiMxWYBApyfq0sQ=.083b5ccb-cee4-4978-b934-61291cf0a1d1@github.com>
Message-ID: <KQxhvme7JFREYQC7T23Lxti1ry3siZmvENxJwz3Z9Jc=.bc42c4b9-c770-4eae-a4d1-599d8143a06b@github.com>

On Fri, 10 Jun 2022 10:30:54 GMT, Tejesh R <tr at openjdk.org> wrote:

> > > > Was there any reason of calling table.setFocusable(false) in clearSelect()? We have some focus related mach5 issues in macos that crops out intermittently so maybe we should get rid of that if it's not needed. I think just calling clearSelection() would have been enough. Can you please check?
> > > 
> > > 
> > > Yeah, table.setFocusable(false) is added intentionally, it is added to disable the cell focus. After selection the focus remains in cell, so in order to release the focus I used it. Any alternative to this is available?
> > 
> > 
> > Even if the focus remains in the cell, what was the problem? I guess the problem was the contents was not drawn initially and only was getting drawn if rowcell is clicked. So, before and after mouseclick, the bufferedimage contents should be same, I guess focus is irrelevant here.
> 
> No issue with the contents drawn. Before mouseclick there wouldn't be any focus on any cell, but after mouseclick the focus will be seen on the clicked cell. In order to remove that set focus, setFocusable(false) is required. Otherwise the matching fails due to cell focus draw as rectangular border around the cell.

ok

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

PR: https://git.openjdk.org/jdk/pull/9117


From mbaesken at openjdk.java.net  Fri Jun 10 11:30:06 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 10 Jun 2022 11:30:06 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling
In-Reply-To: <hhcl2DS9otR1Jql7mhvTBsiP96NUBscYl-i5zXiVIzc=.e1dee9ab-6eff-45b6-b769-8d05bc10871a@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <hhcl2DS9otR1Jql7mhvTBsiP96NUBscYl-i5zXiVIzc=.e1dee9ab-6eff-45b6-b769-8d05bc10871a@github.com>
Message-ID: <1ekFL0P-_g0l_A4cqFl61JU66x4SyCp97VFeqtkX0gw=.0b43bf9e-0dc1-41b2-bb1f-89e8dcd7d393@github.com>

On Fri, 10 Jun 2022 10:49:25 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> LGTM and sounds feasible.

Hi Martin, thanks for the review.

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

PR: https://git.openjdk.org/jdk/pull/9105


From aivanov at openjdk.java.net  Fri Jun 10 12:16:15 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 10 Jun 2022 12:16:15 GMT
Subject: RFR: 8265586: [windows] last button is not shown in AWT Frame with
 BorderLayout and MenuBar set.
In-Reply-To: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
References: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
Message-ID: <-6qqIIcOwHkFFet5HtU3TQPa9M7VmySbMXYIxc-CpC8=.727b7269-4840-4e01-9c99-2548ddec6841@github.com>

On Fri, 10 Jun 2022 05:55:35 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Due to incorrect AWT Frame inset values being returned from native code, few of the components in the frame were not being shown completely on Windows. With the proposed fix, correct insets are obtained which in turn sizes and displays the frame correctly.
> 
> The default insets obtained from the Win system was adding only `::GetSystemMetrics(SM_CXSIZEFRAME)` for **WS_THICKFRAME** and the insets were off by 6px from the expected value. `::GetSystemMetrics(SM_CXPADDEDBORDER)` is additionally added to top, bottom, left and right insets to account for the 6px. [GetSystemMetric() Document](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics)
> 
> A test case is added which checks if the actual frame size is equal to the expected frame size (frame.getSize() == frame.getPreferredSize()), thus checking if frame.pack() works as expected.
> 
> Following are before and after screenshots - 
> ![image](https://user-images.githubusercontent.com/95945681/172999272-981a0b07-2bd1-425c-b73d-f21f68922262.png)

Changes requested by aivanov (Reviewer).

src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1402:

> 1400:     ZeroMemory(&info, sizeof(OSVERSIONINFOEX));
> 1401:     info.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);
> 1402:     GetVersionEx((LPOSVERSIONINFO) &info);

You don't need to check Windows version. Windows XP and 2000 are unsupported, java.exe doesn't even start there because its exe file header requires version 6.0 (Vista).

The lowest version supported by Microsoft is Windows 10, Windows 8.1 will reach its end of extended support in January 2023.

Thus, it's safe to call `::GetSystemMetrics(SM_CXPADDEDBORDER)`.

This issue came up after Windows SDK had been upgraded, which led to [/subsystem](https://docs.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=msvc-140) version being set to 6.0. When targeting to previous versions, the `SM_CXPADDEDBORDER` is excluded from the non-client area of a window.

src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1440:

> 1438:                     ::GetSystemMetrics(SM_CXDLGFRAME);
> 1439:                 m_insets.top = m_insets.bottom =
> 1440:                     ::GetSystemMetrics(SM_CYDLGFRAME);

It's likely needed here as well.

Make the frame non-resizeable to get into this block.

test/jdk/java/awt/Frame/AwtFramePackTest.java line 28:

> 26:  * @bug 8265586
> 27:  * @key headful
> 28:  * @summary Tests the functionality of AWT frame.pack() on Windows.

Could you be more specific? It tests *the insets* of a frame are calculated correctly on Windows.

test/jdk/java/awt/Frame/AwtFramePackTest.java line 30:

> 28:  * @summary Tests the functionality of AWT frame.pack() on Windows.
> 29:  * @run main AwtFramePackTest
> 30:  * @requires (os.family == "windows")

Usually, `@run` is the latest tag in a test description; `@requires` usually goes before `@summary`.

test/jdk/java/awt/Frame/AwtFramePackTest.java line 31:

> 29:  * @run main AwtFramePackTest
> 30:  * @requires (os.family == "windows")
> 31:  */

I am for placing the test tags before the class declaration, after imports. They're easier to see when you open the file in the IDE because they aren't collapsed.

test/jdk/java/awt/Frame/AwtFramePackTest.java line 73:

> 71: 
> 72:             frame.pack();
> 73:             frame.setVisible(true);

You should call `Robot.waitForIdle()` after making the frame visible. Calling it before you created the frame has no effect.

test/jdk/java/awt/Frame/AwtFramePackTest.java line 84:

> 82:                 throw new RuntimeException("Expected and Actual frame size" +
> 83:                         " are different. frame.pack() does not work!!");
> 84:            }

One space of indent is missing before the closing brace.

test/jdk/java/awt/Frame/AwtFramePackTest.java line 93:

> 91:     private static void saveScreenCapture() {
> 92:         robot.delay(500);
> 93:         robot.waitForIdle();

I don't think another `delay` and `waitForIdle` are required here.

The frame should be properly displayed before `frame.getSize()` is called.

test/jdk/java/awt/Frame/AwtFramePackTest.java line 95:

> 93:         robot.waitForIdle();
> 94:         BufferedImage image = robot.createScreenCapture(
> 95:                 new Rectangle(0, 0, 500, 500));

You probably want to capture `frame.getBounds()`.

test/jdk/java/awt/Frame/AwtFramePackTest.java line 97:

> 95:                 new Rectangle(0, 0, 500, 500));
> 96:         try {
> 97:             ImageIO.write(image, "png", new File("Frame"));

Suggestion:

            ImageIO.write(image, "png", new File("Frame.png"));

Add extension to the image file.

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

PR: https://git.openjdk.org/jdk/pull/9118


From aivanov at openjdk.java.net  Fri Jun 10 12:26:05 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 10 Jun 2022 12:26:05 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v6]
In-Reply-To: <7u-yUIx7WRWwfbART_dVbKunF3D9hQlfcxfpLcnZXDM=.f0d4713d-6e8e-4a67-bacd-87e6789544ea@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <Ynva90EcdSNf7EyAxZorJNsbqjqpYZjyggv2MOPlK10=.4478324f-75ac-4b52-9d6a-695dbae8f311@github.com>
 <7u-yUIx7WRWwfbART_dVbKunF3D9hQlfcxfpLcnZXDM=.f0d4713d-6e8e-4a67-bacd-87e6789544ea@github.com>
Message-ID: <sremizdcaZgk3h7eYyJlL0LyspG_Onjs8vKPu9GUrUY=.9d1223a6-276a-4868-a4d7-c2953f95fc45@github.com>

On Fri, 10 Jun 2022 05:45:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This version look good, just one more thought. Can we extend this approach and do not request all sizes if the user wanted only one image? So if the user will request all images we request that list from the OS, otherwise only one image will be requested and cached, what do you think?

How would you implement this?

I mean the user requests the icon in user's space (right?). On a High DPI system which may change in runtime, a larger icon version is required for rendering. To get a larger icon from native, we have to keep the file name or PIDL and call shell interfaces on COM thread to fetch the icon.

Overall, I like the idea? We may have discussed it. Keeping only sizes that are needed will reduce the memory usage. All in all, it's definitely out of scope for this fix.

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

PR: https://git.openjdk.org/jdk/pull/7805


From aivanov at openjdk.java.net  Fri Jun 10 12:30:01 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 10 Jun 2022 12:30:01 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed [v2]
In-Reply-To: <QbLmexy7rrNGlj2YDMpJ_-Hyc7-inp8NN1j9G3LWYIk=.8d08b952-ae4e-4042-8273-29ddd3894f8d@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
 <tA6NanagDur6PgX8_CfFc2x-YgjknkKPCHJcvEmqGF0=.df8f5ac3-bdc1-488d-a79a-11dcde368be9@github.com>
 <DiaaEHludW7a2Aa3NSLZIHACxUC0hGTWWCdcRimD3VQ=.42cb8dc5-c2a9-43c9-922d-c5cc1b3b29ce@github.com>
 <ktVuNTIc6nLToUQ_l5AzNF99gWK--71qUQDK3OVwHlo=.2e927921-6504-4f86-86b3-92fba42e7bc5@github.com>
 <5a03vAMfkMnFN7maIyKNjzsv4vhED-ssWpE8jE9zacM=.cb079e84-0091-467e-a9f4-1fbaf9c1f0cb@github.com>
 <tlXy1lpQkB_Hqie3Zo7U9G4_WDA1t6AAIZduGPoBgvg=.3aa8332f-bc2a-40e4-9a45-853fa148ed7f@github.com>
 <ao-6NWtzk_t1ENzyEhJWkbEum-BgqncTGUPnYThyp5o=.94df6d70-15b4-4fb4-af70-13f47a355e61@github.com>
 <QT5-i3Y_xpwQfc7wiLVwoY1Nz4G6u7x62YvkrwVgQPo=.a6e825a9-b114-48d3-a0c5-62e42c93ddbe@github.com>
 <QbLmexy7rrNGlj2YDMpJ_-Hyc7-inp8NN1j9G3LWYIk=.8d08b952-ae4e-4042-8273-29ddd3894f8d@github.com>
Message-ID: <Z8WYGkTX00FshprjuxYWbEmZmL68sEzOTdQIF82561M=.fada437c-c2c1-4b63-8feb-af3b7d478b82@github.com>

On Fri, 10 Jun 2022 09:25:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Probably we can apply the defensive fix of color tolerance as per 1st iteration ?
>
> It still fails once or twice with createMultiResolutionScreenCapture if the test iteration is increased, so I think color tolerance, even if defensive, is the one to go for.

> On the HiDPI screen that MRI will have two images, and my expectation is that the image requested by the updated test and the image used before the fix should be the same.

In this case, yes, the image will be the same as before: a scaled down bitmap you get with regular `createScreenCapture`.

> How to find those 2 bufferedimages returned by createMultiResolutionScreenCapture and createScreenCapture are same or not apart from pixel check (which shows obviously they are not same and color differ by 1)?

You can get the largest variant, and compare colors there. Yet the size of the two images will be different, most likely.

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

PR: https://git.openjdk.org/jdk/pull/9011


From aivanov at openjdk.java.net  Fri Jun 10 12:37:04 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 10 Jun 2022 12:37:04 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed [v3]
In-Reply-To: <a9QjX_WeAlUcTnZy8M7rRA42JnWMJ4t0nASwoIwwVGE=.1015f5c7-0ab4-4180-a6d5-9b8c2d535d5f@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
 <a9QjX_WeAlUcTnZy8M7rRA42JnWMJ4t0nASwoIwwVGE=.1015f5c7-0ab4-4180-a6d5-9b8c2d535d5f@github.com>
Message-ID: <B9r4qJVG-3UbE7BMiibCDt6eWvsJoc9nyK14xngVPXk=.6978a79e-c13f-4b86-908c-3f4b61002e90@github.com>

On Fri, 10 Jun 2022 09:29:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test is failing in iMac CI systems owing to color difference of 1
>> 
>> `x 0 y 0 rgb1: fff0f0f0 rgb2: fff0eff0`
>> 
>> Added minor color tolerance check. CI testing is green
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add color tolerance fix

Shall the copyright year be updated?

test/jdk/javax/swing/text/CSSBorder/6796710/bug6796710.java line 143:

> 141:         int width = bufferedImage0.getWidth();
> 142:         int height = bufferedImage0.getHeight();
> 143:         int colorTolerance = 5;

A constant in the class?

test/jdk/javax/swing/text/CSSBorder/6796710/bug6796710.java line 167:

> 165:                         System.out.println("x "+ x + " y " + y +
> 166:                             " rgb1: " + Integer.toHexString(bufferedImage0.getRGB(x, y)) +
> 167:                             " rgb2: " + Integer.toHexString(bufferedImage1.getRGB(x, y)));

You can use the stored values in `bufCol0` and `bufCol1`.

test/jdk/javax/swing/text/CSSBorder/6796710/bug6796710.java line 182:

> 180: 
> 181:         return robot.createScreenCapture(rect);
> 182: 

Could be removed?

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

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9011


From psadhukhan at openjdk.java.net  Fri Jun 10 12:49:08 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 10 Jun 2022 12:49:08 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed [v4]
In-Reply-To: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
Message-ID: <x7bVpmxIpassQ28av0yhTyF5Wy8hpwf5oVlAkcTz54U=.2af4d00f-6a6a-460e-ba6b-ab8d13060cc6@github.com>

> Test is failing in iMac CI systems owing to color difference of 1
> 
> `x 0 y 0 rgb1: fff0f0f0 rgb2: fff0eff0`
> 
> Added minor color tolerance check. CI testing is green

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - Fix review comments
 - Fix review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9011/files
  - new: https://git.openjdk.org/jdk/pull/9011/files/afd6fb93..51c37d95

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

  Stats: 10 lines in 1 file changed: 1 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9011.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9011/head:pull/9011

PR: https://git.openjdk.org/jdk/pull/9011


From aivanov at openjdk.java.net  Fri Jun 10 12:58:04 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 10 Jun 2022 12:58:04 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed [v4]
In-Reply-To: <x7bVpmxIpassQ28av0yhTyF5Wy8hpwf5oVlAkcTz54U=.2af4d00f-6a6a-460e-ba6b-ab8d13060cc6@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
 <x7bVpmxIpassQ28av0yhTyF5Wy8hpwf5oVlAkcTz54U=.2af4d00f-6a6a-460e-ba6b-ab8d13060cc6@github.com>
Message-ID: <jayICx8zw9piwtOWb_dem_rwOvr8Y0e_U8DQ-28RIk8=.ad4707b6-8cfa-4859-8ac7-8c00a1c5d52a@github.com>

On Fri, 10 Jun 2022 12:49:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test is failing in iMac CI systems owing to color difference of 1
>> 
>> `x 0 y 0 rgb1: fff0f0f0 rgb2: fff0eff0`
>> 
>> Added minor color tolerance check. CI testing is green
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix review comments
>  - Fix review comments

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/text/CSSBorder/6796710/bug6796710.java line 76:

> 74: 
> 75:     private static JPanel pnBottom;
> 76:     private static final int COLORTOLERANCE = 5;

It's common to separate words in constants by an underscore: `COLOR_TOLERANCE`.

test/jdk/javax/swing/text/CSSBorder/6796710/bug6796710.java line 163:

> 161:                 if ((Math.abs(red1 - red2) > COLORTOLERANCE) ||
> 162:                     (Math.abs(green1 - green2) > COLORTOLERANCE) ||
> 163:                     (Math.abs(blue1 - blue2) > COLORTOLERANCE)) {

Are binary operators usually wrapped to the next line or left on the same line?

Which style is the preferred one?

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

PR: https://git.openjdk.org/jdk/pull/9011


From psadhukhan at openjdk.java.net  Fri Jun 10 13:11:14 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 10 Jun 2022 13:11:14 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed [v5]
In-Reply-To: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
Message-ID: <2hW-XpfbKayZqfVWVG5fFvqo_3xQJhQ9ZrYBt8e0jPA=.5c00a026-a71d-431a-b02b-4528a3191883@github.com>

> Test is failing in iMac CI systems owing to color difference of 1
> 
> `x 0 y 0 rgb1: fff0f0f0 rgb2: fff0eff0`
> 
> Added minor color tolerance check. CI testing is green

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9011/files
  - new: https://git.openjdk.org/jdk/pull/9011/files/51c37d95..c7028928

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

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

PR: https://git.openjdk.org/jdk/pull/9011


From psadhukhan at openjdk.java.net  Fri Jun 10 13:11:16 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 10 Jun 2022 13:11:16 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed [v4]
In-Reply-To: <jayICx8zw9piwtOWb_dem_rwOvr8Y0e_U8DQ-28RIk8=.ad4707b6-8cfa-4859-8ac7-8c00a1c5d52a@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
 <x7bVpmxIpassQ28av0yhTyF5Wy8hpwf5oVlAkcTz54U=.2af4d00f-6a6a-460e-ba6b-ab8d13060cc6@github.com>
 <jayICx8zw9piwtOWb_dem_rwOvr8Y0e_U8DQ-28RIk8=.ad4707b6-8cfa-4859-8ac7-8c00a1c5d52a@github.com>
Message-ID: <hjGmd4kypL9D0gAgllsWPVwJ3j0W2haNES62hCX9rKc=.ee58bc57-7446-4966-8d92-cb5e8b75d737@github.com>

On Fri, 10 Jun 2022 12:54:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix review comments
>>  - Fix review comments
>
> test/jdk/javax/swing/text/CSSBorder/6796710/bug6796710.java line 163:
> 
>> 161:                 if ((Math.abs(red1 - red2) > COLORTOLERANCE) ||
>> 162:                     (Math.abs(green1 - green2) > COLORTOLERANCE) ||
>> 163:                     (Math.abs(blue1 - blue2) > COLORTOLERANCE)) {
> 
> Are binary operators usually wrapped to the next line or left on the same line?
> 
> Which style is the preferred one?

I have seen the present style more common.

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

PR: https://git.openjdk.org/jdk/pull/9011


From aivanov at openjdk.java.net  Fri Jun 10 13:17:01 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 10 Jun 2022 13:17:01 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed [v5]
In-Reply-To: <2hW-XpfbKayZqfVWVG5fFvqo_3xQJhQ9ZrYBt8e0jPA=.5c00a026-a71d-431a-b02b-4528a3191883@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
 <2hW-XpfbKayZqfVWVG5fFvqo_3xQJhQ9ZrYBt8e0jPA=.5c00a026-a71d-431a-b02b-4528a3191883@github.com>
Message-ID: <7wCL5ahp6nntT94ot2r0S7xvUz2Ghbkon_a2Zs2OhMk=.a0ad30a1-17b8-40cd-a73b-ed05a119f688@github.com>

On Fri, 10 Jun 2022 13:11:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test is failing in iMac CI systems owing to color difference of 1
>> 
>> `x 0 y 0 rgb1: fff0f0f0 rgb2: fff0eff0`
>> 
>> Added minor color tolerance check. CI testing is green
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix review comments

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9011


From martin.desruisseaux at geomatys.com  Fri Jun 10 13:38:56 2022
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Fri, 10 Jun 2022 15:38:56 +0200
Subject: AffineTransform.equals(Object) is sometime inconsistent with itself
 and with hashCode()
Message-ID: <76531f4e-9de2-b54a-ec6f-1d71b34d1468@geomatys.com>

Hello

I created a new pull request for two inconsistencies in 
AffineTransform.equals(Object). Current implementation of that method 
breaks two invariant:

  * A.equals(A) returns false if at least one affine transform
    coefficient is NaN (reflexivity broken).
  * A.equals(B) should imply A.hashCode() == B.hashCode(), but it is not
    the case if a coefficient is zero with an opposite sign in A and B.

The proposed patch preserves the current equals(Object) behavior when 
possible for backward compatibility. The merge request is at 
https://github.com/openjdk/jdk/pull/9121 and passes the pre-submit 
tests. If accepted, I presume that we would need someone to create an 
issue on https://bugs.openjdk.org/ ?

 ??? Martin



From psadhukhan at openjdk.java.net  Fri Jun 10 13:41:01 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 10 Jun 2022 13:41:01 GMT
Subject: Integrated: 8287743:
 javax/swing/text/CSSBorder/6796710/bug6796710.java failed
In-Reply-To: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
Message-ID: <6gL2huZZ5KLVK1J7qHphcTuinheMN3d-bxwbusFaGtU=.fb9d1503-383f-436f-bc66-4ecd3cbc7ddc@github.com>

On Fri, 3 Jun 2022 09:46:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test is failing in iMac CI systems owing to color difference of 1
> 
> `x 0 y 0 rgb1: fff0f0f0 rgb2: fff0eff0`
> 
> Added minor color tolerance check. CI testing is green

This pull request has now been integrated.

Changeset: fcb35ed4
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fcb35ed40e46759f52d5c86a09e4a4f973edd58d
Stats:     39 lines in 1 file changed: 37 ins; 0 del; 2 mod

8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java failed

Reviewed-by: aivanov

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

PR: https://git.openjdk.org/jdk/pull/9011


From stefan.reich.maker.of.eye at googlemail.com  Fri Jun 10 14:36:00 2022
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Fri, 10 Jun 2022 16:36:00 +0200
Subject: Mouse cursor flickers when taking screenshots on Windows
Message-ID: <CAC2-jLFyGx3QPqVq9RiioxxQdnJ1Omw1XGKfxM+xb7+U6wVKcg@mail.gmail.com>

Hi,

I am developing an application for screen automation in Java. It
necessarily has to grab screenshots regularly (up to 20 FPS) using
java.awt.Robot. On Windows, this causes the mouse cursor to flicker
constantly
<https://stackoverflow.com/questions/25705814/java-cursor-flickering-when-i-take-many-screenshot>
which is very annoying.

Is there any way around this?

I'd be completely fine with having a screenshot that includes the mouse
cursor. (I assume hiding the mouse cursor in the screenshot is the reason
the flickering occurs.)

Greetings,
Stefan

-- 
== Gaz.AI ==


From honkar at openjdk.java.net  Fri Jun 10 15:53:10 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Fri, 10 Jun 2022 15:53:10 GMT
Subject: RFR: 8265586: [windows] last button is not shown in AWT Frame with
 BorderLayout and MenuBar set.
In-Reply-To: <-6qqIIcOwHkFFet5HtU3TQPa9M7VmySbMXYIxc-CpC8=.727b7269-4840-4e01-9c99-2548ddec6841@github.com>
References: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
 <-6qqIIcOwHkFFet5HtU3TQPa9M7VmySbMXYIxc-CpC8=.727b7269-4840-4e01-9c99-2548ddec6841@github.com>
Message-ID: <ZzEEEgj4QR-S1lQOpQjOkwHV4st_bvyjm9kuOL8bLe8=.39de3486-7585-4dc1-9255-0bbe3cccff65@github.com>

On Fri, 10 Jun 2022 12:12:31 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Due to incorrect AWT Frame inset values being returned from native code, few of the components in the frame were not being shown completely on Windows. With the proposed fix, correct insets are obtained which in turn sizes and displays the frame correctly.
>> 
>> The default insets obtained from the Win system was adding only `::GetSystemMetrics(SM_CXSIZEFRAME)` for **WS_THICKFRAME** and the insets were off by 6px from the expected value. `::GetSystemMetrics(SM_CXPADDEDBORDER)` is additionally added to top, bottom, left and right insets to account for the 6px. [GetSystemMetric() Document](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics)
>> 
>> A test case is added which checks if the actual frame size is equal to the expected frame size (frame.getSize() == frame.getPreferredSize()), thus checking if frame.pack() works as expected.
>> 
>> Following are before and after screenshots - 
>> ![image](https://user-images.githubusercontent.com/95945681/172999272-981a0b07-2bd1-425c-b73d-f21f68922262.png)
>
> Changes requested by aivanov (Reviewer).

@aivanov-jdk Thank you for reviewing. I'll have the suggested changes fixed in the next commit.

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

PR: https://git.openjdk.org/jdk/pull/9118


From achung at openjdk.java.net  Fri Jun 10 19:11:19 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Fri, 10 Jun 2022 19:11:19 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v25]
In-Reply-To: <yRnCrnUxByPUfcZLJUdOcy4F-KEnkzgrkE85lDtqrDI=.b3323f8c-c9a9-4a97-831b-b36de4317ad1@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <5OeF1xoZhJSeVPXfYvAaLVXD4z3SJI7sUj8Mp19dQ9w=.ecb50ef6-2c7b-42cb-a6dc-95268662f56d@github.com>
 <4p0Hu6kjL0vKi2-tDQY41slAKGYm2rPmQs9VgTWSXNc=.1e48064b-687f-46a5-a6f0-c6e9a4490468@github.com>
 <yRnCrnUxByPUfcZLJUdOcy4F-KEnkzgrkE85lDtqrDI=.b3323f8c-c9a9-4a97-831b-b36de4317ad1@github.com>
Message-ID: <ZkombtdFuFDKDR-sm3b2nc8bfhW7gKNrD9dyufTqgxA=.ae4a1e89-8686-4a18-bdae-ba43ffa42fc2@github.com>

On Thu, 9 Jun 2022 18:45:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 158:
>> 
>>> 156:         AffineTransform at = new AffineTransform();
>>> 157:         Stroke oldStk = new BasicStroke();
>>> 158:         int stkWidth = 1;
>> 
>> Now the usage of these variables is restricted to the case where `resetTransform` is set to `true`. Therefore, they can be left uninitialised here; a value is assigned before it's used in all the code paths as far as I can see.
>> 
>> It's just a small (premature) optimisation, it avoids creating two objects. I don't insist though.
>
> I'd be inclined to remove the initialisation.

I'm running into an error that at and oldStk may not have been initialized if I try to remove the initializations

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

PR: https://git.openjdk.org/jdk/pull/7449


From aivanov at openjdk.java.net  Fri Jun 10 19:40:11 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 10 Jun 2022 19:40:11 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v25]
In-Reply-To: <yRnCrnUxByPUfcZLJUdOcy4F-KEnkzgrkE85lDtqrDI=.b3323f8c-c9a9-4a97-831b-b36de4317ad1@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <5OeF1xoZhJSeVPXfYvAaLVXD4z3SJI7sUj8Mp19dQ9w=.ecb50ef6-2c7b-42cb-a6dc-95268662f56d@github.com>
 <4p0Hu6kjL0vKi2-tDQY41slAKGYm2rPmQs9VgTWSXNc=.1e48064b-687f-46a5-a6f0-c6e9a4490468@github.com>
 <yRnCrnUxByPUfcZLJUdOcy4F-KEnkzgrkE85lDtqrDI=.b3323f8c-c9a9-4a97-831b-b36de4317ad1@github.com>
Message-ID: <RScIQwbXWRrdG9fPH4_dlkGJLzGumJPdjgxw2F1VMV0=.38089d0d-090e-4d5b-a716-57228889ffb9@github.com>

On Thu, 9 Jun 2022 18:45:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 158:
>> 
>>> 156:         AffineTransform at = new AffineTransform();
>>> 157:         Stroke oldStk = new BasicStroke();
>>> 158:         int stkWidth = 1;
>> 
>> Now the usage of these variables is restricted to the case where `resetTransform` is set to `true`. Therefore, they can be left uninitialised here; a value is assigned before it's used in all the code paths as far as I can see.
>> 
>> It's just a small (premature) optimisation, it avoids creating two objects. I don't insist though.
>
> I'd be inclined to remove the initialisation.

I see, the static analyser is not smart enough to notice that the variables get initialised before they're used.

To resolve the error, initialise `at` and `oldStk` with `null`.

`stkWidth` needs to be initialised by 1 as it's currently done, it's always used.

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

PR: https://git.openjdk.org/jdk/pull/7449


From aivanov at openjdk.java.net  Fri Jun 10 19:58:12 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 10 Jun 2022 19:58:12 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v25]
In-Reply-To: <5OeF1xoZhJSeVPXfYvAaLVXD4z3SJI7sUj8Mp19dQ9w=.ecb50ef6-2c7b-42cb-a6dc-95268662f56d@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <5OeF1xoZhJSeVPXfYvAaLVXD4z3SJI7sUj8Mp19dQ9w=.ecb50ef6-2c7b-42cb-a6dc-95268662f56d@github.com>
Message-ID: <r2H6ArKTMhtbJIgoZdrkDcokG4pAUWaeSURoSlCZ978=.e0b2cb97-364e-4af1-a638-01bcf7a73846@github.com>

On Wed, 8 Jun 2022 22:25:12 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed rendering hints, changed condition to reapply old transform

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 33:

> 31: import java.awt.Color;
> 32: import java.awt.Component;
> 33: import java.awt.RenderingHints;

RenderingHints aren't used, to be removed.

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

PR: https://git.openjdk.org/jdk/pull/7449


From clanger at openjdk.java.net  Fri Jun 10 20:16:05 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Fri, 10 Jun 2022 20:16:05 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <nvWG4eKOXZIiB9FBNDHzbqmR9jVghlYQAGgDprq1Yl8=.2318a5e3-a50d-4719-b43c-53f0ff1a0138@github.com>

On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

Looks good to me.

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

Marked as reviewed by clanger (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9105


From prr at openjdk.java.net  Fri Jun 10 21:08:03 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 10 Jun 2022 21:08:03 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <BWDc3GhMpw9OZ71u7HtHOzza-oh0l2oiw0Zp74gDbu0=.ddccdd37-1179-4aac-b2ed-0927138c6f6a@github.com>

On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 38:

> 36: #  define ROUND_TO_INT(num)    ((int) round(num))
> 37: #else
> 38: #  define ROUND_TO_INT(num)    ((int) floor((num) + 0.5))

If you look at when and why this was introduced (*), the "else" was not to support some other compiler - it was to support the older MS compiler. So if you don't want that, then the whole thing reduces to
#define ROUND_TO_INT(num) ((int) round(num))

.. you could even go further and eliminate the macro altogether if it makes sense - you'd have to look at the usages.

Same logic applies to the other files.


(*) https://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010889.html

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

PR: https://git.openjdk.org/jdk/pull/9105


From achung at openjdk.java.net  Fri Jun 10 22:15:34 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Fri, 10 Jun 2022 22:15:34 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v26]
In-Reply-To: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
Message-ID: <WL5wNEm_Jsla5tRiC6uleAG0NXjO9-7c0cCmEP_vcvE=.6f6024b0-3a77-4871-8d08-904dd5661198@github.com>

> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:

 - changed initializations to null
 - removed initialization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/7449/files
  - new: https://git.openjdk.org/jdk/pull/7449/files/35e7d5a8..93f0b73c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=25
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=24-25

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

PR: https://git.openjdk.org/jdk/pull/7449


From prr at openjdk.java.net  Fri Jun 10 22:15:34 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 10 Jun 2022 22:15:34 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v25]
In-Reply-To: <RScIQwbXWRrdG9fPH4_dlkGJLzGumJPdjgxw2F1VMV0=.38089d0d-090e-4d5b-a716-57228889ffb9@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <5OeF1xoZhJSeVPXfYvAaLVXD4z3SJI7sUj8Mp19dQ9w=.ecb50ef6-2c7b-42cb-a6dc-95268662f56d@github.com>
 <4p0Hu6kjL0vKi2-tDQY41slAKGYm2rPmQs9VgTWSXNc=.1e48064b-687f-46a5-a6f0-c6e9a4490468@github.com>
 <yRnCrnUxByPUfcZLJUdOcy4F-KEnkzgrkE85lDtqrDI=.b3323f8c-c9a9-4a97-831b-b36de4317ad1@github.com>
 <RScIQwbXWRrdG9fPH4_dlkGJLzGumJPdjgxw2F1VMV0=.38089d0d-090e-4d5b-a716-57228889ffb9@github.com>
Message-ID: <PQgy50bGKpULxTDWCq_dtJtYPN92ahvUxKfDEcTghFU=.f6f8891a-135b-4ae2-bb6a-f7f975e25372@github.com>

On Fri, 10 Jun 2022 19:36:50 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I'd be inclined to remove the initialisation.
>
> I see, the static analyser is not smart enough to notice that the variables get initialised before they're used.
> 
> To resolve the error, initialise `at` and `oldStk` with `null`.
> 
> `stkWidth` needs to be initialised by 1 as it's currently done, its value is used even if `resetTransform` remains `false`.

Yes, seems the code logic is too much for the compiler
intuitively I'd have expected that it should be, but you'd need to restructure to fix it ..

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

PR: https://git.openjdk.org/jdk/pull/7449


From achung at openjdk.java.net  Fri Jun 10 23:21:24 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Fri, 10 Jun 2022 23:21:24 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v27]
In-Reply-To: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
Message-ID: <X4b9B8AOfTVNaO2k81TGyWTbxSgvbdisSwzfzCAnkmg=.c6617b75-21c6-42d7-bd48-f0fef3ee50e5@github.com>

> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

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

  fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/7449/files
  - new: https://git.openjdk.org/jdk/pull/7449/files/93f0b73c..610d8f81

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=26
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=25-26

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

PR: https://git.openjdk.org/jdk/pull/7449


From honkar at openjdk.java.net  Sat Jun 11 00:10:57 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Sat, 11 Jun 2022 00:10:57 GMT
Subject: RFR: 8265586: [windows] last button is not shown in AWT Frame with
 BorderLayout and MenuBar set. [v2]
In-Reply-To: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
References: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
Message-ID: <hqn786i9Vea94rpGYxMYcEI-eyjm272bhFjSRaS2AXU=.c2474ccf-bbd4-42e2-b1fd-df97fee8b6d6@github.com>

> Due to incorrect AWT Frame inset values being returned from native code, few of the components in the frame were not being shown completely on Windows. With the proposed fix, correct insets are obtained which in turn sizes and displays the frame correctly.
> 
> The default insets obtained from the Win system was adding only `::GetSystemMetrics(SM_CXSIZEFRAME)` for **WS_THICKFRAME** and the insets were off by few pixels from the expected value. `::GetSystemMetrics(SM_CXPADDEDBORDER)` is additionally added to top, bottom, left and right insets to account for the 6px. [GetSystemMetric() Document](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics)
> 
> A test case is added which checks if the actual frame size is equal to the expected frame size (frame.getSize() == frame.getPreferredSize()), thus checking if frame.pack() works as expected.
> 
> Following are before and after screenshots - 
> ![image](https://user-images.githubusercontent.com/95945681/172999272-981a0b07-2bd1-425c-b73d-f21f68922262.png)

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  removed os version check, added review changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9118/files
  - new: https://git.openjdk.org/jdk/pull/9118/files/afe3afbc..a6a2e429

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

  Stats: 43 lines in 2 files changed: 15 ins; 20 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/9118.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9118/head:pull/9118

PR: https://git.openjdk.org/jdk/pull/9118


From honkar at openjdk.java.net  Sat Jun 11 00:33:58 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Sat, 11 Jun 2022 00:33:58 GMT
Subject: RFR: 8265586: [windows] last button is not shown in AWT Frame with
 BorderLayout and MenuBar set. [v2]
In-Reply-To: <-6qqIIcOwHkFFet5HtU3TQPa9M7VmySbMXYIxc-CpC8=.727b7269-4840-4e01-9c99-2548ddec6841@github.com>
References: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
 <-6qqIIcOwHkFFet5HtU3TQPa9M7VmySbMXYIxc-CpC8=.727b7269-4840-4e01-9c99-2548ddec6841@github.com>
Message-ID: <f-zFqrpmBNLGCeESTezSWVQ_-K9DfgfkEbcmxoFQ2qY=.15e780b7-4bc0-491a-a150-6655b87604b8@github.com>

On Fri, 10 Jun 2022 12:01:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed os version check, added review changes
>
> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1440:
> 
>> 1438:                     ::GetSystemMetrics(SM_CXDLGFRAME);
>> 1439:                 m_insets.top = m_insets.bottom =
>> 1440:                     ::GetSystemMetrics(SM_CYDLGFRAME);
> 
> It's likely needed here as well.
> 
> Make the frame non-resizeable to get into this block.

Added `SM_CXPADDEDBORDER` to Non-Resizable Frames. After the addition of padded border the second button is being shown similar to Resizable frames. But unlike resizable frames,  for the non-resizable frames - the actual frame size and the preferred size are different. Ideally the frame.getSize() should be equal to preferred size when frame.pack() is used.

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

PR: https://git.openjdk.org/jdk/pull/9118


From honkar at openjdk.java.net  Sat Jun 11 00:49:10 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Sat, 11 Jun 2022 00:49:10 GMT
Subject: RFR: 8265586: [windows] last button is not shown in AWT Frame with
 BorderLayout and MenuBar set. [v2]
In-Reply-To: <f-zFqrpmBNLGCeESTezSWVQ_-K9DfgfkEbcmxoFQ2qY=.15e780b7-4bc0-491a-a150-6655b87604b8@github.com>
References: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
 <-6qqIIcOwHkFFet5HtU3TQPa9M7VmySbMXYIxc-CpC8=.727b7269-4840-4e01-9c99-2548ddec6841@github.com>
 <f-zFqrpmBNLGCeESTezSWVQ_-K9DfgfkEbcmxoFQ2qY=.15e780b7-4bc0-491a-a150-6655b87604b8@github.com>
Message-ID: <0hoGffa--wuo5Sb3m1Nj5Ergyg55sLsM0C9-_tzfv5g=.bb01d924-95ac-45de-8a0d-f0292c929335@github.com>

On Sat, 11 Jun 2022 00:30:20 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1440:
>> 
>>> 1438:                     ::GetSystemMetrics(SM_CXDLGFRAME);
>>> 1439:                 m_insets.top = m_insets.bottom =
>>> 1440:                     ::GetSystemMetrics(SM_CYDLGFRAME);
>> 
>> It's likely needed here as well.
>> 
>> Make the frame non-resizeable to get into this block.
>
> Added `SM_CXPADDEDBORDER` to Non-Resizable Frames. After the addition of padded border the second button is being shown similar to Resizable frames. But unlike resizable frames,  for the non-resizable frames - the actual frame size and the preferred size are different. Ideally the frame.getSize() should be equal to preferred size when frame.pack() is used.

Side-by-Side comparison of Resizable and Non-Resizable frames  - Resizable frame slightly wider and taller compared to non-resizable. 

On UiScale =1,
Resizable Frame size= java.awt.Dimension[width=241,height=119]
Non-Resizable Frame size = java.awt.Dimension[width=237,height=115]

![image](https://user-images.githubusercontent.com/95945681/173165801-a387f853-bff0-4c16-ba83-056069137dac.png)

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

PR: https://git.openjdk.org/jdk/pull/9118


From ihse at openjdk.java.net  Sat Jun 11 09:58:10 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Sat, 11 Jun 2022 09:58:10 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v6]
In-Reply-To: <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
Message-ID: <H1W5bpGcXIH-8_JXu6cX9u2UEwHMfb52yJVB5rvfYVs=.a0302b8f-c2e1-43b4-ab5b-44e13c9f21b7@github.com>

On Fri, 13 May 2022 16:53:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision:
> 
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/40c585cd...98e635a5

Thank you bot. I'm on it!

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

PR: https://git.openjdk.org/jdk/pull/8328


From mbaesken at openjdk.java.net  Mon Jun 13 07:24:52 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 13 Jun 2022 07:24:52 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  use round directly

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9105/files
  - new: https://git.openjdk.org/jdk/pull/9105/files/ee8dc996..e97c8329

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

  Stats: 21 lines in 3 files changed: 0 ins; 17 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9105.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9105/head:pull/9105

PR: https://git.openjdk.org/jdk/pull/9105


From mbaesken at openjdk.java.net  Mon Jun 13 07:24:53 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 13 Jun 2022 07:24:53 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]
In-Reply-To: <BWDc3GhMpw9OZ71u7HtHOzza-oh0l2oiw0Zp74gDbu0=.ddccdd37-1179-4aac-b2ed-0927138c6f6a@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <BWDc3GhMpw9OZ71u7HtHOzza-oh0l2oiw0Zp74gDbu0=.ddccdd37-1179-4aac-b2ed-0927138c6f6a@github.com>
Message-ID: <dNLh7YlIe945J7TSYatk82tCc3HzmB5YF0ogLmt2dVg=.fad405f8-0895-4e22-a7b8-2b09e1afea2a@github.com>

On Fri, 10 Jun 2022 21:04:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use round directly
>
> src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 38:
> 
>> 36: #  define ROUND_TO_INT(num)    ((int) round(num))
>> 37: #else
>> 38: #  define ROUND_TO_INT(num)    ((int) floor((num) + 0.5))
> 
> If you look at when and why this was introduced (*), the "else" was not to support some other compiler - it was to support the older MS compiler. So if you don't want that, then the whole thing reduces to
> #define ROUND_TO_INT(num) ((int) round(num))
> 
> .. you could even go further and eliminate the macro altogether if it makes sense - you'd have to look at the usages.
> 
> Same logic applies to the other files.
> 
> 
> (*) https://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010889.html

Hi Phil, I simplified the code more and now use round directly.

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

PR: https://git.openjdk.org/jdk/pull/9105


From serb at openjdk.java.net  Mon Jun 13 07:41:03 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 13 Jun 2022 07:41:03 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v13]
In-Reply-To: <fl4LtVyoXfiaQhLY3FMnaO1HtS35ZIfbKAhYNGLSQus=.74efb62e-1158-4004-8823-ba98663f1b86@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <fl4LtVyoXfiaQhLY3FMnaO1HtS35ZIfbKAhYNGLSQus=.74efb62e-1158-4004-8823-ba98663f1b86@github.com>
Message-ID: <ln_b2SiKrHn4f4nD3Jxam1twqB-dL48gESfcp5QQYAE=.dc8919be-7614-468d-bbab-a1b32cd63b46@github.com>

On Thu, 9 Jun 2022 18:15:03 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated doc.

Probably we should mark this new block of text as implementation details or notes or something? Or will we consider it part of the spec against which the new tck tests be created?

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

PR: https://git.openjdk.org/jdk/pull/7446


From serb at openjdk.java.net  Mon Jun 13 08:03:57 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 13 Jun 2022 08:03:57 GMT
Subject: RFR: 8287743: javax/swing/text/CSSBorder/6796710/bug6796710.java
 failed [v2]
In-Reply-To: <Z8WYGkTX00FshprjuxYWbEmZmL68sEzOTdQIF82561M=.fada437c-c2c1-4b63-8feb-af3b7d478b82@github.com>
References: <CHUcgeyccAuzQB3lKZ83qzOSseh4Mfb0EIRR9fxVEKY=.d2628e3f-4a03-4753-9e4c-de47c8a8f52f@github.com>
 <tA6NanagDur6PgX8_CfFc2x-YgjknkKPCHJcvEmqGF0=.df8f5ac3-bdc1-488d-a79a-11dcde368be9@github.com>
 <DiaaEHludW7a2Aa3NSLZIHACxUC0hGTWWCdcRimD3VQ=.42cb8dc5-c2a9-43c9-922d-c5cc1b3b29ce@github.com>
 <ktVuNTIc6nLToUQ_l5AzNF99gWK--71qUQDK3OVwHlo=.2e927921-6504-4f86-86b3-92fba42e7bc5@github.com>
 <5a03vAMfkMnFN7maIyKNjzsv4vhED-ssWpE8jE9zacM=.cb079e84-0091-467e-a9f4-1fbaf9c1f0cb@github.com>
 <tlXy1lpQkB_Hqie3Zo7U9G4_WDA1t6AAIZduGPoBgvg=.3aa8332f-bc2a-40e4-9a45-853fa148ed7f@github.com>
 <ao-6NWtzk_t1ENzyEhJWkbEum-BgqncTGUPnYThyp5o=.94df6d70-15b4-4fb4-af70-13f47a355e61@github.com>
 <QT5-i3Y_xpwQfc7wiLVwoY1Nz4G6u7x62YvkrwVgQPo=.a6e825a9-b114-48d3-a0c5-62e42c93ddbe@github.com>
 <QbLmexy7rrNGlj2YDMpJ_-Hyc7-inp8NN1j9G3LWYIk=.8d08b952-ae4e-4042-8273-29ddd3894f8d@github.com>
 <Z8WYGkTX00FshprjuxYWbEmZmL68sEzOTdQIF82561M=.fada437c-c2c1-4b63-8feb-af3b7d478b82@github.com>
Message-ID: <ch7OxcOBtJQGaDqzzk6oXSiZOHwiaoS_5qKf1ky3xhU=.377979a4-6873-4837-83d6-ff319e2c2145@github.com>

On Fri, 10 Jun 2022 12:26:20 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It still fails once or twice with createMultiResolutionScreenCapture if the test iteration is increased, so I think color tolerance, even if defensive, is the one to go for.
>
>> On the HiDPI screen that MRI will have two images, and my expectation is that the image requested by the updated test and the image used before the fix should be the same.
> 
> In this case, yes, the image will be the same as before: a scaled down bitmap you get with regular `createScreenCapture`.
> 
>> How to find those 2 bufferedimages returned by createMultiResolutionScreenCapture and createScreenCapture are same or not apart from pixel check (which shows obviously they are not same and color differ by 1)?
> 
> You can get the largest variant, and compare colors there. Yet the size of the two images will be different, most likely.

> It still fails once or twice with createMultiResolutionScreenCapture if the test iteration is increased, so I think color tolerance, even if defensive, is the one to go for.

So we return back to the initial question, why the code which capture same window rendered in same color in the same location produce different results? Why the tolerance is needed, Is it possible that the robot or rendering generate some garbage or override/read something wrong in memory?

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

PR: https://git.openjdk.org/jdk/pull/9011


From mdoerr at openjdk.java.net  Mon Jun 13 10:12:07 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 13 Jun 2022 10:12:07 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]
In-Reply-To: <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>
Message-ID: <m5D_rDzd-3NEkUD13SO3ZeXoKJFvWPAR7B-HUshyNlw=.e94d9098-4e20-451a-b58d-df86c87b87c7@github.com>

On Mon, 13 Jun 2022 07:24:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
>> 
>> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
>> VALID_VS_VERSIONS="2019 2017 2022"
>> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use round directly

Nice!

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

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9105


From aturbanov at openjdk.java.net  Mon Jun 13 10:36:54 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 13 Jun 2022 10:36:54 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]
In-Reply-To: <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>
Message-ID: <SUUtDTu4nJk6ynOPqW1O8zG3ESs1fz9D2hFy5qjqTHM=.94191838-3212-4261-ac0b-4e4f26e2dc9d@github.com>

On Mon, 13 Jun 2022 07:24:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
>> 
>> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
>> VALID_VS_VERSIONS="2019 2017 2022"
>> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use round directly

src/hotspot/share/adlc/main.cpp line 491:

> 489: }
> 490: 
> 491: // VS2005 has its own definition, identical to this one.

Let's adjust comment too. No need to mention VS2005.

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

PR: https://git.openjdk.org/jdk/pull/9105


From mbaesken at openjdk.java.net  Mon Jun 13 11:46:53 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 13 Jun 2022 11:46:53 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]
In-Reply-To: <SUUtDTu4nJk6ynOPqW1O8zG3ESs1fz9D2hFy5qjqTHM=.94191838-3212-4261-ac0b-4e4f26e2dc9d@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>
 <SUUtDTu4nJk6ynOPqW1O8zG3ESs1fz9D2hFy5qjqTHM=.94191838-3212-4261-ac0b-4e4f26e2dc9d@github.com>
Message-ID: <--XzEepPg2J69xcO4_8XjnUr6zUwWrbRFvw3Y87zEV8=.69b1d008-159c-49f3-a685-4115e4d6d53d@github.com>

On Mon, 13 Jun 2022 10:33:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use round directly
>
> src/hotspot/share/adlc/main.cpp line 491:
> 
>> 489: }
>> 490: 
>> 491: // VS2005 has its own definition, identical to this one.
> 
> Let's adjust comment too. No need to mention VS2005.

Thanks for the hint, I removed the VS2005 related comment.

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

PR: https://git.openjdk.org/jdk/pull/9105


From mbaesken at openjdk.java.net  Mon Jun 13 11:46:52 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 13 Jun 2022 11:46:52 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v3]
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <7Ep2pzeiYSx4eA1UNVNTnPLNBskrORoTRlvEJy4votc=.3a6c781b-378f-4da6-b575-7cd325e684d5@github.com>

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  remove VS2005 comment in adlc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9105/files
  - new: https://git.openjdk.org/jdk/pull/9105/files/e97c8329..97659965

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

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

PR: https://git.openjdk.org/jdk/pull/9105


From aivanov at openjdk.java.net  Mon Jun 13 13:44:17 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 13 Jun 2022 13:44:17 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v27]
In-Reply-To: <X4b9B8AOfTVNaO2k81TGyWTbxSgvbdisSwzfzCAnkmg=.c6617b75-21c6-42d7-bd48-f0fef3ee50e5@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <X4b9B8AOfTVNaO2k81TGyWTbxSgvbdisSwzfzCAnkmg=.c6617b75-21c6-42d7-bd48-f0fef3ee50e5@github.com>
Message-ID: <u4Sdfz0nvs--QQWHo_omtM5P5ufgmEpo7caNayzETf0=.40ed2bf7-5c09-4881-bb17-81d5bbffd914@github.com>

On Fri, 10 Jun 2022 23:21:24 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/7449


From aivanov at openjdk.java.net  Mon Jun 13 13:48:30 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 13 Jun 2022 13:48:30 GMT
Subject: RFR: 8279614: The left line of the TitledBorder is not painted on
 150 scale factor [v27]
In-Reply-To: <X4b9B8AOfTVNaO2k81TGyWTbxSgvbdisSwzfzCAnkmg=.c6617b75-21c6-42d7-bd48-f0fef3ee50e5@github.com>
References: <xo3qlnwRezly7wAHci7-JIY-GFkyyNj972o6sWxijy8=.1da3da10-f8b0-4e52-849c-20e9bee3b260@github.com>
 <X4b9B8AOfTVNaO2k81TGyWTbxSgvbdisSwzfzCAnkmg=.c6617b75-21c6-42d7-bd48-f0fef3ee50e5@github.com>
Message-ID: <6V536NGaH3HlGzb3325zU9ySTHij5FVuit4OtvUVkw8=.e7ec5b51-f0ca-4153-98a2-a159dc75c99f@github.com>

On Fri, 10 Jun 2022 23:21:24 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Please remove import `java.awt.RenderingHints;` from `EtchedBorder.java`.

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

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/7449


From honkar at openjdk.java.net  Mon Jun 13 23:02:59 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Mon, 13 Jun 2022 23:02:59 GMT
Subject: RFR: 8284619: javax/swing/JTable/8236907/LastVisibleRow.java
 failed with "Test Case Failed!!, Last Row not Visible!!!"
In-Reply-To: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
References: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
Message-ID: <KEp3vjRZ6AVa2dZy44p7YzgsQSRmIV43dmHtWex-7ro=.450a45fb-a475-49ed-b6b0-3739cffa6437@github.com>

On Fri, 10 Jun 2022 05:35:22 GMT, Tejesh R <tr at openjdk.org> wrote:

> Fix history - #7422.
> The test is automatic and check if the last row is painted (Which was not happening before the fix, the last row appeared only after MouseClick operation) by capturing the last row before and after MouseClick Operation.If the both the captured images are same, then the test passes else it fails.
> This Fix includes for ubuntu and macos failure, in which only the test case failed due to following reasons.
> 
> In ubuntu, the test fails due to unexpected dark line appearing on right side of last row before MouseClick operation.
> In macos, the test fails since after MouseClick operation of last row, clearSelection didn't show any effect on the selected row.
> The issue is intermittent and not able to reproduce it frequently. As a defensive fix, the rectangular area which is being captured is reduce for ubuntu failure and Delay is added between ClearSelection of focus and Image Capture for macos failure

In getCellClickPoint() method, you could simply the code by returning point variable , instead of using extra result variable. https://github.com/openjdk/jdk/blob/8722b1b020f30d54e2eab2122c2b1777a6e5182a/test/jdk/javax/swing/JTable/8236907/LastVisibleRow.java#L102

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

PR: https://git.openjdk.org/jdk/pull/9117


From honkar at openjdk.java.net  Tue Jun 14 00:23:52 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Tue, 14 Jun 2022 00:23:52 GMT
Subject: RFR: 8284619: javax/swing/JTable/8236907/LastVisibleRow.java
 failed with "Test Case Failed!!, Last Row not Visible!!!"
In-Reply-To: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
References: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
Message-ID: <TcYS89bMEK6u2znn9HzUKT7aKGkhpBIm2aFqnOcmH9Y=.3ee8bc6d-8584-47bb-bafc-ebde2f12d40f@github.com>

On Fri, 10 Jun 2022 05:35:22 GMT, Tejesh R <tr at openjdk.org> wrote:

> Fix history - #7422.
> The test is automatic and check if the last row is painted (Which was not happening before the fix, the last row appeared only after MouseClick operation) by capturing the last row before and after MouseClick Operation.If the both the captured images are same, then the test passes else it fails.
> This Fix includes for ubuntu and macos failure, in which only the test case failed due to following reasons.
> 
> In ubuntu, the test fails due to unexpected dark line appearing on right side of last row before MouseClick operation.
> In macos, the test fails since after MouseClick operation of last row, clearSelection didn't show any effect on the selected row.
> The issue is intermittent and not able to reproduce it frequently. As a defensive fix, the rectangular area which is being captured is reduce for ubuntu failure and Delay is added between ClearSelection of focus and Image Capture for macos failure

If the test criteria is to check if the last row is visible, then the following suggestion might help to make the test more stable on different platforms.

This is similar to one of the issues I was working on and @[azuev-java](https://github.com/azuev-java) suggested a good idea, that I think could be applicable here too.

- Set the background of last row (can be done for all the cells of the third row) to a different color, say red.
- Check if this color is visible using Robot.getPixelColor() at desired location.
- If red is returned then the third row is visible, else throw RuntimeException()

This would simplify the test case as you wouldn't have to compare two buffered images - before and after images and deal with platform specific issues such as unexpected dark line (on Ubuntu) and clearing the focus (on Mac). 

Hope this helps :)

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

PR: https://git.openjdk.org/jdk/pull/9117


From tr at openjdk.java.net  Tue Jun 14 04:59:55 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Tue, 14 Jun 2022 04:59:55 GMT
Subject: RFR: 8284619: javax/swing/JTable/8236907/LastVisibleRow.java
 failed with "Test Case Failed!!, Last Row not Visible!!!"
In-Reply-To: <jAQDoZpfutT39pzfCC72asGPvH7EjDfQgSvJEsajtPQ=.2c874032-e902-4abd-90b4-bf39f7d859f3@github.com>
References: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
 <jAQDoZpfutT39pzfCC72asGPvH7EjDfQgSvJEsajtPQ=.2c874032-e902-4abd-90b4-bf39f7d859f3@github.com>
Message-ID: <bz2EdqsPyLr_DgqQxMgiwqayBMMwmtX9I4SIVFoq6j0=.e9cdf44f-0bb0-4882-8c4b-3443090a41b9@github.com>

On Mon, 13 Jun 2022 22:35:41 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Fix history - #7422.
>> The test is automatic and check if the last row is painted (Which was not happening before the fix, the last row appeared only after MouseClick operation) by capturing the last row before and after MouseClick Operation.If the both the captured images are same, then the test passes else it fails.
>> This Fix includes for ubuntu and macos failure, in which only the test case failed due to following reasons.
>> 
>> In ubuntu, the test fails due to unexpected dark line appearing on right side of last row before MouseClick operation.
>> In macos, the test fails since after MouseClick operation of last row, clearSelection didn't show any effect on the selected row.
>> The issue is intermittent and not able to reproduce it frequently. As a defensive fix, the rectangular area which is being captured is reduce for ubuntu failure and Delay is added between ClearSelection of focus and Image Capture for macos failure
>
> test/jdk/javax/swing/JTable/8236907/LastVisibleRow.java line 172:
> 
>> 170:                 SwingUtilities.convertPointToScreen(point, table);
>> 171: 
>> 172:                 captureRect[0] = new Rectangle(point.x+5, point.y+2, table.getColumnCount() * cellRect.width - 10, cellRect.height-2);
> 
> Please adjust line lengths. Some of the lines contain more than 80 characters.

Updated.

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

PR: https://git.openjdk.org/jdk/pull/9117


From tr at openjdk.java.net  Tue Jun 14 05:17:48 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Tue, 14 Jun 2022 05:17:48 GMT
Subject: RFR: 8284619: javax/swing/JTable/8236907/LastVisibleRow.java
 failed with "Test Case Failed!!, Last Row not Visible!!!"
In-Reply-To: <TcYS89bMEK6u2znn9HzUKT7aKGkhpBIm2aFqnOcmH9Y=.3ee8bc6d-8584-47bb-bafc-ebde2f12d40f@github.com>
References: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
 <TcYS89bMEK6u2znn9HzUKT7aKGkhpBIm2aFqnOcmH9Y=.3ee8bc6d-8584-47bb-bafc-ebde2f12d40f@github.com>
Message-ID: <sgYNs4KOvCRfJvNUr_2jejA2YNXEf3T53KnYjM5003s=.10fd9064-2ce6-417e-8977-4b9d8e4900ae@github.com>

On Tue, 14 Jun 2022 00:20:18 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> If the test criteria is to check if the last row is visible, then the following suggestion might help to make the test more stable on different platforms.
> 
> This is similar to one of the issues I'm working on and @[azuev-java](https://github.com/azuev-java) suggested a good idea, that I think could be applicable here too.
> 
> * Set the background of ONLY the last row to a different color, say red. (can be done for all the cells of the third row)
> * Check if this color is visible using Robot.getPixelColor() at desired location.
> * If red is returned then the third row is visible, else throw RuntimeException()
> 
> This would simplify the test case as you wouldn't have to compare two buffered images - before and after images and deal with platform specific issues such as unexpected dark line (on Ubuntu) and clearing the focus (on Mac).
> 
> Hope this helps :)

Its really helpful suggestion. But in this case we are validating the last row contents, not the last row itself. Before the fix the last row was painted without the contents, after the fix we are validating whether the contents are printed on it. We still can use the technique though to verify the contents, means have to get the text content position and check if it is black or still background color. But I feel for this test case this technique wont be robust enough and finding the text area inside the cell might not be accurate always.

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

PR: https://git.openjdk.org/jdk/pull/9117


From tr at openjdk.java.net  Tue Jun 14 05:36:36 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Tue, 14 Jun 2022 05:36:36 GMT
Subject: RFR: 8284619: javax/swing/JTable/8236907/LastVisibleRow.java
 failed with "Test Case Failed!!, Last Row not Visible!!!" [v2]
In-Reply-To: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
References: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
Message-ID: <fcFTFXGRHdOlROPmimXNGJXhBsnHvfqJWU2ED90dD1w=.f65e2061-1ecd-41d4-b41a-66736d078ab1@github.com>

> Fix history - #7422.
> The test is automatic and check if the last row is painted (Which was not happening before the fix, the last row appeared only after MouseClick operation) by capturing the last row before and after MouseClick Operation.If the both the captured images are same, then the test passes else it fails.
> This Fix includes for ubuntu and macos failure, in which only the test case failed due to following reasons.
> 
> In ubuntu, the test fails due to unexpected dark line appearing on right side of last row before MouseClick operation.
> In macos, the test fails since after MouseClick operation of last row, clearSelection didn't show any effect on the selected row.
> The issue is intermittent and not able to reproduce it frequently. As a defensive fix, the rectangular area which is being captured is reduce for ubuntu failure and Delay is added between ClearSelection of focus and Image Capture for macos failure

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9117/files
  - new: https://git.openjdk.org/jdk/pull/9117/files/8722b1b0..4b023577

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

  Stats: 18 lines in 1 file changed: 7 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/9117.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9117/head:pull/9117

PR: https://git.openjdk.org/jdk/pull/9117


From tr at openjdk.java.net  Tue Jun 14 05:36:36 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Tue, 14 Jun 2022 05:36:36 GMT
Subject: RFR: 8284619: javax/swing/JTable/8236907/LastVisibleRow.java
 failed with "Test Case Failed!!, Last Row not Visible!!!"
In-Reply-To: <KEp3vjRZ6AVa2dZy44p7YzgsQSRmIV43dmHtWex-7ro=.450a45fb-a475-49ed-b6b0-3739cffa6437@github.com>
References: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
 <KEp3vjRZ6AVa2dZy44p7YzgsQSRmIV43dmHtWex-7ro=.450a45fb-a475-49ed-b6b0-3739cffa6437@github.com>
Message-ID: <C_vGLi4WiWOySKMvTSVmtAmI--m6EeZ_fipoNMRSkrQ=.0dd80b42-6b8e-4826-81e3-db60315ab6ca@github.com>

On Mon, 13 Jun 2022 22:59:41 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> In getCellClickPoint() method, you could simplify the code by returning point variable , instead of using extra result variable.
> 
> https://github.com/openjdk/jdk/blob/8722b1b020f30d54e2eab2122c2b1777a6e5182a/test/jdk/javax/swing/JTable/8236907/LastVisibleRow.java#L102

Updated.

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

PR: https://git.openjdk.org/jdk/pull/9117


From kizune at openjdk.java.net  Tue Jun 14 06:21:55 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 14 Jun 2022 06:21:55 GMT
Subject: RFR: 8265586: [windows] last button is not shown in AWT Frame with
 BorderLayout and MenuBar set. [v3]
In-Reply-To: <D82_x0RRX-yScAZViPoxbdyBAyoaIflzwbro_3U5gWU=.3952aa60-9f69-418e-89a4-8425ee055b22@github.com>
References: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
 <D82_x0RRX-yScAZViPoxbdyBAyoaIflzwbro_3U5gWU=.3952aa60-9f69-418e-89a4-8425ee055b22@github.com>
Message-ID: <FPUn9LH_rMFy_DFUKv9kn1ajc6jPxdhZC_JvssAU6ro=.04ded1ed-0335-4446-b0cf-0e32a43450a4@github.com>

On Fri, 10 Jun 2022 06:02:51 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor changes
>
> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1407:
> 
>> 1405:     int extraPaddedBorderInsets = info.dwMajorVersion >= 6 ?
>> 1406:      ::GetSystemMetrics(SM_CXPADDEDBORDER) : 0;
>> 1407: 
> 
> The OS version check is added since **SM_CXPADDEDBORDER** metric is not supported on Win XP & 2000. If the current JDK Window target OS version is set to Windows Vista, probably this check is not required or redundant. Suggestions would be helpful as to whether to retain this check or not
> 
> ![image](https://user-images.githubusercontent.com/95945681/173000377-4109fd09-f8e3-43a3-aa62-3d0c67d2ff56.png)
>  
> Screenshot source: [GetSystemMetrics Doc](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics)

You can look at the oficially supported versions of operating systems by different Java versions here: https://www.oracle.com/java/technologies/javase-subscription/documentation.html#sysconfig
Nothing even remotely relevant supports Windows XP.

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

PR: https://git.openjdk.org/jdk/pull/9118


From mbaesken at openjdk.java.net  Tue Jun 14 07:18:08 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Jun 2022 07:18:08 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v3]
In-Reply-To: <7Ep2pzeiYSx4eA1UNVNTnPLNBskrORoTRlvEJy4votc=.3a6c781b-378f-4da6-b575-7cd325e684d5@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <7Ep2pzeiYSx4eA1UNVNTnPLNBskrORoTRlvEJy4votc=.3a6c781b-378f-4da6-b575-7cd325e684d5@github.com>
Message-ID: <F8p1pl8Xqp0YUWSM2CVv6dOYOmi4JfzNLPDm_kDEgXg=.7fd59069-da46-46f5-b23a-3c0c8776b933@github.com>

On Mon, 13 Jun 2022 11:46:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
>> 
>> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
>> VALID_VS_VERSIONS="2019 2017 2022"
>> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove VS2005 comment in adlc

Hi Phil and Andrey are you fine with the current version of the PR ?

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

PR: https://git.openjdk.org/jdk/pull/9105


From aturbanov at openjdk.java.net  Tue Jun 14 07:37:05 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 14 Jun 2022 07:37:05 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v3]
In-Reply-To: <7Ep2pzeiYSx4eA1UNVNTnPLNBskrORoTRlvEJy4votc=.3a6c781b-378f-4da6-b575-7cd325e684d5@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <7Ep2pzeiYSx4eA1UNVNTnPLNBskrORoTRlvEJy4votc=.3a6c781b-378f-4da6-b575-7cd325e684d5@github.com>
Message-ID: <PRMkbDt9F0wzGz15GXiw_jJCfpW7NHXz9ntnsRAFwT4=.6627e221-f9a1-48ca-8ee5-a5ea3db846f6@github.com>

On Mon, 13 Jun 2022 11:46:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
>> 
>> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
>> VALID_VS_VERSIONS="2019 2017 2022"
>> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove VS2005 comment in adlc

Marked as reviewed by aturbanov (Committer).

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

PR: https://git.openjdk.org/jdk/pull/9105


From serb at openjdk.java.net  Tue Jun 14 08:47:02 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 14 Jun 2022 08:47:02 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v6]
In-Reply-To: <sremizdcaZgk3h7eYyJlL0LyspG_Onjs8vKPu9GUrUY=.9d1223a6-276a-4868-a4d7-c2953f95fc45@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <Ynva90EcdSNf7EyAxZorJNsbqjqpYZjyggv2MOPlK10=.4478324f-75ac-4b52-9d6a-695dbae8f311@github.com>
 <7u-yUIx7WRWwfbART_dVbKunF3D9hQlfcxfpLcnZXDM=.f0d4713d-6e8e-4a67-bacd-87e6789544ea@github.com>
 <sremizdcaZgk3h7eYyJlL0LyspG_Onjs8vKPu9GUrUY=.9d1223a6-276a-4868-a4d7-c2953f95fc45@github.com>
Message-ID: <5qvI6fcJT-VJOLp15wae5FuTUK9uRDvtR72I8nAalps=.83f92002-d669-439d-90c5-ad5c36143b0d@github.com>

On Fri, 10 Jun 2022 12:22:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> How would you implement this?
> I mean the user requests the icon in user's space (right?). On a High DPI system which may change in runtime, a larger icon version is required for rendering. To get a larger icon from native, we have to keep the file name or PIDL and call shell interfaces on COM thread to fetch the icon.
 > Overall, I like the idea? We may have discussed it. Keeping only sizes that are needed will reduce the memory usage. All in all, it's definitely out of scope for this fix.

That was the whole purpose of the initial 8182043 issue, to provide a HiDPI(or various DPI) icons for the user. If the user asks for the 16x16 we will provide them the MRI where the base image is 16x16, but that MRI could also provide large images by request. If that 16x16 image renders on scale=1.25 then the MRI should generate the image which looks good on that screen. This current proposal generates it on the fly using java code, but I think it should request that information from the native system, this was the purpose of the new getSystemIcon(file,w,w) method.

We do not need to always request the icon via COM thread, we can initially load the low dpi image, or the image for the main screen scale, then if the scale changed we can request to load the HiDPI image, and use it when ready.

The wondering why it looks bad on some DPI is actually proves that the previous fix has some limitations.

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

PR: https://git.openjdk.org/jdk/pull/7805


From dmarkov at openjdk.java.net  Tue Jun 14 09:41:49 2022
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Tue, 14 Jun 2022 09:41:49 GMT
Subject: RFR: 8265586: [windows] last button is not shown in AWT Frame with
 BorderLayout and MenuBar set. [v3]
In-Reply-To: <1fTMFRhq0ez161rADVVkXu_gyEr_gh_AeE17afFPE2Q=.19d7a1d0-d3fd-4dee-bee6-f8e4c07e0651@github.com>
References: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
 <1fTMFRhq0ez161rADVVkXu_gyEr_gh_AeE17afFPE2Q=.19d7a1d0-d3fd-4dee-bee6-f8e4c07e0651@github.com>
Message-ID: <w8TLRorVzZZzxV58xnH5KGdThlC4BznqHnGUfPUzdhQ=.7cb08aa3-4ea2-4632-a413-6e8e1cc2fb28@github.com>

On Mon, 13 Jun 2022 21:24:09 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Due to incorrect AWT Frame inset values being returned from native code, few of the components in the frame were not being shown completely on Windows. With the proposed fix, correct insets are obtained which in turn sizes and displays the frame correctly.
>> 
>> The default insets obtained from the Win system was adding only `::GetSystemMetrics(SM_CXSIZEFRAME)` for **WS_THICKFRAME** and the insets were off by few pixels from the expected value. `::GetSystemMetrics(SM_CXPADDEDBORDER)` is additionally added to top, bottom, left and right insets to account for the 6px. [GetSystemMetric() Document](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics)
>> 
>> A test case is added which checks if the actual frame size is equal to the expected frame size (frame.getSize() == frame.getPreferredSize()), thus checking if frame.pack() works as expected.
>> 
>> Following are before and after screenshots - 
>> ![image](https://user-images.githubusercontent.com/95945681/172999272-981a0b07-2bd1-425c-b73d-f21f68922262.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor changes

Marked as reviewed by dmarkov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9118


From mbaesken at openjdk.java.net  Tue Jun 14 10:46:01 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Jun 2022 10:46:01 GMT
Subject: Integrated: JDK-8288094: cleanup old _MSC_VER handling
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <Wl-mzvch4bCaBlR8_EsYZBVWJJb3r6QJWYOmvWdXMCU=.a1b8b570-16a8-45a0-a2c9-13b29d29ee6f@github.com>

On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

This pull request has now been integrated.

Changeset: 0530f4e5
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0530f4e517be5d5b3ff10be8a0764e564f068c06
Stats:     163 lines in 9 files changed: 0 ins; 149 del; 14 mod

8288094: cleanup old _MSC_VER handling

Reviewed-by: mdoerr, clanger, aturbanov

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

PR: https://git.openjdk.org/jdk/pull/9105


From aivanov at openjdk.java.net  Tue Jun 14 11:14:00 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 14 Jun 2022 11:14:00 GMT
Subject: RFR: 8265586: [windows] last button is not shown in AWT Frame with
 BorderLayout and MenuBar set. [v3]
In-Reply-To: <o6KmyCew-7fF7-GOAd_84FALV47MTzBxwENHKaa7RtA=.d6ec546f-83c6-4589-a705-7a2e51a47f88@github.com>
References: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
 <1fTMFRhq0ez161rADVVkXu_gyEr_gh_AeE17afFPE2Q=.19d7a1d0-d3fd-4dee-bee6-f8e4c07e0651@github.com>
 <o6KmyCew-7fF7-GOAd_84FALV47MTzBxwENHKaa7RtA=.d6ec546f-83c6-4589-a705-7a2e51a47f88@github.com>
Message-ID: <cFMpwPSdncHFsMU_CKUbFWWUzPvtEwMaqWlxI2XUIP0=.000a0a6c-a55f-4be3-91a5-567e2db9b906@github.com>

On Mon, 13 Jun 2022 21:16:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor changes
>
> Marked as reviewed by aivanov (Reviewer).

> @aivanov-jdk The change author (@honkar-jdk) must issue an `integrate` command before the integration can be sponsored.

I was under the impression that the `integrate` command had been issued already.

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

PR: https://git.openjdk.org/jdk/pull/9118


From azvegint at openjdk.java.net  Tue Jun 14 15:38:54 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 14 Jun 2022 15:38:54 GMT
Subject: RFR: 8265586: [windows] last button is not shown in AWT Frame with
 BorderLayout and MenuBar set. [v3]
In-Reply-To: <1fTMFRhq0ez161rADVVkXu_gyEr_gh_AeE17afFPE2Q=.19d7a1d0-d3fd-4dee-bee6-f8e4c07e0651@github.com>
References: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
 <1fTMFRhq0ez161rADVVkXu_gyEr_gh_AeE17afFPE2Q=.19d7a1d0-d3fd-4dee-bee6-f8e4c07e0651@github.com>
Message-ID: <Dw84F01GA6lO93bzv901t1EtnjOmxXW2POlwBuz0yOE=.8a23dc98-5c55-40f6-b862-9ecbd77492a1@github.com>

On Mon, 13 Jun 2022 21:24:09 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Due to incorrect AWT Frame inset values being returned from native code, few of the components in the frame were not being shown completely on Windows. With the proposed fix, correct insets are obtained which in turn sizes and displays the frame correctly.
>> 
>> The default insets obtained from the Win system was adding only `::GetSystemMetrics(SM_CXSIZEFRAME)` for **WS_THICKFRAME** and the insets were off by few pixels from the expected value. `::GetSystemMetrics(SM_CXPADDEDBORDER)` is additionally added to top, bottom, left and right insets to account for the 6px. [GetSystemMetric() Document](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics)
>> 
>> A test case is added which checks if the actual frame size is equal to the expected frame size (frame.getSize() == frame.getPreferredSize()), thus checking if frame.pack() works as expected.
>> 
>> Following are before and after screenshots - 
>> ![image](https://user-images.githubusercontent.com/95945681/172999272-981a0b07-2bd1-425c-b73d-f21f68922262.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor changes

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9118


From honkar at openjdk.java.net  Tue Jun 14 16:29:03 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Tue, 14 Jun 2022 16:29:03 GMT
Subject: RFR: 8265586: [windows] last button is not shown in AWT Frame with
 BorderLayout and MenuBar set. [v3]
In-Reply-To: <FPUn9LH_rMFy_DFUKv9kn1ajc6jPxdhZC_JvssAU6ro=.04ded1ed-0335-4446-b0cf-0e32a43450a4@github.com>
References: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
 <D82_x0RRX-yScAZViPoxbdyBAyoaIflzwbro_3U5gWU=.3952aa60-9f69-418e-89a4-8425ee055b22@github.com>
 <FPUn9LH_rMFy_DFUKv9kn1ajc6jPxdhZC_JvssAU6ro=.04ded1ed-0335-4446-b0cf-0e32a43450a4@github.com>
Message-ID: <-qTrPgUXzNl-79zLNUSmOo2Lxzoxm3-APTEEomawmFw=.4b1c3d67-a4a0-4958-993f-6ced63b35ae9@github.com>

On Tue, 14 Jun 2022 06:18:50 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1407:
>> 
>>> 1405:     int extraPaddedBorderInsets = info.dwMajorVersion >= 6 ?
>>> 1406:      ::GetSystemMetrics(SM_CXPADDEDBORDER) : 0;
>>> 1407: 
>> 
>> The OS version check is added since **SM_CXPADDEDBORDER** metric is not supported on Win XP & 2000. If the current JDK Window target OS version is set to Windows Vista, probably this check is not required or redundant. Suggestions would be helpful as to whether to retain this check or not
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/173000377-4109fd09-f8e3-43a3-aa62-3d0c67d2ff56.png)
>>  
>> Screenshot source: [GetSystemMetrics Doc](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics)
>
> You can look at the oficially supported versions of operating systems by different Java versions here: https://www.oracle.com/java/technologies/javase-subscription/documentation.html#sysconfig
> Nothing even remotely relevant supports Windows XP.

@azuev-java Thank you for clarifying and sharing the link. It's a good reference for future as well.

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

PR: https://git.openjdk.org/jdk/pull/9118


From aivanov at openjdk.java.net  Tue Jun 14 17:03:06 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 14 Jun 2022 17:03:06 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v6]
In-Reply-To: <5qvI6fcJT-VJOLp15wae5FuTUK9uRDvtR72I8nAalps=.83f92002-d669-439d-90c5-ad5c36143b0d@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <Ynva90EcdSNf7EyAxZorJNsbqjqpYZjyggv2MOPlK10=.4478324f-75ac-4b52-9d6a-695dbae8f311@github.com>
 <7u-yUIx7WRWwfbART_dVbKunF3D9hQlfcxfpLcnZXDM=.f0d4713d-6e8e-4a67-bacd-87e6789544ea@github.com>
 <sremizdcaZgk3h7eYyJlL0LyspG_Onjs8vKPu9GUrUY=.9d1223a6-276a-4868-a4d7-c2953f95fc45@github.com>
 <5qvI6fcJT-VJOLp15wae5FuTUK9uRDvtR72I8nAalps=.83f92002-d669-439d-90c5-ad5c36143b0d@github.com>
Message-ID: <-lzCX_0sMzGt-MlBrMBLxJa75gvAurd6iEvdsZPi2KQ=.eff2c2c9-f097-428c-b1d7-6a751b451aef@github.com>

On Tue, 14 Jun 2022 08:42:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> That was the whole purpose of the initial 8182043 issue, to provide a HiDPI(or various DPI) icons for the user. If the user asks for the 16x16 we will provide them the MRI where the base image is 16x16, but that MRI could also provide large images by request. If that 16x16 image renders on scale=1.25 then the MRI should generate the image which looks good on that screen.

[JDK-8182043](https://bugs.openjdk.org/browse/JDK-8182043) has enhanced support for High DPI, which can be confirmed by displaying a JFileChooser (in SwingSet2) and moving it from one monitor to another or changing the scale of a monitor where it's displayed.

Before JDK-8182043, the icon was either 16?16 or 32?32 and didn't change if the scale was changed. Now the icon gets updated after the scale changes, it's noticeable on folder icons in user's home because a set of icons is fetched.

There are still two different ways where icons are fetched from the Windows shell: `Java_sun_awt_shell_Win32ShellFolder2_getIcon` and `Java_sun_awt_shell_Win32ShellFolder2_extractIcon`. As @azuev-java notes, at times the returned size doesn't match the requested size.

> This current proposal generates it on the fly using java code, but I think it should request that information from the native system, this was the purpose of the new getSystemIcon(file,w,w) method.

This current proposal handles the situation where the returned icon doesn't have the requested size.

So, there are drawbacks and limitations in the current implementation, and there are opportunities to improve it, some of them are listed in [my comment above](https://github.com/openjdk/jdk/pull/7805#discussion_r893306463). I shall submit them so that we don't forget about them, if no one else has already done it.

> We do not need to always request the icon via COM thread, we can initially load the low dpi image, or the image for the main screen scale, then if the scale changed we can request to load the HiDPI image, and use it when ready.

Why not? To request the icon of a larger size, the object which stores the icon should keep the reference to the file or folder, folders could have custom icons, and Documents, Downloads, Pictures are the examples of such folders. This must be done on COM thread because the icons are requested from the Windows shell.


I agree that we should not get all possible resolutions of an icon when only one is needed. But it's out of scope of this particular issue.

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

PR: https://git.openjdk.org/jdk/pull/7805


From honkar at openjdk.java.net  Tue Jun 14 19:51:46 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Tue, 14 Jun 2022 19:51:46 GMT
Subject: Integrated: 8265586: [windows] last button is not shown in AWT Frame
 with BorderLayout and MenuBar set.
In-Reply-To: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
References: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
Message-ID: <NW8Y3wqvBgDKrir6IvB5cSfDZ-xG6NomHBKhgeAJs-s=.bfac68a1-0750-4a60-b230-c94982baeda0@github.com>

On Fri, 10 Jun 2022 05:55:35 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Due to incorrect AWT Frame inset values being returned from native code, few of the components in the frame were not being shown completely on Windows. With the proposed fix, correct insets are obtained which in turn sizes and displays the frame correctly.
> 
> The default insets obtained from the Win system was adding only `::GetSystemMetrics(SM_CXSIZEFRAME)` for **WS_THICKFRAME** and the insets were off by few pixels from the expected value. `::GetSystemMetrics(SM_CXPADDEDBORDER)` is additionally added to top, bottom, left and right insets to account for the 6px. [GetSystemMetric() Document](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics)
> 
> A test case is added which checks if the actual frame size is equal to the expected frame size (frame.getSize() == frame.getPreferredSize()), thus checking if frame.pack() works as expected.
> 
> Following are before and after screenshots - 
> ![image](https://user-images.githubusercontent.com/95945681/172999272-981a0b07-2bd1-425c-b73d-f21f68922262.png)

This pull request has now been integrated.

Changeset: bbaeacb5
Author:    Harshitha Onkar <honkar at openjdk.org>
Committer: Dmitry Markov <dmarkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bbaeacb597a8acc2c88793a6231c53ea0453f4d4
Stats:     111 lines in 2 files changed: 104 ins; 3 del; 4 mod

8265586: [windows] last button is not shown in AWT Frame with BorderLayout and MenuBar set.

Reviewed-by: aivanov, dmarkov, azvegint

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

PR: https://git.openjdk.org/jdk/pull/9118


From honkar at openjdk.java.net  Wed Jun 15 00:39:40 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Wed, 15 Jun 2022 00:39:40 GMT
Subject: RFR: 8284619: javax/swing/JTable/8236907/LastVisibleRow.java
 failed with "Test Case Failed!!, Last Row not Visible!!!" [v2]
In-Reply-To: <fcFTFXGRHdOlROPmimXNGJXhBsnHvfqJWU2ED90dD1w=.f65e2061-1ecd-41d4-b41a-66736d078ab1@github.com>
References: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
 <fcFTFXGRHdOlROPmimXNGJXhBsnHvfqJWU2ED90dD1w=.f65e2061-1ecd-41d4-b41a-66736d078ab1@github.com>
Message-ID: <YAVtdGc4VbFwIS1wrCvCERwfKmGCs1sFypc_Z_mXx0s=.1b68ece0-1b65-4aec-90ee-74dfffd3f721@github.com>

On Tue, 14 Jun 2022 05:36:36 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Fix history - #7422.
>> The test is automatic and check if the last row is painted (Which was not happening before the fix, the last row appeared only after MouseClick operation) by capturing the last row before and after MouseClick Operation.If the both the captured images are same, then the test passes else it fails.
>> This Fix includes for ubuntu and macos failure, in which only the test case failed due to following reasons.
>> 
>> In ubuntu, the test fails due to unexpected dark line appearing on right side of last row before MouseClick operation.
>> In macos, the test fails since after MouseClick operation of last row, clearSelection didn't show any effect on the selected row.
>> The issue is intermittent and not able to reproduce it frequently. As a defensive fix, the rectangular area which is being captured is reduce for ubuntu failure and Delay is added between ClearSelection of focus and Image Capture for macos failure
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Marked as reviewed by honkar (Author).

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

PR: https://git.openjdk.org/jdk/pull/9117


From smandalika at openjdk.java.net  Wed Jun 15 05:13:41 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 15 Jun 2022 05:13:41 GMT
Subject: RFR: JDK-8282777: Create a Regression test for JDK-4515031 [v6]
In-Reply-To: <f7hBFNUDXcwMeTleH7PQsUE8sKq1MmTumY9FvONoFUA=.7c8b4a15-c1aa-41b8-9636-72de021c965f@github.com>
References: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
 <f7hBFNUDXcwMeTleH7PQsUE8sKq1MmTumY9FvONoFUA=.7c8b4a15-c1aa-41b8-9636-72de021c965f@github.com>
Message-ID: <gB7YfNJ9KYvZqZagoEIGs6I9k2S8M7FvsaGOUoK2cCE=.c4e6c62c-6d45-488b-909d-d5a328e3a79b@github.com>

On Fri, 3 Jun 2022 06:36:17 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a Regression test for [JDK-4515031](https://bugs.openjdk.java.net/browse/JDK-4515031)
>> 
>> The issue indicates the need for a a getAccessibleDescription being implemented for the JFileChooser.
>> The test added verifies the same.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika 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:
> 
>   Review comment fixed: removed redundant robot code.

Hi! Can someone please take a look at this PR and provide their valuable feedback ?

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

PR: https://git.openjdk.org/jdk/pull/7738


From smandalika at openjdk.java.net  Wed Jun 15 05:14:43 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 15 Jun 2022 05:14:43 GMT
Subject: RFR: 8284767: Create an automated test for JDK-4422535 [v3]
In-Reply-To: <3rXFVh7JvLK-ycYNRlmK8tTqTpmrs7GuF0lxiaO78kQ=.9f972f36-f57f-4cf1-a2d8-58feba441f71@github.com>
References: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
 <3rXFVh7JvLK-ycYNRlmK8tTqTpmrs7GuF0lxiaO78kQ=.9f972f36-f57f-4cf1-a2d8-58feba441f71@github.com>
Message-ID: <hgy-mPDW4cXddzQfZrYGVkSi4NnsFuPzPOE-XoVNog4=.3c74158d-2626-48cb-b46c-35a30ebee9d3@github.com>

On Wed, 18 May 2022 08:37:03 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422535](https://bugs.openjdk.java.net/browse/JDK-4422535)
>> AccessibleValue implementation only accept Integers
>> The AccessibleValue implementations of the following components:
>> 
>> java.awt.Scrollbar
>> javax.swing.AbstractButton
>> javax.swing.JInternalFrame
>> javax.swing.JSplitPane
>> javax.swing.JScrollBar
>> javax.swing.JProgressBar
>> javax.swing.JSlider
>> 
>> require the argument to setCurrentAccessibleValue(Number) to be an Integer, else they completely ignore it - it returns a false indicating that the value has not been set by the return value, but they cannot know the reason for that).
>> 
>> The test verifies that for each of the above components, the AccessibleValue is set when it is set to a Number (Float, Double, long etc) and not just for an Integer.
>> 
>> his review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: Fixed File location path.

Hi! Can someone please take a look at this PR and provide their valuable feedback and approval ?

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

PR: https://git.openjdk.org/jdk/pull/8220


From smandalika at openjdk.java.net  Wed Jun 15 05:14:45 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 15 Jun 2022 05:14:45 GMT
Subject: RFR: 8284524: Create an automated test for JDK-4422362 [v3]
In-Reply-To: <ASMCKuK4Ur54E_sI13yc-5J9BZlH8thmHe5a8fWwxYI=.6160ccaf-36b9-4838-bb6a-a845840fc5d8@github.com>
References: <Zc6TLIeUCxotLqICjVkZF4g1hUTkdB7mANhMull6Qzc=.14959182-424c-42f6-979f-7d6eeb266dfb@github.com>
 <ASMCKuK4Ur54E_sI13yc-5J9BZlH8thmHe5a8fWwxYI=.6160ccaf-36b9-4838-bb6a-a845840fc5d8@github.com>
Message-ID: <HvI2WSV8ut5JF-sN8eQVvYx9V65eMlf6MQKu1I0ayUM=.8ecea8ae-ff17-4700-a1b0-5e56ccbf18d4@github.com>

On Wed, 18 May 2022 08:38:49 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422362](https://bugs.openjdk.java.net/browse/JDK-4422362)
>> 
>> The BoundedRangeModel components (JScrollBar, JSlider, JProgressBar) return
>> BoundedRangeModel.getMaximum() from getMaximumAccessibleValue() in their
>> AccessibleValue implementation.
>> The real maximum value (due to the constraints on BoundedRangeModel) is
>> model.getMaximum() - model.getExtent().
>> 
>> The test verifies that the above is adhered to as expected.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: Fixed File location path.

Hi! Can someone please take a look at this PR and provide their valuable feedback ?

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

PR: https://git.openjdk.org/jdk/pull/8158


From smandalika at openjdk.java.net  Wed Jun 15 05:14:56 2022
From: smandalika at openjdk.java.net (Srinivas Mandalika)
Date: Wed, 15 Jun 2022 05:14:56 GMT
Subject: RFR: 8286172: Create an automated test for JDK-4516019 [v4]
In-Reply-To: <qszRSkeqzMN-7mAWy2OTGqRBHjrsDgKMMIjlQkcDR80=.f13c6c67-ea7e-4e6d-b08a-6112b6404fa4@github.com>
References: <lAQZthlNPKA2vOejKdfEJ5aLiEfifijBS8l-Y_BT3_o=.fb0d426a-c040-4647-a0f3-df848784217c@github.com>
 <qszRSkeqzMN-7mAWy2OTGqRBHjrsDgKMMIjlQkcDR80=.f13c6c67-ea7e-4e6d-b08a-6112b6404fa4@github.com>
Message-ID: <Dse46QmmC7rZg25js41ZQwJ768rstj5hDCxT81_xsjQ=.d33dcd71-5099-4d30-ad39-b9d81d7a50d7@github.com>

On Thu, 9 Jun 2022 07:32:29 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4516019](https://bugs.openjdk.java.net/browse/JDK-4516019)
>> 
>> Clicking on the increment/decrement buttons of the spinner does not install focus on the spinner or one of its focusable children.
>> 
>> The test validates the same.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: replaced sleep with robot.waitForIdle

Hi! Can someone please take a look at this PR and provide their valuable feedback and approval?

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

PR: https://git.openjdk.org/jdk/pull/8546


From serb at openjdk.java.net  Wed Jun 15 05:39:44 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 15 Jun 2022 05:39:44 GMT
Subject: RFR: 8265586: [windows] last button is not shown in AWT Frame with
 BorderLayout and MenuBar set. [v3]
In-Reply-To: <1fTMFRhq0ez161rADVVkXu_gyEr_gh_AeE17afFPE2Q=.19d7a1d0-d3fd-4dee-bee6-f8e4c07e0651@github.com>
References: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
 <1fTMFRhq0ez161rADVVkXu_gyEr_gh_AeE17afFPE2Q=.19d7a1d0-d3fd-4dee-bee6-f8e4c07e0651@github.com>
Message-ID: <bBQAPmU1302HS351T6fqTeiCOFxLlKEObIg932u-nXU=.e03a4aa9-60ff-4399-a248-9038e8dbd41a@github.com>

On Mon, 13 Jun 2022 21:24:09 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Due to incorrect AWT Frame inset values being returned from native code, few of the components in the frame were not being shown completely on Windows. With the proposed fix, correct insets are obtained which in turn sizes and displays the frame correctly.
>> 
>> The default insets obtained from the Win system was adding only `::GetSystemMetrics(SM_CXSIZEFRAME)` for **WS_THICKFRAME** and the insets were off by few pixels from the expected value. `::GetSystemMetrics(SM_CXPADDEDBORDER)` is additionally added to top, bottom, left and right insets to account for the 6px. [GetSystemMetric() Document](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics)
>> 
>> A test case is added which checks if the actual frame size is equal to the expected frame size (frame.getSize() == frame.getPreferredSize()), thus checking if frame.pack() works as expected.
>> 
>> Following are before and after screenshots - 
>> ![image](https://user-images.githubusercontent.com/95945681/172999272-981a0b07-2bd1-425c-b73d-f21f68922262.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor changes

test/jdk/java/awt/Frame/AwtFramePackTest.java line 42:

> 40:  * @bug 8265586
> 41:  * @key headful
> 42:  * @requires (os.family == "windows")

Any reason why the test is windows specific? It does not have the platform specific code.

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

PR: https://git.openjdk.org/jdk/pull/9118


From aturbanov at openjdk.java.net  Wed Jun 15 07:31:56 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 15 Jun 2022 07:31:56 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v6]
In-Reply-To: <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
Message-ID: <L49ntFdH5g3YCosPSB16px9r0Mm3vuohTKBPgD03e_I=.7376119e-5c11-4c20-b2f3-cfc68ce89145@github.com>

On Fri, 13 May 2022 16:53:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision:
> 
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/40c585cd...98e635a5

src/java.desktop/share/classes/javax/swing/JTree.java line 3320:

> 3318:                                    (parent, path.getPathComponent(counter));
> 3319:                 parent = path.getPathComponent(counter);
> 3320:                 if(indices[counter - 1] < 0)

let's add space after `if`

src/java.desktop/share/classes/javax/swing/JTree.java line 3335:

> 3333:      */
> 3334:     private TreePath getPathForIndexs(int[] indices) {
> 3335:         if(indices == null)

please add space after `if`

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

PR: https://git.openjdk.org/jdk/pull/8328


From aivanov at openjdk.java.net  Wed Jun 15 10:12:46 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 15 Jun 2022 10:12:46 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v6]
In-Reply-To: <L49ntFdH5g3YCosPSB16px9r0Mm3vuohTKBPgD03e_I=.7376119e-5c11-4c20-b2f3-cfc68ce89145@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
 <L49ntFdH5g3YCosPSB16px9r0Mm3vuohTKBPgD03e_I=.7376119e-5c11-4c20-b2f3-cfc68ce89145@github.com>
Message-ID: <sid_RqGy2RIBuCmDj16ulAx0yTijUAtGwkySwLqgrC4=.45e0fb64-9d3c-4b61-b28e-3e826705f05c@github.com>

On Wed, 15 Jun 2022 07:27:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision:
>> 
>>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/40c585cd...98e635a5
>
> src/java.desktop/share/classes/javax/swing/JTree.java line 3320:
> 
>> 3318:                                    (parent, path.getPathComponent(counter));
>> 3319:                 parent = path.getPathComponent(counter);
>> 3320:                 if(indices[counter - 1] < 0)
> 
> let's add space after `if`

Better not: if you look at the code around it, there's no space between a keyword and the opening parenthesis. So the code looks consistent. Changing this `if` will make the code inconsistent.

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

PR: https://git.openjdk.org/jdk/pull/8328


From ihse at openjdk.java.net  Wed Jun 15 10:45:52 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 15 Jun 2022 10:45:52 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v6]
In-Reply-To: <L49ntFdH5g3YCosPSB16px9r0Mm3vuohTKBPgD03e_I=.7376119e-5c11-4c20-b2f3-cfc68ce89145@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
 <L49ntFdH5g3YCosPSB16px9r0Mm3vuohTKBPgD03e_I=.7376119e-5c11-4c20-b2f3-cfc68ce89145@github.com>
Message-ID: <E83YFbh2P18w84gm2LQAy5umVsaFq-O11pRGOcRnnms=.29da439d-c489-4f10-ac2e-3635540783d0@github.com>

On Wed, 15 Jun 2022 07:27:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision:
>> 
>>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/40c585cd...98e635a5
>
> src/java.desktop/share/classes/javax/swing/JTree.java line 3320:
> 
>> 3318:                                    (parent, path.getPathComponent(counter));
>> 3319:                 parent = path.getPathComponent(counter);
>> 3320:                 if(indices[counter - 1] < 0)
> 
> let's add space after `if`

@turbanoff I'll go with @aivanov-jdk's suggestion here. Also, this is a PR created by an automation tool. I'd really prefer not to do any manual intervention, if possible, and at the very least not spelling related.

> src/java.desktop/share/classes/javax/swing/JTree.java line 3335:
> 
>> 3333:      */
>> 3334:     private TreePath getPathForIndexs(int[] indices) {
>> 3335:         if(indices == null)
> 
> please add space after `if`

Same here. Space issues are not typos.

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

PR: https://git.openjdk.org/jdk/pull/8328


From honkar at openjdk.java.net  Wed Jun 15 15:52:12 2022
From: honkar at openjdk.java.net (Harshitha Onkar)
Date: Wed, 15 Jun 2022 15:52:12 GMT
Subject: RFR: 8265586: [windows] last button is not shown in AWT Frame with
 BorderLayout and MenuBar set. [v3]
In-Reply-To: <bBQAPmU1302HS351T6fqTeiCOFxLlKEObIg932u-nXU=.e03a4aa9-60ff-4399-a248-9038e8dbd41a@github.com>
References: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
 <1fTMFRhq0ez161rADVVkXu_gyEr_gh_AeE17afFPE2Q=.19d7a1d0-d3fd-4dee-bee6-f8e4c07e0651@github.com>
 <bBQAPmU1302HS351T6fqTeiCOFxLlKEObIg932u-nXU=.e03a4aa9-60ff-4399-a248-9038e8dbd41a@github.com>
Message-ID: <NTq-AAiYlsQoKJyrQRgnZ79qqacMuddpe0oj26qQAnY=.7875d7c1-aa1a-4382-bec1-8c00614f4f9a@github.com>

On Wed, 15 Jun 2022 05:37:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor changes
>
> test/jdk/java/awt/Frame/AwtFramePackTest.java line 42:
> 
>> 40:  * @bug 8265586
>> 41:  * @key headful
>> 42:  * @requires (os.family == "windows")
> 
> Any reason why the test is windows specific? It does not have the platform specific code.

@mrserb I wanted to clarify if you meant - Though the fix is windows specific, the condition used in test case frame.getSize() == frame.getPreferredSize() should hold on all platforms and the test case can be made generic?

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

PR: https://git.openjdk.org/jdk/pull/9118


From dnguyen at openjdk.java.net  Wed Jun 15 17:27:53 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Wed, 15 Jun 2022 17:27:53 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v14]
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <7xT1SjSu9emN2LKYuIbMXI1ZBeKmGbTKdMhDi2w_dZk=.3cb8860e-373c-4ad7-a96c-d5b7c647157e@github.com>

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Moved doc change.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/7446/files
  - new: https://git.openjdk.org/jdk/pull/7446/files/4ddb26d7..fb05671e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7446&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7446&range=12-13

  Stats: 21 lines in 2 files changed: 10 ins; 11 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/7446.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7446/head:pull/7446

PR: https://git.openjdk.org/jdk/pull/7446


From dnguyen at openjdk.java.net  Wed Jun 15 17:32:25 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Wed, 15 Jun 2022 17:32:25 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v13]
In-Reply-To: <ln_b2SiKrHn4f4nD3Jxam1twqB-dL48gESfcp5QQYAE=.dc8919be-7614-468d-bbab-a1b32cd63b46@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <fl4LtVyoXfiaQhLY3FMnaO1HtS35ZIfbKAhYNGLSQus=.74efb62e-1158-4004-8823-ba98663f1b86@github.com>
 <ln_b2SiKrHn4f4nD3Jxam1twqB-dL48gESfcp5QQYAE=.dc8919be-7614-468d-bbab-a1b32cd63b46@github.com>
Message-ID: <KIYZImAezsPGrmvMrPwU1wTA8IV3VkTa46jS7Mt_tRw=.b93c38e0-e438-49a2-ae45-548e0065801a@github.com>

On Mon, 13 Jun 2022 07:37:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Probably we should mark this new block of text as implementation details or notes or something? Or will we consider it part of the spec against which the new tck tests be created?

I can add the implementation notes tag if needed. I moved the additional doc text to HTMLEditorKit.HTMLFactory since it makes more sense to have this information in the editor and HTMLFactory builds the views that display this behavior. It looks like the implNote tag doesn't really seem to fit since I see it used in places where param or return tags are also used, and the place I inserted the javadoc text into lacks this. So, I'm leaving it out to maintain the overall format.

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

PR: https://git.openjdk.org/jdk/pull/7446


From aivanov at openjdk.java.net  Wed Jun 15 18:19:08 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 15 Jun 2022 18:19:08 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v14]
In-Reply-To: <7xT1SjSu9emN2LKYuIbMXI1ZBeKmGbTKdMhDi2w_dZk=.3cb8860e-373c-4ad7-a96c-d5b7c647157e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <7xT1SjSu9emN2LKYuIbMXI1ZBeKmGbTKdMhDi2w_dZk=.3cb8860e-373c-4ad7-a96c-d5b7c647157e@github.com>
Message-ID: <_T9FZGtt3TXcOlnlVBbQQxPd7snHAhrFVaJjiUWE1cQ=.462bf188-d203-4937-8904-48dce51b6bde@github.com>

On Wed, 15 Jun 2022 17:27:53 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved doc change.

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 28:

> 26: package javax.swing.text.html;
> 27: 
> 28: import sun.awt.AppContext;

In JDK code, internal classes are listed below public `java.*` and `javax.*` packages. The order was correct.

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1184:

> 1182:      * table describes what this factory will build by
> 1183:      * default.
> 1184:      * <p>

I'd rather move this block below the table. The sentence above introduces the table, then it lists how the common HTML tags are handled. This added paragraph describes how unsupported and unknown tags are handled.

Does it make sense to use lists?

* When the container is editable, ?
* When the container is not editable,
  * If tag is recognized but not supported, ?
  * If tag is unknown or not supported, ?

Or simply split the two cases in different paragraphs for better readability?

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

PR: https://git.openjdk.org/jdk/pull/7446


From prr at openjdk.java.net  Wed Jun 15 18:24:18 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 15 Jun 2022 18:24:18 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v14]
In-Reply-To: <7xT1SjSu9emN2LKYuIbMXI1ZBeKmGbTKdMhDi2w_dZk=.3cb8860e-373c-4ad7-a96c-d5b7c647157e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <7xT1SjSu9emN2LKYuIbMXI1ZBeKmGbTKdMhDi2w_dZk=.3cb8860e-373c-4ad7-a96c-d5b7c647157e@github.com>
Message-ID: <sXxir7S7GKI08-CvDULCfxM4JNk1JT41sDZKYTODlrw=.403419d4-e2c7-402b-b746-ab39fdb2532f@github.com>

On Wed, 15 Jun 2022 17:27:53 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved doc change.

Changes requested by prr (Reviewer).

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1184:

> 1182:      * table describes what this factory will build by
> 1183:      * default.
> 1184:      * <p>

I think it fine to add @implNote right here.

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1188:

> 1186:      * When the container using HTML tags is editable, all non-supported tags
> 1187:      * will be displayed as editable text fields in place of the tags. The contents
> 1188:      * within the tags will be handled by the editor as regular text.

new paragraph - to force a new line here

and "full support" what does that mean ?

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1190:

> 1188:      * within the tags will be handled by the editor as regular text.
> 1189:      * If the container is not editable and a tag is recognized but not supported,
> 1190:      * such as script tags, the tag and its contents will be hidden.

another nl here I think. This is almost like a list, but the main point is it is easier to read the conditions when there's a line break. Remember your formatting doesn't get carried over into the published javadoc

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1192:

> 1190:      * such as script tags, the tag and its contents will be hidden.
> 1191:      * If the container is not editable and a tag is unknown or not supported at
> 1192:      * all, the tags will be hidden but its contents will display as regular text.

"unknown or not supported at all" ?
unknown tags are surely always unsupported so why do we need to say that here ?

With all the above it ends up something like 
     * @implNote
     * Parsed tags that are unrecognized or are recognized but unsupported are handled differently by the editor.
     * <ul>
     * <li> When the container using HTML tags is editable, all such tags
     * The contents will be displayed as editable text fields in place of the tags.
     * The content within the tags will be handled by the editor as regular text.
     * <li> If the container is not editable and a tag is recognized but not supported,
     * such as script tags, the tag and its contents will be hidden.
     * <li> If the container is not editable and a tag is unknown
     * the tag will be hidden but its contents will display as regular text.
      *</ul>
     * <p>
     * <p>

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

PR: https://git.openjdk.org/jdk/pull/7446


From dnguyen at openjdk.java.net  Wed Jun 15 18:30:19 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Wed, 15 Jun 2022 18:30:19 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v15]
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <QaZR1cHuILnfEv2rTKjOoXsv_JwRHuPcnBfbDWnFLKQ=.3a39e85f-805b-473b-a68e-d606c36114ca@github.com>

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Reverted imports.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/7446/files
  - new: https://git.openjdk.org/jdk/pull/7446/files/fb05671e..bf774910

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7446&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7446&range=13-14

  Stats: 15 lines in 1 file changed: 7 ins; 8 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/7446.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7446/head:pull/7446

PR: https://git.openjdk.org/jdk/pull/7446


From prr at openjdk.java.net  Wed Jun 15 18:30:21 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 15 Jun 2022 18:30:21 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v14]
In-Reply-To: <7xT1SjSu9emN2LKYuIbMXI1ZBeKmGbTKdMhDi2w_dZk=.3cb8860e-373c-4ad7-a96c-d5b7c647157e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <7xT1SjSu9emN2LKYuIbMXI1ZBeKmGbTKdMhDi2w_dZk=.3cb8860e-373c-4ad7-a96c-d5b7c647157e@github.com>
Message-ID: <T-g9Qv85mBDFkySVcY7RYrsEaVfSH5jUvqDYmlZOq2Y=.dd321e4d-027e-4eeb-9479-cff26345f8ba@github.com>

On Wed, 15 Jun 2022 17:27:53 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved doc change.

src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java line 28:

> 26: package javax.swing.text.html.parser;
> 27: 
> 28: import java.io.CharArrayReader;

We can revert all changes to this file now.

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

PR: https://git.openjdk.org/jdk/pull/7446


From dnguyen at openjdk.java.net  Wed Jun 15 18:30:22 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Wed, 15 Jun 2022 18:30:22 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v14]
In-Reply-To: <T-g9Qv85mBDFkySVcY7RYrsEaVfSH5jUvqDYmlZOq2Y=.dd321e4d-027e-4eeb-9479-cff26345f8ba@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <7xT1SjSu9emN2LKYuIbMXI1ZBeKmGbTKdMhDi2w_dZk=.3cb8860e-373c-4ad7-a96c-d5b7c647157e@github.com>
 <T-g9Qv85mBDFkySVcY7RYrsEaVfSH5jUvqDYmlZOq2Y=.dd321e4d-027e-4eeb-9479-cff26345f8ba@github.com>
Message-ID: <MFkuNJuw9e1Z9JYhAqW6gk0G49uWAdh19yZDOqDKGxc=.a0f52162-d331-43c8-b670-7ce4fa790e47@github.com>

On Wed, 15 Jun 2022 18:21:12 GMT, Phil Race <prr at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved doc change.
>
> src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java line 28:
> 
>> 26: package javax.swing.text.html.parser;
>> 27: 
>> 28: import java.io.CharArrayReader;
> 
> We can revert all changes to this file now.

Thanks for catching that. Reverted

-------------

PR: https://git.openjdk.org/jdk/pull/7446


From serb at openjdk.java.net  Thu Jun 16 03:33:02 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 16 Jun 2022 03:33:02 GMT
Subject: RFR: 8272998: ImageIO.read() throws incorrect exception type
In-Reply-To: <7P_RTUjGWttc7Wpknqa7CCPgNIssyX4xT--MjQ_R5po=.be6078e7-bb89-4b23-9b55-6d8fe93c70f6@github.com>
References: <7P_RTUjGWttc7Wpknqa7CCPgNIssyX4xT--MjQ_R5po=.be6078e7-bb89-4b23-9b55-6d8fe93c70f6@github.com>
Message-ID: <RCPQz7Uzpx-rTJqjcp4o0GsahxabKIw1-_VRO6NvLe0=.b6c6b8cf-b324-473a-b102-beb1e4ee6223@github.com>

On Thu, 9 Jun 2022 19:53:22 GMT, Phil Race <prr at openjdk.org> wrote:

> ImageIO.read() only documents IOException for any kind of decoding problem and since
> it is a convenience API we don't want to start requiring applications to handle other RuntimeExceptions.
> So in the unlikely case of some problem decoding using this API, wrap any RuntimeException in
> an IIOException. This will give more stable app behaviour and still report the underlying problem.

src/java.desktop/share/classes/javax/imageio/ImageIO.java line 1467:

> 1465:         try (stream) {
> 1466:             bi = reader.read(0, param);
> 1467:         } catch (RuntimeException e) {

Is that necessary to catch all possible runtime exceptions? Probably we should catch only the exceptions thrown by the read method? I think it should be "IllegalArgumentException" only, the IllegalStateException/IndexOutOfBoundsException should not be thrown here, and the IOException is fine.

-------------

PR: https://git.openjdk.org/jdk/pull/9113


From serb at openjdk.java.net  Thu Jun 16 03:38:08 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 16 Jun 2022 03:38:08 GMT
Subject: RFR: JDK-8282777: Create a Regression test for JDK-4515031 [v6]
In-Reply-To: <f7hBFNUDXcwMeTleH7PQsUE8sKq1MmTumY9FvONoFUA=.7c8b4a15-c1aa-41b8-9636-72de021c965f@github.com>
References: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
 <f7hBFNUDXcwMeTleH7PQsUE8sKq1MmTumY9FvONoFUA=.7c8b4a15-c1aa-41b8-9636-72de021c965f@github.com>
Message-ID: <3qHHIn5ND3OVbNuEElMZP1D6ezcp65ES-yFuZ8QgSeQ=.feb8f1ee-33c4-4ab7-868c-c8da2df592ad@github.com>

On Fri, 3 Jun 2022 06:36:17 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create a Regression test for [JDK-4515031](https://bugs.openjdk.java.net/browse/JDK-4515031)
>> 
>> The issue indicates the need for a a getAccessibleDescription being implemented for the JFileChooser.
>> The test added verifies the same.
>> This review is for migrating tests from a closed test suite to open.
>
> Srinivas Mandalika 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:
> 
>   Review comment fixed: removed redundant robot code.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/7738


From serb at openjdk.java.net  Thu Jun 16 03:40:11 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 16 Jun 2022 03:40:11 GMT
Subject: RFR: 8284524: Create an automated test for JDK-4422362 [v3]
In-Reply-To: <ASMCKuK4Ur54E_sI13yc-5J9BZlH8thmHe5a8fWwxYI=.6160ccaf-36b9-4838-bb6a-a845840fc5d8@github.com>
References: <Zc6TLIeUCxotLqICjVkZF4g1hUTkdB7mANhMull6Qzc=.14959182-424c-42f6-979f-7d6eeb266dfb@github.com>
 <ASMCKuK4Ur54E_sI13yc-5J9BZlH8thmHe5a8fWwxYI=.6160ccaf-36b9-4838-bb6a-a845840fc5d8@github.com>
Message-ID: <NhnYtGGuSQvk6NX7XfRdHOAGpIG4z2E4oP8hAe3AK8I=.26b4cb7d-3af8-4ee5-9423-5674dff234de@github.com>

On Wed, 18 May 2022 08:38:49 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422362](https://bugs.openjdk.java.net/browse/JDK-4422362)
>> 
>> The BoundedRangeModel components (JScrollBar, JSlider, JProgressBar) return
>> BoundedRangeModel.getMaximum() from getMaximumAccessibleValue() in their
>> AccessibleValue implementation.
>> The real maximum value (due to the constraints on BoundedRangeModel) is
>> model.getMaximum() - model.getExtent().
>> 
>> The test verifies that the above is adhered to as expected.
>> 
>> This review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: Fixed File location path.

test/jdk/javax/accessibility/MaximumAccessibleValueTest.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @key headful

I think the headful tag is not needed in this test, please check.

-------------

PR: https://git.openjdk.org/jdk/pull/8158


From serb at openjdk.java.net  Thu Jun 16 03:43:07 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 16 Jun 2022 03:43:07 GMT
Subject: RFR: 8284767: Create an automated test for JDK-4422535 [v3]
In-Reply-To: <3rXFVh7JvLK-ycYNRlmK8tTqTpmrs7GuF0lxiaO78kQ=.9f972f36-f57f-4cf1-a2d8-58feba441f71@github.com>
References: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
 <3rXFVh7JvLK-ycYNRlmK8tTqTpmrs7GuF0lxiaO78kQ=.9f972f36-f57f-4cf1-a2d8-58feba441f71@github.com>
Message-ID: <1aHb4tDmlGR37mVahrlvOIgaW3aCDKSYDd5JSEnx3T4=.6c7014c3-340a-4364-9bda-78c32c55ec9d@github.com>

On Wed, 18 May 2022 08:37:03 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Create an automated test for [JDK-4422535](https://bugs.openjdk.java.net/browse/JDK-4422535)
>> AccessibleValue implementation only accept Integers
>> The AccessibleValue implementations of the following components:
>> 
>> java.awt.Scrollbar
>> javax.swing.AbstractButton
>> javax.swing.JInternalFrame
>> javax.swing.JSplitPane
>> javax.swing.JScrollBar
>> javax.swing.JProgressBar
>> javax.swing.JSlider
>> 
>> require the argument to setCurrentAccessibleValue(Number) to be an Integer, else they completely ignore it - it returns a false indicating that the value has not been set by the return value, but they cannot know the reason for that).
>> 
>> The test verifies that for each of the above components, the AccessibleValue is set when it is set to a Number (Float, Double, long etc) and not just for an Integer.
>> 
>> his review is for migrating tests from a closed test suite to open.
>> 
>> Testing:
>> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Comments Fixed: Fixed File location path.

test/jdk/javax/accessibility/SetCurrentAccessibleValueTest.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @key headful

Do we need a headful tag here?

-------------

PR: https://git.openjdk.org/jdk/pull/8220


From tr at openjdk.java.net  Thu Jun 16 03:50:24 2022
From: tr at openjdk.java.net (Tejesh R)
Date: Thu, 16 Jun 2022 03:50:24 GMT
Subject: Integrated: 8284619: javax/swing/JTable/8236907/LastVisibleRow.java
 failed with "Test Case Failed!!, Last Row not Visible!!!"
In-Reply-To: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
References: <EXYkRcOFbWzTKHfQj4E3QuA12dvyjvfVAoGsDilivMg=.97e33e53-7e50-40b0-a5d7-744430f47cc4@github.com>
Message-ID: <J7OmI-luyW-FYND4v8k8C_Y2nCqYBi-erDi6wTHSZqg=.9ab70f12-1025-401e-9df2-deca243904f7@github.com>

On Fri, 10 Jun 2022 05:35:22 GMT, Tejesh R <tr at openjdk.org> wrote:

> Fix history - #7422.
> The test is automatic and check if the last row is painted (Which was not happening before the fix, the last row appeared only after MouseClick operation) by capturing the last row before and after MouseClick Operation.If the both the captured images are same, then the test passes else it fails.
> This Fix includes for ubuntu and macos failure, in which only the test case failed due to following reasons.
> 
> In ubuntu, the test fails due to unexpected dark line appearing on right side of last row before MouseClick operation.
> In macos, the test fails since after MouseClick operation of last row, clearSelection didn't show any effect on the selected row.
> The issue is intermittent and not able to reproduce it frequently. As a defensive fix, the rectangular area which is being captured is reduce for ubuntu failure and Delay is added between ClearSelection of focus and Image Capture for macos failure

This pull request has now been integrated.

Changeset: 39526e28
Author:    Tejesh R <tr at openjdk.org>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/39526e28bc4b82d22623a839362fd443e9fb11f0
Stats:     61 lines in 2 files changed: 9 ins; 39 del; 13 mod

8284619: javax/swing/JTable/8236907/LastVisibleRow.java failed with "Test Case Failed!!, Last Row not Visible!!!"

Reviewed-by: psadhukhan, honkar

-------------

PR: https://git.openjdk.org/jdk/pull/9117


From serb at openjdk.java.net  Thu Jun 16 04:01:12 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 16 Jun 2022 04:01:12 GMT
Subject: RFR: 8284672: Collapse identical catch branches in java.desktop
 [v2]
In-Reply-To: <TLLG7XM4wV1Q7douly657vwd36dod5qUFMICnl7wpJc=.982c2ba7-cfed-43cb-a68d-4077b07bf4f7@github.com>
References: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
 <TLLG7XM4wV1Q7douly657vwd36dod5qUFMICnl7wpJc=.982c2ba7-cfed-43cb-a68d-4077b07bf4f7@github.com>
Message-ID: <vcQO9naoHJ0HBmxS2bn8rSni0VWR8avPDSibJHtJ9KU=.4edcb92d-65f5-4090-8619-d01ebff6696a@github.com>

On Wed, 1 Jun 2022 20:55:30 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types".
>> It simplifies code. Reduces duplication.
>> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284672: Collapse identical catch branches in java.desktop
>   fix formatting

src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java line 120:

> 118:             try {
> 119:                 INSTANCE = new Metacity(themeName);
> 120:             } catch (FileNotFoundException ex) {

Is it possible that the FileNotFoundException was ignored intentionally? After this change, it will be traced.

-------------

PR: https://git.openjdk.org/jdk/pull/8154


From serb at openjdk.java.net  Thu Jun 16 04:01:15 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 16 Jun 2022 04:01:15 GMT
Subject: RFR: 8284672: Collapse identical catch branches in java.desktop
 [v2]
In-Reply-To: <Qhm51ibMOoE-vKp1zECWtwEQhExJ5jQOQxtI1aEn6sA=.fa1de9e0-b7ce-4b05-ad49-38f036a6bbb0@github.com>
References: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
 <sHkXMpkUXAG5rkkJnednTmISoY4Li2RNOFQcf6zytQ8=.1afdaf08-c759-4ef7-b11c-b63b3d983e04@github.com>
 <Qhm51ibMOoE-vKp1zECWtwEQhExJ5jQOQxtI1aEn6sA=.fa1de9e0-b7ce-4b05-ad49-38f036a6bbb0@github.com>
Message-ID: <83f5TNNzytdB_O-gAmeG1o57YtzyN_uVBxqwl4P63mc=.1750e7f0-71a7-46e1-8bf4-f2ca63bd956d@github.com>

On Wed, 1 Jun 2022 20:50:42 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/media/sound/SF2SoundbankReader.java line 50:
>> 
>>> 48:         try {
>>> 49:             return new SF2Soundbank(url);
>>> 50:         } catch (IOException e) {
>> 
>> same here
>
> Yeah. I think it makes sense to amend behavior here and not catch IOException. Callers should be ready for it.

This getSoundbank method is called when we iterate over providers and check which can be used, unfortunately, that code is not ready for the IOException and we return "null" -> the next provider will be checked. This is a kind of compatibility quirk.

-------------

PR: https://git.openjdk.org/jdk/pull/8154


From dnguyen at openjdk.java.net  Thu Jun 16 07:59:08 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Thu, 16 Jun 2022 07:59:08 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v16]
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <p9AL6RYYTvTDxbQXitofuI3MT-LwfPOum6fEvhrb2ic=.1aad6703-6d8b-4c7c-86e6-b5deb4fe5530@github.com>

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Added list format to javadoc and moved to under table. Fixed auto import.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7446/files
  - new: https://git.openjdk.org/jdk/pull/7446/files/bf774910..b7a7ac88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7446&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7446&range=14-15

  Stats: 33 lines in 1 file changed: 23 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/7446.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7446/head:pull/7446

PR: https://git.openjdk.org/jdk/pull/7446


From dnguyen at openjdk.java.net  Thu Jun 16 07:59:13 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Thu, 16 Jun 2022 07:59:13 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v14]
In-Reply-To: <_T9FZGtt3TXcOlnlVBbQQxPd7snHAhrFVaJjiUWE1cQ=.462bf188-d203-4937-8904-48dce51b6bde@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <7xT1SjSu9emN2LKYuIbMXI1ZBeKmGbTKdMhDi2w_dZk=.3cb8860e-373c-4ad7-a96c-d5b7c647157e@github.com>
 <_T9FZGtt3TXcOlnlVBbQQxPd7snHAhrFVaJjiUWE1cQ=.462bf188-d203-4937-8904-48dce51b6bde@github.com>
Message-ID: <oSE6A0PKvwPRUUTzswQeigaHpE6Cr0FLUNkFJdVrcYM=.93e75d08-ee49-43fa-9064-dc37b8a33885@github.com>

On Wed, 15 Jun 2022 18:04:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved doc change.
>
> src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 28:
> 
>> 26: package javax.swing.text.html;
>> 27: 
>> 28: import sun.awt.AppContext;
> 
> In JDK code, internal classes are listed below public `java.*` and `javax.*` packages. The order was correct.

Thanks, I fixed this in my IntelliJ auto import settings.

> src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1184:
> 
>> 1182:      * table describes what this factory will build by
>> 1183:      * default.
>> 1184:      * <p>
> 
> I'd rather move this block below the table. The sentence above introduces the table, then it lists how the common HTML tags are handled. This added paragraph describes how unsupported and unknown tags are handled.
> 
> Does it make sense to use lists?
> 
> * When the container is editable, ?
> * When the container is not editable,
>   * If tag is recognized but not supported, ?
>   * If tag is unknown or not supported, ?
> 
> Or simply split the two cases in different paragraphs for better readability?

I added the list formatting for better readability.

-------------

PR: https://git.openjdk.org/jdk/pull/7446


From dnguyen at openjdk.java.net  Thu Jun 16 07:59:16 2022
From: dnguyen at openjdk.java.net (Damon Nguyen)
Date: Thu, 16 Jun 2022 07:59:16 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v14]
In-Reply-To: <sXxir7S7GKI08-CvDULCfxM4JNk1JT41sDZKYTODlrw=.403419d4-e2c7-402b-b746-ab39fdb2532f@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <7xT1SjSu9emN2LKYuIbMXI1ZBeKmGbTKdMhDi2w_dZk=.3cb8860e-373c-4ad7-a96c-d5b7c647157e@github.com>
 <sXxir7S7GKI08-CvDULCfxM4JNk1JT41sDZKYTODlrw=.403419d4-e2c7-402b-b746-ab39fdb2532f@github.com>
Message-ID: <cjRi7JGCl_b5brvN7riglKrXEfnXeQcS3kHMSqEDf1Y=.2c9bf107-076b-493a-b416-e93f71c1f48e@github.com>

On Wed, 15 Jun 2022 18:19:54 GMT, Phil Race <prr at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved doc change.
>
> src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1192:
> 
>> 1190:      * such as script tags, the tag and its contents will be hidden.
>> 1191:      * If the container is not editable and a tag is unknown or not supported at
>> 1192:      * all, the tags will be hidden but its contents will display as regular text.
> 
> "unknown or not supported at all" ?
> unknown tags are surely always unsupported so why do we need to say that here ?
> 
> With all the above it ends up something like 
>      * @implNote
>      * Parsed tags that are unrecognized or are recognized but unsupported are handled differently by the editor.
>      * <ul>
>      * <li> When the container using HTML tags is editable, all such tags
>      * The contents will be displayed as editable text fields in place of the tags.
>      * The content within the tags will be handled by the editor as regular text.
>      * <li> If the container is not editable and a tag is recognized but not supported,
>      * such as script tags, the tag and its contents will be hidden.
>      * <li> If the container is not editable and a tag is unknown
>      * the tag will be hidden but its contents will display as regular text.
>       *</ul>
>      * <p>
>      * <p>

I took @aivanov-jdk and your advice and reformatted the text into list formatting. I reworded some statements to better differentiate tag text vs contents within the tags. I hope it's clear, but let me know if there is still anything unclear.

-------------

PR: https://git.openjdk.org/jdk/pull/7446


From mkartashev at openjdk.org  Thu Jun 16 11:40:06 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Thu, 16 Jun 2022 11:40:06 GMT
Subject: RFR: 8288567: [macOS] NPE at
 sun.lwawt.macosx.CPlatformComponent.setBounds
Message-ID: <4OLkCQnPTmf6P-Iie09lahfeBynpAC0b2kfPU_vyW7g=.a6d729a3-2ae8-4050-94e0-d0e0559fdd70@github.com>

Even though I have not been able to reproduce the crash by hand, the problem and the fix are fairly obvious: 
`CWarningWindow` doesn't have a peer, so `platformWindow.getPeer()` can be null in that case. The fix is to accomodate for that in `CPlatformComponent.setBounds()`. Similar provisions exist elsewhere in the vicinity (for ex. `CPlatformLWWindow.setBounds()`, `CPlatformWindow.maximize()`, etc).

-------------

Commit messages:
 - 8288567: [macOS] NPE at sun.lwawt.macosx.CPlatformComponent.setBounds

Changes: https://git.openjdk.org/jdk/pull/9184/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9184&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288567
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9184.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9184/head:pull/9184

PR: https://git.openjdk.org/jdk/pull/9184


From asotona at openjdk.org  Thu Jun 16 13:59:07 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Jun 2022 13:59:07 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v11]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <E4j45zg2e_METAHDCb8VB7vBVN3OBZMV9r7kuSY_Ud0=.80634e26-7c57-40c3-b424-104af94c2591@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - Merge branch 'openjdk:master' into JDK-8244681
 - ... and 5 more: https://git.openjdk.org/jdk/compare/cf4a4966...3314423d

-------------

Changes: https://git.openjdk.org/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=10
  Stats: 442 lines in 17 files changed: 440 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.org/jdk/pull/8599


From mvs at openjdk.org  Thu Jun 16 15:10:29 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Thu, 16 Jun 2022 15:10:29 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is unstable in
 MacOS machines
Message-ID: <pClI2zW5gi4TBiMW2CeftBlBN_p5Z7KWF4fpeVZqtlg=.e332bcae-1242-4227-8804-9ae8f0576381@github.com>

java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines. It seems to be a testbug as adding some stability improvements fix the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. I have removed the problem listing and tested it in windows platform also, it works fine there.

Fix:
Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.

-------------

Commit messages:
 - 8288415: java/awt/PopupMenu/PopupMenuLocation.java is unstable in MacOS machines

Changes: https://git.openjdk.org/jdk/pull/9187/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9187&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288415
  Stats: 22 lines in 2 files changed: 10 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/9187.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9187/head:pull/9187

PR: https://git.openjdk.org/jdk/pull/9187


From asotona at openjdk.org  Thu Jun 16 17:05:17 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Jun 2022 17:05:17 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v12]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <3FVbsCyO8Uhv_P47AQJRdjzXy-Vrd3bD1-ReNIZ7jBI=.f4b29583-4211-4027-90b1-f7e133ff56ea@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - ... and 6 more: https://git.openjdk.org/jdk/compare/e7d52e25...1b2d663d

-------------

Changes: https://git.openjdk.org/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=11
  Stats: 442 lines in 17 files changed: 440 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.org/jdk/pull/8599


From aturbanov at openjdk.org  Thu Jun 16 17:33:55 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 16 Jun 2022 17:33:55 GMT
Subject: RFR: 8284672: Collapse identical catch branches in java.desktop
 [v2]
In-Reply-To: <vcQO9naoHJ0HBmxS2bn8rSni0VWR8avPDSibJHtJ9KU=.4edcb92d-65f5-4090-8619-d01ebff6696a@github.com>
References: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
 <TLLG7XM4wV1Q7douly657vwd36dod5qUFMICnl7wpJc=.982c2ba7-cfed-43cb-a68d-4077b07bf4f7@github.com>
 <vcQO9naoHJ0HBmxS2bn8rSni0VWR8avPDSibJHtJ9KU=.4edcb92d-65f5-4090-8619-d01ebff6696a@github.com>
Message-ID: <3yyPQ940zQYkL4VGtXL0Enmfsu7Qmx_ZNHX14oONnR4=.14cce160-3174-4ab5-8733-600af7f3d88a@github.com>

On Thu, 16 Jun 2022 03:43:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8284672: Collapse identical catch branches in java.desktop
>>   fix formatting
>
> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java line 120:
> 
>> 118:             try {
>> 119:                 INSTANCE = new Metacity(themeName);
>> 120:             } catch (FileNotFoundException ex) {
> 
> Is it possible that the FileNotFoundException was ignored intentionally? After this change, it will be traced.

I didn't change how `FileNotFoundException` is handled. It's still ignored.

-------------

PR: https://git.openjdk.org/jdk/pull/8154


From bourges.laurent at gmail.com  Thu Jun 16 20:24:12 2022
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 16 Jun 2022 22:24:12 +0200
Subject: Any interest in JDK-8264999 (stroke miter edge case in
 Marlin)
In-Reply-To: <CAKjRUT6EwosyowHwaEK7HzNYox17v3OBaQHc7N77sa5fopVBYw@mail.gmail.com>
References: <em956b4aed-8eed-4621-88ac-4433c897d3cd@4e48b9a9.com>
 <CAKjRUT5=CsuyXP2QPPYYdH5YRPKDJ_xopAb0vEJ-v8CVKhjQhA@mail.gmail.com>
 <em4b3d4ab2-f324-4bdf-b221-36f35f807324@4e48b9a9.com>
 <CAKjRUT6vcEPciK+X9J9ZEU_Fcv3Z_i-N_KwUrRo8g3WsPR_6yg@mail.gmail.com>
 <CAKjRUT62cVDTfF4HW_LRywqo5dQt7HTeoQ+hJFk9h_8szs8fBg@mail.gmail.com>
 <CAKjRUT6XjXmY_O_qsPLYZ4XELgnFf71_Dr4C5vEUj-UqqFu_5g@mail.gmail.com>
 <CAKjRUT54LYwseYDKLwMzbbTvVeGiiEOO=i_OUm7tDbE2Y06i7Q@mail.gmail.com>
 <em2349b285-c3ce-4077-8edd-ec5dabc7200c@0b4679bb.com>
 <CAKjRUT6=5CusEbZVx4wLTds_M=i9r5VoC8MhqAXXyFf9rxLNXQ@mail.gmail.com>
 <CAKjRUT6EwosyowHwaEK7HzNYox17v3OBaQHc7N77sa5fopVBYw@mail.gmail.com>
Message-ID: <CAKjRUT50tzKr5LVFoPLFTJDj7xFEXxfbZ+wEsagnCV4E4GAPtA@mail.gmail.com>

Dear phil & java2d team,

I think this PR is good to have asap (jdk19 rdp1 ?) as the fix is trivial :
1 if in the Stroker class (3 lines).

Could you please review the PR asap as I am not an official openjdk
reviewer  ?
https://github.com/openjdk/jdk/pull/8943

Thanks,
Laurent

Le ven. 3 juin 2022, 00:07, Laurent Bourg?s <bourges.laurent at gmail.com> a
?crit :

> Sorry, I corrected 2 typo error:
>
> I quickly tested my modified patch with the extra condition and noticed no
> difference in my tests + fixed the original reproducer code.
>
> Laurent
>
> Le ven. 3 juin 2022, 00:00, Laurent Bourg?s <bourges.laurent at gmail.com> a
> ?crit :
>
>> Hi Jeremy,
>>
>> I quickly tested my modified path with the extra condition and noticed so
>> difference in my tests + fixed the original reproducer code.
>>
>> It is quite trivial ~ 3 lines in Stroker so it seems doable to release
>> this fix on time.
>>
>> I will look at your test code and see how to test few more cases :
>> quad(..., end) + lineto(end) and cubicto(..., end) + lineto(end).
>>
>> Anyway this looks good to fix.
>>
>> Let's see if phil or anybody else has a slot for a simple review next
>> week.
>>
>> Roadmap:
>> https://openjdk.org/projects/jdk/19/
>>
>> Deadline for integration is june 9th.
>>
>> Cheers,
>> Laurent
>>
>> Le jeu. 2 juin 2022, 23:36, Jeremy Wood <mickleness at gmail.com> a ?crit :
>>
>>> Laurent,
>>>
>>> I made a very modest PR here:
>>>
>>> https://github.com/openjdk/jdk/pull/8943
>>>
>>> I wasn?t aware there was a deadline coming up; thanks for letting me
>>> know.
>>>
>>> This passes my current test, but depending on code review feedback it?s
>>> hard to predict if this will be ready by next week.
>>>
>>>   - Jeremy
>>>
>>> ------ Original Message ------
>>> From "Laurent Bourg?s" <bourges.laurent at gmail.com>
>>> To "Jeremy Wood" <mickleness at gmail.com>
>>> Cc client-libs-dev at openjdk.java.net
>>> Date 6/2/2022 4:48:25 PM
>>> Subject Re: Re[2]: Any interest in JDK-8264999 (stroke miter edge case
>>> in Marlin)
>>>
>>> >Jeremy,
>>> >
>>> >I hope you are doing well.
>>> >
>>> >As jdk9 rdp1 is next week, do you plan this bug to be ready for this
>>> >short window or not ?
>>> >
>>> >Laurent
>>> >
>>> >Le dim. 29 mai 2022, 09:31, Laurent Bourg?s <bourges.laurent at gmail.com>
>>>
>>> >a ?crit :
>>> >>One more general comment on this bug:
>>> >>what is expected when lineTo() does not change last point after all
>>> >>other possible operations ?
>>> >>- lineTo, lineto (this bug)
>>> >>- quadTo, lineto
>>> >>- cubicTo, lineto
>>> >>- moveto, lineto: point (ok)
>>> >>- close, lineto(star: equiv to close, move start, lineto start: point
>>> >>start (ok ?)
>>> >>
>>> >>If any drawing operation in progress (lineto, quadto, curveto), then
>>> >>skip repeated end point is the specified behaviour.
>>> >>
>>> >>Laurent
>>> >>
>>> >>Le mer. 25 mai 2022, 08:57, Laurent Bourg?s
>>> >><bourges.laurent at gmail.com> a ?crit :
>>> >>>In Stroker, this lines seems causing the problem:
>>> >>>
>>> https://github.com/openjdk/jdk/blob/a0cccb54791d954bf08da5aac9b9794e370617c8/src/java.desktop/share/classes/sun/java2d/marlin/Stroker.java#L568
>>> >>>
>>> >>>If delta is 0, then tangent is (1, 0) !
>>> >>>Should be:
>>> >>>If drawOp was lineTo and delta is 0, return (skip).
>>> >>>
>>> >>>I wonder if there are other renderer suffering the same problem.
>>> >>>Phil, how could we generalize this kind of path operation filtering ?
>>> >>>
>>> >>>My 2 cents,
>>> >>>Laurent
>>> >>>
>>> >>>Le mer. 25 mai 2022, 08:15, Laurent Bourg?s
>>> >>><bourges.laurent at gmail.com> a ?crit :
>>> >>>>Jeremy,
>>> >>>>
>>> >>>>Probably your fix could be plugged in marlin pathTo() :
>>> >>>>
>>> https://github.com/openjdk/jdk/blob/742644e291039e4f2f30cf80718669c06da5809c/src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java#L768
>>> >>>>
>>> >>>>Or in Stroker lineTo...
>>> >>>>
>>> >>>>Laurent
>>> >>>>
>>> >>>>Le mar. 24 mai 2022, 22:55, Jeremy Wood <mickleness at gmail.com> a
>>> >>>>?crit :
>>> >>>>>I may still move it in the Stroker classes. There are a few other
>>> >>>>>things
>>> >>>>>I want to look at, too. This is a very rough draft I put together
>>> >>>>>in
>>> >>>>>under an hour; I just wanted to make sure it was worth pursuing
>>> >>>>>before I
>>> >>>>>put more time into it.
>>> >>>>>
>>> >>>>>   - Jeremy
>>> >>>>>
>>> >>>>>
>>> >>>>>------ Original Message ------
>>> >>>>>From "Laurent Bourg?s" <bourges.laurent at gmail.com>
>>> >>>>>To "Jeremy Wood" <mickleness at gmail.com>
>>> >>>>>Cc client-libs-dev at openjdk.java.net
>>> >>>>>Date 5/24/2022 4:35:21 PM
>>> >>>>>Subject Re: Any interest in JDK-8264999 (stroke miter edge case in
>>> >>>>>Marlin)
>>> >>>>>
>>> >>>>> >Thanks Jereremy for the notification I was not aware of this one.
>>> >>>>> >
>>> >>>>> >I wonder if the problem should be fixed inside the marlin renderer
>>> >>>>> >Stroker that should ignore such useless lineTo...
>>> >>>>> >
>>> >>>>> >I will read your code and try to figure out potential causes in
>>> >>>>>stroker
>>> >>>>> >and give you my feedback.
>>> >>>>> >
>>> >>>>> >Laurent
>>> >>>>> >
>>> >>>>> >Le mar. 24 mai 2022, 19:52, Jeremy Wood <mickleness at gmail.com> a
>>> >>>>>?crit
>>> >>>>> >:
>>> >>>>> >>This is a P3 ticket currently assigned to Philip Race:
>>> >>>>> >>https://bugs.openjdk.java.net/browse/JDK-8264999
>>> >>>>> >>
>>> >>>>> >>If I put together a PR: Is anyone available/willing to help
>>> >>>>>review it?
>>> >>>>> >>
>>> >>>>> >>I made a rough draft
>>> >>>>> >><
>>> https://github.com/openjdk/jdk/compare/master...mickleness:JDK-8264999?expand=1
>>> >
>>> >>>>> >>of a potential solution last night. I can continue to work on
>>> >>>>>this, or
>>> >>>>> >>I
>>> >>>>> >>can move on if the interest isn?t there.
>>> >>>>> >>
>>> >>>>> >>(No urgency at all.)
>>> >>>>> >>
>>> >>>>> >>Regards,
>>> >>>>> >>   - Jeremy
>>> >>>>> >><https://>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220616/213fc039/attachment.htm>

From aivanov at openjdk.org  Thu Jun 16 20:37:51 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 16 Jun 2022 20:37:51 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v16]
In-Reply-To: <p9AL6RYYTvTDxbQXitofuI3MT-LwfPOum6fEvhrb2ic=.1aad6703-6d8b-4c7c-86e6-b5deb4fe5530@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <p9AL6RYYTvTDxbQXitofuI3MT-LwfPOum6fEvhrb2ic=.1aad6703-6d8b-4c7c-86e6-b5deb4fe5530@github.com>
Message-ID: <NJX82eQA1MK96hInAkWYida4iB4_e54h3qf8pPa8iTg=.2e892073-50f4-4740-ab7c-d172a2fec562@github.com>

On Thu, 16 Jun 2022 07:59:08 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added list format to javadoc and moved to under table. Fixed auto import.

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1304:

> 1302:      *
> 1303:      * <p>
> 1304:      * @implNote

The `<p>` tag before `@implNote` is unneeded, javadoc will generate a section code.

At least I can't see it used in other places. I'm currently building docs with this change to confirm.

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1314:

> 1312:      *     <li>The content within the tags will be handled by the editor as
> 1313:      *     regular text.</li>
> 1314:      * </ul>

You should close `</li>` on the first line but after closing `</ul>`: the inner `<ul>` has to be inside a list item.

The list should look like:

<ul>
    <li>Outer 1st
        <ul>
            <li>Inner</li>
        </ul>
   </li>
   <li>Outer 2nd</li>
</ul>

-------------

PR: https://git.openjdk.org/jdk/pull/7446


From aivanov at openjdk.org  Thu Jun 16 20:50:55 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 16 Jun 2022 20:50:55 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v16]
In-Reply-To: <NJX82eQA1MK96hInAkWYida4iB4_e54h3qf8pPa8iTg=.2e892073-50f4-4740-ab7c-d172a2fec562@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <p9AL6RYYTvTDxbQXitofuI3MT-LwfPOum6fEvhrb2ic=.1aad6703-6d8b-4c7c-86e6-b5deb4fe5530@github.com>
 <NJX82eQA1MK96hInAkWYida4iB4_e54h3qf8pPa8iTg=.2e892073-50f4-4740-ab7c-d172a2fec562@github.com>
Message-ID: <YgnXKp7ThtKDOSHci0S4cdbhjJqplajzrCJiWjZYhN8=.d23bffc1-2cb6-4a32-b206-c5416b57bf57@github.com>

On Thu, 16 Jun 2022 20:34:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The `<p>` tag before `@implNote` is unneeded, javadoc will generate a section code.

It must be removed, it results in `make docs` failure:


=== Output from failing command(s) repeated here ===
* For target jdk_modules_java.desktop__the.java.desktop_batch:
...\classes\javax\swing\text\html\HTMLEditorKit.java:1303:
warning: empty <p> tag
     * <p>
       ^

> You should close `</li>` not on the first line but after closing `</ul>`: the inner `<ul>` has to be inside a list item.

`make docs` also reports an error here:


...\javax\swing\text\html\HTMLEditorKit.java:1310:
error: tag not allowed here: <ul>
     * <ul>
       ^

-------------

PR: https://git.openjdk.org/jdk/pull/7446


From dnguyen at openjdk.org  Thu Jun 16 21:31:45 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 16 Jun 2022 21:31:45 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v17]
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <CDFbiFOSx0GkULnOIAEX8z0oNSPUNFJBpN4uhMbe9S4=.0ee7d88e-8d07-4b4d-a54c-43c86e8fdc95@github.com>

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Fixed list format. Removed p.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7446/files
  - new: https://git.openjdk.org/jdk/pull/7446/files/b7a7ac88..b946da57

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7446&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7446&range=15-16

  Stats: 16 lines in 1 file changed: 2 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/7446.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7446/head:pull/7446

PR: https://git.openjdk.org/jdk/pull/7446


From dnguyen at openjdk.org  Thu Jun 16 21:46:55 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 16 Jun 2022 21:46:55 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v16]
In-Reply-To: <YgnXKp7ThtKDOSHci0S4cdbhjJqplajzrCJiWjZYhN8=.d23bffc1-2cb6-4a32-b206-c5416b57bf57@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <p9AL6RYYTvTDxbQXitofuI3MT-LwfPOum6fEvhrb2ic=.1aad6703-6d8b-4c7c-86e6-b5deb4fe5530@github.com>
 <NJX82eQA1MK96hInAkWYida4iB4_e54h3qf8pPa8iTg=.2e892073-50f4-4740-ab7c-d172a2fec562@github.com>
 <YgnXKp7ThtKDOSHci0S4cdbhjJqplajzrCJiWjZYhN8=.d23bffc1-2cb6-4a32-b206-c5416b57bf57@github.com>
Message-ID: <lExWXDWdHihvyRsmuL2yl0BSb06u__v3ep1KAA_kMyg=.7b3ead9b-9c38-4f6d-b2ec-11b52e86d903@github.com>

On Thu, 16 Jun 2022 20:46:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1314:
>> 
>>> 1312:      *     <li>The content within the tags will be handled by the editor as
>>> 1313:      *     regular text.</li>
>>> 1314:      * </ul>
>> 
>> You should close `</li>` not on the first line but after closing `</ul>`: the inner `<ul>` has to be inside a list item.
>> 
>> The list should look like:
>> 
>> <ul>
>>     <li>Outer 1st
>>         <ul>
>>             <li>Inner</li>
>>         </ul>
>>    </li>
>>    <li>Outer 2nd</li>
>> </ul>
>
>> You should close `</li>` not on the first line but after closing `</ul>`: the inner `<ul>` has to be inside a list item.
> 
> `make docs` also reports an error here:
> 
> 
> ...\javax\swing\text\html\HTMLEditorKit.java:1310:
> error: tag not allowed here: <ul>
>      * <ul>
>        ^

@aivanov-jdk I believe I fixed it. I ran make docs and I got no errors now.

-------------

PR: https://git.openjdk.org/jdk/pull/7446


From serb at openjdk.org  Fri Jun 17 03:36:45 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 17 Jun 2022 03:36:45 GMT
Subject: RFR: 8288633: The ICC_ColorSpace.fromCIEXYZ method uses the wrong
 rendering intent
In-Reply-To: <AprfDeGGekE6v7_zvFM4-HP6mlJnsl7ORj35pSVcbIM=.414a77f0-99db-4535-8bfe-94c77418aeb6@github.com>
References: <AprfDeGGekE6v7_zvFM4-HP6mlJnsl7ORj35pSVcbIM=.414a77f0-99db-4535-8bfe-94c77418aeb6@github.com>
Message-ID: <ygP4ipr5Jd3HKCm2qZnTSwV177k0Mui9loKSbwHmADw=.94970b14-5319-4d39-acb7-256a5ae8f6ed@github.com>

On Fri, 17 Jun 2022 00:09:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The specification of the  ICC_ColorSpace.fromCIEXYZ method [says](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java*L428__;Iw!!ACWV5N9M2RV99hQ!O6u_5a2OIv7nQRvzuo8YPagpD5wweMTCcCMXjlAULI5kuKM3O6ylgYgAkXRlVnqJZwTMSj08ApwCsE_EIQeU5A$ ):
> 
>> * This method transforms color values using relative colorimetry, as defined by the ICC Specification.
> 
> The LCMS plugin implementation expects the rendering intent in the first part of transform:
> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java*L116__;Iw!!ACWV5N9M2RV99hQ!O6u_5a2OIv7nQRvzuo8YPagpD5wweMTCcCMXjlAULI5kuKM3O6ylgYgAkXRlVnqJZwTMSj08ApwCsE-MkB32-w$ 
> 
> But the ICC_ColorSpace.fromCIEXYZ pass "ICC_Profile.icRelativeColorimetric" to the [second ](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java*L534__;Iw!!ACWV5N9M2RV99hQ!O6u_5a2OIv7nQRvzuo8YPagpD5wweMTCcCMXjlAULI5kuKM3O6ylgYgAkXRlVnqJZwTMSj08ApwCsE8nfC5jpQ$ ) part of transform. 
> 
> Note that ICC_ColorSpace.toCIEXYZ has a similar [specification ](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java*L288)is__;Iw!!ACWV5N9M2RV99hQ!O6u_5a2OIv7nQRvzuo8YPagpD5wweMTCcCMXjlAULI5kuKM3O6ylgYgAkXRlVnqJZwTMSj08ApwCsE9fNODMBw$  implemented [properly](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java*L391__;Iw!!ACWV5N9M2RV99hQ!O6u_5a2OIv7nQRvzuo8YPagpD5wweMTCcCMXjlAULI5kuKM3O6ylgYgAkXRlVnqJZwTMSj08ApwCsE_VcZTZVA$ ).

src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java line 539:

> 537:                         transforms[1] = mdl.createTransform(thisProfile,
> 538:                                         ColorTransform.Any, ColorTransform.Out);
> 539:                     }

Note that this try/catch block is not needed, we never throw the exceptions here, but I follow this pattern for now. Will clean up it in the separate PR.

-------------

PR: https://git.openjdk.org/jdk/pull/9194


From serb at openjdk.org  Fri Jun 17 03:36:43 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 17 Jun 2022 03:36:43 GMT
Subject: RFR: 8288633: The ICC_ColorSpace.fromCIEXYZ method uses the wrong
 rendering intent
Message-ID: <AprfDeGGekE6v7_zvFM4-HP6mlJnsl7ORj35pSVcbIM=.414a77f0-99db-4535-8bfe-94c77418aeb6@github.com>

The specification of the  ICC_ColorSpace.fromCIEXYZ method [says](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java*L428__;Iw!!ACWV5N9M2RV99hQ!NAAdRno23xze0ZEWsbb6vcPyhq3uSLQLn75UMmiM--6Np4w3HL7ZObrqG4JR_33oVwNueSb1CcnE78vZi2YAcw$ ):

> * This method transforms color values using relative colorimetry, as defined by the ICC Specification.

The LCMS plugin implementation expects the rendering intent in the first part of transform:
https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java*L116__;Iw!!ACWV5N9M2RV99hQ!NAAdRno23xze0ZEWsbb6vcPyhq3uSLQLn75UMmiM--6Np4w3HL7ZObrqG4JR_33oVwNueSb1CcnE78tHGfZENw$ 

But the ICC_ColorSpace.fromCIEXYZ pass "ICC_Profile.icRelativeColorimetric" to the [second ](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java*L534__;Iw!!ACWV5N9M2RV99hQ!NAAdRno23xze0ZEWsbb6vcPyhq3uSLQLn75UMmiM--6Np4w3HL7ZObrqG4JR_33oVwNueSb1CcnE78s0xPRGZQ$ ) part of transform. 

Note that ICC_ColorSpace.toCIEXYZ has a similar [specification ](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java*L288)is__;Iw!!ACWV5N9M2RV99hQ!NAAdRno23xze0ZEWsbb6vcPyhq3uSLQLn75UMmiM--6Np4w3HL7ZObrqG4JR_33oVwNueSb1CcnE78v2XGbsLw$  implemented [properly](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java*L391__;Iw!!ACWV5N9M2RV99hQ!NAAdRno23xze0ZEWsbb6vcPyhq3uSLQLn75UMmiM--6Np4w3HL7ZObrqG4JR_33oVwNueSb1CcnE78vH5MMpLg$ ).

-------------

Commit messages:
 - Update ICC_ColorSpace.java
 - 8288633: The ICC_ColorSpace.fromCIEXYZ method uses the wrong rendering intent

Changes: https://git.openjdk.org/jdk/pull/9194/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9194&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288633
  Stats: 102 lines in 2 files changed: 95 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9194.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9194/head:pull/9194

PR: https://git.openjdk.org/jdk/pull/9194


From psadhukhan at openjdk.org  Fri Jun 17 03:53:09 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 17 Jun 2022 03:53:09 GMT
Subject: RFR: 8288528: broken links in java.desktop
Message-ID: <FWD3xgIj5BMR-uu2hAyXutmEmlx1Jdm4pnxYk8V8MGQ=.99c6d315-6cd1-477f-a8f9-a40f14951e82@github.com>

doccheck reports some broken links which are rectified

-------------

Commit messages:
 - 8288528: broken links in java.desktop

Changes: https://git.openjdk.org/jdk/pull/9195/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9195&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288528
  Stats: 10 lines in 4 files changed: 0 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/9195.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9195/head:pull/9195

PR: https://git.openjdk.org/jdk/pull/9195


From serb at openjdk.org  Fri Jun 17 08:07:51 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 17 Jun 2022 08:07:51 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines
In-Reply-To: <pClI2zW5gi4TBiMW2CeftBlBN_p5Z7KWF4fpeVZqtlg=.e332bcae-1242-4227-8804-9ae8f0576381@github.com>
References: <pClI2zW5gi4TBiMW2CeftBlBN_p5Z7KWF4fpeVZqtlg=.e332bcae-1242-4227-8804-9ae8f0576381@github.com>
Message-ID: <sCaZQ0dbK17CJoSb1Z4mzHXB5mvYmn3DfZaMqdhPt8g=.705930d8-3fbe-49f4-a080-0771c74b15c1@github.com>

On Thu, 16 Jun 2022 15:01:12 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines. It seems to be a testbug as adding some stability improvements fix the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. I have removed the problem listing and tested it in windows platform also, it works fine there.
> 
> Fix:
> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.

test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 47:

> 45:  * @key headful
> 46:  * @bug 8160270
> 47:  * @run main/timeout=300/othervm -Dsun.java2d.uiScale=1 PopupMenuLocation

Why do you need a "-Dsun.java2d.uiScale=1" option? I do not think it affects this test execution in any way.

test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 77:

> 75: 
> 76:     private static void test(final Point tmp) throws Exception {
> 77:         actionEventReceivedLatch = new CountDownLatch(1);

You set this field on one thread and read on another, some synchronization is needed.

test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 119:

> 117:         final AtomicReference<Point> pt = new AtomicReference<>();
> 118:         SwingUtilities.invokeAndWait(() -> {
> 119:                                           pt.set(frame.getLocationOnScreen());

This test uses only awt components which should work on any threads, why invokeAndWait is necessary?

-------------

PR: https://git.openjdk.org/jdk/pull/9187


From serb at openjdk.org  Fri Jun 17 08:22:50 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 17 Jun 2022 08:22:50 GMT
Subject: RFR: 8288567: [macOS] NPE at
 sun.lwawt.macosx.CPlatformComponent.setBounds
In-Reply-To: <4OLkCQnPTmf6P-Iie09lahfeBynpAC0b2kfPU_vyW7g=.a6d729a3-2ae8-4050-94e0-d0e0559fdd70@github.com>
References: <4OLkCQnPTmf6P-Iie09lahfeBynpAC0b2kfPU_vyW7g=.a6d729a3-2ae8-4050-94e0-d0e0559fdd70@github.com>
Message-ID: <A3KGsXbZMUp09KvJF_O1zn_PTAPy3Ngn4YkDYXfqsYY=.2138283a-2500-4666-8c58-081a8d90fb50@github.com>

On Thu, 16 Jun 2022 11:30:01 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> Even though I have not been able to reproduce the crash by hand, the problem and the fix are fairly obvious: 
> `CWarningWindow` doesn't have a peer, so `platformWindow.getPeer()` can be null in that case. The fix is to accomodate for that in `CPlatformComponent.setBounds()`. Similar provisions exist elsewhere in the vicinity (for ex. `CPlatformLWWindow.setBounds()`, `CPlatformWindow.maximize()`, etc).

The CPlatformComponent is a part of JAWT interface, I think we should not provide such access to the security warning window. So probably it will be better to set CPlatformLWComponent(which is noop) when we create a warning icon?

-------------

PR: https://git.openjdk.org/jdk/pull/9184


From smandalika at openjdk.org  Fri Jun 17 08:25:12 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Fri, 17 Jun 2022 08:25:12 GMT
Subject: Integrated: JDK-8282777: Create a Regression test for JDK-4515031
In-Reply-To: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
References: <D8K1EcGCjhQQzplHsgYncKPvGmSPhrAs7RNDIl_pQlo=.e8d60f67-9cf4-4ac7-957b-ddbecffc85de@github.com>
Message-ID: <R8AZ7zjk-Tuurwy5P42xER8EF7ymcmTvRMaNaHEJ_Jw=.a89d5312-e433-472f-a2fa-eeab6923f513@github.com>

On Tue, 8 Mar 2022 08:17:09 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Create a Regression test for [JDK-4515031](https://bugs.openjdk.java.net/browse/JDK-4515031)
> 
> The issue indicates the need for a a getAccessibleDescription being implemented for the JFileChooser.
> The test added verifies the same.
> This review is for migrating tests from a closed test suite to open.

This pull request has now been integrated.

Changeset: 523d553e
Author:    Srinivas Mandalika <smandalika at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/523d553e13e7d6fbf0a3befb1c18431738fe8d7f
Stats:     102 lines in 1 file changed: 102 ins; 0 del; 0 mod

8282777: Create a Regression test for JDK-4515031

Reviewed-by: serb

-------------

PR: https://git.openjdk.org/jdk/pull/7738


From mvs at openjdk.org  Fri Jun 17 10:58:04 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Fri, 17 Jun 2022 10:58:04 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v2]
In-Reply-To: <sCaZQ0dbK17CJoSb1Z4mzHXB5mvYmn3DfZaMqdhPt8g=.705930d8-3fbe-49f4-a080-0771c74b15c1@github.com>
References: <pClI2zW5gi4TBiMW2CeftBlBN_p5Z7KWF4fpeVZqtlg=.e332bcae-1242-4227-8804-9ae8f0576381@github.com>
 <sCaZQ0dbK17CJoSb1Z4mzHXB5mvYmn3DfZaMqdhPt8g=.705930d8-3fbe-49f4-a080-0771c74b15c1@github.com>
Message-ID: <PEpU-cy2OGTvtxFnTL6At4xHlQqZ9NrLUxd71prsqok=.54eacd9d-2838-4481-a415-6739d8734f72@github.com>

On Fri, 17 Jun 2022 08:01:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments fixed: Removed -Dsun.java2d.uiScale=1, frame.getLocationOnScreen() removed from EDT, added volatile keyword for actionEventReceivedLatch
>
> test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 47:
> 
>> 45:  * @key headful
>> 46:  * @bug 8160270
>> 47:  * @run main/timeout=300/othervm -Dsun.java2d.uiScale=1 PopupMenuLocation
> 
> Why do you need a "-Dsun.java2d.uiScale=1" option? I do not think it affects this test execution in any way.

Removed it

> test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 77:
> 
>> 75: 
>> 76:     private static void test(final Point tmp) throws Exception {
>> 77:         actionEventReceivedLatch = new CountDownLatch(1);
> 
> You set this field on one thread and read on another, some synchronization is needed.

Added volatile keyword for this field

> test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 119:
> 
>> 117:         final AtomicReference<Point> pt = new AtomicReference<>();
>> 118:         SwingUtilities.invokeAndWait(() -> {
>> 119:                                           pt.set(frame.getLocationOnScreen());
> 
> This test uses only awt components which should work on any threads, why invokeAndWait is necessary?

Removed from EDT

-------------

PR: https://git.openjdk.org/jdk/pull/9187


From aivanov at openjdk.org  Fri Jun 17 14:00:01 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 17 Jun 2022 14:00:01 GMT
Subject: RFR: 8284672: Collapse identical catch branches in java.desktop
 [v2]
In-Reply-To: <TLLG7XM4wV1Q7douly657vwd36dod5qUFMICnl7wpJc=.982c2ba7-cfed-43cb-a68d-4077b07bf4f7@github.com>
References: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
 <TLLG7XM4wV1Q7douly657vwd36dod5qUFMICnl7wpJc=.982c2ba7-cfed-43cb-a68d-4077b07bf4f7@github.com>
Message-ID: <KRKvYMZQSbOsNI2Ujv7hTs85TtliagFK6pxEMPTGKYU=.35bed33a-ae3c-4e1c-8ab3-7ad3cfd1796c@github.com>

On Wed, 1 Jun 2022 20:55:30 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types".
>> It simplifies code. Reduces duplication.
>> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284672: Collapse identical catch branches in java.desktop
>   fix formatting

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/text/InternationalFormatter.java line 531:

> 529:                         updateMask(iterator);
> 530:                     }
> 531:                     catch (ParseException | NullPointerException | IllegalArgumentException e) {}

Maybe move `catch` to the line with the closing brace? The try block above follows the regular Java code style.

src/java.desktop/share/classes/javax/swing/text/InternationalFormatter.java line 1049:

> 1047:                                 }
> 1048:                             }
> 1049:                             catch (ParseException | BadLocationException e) { }

Same here?

-------------

PR: https://git.openjdk.org/jdk/pull/8154


From aivanov at openjdk.org  Fri Jun 17 14:00:02 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 17 Jun 2022 14:00:02 GMT
Subject: RFR: 8284672: Collapse identical catch branches in java.desktop
 [v2]
In-Reply-To: <83f5TNNzytdB_O-gAmeG1o57YtzyN_uVBxqwl4P63mc=.1750e7f0-71a7-46e1-8bf4-f2ca63bd956d@github.com>
References: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
 <sHkXMpkUXAG5rkkJnednTmISoY4Li2RNOFQcf6zytQ8=.1afdaf08-c759-4ef7-b11c-b63b3d983e04@github.com>
 <Qhm51ibMOoE-vKp1zECWtwEQhExJ5jQOQxtI1aEn6sA=.fa1de9e0-b7ce-4b05-ad49-38f036a6bbb0@github.com>
 <83f5TNNzytdB_O-gAmeG1o57YtzyN_uVBxqwl4P63mc=.1750e7f0-71a7-46e1-8bf4-f2ca63bd956d@github.com>
Message-ID: <rJIwxLdsbgw_B8Y7mCiGbbF0JcuEKdliLLoLBv_mzuI=.00ed2391-fd8c-4538-903a-d4d81467774a@github.com>

On Thu, 16 Jun 2022 03:49:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yeah. I think it makes sense to amend behavior here and not catch IOException. Callers should be ready for it.
>
> This getSoundbank method is called when we iterate over providers and check which can be used, unfortunately, that code is not ready for the IOException and we return "null" -> the next provider will be checked. This is a kind of compatibility quirk.

Doesn't IOException mean the next provider is to be checked?

That is the IOException could be handled in the iterator, its code may need to be updated for that. Then the implementations of `getSoundbank(URL)` could propagate the IOException too and eliminate duplicate code.

`InvalidMidiDataException` isn't caught there, so the iterator code should handle it.

-------------

PR: https://git.openjdk.org/jdk/pull/8154


From aivanov at openjdk.org  Fri Jun 17 14:38:01 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 17 Jun 2022 14:38:01 GMT
Subject: RFR: 8288528: broken links in java.desktop
In-Reply-To: <FWD3xgIj5BMR-uu2hAyXutmEmlx1Jdm4pnxYk8V8MGQ=.99c6d315-6cd1-477f-a8f9-a40f14951e82@github.com>
References: <FWD3xgIj5BMR-uu2hAyXutmEmlx1Jdm4pnxYk8V8MGQ=.99c6d315-6cd1-477f-a8f9-a40f14951e82@github.com>
Message-ID: <9FnfXiIJmrJEj_1fJhVZZKrg9tzzRPFZXCpNy1KDVqA=.b2e56e81-a712-4dd0-a463-558bb9bb7de1@github.com>

On Fri, 17 Jun 2022 03:45:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> doccheck reports some broken links which are rectified

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/share/classes/java/awt/doc-files/AWTThreadIssues.html line 124:

> 122: <p>
> 123: Starting with 1.4, the behavior has changed as a result of the fix for
> 124: <a href="https://bugs.openjdk.org/browse/JDK-4030718">

The old URL has changed to https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4030718

I am for using JBS links though.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java line 2143:

> 2141:     /**
> 2142:      * Returns a {@code LayoutStyle} implementing Java look and feel
> 2143:      * design guidelines.

Suggestion:

     * Returns a {@code LayoutStyle} implementing the Java look and feel
     * design guidelines.

-------------

PR: https://git.openjdk.org/jdk/pull/9195


From mvs at openjdk.org  Fri Jun 17 14:38:35 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Fri, 17 Jun 2022 14:38:35 GMT
Subject: RFR: 8288428: javax/swing/JInternalFrame/Test6505027.java fails
 frequently in MacOS 12 machines
Message-ID: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>

javax/swing/JInternalFrame/Test6505027.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines and it fails intermittently in CI causing some noise.
It seems to be a testbug as adding some stability improvements fix the issue.

Fix:
Some stability improvements have been done and the test has been run 10 times per platform in mach5 and got full PASS.

-------------

Commit messages:
 - 8288428: javax/swing/JInternalFrame/Test6505027.java fails frequently in MacOS 12 machines

Changes: https://git.openjdk.org/jdk/pull/9202/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9202&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288428
  Stats: 38 lines in 1 file changed: 26 ins; 3 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/9202.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9202/head:pull/9202

PR: https://git.openjdk.org/jdk/pull/9202


From prr at openjdk.org  Fri Jun 17 14:48:53 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 17 Jun 2022 14:48:53 GMT
Subject: RFR: 8288528: broken links in java.desktop
In-Reply-To: <FWD3xgIj5BMR-uu2hAyXutmEmlx1Jdm4pnxYk8V8MGQ=.99c6d315-6cd1-477f-a8f9-a40f14951e82@github.com>
References: <FWD3xgIj5BMR-uu2hAyXutmEmlx1Jdm4pnxYk8V8MGQ=.99c6d315-6cd1-477f-a8f9-a40f14951e82@github.com>
Message-ID: <NaAcaApewr4G1EVQpWO_7qPJLmZQkpV1n03iA0Cm04A=.f24d81e3-ab06-42d6-ae19-abf2613b856d@github.com>

On Fri, 17 Jun 2022 03:45:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> doccheck reports some broken links which are rectified

Changes requested by prr (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/multi/doc-files/multi_tsc.html line 42:

> 40: This document is based on an article
> 41: originally published in
> 42: <a href="https://www.comp.nus.edu.sg/~cs3283/ftp/Java/swingConnect/archive/plaf_papers_arch/multi_update/multi_update.html"

Well I am 100% sure this article wasn't originally published by the national university of singapore.
And we definitely should NOT be linking there. 
I actually think for most of these we'd be better off getting rid of the link entirely.

-------------

PR: https://git.openjdk.org/jdk/pull/9195


From duke at openjdk.org  Fri Jun 17 15:58:57 2022
From: duke at openjdk.org (kristylee88)
Date: Fri, 17 Jun 2022 15:58:57 GMT
Subject: RFR: 8288567: [macOS] NPE at
 sun.lwawt.macosx.CPlatformComponent.setBounds
In-Reply-To: <4OLkCQnPTmf6P-Iie09lahfeBynpAC0b2kfPU_vyW7g=.a6d729a3-2ae8-4050-94e0-d0e0559fdd70@github.com>
References: <4OLkCQnPTmf6P-Iie09lahfeBynpAC0b2kfPU_vyW7g=.a6d729a3-2ae8-4050-94e0-d0e0559fdd70@github.com>
Message-ID: <UtQzyyDX5y1FU-g1a7x4m7OAl9iv3MaazrgUcmdWhQY=.415da63a-e168-4b3d-a5cd-3f25007c333b@github.com>

On Thu, 16 Jun 2022 11:30:01 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> Even though I have not been able to reproduce the crash by hand, the problem and the fix are fairly obvious: 
> `CWarningWindow` doesn't have a peer, so `platformWindow.getPeer()` can be null in that case. The fix is to accomodate for that in `CPlatformComponent.setBounds()`. Similar provisions exist elsewhere in the vicinity (for ex. `CPlatformLWWindow.setBounds()`, `CPlatformWindow.maximize()`, etc).

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk/pull/9184


From mkartashev at openjdk.org  Fri Jun 17 15:58:59 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Fri, 17 Jun 2022 15:58:59 GMT
Subject: RFR: 8288567: [macOS] NPE at
 sun.lwawt.macosx.CPlatformComponent.setBounds
In-Reply-To: <A3KGsXbZMUp09KvJF_O1zn_PTAPy3Ngn4YkDYXfqsYY=.2138283a-2500-4666-8c58-081a8d90fb50@github.com>
References: <4OLkCQnPTmf6P-Iie09lahfeBynpAC0b2kfPU_vyW7g=.a6d729a3-2ae8-4050-94e0-d0e0559fdd70@github.com>
 <A3KGsXbZMUp09KvJF_O1zn_PTAPy3Ngn4YkDYXfqsYY=.2138283a-2500-4666-8c58-081a8d90fb50@github.com>
Message-ID: <gfHPuekFAjYHbcPzcMj4JDR31clKB1i3SRXT37hIGsQ=.e9e52338-7e3a-4fcc-8b2e-02294219e621@github.com>

On Fri, 17 Jun 2022 08:19:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The CPlatformComponent is a part of JAWT interface, I think we should not provide such access to the security warning window. So probably it will be better to set CPlatformLWComponent(which is noop) when we create a warning icon?

I did not quite understand that. Could you re-phrase it in terms of code, please?

-------------

PR: https://git.openjdk.org/jdk/pull/9184


From aivanov at openjdk.org  Fri Jun 17 17:13:00 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 17 Jun 2022 17:13:00 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v17]
In-Reply-To: <CDFbiFOSx0GkULnOIAEX8z0oNSPUNFJBpN4uhMbe9S4=.0ee7d88e-8d07-4b4d-a54c-43c86e8fdc95@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <CDFbiFOSx0GkULnOIAEX8z0oNSPUNFJBpN4uhMbe9S4=.0ee7d88e-8d07-4b4d-a54c-43c86e8fdc95@github.com>
Message-ID: <nzW2Sf86qP6N2YZv3DINZu0Ja5cX_cAg5aD_RotgQeU=.0f6abf97-f730-43a0-8630-d8a5d13fd40e@github.com>

On Thu, 16 Jun 2022 21:31:45 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed list format. Removed p.

I wonder if `<script>` is the only recognised but not fully supported.

According to the Parser code, `<script>` is the only tag the contents of which is treated as a comment. Other than that, your text looks correct: the tags are rendered as a text field with the tag name, the content is rendered as regular text; when non-editable, these are hidden.

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1308:

> 1306:      *
> 1307:      * <ul>
> 1308:      * <li>When the container using HTML tags is editable:

Suggestion:

     * <li>When the container is editable:

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1310:

> 1308:      * <li>When the container using HTML tags is editable:
> 1309:      *     <ul>
> 1310:      *         <li>Tags display the tag text as editable text fields.</li>

Suggestion:

     *         <li>The tags will be displayed as editable text fields with the tag name.</li>

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1312:

> 1310:      *         <li>Tags display the tag text as editable text fields.</li>
> 1311:      *         <li>The content within the tags will be handled by the editor as
> 1312:      *         regular text.</li>

This is not how `<script>` is handled though: the content is displayed in a text field. The text in the unknown tag is displayed directly.

The content of `<script>` tag is handled as if it's a comment.
<a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/ae2504b4692a5298b5835727b04a44e1edc8a4d6/src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java*L2176-L2177__;Iw!!ACWV5N9M2RV99hQ!PBMPNjkhh2ozj_1_t0_1CHvTIH4bn4bE_eM3bSkNLu9CPcnVYtUWZoSvftqHBz8qxuF-2JYw3a_6Lmtj8fcZT79FYg$">https://github.com/openjdk/jdk/blob/ae2504b4692a5298b5835727b04a44e1edc8a4d6/src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java#L2176-L2177</a>

-------------

PR: https://git.openjdk.org/jdk/pull/7446


From psadhukhan at openjdk.org  Fri Jun 17 17:14:56 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 17 Jun 2022 17:14:56 GMT
Subject: RFR: 8288528: broken links in java.desktop [v2]
In-Reply-To: <FWD3xgIj5BMR-uu2hAyXutmEmlx1Jdm4pnxYk8V8MGQ=.99c6d315-6cd1-477f-a8f9-a40f14951e82@github.com>
References: <FWD3xgIj5BMR-uu2hAyXutmEmlx1Jdm4pnxYk8V8MGQ=.99c6d315-6cd1-477f-a8f9-a40f14951e82@github.com>
Message-ID: <4lqvHf7brez6MZzAyQ_FHJmm7-oNJ9fFhwLxnvg8Iag=.9208e133-7705-44e3-ac42-dd3509f8227c@github.com>

> doccheck reports some broken links which are rectified

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Review comment fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9195/files
  - new: https://git.openjdk.org/jdk/pull/9195/files/f0d30a11..83910eb0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9195&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9195&range=00-01

  Stats: 14 lines in 2 files changed: 0 ins; 13 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9195.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9195/head:pull/9195

PR: https://git.openjdk.org/jdk/pull/9195


From dnguyen at openjdk.org  Fri Jun 17 17:43:59 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 17 Jun 2022 17:43:59 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v18]
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <dmLKo1wO-sdzVIfYIkXfikI3sifzc9TTWLuLuOVHvKA=.adc59e08-890d-47cf-b5a9-089a8cdb49be@github.com>

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Clarified javadoc.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7446/files
  - new: https://git.openjdk.org/jdk/pull/7446/files/b946da57..69d093e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7446&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7446&range=16-17

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/7446.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7446/head:pull/7446

PR: https://git.openjdk.org/jdk/pull/7446


From dnguyen at openjdk.org  Fri Jun 17 17:44:02 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 17 Jun 2022 17:44:02 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v17]
In-Reply-To: <nzW2Sf86qP6N2YZv3DINZu0Ja5cX_cAg5aD_RotgQeU=.0f6abf97-f730-43a0-8630-d8a5d13fd40e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <CDFbiFOSx0GkULnOIAEX8z0oNSPUNFJBpN4uhMbe9S4=.0ee7d88e-8d07-4b4d-a54c-43c86e8fdc95@github.com>
 <nzW2Sf86qP6N2YZv3DINZu0Ja5cX_cAg5aD_RotgQeU=.0f6abf97-f730-43a0-8630-d8a5d13fd40e@github.com>
Message-ID: <UWEwCbxVkvaYTTroDNZawN5xw4htZM4cPczsE5j-xXQ=.35ce4dea-15d6-484d-8b42-9069a49a579a@github.com>

On Fri, 17 Jun 2022 15:29:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed list format. Removed p.
>
> src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1310:
> 
>> 1308:      * <li>When the container using HTML tags is editable:
>> 1309:      *     <ul>
>> 1310:      *         <li>Tags display the tag text as editable text fields.</li>
> 
> Suggestion:
> 
>      *         <li>The tags will be displayed as editable text fields with the tag name.</li>

Incorporated both of the suggested changes for clarification.

> src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1312:
> 
>> 1310:      *         <li>Tags display the tag text as editable text fields.</li>
>> 1311:      *         <li>The content within the tags will be handled by the editor as
>> 1312:      *         regular text.</li>
> 
> This is not how `<script>` is handled though: the content is displayed in a text field. The text in the unknown tag is displayed directly.
> 
> The content of `<script>` tag is handled as if it's a comment.
> <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/ae2504b4692a5298b5835727b04a44e1edc8a4d6/src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java*L2176-L2177__;Iw!!ACWV5N9M2RV99hQ!PnVrjBcKvJKsl9fX2K3YCtM24LMYsgrkK8FME1loi_CnL-s9xVe-pJaoBehKau9VcSJb84q6JAKerMNBFZOPyeckCA$">https://github.com/openjdk/jdk/blob/ae2504b4692a5298b5835727b04a44e1edc8a4d6/src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java#L2176-L2177</a>

I tried to cover this in earlier commits where I differentiate known but unsupported tags, such as script tags, and completely unknown tags. In conversation and testing, HTMLEditorKit.HTMLFactory has a create method that creates HiddenTagViews for unknown tags and for a small list of tags (title, script, param, etc.). In the end, these are all treated the same, so I grouped script tags in this javadoc change. Script tags do have a special case in the Parser where it is handled as a comment but being handled as a comment doesn't change the behavior and still displays the content.

-------------

PR: https://git.openjdk.org/jdk/pull/7446


From duke at openjdk.org  Fri Jun 17 17:46:05 2022
From: duke at openjdk.org (kristylee88)
Date: Fri, 17 Jun 2022 17:46:05 GMT
Subject: RFR: 8288528: broken links in java.desktop [v2]
In-Reply-To: <4lqvHf7brez6MZzAyQ_FHJmm7-oNJ9fFhwLxnvg8Iag=.9208e133-7705-44e3-ac42-dd3509f8227c@github.com>
References: <FWD3xgIj5BMR-uu2hAyXutmEmlx1Jdm4pnxYk8V8MGQ=.99c6d315-6cd1-477f-a8f9-a40f14951e82@github.com>
 <4lqvHf7brez6MZzAyQ_FHJmm7-oNJ9fFhwLxnvg8Iag=.9208e133-7705-44e3-ac42-dd3509f8227c@github.com>
Message-ID: <Feopf6Iwu6ChoD22fxJQqyZTfiXQKyg4ajRE-Riul6M=.e3643e53-9149-4241-b779-cebedb6821c9@github.com>

On Fri, 17 Jun 2022 17:14:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> doccheck reports some broken links which are rectified
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk/pull/9195


From aivanov at openjdk.org  Fri Jun 17 18:07:01 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 17 Jun 2022 18:07:01 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v18]
In-Reply-To: <dmLKo1wO-sdzVIfYIkXfikI3sifzc9TTWLuLuOVHvKA=.adc59e08-890d-47cf-b5a9-089a8cdb49be@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <dmLKo1wO-sdzVIfYIkXfikI3sifzc9TTWLuLuOVHvKA=.adc59e08-890d-47cf-b5a9-089a8cdb49be@github.com>
Message-ID: <qC335AeYDTgpn97c2PZrh4sK4cCP86JAYNRvV-hkcVQ=.82733b30-491c-403c-9aae-08978f0e592f@github.com>

On Fri, 17 Jun 2022 17:43:59 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarified javadoc.

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/7446


From aivanov at openjdk.org  Fri Jun 17 18:52:53 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 17 Jun 2022 18:52:53 GMT
Subject: RFR: 8288528: broken links in java.desktop [v2]
In-Reply-To: <4lqvHf7brez6MZzAyQ_FHJmm7-oNJ9fFhwLxnvg8Iag=.9208e133-7705-44e3-ac42-dd3509f8227c@github.com>
References: <FWD3xgIj5BMR-uu2hAyXutmEmlx1Jdm4pnxYk8V8MGQ=.99c6d315-6cd1-477f-a8f9-a40f14951e82@github.com>
 <4lqvHf7brez6MZzAyQ_FHJmm7-oNJ9fFhwLxnvg8Iag=.9208e133-7705-44e3-ac42-dd3509f8227c@github.com>
Message-ID: <DbxQ0n9Mf77tkVuaXozlkm5RQofACLVj2_Dn_V9x9_A=.91c1bc15-473b-45f0-8ba5-b5e85b03510b@github.com>

On Fri, 17 Jun 2022 17:14:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> doccheck reports some broken links which are rectified
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9195


From serb at openjdk.org  Fri Jun 17 19:07:52 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 17 Jun 2022 19:07:52 GMT
Subject: RFR: 8288567: [macOS] NPE at
 sun.lwawt.macosx.CPlatformComponent.setBounds
In-Reply-To: <gfHPuekFAjYHbcPzcMj4JDR31clKB1i3SRXT37hIGsQ=.e9e52338-7e3a-4fcc-8b2e-02294219e621@github.com>
References: <4OLkCQnPTmf6P-Iie09lahfeBynpAC0b2kfPU_vyW7g=.a6d729a3-2ae8-4050-94e0-d0e0559fdd70@github.com>
 <A3KGsXbZMUp09KvJF_O1zn_PTAPy3Ngn4YkDYXfqsYY=.2138283a-2500-4666-8c58-081a8d90fb50@github.com>
 <gfHPuekFAjYHbcPzcMj4JDR31clKB1i3SRXT37hIGsQ=.e9e52338-7e3a-4fcc-8b2e-02294219e621@github.com>
Message-ID: <kuNCjpwUPcqY2nQZDuGrRWNVmKdYI6o8m1-aN0vV4LU=.c231e19b-4eb4-4f8d-88b4-20b42b0ced6f@github.com>

On Fri, 17 Jun 2022 15:52:05 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> > The CPlatformComponent is a part of JAWT interface, I think we should not provide such access to the security warning window. So probably it will be better to set CPlatformLWComponent(which is noop) when we create a warning icon?
> 
> I did not quite understand that. Could you re-phrase it in terms of code, please?

The CPlatformComponent is a special object which we create for each(most) UI components, this CPlatformComponent object store the native pointer to the native nslayer so the users native code can draw on top of our components. If your investigation in the description is correct and the root cause is CWarningWindow+CPlatformComponent, then I suggest to use the noop version of that object(the CPlatformLWComponent) inside CWarningWindow. This will block the native access to the CWarningWindow.

-------------

PR: https://git.openjdk.org/jdk/pull/9184


From prr at openjdk.org  Fri Jun 17 20:48:57 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 17 Jun 2022 20:48:57 GMT
Subject: RFR: 8288528: broken links in java.desktop [v2]
In-Reply-To: <4lqvHf7brez6MZzAyQ_FHJmm7-oNJ9fFhwLxnvg8Iag=.9208e133-7705-44e3-ac42-dd3509f8227c@github.com>
References: <FWD3xgIj5BMR-uu2hAyXutmEmlx1Jdm4pnxYk8V8MGQ=.99c6d315-6cd1-477f-a8f9-a40f14951e82@github.com>
 <4lqvHf7brez6MZzAyQ_FHJmm7-oNJ9fFhwLxnvg8Iag=.9208e133-7705-44e3-ac42-dd3509f8227c@github.com>
Message-ID: <hdQMggDaknR_3kmb_2oCr3tva6gYUaYlJmT8RKRarRs=.38e073f7-2d42-4484-8fae-d54908fad435@github.com>

On Fri, 17 Jun 2022 17:14:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> doccheck reports some broken links which are rectified
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

Changes requested by prr (Reviewer).

src/java.desktop/share/classes/java/awt/doc-files/AWTThreadIssues.html line 157:

> 155:   <li> Other packages can create displayable components for internal
> 156:        needs and never make them undisplayable. See
> 157: <a href="https://bugs.openjdk.org/browse/JDK-4515058">

This is about Solaris IMF .. I think we don't need to worry about it any more.

src/java.desktop/share/classes/java/awt/doc-files/AWTThreadIssues.html line 159:

> 157: <a href="https://bugs.openjdk.org/browse/JDK-4515058">
> 158: 4515058</a>,
> 159: <a href="https://bugs.openjdk.org/browse/JDK-4671025">

And even better it was resolved in 1.5 under this bug id which I guess was still open when this doc was written

src/java.desktop/share/classes/java/awt/doc-files/AWTThreadIssues.html line 161:

> 159: <a href="https://bugs.openjdk.org/browse/JDK-4671025">
> 160: 4671025</a>, and
> 161: <a href="https://bugs.openjdk.org/browse/JDK-4465537">

This bug was about some off-screen image problem with JScrollBar
It was closed as a dup of 4417287 which was fixed in 1.4

So in summary it is wrong to keep these linked bugs in here.
Remove the lot of them

src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java line 36:

> 34:  * manufacturers.  The Exif specification may be found at
> 35:  * <a href="https://urldefense.com/v3/__http://web.archive.org/web/20131018091152/http:/*exif.org/Exif2-2.PDF__;Lw!!ACWV5N9M2RV99hQ!I-Fd-s8_Zomn1UUt78DbuGfA1KfJRFl6Xzr8upsTCb7FiZOGBhxJxmrm3a6ie_WywxyifkaYQQKu36oPy5wO$">
> 36:  * {@code http://web.archive.org/web/20131018091152/http://exif.org/Exif2-2.PDF}

Let's not point to web archives
https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf seems like a better option. 
Perhaps @bplb has another idea.

-------------

PR: https://git.openjdk.org/jdk/pull/9195


From prr at openjdk.org  Fri Jun 17 20:48:59 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 17 Jun 2022 20:48:59 GMT
Subject: RFR: 8288528: broken links in java.desktop [v2]
In-Reply-To: <9FnfXiIJmrJEj_1fJhVZZKrg9tzzRPFZXCpNy1KDVqA=.b2e56e81-a712-4dd0-a463-558bb9bb7de1@github.com>
References: <FWD3xgIj5BMR-uu2hAyXutmEmlx1Jdm4pnxYk8V8MGQ=.99c6d315-6cd1-477f-a8f9-a40f14951e82@github.com>
 <9FnfXiIJmrJEj_1fJhVZZKrg9tzzRPFZXCpNy1KDVqA=.b2e56e81-a712-4dd0-a463-558bb9bb7de1@github.com>
Message-ID: <687K7qmg3ojM6wfudHnYUvuZ5I7JZpseeBXFx3D1edI=.31973890-ad96-4110-ab60-4d4552f5fbb8@github.com>

On Fri, 17 Jun 2022 14:05:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment fix
>
> src/java.desktop/share/classes/java/awt/doc-files/AWTThreadIssues.html line 124:
> 
>> 122: <p>
>> 123: Starting with 1.4, the behavior has changed as a result of the fix for
>> 124: <a href="https://bugs.openjdk.org/browse/JDK-4030718">
> 
> The old URL has changed to https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4030718
> 
> I am for using JBS links though.

JDK 1.4 launched over 20 years ago. I think we can just scrap the link.
Maybe change the text to scrap mentioining it and just leave the text starting with  

"AWT terminates all its helper threads allowing .. "

-------------

PR: https://git.openjdk.org/jdk/pull/9195


From aivanov at openjdk.org  Fri Jun 17 21:06:01 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 17 Jun 2022 21:06:01 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v18]
In-Reply-To: <dmLKo1wO-sdzVIfYIkXfikI3sifzc9TTWLuLuOVHvKA=.adc59e08-890d-47cf-b5a9-089a8cdb49be@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <dmLKo1wO-sdzVIfYIkXfikI3sifzc9TTWLuLuOVHvKA=.adc59e08-890d-47cf-b5a9-089a8cdb49be@github.com>
Message-ID: <5QfPtHRSQMtgCQ7yT6HlbI1VRvqIHJtCwY9Lie85wpo=.90d5886b-7e60-4360-980f-ebf4785c6d85@github.com>

On Fri, 17 Jun 2022 17:43:59 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarified javadoc.

test/jdk/javax/swing/text/html/HtmlScriptTagParserTest.java line 43:

> 41: 
> 42: public class HtmlScriptTagParserTest {
> 43:     private static String instructionsText = "Pass if you can see the script " +

May I suggest adding `final` to instructions too?

-------------

PR: https://git.openjdk.org/jdk/pull/7446


From psadhukhan at openjdk.org  Mon Jun 20 04:05:42 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 20 Jun 2022 04:05:42 GMT
Subject: RFR: 8288528: broken links in java.desktop [v3]
In-Reply-To: <FWD3xgIj5BMR-uu2hAyXutmEmlx1Jdm4pnxYk8V8MGQ=.99c6d315-6cd1-477f-a8f9-a40f14951e82@github.com>
References: <FWD3xgIj5BMR-uu2hAyXutmEmlx1Jdm4pnxYk8V8MGQ=.99c6d315-6cd1-477f-a8f9-a40f14951e82@github.com>
Message-ID: <DQEEJ4f35n7fzdijnAPdHHVEcEK5Q1357zacfWtnass=.264c65b1-5a49-4428-8423-a97756e1c762@github.com>

> doccheck reports some broken links which are rectified

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary JBS links and fix EXIF link

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9195/files
  - new: https://git.openjdk.org/jdk/pull/9195/files/83910eb0..e3075733

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9195&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9195&range=01-02

  Stats: 9 lines in 2 files changed: 0 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9195.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9195/head:pull/9195

PR: https://git.openjdk.org/jdk/pull/9195


From lbourges at openjdk.org  Mon Jun 20 06:57:48 2022
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Mon, 20 Jun 2022 06:57:48 GMT
Subject: RFR: 8264999: GeneralPath.lineTo() to itself produces jagged lines
 [v4]
In-Reply-To: <zDQ9DQXj6qgiY0yWof30AAchwCBfEmYlyozs0Dzvv8c=.6b4629e7-7fc0-487e-9c34-32216bcfb8c6@github.com>
References: <PaF492RmCm-Uc6UPj8EmPPYTcJDy-ZMj2CbuL2dnQOU=.c732bb39-cd9a-4ca7-b558-d3e15a405b24@github.com>
 <zDQ9DQXj6qgiY0yWof30AAchwCBfEmYlyozs0Dzvv8c=.6b4629e7-7fc0-487e-9c34-32216bcfb8c6@github.com>
Message-ID: <igreng-Cba1xuStrQ8Nr4RajOhyA2Uw9hmsVQVxICSQ=.d38d2e48-d54f-4372-9d46-d91453071487@github.com>

On Fri, 10 Jun 2022 01:24:48 GMT, Jeremy <duke at openjdk.org> wrote:

>> Previously when you drew a line that moved exactly (+0, +0) with a miter stroke the Stroker class acted like a horizontal miter was appropriate. Now we abort instead, so no miter is applied.
>> 
>> The new unit test tests the original steps plus several variations.
>> 
>> I'm a little nervous about this change because it looks like someone previously considered this exact condition and implemented a different behavior. I don't think I understand the original rationale.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8264999: GeneralPath.lineTo() to itself produces jagged lines
>   
>   Revising failing (commented out) scenarios.

@prrace please review this PR officially, LGTM

-------------

PR: https://git.openjdk.org/jdk/pull/8943


From psadhukhan at openjdk.org  Mon Jun 20 07:27:58 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 20 Jun 2022 07:27:58 GMT
Subject: RFR: 8288528: broken links in java.desktop [v3]
In-Reply-To: <DQEEJ4f35n7fzdijnAPdHHVEcEK5Q1357zacfWtnass=.264c65b1-5a49-4428-8423-a97756e1c762@github.com>
References: <FWD3xgIj5BMR-uu2hAyXutmEmlx1Jdm4pnxYk8V8MGQ=.99c6d315-6cd1-477f-a8f9-a40f14951e82@github.com>
 <DQEEJ4f35n7fzdijnAPdHHVEcEK5Q1357zacfWtnass=.264c65b1-5a49-4428-8423-a97756e1c762@github.com>
Message-ID: <1-NcjQOXsR0IHuVrxHjpfqdiLBHXp9ssvSfPuOleXIo=.0952c77d-f018-4ed3-92bb-6a6995fced8b@github.com>

On Mon, 20 Jun 2022 04:05:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> doccheck reports some broken links which are rectified
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary JBS links and fix EXIF link

will be done in jdk19 forked repo

-------------

PR: https://git.openjdk.org/jdk/pull/9195


From psadhukhan at openjdk.org  Mon Jun 20 07:27:59 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 20 Jun 2022 07:27:59 GMT
Subject: Withdrawn: 8288528: broken links in java.desktop
In-Reply-To: <FWD3xgIj5BMR-uu2hAyXutmEmlx1Jdm4pnxYk8V8MGQ=.99c6d315-6cd1-477f-a8f9-a40f14951e82@github.com>
References: <FWD3xgIj5BMR-uu2hAyXutmEmlx1Jdm4pnxYk8V8MGQ=.99c6d315-6cd1-477f-a8f9-a40f14951e82@github.com>
Message-ID: <J90J7DwQtoXw2iLcCCcgI53EdQ7t5mH1tWtD48tDsoE=.2896cacd-ec72-459e-bef7-261565f57dc2@github.com>

On Fri, 17 Jun 2022 03:45:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> doccheck reports some broken links which are rectified

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9195


From aturbanov at openjdk.org  Mon Jun 20 07:49:10 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 20 Jun 2022 07:49:10 GMT
Subject: RFR: 8284672: Collapse identical catch branches in java.desktop
 [v3]
In-Reply-To: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
References: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
Message-ID: <-AzjD2ev6x1CJaUfNMFJoIx5gOmScrTeUJ2S0R__pPs=.67e184af-b4bc-4df7-a183-d6e9d1edb493@github.com>

> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types".
> It simplifies code. Reduces duplication.
> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8284672: Collapse identical catch branches in java.desktop
  move '}' to new line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8154/files
  - new: https://git.openjdk.org/jdk/pull/8154/files/66906b3c..028be325

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8154&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8154&range=01-02

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8154.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8154/head:pull/8154

PR: https://git.openjdk.org/jdk/pull/8154


From serb at openjdk.org  Mon Jun 20 08:58:59 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 20 Jun 2022 08:58:59 GMT
Subject: RFR: 8284672: Collapse identical catch branches in java.desktop
 [v3]
In-Reply-To: <-AzjD2ev6x1CJaUfNMFJoIx5gOmScrTeUJ2S0R__pPs=.67e184af-b4bc-4df7-a183-d6e9d1edb493@github.com>
References: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
 <-AzjD2ev6x1CJaUfNMFJoIx5gOmScrTeUJ2S0R__pPs=.67e184af-b4bc-4df7-a183-d6e9d1edb493@github.com>
Message-ID: <43I_hviGD-_T4141Hub0IxVAmKz8zdHeTJlaiYC6Mwo=.adcb2b48-653c-44e4-9422-95cce688ed90@github.com>

On Mon, 20 Jun 2022 07:49:10 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types".
>> It simplifies code. Reduces duplication.
>> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284672: Collapse identical catch branches in java.desktop
>   move '}' to new line

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/8154


From serb at openjdk.org  Mon Jun 20 08:59:01 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 20 Jun 2022 08:59:01 GMT
Subject: RFR: 8284672: Collapse identical catch branches in java.desktop
 [v2]
In-Reply-To: <3yyPQ940zQYkL4VGtXL0Enmfsu7Qmx_ZNHX14oONnR4=.14cce160-3174-4ab5-8733-600af7f3d88a@github.com>
References: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
 <TLLG7XM4wV1Q7douly657vwd36dod5qUFMICnl7wpJc=.982c2ba7-cfed-43cb-a68d-4077b07bf4f7@github.com>
 <vcQO9naoHJ0HBmxS2bn8rSni0VWR8avPDSibJHtJ9KU=.4edcb92d-65f5-4090-8619-d01ebff6696a@github.com>
 <3yyPQ940zQYkL4VGtXL0Enmfsu7Qmx_ZNHX14oONnR4=.14cce160-3174-4ab5-8733-600af7f3d88a@github.com>
Message-ID: <STwwnbG4Un6_acEkOPoDaZpQgz_gE3qkYojuEZCx5Nk=.8f8e264d-d403-41b9-b99d-5f8a0923654a@github.com>

On Thu, 16 Jun 2022 17:30:21 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java line 120:
>> 
>>> 118:             try {
>>> 119:                 INSTANCE = new Metacity(themeName);
>>> 120:             } catch (FileNotFoundException ex) {
>> 
>> Is it possible that the FileNotFoundException was ignored intentionally? After this change, it will be traced.
>
> I didn't change how `FileNotFoundException` is handled. It's still ignored.

For some reason I thought it was merged to the IOException.

-------------

PR: https://git.openjdk.org/jdk/pull/8154


From serb at openjdk.org  Mon Jun 20 08:59:03 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 20 Jun 2022 08:59:03 GMT
Subject: RFR: 8284672: Collapse identical catch branches in java.desktop
 [v3]
In-Reply-To: <rJIwxLdsbgw_B8Y7mCiGbbF0JcuEKdliLLoLBv_mzuI=.00ed2391-fd8c-4538-903a-d4d81467774a@github.com>
References: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
 <sHkXMpkUXAG5rkkJnednTmISoY4Li2RNOFQcf6zytQ8=.1afdaf08-c759-4ef7-b11c-b63b3d983e04@github.com>
 <Qhm51ibMOoE-vKp1zECWtwEQhExJ5jQOQxtI1aEn6sA=.fa1de9e0-b7ce-4b05-ad49-38f036a6bbb0@github.com>
 <83f5TNNzytdB_O-gAmeG1o57YtzyN_uVBxqwl4P63mc=.1750e7f0-71a7-46e1-8bf4-f2ca63bd956d@github.com>
 <rJIwxLdsbgw_B8Y7mCiGbbF0JcuEKdliLLoLBv_mzuI=.00ed2391-fd8c-4538-903a-d4d81467774a@github.com>
Message-ID: <lXFQgWbRfMwVUMfg5Le3eV9G01NQw2N0ujwICtTaObU=.3f33e9d9-1459-474c-8c29-5f2d8c302b29@github.com>

On Fri, 17 Jun 2022 13:41:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This getSoundbank method is called when we iterate over providers and check which can be used, unfortunately, that code is not ready for the IOException and we return "null" -> the next provider will be checked. This is a kind of compatibility quirk.
>
> Doesn't IOException mean the next provider is to be checked?
> 
> That is the IOException could be handled in the iterator, its code may need to be updated for that. Then the implementations of `getSoundbank(URL)` could propagate the IOException too and eliminate duplicate code.
> 
> `InvalidMidiDataException` isn't caught there, so the iterator code should handle it.

It is implemented in a way that if the bundled provider will fail we will try some next provider, but if the user add custom provider then getSoundbank(URL) will throw IOException signalling that something went wrong.

I think InvalidMidiDataException should not be caught since that exception means the sound bank provider started to read the file, recognized that the file is supported, but then found the broken midi data.

-------------

PR: https://git.openjdk.org/jdk/pull/8154


From aturbanov at openjdk.org  Mon Jun 20 09:05:00 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 20 Jun 2022 09:05:00 GMT
Subject: RFR: 8284672: Collapse identical catch branches in java.desktop
 [v3]
In-Reply-To: <-AzjD2ev6x1CJaUfNMFJoIx5gOmScrTeUJ2S0R__pPs=.67e184af-b4bc-4df7-a183-d6e9d1edb493@github.com>
References: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
 <-AzjD2ev6x1CJaUfNMFJoIx5gOmScrTeUJ2S0R__pPs=.67e184af-b4bc-4df7-a183-d6e9d1edb493@github.com>
Message-ID: <zixQeOkFrYH6oGEA7_jUq2TeLu0FcCZxVJ3zVMIGn18=.3f28d73c-b81a-4740-b751-2c6832428c46@github.com>

On Mon, 20 Jun 2022 07:49:10 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types".
>> It simplifies code. Reduces duplication.
>> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284672: Collapse identical catch branches in java.desktop
>   move '}' to new line

Thank you for review!

-------------

PR: https://git.openjdk.org/jdk/pull/8154


From aturbanov at openjdk.org  Mon Jun 20 09:05:02 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 20 Jun 2022 09:05:02 GMT
Subject: Integrated: 8284672: Collapse identical catch branches in java.desktop
In-Reply-To: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
References: <Hn-N6jOAqYovweOuFVBMML-Px6xr4Htj-y-snkbcCxA=.937877f9-8125-42a6-8260-382dba3fc005@github.com>
Message-ID: <AWXzJPW6P1rXAadur01JyabnJId6eH18Lz6MWlX1d2s=.27f325e8-1eca-4ebc-b6a2-03fd520e2bf6@github.com>

On Fri, 8 Apr 2022 06:50:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types".
> It simplifies code. Reduces duplication.
> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement

This pull request has now been integrated.

Changeset: 695d8656
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/695d8656c5c6452b20d9d5a33ebb8f3d2f71c176
Stats:     299 lines in 45 files changed: 2 ins; 169 del; 128 mod

8284672: Collapse identical catch branches in java.desktop

Reviewed-by: prr, aivanov, serb

-------------

PR: https://git.openjdk.org/jdk/pull/8154


From serb at openjdk.org  Tue Jun 21 03:07:54 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 21 Jun 2022 03:07:54 GMT
Subject: RFR: 8282526: Default icon is not painted properly [v6]
In-Reply-To: <-lzCX_0sMzGt-MlBrMBLxJa75gvAurd6iEvdsZPi2KQ=.eff2c2c9-f097-428c-b1d7-6a751b451aef@github.com>
References: <gsYtdSPvj_BDFx4d9g5vrk-2Ly7QO9IpPfnGVFQfvFk=.483414d8-798d-41ea-a771-e074f5f91bbd@github.com>
 <Ynva90EcdSNf7EyAxZorJNsbqjqpYZjyggv2MOPlK10=.4478324f-75ac-4b52-9d6a-695dbae8f311@github.com>
 <7u-yUIx7WRWwfbART_dVbKunF3D9hQlfcxfpLcnZXDM=.f0d4713d-6e8e-4a67-bacd-87e6789544ea@github.com>
 <sremizdcaZgk3h7eYyJlL0LyspG_Onjs8vKPu9GUrUY=.9d1223a6-276a-4868-a4d7-c2953f95fc45@github.com>
 <5qvI6fcJT-VJOLp15wae5FuTUK9uRDvtR72I8nAalps=.83f92002-d669-439d-90c5-ad5c36143b0d@github.com>
 <-lzCX_0sMzGt-MlBrMBLxJa75gvAurd6iEvdsZPi2KQ=.eff2c2c9-f097-428c-b1d7-6a751b451aef@github.com>
Message-ID: <9zCJcmOcfXZtR31WIXTeHGbOpkGsNRHe6yE9_m9sJ1k=.3cd48e19-de98-4c54-a934-dfc4ad738bce@github.com>

On Tue, 14 Jun 2022 16:58:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> How would you implement this?
>>> I mean the user requests the icon in user's space (right?). On a High DPI system which may change in runtime, a larger icon version is required for rendering. To get a larger icon from native, we have to keep the file name or PIDL and call shell interfaces on COM thread to fetch the icon.
>>  > Overall, I like the idea? We may have discussed it. Keeping only sizes that are needed will reduce the memory usage. All in all, it's definitely out of scope for this fix.
>> 
>> That was the whole purpose of the initial 8182043 issue, to provide a HiDPI(or various DPI) icons for the user. If the user asks for the 16x16 we will provide them the MRI where the base image is 16x16, but that MRI could also provide large images by request. If that 16x16 image renders on scale=1.25 then the MRI should generate the image which looks good on that screen. This current proposal generates it on the fly using java code, but I think it should request that information from the native system, this was the purpose of the new getSystemIcon(file,w,w) method.
>> 
>> We do not need to always request the icon via COM thread, we can initially load the low dpi image, or the image for the main screen scale, then if the scale changed we can request to load the HiDPI image, and use it when ready.
>> 
>> The wondering why it looks bad on some DPI is actually proves that the previous fix has some limitations.
>
>> That was the whole purpose of the initial 8182043 issue, to provide a HiDPI(or various DPI) icons for the user. If the user asks for the 16x16 we will provide them the MRI where the base image is 16x16, but that MRI could also provide large images by request. If that 16x16 image renders on scale=1.25 then the MRI should generate the image which looks good on that screen.
> 
> [JDK-8182043](https://bugs.openjdk.org/browse/JDK-8182043) has enhanced support for High DPI, which can be confirmed by displaying a JFileChooser (in SwingSet2) and moving it from one monitor to another or changing the scale of a monitor where it's displayed.
> 
> Before JDK-8182043, the icon was either 16?16 or 32?32 and didn't change if the scale was changed. Now the icon gets updated after the scale changes, it's noticeable on folder icons in user's home because a set of icons is fetched.
> 
> There are still two different ways where icons are fetched from the Windows shell: `Java_sun_awt_shell_Win32ShellFolder2_getIcon` and `Java_sun_awt_shell_Win32ShellFolder2_extractIcon`. As @azuev-java notes, at times the returned size doesn't match the requested size.
> 
>> This current proposal generates it on the fly using java code, but I think it should request that information from the native system, this was the purpose of the new getSystemIcon(file,w,w) method.
> 
> This current proposal handles the situation where the returned icon doesn't have the requested size.
> 
> So, there are drawbacks and limitations in the current implementation, and there are opportunities to improve it, some of them are listed in [my comment above](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/7805*discussion_r893306463__;Iw!!ACWV5N9M2RV99hQ!NzvIlbxOBhjZnQ75rhWKdFBXZFBg4Sa1RzSEYg9-q2H8UiMEBrYPMgM3Qxz_SkurK05jp1Yr6lIAlbrlevXeSQ$ ). I shall submit them so that we don't forget about them, if no one else has already done it.
> 
>> We do not need to always request the icon via COM thread, we can initially load the low dpi image, or the image for the main screen scale, then if the scale changed we can request to load the HiDPI image, and use it when ready.
> 
> Why not? To request the icon of a larger size, the object which stores the icon should keep the reference to the file or folder, folders could have custom icons, and Documents, Downloads, Pictures are the examples of such folders. This must be done on COM thread because the icons are requested from the Windows shell.
> 
> 
> I agree that we should not get all possible resolutions of an icon when only one is needed. But it's out of scope of this particular issue.

> > That was the whole purpose of the initial 8182043 issue, to provide a HiDPI(or various DPI) icons for the user. If the user asks for the 16x16 we will provide them the MRI where the base image is 16x16, but that MRI could also provide large images by request. If that 16x16 image renders on scale=1.25 then the MRI should generate the image which looks good on that screen.

> Before JDK-8182043, the icon was either 16?16 or 32?32 and didn't change if the scale was changed. Now the icon gets updated after the scale changes, it's noticeable on folder icons in user's home because a set of icons is fetched.

Before the JDK-8182043 we also used the MRI so it should be changed if the scale was changed from low to hidpi. It adds more variants which could be used by some other DPI, I think one important new variant is the 64x64 because it used as a large icon on HiDPI monitor. But if the dpi is 125% or 150% it will not work even if the user will [try to request](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/2875*discussion_r641078169__;Iw!!ACWV5N9M2RV99hQ!NzvIlbxOBhjZnQ75rhWKdFBXZFBg4Sa1RzSEYg9-q2H8UiMEBrYPMgM3Qxz_SkurK05jp1Yr6lIAlbrgDZVFDQ$ ) such image.

> There are still two different ways where icons are fetched from the Windows shell: `Java_sun_awt_shell_Win32ShellFolder2_getIcon` and `Java_sun_awt_shell_Win32ShellFolder2_extractIcon`. As @azuev-java notes, at times the returned size doesn't match the requested size.

We had similar "issue" before the latest version of this change, we still have an issue related to the size value [initialization](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/7805*discussion_r887384908__;Iw!!ACWV5N9M2RV99hQ!NzvIlbxOBhjZnQ75rhWKdFBXZFBg4Sa1RzSEYg9-q2H8UiMEBrYPMgM3Qxz_SkurK05jp1Yr6lIAlbpBX68EEQ$ ). So it might be other our bug caused that the size is ignored.

> This current proposal handles the situation where the returned icon doesn't have the requested size.

Take a look to the description of 8182043, the user wanted to get some large Icon, now imaging he would like to get a 79x79 icon for some file, did we provide a way to do that? I assume we even do not try to request that size from the operation system so it actually cannot ignore our request? 

> So, there are drawbacks and limitations in the current implementation, and there are opportunities to improve it, some of them are listed in [my comment above](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/7805*discussion_r893306463__;Iw!!ACWV5N9M2RV99hQ!NzvIlbxOBhjZnQ75rhWKdFBXZFBg4Sa1RzSEYg9-q2H8UiMEBrYPMgM3Qxz_SkurK05jp1Yr6lIAlbrlevXeSQ$ ). I shall submit them so that we don't forget about them, if no one else has already done it.
+1

> Why not? To request the icon of a larger size, the object which stores the icon should keep the reference to the file or folder, folders could have custom icons, and Documents, Downloads, Pictures are the examples of such folders. This must be done on COM thread because the icons are requested from the Windows shell.

Because selection of the proper icon/image will be done during rendering of the component, and waiting of the results on the com thread may slowdown it. Instead we can use default image which we initially loaded, and later use the better one when it will be loaded on the com thread.

> I agree that we should not get all possible resolutions of an icon when only one is needed. But it's out of scope of this particular issue.

Yes, please take a look to these change.

-------------

PR: https://git.openjdk.org/jdk/pull/7805


From mkartashev at openjdk.org  Tue Jun 21 09:40:54 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Tue, 21 Jun 2022 09:40:54 GMT
Subject: RFR: 8288567: [macOS] NPE at
 sun.lwawt.macosx.CPlatformComponent.setBounds
In-Reply-To: <4OLkCQnPTmf6P-Iie09lahfeBynpAC0b2kfPU_vyW7g=.a6d729a3-2ae8-4050-94e0-d0e0559fdd70@github.com>
References: <4OLkCQnPTmf6P-Iie09lahfeBynpAC0b2kfPU_vyW7g=.a6d729a3-2ae8-4050-94e0-d0e0559fdd70@github.com>
Message-ID: <5QIO8fyzY7rjhHVX7BT7qJY1YnAptrJi2CLtM1hR5M8=.7b187bf2-dffd-419e-acd2-11fa9744ca53@github.com>

On Thu, 16 Jun 2022 11:30:01 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> Even though I have not been able to reproduce the crash by hand, the problem and the fix are fairly obvious: 
> `CWarningWindow` doesn't have a peer, so `platformWindow.getPeer()` can be null in that case. The fix is to accomodate for that in `CPlatformComponent.setBounds()`. Similar provisions exist elsewhere in the vicinity (for ex. `CPlatformLWWindow.setBounds()`, `CPlatformWindow.maximize()`, etc).

Perhaps my initial analysis about `CWarningWindow` is incorrect, but I can't seem to find any connection between that and `CPlatformComponent`. So maybe the culprit is actually outside of OpenJDK code...

-------------

PR: https://git.openjdk.org/jdk/pull/9184


From mkartashev at openjdk.org  Tue Jun 21 10:02:38 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Tue, 21 Jun 2022 10:02:38 GMT
Subject: Withdrawn: 8288567: [macOS] NPE at
 sun.lwawt.macosx.CPlatformComponent.setBounds
In-Reply-To: <4OLkCQnPTmf6P-Iie09lahfeBynpAC0b2kfPU_vyW7g=.a6d729a3-2ae8-4050-94e0-d0e0559fdd70@github.com>
References: <4OLkCQnPTmf6P-Iie09lahfeBynpAC0b2kfPU_vyW7g=.a6d729a3-2ae8-4050-94e0-d0e0559fdd70@github.com>
Message-ID: <My1-FsTp7G6fXkxRafMc484ce_QnI8GDQdTmsPvvb4I=.12192e5d-1e9c-43b0-bed2-33aac95c47db@github.com>

On Thu, 16 Jun 2022 11:30:01 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> Even though I have not been able to reproduce the crash by hand, the problem and the fix are fairly obvious: 
> `CWarningWindow` doesn't have a peer, so `platformWindow.getPeer()` can be null in that case. The fix is to accomodate for that in `CPlatformComponent.setBounds()`. Similar provisions exist elsewhere in the vicinity (for ex. `CPlatformLWWindow.setBounds()`, `CPlatformWindow.maximize()`, etc).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9184


From duke at openjdk.org  Tue Jun 21 13:50:43 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Tue, 21 Jun 2022 13:50:43 GMT
Subject: RFR: 8287609: macOS: SIGSEGV at [CoreFoundation] CFArrayGetCount /
 sun.font.CFont.getTableBytesNative
In-Reply-To: <ALhs4xV4daoPB_o150gAHH-e7B-e0_FC65Vyp_UpnbU=.3ce981ad-0ba7-4e48-a395-537b5b3cb971@github.com>
References: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
 <ALhs4xV4daoPB_o150gAHH-e7B-e0_FC65Vyp_UpnbU=.3ce981ad-0ba7-4e48-a395-537b5b3cb971@github.com>
Message-ID: <kktkPY9kkLzUBCsxDrqmeG-SZKrGuzk62lTbrZ-g-y4=.721bf719-d319-44ef-bf7e-d0bd0f4322d4@github.com>

On Sun, 5 Jun 2022 15:38:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> `CTFontCopyAvailableTables` can return null, which causes subsequent call to `CFArrayGetCount` to crash with SEGFAULT, just added a null-check.
>
> how do to backports is documented here : https://wiki.openjdk.java.net/display/SKARA/Backports
> but the wiki is down for maintenance so you'll need to wait for it to be back up to read it.

Hi @prrace! Bot says I cannot use `/backport` command because it doesn't recognize me as contributor, though I'm `/covered`. Can you help me with this, please?

-------------

PR: https://git.openjdk.org/jdk/pull/8962


From dnguyen at openjdk.org  Tue Jun 21 16:03:41 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 21 Jun 2022 16:03:41 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v19]
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <_IWVW43ER-fbUP4usPMeT71b87zgnR9pEXOPkpoMbHE=.a3e9f088-c7d4-47e5-8500-0a2d0c7641f6@github.com>

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Added final to instructions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7446/files
  - new: https://git.openjdk.org/jdk/pull/7446/files/69d093e7..061d2291

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7446&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7446&range=17-18

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/7446.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7446/head:pull/7446

PR: https://git.openjdk.org/jdk/pull/7446


From prr at openjdk.org  Tue Jun 21 18:28:13 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 Jun 2022 18:28:13 GMT
Subject: RFR: 8272998: ImageIO.read() throws incorrect exception type
In-Reply-To: <RCPQz7Uzpx-rTJqjcp4o0GsahxabKIw1-_VRO6NvLe0=.b6c6b8cf-b324-473a-b102-beb1e4ee6223@github.com>
References: <7P_RTUjGWttc7Wpknqa7CCPgNIssyX4xT--MjQ_R5po=.be6078e7-bb89-4b23-9b55-6d8fe93c70f6@github.com>
 <RCPQz7Uzpx-rTJqjcp4o0GsahxabKIw1-_VRO6NvLe0=.b6c6b8cf-b324-473a-b102-beb1e4ee6223@github.com>
Message-ID: <pyd50p5WqN6Dj0gtJsuo7PgCtdYVFqMIKpbMr7na97s=.c5c64abe-f7cd-498f-979a-221a56111887@github.com>

On Thu, 16 Jun 2022 03:29:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> ImageIO.read() only documents IOException for any kind of decoding problem and since
>> it is a convenience API we don't want to start requiring applications to handle other RuntimeExceptions.
>> So in the unlikely case of some problem decoding using this API, wrap any RuntimeException in
>> an IIOException. This will give more stable app behaviour and still report the underlying problem.
>
> src/java.desktop/share/classes/javax/imageio/ImageIO.java line 1467:
> 
>> 1465:         try (stream) {
>> 1466:             bi = reader.read(0, param);
>> 1467:         } catch (RuntimeException e) {
> 
> Is that necessary to catch all possible runtime exceptions? Probably we should catch only the exceptions thrown by the read method? I think it should be "IllegalArgumentException" only, the IllegalStateException/IndexOutOfBoundsException should not be thrown here, and the IOException is fine.

I did comment on this in the bug and the PR description.
Other exception types are possible or very difficult to prove they won't be thrown anprop if it ever did happen
we'd be back here. So this seems like the best to thing to do since we do not want to propagate them.

-------------

PR: https://git.openjdk.org/jdk/pull/9113


From prr at openjdk.org  Tue Jun 21 19:30:35 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 Jun 2022 19:30:35 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v19]
In-Reply-To: <_IWVW43ER-fbUP4usPMeT71b87zgnR9pEXOPkpoMbHE=.a3e9f088-c7d4-47e5-8500-0a2d0c7641f6@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <_IWVW43ER-fbUP4usPMeT71b87zgnR9pEXOPkpoMbHE=.a3e9f088-c7d4-47e5-8500-0a2d0c7641f6@github.com>
Message-ID: <Ma7Rip09RQTBvf_kg5OHluiC1BimcD858lXcsjxY0Vg=.8fef7eab-66cc-4baa-980b-05bbef576389@github.com>

On Tue, 21 Jun 2022 16:03:41 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added final to instructions.

You need to change the PR title to match the updated bug summary .. and wait for the CSR .. otherwise I think we are good now.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/7446


From prr at openjdk.org  Tue Jun 21 19:39:19 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 Jun 2022 19:39:19 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v19]
In-Reply-To: <_IWVW43ER-fbUP4usPMeT71b87zgnR9pEXOPkpoMbHE=.a3e9f088-c7d4-47e5-8500-0a2d0c7641f6@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <_IWVW43ER-fbUP4usPMeT71b87zgnR9pEXOPkpoMbHE=.a3e9f088-c7d4-47e5-8500-0a2d0c7641f6@github.com>
Message-ID: <qzrl48VRNxcqMnKitEv8mMraErIFHtKKsEg79z8sW_w=.bea82ae5-0b42-46a5-9968-1fafb9738707@github.com>

On Tue, 21 Jun 2022 16:03:41 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added final to instructions.

PS update the bug with an evaluation explaining the eventual solution and reasons,

-------------

PR: https://git.openjdk.org/jdk/pull/7446


From aivanov at openjdk.org  Tue Jun 21 19:39:22 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 21 Jun 2022 19:39:22 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v17]
In-Reply-To: <UWEwCbxVkvaYTTroDNZawN5xw4htZM4cPczsE5j-xXQ=.35ce4dea-15d6-484d-8b42-9069a49a579a@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <CDFbiFOSx0GkULnOIAEX8z0oNSPUNFJBpN4uhMbe9S4=.0ee7d88e-8d07-4b4d-a54c-43c86e8fdc95@github.com>
 <nzW2Sf86qP6N2YZv3DINZu0Ja5cX_cAg5aD_RotgQeU=.0f6abf97-f730-43a0-8630-d8a5d13fd40e@github.com>
 <UWEwCbxVkvaYTTroDNZawN5xw4htZM4cPczsE5j-xXQ=.35ce4dea-15d6-484d-8b42-9069a49a579a@github.com>
Message-ID: <mxWLrQ0Gcc4tvlAL-1judwpTX-ftAUs_DLeblg52TaQ=.b7e0d839-0fd9-4828-a887-2fcd16f0f35f@github.com>

On Fri, 17 Jun 2022 17:37:59 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1312:
>> 
>>> 1310:      *         <li>Tags display the tag text as editable text fields.</li>
>>> 1311:      *         <li>The content within the tags will be handled by the editor as
>>> 1312:      *         regular text.</li>
>> 
>> This is not how `<script>` is handled though: the content is displayed in a text field. The text in the unknown tag is displayed directly.
>> 
>> The content of `<script>` tag is handled as if it's a comment.
>> <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/ae2504b4692a5298b5835727b04a44e1edc8a4d6/src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java*L2176-L2177__;Iw!!ACWV5N9M2RV99hQ!NqsGchdsnHguT_YueWoIeXjM3AHFK0ubKRMdbIILDs_HFu0N7un0tnC0AlP9eVfP8RPOcwStlGK95a8lrFX339v9mg$">https://github.com/openjdk/jdk/blob/ae2504b4692a5298b5835727b04a44e1edc8a4d6/src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java#L2176-L2177</a>
>
> I tried to cover this in earlier commits where I differentiate known but unsupported tags, such as script tags, and completely unknown tags. In conversation and testing, HTMLEditorKit.HTMLFactory has a create method that creates HiddenTagViews for unknown tags and for a small list of tags (title, script, param, etc.). In the end, these are all treated the same, so I grouped script tags in this javadoc change. Script tags do have a special case in the Parser where it is handled as a comment but being handled as a comment doesn't change the behavior and still displays the content.

Comments are rendered in a `JTextArea`, that's the only difference. It's covered in the test.

Adding these details could be overkill.

-------------

PR: https://git.openjdk.org/jdk/pull/7446


From dnguyen at openjdk.org  Tue Jun 21 20:02:44 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 21 Jun 2022 20:02:44 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v17]
In-Reply-To: <mxWLrQ0Gcc4tvlAL-1judwpTX-ftAUs_DLeblg52TaQ=.b7e0d839-0fd9-4828-a887-2fcd16f0f35f@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <CDFbiFOSx0GkULnOIAEX8z0oNSPUNFJBpN4uhMbe9S4=.0ee7d88e-8d07-4b4d-a54c-43c86e8fdc95@github.com>
 <nzW2Sf86qP6N2YZv3DINZu0Ja5cX_cAg5aD_RotgQeU=.0f6abf97-f730-43a0-8630-d8a5d13fd40e@github.com>
 <UWEwCbxVkvaYTTroDNZawN5xw4htZM4cPczsE5j-xXQ=.35ce4dea-15d6-484d-8b42-9069a49a579a@github.com>
 <mxWLrQ0Gcc4tvlAL-1judwpTX-ftAUs_DLeblg52TaQ=.b7e0d839-0fd9-4828-a887-2fcd16f0f35f@github.com>
Message-ID: <i2v6zBBzFhymJHm_nSrGD9BJ1PlfuG9UhiAstQs6psg=.577c8d08-79ff-4eea-a618-3f8c7eacda78@github.com>

On Tue, 21 Jun 2022 19:36:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I tried to cover this in earlier commits where I differentiate known but unsupported tags, such as script tags, and completely unknown tags. In conversation and testing, HTMLEditorKit.HTMLFactory has a create method that creates HiddenTagViews for unknown tags and for a small list of tags (title, script, param, etc.). In the end, these are all treated the same, so I grouped script tags in this javadoc change. Script tags do have a special case in the Parser where it is handled as a comment but being handled as a comment doesn't change the behavior and still displays the content.
>
> Comments are rendered in a `JTextArea`, that's the only difference. It's covered in the test.
> 
> Adding these details could be overkill.

I thought the same about the additional details being overkill, so I decided to write it the way I did. I could add the details about script tags specifically being handled as a comment, but I believe the current text describes it sufficiently. Let me know what you think.

-------------

PR: https://git.openjdk.org/jdk/pull/7446


From dnguyen at openjdk.org  Tue Jun 21 20:02:45 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 21 Jun 2022 20:02:45 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v18]
In-Reply-To: <5QfPtHRSQMtgCQ7yT6HlbI1VRvqIHJtCwY9Lie85wpo=.90d5886b-7e60-4360-980f-ebf4785c6d85@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <dmLKo1wO-sdzVIfYIkXfikI3sifzc9TTWLuLuOVHvKA=.adc59e08-890d-47cf-b5a9-089a8cdb49be@github.com>
 <5QfPtHRSQMtgCQ7yT6HlbI1VRvqIHJtCwY9Lie85wpo=.90d5886b-7e60-4360-980f-ebf4785c6d85@github.com>
Message-ID: <Z6mDh35GbuxdZyT9G2Qxxd_wfQLirDDhzLq6mGBjNeU=.6877c589-2f6a-4747-8205-705760ea892f@github.com>

On Fri, 17 Jun 2022 21:02:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarified javadoc.
>
> test/jdk/javax/swing/text/html/HtmlScriptTagParserTest.java line 43:
> 
>> 41: 
>> 42: public class HtmlScriptTagParserTest {
>> 43:     private static String instructionsText = "Pass if you can see the script " +
> 
> May I suggest adding `final` to instructions too?

Done

-------------

PR: https://git.openjdk.org/jdk/pull/7446


From prr at openjdk.org  Tue Jun 21 20:34:35 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 Jun 2022 20:34:35 GMT
Subject: RFR: 8012675: Javadoc for
 javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v17]
In-Reply-To: <i2v6zBBzFhymJHm_nSrGD9BJ1PlfuG9UhiAstQs6psg=.577c8d08-79ff-4eea-a618-3f8c7eacda78@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
 <CDFbiFOSx0GkULnOIAEX8z0oNSPUNFJBpN4uhMbe9S4=.0ee7d88e-8d07-4b4d-a54c-43c86e8fdc95@github.com>
 <nzW2Sf86qP6N2YZv3DINZu0Ja5cX_cAg5aD_RotgQeU=.0f6abf97-f730-43a0-8630-d8a5d13fd40e@github.com>
 <UWEwCbxVkvaYTTroDNZawN5xw4htZM4cPczsE5j-xXQ=.35ce4dea-15d6-484d-8b42-9069a49a579a@github.com>
 <mxWLrQ0Gcc4tvlAL-1judwpTX-ftAUs_DLeblg52TaQ=.b7e0d839-0fd9-4828-a887-2fcd16f0f35f@github.com>
 <i2v6zBBzFhymJHm_nSrGD9BJ1PlfuG9UhiAstQs6psg=.577c8d08-79ff-4eea-a618-3f8c7eacda78@github.com>
Message-ID: <__WBi0Aq50Qw6FRfYJpwIanBl6pSPTCU-csJUJ66yK8=.0f698d90-3693-4969-9006-00f2b2180dbf@github.com>

On Tue, 21 Jun 2022 19:57:41 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Comments are rendered in a `JTextArea`, that's the only difference. It's covered in the test.
>> 
>> Adding these details could be overkill.
>
> I thought the same about the additional details being overkill, so I decided to write it the way I did. I could add the details about script tags specifically being handled as a comment, but I believe the current text describes it sufficiently. Let me know what you think.

I don't think we need to say it is a JTextArea or a JTextField or whatever.

-------------

PR: https://git.openjdk.org/jdk/pull/7446


From psadhukhan at openjdk.org  Wed Jun 22 03:37:15 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 22 Jun 2022 03:37:15 GMT
Subject: RFR: 8267374: (macos) Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea
Message-ID: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>

Unlike in native "Notes" editor where Option+Up/Down traverses to start/end of each line respectively,
Java does not honour these key combination in editor.

Added the key combination support by moving the caret to start/end of line and then doing caret up/down a line depending on if we are pressing UP or DOWN key.

-------------

Commit messages:
 - Fix
 - Fix

Changes: https://git.openjdk.org/jdk/pull/9230/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9230&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8267374
  Stats: 347 lines in 3 files changed: 347 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9230/head:pull/9230

PR: https://git.openjdk.org/jdk/pull/9230


From serb at openjdk.org  Wed Jun 22 06:27:02 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 22 Jun 2022 06:27:02 GMT
Subject: RFR: 8267374: (macos) Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea
In-Reply-To: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
Message-ID: <rxdHQ-zL-lTLJ7WFY2Q-XbViGbJrcy6WXVE4Sh9QpjE=.3c4110f5-e4e0-42aa-9a76-7d134e8e6ce1@github.com>

On Wed, 22 Jun 2022 03:28:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Unlike in native "Notes" editor where Option+Up/Down traverses to start/end of each line respectively,
> Java does not honour these key combination in editor.
> 
> Added the key combination support by moving the caret to start/end of line and then doing caret up/down a line depending on if we are pressing UP or DOWN key.

Is it possible that the submitter tested the right option key? I think it stopped working somewhere after jdk8 as described in the JBS.

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From serb at openjdk.org  Wed Jun 22 06:30:53 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 22 Jun 2022 06:30:53 GMT
Subject: RFR: 8267374: (macos) Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea
In-Reply-To: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
Message-ID: <hJz6nUy4--a0lxenU2rEiMSgFnCA77lJWZvpd4EdokQ=.9efeb730-ac8f-479f-965d-74104d943439@github.com>

On Wed, 22 Jun 2022 03:28:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Unlike in native "Notes" editor where Option+Up/Down traverses to start/end of each line respectively,
> Java does not honour these key combination in editor.
> 
> Added the key combination support by moving the caret to start/end of line and then doing caret up/down a line depending on if we are pressing UP or DOWN key.

src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java line 648:

> 646:      * Name of the <code>Action</code> for moving the caret
> 647:      * to the end of a line and logically upward one position.
> 648:      * @see #getActions

Tested the native behavior in XCode and it seems that this shortcut moves the cursor to the end if not at the end already or one line down otherwise.

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From psadhukhan at openjdk.org  Wed Jun 22 06:59:29 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 22 Jun 2022 06:59:29 GMT
Subject: RFR: 8267374: (macos) Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v2]
In-Reply-To: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
Message-ID: <ewAinit1TMvgDsMvfRc_viIM_ohFxHdjsQ9ZpuCOMoQ=.9c4fbfb8-7a44-4f02-9d63-c2303f940856@github.com>

> Unlike in native "Notes" editor where Option+Up/Down traverses to start/end of each line respectively,
> Java does not honour these key combination in editor.
> 
> Added the key combination support by moving the caret to start/end of line and then doing caret up/down a line depending on if we are pressing UP or DOWN key.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9230/files
  - new: https://git.openjdk.org/jdk/pull/9230/files/95d2ff04..2b523c29

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9230&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9230&range=00-01

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9230/head:pull/9230

PR: https://git.openjdk.org/jdk/pull/9230


From psadhukhan at openjdk.org  Wed Jun 22 06:59:30 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 22 Jun 2022 06:59:30 GMT
Subject: RFR: 8267374: (macos) Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea
In-Reply-To: <rxdHQ-zL-lTLJ7WFY2Q-XbViGbJrcy6WXVE4Sh9QpjE=.3c4110f5-e4e0-42aa-9a76-7d134e8e6ce1@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <rxdHQ-zL-lTLJ7WFY2Q-XbViGbJrcy6WXVE4Sh9QpjE=.3c4110f5-e4e0-42aa-9a76-7d134e8e6ce1@github.com>
Message-ID: <2dwKHgzSR1BLddkqZl2vajQEJB-bhb8woq-hhD4ddTE=.d46af140-f07d-47ee-a2b3-b34c473b9775@github.com>

On Wed, 22 Jun 2022 06:22:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Is it possible that the submitter tested the right option key? I think it stopped working somewhere after jdk8 as described in the JBS.

Right option key does not work at all...Left option key worked for left-right but not for up-down..this PR addresses that left option key up/down issue..

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From psadhukhan at openjdk.org  Wed Jun 22 06:59:30 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 22 Jun 2022 06:59:30 GMT
Subject: RFR: 8267374: (macos) Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v2]
In-Reply-To: <hJz6nUy4--a0lxenU2rEiMSgFnCA77lJWZvpd4EdokQ=.9efeb730-ac8f-479f-965d-74104d943439@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <hJz6nUy4--a0lxenU2rEiMSgFnCA77lJWZvpd4EdokQ=.9efeb730-ac8f-479f-965d-74104d943439@github.com>
Message-ID: <ejvD9ayKVO2qM0Qwy_7vAeAmEFpod-xBZDdGlOe4REE=.8f5c3ba7-2b77-4f15-8962-28d41a1b3dea@github.com>

On Wed, 22 Jun 2022 06:27:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix javadoc
>
> src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java line 648:
> 
>> 646:      * Name of the <code>Action</code> for moving the caret
>> 647:      * to the end of a line and logically upward one position.
>> 648:      * @see #getActions
> 
> Tested the native behavior in XCode and it seems that this shortcut moves the cursor to the end if not at the end already or one line down otherwise.

The code does that only...javadoc was wrong..fixed that

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From aivanov at openjdk.org  Wed Jun 22 09:51:41 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 22 Jun 2022 09:51:41 GMT
Subject: RFR: 8272998: ImageIO.read() throws incorrect exception type
In-Reply-To: <7P_RTUjGWttc7Wpknqa7CCPgNIssyX4xT--MjQ_R5po=.be6078e7-bb89-4b23-9b55-6d8fe93c70f6@github.com>
References: <7P_RTUjGWttc7Wpknqa7CCPgNIssyX4xT--MjQ_R5po=.be6078e7-bb89-4b23-9b55-6d8fe93c70f6@github.com>
Message-ID: <ddu_Vz9UMd71_J6IGXmDFNOMUaRxsQoivPcPXQw-8MI=.406bdbbf-f8cc-4ebc-aaf0-06308249b60d@github.com>

On Thu, 9 Jun 2022 19:53:22 GMT, Phil Race <prr at openjdk.org> wrote:

> ImageIO.read() only documents IOException for any kind of decoding problem and since
> it is a convenience API we don't want to start requiring applications to handle other RuntimeExceptions.
> So in the unlikely case of some problem decoding using this API, wrap any RuntimeException in
> an IIOException. This will give more stable app behaviour and still report the underlying problem.

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9113


From aivanov at openjdk.org  Wed Jun 22 09:58:55 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 22 Jun 2022 09:58:55 GMT
Subject: RFR: 8287609: macOS: SIGSEGV at [CoreFoundation] CFArrayGetCount /
 sun.font.CFont.getTableBytesNative
In-Reply-To: <ALhs4xV4daoPB_o150gAHH-e7B-e0_FC65Vyp_UpnbU=.3ce981ad-0ba7-4e48-a395-537b5b3cb971@github.com>
References: <defHaUTl3hgK9Dw_CtFZwPAgHAl_dkDZZ3_2xOBoKwo=.6ee11742-2b04-47d2-9c62-62d93e58bae3@github.com>
 <ALhs4xV4daoPB_o150gAHH-e7B-e0_FC65Vyp_UpnbU=.3ce981ad-0ba7-4e48-a395-537b5b3cb971@github.com>
Message-ID: <szB5aJo-D8vATahgSnbpRebBA8mHvKKmXUYQFvec_As=.df7df1b1-4831-4e47-b8a2-7fa1db13f539@github.com>

On Sun, 5 Jun 2022 15:38:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> `CTFontCopyAvailableTables` can return null, which causes subsequent call to `CFArrayGetCount` to crash with SEGFAULT, just added a null-check.
>
> how do to backports is documented here : https://wiki.openjdk.java.net/display/SKARA/Backports
> but the wiki is down for maintenance so you'll need to wait for it to be back up to read it.

> Hi @prrace! Bot says I cannot use `/backport` command because it doesn't recognize me as contributor, though I'm `/covered`. Can you help me with this, please?

You can create a backport PR as regular one: create a branch in your fork of jdk18u, apply the changeset, commit and push the branch. Now create a PR with the title *Backport `<commit-hash>`* where `commit-hash` is the hash of the commit you're backporting, which is `8c460b043e1cbaf1f2d74958033bb24dea66a390` in this case.

-------------

PR: https://git.openjdk.org/jdk/pull/8962


From smandalika at openjdk.org  Wed Jun 22 11:42:06 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Wed, 22 Jun 2022 11:42:06 GMT
Subject: RFR: 8284767: Create an automated test for JDK-4422535 [v4]
In-Reply-To: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
References: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
Message-ID: <KH__xA99ahmnlQwY5RPRMOWEsyFWHdntBOReEF5yJI0=.a25359d0-a7da-47c6-b127-30a355a87bbf@github.com>

> Create an automated test for [JDK-4422535](https://bugs.openjdk.java.net/browse/JDK-4422535)
> AccessibleValue implementation only accept Integers
> The AccessibleValue implementations of the following components:
> 
> java.awt.Scrollbar
> javax.swing.AbstractButton
> javax.swing.JInternalFrame
> javax.swing.JSplitPane
> javax.swing.JScrollBar
> javax.swing.JProgressBar
> javax.swing.JSlider
> 
> require the argument to setCurrentAccessibleValue(Number) to be an Integer, else they completely ignore it - it returns a false indicating that the value has not been set by the return value, but they cannot know the reason for that).
> 
> The test verifies that for each of the above components, the AccessibleValue is set when it is set to a Number (Float, Double, long etc) and not just for an Integer.
> 
> his review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

Srinivas Mandalika 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 six additional commits since the last revision:

 - Merge branch 'openjdk:master' into 8284767
 - Review comment fixed: removed redundant headful tag
 - Review Comments Fixed: Fixed File location path.
 - Review Comments Fixed: Simplified test code with a loop over the JComponents being tested.
 - 8284767: Create an automated test for JDK-4422535
 - 8284767: Create an automated test for JDK-4422535

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8220/files
  - new: https://git.openjdk.org/jdk/pull/8220/files/4a57e660..258971c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8220&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8220&range=02-03

  Stats: 393040 lines in 5701 files changed: 260846 ins; 98299 del; 33895 mod
  Patch: https://git.openjdk.org/jdk/pull/8220.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8220/head:pull/8220

PR: https://git.openjdk.org/jdk/pull/8220


From smandalika at openjdk.org  Wed Jun 22 12:43:58 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Wed, 22 Jun 2022 12:43:58 GMT
Subject: RFR: 8284767: Create an automated test for JDK-4422535 [v3]
In-Reply-To: <1aHb4tDmlGR37mVahrlvOIgaW3aCDKSYDd5JSEnx3T4=.6c7014c3-340a-4364-9bda-78c32c55ec9d@github.com>
References: <iWC939OdQdtwd4aHn2SafTsP1e1knRWsxNCzKos1Cts=.e7b80f3f-8fb2-41a1-af41-0e31131d756e@github.com>
 <3rXFVh7JvLK-ycYNRlmK8tTqTpmrs7GuF0lxiaO78kQ=.9f972f36-f57f-4cf1-a2d8-58feba441f71@github.com>
 <1aHb4tDmlGR37mVahrlvOIgaW3aCDKSYDd5JSEnx3T4=.6c7014c3-340a-4364-9bda-78c32c55ec9d@github.com>
Message-ID: <JrhhZDQPXLhYGbJEDT6UGdYvq_aDpr0Nm_X8GmXHetU=.98de3421-3272-4570-b313-10dcadd71a48@github.com>

On Thu, 16 Jun 2022 03:39:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review Comments Fixed: Fixed File location path.
>
> test/jdk/javax/accessibility/SetCurrentAccessibleValueTest.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @key headful
> 
> Do we need a headful tag here?

Removed the unwanted headful tag.

-------------

PR: https://git.openjdk.org/jdk/pull/8220


From smandalika at openjdk.org  Wed Jun 22 12:52:42 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Wed, 22 Jun 2022 12:52:42 GMT
Subject: RFR: 8284524: Create an automated test for JDK-4422362 [v4]
In-Reply-To: <Zc6TLIeUCxotLqICjVkZF4g1hUTkdB7mANhMull6Qzc=.14959182-424c-42f6-979f-7d6eeb266dfb@github.com>
References: <Zc6TLIeUCxotLqICjVkZF4g1hUTkdB7mANhMull6Qzc=.14959182-424c-42f6-979f-7d6eeb266dfb@github.com>
Message-ID: <EfLbsgzAFfa1C6hJQk6eYRhgzu0Id9ogetzOckJJBe8=.d8bee794-753e-4ebc-b86f-24defaf1a012@github.com>

> Create an automated test for [JDK-4422362](https://bugs.openjdk.java.net/browse/JDK-4422362)
> 
> The BoundedRangeModel components (JScrollBar, JSlider, JProgressBar) return
> BoundedRangeModel.getMaximum() from getMaximumAccessibleValue() in their
> AccessibleValue implementation.
> The real maximum value (due to the constraints on BoundedRangeModel) is
> model.getMaximum() - model.getExtent().
> 
> The test verifies that the above is adhered to as expected.
> 
> This review is for migrating tests from a closed test suite to open.
> 
> Testing:
> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64.

Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:

  Review comment fixed: removed redundant headful tag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8158/files
  - new: https://git.openjdk.org/jdk/pull/8158/files/33d7b2b3..3b953b77

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8158&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8158&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/8158.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8158/head:pull/8158

PR: https://git.openjdk.org/jdk/pull/8158


From smandalika at openjdk.org  Wed Jun 22 12:52:43 2022
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Wed, 22 Jun 2022 12:52:43 GMT
Subject: RFR: 8284524: Create an automated test for JDK-4422362 [v3]
In-Reply-To: <NhnYtGGuSQvk6NX7XfRdHOAGpIG4z2E4oP8hAe3AK8I=.26b4cb7d-3af8-4ee5-9423-5674dff234de@github.com>
References: <Zc6TLIeUCxotLqICjVkZF4g1hUTkdB7mANhMull6Qzc=.14959182-424c-42f6-979f-7d6eeb266dfb@github.com>
 <ASMCKuK4Ur54E_sI13yc-5J9BZlH8thmHe5a8fWwxYI=.6160ccaf-36b9-4838-bb6a-a845840fc5d8@github.com>
 <NhnYtGGuSQvk6NX7XfRdHOAGpIG4z2E4oP8hAe3AK8I=.26b4cb7d-3af8-4ee5-9423-5674dff234de@github.com>
Message-ID: <iuVjHdKtxGXuwqQn1DDpALilKlBUCQPp7LhXcaOc1Ew=.2eeb986c-9d9e-49b1-9a2d-c58164c0871d@github.com>

On Thu, 16 Jun 2022 03:38:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review Comments Fixed: Fixed File location path.
>
> test/jdk/javax/accessibility/MaximumAccessibleValueTest.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @key headful
> 
> I think the headful tag is not needed in this test, please check.

Removed the unwanted headful tag.

-------------

PR: https://git.openjdk.org/jdk/pull/8158


From mvs at openjdk.org  Wed Jun 22 13:19:45 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 22 Jun 2022 13:19:45 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v2]
In-Reply-To: <07vES8jtHcWypuL2HBv-ryMPrVDe0ti0mU_bVRdlzrk=.21082c4e-f4a3-434e-9584-05d0bc6c6c85@github.com>
References: <pClI2zW5gi4TBiMW2CeftBlBN_p5Z7KWF4fpeVZqtlg=.e332bcae-1242-4227-8804-9ae8f0576381@github.com>
 <07vES8jtHcWypuL2HBv-ryMPrVDe0ti0mU_bVRdlzrk=.21082c4e-f4a3-434e-9584-05d0bc6c6c85@github.com>
Message-ID: <HBVuy7KnV7Udnmftr1oMCwfLLOj6kW_poZo9y3LyTlw=.a79ae2e6-098d-4292-9b0d-851ebb1879c3@github.com>

On Fri, 17 Jun 2022 10:57:59 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines. It seems to be a testbug as adding some stability improvements fix the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. I have removed the problem listing and tested it in windows platform also, it works fine there.
>> 
>> Fix:
>> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Removed -Dsun.java2d.uiScale=1, frame.getLocationOnScreen() removed from EDT, added volatile keyword for actionEventReceivedLatch

Any volunteers?

-------------

PR: https://git.openjdk.org/jdk/pull/9187


From mvs at openjdk.org  Wed Jun 22 13:19:52 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 22 Jun 2022 13:19:52 GMT
Subject: RFR: 8288428: javax/swing/JInternalFrame/Test6505027.java fails
 frequently in MacOS 12 machines
In-Reply-To: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
References: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
Message-ID: <-nMY9M43HIwi-hzDW4AaeFsFfEzCEhcp7nIIRSm5BJw=.078f2cd6-5ede-418d-8c6d-02f4510c6a84@github.com>

On Fri, 17 Jun 2022 14:28:15 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> javax/swing/JInternalFrame/Test6505027.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines and it fails intermittently in CI causing some noise.
> It seems to be a testbug as adding some stability improvements fix the issue.
> 
> Fix:
> Some stability improvements have been done and the test has been run 10 times per platform in mach5 and got full PASS.

Any volunteers?

-------------

PR: https://git.openjdk.org/jdk/pull/9202


From honkar at openjdk.org  Wed Jun 22 18:54:21 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 22 Jun 2022 18:54:21 GMT
Subject: RFR: 8265586: [windows] last button is not shown in AWT Frame with
 BorderLayout and MenuBar set. [v3]
In-Reply-To: <bBQAPmU1302HS351T6fqTeiCOFxLlKEObIg932u-nXU=.e03a4aa9-60ff-4399-a248-9038e8dbd41a@github.com>
References: <8d1cbCMZbRzhwEV4JF1V3nY2lUjgjYbW9cVY2sl8J1A=.aaeef766-d265-45c5-9982-2e4a31428d4a@github.com>
 <1fTMFRhq0ez161rADVVkXu_gyEr_gh_AeE17afFPE2Q=.19d7a1d0-d3fd-4dee-bee6-f8e4c07e0651@github.com>
 <bBQAPmU1302HS351T6fqTeiCOFxLlKEObIg932u-nXU=.e03a4aa9-60ff-4399-a248-9038e8dbd41a@github.com>
Message-ID: <X3WHIL6Qym5HRAqxQzkligC0b1pOaDjnzUoPdIqGWJ4=.332f1f25-b29f-4aa0-9222-21c9b7eaa5f4@github.com>

On Wed, 15 Jun 2022 05:37:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor changes
>
> test/jdk/java/awt/Frame/AwtFramePackTest.java line 42:
> 
>> 40:  * @bug 8265586
>> 41:  * @key headful
>> 42:  * @requires (os.family == "windows")
> 
> Any reason why the test is windows specific? It does not have the platform specific code.

@mrserb Since the PR was already integrated before the review suggestion was made to make the test generic, a new PR has been created to remove the `@requires` tag from the test. 

PR link: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9248__;!!ACWV5N9M2RV99hQ!MFn79i-DER0pt7vktu0YuA2JXKunu0coHlgVa2zAlCcpScyA7dyomdf_7YO2iKvexwrEpQkRtThzZWRSkDjQa9T5$ 
JBS bug: https://bugs.openjdk.org/browse/JDK-8288993

-------------

PR: https://git.openjdk.org/jdk/pull/9118


From honkar at openjdk.org  Wed Jun 22 18:59:21 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 22 Jun 2022 18:59:21 GMT
Subject: RFR: JDK-8288993: Make AwtFramePackTest generic by removing @requires
 tag
Message-ID: <r5HklzGTf9N2fzKgd1sQDObs44rRLp8_iVU7gkOXrLE=.a6c2ceb3-8ec2-4438-9eb8-fc475f27c56b@github.com>

The following test was changed to generic based on this [Review Comment](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9118*discussion_r897553780__;Iw!!ACWV5N9M2RV99hQ!Lvy6J9KfgCVA-2ID-oLD9YoyDyMh8Q_Go0rcyfxSVvBfdnsqtHuQV6n-qliRfxxnFGqCpYw6GNVsyMavk4WIGyE0$ ) and as the condition `frame.getSize() == frame.getPreferredSize() ` should hold on all platforms when frame.pack() is used.

-------------

Commit messages:
 - removed @requires tag

Changes: https://git.openjdk.org/jdk/pull/9248/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9248&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288993
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9248.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9248/head:pull/9248

PR: https://git.openjdk.org/jdk/pull/9248


From dmarkov at openjdk.org  Wed Jun 22 21:03:45 2022
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Wed, 22 Jun 2022 21:03:45 GMT
Subject: RFR: JDK-8288993: Make AwtFramePackTest generic by removing
 @requires tag
In-Reply-To: <r5HklzGTf9N2fzKgd1sQDObs44rRLp8_iVU7gkOXrLE=.a6c2ceb3-8ec2-4438-9eb8-fc475f27c56b@github.com>
References: <r5HklzGTf9N2fzKgd1sQDObs44rRLp8_iVU7gkOXrLE=.a6c2ceb3-8ec2-4438-9eb8-fc475f27c56b@github.com>
Message-ID: <HpOxqyL3BPJ4bRj31RpHgQIH-c_EXitHOTpR31-0jYg=.449935f9-3a5f-44da-81ed-60ea8c6b7ca2@github.com>

On Wed, 22 Jun 2022 18:50:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> The following test was changed to generic based on this [Review Comment](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9118*discussion_r897553780__;Iw!!ACWV5N9M2RV99hQ!NlZ2-nOkKDwGHMiGS-ZHpyHhmwMZwxkM78nsrp6k-TSMCrxiOt96BQ5v50VqAVY34Pd4N9c18FdfLlZ5J_DOFzFcHA$ ) and as the condition `frame.getSize() == frame.getPreferredSize() ` should hold on all platforms when frame.pack() is used.

Marked as reviewed by dmarkov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9248


From honkar at openjdk.org  Thu Jun 23 01:19:52 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 23 Jun 2022 01:19:52 GMT
Subject: RFR: JDK-8288993: Make AwtFramePackTest generic by removing
 @requires tag
In-Reply-To: <HpOxqyL3BPJ4bRj31RpHgQIH-c_EXitHOTpR31-0jYg=.449935f9-3a5f-44da-81ed-60ea8c6b7ca2@github.com>
References: <r5HklzGTf9N2fzKgd1sQDObs44rRLp8_iVU7gkOXrLE=.a6c2ceb3-8ec2-4438-9eb8-fc475f27c56b@github.com>
 <HpOxqyL3BPJ4bRj31RpHgQIH-c_EXitHOTpR31-0jYg=.449935f9-3a5f-44da-81ed-60ea8c6b7ca2@github.com>
Message-ID: <xt6wjnuI4puIlkh3XEfa7HSn9Uwp4VK6k7-2xUQXJ7U=.88343acd-a713-4cb1-ba9f-887d50f9992b@github.com>

On Wed, 22 Jun 2022 21:00:30 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> The following test was changed to generic based on this [Review Comment](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9118*discussion_r897553780__;Iw!!ACWV5N9M2RV99hQ!JumRvVf_p_sqpLDLCzx73muB4YOAryoWk4sWfo9E-H_wPUkRdMXSetD9xXDnD4xO3b14bxul0afwt0g0EMo86pTN$ ) and as the condition `frame.getSize() == frame.getPreferredSize() ` should hold on all platforms when frame.pack() is used.
>
> Marked as reviewed by dmarkov (Reviewer).

@dmarkov20 Thank you for reviewing.

-------------

PR: https://git.openjdk.org/jdk/pull/9248


From honkar at openjdk.org  Thu Jun 23 01:23:56 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 23 Jun 2022 01:23:56 GMT
Subject: RFR: JDK-8288993: Make AwtFramePackTest generic by removing
 @requires tag
In-Reply-To: <r5HklzGTf9N2fzKgd1sQDObs44rRLp8_iVU7gkOXrLE=.a6c2ceb3-8ec2-4438-9eb8-fc475f27c56b@github.com>
References: <r5HklzGTf9N2fzKgd1sQDObs44rRLp8_iVU7gkOXrLE=.a6c2ceb3-8ec2-4438-9eb8-fc475f27c56b@github.com>
Message-ID: <fRm397r7P86doXJgpb1UbZvxbO6YRwHKMHi-feSR258=.bbada845-2bdb-45ac-ae9f-b8dc9ee08299@github.com>

On Wed, 22 Jun 2022 18:50:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> The following test was changed to generic based on this [Review Comment](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9118*discussion_r897553780__;Iw!!ACWV5N9M2RV99hQ!OeF8K62SHfgLypmQHAuA1ZOTU2Iov7vUmm6SGGwCpt1ghTntSWf2gpN3pceBSNLYHtxgkCN5WcaojrlABQMsg0I8$ ) and as the condition `frame.getSize() == frame.getPreferredSize() ` should hold on all platforms when frame.pack() is used.

@mrserb Just wanted to follow-up and check if you wanted to add anything additional to this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/9248


From serb at openjdk.org  Thu Jun 23 06:09:43 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Jun 2022 06:09:43 GMT
Subject: RFR: JDK-8288993: Make AwtFramePackTest generic by removing
 @requires tag
In-Reply-To: <r5HklzGTf9N2fzKgd1sQDObs44rRLp8_iVU7gkOXrLE=.a6c2ceb3-8ec2-4438-9eb8-fc475f27c56b@github.com>
References: <r5HklzGTf9N2fzKgd1sQDObs44rRLp8_iVU7gkOXrLE=.a6c2ceb3-8ec2-4438-9eb8-fc475f27c56b@github.com>
Message-ID: <ALkLF3ENDSFIOnclRw4NjCulDYpd_Em0DPuLB_Rcauo=.98e22be7-29d3-43fe-b873-33972b79545c@github.com>

On Wed, 22 Jun 2022 18:50:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> The following test was changed to generic based on this [Review Comment](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9118*discussion_r897553780__;Iw!!ACWV5N9M2RV99hQ!P_GL_NjJc6mQksISE_S4ESnbESYQ3p0UToATIN3T-tcXlKTRrjPp9Zv_4daRhzlJmEbbS_AftmcQrfKhNwSpDA$ ) and as the condition `frame.getSize() == frame.getPreferredSize() ` should hold on all platforms when frame.pack() is used.

test/jdk/java/awt/Frame/AwtFramePackTest.java line 44:

> 42:  * @summary Tests whether insets are calculated correctly on Windows
> 43:  * for AWT Frame by checking the actual and expected/preferred frame sizes.
> 44:  * @run main/othervm -Dsun.java2d.uiScale=1 AwtFramePackTest

Please double check that the "-Dsun.java2d.uiScale=1" option is needed here, It does not affect the frame decoration, and I think this can cause the test to fail if the desktop scale=200% is set in the WIndows.

-------------

PR: https://git.openjdk.org/jdk/pull/9248


From serb at openjdk.org  Thu Jun 23 06:10:46 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Jun 2022 06:10:46 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea
In-Reply-To: <2dwKHgzSR1BLddkqZl2vajQEJB-bhb8woq-hhD4ddTE=.d46af140-f07d-47ee-a2b3-b34c473b9775@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <rxdHQ-zL-lTLJ7WFY2Q-XbViGbJrcy6WXVE4Sh9QpjE=.3c4110f5-e4e0-42aa-9a76-7d134e8e6ce1@github.com>
 <2dwKHgzSR1BLddkqZl2vajQEJB-bhb8woq-hhD4ddTE=.d46af140-f07d-47ee-a2b3-b34c473b9775@github.com>
Message-ID: <_9jZcOEEC8K51EYeNH0JXCHa4AAX1SrvU9g8yCqOnDc=.e9a52478-0670-4e31-955d-1de3d331dc2b@github.com>

On Wed, 22 Jun 2022 06:56:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Right option key does not work at all...Left option key worked for left-right but not for up-down..this PR addresses that left option key up/down issue..

But the right key worked in jdk8, no?

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From serb at openjdk.org  Thu Jun 23 06:12:37 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Jun 2022 06:12:37 GMT
Subject: RFR: 8288633: The ICC_ColorSpace.fromCIEXYZ method uses the wrong
 rendering intent [v2]
In-Reply-To: <AprfDeGGekE6v7_zvFM4-HP6mlJnsl7ORj35pSVcbIM=.414a77f0-99db-4535-8bfe-94c77418aeb6@github.com>
References: <AprfDeGGekE6v7_zvFM4-HP6mlJnsl7ORj35pSVcbIM=.414a77f0-99db-4535-8bfe-94c77418aeb6@github.com>
Message-ID: <DuZIpHsaFdw_cxbhiyLJ0cg4D8lNxYp2MVJ8rHB3mOI=.ce31cf20-5ca6-485b-822a-90a828dac705@github.com>

> The specification of the  ICC_ColorSpace.fromCIEXYZ method [says](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java*L428__;Iw!!ACWV5N9M2RV99hQ!IJJLWj4I9dcJ4yXCu-UdKP0SxwlTrppr5gQ9cHORP1CPHKQui0bgNjfvD2Sa7UaOIBCxbN5AX_Hm9ZzsavUWyw$ ):
> 
>> * This method transforms color values using relative colorimetry, as defined by the ICC Specification.
> 
> The LCMS plugin implementation expects the rendering intent in the first part of transform:
> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java*L116__;Iw!!ACWV5N9M2RV99hQ!IJJLWj4I9dcJ4yXCu-UdKP0SxwlTrppr5gQ9cHORP1CPHKQui0bgNjfvD2Sa7UaOIBCxbN5AX_Hm9ZzUSCgAVQ$ 
> 
> But the ICC_ColorSpace.fromCIEXYZ pass "ICC_Profile.icRelativeColorimetric" to the [second ](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java*L534__;Iw!!ACWV5N9M2RV99hQ!IJJLWj4I9dcJ4yXCu-UdKP0SxwlTrppr5gQ9cHORP1CPHKQui0bgNjfvD2Sa7UaOIBCxbN5AX_Hm9ZwMfwrirg$ ) part of transform. 
> 
> Note that ICC_ColorSpace.toCIEXYZ has a similar [specification ](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java*L288)is__;Iw!!ACWV5N9M2RV99hQ!IJJLWj4I9dcJ4yXCu-UdKP0SxwlTrppr5gQ9cHORP1CPHKQui0bgNjfvD2Sa7UaOIBCxbN5AX_Hm9Zz9XsnUbw$  implemented [properly](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java*L391__;Iw!!ACWV5N9M2RV99hQ!IJJLWj4I9dcJ4yXCu-UdKP0SxwlTrppr5gQ9cHORP1CPHKQui0bgNjfvD2Sa7UaOIBCxbN5AX_Hm9ZwYioFgQw$ ).

Sergey Bylokhov 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 'openjdk:master' into JDK-8288633
 - Update ICC_ColorSpace.java
 - 8288633: The ICC_ColorSpace.fromCIEXYZ method uses the wrong rendering intent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9194/files
  - new: https://git.openjdk.org/jdk/pull/9194/files/3dba4abc..045e55bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9194&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9194&range=00-01

  Stats: 26181 lines in 669 files changed: 7449 ins; 8671 del; 10061 mod
  Patch: https://git.openjdk.org/jdk/pull/9194.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9194/head:pull/9194

PR: https://git.openjdk.org/jdk/pull/9194


From psadhukhan at openjdk.org  Thu Jun 23 06:44:54 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Jun 2022 06:44:54 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea
In-Reply-To: <_9jZcOEEC8K51EYeNH0JXCHa4AAX1SrvU9g8yCqOnDc=.e9a52478-0670-4e31-955d-1de3d331dc2b@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <rxdHQ-zL-lTLJ7WFY2Q-XbViGbJrcy6WXVE4Sh9QpjE=.3c4110f5-e4e0-42aa-9a76-7d134e8e6ce1@github.com>
 <2dwKHgzSR1BLddkqZl2vajQEJB-bhb8woq-hhD4ddTE=.d46af140-f07d-47ee-a2b3-b34c473b9775@github.com>
 <_9jZcOEEC8K51EYeNH0JXCHa4AAX1SrvU9g8yCqOnDc=.e9a52478-0670-4e31-955d-1de3d331dc2b@github.com>
Message-ID: <-2ZlfGrmrAPTdnnfqGUdhNx6IGyFWCCBtq9syFCNwCY=.e8dd5abd-4e07-4e71-9dae-2e6081269c7d@github.com>

On Thu, 23 Jun 2022 06:07:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Right option key does not work at all...Left option key worked for left-right but not for up-down..this PR addresses that left option key up/down issue..
> 
> But the right key worked in jdk8, no?

Right Option Key worked for left-right, not for up-down in jdk8..in fact it stopped working from jdk9-b120 even for left-right it seems..
BTW, what is the keycode for Right Option Key? Is it VK_ALT_GRAPH?

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From psadhukhan at openjdk.org  Thu Jun 23 07:40:29 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Jun 2022 07:40:29 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v3]
In-Reply-To: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
Message-ID: <adr5M6pu2qQhUrRVlDFARNLJ3Yqd2S6W1_gMWs_3baM=.6448779e-1232-4f87-afe8-84f31db026ca@github.com>

> Unlike in native "Notes" editor where Option+Up/Down traverses to start/end of each line respectively,
> Java does not honour these key combination in editor.
> 
> Added the key combination support by moving the caret to start/end of line and then doing caret up/down a line depending on if we are pressing UP or DOWN key.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Revert JDK-8151136 for Right Option Key

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9230/files
  - new: https://git.openjdk.org/jdk/pull/9230/files/2b523c29..0268daed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9230&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9230&range=01-02

  Stats: 17 lines in 1 file changed: 0 ins; 16 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9230/head:pull/9230

PR: https://git.openjdk.org/jdk/pull/9230


From psadhukhan at openjdk.org  Thu Jun 23 07:44:44 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Jun 2022 07:44:44 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea
In-Reply-To: <-2ZlfGrmrAPTdnnfqGUdhNx6IGyFWCCBtq9syFCNwCY=.e8dd5abd-4e07-4e71-9dae-2e6081269c7d@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <rxdHQ-zL-lTLJ7WFY2Q-XbViGbJrcy6WXVE4Sh9QpjE=.3c4110f5-e4e0-42aa-9a76-7d134e8e6ce1@github.com>
 <2dwKHgzSR1BLddkqZl2vajQEJB-bhb8woq-hhD4ddTE=.d46af140-f07d-47ee-a2b3-b34c473b9775@github.com>
 <_9jZcOEEC8K51EYeNH0JXCHa4AAX1SrvU9g8yCqOnDc=.e9a52478-0670-4e31-955d-1de3d331dc2b@github.com>
 <-2ZlfGrmrAPTdnnfqGUdhNx6IGyFWCCBtq9syFCNwCY=.e8dd5abd-4e07-4e71-9dae-2e6081269c7d@github.com>
Message-ID: <PGZcnGmUSIbdeSLFbLhqjGLJLh5eV3ocMV4Q6CnK5ks=.ebd5e160-f447-48e9-8879-7f171bcfd164@github.com>

On Thu, 23 Jun 2022 06:41:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > > Right option key does not work at all...Left option key worked for left-right but not for up-down..this PR addresses that left option key up/down issue..
> > 
> > 
> > But the right key worked in jdk8, no?
> 
> Right Option Key worked for left-right, not for up-down in jdk8..in fact it stopped working from jdk9-b120 even for left-right it seems.. BTW, what is the keycode for Right Option Key? Is it VK_ALT_GRAPH?

[JDK-8151136](https://bugs.openjdk.org/browse/JDK-8151136) regressed Right Option Key working for making test/java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java work which only tests for Linux as per manual instruction so no need to test it for mac

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From aghaisas at openjdk.org  Thu Jun 23 11:01:14 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Thu, 23 Jun 2022 11:01:14 GMT
Subject: RFR: 8288948: Few J2DBench tests indicate lower primitive drawing
 performance with metal rendering pipeline
Message-ID: <1mlxTrRcSlrjN3e12IHWPsLIs67J_lce3s69JTuxfX8=.374cb6e2-a9a1-40fd-9f64-164385fbbe01@github.com>

J2DBench test option files attached to [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) indicate lower drawing performance on macOS with Metal rendering pipeline as compared to OpenGL rendering pipeline.

**Analysis :** 
Current implementation of 2D primitives (Line, Rectangle, Parallelogram - Draw/Fill operations) in Metal rendering pipeline follow below structure-
1) End points (vertices) required for the primitive drawing are put in a buffer.
2) The data prepared in above step is sent to GPU using MTLRenderCommandEncoder `setVertexBytes()` call
3) A draw command is issued using MTLRenderCommandEncoder `drawPrimitives()` call
4) Primitive Color is set (repeated when encoder or color changes) using MTLRenderCommandEncoder `setFragmentBytes()` call in MTLRenderCommandEncoder state update.

**Root Cause of slower performance :**
It is found that the multiple calls to MTLRenderCommandEncoder `drawPrimitives()` by using MTLRenderCommandEncoder `setVertexBytes()` to send a tiny amount of data each time slows down the rendering.

**Fix :** 
MTLRenderCommandEncoder `setVertexBytes()` can accept 4KB of buffer at a time.
The primitive drawing logic is modified to collate adjacent draw calls as below -
1) A buffer of size approximately equal to 4KB is created - this is treated as common vertex buffer which is reused again and again
2) For each primitive draw call - the vertices needed for that draw call are added to the above buffer
3) When the buffer is full OR some other condition occurs ( e.g. breakage of draw primitive sequence, some other operation as change of color etc) - 
     a) Vertex data buffer is sent to the GPU using MTLRenderCommandEncoder `setVertexBytes()` call.
     b) A single (or multiple) draw command(s) are issued using MTLRenderCommandEncoder `drawPrimitives()` call.


**More insight :** 
In general, an application requires a mix of 2D shapes, images and text of different color and sizes.
The performance test that we have measure rendering performance of extreme cases such as -
1) J2DBench - tests the repeated drawing of the same type and same color in a time period - e.g. Find the rendering speed of repeated 2D Line draw operation in X mSec?
2) RenderPerf test - tests the drawing of N primitives of the same type but each instance with a different color and capture FPS.

This PR optimizes the Java2D Metal rendering pipeline implementation for the first case where the same primitive is drawn repeatedly without changing its color. Our current architecture needs to be tweaked to address slower performance shown by RenderPerf tests.  If needed, that needs to be done separately. 

**Results :**
The performance results are attached to the JBS.

-------------

Commit messages:
 - add a comment
 - collate adjacent draw calls

Changes: https://git.openjdk.org/jdk/pull/9245/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9245&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288948
  Stats: 257 lines in 4 files changed: 149 ins; 27 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/9245.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9245/head:pull/9245

PR: https://git.openjdk.org/jdk/pull/9245


From avu at openjdk.org  Thu Jun 23 11:57:53 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Thu, 23 Jun 2022 11:57:53 GMT
Subject: RFR: 8288948: Few J2DBench tests indicate lower primitive drawing
 performance with metal rendering pipeline
In-Reply-To: <1mlxTrRcSlrjN3e12IHWPsLIs67J_lce3s69JTuxfX8=.374cb6e2-a9a1-40fd-9f64-164385fbbe01@github.com>
References: <1mlxTrRcSlrjN3e12IHWPsLIs67J_lce3s69JTuxfX8=.374cb6e2-a9a1-40fd-9f64-164385fbbe01@github.com>
Message-ID: <zf9QPMS56vj7XTv_H23zuDpkA9i4Jb4keGPZ_J9rp48=.989cf608-39c0-4add-bfcd-c6ab9579531b@github.com>

On Wed, 22 Jun 2022 16:32:11 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> J2DBench test option files attached to [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) indicate lower drawing performance on macOS with Metal rendering pipeline as compared to OpenGL rendering pipeline.
> 
> **Analysis :** 
> Current implementation of 2D primitives (Line, Rectangle, Parallelogram - Draw/Fill operations) in Metal rendering pipeline follow below structure-
> 1) End points (vertices) required for the primitive drawing are put in a buffer.
> 2) The data prepared in above step is sent to GPU using MTLRenderCommandEncoder `setVertexBytes()` call
> 3) A draw command is issued using MTLRenderCommandEncoder `drawPrimitives()` call
> 4) Primitive Color is set (repeated when encoder or color changes) using MTLRenderCommandEncoder `setFragmentBytes()` call in MTLRenderCommandEncoder state update.
> 
> **Root Cause of slower performance :**
> It is found that the multiple calls to MTLRenderCommandEncoder `drawPrimitives()` by using MTLRenderCommandEncoder `setVertexBytes()` to send a tiny amount of data each time slows down the rendering.
> 
> **Fix :** 
> MTLRenderCommandEncoder `setVertexBytes()` can accept 4KB of buffer at a time.
> The primitive drawing logic is modified to collate adjacent draw calls as below -
> 1) A buffer of size approximately equal to 4KB is created - this is treated as common vertex buffer which is reused again and again
> 2) For each primitive draw call - the vertices needed for that draw call are added to the above buffer
> 3) When the buffer is full OR some other condition occurs ( e.g. breakage of draw primitive sequence, some other operation as change of color etc) - 
>      a) Vertex data buffer is sent to the GPU using MTLRenderCommandEncoder `setVertexBytes()` call.
>      b) A single (or multiple) draw command(s) are issued using MTLRenderCommandEncoder `drawPrimitives()` call.
> 
> 
> **More insight :** 
> In general, an application requires a mix of 2D shapes, images and text of different color and sizes.
> The performance test that we have measure rendering performance of extreme cases such as -
> 1) J2DBench - tests the repeated drawing of the same type and same color in a time period - e.g. Find the rendering speed of repeated 2D Line draw operation in X mSec?
> 2) RenderPerf test - tests the drawing of N primitives of the same type but each instance with a different color and capture FPS.
> 
> This PR optimizes the Java2D Metal rendering pipeline implementation for the first case where the same primitive is drawn repeatedly without changing its color. Our current architecture needs to be tweaked to address slower performance shown by RenderPerf tests.  If needed, that needs to be done separately. 
> 
> **Results :**
> The performance results are attached to the JBS.

Overal looks good

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m line 261:

> 259:     // Translate each vertex by a fraction so
> 260:     // that we hit pixel centers.
> 261:     //const int verticesCount = 5;

I suppose we can remove this commented code

-------------

Marked as reviewed by avu (Committer).

PR: https://git.openjdk.org/jdk/pull/9245


From honkar at openjdk.org  Thu Jun 23 18:57:59 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 23 Jun 2022 18:57:59 GMT
Subject: RFR: JDK-8288993: Make AwtFramePackTest generic by removing
 @requires tag
In-Reply-To: <ALkLF3ENDSFIOnclRw4NjCulDYpd_Em0DPuLB_Rcauo=.98e22be7-29d3-43fe-b873-33972b79545c@github.com>
References: <r5HklzGTf9N2fzKgd1sQDObs44rRLp8_iVU7gkOXrLE=.a6c2ceb3-8ec2-4438-9eb8-fc475f27c56b@github.com>
 <ALkLF3ENDSFIOnclRw4NjCulDYpd_Em0DPuLB_Rcauo=.98e22be7-29d3-43fe-b873-33972b79545c@github.com>
Message-ID: <1rJk-Fjx54YHJcvariyUjkfrZD2F4efs3xusjukyWxM=.9e0483e9-9720-4875-9ac2-6a509df6a991@github.com>

On Thu, 23 Jun 2022 06:05:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The following test was changed to generic based on this [Review Comment](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9118*discussion_r897553780__;Iw!!ACWV5N9M2RV99hQ!PzEP--HZMd-cIGZirzJpRTsQ2E09rc1Z49qxljJ5UkXKhZCo2iuQREEwcjSXTRjfuF3-u8yQmJW--mqx-WrLE64X$ ) and as the condition `frame.getSize() == frame.getPreferredSize() ` should hold on all platforms when frame.pack() is used.
>
> test/jdk/java/awt/Frame/AwtFramePackTest.java line 44:
> 
>> 42:  * @summary Tests whether insets are calculated correctly on Windows
>> 43:  * for AWT Frame by checking the actual and expected/preferred frame sizes.
>> 44:  * @run main/othervm -Dsun.java2d.uiScale=1 AwtFramePackTest
> 
> Please double check that the "-Dsun.java2d.uiScale=1" option is needed here, It does not affect the frame decoration, and I think this can cause the test to fail if the desktop scale=200% is set in the WIndows.

@mrserb Thank you for catching it :) 
I do see that the test fails when scale >= 200% and passes when the uiScale option is removed. I'll additionally test it on other platforms to check for stability before making the changes.

-------------

PR: https://git.openjdk.org/jdk/pull/9248


From serb at openjdk.org  Thu Jun 23 19:24:51 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Jun 2022 19:24:51 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v3]
In-Reply-To: <adr5M6pu2qQhUrRVlDFARNLJ3Yqd2S6W1_gMWs_3baM=.6448779e-1232-4f87-afe8-84f31db026ca@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <adr5M6pu2qQhUrRVlDFARNLJ3Yqd2S6W1_gMWs_3baM=.6448779e-1232-4f87-afe8-84f31db026ca@github.com>
Message-ID: <v4_Ol_2T9rhJGomRxqgcAOwBHDWh4hvfr5vEiIWejBE=.96db53bc-6a93-4b89-a03d-fd02eb1aa8c8@github.com>

On Thu, 23 Jun 2022 07:40:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Unlike in native "Notes" editor where Option+Up/Down traverses to start/end of each line respectively,
>> Java does not honour these key combination in editor.
>> 
>> Added the key combination support by moving the caret to start/end of line and then doing caret up/down a line depending on if we are pressing UP or DOWN key.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert JDK-8151136 for Right Option Key

[JDK-8151136](https://bugs.openjdk.org/browse/JDK-8151136) was about the handling of the right alt key? It had the instructions for windows and linux, and that fix added the case for macOS. I do not think it should be reverted. Probably the shortcuts should take care about that right-option key.

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From aturbanov at openjdk.org  Thu Jun 23 19:44:56 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 23 Jun 2022 19:44:56 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v6]
In-Reply-To: <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
Message-ID: <PPSTUbLpJnkQgZUlXyikcp9Vjq1D0J8ly5qZQfxJBX4=.51002137-8a00-4dfe-af6b-c5c152be0d1c@github.com>

On Fri, 13 May 2022 16:53:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision:
> 
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/40c585cd...98e635a5

Marked as reviewed by aturbanov (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/8328


From duke at openjdk.org  Thu Jun 23 22:54:18 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 23 Jun 2022 22:54:18 GMT
Subject: RFR: 8288528: broken links in java.desktop
Message-ID: <jcR10e9e6ghqYlY6WJFLGymvxTmXQTv_A6J-8pSPRHI=.65b99ff4-47ab-40f0-bbff-728b6d8d363c@github.com>

doccheck reports some broken links which are rectified. copyright year updated for files.

-------------

Commit messages:
 - copyright year changed for all files
 - ExifTIFFTagSet.java file updated
 - broken links re-fix
 - broken links re-fix
 - broken links fix

Changes: https://git.openjdk.org/jdk19/pull/44/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=44&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288528
  Stats: 33 lines in 4 files changed: 0 ins; 24 del; 9 mod
  Patch: https://git.openjdk.org/jdk19/pull/44.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/44/head:pull/44

PR: https://git.openjdk.org/jdk19/pull/44


From prr at openjdk.org  Thu Jun 23 22:54:18 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 23 Jun 2022 22:54:18 GMT
Subject: RFR: 8288528: broken links in java.desktop
In-Reply-To: <jcR10e9e6ghqYlY6WJFLGymvxTmXQTv_A6J-8pSPRHI=.65b99ff4-47ab-40f0-bbff-728b6d8d363c@github.com>
References: <jcR10e9e6ghqYlY6WJFLGymvxTmXQTv_A6J-8pSPRHI=.65b99ff4-47ab-40f0-bbff-728b6d8d363c@github.com>
Message-ID: <YnnxHuRssxeoXC9hGq-bdbFQJUqTqzfZVK3xS5zMteg=.c05059f1-a356-49aa-abf0-f9224ba6aba1@github.com>

On Mon, 20 Jun 2022 07:35:14 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> doccheck reports some broken links which are rectified. copyright year updated for files.

Please ensure that "make docs" is happy and looks good.

"doccheck reports some broken links which are rectified"

That's a bit terse. 
First this version owes a lot to what was discussed in the initial PR : https://git.openjdk.org/jdk/pull/9195
Second: please add an evaluation about these points in the bug report.

Third: there's no spec issue here so we don't need a CSR.

This isn't actually "rfr" yet because of the lack of OCA verification.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/44


From aivanov at openjdk.org  Thu Jun 23 22:54:19 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 23 Jun 2022 22:54:19 GMT
Subject: RFR: 8288528: broken links in java.desktop
In-Reply-To: <jcR10e9e6ghqYlY6WJFLGymvxTmXQTv_A6J-8pSPRHI=.65b99ff4-47ab-40f0-bbff-728b6d8d363c@github.com>
References: <jcR10e9e6ghqYlY6WJFLGymvxTmXQTv_A6J-8pSPRHI=.65b99ff4-47ab-40f0-bbff-728b6d8d363c@github.com>
Message-ID: <ODP_Sxt5Q9SMCjnVAi9Lo6yPXNTnFGi6TyceiENvc5k=.ca5015cb-5528-4329-be3d-84eb26819924@github.com>

On Mon, 20 Jun 2022 07:35:14 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> doccheck reports some broken links which are rectified. copyright year updated for files.

Should the copyright year be updated?

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java line 35:

> 33:  * standard for annotating images used by most digital camera
> 34:  * manufacturers.  The Exif specification may be found at
> 35:  *<a href="https://urldefense.com/v3/__https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf__;!!ACWV5N9M2RV99hQ!IBGO3MJOU26HBT1yByX4Z6pQzEqwW7rqVBlXyh6QJhqmUkvRQFpOKVCBomsuQMErZpeGU1eWoIWYMQOg1oVwR_RauA$">

I'd preserve the space between `*` and `<` as it was before.

-------------

PR: https://git.openjdk.org/jdk19/pull/44


From aivanov at openjdk.org  Thu Jun 23 22:54:20 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 23 Jun 2022 22:54:20 GMT
Subject: RFR: 8288528: broken links in java.desktop
In-Reply-To: <ODP_Sxt5Q9SMCjnVAi9Lo6yPXNTnFGi6TyceiENvc5k=.ca5015cb-5528-4329-be3d-84eb26819924@github.com>
References: <jcR10e9e6ghqYlY6WJFLGymvxTmXQTv_A6J-8pSPRHI=.65b99ff4-47ab-40f0-bbff-728b6d8d363c@github.com>
 <ODP_Sxt5Q9SMCjnVAi9Lo6yPXNTnFGi6TyceiENvc5k=.ca5015cb-5528-4329-be3d-84eb26819924@github.com>
Message-ID: <xqQgrk5smag-Pinw8ia50C5Fx-FhBeaolwY_VM-8FsA=.92d97af4-6f81-4552-be33-6f31e6aec29a@github.com>

On Tue, 21 Jun 2022 20:13:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Should the copyright year be updated?

This applies to all the files, not only `ExifTIFFTagSet.java`.

-------------

PR: https://git.openjdk.org/jdk19/pull/44


From duke at openjdk.org  Thu Jun 23 22:58:23 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 23 Jun 2022 22:58:23 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method should be
 better specified
Message-ID: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>

JLabel and AbstractButton's imageUpdate method description updated.

---------
### Progress
- [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
- [x] Change must not contain extraneous whitespace
- [x] Commit message must refer to an issue

### Error
&nbsp;?? OCA signatory status must be verified

### Integration blocker
&nbsp;?? Title mismatch between PR and JBS for issue [JDK-6391806](https://bugs.openjdk.org/browse/JDK-6391806)



### Reviewing
<details><summary>Using <code>git</code></summary>

Checkout this PR locally: \
`$ git fetch https://git.openjdk.org/jdk pull/9240/head:pull/9240` \
`$ git checkout pull/9240`

Update a local copy of the PR: \
`$ git checkout pull/9240` \
`$ git pull https://git.openjdk.org/jdk pull/9240/head`

</details>
<details><summary>Using Skara CLI tools</summary>

Checkout this PR locally: \
`$ git pr checkout 9240`

View PR using the GUI difftool: \
`$ git pr show -t 9240`

</details>
<details><summary>Using diff file</summary>

Download this PR as a diff file: \
<a href="https://git.openjdk.org/jdk/pull/9240.diff">https://git.openjdk.org/jdk/pull/9240.diff</a>

</details>

-------------

Commit messages:
 - imageUpdate method description changed

Changes: https://git.openjdk.org/jdk/pull/9240/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9240&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6391806
  Stats: 6 lines in 2 files changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9240.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9240/head:pull/9240

PR: https://git.openjdk.org/jdk/pull/9240


From duke at openjdk.org  Thu Jun 23 22:58:24 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 23 Jun 2022 22:58:24 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified
In-Reply-To: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
Message-ID: <RI-j81Q4DtHFSvl28ty6mP5FHk9eKTkpHD9qGx0sl5A=.af2079a8-5b94-4a25-805b-87ba4c9f2122@github.com>

On Wed, 22 Jun 2022 13:14:31 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> JLabel and AbstractButton's imageUpdate method description updated.
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> ### Error
> &nbsp;?? OCA signatory status must be verified
> 
> ### Integration blocker
> &nbsp;?? Title mismatch between PR and JBS for issue [JDK-6391806](https://bugs.openjdk.org/browse/JDK-6391806)
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk pull/9240/head:pull/9240` \
> `$ git checkout pull/9240`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/9240` \
> `$ git pull https://git.openjdk.org/jdk pull/9240/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 9240`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 9240`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/9240.diff">https://git.openjdk.org/jdk/pull/9240.diff</a>
> 
> </details>

changed the title

-------------

PR: https://git.openjdk.org/jdk/pull/9240


From honkar at openjdk.org  Fri Jun 24 00:53:35 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 24 Jun 2022 00:53:35 GMT
Subject: RFR: JDK-8288993: Make AwtFramePackTest generic by removing
 @requires tag [v2]
In-Reply-To: <r5HklzGTf9N2fzKgd1sQDObs44rRLp8_iVU7gkOXrLE=.a6c2ceb3-8ec2-4438-9eb8-fc475f27c56b@github.com>
References: <r5HklzGTf9N2fzKgd1sQDObs44rRLp8_iVU7gkOXrLE=.a6c2ceb3-8ec2-4438-9eb8-fc475f27c56b@github.com>
Message-ID: <C1A1WnQJzK3HP-H28uac1UIBtWciV29Kdfd-NXj4CVM=.a817ee7c-72ff-43ff-8374-179d4396e6a3@github.com>

> The following test was changed to generic based on this [Review Comment](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9118*discussion_r897553780__;Iw!!ACWV5N9M2RV99hQ!NUXhvbQ5RkrT6hE8jJxIhMMFz0Sk_M_g3cp2mo-sJEQ2CcicbpH3d4LuE5aV7ck40Vlum-RDx-cK7CFYN4AjAjUt$ ) and as the condition `frame.getSize() == frame.getPreferredSize() ` should hold on all platforms when frame.pack() is used.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  removed uiScale

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9248/files
  - new: https://git.openjdk.org/jdk/pull/9248/files/c518f8bd..d4db9916

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9248&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9248&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9248.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9248/head:pull/9248

PR: https://git.openjdk.org/jdk/pull/9248


From honkar at openjdk.org  Fri Jun 24 00:53:35 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 24 Jun 2022 00:53:35 GMT
Subject: RFR: JDK-8288993: Make AwtFramePackTest generic by removing
 @requires tag [v2]
In-Reply-To: <ALkLF3ENDSFIOnclRw4NjCulDYpd_Em0DPuLB_Rcauo=.98e22be7-29d3-43fe-b873-33972b79545c@github.com>
References: <r5HklzGTf9N2fzKgd1sQDObs44rRLp8_iVU7gkOXrLE=.a6c2ceb3-8ec2-4438-9eb8-fc475f27c56b@github.com>
 <ALkLF3ENDSFIOnclRw4NjCulDYpd_Em0DPuLB_Rcauo=.98e22be7-29d3-43fe-b873-33972b79545c@github.com>
Message-ID: <jJfQpK6hqZwmRA3gHss2y4yJ6ZcIxC2bFZh5lkDyi3M=.3bee404a-6faf-4759-9e4c-5f3d3f152fd8@github.com>

On Thu, 23 Jun 2022 06:05:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed uiScale
>
> test/jdk/java/awt/Frame/AwtFramePackTest.java line 44:
> 
>> 42:  * @summary Tests whether insets are calculated correctly on Windows
>> 43:  * for AWT Frame by checking the actual and expected/preferred frame sizes.
>> 44:  * @run main/othervm -Dsun.java2d.uiScale=1 AwtFramePackTest
> 
> Please double check that the "-Dsun.java2d.uiScale=1" option is needed here, It does not affect the frame decoration, and I think this can cause the test to fail if the desktop scale=200% is set in the WIndows.

@mrserb Removed uiScale=1,test works on all platforms.

-------------

PR: https://git.openjdk.org/jdk/pull/9248


From psadhukhan at openjdk.org  Fri Jun 24 03:16:46 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Jun 2022 03:16:46 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v3]
In-Reply-To: <v4_Ol_2T9rhJGomRxqgcAOwBHDWh4hvfr5vEiIWejBE=.96db53bc-6a93-4b89-a03d-fd02eb1aa8c8@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <adr5M6pu2qQhUrRVlDFARNLJ3Yqd2S6W1_gMWs_3baM=.6448779e-1232-4f87-afe8-84f31db026ca@github.com>
 <v4_Ol_2T9rhJGomRxqgcAOwBHDWh4hvfr5vEiIWejBE=.96db53bc-6a93-4b89-a03d-fd02eb1aa8c8@github.com>
Message-ID: <zfbirptOeLX7xhsqgpMrD6TfXnKzajMCFX4IghXfY7Q=.4a7c6868-1a16-44b7-a326-9695bfe3c697@github.com>

On Thu, 23 Jun 2022 19:21:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> [JDK-8151136](https://bugs.openjdk.org/browse/JDK-8151136) was about the handling of the right alt key? It had the instructions for windows and linux, and that fix added the case for macOS. I do not think it should be reverted. Probably the shortcuts should take care about that right-option key.

But if you take a look now, that test only do the test for linux and all other instructions for other platforms are removed. I couldn't find the JBS issue which did the removal but I guess it was done for a cause.

Also, I couldn't find any shortcuts for right-option key...It seems, both left and right option key has same keycode from native NSAlternateKeyMask

If you still insist on reverting, I will request to let this PR to tackle only Left Option for now. I will file another issue to take a look at Right Option Key.

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From psadhukhan at openjdk.org  Fri Jun 24 03:56:22 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Jun 2022 03:56:22 GMT
Subject: RFR: 8288707: javax/swing/JToolBar/4529206/bug4529206.java:
 setFloating does not work correctly
Message-ID: <RPkNNkTmYAcBhA67ENFKO2omtGISEideYdn_oyo51Kc=.8fa3ec08-fcb2-4c72-a78b-4b52f5010e00@github.com>

Test was failing intermittently around 1 or 2 out of 30 runs. 
Fixed by adding stability code, wait for a sec after frame is visible, set frame to center.
Modified test has run at least 50 times in all platforms and 100 times in linux (where it is seen intermittently) without any issue.

-------------

Commit messages:
 - Fix
 - 8288707: javax/swing/JToolBar/4529206/bug4529206.java: setFloating does not work correctly

Changes: https://git.openjdk.org/jdk/pull/9269/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9269&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288707
  Stats: 63 lines in 1 file changed: 34 ins; 9 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/9269.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9269/head:pull/9269

PR: https://git.openjdk.org/jdk/pull/9269


From duke at openjdk.org  Fri Jun 24 04:25:03 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 24 Jun 2022 04:25:03 GMT
Subject: Integrated: 8288528: broken links in java.desktop
In-Reply-To: <jcR10e9e6ghqYlY6WJFLGymvxTmXQTv_A6J-8pSPRHI=.65b99ff4-47ab-40f0-bbff-728b6d8d363c@github.com>
References: <jcR10e9e6ghqYlY6WJFLGymvxTmXQTv_A6J-8pSPRHI=.65b99ff4-47ab-40f0-bbff-728b6d8d363c@github.com>
Message-ID: <j2E1mHJKJIQaJUFtbwxseMqHCdoqkuOgFlIGUdFSkeo=.57526663-5a62-4473-ab94-335c7fede41c@github.com>

On Mon, 20 Jun 2022 07:35:14 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> doccheck reports some broken links which are rectified. copyright year updated for files.

This pull request has now been integrated.

Changeset: b0db3333
Author:    Abhishek Kumar <abhishek.cx.kumar at oracle.com>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/b0db33333a9fbc39e8d9f7d6a0f13d6a1b5dde04
Stats:     33 lines in 4 files changed: 0 ins; 24 del; 9 mod

8288528: broken links in java.desktop

Reviewed-by: prr, aivanov

-------------

PR: https://git.openjdk.org/jdk19/pull/44


From duke at openjdk.org  Fri Jun 24 04:51:59 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 24 Jun 2022 04:51:59 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified
In-Reply-To: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
Message-ID: <lxjMOXJ1rGFlk6C7BrKMKPQiLgmov6Dxvasfs0wX84U=.1f97aec1-5385-4017-8b37-2a07d4966a49@github.com>

On Wed, 22 Jun 2022 13:14:31 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> JLabel and AbstractButton's imageUpdate method description updated.
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> ### Error
> &nbsp;?? OCA signatory status must be verified
> 
> ### Integration blocker
> &nbsp;?? Title mismatch between PR and JBS for issue [JDK-6391806](https://bugs.openjdk.org/browse/JDK-6391806)
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk pull/9240/head:pull/9240` \
> `$ git checkout pull/9240`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/9240` \
> `$ git pull https://git.openjdk.org/jdk pull/9240/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 9240`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 9240`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/9240.diff">https://git.openjdk.org/jdk/pull/9240.diff</a>
> 
> </details>

dummy comment

-------------

PR: https://git.openjdk.org/jdk/pull/9240


From aghaisas at openjdk.org  Fri Jun 24 05:31:33 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 24 Jun 2022 05:31:33 GMT
Subject: RFR: 8288948: Few J2DBench tests indicate lower primitive drawing
 performance with metal rendering pipeline [v2]
In-Reply-To: <1mlxTrRcSlrjN3e12IHWPsLIs67J_lce3s69JTuxfX8=.374cb6e2-a9a1-40fd-9f64-164385fbbe01@github.com>
References: <1mlxTrRcSlrjN3e12IHWPsLIs67J_lce3s69JTuxfX8=.374cb6e2-a9a1-40fd-9f64-164385fbbe01@github.com>
Message-ID: <ZwwACGtK8MWjlO3Dys1K4SdE2jntgvSpXWNvsoGVXwI=.5425128a-80a1-435f-9f6e-704247ade0e5@github.com>

> J2DBench test option files attached to [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) indicate lower drawing performance on macOS with Metal rendering pipeline as compared to OpenGL rendering pipeline.
> 
> **Analysis :** 
> Current implementation of 2D primitives (Line, Rectangle, Parallelogram - Draw/Fill operations) in Metal rendering pipeline follow below structure-
> 1) End points (vertices) required for the primitive drawing are put in a buffer.
> 2) The data prepared in above step is sent to GPU using MTLRenderCommandEncoder `setVertexBytes()` call
> 3) A draw command is issued using MTLRenderCommandEncoder `drawPrimitives()` call
> 4) Primitive Color is set (repeated when encoder or color changes) using MTLRenderCommandEncoder `setFragmentBytes()` call in MTLRenderCommandEncoder state update.
> 
> **Root Cause of slower performance :**
> It is found that the multiple calls to MTLRenderCommandEncoder `drawPrimitives()` by using MTLRenderCommandEncoder `setVertexBytes()` to send a tiny amount of data each time slows down the rendering.
> 
> **Fix :** 
> MTLRenderCommandEncoder `setVertexBytes()` can accept 4KB of buffer at a time.
> The primitive drawing logic is modified to collate adjacent draw calls as below -
> 1) A buffer of size approximately equal to 4KB is created - this is treated as common vertex buffer which is reused again and again
> 2) For each primitive draw call - the vertices needed for that draw call are added to the above buffer
> 3) When the buffer is full OR some other condition occurs ( e.g. breakage of draw primitive sequence, some other operation as change of color etc) - 
>      a) Vertex data buffer is sent to the GPU using MTLRenderCommandEncoder `setVertexBytes()` call.
>      b) A single (or multiple) draw command(s) are issued using MTLRenderCommandEncoder `drawPrimitives()` call.
> 
> 
> **More insight :** 
> In general, an application requires a mix of 2D shapes, images and text of different color and sizes.
> The performance test that we have measure rendering performance of extreme cases such as -
> 1) J2DBench - tests the repeated drawing of the same type and same color in a time period - e.g. Find the rendering speed of repeated 2D Line draw operation in X mSec?
> 2) RenderPerf test - tests the drawing of N primitives of the same type but each instance with a different color and capture FPS.
> 
> This PR optimizes the Java2D Metal rendering pipeline implementation for the first case where the same primitive is drawn repeatedly without changing its color. Our current architecture needs to be tweaked to address slower performance shown by RenderPerf tests.  If needed, that needs to be done separately. 
> 
> **Results :**
> The performance results are attached to the JBS.

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  make method inline + clean commented line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9245/files
  - new: https://git.openjdk.org/jdk/pull/9245/files/ea5e233f..766ed69e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9245&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9245&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9245.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9245/head:pull/9245

PR: https://git.openjdk.org/jdk/pull/9245


From psadhukhan at openjdk.org  Fri Jun 24 08:08:46 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Jun 2022 08:08:46 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v3]
In-Reply-To: <zfbirptOeLX7xhsqgpMrD6TfXnKzajMCFX4IghXfY7Q=.4a7c6868-1a16-44b7-a326-9695bfe3c697@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <adr5M6pu2qQhUrRVlDFARNLJ3Yqd2S6W1_gMWs_3baM=.6448779e-1232-4f87-afe8-84f31db026ca@github.com>
 <v4_Ol_2T9rhJGomRxqgcAOwBHDWh4hvfr5vEiIWejBE=.96db53bc-6a93-4b89-a03d-fd02eb1aa8c8@github.com>
 <zfbirptOeLX7xhsqgpMrD6TfXnKzajMCFX4IghXfY7Q=.4a7c6868-1a16-44b7-a326-9695bfe3c697@github.com>
Message-ID: <iDQtO_AGoK-ClsyMaWipuEBjsYqpu6cJc2cf_DtSXq0=.87da2c76-ab3b-44c8-b730-42c6b4eef1e6@github.com>

On Fri, 24 Jun 2022 03:13:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> [JDK-8151136](https://bugs.openjdk.org/browse/JDK-8151136) was about the handling of the right alt key?

Yes. As per the comments on the bug


Cause of the problem:
On OS X AltGraph functionality was not implemented. 
Fix:
Right Option key is defined to behave as AltGraph key on OS X. Left Option key only act as Alt key. 


Now, our key bindings are all Alt Key based. 
https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/classes/com/apple/laf/AquaKeyBindings.java*L89__;Iw!!ACWV5N9M2RV99hQ!PjuWn3e0Dtdx0Uux1T5kPZDYwInd_M8ecnJj8J2I15VRXVDwaI4zCLQq8y71o2a0Ybi8pAeNBTqJ7rphBKLsXpI-FX5xFA$ 
so it used to work for Right Option key till this fix was integrated...It still works for Left Option key as it is mapped to Alt..
Now it return VK_ALT_GRAPH and we do not have keybindings for that.. I do not see anywhere in any L&F ALT_GRAPH is used

so either we need to have VK_ALT as used before the fix (which is why I reverted) or somewhat use ALT_GRAPH binding. 

Do you know how to have "ALT GRAPH" key binding?

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From avu at openjdk.org  Fri Jun 24 09:19:58 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Fri, 24 Jun 2022 09:19:58 GMT
Subject: RFR: 8288948: Few J2DBench tests indicate lower primitive drawing
 performance with metal rendering pipeline [v2]
In-Reply-To: <ZwwACGtK8MWjlO3Dys1K4SdE2jntgvSpXWNvsoGVXwI=.5425128a-80a1-435f-9f6e-704247ade0e5@github.com>
References: <1mlxTrRcSlrjN3e12IHWPsLIs67J_lce3s69JTuxfX8=.374cb6e2-a9a1-40fd-9f64-164385fbbe01@github.com>
 <ZwwACGtK8MWjlO3Dys1K4SdE2jntgvSpXWNvsoGVXwI=.5425128a-80a1-435f-9f6e-704247ade0e5@github.com>
Message-ID: <bXSV6Cm5aXU0fOu5YoI_KsZQAmyd9sdWup_dsksdlXA=.a627c399-657f-459f-a29c-10bdfe205cb8@github.com>

On Fri, 24 Jun 2022 05:31:33 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> J2DBench test option files attached to [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) indicate lower drawing performance on macOS with Metal rendering pipeline as compared to OpenGL rendering pipeline.
>> 
>> **Analysis :** 
>> Current implementation of 2D primitives (Line, Rectangle, Parallelogram - Draw/Fill operations) in Metal rendering pipeline follow below structure-
>> 1) End points (vertices) required for the primitive drawing are put in a buffer.
>> 2) The data prepared in above step is sent to GPU using MTLRenderCommandEncoder `setVertexBytes()` call
>> 3) A draw command is issued using MTLRenderCommandEncoder `drawPrimitives()` call
>> 4) Primitive Color is set (repeated when encoder or color changes) using MTLRenderCommandEncoder `setFragmentBytes()` call in MTLRenderCommandEncoder state update.
>> 
>> **Root Cause of slower performance :**
>> It is found that the multiple calls to MTLRenderCommandEncoder `drawPrimitives()` by using MTLRenderCommandEncoder `setVertexBytes()` to send a tiny amount of data each time slows down the rendering.
>> 
>> **Fix :** 
>> MTLRenderCommandEncoder `setVertexBytes()` can accept 4KB of buffer at a time.
>> The primitive drawing logic is modified to collate adjacent draw calls as below -
>> 1) A buffer of size approximately equal to 4KB is created - this is treated as common vertex buffer which is reused again and again
>> 2) For each primitive draw call - the vertices needed for that draw call are added to the above buffer
>> 3) When the buffer is full OR some other condition occurs ( e.g. breakage of draw primitive sequence, some other operation as change of color etc) - 
>>      a) Vertex data buffer is sent to the GPU using MTLRenderCommandEncoder `setVertexBytes()` call.
>>      b) A single (or multiple) draw command(s) are issued using MTLRenderCommandEncoder `drawPrimitives()` call.
>> 
>> 
>> **More insight :** 
>> In general, an application requires a mix of 2D shapes, images and text of different color and sizes.
>> The performance test that we have measure rendering performance of extreme cases such as -
>> 1) J2DBench - tests the repeated drawing of the same type and same color in a time period - e.g. Find the rendering speed of repeated 2D Line draw operation in X mSec?
>> 2) RenderPerf test - tests the drawing of N primitives of the same type but each instance with a different color and capture FPS.
>> 
>> This PR optimizes the Java2D Metal rendering pipeline implementation for the first case where the same primitive is drawn repeatedly without changing its color. Our current architecture needs to be tweaked to address slower performance shown by RenderPerf tests.  If needed, that needs to be done separately. 
>> 
>> **Results :**
>> The performance results are attached to the JBS.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make method inline + clean commented line

Looks good

-------------

Marked as reviewed by avu (Committer).

PR: https://git.openjdk.org/jdk/pull/9245


From psadhukhan at openjdk.org  Fri Jun 24 12:04:43 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Jun 2022 12:04:43 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v4]
In-Reply-To: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
Message-ID: <FPHoJXSaJK3vJednWjQsgdH_Reevv4kRqXueZJdacYk=.90e4d39d-d298-446d-b37b-f0e0198ecc0f@github.com>

> Unlike in native "Notes" editor where Option+Up/Down traverses to start/end of each line respectively,
> Java does not honour these key combination in editor.
> 
> Added the key combination support by moving the caret to start/end of line and then doing caret up/down a line depending on if we are pressing UP or DOWN key.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix Right Option Key handling

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9230/files
  - new: https://git.openjdk.org/jdk/pull/9230/files/0268daed..8149271b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9230&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9230&range=02-03

  Stats: 21 lines in 2 files changed: 20 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9230/head:pull/9230

PR: https://git.openjdk.org/jdk/pull/9230


From psadhukhan at openjdk.org  Fri Jun 24 12:15:34 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Jun 2022 12:15:34 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v5]
In-Reply-To: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
Message-ID: <eaIqfbBPgL1ztaV0YUgcV2zF38-eR4XfmNpfAj5NWic=.2ece233e-c6f0-43f2-aa2b-2d9d4441432c@github.com>

> Unlike in native "Notes" editor where Option+Up/Down traverses to start/end of each line respectively,
> Java does not honour these key combination in editor.
> 
> Added the key combination support by moving the caret to start/end of line and then doing caret up/down a line depending on if we are pressing UP or DOWN key.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix Right Option Key handling

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9230/files
  - new: https://git.openjdk.org/jdk/pull/9230/files/8149271b..71fa4673

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9230&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9230&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9230/head:pull/9230

PR: https://git.openjdk.org/jdk/pull/9230


From prr at openjdk.org  Fri Jun 24 17:57:01 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 24 Jun 2022 17:57:01 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v5]
In-Reply-To: <eaIqfbBPgL1ztaV0YUgcV2zF38-eR4XfmNpfAj5NWic=.2ece233e-c6f0-43f2-aa2b-2d9d4441432c@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <eaIqfbBPgL1ztaV0YUgcV2zF38-eR4XfmNpfAj5NWic=.2ece233e-c6f0-43f2-aa2b-2d9d4441432c@github.com>
Message-ID: <2lojbp2WLFbEEIhZVeVIbHU_6g_n3zQHpyKAAU9Jl7E=.1ed34cc5-5c1e-4c45-8657-df36af1ecffe@github.com>

On Fri, 24 Jun 2022 12:15:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Unlike in native "Notes" editor where Option+Up/Down traverses to start/end of each line respectively,
>> Java does not honour these key combination in editor.
>> 
>> Added the key combination support by moving the caret to start/end of line and then doing caret up/down a line depending on if we are pressing UP or DOWN key.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Right Option Key handling

src/java.desktop/macosx/classes/com/apple/laf/AquaKeyBindings.java line 95:

> 93:         "alt altgraph LEFT", DefaultEditorKit.previousWordAction,
> 94:         "alt altgraph RIGHT", DefaultEditorKit.nextWordAction,
> 95:         "alt UP", DefaultEditorKit.beginLineUpAction,

I find it utterly bizarre to say we need "altgraph" when macOS doesn't have altgraph - certainly not on the k/bs on current mac books or imacs.

My take is that the previous fix JDK-8151136 was a mistake and we should have just excluded the test there on macOS.

src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java line 650:

> 648:      * upward one line otherwise.
> 649:      * @see #getActions
> 650:      */

What ? We are adding new public API to solve this ? 
Why is that necessary ?

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From honkar at openjdk.org  Fri Jun 24 22:22:35 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 24 Jun 2022 22:22:35 GMT
Subject: RFR: 8288444: Remove the workaround for frame.pack() in
 ModalDialogTest
Message-ID: <88CU8XufxULaqu9xL-G581LBMSlsAR9TU_fuKspZs20=.e576f3b0-e3ff-4037-9cb9-a92bf204cb02@github.com>

Previously frame.pack() was called twice as a workaround  AWT frame sizing issue in this particular test case on Windows. This issue was fixed **[JDK-8265586](https://bugs.openjdk.org/browse/JDK-8265586)** and hence the workaround is being removed from this test.

PassFailJFrame is being used as the test framework. Since only the root frame of this test is being added to PassFailJFrame, no additional changes are required on PassFailJFrame.java

**Proposed change related to PassFailJFrame Test framework**

Instead of creating new methods to handle AWT Windows as well as Frames, method signatures - [**PassFailJFrame .positionTestFrame()**](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/53b37fe1535388eb14e04c620a6b0118ed8884a0/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java*L271__;Iw!!ACWV5N9M2RV99hQ!N9BsFaF3cRzz4adDsuCirNEsZjEpgcd-LeT6g6zJAgoWcLRTdYwRMpSLfc9EYL2BLffozASWdQPdKcP8VRkb2p3_$ ) and [**PassFailJFrame .addTestFrame()**](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/53b37fe1535388eb14e04c620a6b0118ed8884a0/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java*L294__;Iw!!ACWV5N9M2RV99hQ!N9BsFaF3cRzz4adDsuCirNEsZjEpgcd-LeT6g6zJAgoWcLRTdYwRMpSLfc9EYL2BLffozASWdQPdKcP8VamKQnE9$ ) can be changed to take in Window instead of Frame, since Window is a superclass and this would allow the test frame to be a Window/Frame/Dialog and not be restricted to a Frame.

-------------

Commit messages:
 - ModalDialogTest changes

Changes: https://git.openjdk.org/jdk/pull/9286/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9286&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288444
  Stats: 355 lines in 1 file changed: 355 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9286.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9286/head:pull/9286

PR: https://git.openjdk.org/jdk/pull/9286


From duke at openjdk.org  Sat Jun 25 01:11:59 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Sat, 25 Jun 2022 01:11:59 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v4]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <3aUzwJTlKj3o0N9WbF7EHfFB2KwPBA1z5vCsjabSN4U=.f431f660-b8f2-41ab-915a-0014c33fd0d7@github.com>

> 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

Nikita Gubarkov has updated the pull request incrementally with two additional commits since the last revision:

 - 8269806: Fix rendering of colored glyphs on big font sizes
   
   When using OutlineTextRenderer, fallback to GlyphListPipe for glyphs which doesn't have outlines.
 - 8269806: Fix glyph advance rounding with FM=OFF

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/4798/files
  - new: https://git.openjdk.org/jdk/pull/4798/files/9dbed75f..e8b1adab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=02-03

  Stats: 288 lines in 9 files changed: 154 ins; 100 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/4798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/4798/head:pull/4798

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Sat Jun 25 01:16:43 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Sat, 25 Jun 2022 01:16:43 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v4]
In-Reply-To: <3aUzwJTlKj3o0N9WbF7EHfFB2KwPBA1z5vCsjabSN4U=.f431f660-b8f2-41ab-915a-0014c33fd0d7@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <3aUzwJTlKj3o0N9WbF7EHfFB2KwPBA1z5vCsjabSN4U=.f431f660-b8f2-41ab-915a-0014c33fd0d7@github.com>
Message-ID: <9J2uqNgaQjlG3n98vm__aFcASjJi6uATbjjSHxI7dwA=.ba191d67-740f-4afd-a654-03f471e23bb3@github.com>

On Sat, 25 Jun 2022 01:11:59 GMT, Nikita Gubarkov <duke at openjdk.org> 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
>
> Nikita Gubarkov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8269806: Fix rendering of colored glyphs on big font sizes
>    
>    When using OutlineTextRenderer, fallback to GlyphListPipe for glyphs which doesn't have outlines.
>  - 8269806: Fix glyph advance rounding with FM=OFF

src/java.desktop/share/classes/sun/java2d/pipe/OutlineTextRenderer.java line 75:

> 73:     public void drawString(SunGraphics2D g2d, String str, double x, double y) {
> 74: 
> 75:         StandardGlyphVector sgv = new StandardGlyphVector(g2d.getFont(), str, g2d.getFontRenderContext());

I started using `GlyphVector` instead of `TextLayout` because it gives more consistent look for animated text. For example, earlier text which has ligatures rendered with `drawString` was drawn with ligatures on `OutlineTextRenderer` and without on `GlyphListPipe`, which caused artifacts when text size crosses 100 threshold.

-------------

PR: https://git.openjdk.org/jdk/pull/4798


From psadhukhan at openjdk.org  Mon Jun 27 03:26:57 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 27 Jun 2022 03:26:57 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v5]
In-Reply-To: <2lojbp2WLFbEEIhZVeVIbHU_6g_n3zQHpyKAAU9Jl7E=.1ed34cc5-5c1e-4c45-8657-df36af1ecffe@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <eaIqfbBPgL1ztaV0YUgcV2zF38-eR4XfmNpfAj5NWic=.2ece233e-c6f0-43f2-aa2b-2d9d4441432c@github.com>
 <2lojbp2WLFbEEIhZVeVIbHU_6g_n3zQHpyKAAU9Jl7E=.1ed34cc5-5c1e-4c45-8657-df36af1ecffe@github.com>
Message-ID: <mMPsdv3R1O2pEZmuJGwJfEqds_NlYILW4x3a67G-m2k=.ce4b92a5-d146-4ce7-8d66-fe5a8c2b054a@github.com>

On Fri, 24 Jun 2022 17:52:18 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Right Option Key handling
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaKeyBindings.java line 95:
> 
>> 93:         "alt altgraph LEFT", DefaultEditorKit.previousWordAction,
>> 94:         "alt altgraph RIGHT", DefaultEditorKit.nextWordAction,
>> 95:         "alt UP", DefaultEditorKit.beginLineUpAction,
> 
> I find it utterly bizarre to say we need "altgraph" when macOS doesn't have altgraph - certainly not on the k/bs on current mac books or imacs.
> 
> My take is that the previous fix JDK-8151136 was a mistake and we should have just excluded the test there on macOS.

I also agree.

> src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java line 650:
> 
>> 648:      * upward one line otherwise.
>> 649:      * @see #getActions
>> 650:      */
> 
> What ? We are adding new public API to solve this ? 
> Why is that necessary ?

Not public API..we are adding new editor "actions" if we need to keep previous fix..Without the previous fix JDK-8151136 , it works and we will not need to add these new actions.

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From psadhukhan at openjdk.org  Mon Jun 27 04:11:44 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 27 Jun 2022 04:11:44 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v5]
In-Reply-To: <mMPsdv3R1O2pEZmuJGwJfEqds_NlYILW4x3a67G-m2k=.ce4b92a5-d146-4ce7-8d66-fe5a8c2b054a@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <eaIqfbBPgL1ztaV0YUgcV2zF38-eR4XfmNpfAj5NWic=.2ece233e-c6f0-43f2-aa2b-2d9d4441432c@github.com>
 <2lojbp2WLFbEEIhZVeVIbHU_6g_n3zQHpyKAAU9Jl7E=.1ed34cc5-5c1e-4c45-8657-df36af1ecffe@github.com>
 <mMPsdv3R1O2pEZmuJGwJfEqds_NlYILW4x3a67G-m2k=.ce4b92a5-d146-4ce7-8d66-fe5a8c2b054a@github.com>
Message-ID: <uviJNv5EHZ9vFoaw-OYLDaOV85Ulp7jdH9KTmGWAPrc=.92516665-26d4-4b93-a09e-d5fb7885e68c@github.com>

On Mon, 27 Jun 2022 03:24:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java line 650:
>> 
>>> 648:      * upward one line otherwise.
>>> 649:      * @see #getActions
>>> 650:      */
>> 
>> What ? We are adding new public API to solve this ? 
>> Why is that necessary ?
>
> Not public API..we are adding new editor "actions" if we need to keep previous fix..Without the previous fix JDK-8151136 , it works and we will not need to add these new actions.

Actually, we do need the up/down new "action" even without JDK-8151136 fix...it was never working before..
We dont have action that will move the caret to begin/end of line and move up/down one line (if it's already at the begin/end).
It was either the former or the latter..

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From psadhukhan at openjdk.org  Mon Jun 27 07:09:03 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 27 Jun 2022 07:09:03 GMT
Subject: RFR: 7124313: [macosx] Swing Popups should overlap taskbar
Message-ID: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>

In macos, popups does not overlap taskbar unlike windows, as can be seen here  in "Settings"
so we can omit this test from macOS run.

![image](https://urldefense.com/v3/__https://user-images.githubusercontent.com/43534309/175878607-6435da8c-ae32-4512-9cbc-0b449637e93f.png__;!!ACWV5N9M2RV99hQ!PSbIus5gdNAdguS0ywCmpN44iRfQQtdjL5boscGU5AyxhOJdQbpokUwhEahODsh1whMPKxgOGNpwBOgl7LNyMaas7zTC9g$ )

-------------

Commit messages:
 - 7124313: [macosx] Swing Popups should overlap taskbar

Changes: https://git.openjdk.org/jdk/pull/9294/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9294&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7124313
  Stats: 15 lines in 2 files changed: 10 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9294.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9294/head:pull/9294

PR: https://git.openjdk.org/jdk/pull/9294


From asotona at openjdk.org  Mon Jun 27 08:53:01 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Jun 2022 08:53:01 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v13]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <TYFZimuHBQWcdrZsDq3i-o6gLmjjC0Ca8R8BdDsGX3Y=.5bf9fe73-3a01-4b5c-ad3d-dc8d81093d0a@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - ... and 7 more: https://git.openjdk.org/jdk/compare/7905788e...cab6ce59

-------------

Changes: https://git.openjdk.org/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=12
  Stats: 442 lines in 17 files changed: 440 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.org/jdk/pull/8599


From asotona at openjdk.org  Mon Jun 27 09:25:58 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Jun 2022 09:25:58 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v14]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <cg1cvzaYh2RZByrgkAI6sPvZ1J0B4JAOiqVe4ib_e34=.9ec074a6-f3c0-4226-8b8c-8064fefd393b@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8599/files
  - new: https://git.openjdk.org/jdk/pull/8599/files/cab6ce59..6f32938d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=12-13

  Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.org/jdk/pull/8599


From jwilhelm at openjdk.org  Mon Jun 27 11:55:51 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 27 Jun 2022 11:55:51 GMT
Subject: RFR: Merge jdk19
Message-ID: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>

Forwardport JDK 19 -> JDK 20

-------------

Commit messages:
 - Merge
 - 8289079: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed with "RuntimeException: Test failed"
 - 8247407: tools/jlink/plugins/CompressorPluginTest.java test failing
 - 8288983: broken link in com.sun.net.httpserver.SimpleFileServer
 - 8289044: ARM32: missing LIR_Assembler::cmove metadata type support
 - 8288120: VerifyError with JEP 405 pattern match
 - 8288528: broken links in java.desktop
 - 8288080: (fc) FileChannel::map for MemorySegments should state it always throws UOE
 - 8287076: Document.normalizeDocument() produces different results
 - 8288589: Files.readString ignores encoding errors for UTF-16
 - ... and 2 more: https://git.openjdk.org/jdk/compare/7905788e...9579cc05

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9296&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9296&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9296/files
  Stats: 366 lines in 24 files changed: 274 ins; 41 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/9296.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9296/head:pull/9296

PR: https://git.openjdk.org/jdk/pull/9296


From aivanov at openjdk.org  Mon Jun 27 12:26:40 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 27 Jun 2022 12:26:40 GMT
Subject: RFR: JDK-8288993: Make AwtFramePackTest generic by removing
 @requires tag [v2]
In-Reply-To: <C1A1WnQJzK3HP-H28uac1UIBtWciV29Kdfd-NXj4CVM=.a817ee7c-72ff-43ff-8374-179d4396e6a3@github.com>
References: <r5HklzGTf9N2fzKgd1sQDObs44rRLp8_iVU7gkOXrLE=.a6c2ceb3-8ec2-4438-9eb8-fc475f27c56b@github.com>
 <C1A1WnQJzK3HP-H28uac1UIBtWciV29Kdfd-NXj4CVM=.a817ee7c-72ff-43ff-8374-179d4396e6a3@github.com>
Message-ID: <7i3c0A140_EoLZwym0Wx58s-F9_VPlHqsYwp72ncEWQ=.41ef010d-b7db-465c-a15f-465096471814@github.com>

On Fri, 24 Jun 2022 00:53:35 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The following test was changed to generic based on this [Review Comment](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9118*discussion_r897553780__;Iw!!ACWV5N9M2RV99hQ!OD1nHoXjAVjPcd0j0DcrLavC4sicxaeyU7EjyHZ14_HypMbvs7QScxAizrd2r39W1f5_MCu0JziDJQxLmQ7A0ZtO8A$ ) and as the condition `frame.getSize() == frame.getPreferredSize() ` should hold on all platforms when frame.pack() is used.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed uiScale

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9248


From dnguyen at openjdk.org  Mon Jun 27 12:40:16 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 27 Jun 2022 12:40:16 GMT
Subject: Integrated: 8012675: javax.swing.JEditorPane is unclear on the
 handling of unsupported HTML script tags
In-Reply-To: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
References: <qmeQByBZ9whwx4cE_YP4EhPWnRSjewc9iUTNYjU0wPw=.a3657a26-4f4d-4d77-96be-ced60b67698e@github.com>
Message-ID: <tLcRJ0E2v2hiqK4HtH4WkKXu-xjjBY7d5ZWPsGefHwE=.667fb583-6ea4-48e4-bbb0-a521b3c80aae@github.com>

On Fri, 11 Feb 2022 19:20:16 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc.

This pull request has now been integrated.

Changeset: 64f95cfb
Author:    Damon Nguyen <dnguyen at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64f95cfb32233f74faf81b9cfaf824c6b3f8346b
Stats:     110 lines in 2 files changed: 110 ins; 0 del; 0 mod

8012675: javax.swing.JEditorPane is unclear on the handling of unsupported HTML script tags

Reviewed-by: prr, aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/7446


From tr at openjdk.org  Mon Jun 27 16:38:39 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 27 Jun 2022 16:38:39 GMT
Subject: RFR: 8288707: javax/swing/JToolBar/4529206/bug4529206.java:
 setFloating does not work correctly
In-Reply-To: <RPkNNkTmYAcBhA67ENFKO2omtGISEideYdn_oyo51Kc=.8fa3ec08-fcb2-4c72-a78b-4b52f5010e00@github.com>
References: <RPkNNkTmYAcBhA67ENFKO2omtGISEideYdn_oyo51Kc=.8fa3ec08-fcb2-4c72-a78b-4b52f5010e00@github.com>
Message-ID: <9ltHC17l1IuSFgiX4FxXm2tQ85mMjG4yYL2vejqCAxI=.59ec83e0-8159-4810-889f-d4733183b65c@github.com>

On Fri, 24 Jun 2022 03:42:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing intermittently around 1 or 2 out of 30 runs. 
> Fixed by adding stability code, wait for a sec after frame is visible, set frame to center.
> Modified test has run at least 50 times in all platforms and 100 times in linux (where it is seen intermittently) without any issue.

How does` frame.isFocused()` indicate failure test? Can the test case fail status depend on `ui.Floating() == false`..?

-------------

PR: https://git.openjdk.org/jdk/pull/9269


From dmarkov at openjdk.org  Mon Jun 27 16:58:48 2022
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Mon, 27 Jun 2022 16:58:48 GMT
Subject: RFR: JDK-8288993: Make AwtFramePackTest generic by removing
 @requires tag [v2]
In-Reply-To: <C1A1WnQJzK3HP-H28uac1UIBtWciV29Kdfd-NXj4CVM=.a817ee7c-72ff-43ff-8374-179d4396e6a3@github.com>
References: <r5HklzGTf9N2fzKgd1sQDObs44rRLp8_iVU7gkOXrLE=.a6c2ceb3-8ec2-4438-9eb8-fc475f27c56b@github.com>
 <C1A1WnQJzK3HP-H28uac1UIBtWciV29Kdfd-NXj4CVM=.a817ee7c-72ff-43ff-8374-179d4396e6a3@github.com>
Message-ID: <_cSs08FsqNYwdBqon6uVrIcbopdmXMiYCkrBGWT3J_M=.5f46c4f3-d4a5-427d-852a-24d0499895a1@github.com>

On Fri, 24 Jun 2022 00:53:35 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The following test was changed to generic based on this [Review Comment](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9118*discussion_r897553780__;Iw!!ACWV5N9M2RV99hQ!JrM4yW8OP0OG_BKgREXWi9VYzU9Yu9M0mI3HlmjSS2xINvDJn6LplChNN6MH9cpFdQk8Y-EMDRZ3vqCQZ9broVMZNA$ ) and as the condition `frame.getSize() == frame.getPreferredSize() ` should hold on all platforms when frame.pack() is used.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed uiScale

Marked as reviewed by dmarkov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9248


From jwilhelm at openjdk.org  Mon Jun 27 18:32:18 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 27 Jun 2022 18:32:18 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>
References: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>
Message-ID: <QcElHQNvmhWdtuoJp8PQe_xbRrvU3U4EGBqA20EQnPw=.77ba96a7-3560-4cd8-b8ad-0aec9e1ac6ee@github.com>

> Forwardport JDK 19 -> JDK 20

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 146 commits:

 - Merge
 - 8289126: Cleanup unnecessary null comparison before instanceof check in jdk.hotspot.agent
   
   Reviewed-by: ayang, cjplummer
 - 8289078: Make STARTTIME_ANY and STARTTIME_PROCESS_UNKNOWN fields static in ProcessHandleImpl
   
   Reviewed-by: jpai, rriggs, bpb, naoto, iris
 - 8289147: unify os::infinite_sleep on posix platforms
   
   Reviewed-by: mdoerr, kbarrett, dholmes
 - 8266670: Better modeling of access flags in core reflection
   
   Reviewed-by: mchung, rriggs, asotona
 - 8286395: Address possibly lossy conversions in java.security.jgss
   
   Reviewed-by: chegar
 - 8286389: Address possibly lossy conversions in jdk.crypto.ec
   
   Reviewed-by: chegar, xuelei
 - 8288130: compiler error with AP and explicit record accessor
   
   Reviewed-by: jlahoda
 - 8289166: ProblemList tools/jlink/plugins/CompressorPluginTest.java
   
   Reviewed-by: lmesnik, bpb
 - 8289098: clean up ported serviceability/jvmti tests
   
   Reviewed-by: kevinw, sspitsyn
 - ... and 136 more: https://git.openjdk.org/jdk/compare/7e13cdb7...9579cc05

-------------

Changes: https://git.openjdk.org/jdk/pull/9296/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9296&range=01
  Stats: 47784 lines in 1125 files changed: 22921 ins; 12915 del; 11948 mod
  Patch: https://git.openjdk.org/jdk/pull/9296.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9296/head:pull/9296

PR: https://git.openjdk.org/jdk/pull/9296


From jwilhelm at openjdk.org  Mon Jun 27 18:32:18 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 27 Jun 2022 18:32:18 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>
References: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>
Message-ID: <EOnXQGf1n2TS6psge4FEfSaSTM5kHMVXlCOMzBiffUw=.59ead9f8-4337-4c81-8b7b-55e735c78ac6@github.com>

On Mon, 27 Jun 2022 11:49:07 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: d4b040f4
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4b040f42dd0a9100ad1ffa55de4ae4f20e9f182
Stats:     366 lines in 24 files changed: 274 ins; 41 del; 51 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/9296


From serb at openjdk.org  Mon Jun 27 20:25:49 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 27 Jun 2022 20:25:49 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v5]
In-Reply-To: <mMPsdv3R1O2pEZmuJGwJfEqds_NlYILW4x3a67G-m2k=.ce4b92a5-d146-4ce7-8d66-fe5a8c2b054a@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <eaIqfbBPgL1ztaV0YUgcV2zF38-eR4XfmNpfAj5NWic=.2ece233e-c6f0-43f2-aa2b-2d9d4441432c@github.com>
 <2lojbp2WLFbEEIhZVeVIbHU_6g_n3zQHpyKAAU9Jl7E=.1ed34cc5-5c1e-4c45-8657-df36af1ecffe@github.com>
 <mMPsdv3R1O2pEZmuJGwJfEqds_NlYILW4x3a67G-m2k=.ce4b92a5-d146-4ce7-8d66-fe5a8c2b054a@github.com>
Message-ID: <zNYj7hNRvjjkcuwZMWdB5jfYQuORSqZjvr3tqD4bs7s=.daab1253-0c99-4921-98e3-3fd8b226b693@github.com>

On Mon, 27 Jun 2022 03:22:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/com/apple/laf/AquaKeyBindings.java line 95:
>> 
>>> 93:         "alt altgraph LEFT", DefaultEditorKit.previousWordAction,
>>> 94:         "alt altgraph RIGHT", DefaultEditorKit.nextWordAction,
>>> 95:         "alt UP", DefaultEditorKit.beginLineUpAction,
>> 
>> I find it utterly bizarre to say we need "altgraph" when macOS doesn't have altgraph - certainly not on the k/bs on current mac books or imacs.
>> 
>> My take is that the previous fix JDK-8151136 was a mistake and we should have just excluded the test there on macOS.
>
> I also agree.

That's not a mistake, the swing was updated in a few places here and there to support it, for example:
https://bugs.openjdk.org/browse/JDK-8194873

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From serb at openjdk.org  Mon Jun 27 20:25:50 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 27 Jun 2022 20:25:50 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v5]
In-Reply-To: <zNYj7hNRvjjkcuwZMWdB5jfYQuORSqZjvr3tqD4bs7s=.daab1253-0c99-4921-98e3-3fd8b226b693@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <eaIqfbBPgL1ztaV0YUgcV2zF38-eR4XfmNpfAj5NWic=.2ece233e-c6f0-43f2-aa2b-2d9d4441432c@github.com>
 <2lojbp2WLFbEEIhZVeVIbHU_6g_n3zQHpyKAAU9Jl7E=.1ed34cc5-5c1e-4c45-8657-df36af1ecffe@github.com>
 <mMPsdv3R1O2pEZmuJGwJfEqds_NlYILW4x3a67G-m2k=.ce4b92a5-d146-4ce7-8d66-fe5a8c2b054a@github.com>
 <zNYj7hNRvjjkcuwZMWdB5jfYQuORSqZjvr3tqD4bs7s=.daab1253-0c99-4921-98e3-3fd8b226b693@github.com>
Message-ID: <fvBYqKpKDVr14_lc2eBGaiCo38eP0xzS4SLdpoyecB0=.f6b5ef16-55c9-4aea-8ac8-12661ed5ee38@github.com>

On Mon, 27 Jun 2022 20:20:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I also agree.
>
> That's not a mistake, the swing was updated in a few places here and there to support it, for example:
> https://bugs.openjdk.org/browse/JDK-8194873

We could change it back but then we should take care of all that followup changes.

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From serb at openjdk.org  Mon Jun 27 20:26:39 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 27 Jun 2022 20:26:39 GMT
Subject: RFR: JDK-8288993: Make AwtFramePackTest generic by removing
 @requires tag [v2]
In-Reply-To: <C1A1WnQJzK3HP-H28uac1UIBtWciV29Kdfd-NXj4CVM=.a817ee7c-72ff-43ff-8374-179d4396e6a3@github.com>
References: <r5HklzGTf9N2fzKgd1sQDObs44rRLp8_iVU7gkOXrLE=.a6c2ceb3-8ec2-4438-9eb8-fc475f27c56b@github.com>
 <C1A1WnQJzK3HP-H28uac1UIBtWciV29Kdfd-NXj4CVM=.a817ee7c-72ff-43ff-8374-179d4396e6a3@github.com>
Message-ID: <MGx-LXQf9-S9m9_Cm8PEXe7byQZqDGPYmcWRK91M3KM=.4d3447bb-961b-46b3-8127-b0adfa487c51@github.com>

On Fri, 24 Jun 2022 00:53:35 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The following test was changed to generic based on this [Review Comment](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9118*discussion_r897553780__;Iw!!ACWV5N9M2RV99hQ!LHfhNGNhR2w8MuFyO5LWzC2K5BvqXSX7-n7TTtENKtBsy2XP7gxLpoBe16dgydwR0ajqoEEvDT_OzG4hpbXSrA$ ) and as the condition `frame.getSize() == frame.getPreferredSize() ` should hold on all platforms when frame.pack() is used.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed uiScale

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9248


From serb at openjdk.org  Mon Jun 27 20:30:45 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 27 Jun 2022 20:30:45 GMT
Subject: RFR: 8272998: ImageIO.read() throws incorrect exception type
In-Reply-To: <pyd50p5WqN6Dj0gtJsuo7PgCtdYVFqMIKpbMr7na97s=.c5c64abe-f7cd-498f-979a-221a56111887@github.com>
References: <7P_RTUjGWttc7Wpknqa7CCPgNIssyX4xT--MjQ_R5po=.be6078e7-bb89-4b23-9b55-6d8fe93c70f6@github.com>
 <RCPQz7Uzpx-rTJqjcp4o0GsahxabKIw1-_VRO6NvLe0=.b6c6b8cf-b324-473a-b102-beb1e4ee6223@github.com>
 <pyd50p5WqN6Dj0gtJsuo7PgCtdYVFqMIKpbMr7na97s=.c5c64abe-f7cd-498f-979a-221a56111887@github.com>
Message-ID: <JP6PI6zNWemDReNBflJsBeoMFGbvUbYQxHR08JZe6Us=.0163e85c-362b-42d7-bcf2-adb2df43aeec@github.com>

On Tue, 21 Jun 2022 18:25:00 GMT, Phil Race <prr at openjdk.org> wrote:

> Other exception types are possible or very difficult to prove they won't be thrown anprop if it ever did happen
we'd be back here

But then it will mean that the "read" thrown wrong exceptions, Isn't this just hiding the actual bug?

-------------

PR: https://git.openjdk.org/jdk/pull/9113


From honkar at openjdk.org  Mon Jun 27 20:33:38 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 27 Jun 2022 20:33:38 GMT
Subject: RFR: 8288444: Remove the workaround for frame.pack() in
 ModalDialogTest
In-Reply-To: <88CU8XufxULaqu9xL-G581LBMSlsAR9TU_fuKspZs20=.e576f3b0-e3ff-4037-9cb9-a92bf204cb02@github.com>
References: <88CU8XufxULaqu9xL-G581LBMSlsAR9TU_fuKspZs20=.e576f3b0-e3ff-4037-9cb9-a92bf204cb02@github.com>
Message-ID: <ycUeY3ds56yRJ-BRreFiLcOTcpsRDPZ_RQ-3zaUGPvI=.173cd9be-be54-45b1-9b58-fb101c2cf3fb@github.com>

On Fri, 24 Jun 2022 22:12:35 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Previously frame.pack() was called twice as a workaround  AWT frame sizing issue in this particular test case on Windows. This issue was fixed **[JDK-8265586](https://bugs.openjdk.org/browse/JDK-8265586)** and hence the workaround is being removed from this test.
> 
> PassFailJFrame is being used as the test framework. 
> 
> **Proposed change related to PassFailJFrame Test framework**
> 
> Instead of creating separate methods to handle AWT Windows as well as Frames, method signatures - [**PassFailJFrame.positionTestFrame()**](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/53b37fe1535388eb14e04c620a6b0118ed8884a0/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java*L271__;Iw!!ACWV5N9M2RV99hQ!O_tc71pCH8M_I8Ag28EQQ6aYJOFaEVGpuhafqNBZmr6G1mobn57dnkRIOY-RZ-tZccq7FhnMayruH-3alhdIk_q5$ ) and [**PassFailJFrame.addTestFrame()**](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/53b37fe1535388eb14e04c620a6b0118ed8884a0/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java*L294__;Iw!!ACWV5N9M2RV99hQ!O_tc71pCH8M_I8Ag28EQQ6aYJOFaEVGpuhafqNBZmr6G1mobn57dnkRIOY-RZ-tZccq7FhnMayruH-3all_VbfvZ$ ) can be changed to take in Window as input parameter instead of Frame, since Window is a superclass, this would allow the test frame to be a Window/Frame/Dialog and not be restricted to a Frame, additionally would allow proper disposal of windows added to the PassFailJFrame.

The proposed changes for PassFailJFrame are being tracked through: [JDK-8289238](https://bugs.openjdk.org/browse/JDK-8289238)

-------------

PR: https://git.openjdk.org/jdk/pull/9286


From serb at openjdk.org  Mon Jun 27 20:38:43 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 27 Jun 2022 20:38:43 GMT
Subject: RFR: 8288707: javax/swing/JToolBar/4529206/bug4529206.java:
 setFloating does not work correctly
In-Reply-To: <RPkNNkTmYAcBhA67ENFKO2omtGISEideYdn_oyo51Kc=.8fa3ec08-fcb2-4c72-a78b-4b52f5010e00@github.com>
References: <RPkNNkTmYAcBhA67ENFKO2omtGISEideYdn_oyo51Kc=.8fa3ec08-fcb2-4c72-a78b-4b52f5010e00@github.com>
Message-ID: <-onCr-4TWj-vsMTgKCIWnmoBCyqH3lXmzXHJFSAXoNw=.f6e0e4b7-c662-4c35-94c2-14963e351d98@github.com>

On Fri, 24 Jun 2022 03:42:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing intermittently around 1 or 2 out of 30 runs. 
> Fixed by adding stability code, wait for a sec after frame is visible, set frame to center.
> Modified test has run at least 50 times in all platforms and 100 times in linux (where it is seen intermittently) without any issue.

Is it possible to check that the initial bug 4529206 can be verified by the updated test?

-------------

PR: https://git.openjdk.org/jdk/pull/9269


From serb at openjdk.org  Mon Jun 27 20:49:43 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 27 Jun 2022 20:49:43 GMT
Subject: RFR: 7124313: [macosx] Swing Popups should overlap taskbar
In-Reply-To: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
References: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
Message-ID: <HlGIDPiB0f3Mq_JGq6sd0qpEB_4nIt92bt0385rv5go=.8221c450-19f7-41bc-92af-119bdb94feb3@github.com>

On Mon, 27 Jun 2022 07:01:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In macos, popups does not overlap taskbar unlike windows, as can be seen here  in "Settings"
> so we can omit this test from macOS run.
> 
> ![image](https://urldefense.com/v3/__https://user-images.githubusercontent.com/43534309/175878607-6435da8c-ae32-4512-9cbc-0b449637e93f.png__;!!ACWV5N9M2RV99hQ!JsSLvvOHs6BQXvZeuB66RGaeKJ7VU6Jcekj0cvyNF_J6ZeT4UE5TcYoxyxth_vaQcxdJdaVQri3uvj0as6xQ8g$ )

An initial bug 6580930 said that the menu should be big enough to overlap the taskbar. I tried a simple example and it seems that if the popup is big enough(hundred of items) it will overlap taskbar. please double check that.

-------------

PR: https://git.openjdk.org/jdk/pull/9294


From honkar at openjdk.org  Mon Jun 27 21:04:56 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 27 Jun 2022 21:04:56 GMT
Subject: Integrated: JDK-8288993: Make AwtFramePackTest generic by removing
 @requires tag
In-Reply-To: <r5HklzGTf9N2fzKgd1sQDObs44rRLp8_iVU7gkOXrLE=.a6c2ceb3-8ec2-4438-9eb8-fc475f27c56b@github.com>
References: <r5HklzGTf9N2fzKgd1sQDObs44rRLp8_iVU7gkOXrLE=.a6c2ceb3-8ec2-4438-9eb8-fc475f27c56b@github.com>
Message-ID: <XG1ZqXMswoUUKbLypsw4LhOUTeiV2IoP1DNXdkFt8QQ=.f2b60063-baff-4367-ad36-e746b2aeb318@github.com>

On Wed, 22 Jun 2022 18:50:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> The following test was changed to generic based on this [Review Comment](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9118*discussion_r897553780__;Iw!!ACWV5N9M2RV99hQ!ORteC9U3hWXGSP9QFb9HQ3Ec2ELJfRsxaB5wzYCtAXr8pGCNMw901OB4rDkseaX66O1IgBclzcB214GZi8ds29jN$ ) and as the condition `frame.getSize() == frame.getPreferredSize() ` should hold on all platforms when frame.pack() is used.

This pull request has now been integrated.

Changeset: 40bf3b11
Author:    Harshitha Onkar <honkar at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/40bf3b11679f1d4e9418c64a10fe6104e88086f1
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8288993: Make AwtFramePackTest generic by removing @requires tag

Reviewed-by: dmarkov, aivanov, serb

-------------

PR: https://git.openjdk.org/jdk/pull/9248


From serb at openjdk.org  Mon Jun 27 21:44:40 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 27 Jun 2022 21:44:40 GMT
Subject: RFR: 8272998: ImageIO.read() throws incorrect exception type
In-Reply-To: <JP6PI6zNWemDReNBflJsBeoMFGbvUbYQxHR08JZe6Us=.0163e85c-362b-42d7-bcf2-adb2df43aeec@github.com>
References: <7P_RTUjGWttc7Wpknqa7CCPgNIssyX4xT--MjQ_R5po=.be6078e7-bb89-4b23-9b55-6d8fe93c70f6@github.com>
 <RCPQz7Uzpx-rTJqjcp4o0GsahxabKIw1-_VRO6NvLe0=.b6c6b8cf-b324-473a-b102-beb1e4ee6223@github.com>
 <pyd50p5WqN6Dj0gtJsuo7PgCtdYVFqMIKpbMr7na97s=.c5c64abe-f7cd-498f-979a-221a56111887@github.com>
 <JP6PI6zNWemDReNBflJsBeoMFGbvUbYQxHR08JZe6Us=.0163e85c-362b-42d7-bcf2-adb2df43aeec@github.com>
Message-ID: <tPhtRtrEkMVQAR3XHGgrja8FAQF7DjzH6zmEFd1pPCY=.c981fbd7-414b-41a9-80b1-7f4cd524bd58@github.com>

On Mon, 27 Jun 2022 20:27:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I did comment on this in the bug and the PR description.
>> Other exception types are possible or very difficult to prove they won't be thrown anprop if it ever did happen
>> we'd be back here. So this seems like the best to thing to do since we do not want to propagate them.
>
>> Other exception types are possible or very difficult to prove they won't be thrown anprop if it ever did happen
> we'd be back here
> 
> But then it will mean that the "read" thrown wrong exceptions, Isn't this just hiding the actual bug?

In the end, the ImageIO method we change is just a wrapper for getting and using the reader, and that unexpected exception could be thrown if the readers are used directly via a similar public API.

-------------

PR: https://git.openjdk.org/jdk/pull/9113


From prr at openjdk.org  Mon Jun 27 21:59:38 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 27 Jun 2022 21:59:38 GMT
Subject: RFR: 8272998: ImageIO.read() throws incorrect exception type
In-Reply-To: <tPhtRtrEkMVQAR3XHGgrja8FAQF7DjzH6zmEFd1pPCY=.c981fbd7-414b-41a9-80b1-7f4cd524bd58@github.com>
References: <7P_RTUjGWttc7Wpknqa7CCPgNIssyX4xT--MjQ_R5po=.be6078e7-bb89-4b23-9b55-6d8fe93c70f6@github.com>
 <RCPQz7Uzpx-rTJqjcp4o0GsahxabKIw1-_VRO6NvLe0=.b6c6b8cf-b324-473a-b102-beb1e4ee6223@github.com>
 <pyd50p5WqN6Dj0gtJsuo7PgCtdYVFqMIKpbMr7na97s=.c5c64abe-f7cd-498f-979a-221a56111887@github.com>
 <JP6PI6zNWemDReNBflJsBeoMFGbvUbYQxHR08JZe6Us=.0163e85c-362b-42d7-bcf2-adb2df43aeec@github.com>
 <tPhtRtrEkMVQAR3XHGgrja8FAQF7DjzH6zmEFd1pPCY=.c981fbd7-414b-41a9-80b1-7f4cd524bd58@github.com>
Message-ID: <vqA4_ai6rzbcMb6XA5vsLKYGp1deVFsA1JsEiRxkVyc=.7988a076-bf7f-432a-9658-bcdb94ede4bd@github.com>

On Mon, 27 Jun 2022 21:41:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Other exception types are possible or very difficult to prove they won't be thrown anprop if it ever did happen
>> we'd be back here
>> 
>> But then it will mean that the "read" thrown wrong exceptions, Isn't this just hiding the actual bug?
>
> In the end, the ImageIO method we change is just a wrapper for getting and using the reader, and that unexpected exception could be thrown if the readers are used directly via a similar public API.

It is a wrapper that is intended to hide lots of details - such as this.
A sophisticated app which wants to use ImageReader.read() should be ready to handle those
An app that just wants a quick and easy API with no random exceptions wants ImageIO.read().
And as I said the exception is wrapped so it can still be inspected.

-------------

PR: https://git.openjdk.org/jdk/pull/9113


From serb at openjdk.org  Tue Jun 28 00:55:22 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Jun 2022 00:55:22 GMT
Subject: [jdk19] RFR: 8288854: getLocalGraphicsEnvironment() on for
 multi-screen setups throws exception NPE
Message-ID: <rBvFremdQsswOG5ynfNKjOFVDStHLAmeSgVIq8y6MrI=.dfa5031f-3b70-467e-8819-a3c8fc07e81b@github.com>

This is the fix for a copy-paste error. The fix JDK-8076313 replaced the usage of the "screens" array from the parent class to the "devices" where the list of devices is now maintained. Since "screens" array is never used nor initialized its usage caused an NPE. That check was copied as-is, while it should use the actual number of screen devices requested early in that method.

The bug is rarely reproduced because in single screen configuration the main screen is usually 0, and in the multiscreen configuration Xinerama is usually active so the main screen is also 0 => the second part of the "if" statement is not executed.

I have validated the fix by the SwingSet, I also executed desktop tests in that config and found that even though this particular bug is fixed we still have many issues there, around ~100 tests failed.

-------------

Commit messages:
 - JDK-8288854

Changes: https://git.openjdk.org/jdk19/pull/81/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=81&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288854
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk19/pull/81.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/81/head:pull/81

PR: https://git.openjdk.org/jdk19/pull/81


From honkar at openjdk.org  Tue Jun 28 01:08:15 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 28 Jun 2022 01:08:15 GMT
Subject: RFR: JDK-8289238: Refactoring changes to PassFailJFrame Test Framework
Message-ID: <_SkmPalpZpi6t0eCeviOwNOoqE3Sq_tisiYSJXIvrSs=.12cb6181-116b-44b8-9c6e-aff6efc34132@github.com>

Currently PassFailJFrame.positionTestFrame() and PassFailJFrame.addTestFrame() take Frame as input parameter, this has been changed to Window.

Refactored the above method names to reflect the functionality & input parameter type -
addTestWindow(), positionTestWindow()

Additionally added test fail reason to `forceFail()` to avoid NPE.

Benefits of the change -

- Since Window is a parent class, this would allow the test frame to be a Window/Frame/Dialog and not be restricted to a Frame.
- Code reusability - no need to have separate methods to manage Frame and Window
- Additionally it would allow proper clean-up of window and its container subclasses which are added to the PassFailJFrame.

-------------

Commit messages:
 - PassFailJFrame refactoring changes

Changes: https://git.openjdk.org/jdk/pull/9300/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9300&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289238
  Stats: 41 lines in 8 files changed: 3 ins; 3 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/9300.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9300/head:pull/9300

PR: https://git.openjdk.org/jdk/pull/9300


From psadhukhan at openjdk.org  Tue Jun 28 04:19:44 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Jun 2022 04:19:44 GMT
Subject: RFR: 8288707: javax/swing/JToolBar/4529206/bug4529206.java:
 setFloating does not work correctly
In-Reply-To: <RPkNNkTmYAcBhA67ENFKO2omtGISEideYdn_oyo51Kc=.8fa3ec08-fcb2-4c72-a78b-4b52f5010e00@github.com>
References: <RPkNNkTmYAcBhA67ENFKO2omtGISEideYdn_oyo51Kc=.8fa3ec08-fcb2-4c72-a78b-4b52f5010e00@github.com>
Message-ID: <VIL_q2he3qEmxX_Z5w5w0W2Sv746gKJHlMpQwPhi5IM=.a4065c55-ca15-4c66-aae1-7a1444bc116c@github.com>

On Fri, 24 Jun 2022 03:42:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing intermittently around 1 or 2 out of 30 runs. 
> Fixed by adding stability code, wait for a sec after frame is visible, set frame to center.
> Modified test has run at least 50 times in all platforms and 100 times in linux (where it is seen intermittently) without any issue.

Yes, initial bug still fails with the updated test

-------------

PR: https://git.openjdk.org/jdk/pull/9269


From psadhukhan at openjdk.org  Tue Jun 28 04:51:40 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Jun 2022 04:51:40 GMT
Subject: RFR: 7124313: [macosx] Swing Popups should overlap taskbar
In-Reply-To: <HlGIDPiB0f3Mq_JGq6sd0qpEB_4nIt92bt0385rv5go=.8221c450-19f7-41bc-92af-119bdb94feb3@github.com>
References: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
 <HlGIDPiB0f3Mq_JGq6sd0qpEB_4nIt92bt0385rv5go=.8221c450-19f7-41bc-92af-119bdb94feb3@github.com>
Message-ID: <hyAWm8kSgiWe660i-TNJOnFBB56nD9RQTVP01lU49bc=.87789d34-cd22-455a-82bb-ae44b031ae44@github.com>

On Mon, 27 Jun 2022 20:45:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> An initial bug 6580930 said that the menu should be big enough to overlap the taskbar. I tried a simple example and it seems that if the popup is big enough(hundred of items) it will overlap taskbar. please double check that.

It says for windows and linux only

>  In native applications for Windows, if a popup is big enough
> it can overlap the taskbar (see the image attached)
> the same behaiviour can be seen for GTK on *nix

For the existing testcase, it overlaps the taskbar in windows/linux but it does not for macos so I have excluded for macos.
I dont see any native macos popup overlap the taskbar..
if we have to put hundred of items to overlap the taskbar, it might be a bug in macos which needs to be dealt with separately but this testcase, as it is, is not applicable for macos.

-------------

PR: https://git.openjdk.org/jdk/pull/9294


From psadhukhan at openjdk.org  Tue Jun 28 04:57:39 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Jun 2022 04:57:39 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v5]
In-Reply-To: <fvBYqKpKDVr14_lc2eBGaiCo38eP0xzS4SLdpoyecB0=.f6b5ef16-55c9-4aea-8ac8-12661ed5ee38@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <eaIqfbBPgL1ztaV0YUgcV2zF38-eR4XfmNpfAj5NWic=.2ece233e-c6f0-43f2-aa2b-2d9d4441432c@github.com>
 <2lojbp2WLFbEEIhZVeVIbHU_6g_n3zQHpyKAAU9Jl7E=.1ed34cc5-5c1e-4c45-8657-df36af1ecffe@github.com>
 <mMPsdv3R1O2pEZmuJGwJfEqds_NlYILW4x3a67G-m2k=.ce4b92a5-d146-4ce7-8d66-fe5a8c2b054a@github.com>
 <zNYj7hNRvjjkcuwZMWdB5jfYQuORSqZjvr3tqD4bs7s=.daab1253-0c99-4921-98e3-3fd8b226b693@github.com>
 <fvBYqKpKDVr14_lc2eBGaiCo38eP0xzS4SLdpoyecB0=.f6b5ef16-55c9-4aea-8ac8-12661ed5ee38@github.com>
Message-ID: <tX29M6BktlMY1wairp7u5zIbdZyjZjJk1OyR24OUEfI=.d2f957db-bf91-4ea5-a12e-b03430e25ba3@github.com>

On Mon, 27 Jun 2022 20:21:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> That's not a mistake, the swing was updated in a few places here and there to support it, for example:
>> https://bugs.openjdk.org/browse/JDK-8194873
>
> We could change it back but then we should take care of all that followup changes.

> That's not a mistake, the swing was updated in a few places here and there to support it, for example: https://bugs.openjdk.org/browse/JDK-8194873

I dont think @prrace and me are contesting need of ALT_GRAPH in swing, which was fixed by the above bug..I guess it was being contested for macos only so we are not going to revert 8194873 but only 8151136 (which was done to convert right alt to altgraph for macos)

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From serb at openjdk.org  Tue Jun 28 05:40:41 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Jun 2022 05:40:41 GMT
Subject: RFR: 7124313: [macosx] Swing Popups should overlap taskbar
In-Reply-To: <hyAWm8kSgiWe660i-TNJOnFBB56nD9RQTVP01lU49bc=.87789d34-cd22-455a-82bb-ae44b031ae44@github.com>
References: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
 <HlGIDPiB0f3Mq_JGq6sd0qpEB_4nIt92bt0385rv5go=.8221c450-19f7-41bc-92af-119bdb94feb3@github.com>
 <hyAWm8kSgiWe660i-TNJOnFBB56nD9RQTVP01lU49bc=.87789d34-cd22-455a-82bb-ae44b031ae44@github.com>
Message-ID: <al4Gxs8vDwAwhb48NCZU5RBSrpAsxkfdJ8S0XqjWoJc=.7101b5e6-f60d-4a4f-834b-7f0e2b5f916f@github.com>

On Tue, 28 Jun 2022 04:48:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It says for windows and linux only

Are you sure? It has macOS specific code added as part of the https://bugs.openjdk.org/browse/JDK-8196096

> Also, if we put hundred of items in popup , it fails in windows/linux so i wish not to tinker with this existing testcase

I think for the large menu it was fixed by the changed mentioned [here](https://bugs.openjdk.org/browse/JDK-7124313?focusedCommentId=12546867&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12546867) So now the popup menu overlap the taskbar on macOS if it is big enough and will not be located under it.

-------------

PR: https://git.openjdk.org/jdk/pull/9294


From psadhukhan at openjdk.org  Tue Jun 28 05:57:39 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Jun 2022 05:57:39 GMT
Subject: RFR: 7124313: [macosx] Swing Popups should overlap taskbar
In-Reply-To: <al4Gxs8vDwAwhb48NCZU5RBSrpAsxkfdJ8S0XqjWoJc=.7101b5e6-f60d-4a4f-834b-7f0e2b5f916f@github.com>
References: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
 <HlGIDPiB0f3Mq_JGq6sd0qpEB_4nIt92bt0385rv5go=.8221c450-19f7-41bc-92af-119bdb94feb3@github.com>
 <hyAWm8kSgiWe660i-TNJOnFBB56nD9RQTVP01lU49bc=.87789d34-cd22-455a-82bb-ae44b031ae44@github.com>
 <al4Gxs8vDwAwhb48NCZU5RBSrpAsxkfdJ8S0XqjWoJc=.7101b5e6-f60d-4a4f-834b-7f0e2b5f916f@github.com>
Message-ID: <2qXZAm6eeU49u8tO8XD7apBVwQfCrtD4QdJ4ZwOmTTg=.f0083fda-38c9-489b-ad6a-f8ba8d988c25@github.com>

On Tue, 28 Jun 2022 05:38:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Are you sure? It has macOS specific code added as part of the https://bugs.openjdk.org/browse/JDK-8196096

It deproblemlist it for windows. macos specific code was added to check for heavyweight poup in non-macos platform which we dont have for macos for which have existing bug [JDK-7184956](https://bugs.openjdk.org/browse/JDK-7184956)

-------------

PR: https://git.openjdk.org/jdk/pull/9294


From psadhukhan at openjdk.org  Tue Jun 28 06:07:40 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Jun 2022 06:07:40 GMT
Subject: RFR: 7124313: [macosx] Swing Popups should overlap taskbar
In-Reply-To: <al4Gxs8vDwAwhb48NCZU5RBSrpAsxkfdJ8S0XqjWoJc=.7101b5e6-f60d-4a4f-834b-7f0e2b5f916f@github.com>
References: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
 <HlGIDPiB0f3Mq_JGq6sd0qpEB_4nIt92bt0385rv5go=.8221c450-19f7-41bc-92af-119bdb94feb3@github.com>
 <hyAWm8kSgiWe660i-TNJOnFBB56nD9RQTVP01lU49bc=.87789d34-cd22-455a-82bb-ae44b031ae44@github.com>
 <al4Gxs8vDwAwhb48NCZU5RBSrpAsxkfdJ8S0XqjWoJc=.7101b5e6-f60d-4a4f-834b-7f0e2b5f916f@github.com>
Message-ID: <OivbfPyGy7u60DCp-eKipirKEhAy7ARAgP32YoQJfvc=.94c96847-02b5-465a-8b8a-0e697c8c2130@github.com>

On Tue, 28 Jun 2022 05:38:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I think for the large menu it was fixed by the changed mentioned [here](https://bugs.openjdk.org/browse/JDK-7124313?focusedCommentId=12546867&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12546867) So now the popup menu overlap the taskbar on macOS if it is big enough and will not be located under it.

Dont think so. The comment was made on the same day this bug was filed so it was not working in macos even then.

-------------

PR: https://git.openjdk.org/jdk/pull/9294


From serb at openjdk.org  Tue Jun 28 06:30:43 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Jun 2022 06:30:43 GMT
Subject: RFR: 7124313: [macosx] Swing Popups should overlap taskbar
In-Reply-To: <2qXZAm6eeU49u8tO8XD7apBVwQfCrtD4QdJ4ZwOmTTg=.f0083fda-38c9-489b-ad6a-f8ba8d988c25@github.com>
References: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
 <HlGIDPiB0f3Mq_JGq6sd0qpEB_4nIt92bt0385rv5go=.8221c450-19f7-41bc-92af-119bdb94feb3@github.com>
 <hyAWm8kSgiWe660i-TNJOnFBB56nD9RQTVP01lU49bc=.87789d34-cd22-455a-82bb-ae44b031ae44@github.com>
 <al4Gxs8vDwAwhb48NCZU5RBSrpAsxkfdJ8S0XqjWoJc=.7101b5e6-f60d-4a4f-834b-7f0e2b5f916f@github.com>
 <2qXZAm6eeU49u8tO8XD7apBVwQfCrtD4QdJ4ZwOmTTg=.f0083fda-38c9-489b-ad6a-f8ba8d988c25@github.com>
Message-ID: <4hFttQhPfriFFrJEcJjrwkrK4iWhi8ZLhlsJTxz1Jlw=.55e8231d-a508-41fd-b852-4b0126497b31@github.com>

On Tue, 28 Jun 2022 05:53:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > Are you sure? It has macOS specific code added as part of the https://bugs.openjdk.org/browse/JDK-8196096
> 
> It deproblemlist it for windows. macos specific code was added to check for heavyweight poup in non-macos platform which we dont have for macos for which have existing bug [JDK-7184956](https://bugs.openjdk.org/browse/JDK-7184956)

That code was not added, it was excluded from executing on macOS. And as the reason for that excluded code the [JDK-7184956](https://bugs.openjdk.org/browse/JDK-7184956) was referenced. But current failure is different. On my system it fails due to wrong "frame" location, it jumps from the "expected" location. In Swing that expected location is calculated by the JPopupMenu.adjustPopupLocationToFitScreen so we can mimic that logic in the test. Or we can test the large menu to check that the popup overlaps the dock.

-------------

PR: https://git.openjdk.org/jdk/pull/9294


From serb at openjdk.org  Tue Jun 28 06:32:54 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Jun 2022 06:32:54 GMT
Subject: RFR: 8288707: javax/swing/JToolBar/4529206/bug4529206.java:
 setFloating does not work correctly
In-Reply-To: <RPkNNkTmYAcBhA67ENFKO2omtGISEideYdn_oyo51Kc=.8fa3ec08-fcb2-4c72-a78b-4b52f5010e00@github.com>
References: <RPkNNkTmYAcBhA67ENFKO2omtGISEideYdn_oyo51Kc=.8fa3ec08-fcb2-4c72-a78b-4b52f5010e00@github.com>
Message-ID: <s2wQnLAmCl1dF545BCFiMNo8IZgw2Xv6xuhRQd5537M=.2611bc0e-c0e3-4015-b564-f5a41f74bf85@github.com>

On Fri, 24 Jun 2022 03:42:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing intermittently around 1 or 2 out of 30 runs. 
> Fixed by adding stability code, wait for a sec after frame is visible, set frame to center.
> Modified test has run at least 50 times in all platforms and 100 times in linux (where it is seen intermittently) without any issue.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9269


From psadhukhan at openjdk.org  Tue Jun 28 06:37:44 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Jun 2022 06:37:44 GMT
Subject: RFR: 7124313: [macosx] Swing Popups should overlap taskbar
In-Reply-To: <4hFttQhPfriFFrJEcJjrwkrK4iWhi8ZLhlsJTxz1Jlw=.55e8231d-a508-41fd-b852-4b0126497b31@github.com>
References: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
 <HlGIDPiB0f3Mq_JGq6sd0qpEB_4nIt92bt0385rv5go=.8221c450-19f7-41bc-92af-119bdb94feb3@github.com>
 <hyAWm8kSgiWe660i-TNJOnFBB56nD9RQTVP01lU49bc=.87789d34-cd22-455a-82bb-ae44b031ae44@github.com>
 <al4Gxs8vDwAwhb48NCZU5RBSrpAsxkfdJ8S0XqjWoJc=.7101b5e6-f60d-4a4f-834b-7f0e2b5f916f@github.com>
 <2qXZAm6eeU49u8tO8XD7apBVwQfCrtD4QdJ4ZwOmTTg=.f0083fda-38c9-489b-ad6a-f8ba8d988c25@github.com>
 <4hFttQhPfriFFrJEcJjrwkrK4iWhi8ZLhlsJTxz1Jlw=.55e8231d-a508-41fd-b852-4b0126497b31@github.com>
Message-ID: <iV4rDjba1_SQm88SgEMegnBM6DOXaD3bz7LsLH3MpHM=.e9206889-6b62-4000-b55a-e09175c61933@github.com>

On Tue, 28 Jun 2022 06:27:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > > Are you sure? It has macOS specific code added as part of the https://bugs.openjdk.org/browse/JDK-8196096
> > 
> > 
> > It deproblemlist it for windows. macos specific code was added to check for heavyweight poup in non-macos platform which we dont have for macos for which have existing bug [JDK-7184956](https://bugs.openjdk.org/browse/JDK-7184956)
> 
> That code was not added, it was excluded from executing on macOS. And as the reason for that excluded code the [JDK-7184956](https://bugs.openjdk.org/browse/JDK-7184956) was referenced. But current failure is different. On my system it fails due to wrong "frame" location, it jumps from the "expected" location. In Swing that expected location is calculated by the JPopupMenu.adjustPopupLocationToFitScreen so we can mimic that logic in the test. Or we can test the large menu to check that the popup overlaps the dock.

I am not sure why we should tinker with existing testcase when the similar popupmenu with 7 items in "Settings" (as shown in bugfix description) does not overlap the taskbar in native.

@prrace Can we please ask Apple if this behaviour is a bug in Java that we dont overlap the taskbar for small popupmenu
or is it expected?

-------------

PR: https://git.openjdk.org/jdk/pull/9294


From serb at openjdk.org  Tue Jun 28 06:42:51 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Jun 2022 06:42:51 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v5]
In-Reply-To: <tX29M6BktlMY1wairp7u5zIbdZyjZjJk1OyR24OUEfI=.d2f957db-bf91-4ea5-a12e-b03430e25ba3@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <eaIqfbBPgL1ztaV0YUgcV2zF38-eR4XfmNpfAj5NWic=.2ece233e-c6f0-43f2-aa2b-2d9d4441432c@github.com>
 <2lojbp2WLFbEEIhZVeVIbHU_6g_n3zQHpyKAAU9Jl7E=.1ed34cc5-5c1e-4c45-8657-df36af1ecffe@github.com>
 <mMPsdv3R1O2pEZmuJGwJfEqds_NlYILW4x3a67G-m2k=.ce4b92a5-d146-4ce7-8d66-fe5a8c2b054a@github.com>
 <zNYj7hNRvjjkcuwZMWdB5jfYQuORSqZjvr3tqD4bs7s=.daab1253-0c99-4921-98e3-3fd8b226b693@github.com>
 <fvBYqKpKDVr14_lc2eBGaiCo38eP0xzS4SLdpoyecB0=.f6b5ef16-55c9-4aea-8ac8-12661ed5ee38@github.com>
 <tX29M6BktlMY1wairp7u5zIbdZyjZjJk1OyR24OUEfI=.d2f957db-bf91-4ea5-a12e-b03430e25ba3@github.com>
Message-ID: <4upBK4eG3UJ8LItxLizG4bZaFc8UFwM3ZGkx4wNCJaw=.cc8e3214-e98c-49ce-8a96-0244347f5c13@github.com>

On Tue, 28 Jun 2022 04:54:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> We could change it back but then we should take care of all that followup changes.
>
>> That's not a mistake, the swing was updated in a few places here and there to support it, for example: https://bugs.openjdk.org/browse/JDK-8194873
> 
> I dont think @prrace and me are contesting need of ALT_GRAPH in swing, which was fixed by the above bug..I guess it was being contested for macos only so we are not going to revert 8194873 but only 8151136 (which was done to convert right alt to altgraph for macos)

That is similar issue on Windows since we unconditionally set the right alt key to be ALT_GRAPH independently on the current keyboard layout, it is just a button location which is the same on win and mac. So probably right now it is better to update the spec of that flag. 

To workaround that change the fix for [JDK-8194873](https://bugs.openjdk.org/browse/JDK-8194873) updated all our L&F which are used on windows, obviously the Aqua was missed. I think we should update the Aqua in a similar way.

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From serb at openjdk.org  Tue Jun 28 06:58:40 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Jun 2022 06:58:40 GMT
Subject: RFR: 7124313: [macosx] Swing Popups should overlap taskbar
In-Reply-To: <iV4rDjba1_SQm88SgEMegnBM6DOXaD3bz7LsLH3MpHM=.e9206889-6b62-4000-b55a-e09175c61933@github.com>
References: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
 <HlGIDPiB0f3Mq_JGq6sd0qpEB_4nIt92bt0385rv5go=.8221c450-19f7-41bc-92af-119bdb94feb3@github.com>
 <hyAWm8kSgiWe660i-TNJOnFBB56nD9RQTVP01lU49bc=.87789d34-cd22-455a-82bb-ae44b031ae44@github.com>
 <al4Gxs8vDwAwhb48NCZU5RBSrpAsxkfdJ8S0XqjWoJc=.7101b5e6-f60d-4a4f-834b-7f0e2b5f916f@github.com>
 <2qXZAm6eeU49u8tO8XD7apBVwQfCrtD4QdJ4ZwOmTTg=.f0083fda-38c9-489b-ad6a-f8ba8d988c25@github.com>
 <4hFttQhPfriFFrJEcJjrwkrK4iWhi8ZLhlsJTxz1Jlw=.55e8231d-a508-41fd-b852-4b0126497b31@github.com>
 <iV4rDjba1_SQm88SgEMegnBM6DOXaD3bz7LsLH3MpHM=.e9206889-6b62-4000-b55a-e09175c61933@github.com>
Message-ID: <MsJBciI3iBiFAJLEtBXtaO3UBWfL3ClMoqkTdi2NVvc=.29b6ce28-ae56-438b-ae6f-ae77241b3ae2@github.com>

On Tue, 28 Jun 2022 06:34:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> @prrace Can we please ask Apple if this behaviour is a bug in Java that we dont overlap the taskbar for small popupmenu or is it expected?

I do not think that this is an Apple bug, since we(our code) place that menu to the location similar to the native menu. But in java we still overlap it if the menu is big enough, it is just a different meaning of large menu from that bug.

-------------

PR: https://git.openjdk.org/jdk/pull/9294


From serb at openjdk.org  Tue Jun 28 07:03:44 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Jun 2022 07:03:44 GMT
Subject: RFR: 7124313: [macosx] Swing Popups should overlap taskbar
In-Reply-To: <OivbfPyGy7u60DCp-eKipirKEhAy7ARAgP32YoQJfvc=.94c96847-02b5-465a-8b8a-0e697c8c2130@github.com>
References: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
 <HlGIDPiB0f3Mq_JGq6sd0qpEB_4nIt92bt0385rv5go=.8221c450-19f7-41bc-92af-119bdb94feb3@github.com>
 <hyAWm8kSgiWe660i-TNJOnFBB56nD9RQTVP01lU49bc=.87789d34-cd22-455a-82bb-ae44b031ae44@github.com>
 <al4Gxs8vDwAwhb48NCZU5RBSrpAsxkfdJ8S0XqjWoJc=.7101b5e6-f60d-4a4f-834b-7f0e2b5f916f@github.com>
 <OivbfPyGy7u60DCp-eKipirKEhAy7ARAgP32YoQJfvc=.94c96847-02b5-465a-8b8a-0e697c8c2130@github.com>
Message-ID: <tAQpruxnAfpyEr4VQ85VBbRy9gs4isjEDtktq3lrAlE=.1554b07f-fd53-4e19-be42-e4c4eb4d81d0@github.com>

On Tue, 28 Jun 2022 06:04:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Dont think so. The comment was made on the same day this bug was filed so it was not working in macos even then.

Seems it was related to that flag, but was fixed later: https://bugs.openjdk.org/browse/JDK-7154841

-------------

PR: https://git.openjdk.org/jdk/pull/9294


From psadhukhan at openjdk.org  Tue Jun 28 07:08:40 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Jun 2022 07:08:40 GMT
Subject: RFR: 7124313: [macosx] Swing Popups should overlap taskbar
In-Reply-To: <MsJBciI3iBiFAJLEtBXtaO3UBWfL3ClMoqkTdi2NVvc=.29b6ce28-ae56-438b-ae6f-ae77241b3ae2@github.com>
References: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
 <HlGIDPiB0f3Mq_JGq6sd0qpEB_4nIt92bt0385rv5go=.8221c450-19f7-41bc-92af-119bdb94feb3@github.com>
 <hyAWm8kSgiWe660i-TNJOnFBB56nD9RQTVP01lU49bc=.87789d34-cd22-455a-82bb-ae44b031ae44@github.com>
 <al4Gxs8vDwAwhb48NCZU5RBSrpAsxkfdJ8S0XqjWoJc=.7101b5e6-f60d-4a4f-834b-7f0e2b5f916f@github.com>
 <2qXZAm6eeU49u8tO8XD7apBVwQfCrtD4QdJ4ZwOmTTg=.f0083fda-38c9-489b-ad6a-f8ba8d988c25@github.com>
 <4hFttQhPfriFFrJEcJjrwkrK4iWhi8ZLhlsJTxz1Jlw=.55e8231d-a508-41fd-b852-4b0126497b31@github.com>
 <iV4rDjba1_SQm88SgEMegnBM6DOXaD3bz7LsLH3MpHM=.e9206889-6b62-4000-b55a-e09175c61933@github.com>
 <MsJBciI3iBiFAJLEtBXtaO3UBWfL3ClMoqkTdi2NVvc=.29b6ce28-ae56-438b-ae6f-ae77241b3ae2@github.com>
Message-ID: <wtWgPtyoAg0axWE49NKPqJmlu4Y1H2AzmYxc5kld6Gg=.339b2cf1-af5a-4804-a48e-490c90dcd2a8@github.com>

On Tue, 28 Jun 2022 06:54:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > @prrace Can we please ask Apple if this behaviour is a bug in Java that we dont overlap the taskbar for small popupmenu or is it expected?
> 
> I do not think that this is an Apple bug, since we(our code) place that menu to the location similar to the native menu. But in java we still overlap it if the menu is big enough, it is just a different meaning of large menu from that bug.

I did not say it's an Apple bug..I am asking if Apple (or others?) thinks it's a Java bug 
or is it expected behaviour similar to native
as what I am seeing in java, is the same as what native does for similar popup menu with similar number of items..

-------------

PR: https://git.openjdk.org/jdk/pull/9294


From psadhukhan at openjdk.org  Tue Jun 28 07:14:48 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Jun 2022 07:14:48 GMT
Subject: RFR: 7124313: [macosx] Swing Popups should overlap taskbar
In-Reply-To: <tAQpruxnAfpyEr4VQ85VBbRy9gs4isjEDtktq3lrAlE=.1554b07f-fd53-4e19-be42-e4c4eb4d81d0@github.com>
References: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
 <HlGIDPiB0f3Mq_JGq6sd0qpEB_4nIt92bt0385rv5go=.8221c450-19f7-41bc-92af-119bdb94feb3@github.com>
 <hyAWm8kSgiWe660i-TNJOnFBB56nD9RQTVP01lU49bc=.87789d34-cd22-455a-82bb-ae44b031ae44@github.com>
 <al4Gxs8vDwAwhb48NCZU5RBSrpAsxkfdJ8S0XqjWoJc=.7101b5e6-f60d-4a4f-834b-7f0e2b5f916f@github.com>
 <OivbfPyGy7u60DCp-eKipirKEhAy7ARAgP32YoQJfvc=.94c96847-02b5-465a-8b8a-0e697c8c2130@github.com>
 <tAQpruxnAfpyEr4VQ85VBbRy9gs4isjEDtktq3lrAlE=.1554b07f-fd53-4e19-be42-e4c4eb4d81d0@github.com>
Message-ID: <jlkfeGa-PqeHcZG9-DI7iDCIZA5Aj5wyok2HxD4gUz4=.b2674f33-211f-4bff-8bff-ee7b23ef3878@github.com>

On Tue, 28 Jun 2022 07:00:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Dont think so. The comment was made on the same day this bug was filed so it was not working in macos even then.
> 
> Seems it was related to that flag, but was fixed later: https://bugs.openjdk.org/browse/JDK-7154841

That test works on macos for popup with many menu items and it overlaps the taskbar so why do we need another test (ie this test) to test the same on macos? I think we can omit this test from macos run as the other test test/jdk/javax/swing/JPopupMenu/7154841/bug7154841.java is testing the large popup behaviour in macos..

-------------

PR: https://git.openjdk.org/jdk/pull/9294


From psadhukhan at openjdk.org  Tue Jun 28 07:57:47 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Jun 2022 07:57:47 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified
In-Reply-To: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
Message-ID: <fmP_tVY_5v4gvoktPPdAdKqSq8PSahZRjYQYbjlBobQ=.4f5ac8aa-210a-4c2c-b14b-b4635f77cb91@github.com>

On Wed, 22 Jun 2022 13:14:31 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> JLabel and AbstractButton's imageUpdate method description updated.

src/java.desktop/share/classes/javax/swing/AbstractButton.java line 2151:

> 2149:      * Returns true if one of this AbstractButton's icon or disabled icon is derived from
> 2150:      * ImageIcon and it's Image is equal to the image passed in; false
> 2151:      * otherwise.

Guess it should be "Returns true if the button icon for present button state is an instance of ImageIcon and the image it contains is same as the <code>image</code>"

-------------

PR: https://git.openjdk.org/jdk/pull/9240


From psadhukhan at openjdk.org  Tue Jun 28 07:57:48 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Jun 2022 07:57:48 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified
In-Reply-To: <fmP_tVY_5v4gvoktPPdAdKqSq8PSahZRjYQYbjlBobQ=.4f5ac8aa-210a-4c2c-b14b-b4635f77cb91@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <fmP_tVY_5v4gvoktPPdAdKqSq8PSahZRjYQYbjlBobQ=.4f5ac8aa-210a-4c2c-b14b-b4635f77cb91@github.com>
Message-ID: <5pS2XA_FsSN-Fqee8nU4PhdNgsCgEzpehb2ryRUG0hE=.3064abe1-8c37-4a9c-831f-496ace2fdab7@github.com>

On Tue, 28 Jun 2022 07:53:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JLabel and AbstractButton's imageUpdate method description updated.
>
> src/java.desktop/share/classes/javax/swing/AbstractButton.java line 2151:
> 
>> 2149:      * Returns true if one of this AbstractButton's icon or disabled icon is derived from
>> 2150:      * ImageIcon and it's Image is equal to the image passed in; false
>> 2151:      * otherwise.
> 
> Guess it should be "Returns true if the button icon for present button state is an instance of ImageIcon and the image it contains is same as the <code>image</code>"

same for JLabel..

-------------

PR: https://git.openjdk.org/jdk/pull/9240


From duke at openjdk.org  Tue Jun 28 09:12:32 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 28 Jun 2022 09:12:32 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v2]
In-Reply-To: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
Message-ID: <a41X0n8k9o7c4JetU20bt4aWBMIwf7A5DSXF_lmeAqg=.f44eec91-4eb9-47b2-bf14-5464dc26d5d5@github.com>

> JLabel and AbstractButton's imageUpdate method description updated.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  JLabel and Abstract Button's imageUpdate method description changed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9240/files
  - new: https://git.openjdk.org/jdk/pull/9240/files/a16566a4..1e69df0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9240&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9240&range=00-01

  Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9240.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9240/head:pull/9240

PR: https://git.openjdk.org/jdk/pull/9240


From duke at openjdk.org  Tue Jun 28 09:14:48 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 28 Jun 2022 09:14:48 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v2]
In-Reply-To: <5pS2XA_FsSN-Fqee8nU4PhdNgsCgEzpehb2ryRUG0hE=.3064abe1-8c37-4a9c-831f-496ace2fdab7@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <fmP_tVY_5v4gvoktPPdAdKqSq8PSahZRjYQYbjlBobQ=.4f5ac8aa-210a-4c2c-b14b-b4635f77cb91@github.com>
 <5pS2XA_FsSN-Fqee8nU4PhdNgsCgEzpehb2ryRUG0hE=.3064abe1-8c37-4a9c-831f-496ace2fdab7@github.com>
Message-ID: <89XPfiYofmSuVACBTH7ZzG7uJ8klhPDrGILVIBfcugU=.2ebc6a07-e62f-49ae-ade3-f149f7c2d0db@github.com>

On Tue, 28 Jun 2022 07:54:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/AbstractButton.java line 2151:
>> 
>>> 2149:      * Returns true if one of this AbstractButton's icon or disabled icon is derived from
>>> 2150:      * ImageIcon and it's Image is equal to the image passed in; false
>>> 2151:      * otherwise.
>> 
>> Guess it should be "Returns true if the button icon for present button state is an instance of ImageIcon and the image it contains is same as the <code>image</code>"
>
> same for JLabel..

imageUpdate method description changed for AbstractButton and JLabel.

-------------

PR: https://git.openjdk.org/jdk/pull/9240


From psadhukhan at openjdk.org  Tue Jun 28 09:42:42 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Jun 2022 09:42:42 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v2]
In-Reply-To: <a41X0n8k9o7c4JetU20bt4aWBMIwf7A5DSXF_lmeAqg=.f44eec91-4eb9-47b2-bf14-5464dc26d5d5@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <a41X0n8k9o7c4JetU20bt4aWBMIwf7A5DSXF_lmeAqg=.f44eec91-4eb9-47b2-bf14-5464dc26d5d5@github.com>
Message-ID: <xDFtP3-8lcfCeeAhynjt-5v29br4HZhaRAMqfU3_oMA=.7ec383b9-8449-4ed7-af73-2ce96431c2d5@github.com>

On Tue, 28 Jun 2022 09:12:32 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JLabel and AbstractButton's imageUpdate method description updated.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JLabel and Abstract Button's imageUpdate method description changed

src/java.desktop/share/classes/javax/swing/AbstractButton.java line 2150:

> 2148:     /**
> 2149:      * Returns true if the button icon for present button state is an instance of ImageIcon
> 2150:      * and the image it contains is same as the <code>image</code>.

boolean value should be put under <code>true</code>...also you should add "<code>false</code> otherwise"

-------------

PR: https://git.openjdk.org/jdk/pull/9240


From duke at openjdk.org  Tue Jun 28 09:58:40 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 28 Jun 2022 09:58:40 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v2]
In-Reply-To: <89XPfiYofmSuVACBTH7ZzG7uJ8klhPDrGILVIBfcugU=.2ebc6a07-e62f-49ae-ade3-f149f7c2d0db@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <fmP_tVY_5v4gvoktPPdAdKqSq8PSahZRjYQYbjlBobQ=.4f5ac8aa-210a-4c2c-b14b-b4635f77cb91@github.com>
 <5pS2XA_FsSN-Fqee8nU4PhdNgsCgEzpehb2ryRUG0hE=.3064abe1-8c37-4a9c-831f-496ace2fdab7@github.com>
 <89XPfiYofmSuVACBTH7ZzG7uJ8klhPDrGILVIBfcugU=.2ebc6a07-e62f-49ae-ade3-f149f7c2d0db@github.com>
Message-ID: <gADvTWUmnAp_80e0XhTHT_RRTMzlwDr3_idIb1iOPf0=.274da257-ae74-4656-b278-a931b5da53ee@github.com>

On Tue, 28 Jun 2022 09:12:42 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> same for JLabel..
>
> imageUpdate method description changed for AbstractButton and JLabel.

Does it should be <code>img</code> in stead of <code>image</code> ?

-------------

PR: https://git.openjdk.org/jdk/pull/9240


From psadhukhan at openjdk.org  Tue Jun 28 10:30:52 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Jun 2022 10:30:52 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v2]
In-Reply-To: <gADvTWUmnAp_80e0XhTHT_RRTMzlwDr3_idIb1iOPf0=.274da257-ae74-4656-b278-a931b5da53ee@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <fmP_tVY_5v4gvoktPPdAdKqSq8PSahZRjYQYbjlBobQ=.4f5ac8aa-210a-4c2c-b14b-b4635f77cb91@github.com>
 <5pS2XA_FsSN-Fqee8nU4PhdNgsCgEzpehb2ryRUG0hE=.3064abe1-8c37-4a9c-831f-496ace2fdab7@github.com>
 <89XPfiYofmSuVACBTH7ZzG7uJ8klhPDrGILVIBfcugU=.2ebc6a07-e62f-49ae-ade3-f149f7c2d0db@github.com>
 <gADvTWUmnAp_80e0XhTHT_RRTMzlwDr3_idIb1iOPf0=.274da257-ae74-4656-b278-a931b5da53ee@github.com>
Message-ID: <9skMvmixNNNM5CVd_yEsIbGY7XgPz9tst45QI-cD9wM=.983fa2d9-6d0e-415d-a409-d8716c839ee9@github.com>

On Tue, 28 Jun 2022 09:54:41 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> imageUpdate method description changed for AbstractButton and JLabel.
>
> Does it should be <code>img</code> in stead of <code>image</code> ?

Image

-------------

PR: https://git.openjdk.org/jdk/pull/9240


From duke at openjdk.org  Tue Jun 28 10:37:51 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 28 Jun 2022 10:37:51 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v3]
In-Reply-To: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
Message-ID: <PmMhoG8cljLhsR5_LGVvWQw8BPVnhl1QwxME0iBlRqM=.e7bcf8ca-de6a-4bb0-b7e9-e05d6adae16e@github.com>

> JLabel and AbstractButton's imageUpdate method description updated.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  boolean value in description changed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9240/files
  - new: https://git.openjdk.org/jdk/pull/9240/files/1e69df0d..e32c4f9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9240&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9240&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9240.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9240/head:pull/9240

PR: https://git.openjdk.org/jdk/pull/9240


From psadhukhan at openjdk.org  Tue Jun 28 10:37:52 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Jun 2022 10:37:52 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v3]
In-Reply-To: <PmMhoG8cljLhsR5_LGVvWQw8BPVnhl1QwxME0iBlRqM=.e7bcf8ca-de6a-4bb0-b7e9-e05d6adae16e@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <PmMhoG8cljLhsR5_LGVvWQw8BPVnhl1QwxME0iBlRqM=.e7bcf8ca-de6a-4bb0-b7e9-e05d6adae16e@github.com>
Message-ID: <PRCoIQ6ChJLMIRyVUNEc2N3kKWvuV-9DH_BhAKuPOVo=.b87ce234-ec1f-4d61-893d-ca8a2767a948@github.com>

On Tue, 28 Jun 2022 10:34:17 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JLabel and AbstractButton's imageUpdate method description updated.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   boolean value in description changed

please put newline at appropriate and logical position as it is crossing 80char per line..

-------------

PR: https://git.openjdk.org/jdk/pull/9240


From duke at openjdk.org  Tue Jun 28 10:37:55 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 28 Jun 2022 10:37:55 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v2]
In-Reply-To: <xDFtP3-8lcfCeeAhynjt-5v29br4HZhaRAMqfU3_oMA=.7ec383b9-8449-4ed7-af73-2ce96431c2d5@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <a41X0n8k9o7c4JetU20bt4aWBMIwf7A5DSXF_lmeAqg=.f44eec91-4eb9-47b2-bf14-5464dc26d5d5@github.com>
 <xDFtP3-8lcfCeeAhynjt-5v29br4HZhaRAMqfU3_oMA=.7ec383b9-8449-4ed7-af73-2ce96431c2d5@github.com>
Message-ID: <QVuAPLDWYsfR3pw3Pt75XsfDi7dG8p1v3sk_fKD51cg=.2ebf0464-c8ea-4496-bda4-6caa88a28f05@github.com>

On Tue, 28 Jun 2022 09:39:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JLabel and Abstract Button's imageUpdate method description changed
>
> src/java.desktop/share/classes/javax/swing/AbstractButton.java line 2150:
> 
>> 2148:     /**
>> 2149:      * Returns true if the button icon for present button state is an instance of ImageIcon
>> 2150:      * and the image it contains is same as the <code>image</code>.
> 
> boolean value should be put under <code>true</code>...also you should add "<code>false</code> otherwise"

change added

-------------

PR: https://git.openjdk.org/jdk/pull/9240


From duke at openjdk.org  Tue Jun 28 10:37:56 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 28 Jun 2022 10:37:56 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v3]
In-Reply-To: <9skMvmixNNNM5CVd_yEsIbGY7XgPz9tst45QI-cD9wM=.983fa2d9-6d0e-415d-a409-d8716c839ee9@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <fmP_tVY_5v4gvoktPPdAdKqSq8PSahZRjYQYbjlBobQ=.4f5ac8aa-210a-4c2c-b14b-b4635f77cb91@github.com>
 <5pS2XA_FsSN-Fqee8nU4PhdNgsCgEzpehb2ryRUG0hE=.3064abe1-8c37-4a9c-831f-496ace2fdab7@github.com>
 <89XPfiYofmSuVACBTH7ZzG7uJ8klhPDrGILVIBfcugU=.2ebc6a07-e62f-49ae-ade3-f149f7c2d0db@github.com>
 <gADvTWUmnAp_80e0XhTHT_RRTMzlwDr3_idIb1iOPf0=.274da257-ae74-4656-b278-a931b5da53ee@github.com>
 <9skMvmixNNNM5CVd_yEsIbGY7XgPz9tst45QI-cD9wM=.983fa2d9-6d0e-415d-a409-d8716c839ee9@github.com>
Message-ID: <XuTkdoGlTWM_2OlIEmQi2-xNSZDcI3h158R1pOQfl-M=.e21977c9-a448-4239-8e82-a47e49b1fbb1@github.com>

On Tue, 28 Jun 2022 10:28:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Does it should be <code>img</code> in stead of <code>image</code> ?
>
> Image

ok

-------------

PR: https://git.openjdk.org/jdk/pull/9240


From duke at openjdk.org  Tue Jun 28 10:58:34 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 28 Jun 2022 10:58:34 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v4]
In-Reply-To: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
Message-ID: <kgp-nPWgdWB5gWVdoemTpw9TK4zbq6x3K5QVRQugGNI=.fb4b212b-55e7-4be1-bae3-99c9f1ae4d28@github.com>

> JLabel and AbstractButton's imageUpdate method description updated.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  image changed to Image and newline added

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9240/files
  - new: https://git.openjdk.org/jdk/pull/9240/files/e32c4f9a..7e327402

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9240&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9240&range=02-03

  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9240.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9240/head:pull/9240

PR: https://git.openjdk.org/jdk/pull/9240


From psadhukhan at openjdk.org  Tue Jun 28 11:00:52 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Jun 2022 11:00:52 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v4]
In-Reply-To: <kgp-nPWgdWB5gWVdoemTpw9TK4zbq6x3K5QVRQugGNI=.fb4b212b-55e7-4be1-bae3-99c9f1ae4d28@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <kgp-nPWgdWB5gWVdoemTpw9TK4zbq6x3K5QVRQugGNI=.fb4b212b-55e7-4be1-bae3-99c9f1ae4d28@github.com>
Message-ID: <CPjsWAm33QUPN0aiuYZXe7gzkBfwde2vLoFSjIo4bTU=.25fd5f8f-fdb9-4a78-8fdf-91604973710c@github.com>

On Tue, 28 Jun 2022 10:58:34 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JLabel and AbstractButton's imageUpdate method description updated.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   image changed to Image and newline added

src/java.desktop/share/classes/javax/swing/AbstractButton.java line 2151:

> 2149:      * Returns <code>true</code> if the button icon for present button state
> 2150:      * is an instance of ImageIcon and the image it contains is same as the
> 2151:      * <code>Image</code>, <code>false</code> otherwise.

we need to mention "same as the passed in Image" in both..

-------------

PR: https://git.openjdk.org/jdk/pull/9240


From duke at openjdk.org  Tue Jun 28 11:15:41 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 28 Jun 2022 11:15:41 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v5]
In-Reply-To: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
Message-ID: <PZcKj61PMBN6ZeS_BCrdwMUiMhu9K5XyX8V3VBvXvzQ=.836e74ac-5c97-47b2-adc0-4d21e56d734e@github.com>

> JLabel and AbstractButton's imageUpdate method description updated.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  passed in text added

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9240/files
  - new: https://git.openjdk.org/jdk/pull/9240/files/7e327402..106800b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9240&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9240&range=03-04

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9240.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9240/head:pull/9240

PR: https://git.openjdk.org/jdk/pull/9240


From duke at openjdk.org  Tue Jun 28 11:15:43 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 28 Jun 2022 11:15:43 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v4]
In-Reply-To: <CPjsWAm33QUPN0aiuYZXe7gzkBfwde2vLoFSjIo4bTU=.25fd5f8f-fdb9-4a78-8fdf-91604973710c@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <kgp-nPWgdWB5gWVdoemTpw9TK4zbq6x3K5QVRQugGNI=.fb4b212b-55e7-4be1-bae3-99c9f1ae4d28@github.com>
 <CPjsWAm33QUPN0aiuYZXe7gzkBfwde2vLoFSjIo4bTU=.25fd5f8f-fdb9-4a78-8fdf-91604973710c@github.com>
Message-ID: <FV9rJPBnnra-j3mOLH1eIb0mVzlgOtZrqcZtC9HW3UE=.255f79e9-8aa9-4fdd-8157-a1b71c6f0f24@github.com>

On Tue, 28 Jun 2022 10:58:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   image changed to Image and newline added
>
> src/java.desktop/share/classes/javax/swing/AbstractButton.java line 2151:
> 
>> 2149:      * Returns <code>true</code> if the button icon for present button state
>> 2150:      * is an instance of ImageIcon and the image it contains is same as the
>> 2151:      * <code>Image</code>, <code>false</code> otherwise.
> 
> we need to mention "same as the passed in Image" in both..

added

-------------

PR: https://git.openjdk.org/jdk/pull/9240


From psadhukhan at openjdk.org  Tue Jun 28 11:18:03 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Jun 2022 11:18:03 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v5]
In-Reply-To: <PZcKj61PMBN6ZeS_BCrdwMUiMhu9K5XyX8V3VBvXvzQ=.836e74ac-5c97-47b2-adc0-4d21e56d734e@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <PZcKj61PMBN6ZeS_BCrdwMUiMhu9K5XyX8V3VBvXvzQ=.836e74ac-5c97-47b2-adc0-4d21e56d734e@github.com>
Message-ID: <spqNR9tQo7C6yhaQf2g1OKs63Qfr-9h2x-9JtZErWy4=.9d309a14-a3a4-4795-a377-4c02a76c2b76@github.com>

On Tue, 28 Jun 2022 11:15:41 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JLabel and AbstractButton's imageUpdate method description updated.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   passed in text added

looks ok to me..not sure if it will require csr.

-------------

Marked as reviewed by psadhukhan (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9240


From mvs at openjdk.org  Tue Jun 28 13:10:44 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 28 Jun 2022 13:10:44 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v2]
In-Reply-To: <07vES8jtHcWypuL2HBv-ryMPrVDe0ti0mU_bVRdlzrk=.21082c4e-f4a3-434e-9584-05d0bc6c6c85@github.com>
References: <pClI2zW5gi4TBiMW2CeftBlBN_p5Z7KWF4fpeVZqtlg=.e332bcae-1242-4227-8804-9ae8f0576381@github.com>
 <07vES8jtHcWypuL2HBv-ryMPrVDe0ti0mU_bVRdlzrk=.21082c4e-f4a3-434e-9584-05d0bc6c6c85@github.com>
Message-ID: <r5IOgLH4lWpDpfCI-x7Y9sl6zbOzynRGC01mGCrZhsQ=.a286c24c-25a8-4b19-a52a-4aaf3db000f2@github.com>

On Fri, 17 Jun 2022 10:57:59 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines. It seems to be a testbug as adding some stability improvements fix the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. I have removed the problem listing and tested it in windows platform also, it works fine there.
>> 
>> Fix:
>> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Removed -Dsun.java2d.uiScale=1, frame.getLocationOnScreen() removed from EDT, added volatile keyword for actionEventReceivedLatch

Any volunteers please?

-------------

PR: https://git.openjdk.org/jdk/pull/9187


From mvs at openjdk.org  Tue Jun 28 13:11:45 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 28 Jun 2022 13:11:45 GMT
Subject: RFR: 8288428: javax/swing/JInternalFrame/Test6505027.java fails
 frequently in MacOS 12 machines
In-Reply-To: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
References: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
Message-ID: <u-0c8m2akSlpvN8zk23Xsc1E0viz-w7D1M7kyaGhVaE=.c0fc9f96-663e-4c04-af35-e7fa43f93e76@github.com>

On Fri, 17 Jun 2022 14:28:15 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> javax/swing/JInternalFrame/Test6505027.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines and it fails intermittently in CI causing some noise.
> It seems to be a testbug as adding some stability improvements fix the issue.
> 
> Fix:
> Some stability improvements have been done and the test has been run 10 times per platform in mach5 and got full PASS.

Any volunteers please?

-------------

PR: https://git.openjdk.org/jdk/pull/9202


From psadhukhan at openjdk.org  Tue Jun 28 13:15:41 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Jun 2022 13:15:41 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v5]
In-Reply-To: <4upBK4eG3UJ8LItxLizG4bZaFc8UFwM3ZGkx4wNCJaw=.cc8e3214-e98c-49ce-8a96-0244347f5c13@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <eaIqfbBPgL1ztaV0YUgcV2zF38-eR4XfmNpfAj5NWic=.2ece233e-c6f0-43f2-aa2b-2d9d4441432c@github.com>
 <2lojbp2WLFbEEIhZVeVIbHU_6g_n3zQHpyKAAU9Jl7E=.1ed34cc5-5c1e-4c45-8657-df36af1ecffe@github.com>
 <mMPsdv3R1O2pEZmuJGwJfEqds_NlYILW4x3a67G-m2k=.ce4b92a5-d146-4ce7-8d66-fe5a8c2b054a@github.com>
 <zNYj7hNRvjjkcuwZMWdB5jfYQuORSqZjvr3tqD4bs7s=.daab1253-0c99-4921-98e3-3fd8b226b693@github.com>
 <fvBYqKpKDVr14_lc2eBGaiCo38eP0xzS4SLdpoyecB0=.f6b5ef16-55c9-4aea-8ac8-12661ed5ee38@github.com>
 <tX29M6BktlMY1wairp7u5zIbdZyjZjJk1OyR24OUEfI=.d2f957db-bf91-4ea5-a12e-b03430e25ba3@github.com>
 <4upBK4eG3UJ8LItxLizG4bZaFc8UFwM3ZGkx4wNCJaw=.cc8e3214-e98c-49ce-8a96-0244347f5c13@github.com>
Message-ID: <R7yJ5AYM5oIDESlxV5cYb8RUbaFe1kedi595pJxrNlY=.27ba2ed4-a275-4e28-82de-2a0f3ec81187@github.com>

On Tue, 28 Jun 2022 06:40:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> That's not a mistake, the swing was updated in a few places here and there to support it, for example: https://bugs.openjdk.org/browse/JDK-8194873
>> 
>> I dont think @prrace and me are contesting need of ALT_GRAPH in swing, which was fixed by the above bug..I guess it was being contested for macos only so we are not going to revert 8194873 but only 8151136 (which was done to convert right alt to altgraph for macos)
>
> That is similar issue on Windows since we unconditionally set the right alt key to be ALT_GRAPH independently of the current keyboard layout, it is just a button location which is the same on win and mac. So probably right now it is better to update the spec of that flag. 
> 
> To workaround that change the fix for [JDK-8194873](https://bugs.openjdk.org/browse/JDK-8194873) updated all our L&F which are used on windows, obviously the Aqua was missed. I think we should update the Aqua in a similar way.

I can see "AltGr" key in windows keyboard but not mac so am not sure why should we support just because of key location.
Anyway, I will let @prrace decide  on that.

If we need to support altgr, then present PR supports both 8151136  (alt graph) and also Right/Left Option Up/Down

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From kirill.grouchnikov at gmail.com  Tue Jun 28 15:19:02 2022
From: kirill.grouchnikov at gmail.com (Kirill Grouchnikov)
Date: Tue, 28 Jun 2022 11:19:02 -0400
Subject: Getting notified on a window being grabbed and moved / resized
Message-ID: <CAMRG33ZWw1vikdJPjUfkPrXVMsY1TWW9JWsvemux=8LQLZ0HqA@mail.gmail.com>

Is there a public / supported way to get notified when an OS-decorated
window (native title pane from macOS, Windows, etc) is moved around or
resized by the user grabbing the title bar or the border?

I want to get notified on that process starting so that I can hide all the
popups. What I see is that at [1] this is how Swing's popup menu registers
itself to get notified on window grabbing. Note that it's using internal,
undocumented and inaccessible event mask. Then at [2] it gets notified that
the window has been ungrabbed so that it can hide itself. Again, internal
and inaccessible event class. And there's also APIs at [3] to grab / ungrab
windows to have the whole process rolling.

Are there alternatives to these internal APIs that have been exposed as
part of hiding the implementation details?

The only thing I could find so far is adding a component listener to the
frame, but "componentMoved" is called with a noticeable lag, hundreds of
milliseconds after the window has started moving.

[1]
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java#L790
[2]
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java#L861
[3]
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/awt/SunToolkit.java#L1641
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220628/bdf78bbf/attachment.htm>

From azvegint at openjdk.org  Tue Jun 28 18:48:26 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 28 Jun 2022 18:48:26 GMT
Subject: [jdk19] RFR: 8288854: getLocalGraphicsEnvironment() on for
 multi-screen setups throws exception NPE
In-Reply-To: <rBvFremdQsswOG5ynfNKjOFVDStHLAmeSgVIq8y6MrI=.dfa5031f-3b70-467e-8819-a3c8fc07e81b@github.com>
References: <rBvFremdQsswOG5ynfNKjOFVDStHLAmeSgVIq8y6MrI=.dfa5031f-3b70-467e-8819-a3c8fc07e81b@github.com>
Message-ID: <XNJoF82UuXOaKtJn5v3FP61dXEz6HG0hWo4wD6aI9rI=.f37ac84c-907b-4457-8568-b0ad344f980b@github.com>

On Mon, 27 Jun 2022 21:17:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the fix for a copy-paste error. The fix JDK-8076313 replaced the usage of the "screens" array from the parent class to the "devices" where the list of devices is now maintained. Since "screens" array is never used nor initialized its usage caused an NPE. That check was copied as-is, while it should use the actual number of screen devices requested early in that method.
> 
> The bug is rarely reproduced because in single screen configuration the main screen is usually 0, and in the multiscreen configuration Xinerama is usually active so the main screen is also 0 => the second part of the "if" statement is not executed.
> 
> I have validated the fix by the SwingSet, I also executed desktop tests in that config and found that even though this particular bug is fixed we still have many issues there, around ~100 tests failed.

Looks good.

-------------

Marked as reviewed by azvegint (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/81


From azvegint at openjdk.org  Tue Jun 28 18:59:49 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 28 Jun 2022 18:59:49 GMT
Subject: [jdk19] RFR: 8288854: getLocalGraphicsEnvironment() on for
 multi-screen setups throws exception NPE
In-Reply-To: <rBvFremdQsswOG5ynfNKjOFVDStHLAmeSgVIq8y6MrI=.dfa5031f-3b70-467e-8819-a3c8fc07e81b@github.com>
References: <rBvFremdQsswOG5ynfNKjOFVDStHLAmeSgVIq8y6MrI=.dfa5031f-3b70-467e-8819-a3c8fc07e81b@github.com>
Message-ID: <lWTcHrRDGZPPE6GyEAoh3-bn4Vint5Qtrjg0_O_Wvws=.76800aaa-c505-42f0-ad97-e5a1a7c28a32@github.com>

On Mon, 27 Jun 2022 21:17:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the fix for a copy-paste error. The fix JDK-8076313 replaced the usage of the "screens" array from the parent class to the "devices" where the list of devices is now maintained. Since "screens" array is never used nor initialized its usage caused an NPE. That check was copied as-is, while it should use the actual number of screen devices requested early in that method.
> 
> The bug is rarely reproduced because in single screen configuration the main screen is usually 0, and in the multiscreen configuration Xinerama is usually active so the main screen is also 0 => the second part of the "if" statement is not executed.
> 
> I have validated the fix by the SwingSet, I also executed desktop tests in that config and found that even though this particular bug is fixed we still have many issues there, around ~100 tests failed.

BTW why this PR is raised  against JDK19 and not mainline?

-------------

PR: https://git.openjdk.org/jdk19/pull/81


From azvegint at openjdk.org  Tue Jun 28 19:13:04 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 28 Jun 2022 19:13:04 GMT
Subject: RFR: JDK-8289238: Refactoring changes to PassFailJFrame Test
 Framework
In-Reply-To: <_SkmPalpZpi6t0eCeviOwNOoqE3Sq_tisiYSJXIvrSs=.12cb6181-116b-44b8-9c6e-aff6efc34132@github.com>
References: <_SkmPalpZpi6t0eCeviOwNOoqE3Sq_tisiYSJXIvrSs=.12cb6181-116b-44b8-9c6e-aff6efc34132@github.com>
Message-ID: <8anPjkswEqpc5aIsC3Uw6zH5Vw2xwyUGJoq4uSXC3sc=.e06f1dd4-0a07-4b58-b68d-fd3ce2c27186@github.com>

On Tue, 28 Jun 2022 00:58:42 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Currently PassFailJFrame.positionTestFrame() and PassFailJFrame.addTestFrame() take Frame as input parameter, this has been changed to Window.
> 
> Refactored the above method names to reflect the functionality & input parameter type -
> addTestWindow(), positionTestWindow()
> 
> Additionally added test fail reason to `forceFail()` to avoid NPE.
> 
> Benefits of the change -
> 
> - Since Window is a parent class, this would allow the test frame to be a Window/Frame/Dialog and not be restricted to a Frame.
> - Code reusability - no need to have separate methods to manage Frame and Window
> - Additionally it would allow proper clean-up of window and its container subclasses which are added to the PassFailJFrame.

Marked as reviewed by azvegint (Reviewer).

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 219:

> 217:     /**
> 218:      * Dispose all the windows(s) i,e both the test instruction frame and
> 219:      * the testWindow that is added via addTestWindow(Window testWindow)

Shouldn't it be `windows` instead of `testWindow`, because we can add plenty of them with `addTestWindow()`?

Otherwise looks good.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 263:

> 261:      * window) by the specified position
> 262:      * Note: This method should be invoked from the method that creates
> 263:      * testWindow

It looks like you accidentally removed the empty line that served as the visual delimiter.

-------------

PR: https://git.openjdk.org/jdk/pull/9300


From serb at openjdk.org  Tue Jun 28 19:44:31 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Jun 2022 19:44:31 GMT
Subject: RFR: 8272998: ImageIO.read() throws incorrect exception type
In-Reply-To: <vqA4_ai6rzbcMb6XA5vsLKYGp1deVFsA1JsEiRxkVyc=.7988a076-bf7f-432a-9658-bcdb94ede4bd@github.com>
References: <7P_RTUjGWttc7Wpknqa7CCPgNIssyX4xT--MjQ_R5po=.be6078e7-bb89-4b23-9b55-6d8fe93c70f6@github.com>
 <RCPQz7Uzpx-rTJqjcp4o0GsahxabKIw1-_VRO6NvLe0=.b6c6b8cf-b324-473a-b102-beb1e4ee6223@github.com>
 <pyd50p5WqN6Dj0gtJsuo7PgCtdYVFqMIKpbMr7na97s=.c5c64abe-f7cd-498f-979a-221a56111887@github.com>
 <JP6PI6zNWemDReNBflJsBeoMFGbvUbYQxHR08JZe6Us=.0163e85c-362b-42d7-bcf2-adb2df43aeec@github.com>
 <tPhtRtrEkMVQAR3XHGgrja8FAQF7DjzH6zmEFd1pPCY=.c981fbd7-414b-41a9-80b1-7f4cd524bd58@github.com>
 <vqA4_ai6rzbcMb6XA5vsLKYGp1deVFsA1JsEiRxkVyc=.7988a076-bf7f-432a-9658-bcdb94ede4bd@github.com>
Message-ID: <kh_SyzOVFA3CZttHs9LgBMYw7Ip0W5u0eHMtVSQ656A=.49b4105b-1abb-4bd1-a006-d4b50ee40ff2@github.com>

On Mon, 27 Jun 2022 21:57:37 GMT, Phil Race <prr at openjdk.org> wrote:

> A sophisticated app which wants to use ImageReader.read() should be ready to handle those

The current method differs from the "read" only by the "IllegalArgumentException", all other exceptions we will handle here will mean a bug in the read method, which also can be used by the app.

I do not understand why the app should be ready for unexpected/unspecified exceptions in case of "read" method and could not be ready in this one.

-------------

PR: https://git.openjdk.org/jdk/pull/9113


From serb at openjdk.org  Tue Jun 28 19:44:38 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Jun 2022 19:44:38 GMT
Subject: [jdk19] RFR: 8288854: getLocalGraphicsEnvironment() on for
 multi-screen setups throws exception NPE
In-Reply-To: <lWTcHrRDGZPPE6GyEAoh3-bn4Vint5Qtrjg0_O_Wvws=.76800aaa-c505-42f0-ad97-e5a1a7c28a32@github.com>
References: <rBvFremdQsswOG5ynfNKjOFVDStHLAmeSgVIq8y6MrI=.dfa5031f-3b70-467e-8819-a3c8fc07e81b@github.com>
 <lWTcHrRDGZPPE6GyEAoh3-bn4Vint5Qtrjg0_O_Wvws=.76800aaa-c505-42f0-ad97-e5a1a7c28a32@github.com>
Message-ID: <yNkJaf0rUP3Okm0PCwVK-zEWHNxx66yvgBIi4qxF_8o=.3bb91232-a07a-4207-a490-21447ae7eb54@github.com>

On Tue, 28 Jun 2022 18:56:25 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> BTW why this PR is raised against JDK19 and not mainline?

Don't all fixes from JDK19 have merged to the mainline "automatically"?

-------------

PR: https://git.openjdk.org/jdk19/pull/81


From azvegint at openjdk.org  Tue Jun 28 20:13:39 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 28 Jun 2022 20:13:39 GMT
Subject: [jdk19] RFR: 8288854: getLocalGraphicsEnvironment() on for
 multi-screen setups throws exception NPE
In-Reply-To: <yNkJaf0rUP3Okm0PCwVK-zEWHNxx66yvgBIi4qxF_8o=.3bb91232-a07a-4207-a490-21447ae7eb54@github.com>
References: <rBvFremdQsswOG5ynfNKjOFVDStHLAmeSgVIq8y6MrI=.dfa5031f-3b70-467e-8819-a3c8fc07e81b@github.com>
 <lWTcHrRDGZPPE6GyEAoh3-bn4Vint5Qtrjg0_O_Wvws=.76800aaa-c505-42f0-ad97-e5a1a7c28a32@github.com>
 <yNkJaf0rUP3Okm0PCwVK-zEWHNxx66yvgBIi4qxF_8o=.3bb91232-a07a-4207-a490-21447ae7eb54@github.com>
Message-ID: <UQQzFnNCRrVMxTnIBMYFxWQVxH8CMAqiCdsvg0VzF6g=.b661fd27-931d-4c80-80ad-e8bef4fc6169@github.com>

On Tue, 28 Jun 2022 19:41:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > BTW why this PR is raised against JDK19 and not mainline?
> 
> Don't all fixes from JDK19 have merged to the mainline "automatically"?

I worried that [JDK19](https://openjdk.org/projects/jdk/19/) are in [RDP1](https://openjdk.org/jeps/3#rdp-1)  phase right now.

This bug  looks like a "Targeted P3" and it should be dropped.

Correct me if I am wrong.

-------------

PR: https://git.openjdk.org/jdk19/pull/81


From honkar at openjdk.org  Tue Jun 28 20:30:36 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 28 Jun 2022 20:30:36 GMT
Subject: RFR: JDK-8289238: Refactoring changes to PassFailJFrame Test
 Framework [v2]
In-Reply-To: <_SkmPalpZpi6t0eCeviOwNOoqE3Sq_tisiYSJXIvrSs=.12cb6181-116b-44b8-9c6e-aff6efc34132@github.com>
References: <_SkmPalpZpi6t0eCeviOwNOoqE3Sq_tisiYSJXIvrSs=.12cb6181-116b-44b8-9c6e-aff6efc34132@github.com>
Message-ID: <CuXuCDmj-jC4qLbSUsEfUuOyHjnB7QhdWkfe2SY0qps=.6d59b509-0997-4f7f-85ed-54fd430b1117@github.com>

> Currently PassFailJFrame.positionTestFrame() and PassFailJFrame.addTestFrame() take Frame as input parameter, this has been changed to Window.
> 
> Refactored the above method names to reflect the functionality & input parameter type -
> addTestWindow(), positionTestWindow()
> 
> Additionally added test fail reason to `forceFail()` to avoid NPE.
> 
> Benefits of the change -
> 
> - Since Window is a parent class, this would allow the test frame to be a Window/Frame/Dialog and not be restricted to a Frame.
> - Code reusability - no need to have separate methods to manage Frame and Window
> - Additionally it would allow proper clean-up of window and its container subclasses which are added to the PassFailJFrame.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  method doc changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9300/files
  - new: https://git.openjdk.org/jdk/pull/9300/files/ef00a014..30d379ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9300&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9300&range=00-01

  Stats: 9 lines in 1 file changed: 2 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/9300.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9300/head:pull/9300

PR: https://git.openjdk.org/jdk/pull/9300


From honkar at openjdk.org  Tue Jun 28 20:30:38 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 28 Jun 2022 20:30:38 GMT
Subject: RFR: JDK-8289238: Refactoring changes to PassFailJFrame Test
 Framework [v2]
In-Reply-To: <8anPjkswEqpc5aIsC3Uw6zH5Vw2xwyUGJoq4uSXC3sc=.e06f1dd4-0a07-4b58-b68d-fd3ce2c27186@github.com>
References: <_SkmPalpZpi6t0eCeviOwNOoqE3Sq_tisiYSJXIvrSs=.12cb6181-116b-44b8-9c6e-aff6efc34132@github.com>
 <8anPjkswEqpc5aIsC3Uw6zH5Vw2xwyUGJoq4uSXC3sc=.e06f1dd4-0a07-4b58-b68d-fd3ce2c27186@github.com>
Message-ID: <0bDGyQnJWC31aC1jGIft3XjFJivVWL0d0wu1w0ULLwo=.b589f80b-6794-4a12-a793-bd384d66f41d@github.com>

On Tue, 28 Jun 2022 19:07:04 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   method doc changes
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 263:
> 
>> 261:      * window) by the specified position
>> 262:      * Note: This method should be invoked from the method that creates
>> 263:      * testWindow
> 
> It looks like you accidentally removed the empty line that served as the visual delimiter.

@azvegint Thanks for catching it. Updated the PR with changes.

-------------

PR: https://git.openjdk.org/jdk/pull/9300


From serb at openjdk.org  Tue Jun 28 20:36:31 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Jun 2022 20:36:31 GMT
Subject: [jdk19] RFR: 8288854: getLocalGraphicsEnvironment() on for
 multi-screen setups throws exception NPE
In-Reply-To: <UQQzFnNCRrVMxTnIBMYFxWQVxH8CMAqiCdsvg0VzF6g=.b661fd27-931d-4c80-80ad-e8bef4fc6169@github.com>
References: <rBvFremdQsswOG5ynfNKjOFVDStHLAmeSgVIq8y6MrI=.dfa5031f-3b70-467e-8819-a3c8fc07e81b@github.com>
 <lWTcHrRDGZPPE6GyEAoh3-bn4Vint5Qtrjg0_O_Wvws=.76800aaa-c505-42f0-ad97-e5a1a7c28a32@github.com>
 <yNkJaf0rUP3Okm0PCwVK-zEWHNxx66yvgBIi4qxF_8o=.3bb91232-a07a-4207-a490-21447ae7eb54@github.com>
 <UQQzFnNCRrVMxTnIBMYFxWQVxH8CMAqiCdsvg0VzF6g=.b661fd27-931d-4c80-80ad-e8bef4fc6169@github.com>
Message-ID: <JDwnP68sBqXntWg68M-GNwnkudtVZcTuirZ5HOHUGgU=.3dbd4488-b39a-492c-9dd2-e8bfb929cb99@github.com>

On Tue, 28 Jun 2022 20:10:01 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> > Don't all fixes from JDK19 have merged to the mainline "automatically"?
> 
> I worried that [JDK19](https://openjdk.org/projects/jdk/19/) are in [RDP1](https://openjdk.org/jeps/3#rdp-1) phase right now.

This is the phase when all fixes are merged to the mainline.

>From your links above:
" In RDP 1, if the bug is targeted and if time permits, develop and integrate a fix when ready." 

| | Fix | Drop |
-- | -- | -- |
| RDP1 | Current P1?P3 | All P4?P5 |
|           |  Targeted P1?P3 if time |  Targeted P1?P3|
|           |  P1?P5 doc/test bugs |  |

Since the small fix for a recent regression is ready I do not see a reason to skip it?

-------------

PR: https://git.openjdk.org/jdk19/pull/81


From serb at openjdk.org  Wed Jun 29 00:56:53 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 29 Jun 2022 00:56:53 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v2]
In-Reply-To: <07vES8jtHcWypuL2HBv-ryMPrVDe0ti0mU_bVRdlzrk=.21082c4e-f4a3-434e-9584-05d0bc6c6c85@github.com>
References: <pClI2zW5gi4TBiMW2CeftBlBN_p5Z7KWF4fpeVZqtlg=.e332bcae-1242-4227-8804-9ae8f0576381@github.com>
 <07vES8jtHcWypuL2HBv-ryMPrVDe0ti0mU_bVRdlzrk=.21082c4e-f4a3-434e-9584-05d0bc6c6c85@github.com>
Message-ID: <NQEn4UlI5zgecxvgj0xhYrKPFG6rzEbonM5VYHeow60=.ff995bc9-b58b-4e53-bcff-796f60abfcf7@github.com>

On Fri, 17 Jun 2022 10:57:59 GMT, Manukumar V S <mvs at openjdk.org> wrote:

>> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines. It seems to be a testbug as adding some stability improvements fix the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. I have removed the problem listing and tested it in windows platform also, it works fine there.
>> 
>> Fix:
>> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fixed: Removed -Dsun.java2d.uiScale=1, frame.getLocationOnScreen() removed from EDT, added volatile keyword for actionEventReceivedLatch

test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 69:

> 67:             GraphicsConfiguration gc = sd.getDefaultConfiguration();
> 68:             Rectangle bounds = gc.getBounds();
> 69:             Point point = new Point(bounds.x + 20, bounds.y + 20);

Why do you need to add this additional 20 pixels? When we click on the frame we already shift the mouse click location by 130 pixels from the top of the frame.

test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 119:

> 117:     private static void openPopup(final Frame frame) throws Exception {
> 118:         robot.waitForIdle();
> 119:         Point loc = frame.getLocationOnScreen();

Since you removed the reading the location from EDT via a separate loc variable, you do not need to rename pt here? The only meaningful change is adding the CountDownLatch?

-------------

PR: https://git.openjdk.org/jdk/pull/9187


From serb at openjdk.org  Wed Jun 29 00:57:51 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 29 Jun 2022 00:57:51 GMT
Subject: RFR: 7124313: [macosx] Swing Popups should overlap taskbar
In-Reply-To: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
References: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
Message-ID: <9xMjk3dd3sii1oRMzJJVjqyNErsgCP0pmp1E2PROmfA=.3cfea599-deb4-4e32-8432-1b6cc3f625c9@github.com>

On Mon, 27 Jun 2022 07:01:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In macos, popups does not overlap taskbar unlike windows, as can be seen here  in "Settings"
> so we can omit this test from macOS run.
> 
> ![image](https://user-images.githubusercontent.com/43534309/175878607-6435da8c-ae32-4512-9cbc-0b449637e93f.png)

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9294


From serb at openjdk.org  Wed Jun 29 00:57:52 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 29 Jun 2022 00:57:52 GMT
Subject: RFR: 7124313: [macosx] Swing Popups should overlap taskbar
In-Reply-To: <jlkfeGa-PqeHcZG9-DI7iDCIZA5Aj5wyok2HxD4gUz4=.b2674f33-211f-4bff-8bff-ee7b23ef3878@github.com>
References: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
 <HlGIDPiB0f3Mq_JGq6sd0qpEB_4nIt92bt0385rv5go=.8221c450-19f7-41bc-92af-119bdb94feb3@github.com>
 <hyAWm8kSgiWe660i-TNJOnFBB56nD9RQTVP01lU49bc=.87789d34-cd22-455a-82bb-ae44b031ae44@github.com>
 <al4Gxs8vDwAwhb48NCZU5RBSrpAsxkfdJ8S0XqjWoJc=.7101b5e6-f60d-4a4f-834b-7f0e2b5f916f@github.com>
 <OivbfPyGy7u60DCp-eKipirKEhAy7ARAgP32YoQJfvc=.94c96847-02b5-465a-8b8a-0e697c8c2130@github.com>
 <tAQpruxnAfpyEr4VQ85VBbRy9gs4isjEDtktq3lrAlE=.1554b07f-fd53-4e19-be42-e4c4eb4d81d0@github.com>
 <jlkfeGa-PqeHcZG9-DI7iDCIZA5Aj5wyok2HxD4gUz4=.b2674f33-211f-4bff-8bff-ee7b23ef3878@github.com>
Message-ID: <iGfloR8QrT7IFOI_ksWTKG-CJ1bK8mRxiNMa586Q3rk=.2385db66-97dc-4583-b5fa-2dd6abb968c7@github.com>

On Tue, 28 Jun 2022 07:11:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> hat test works on macos for popup with many menu items and it overlaps the taskbar so why do we need another test (ie this test) to test the same on macos? I think we can omit this test from macos run as the other test test/jdk/javax/swing/JPopupMenu/7154841/bug7154841.java is testing the large popup behaviour in macos..

Since we found that fix, and the test that coverers the "large" use case the new test seems unnecessary.

-------------

PR: https://git.openjdk.org/jdk/pull/9294


From tr at openjdk.org  Wed Jun 29 04:14:45 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 29 Jun 2022 04:14:45 GMT
Subject: RFR: 8288707: javax/swing/JToolBar/4529206/bug4529206.java:
 setFloating does not work correctly
In-Reply-To: <RPkNNkTmYAcBhA67ENFKO2omtGISEideYdn_oyo51Kc=.8fa3ec08-fcb2-4c72-a78b-4b52f5010e00@github.com>
References: <RPkNNkTmYAcBhA67ENFKO2omtGISEideYdn_oyo51Kc=.8fa3ec08-fcb2-4c72-a78b-4b52f5010e00@github.com>
Message-ID: <-gydBAxQAXBi1nYpFXeaeAXh3XZvsqu-UmHmHYWA_nA=.349461b2-a043-46c7-a4b8-535da3c7c1ae@github.com>

On Fri, 24 Jun 2022 03:42:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing intermittently around 1 or 2 out of 30 runs. 
> Fixed by adding stability code, wait for a sec after frame is visible, set frame to center.
> Modified test has run at least 50 times in all platforms and 100 times in linux (where it is seen intermittently) without any issue.

Marked as reviewed by tr (Author).

-------------

PR: https://git.openjdk.org/jdk/pull/9269


From mvs at openjdk.org  Wed Jun 29 06:53:29 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 29 Jun 2022 06:53:29 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v3]
In-Reply-To: <pClI2zW5gi4TBiMW2CeftBlBN_p5Z7KWF4fpeVZqtlg=.e332bcae-1242-4227-8804-9ae8f0576381@github.com>
References: <pClI2zW5gi4TBiMW2CeftBlBN_p5Z7KWF4fpeVZqtlg=.e332bcae-1242-4227-8804-9ae8f0576381@github.com>
Message-ID: <Oq-1maRzr3_IDJJ6tzPK-WI_Tb25751Dq2VlOAfuvAk=.ef1eb442-03df-40ef-8e87-0c5d00096b97@github.com>

> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines. It seems to be a testbug as adding some stability improvements fix the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. I have removed the problem listing and tested it in windows platform also, it works fine there.
> 
> Fix:
> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.

Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fixed: Reverted variable name change, reverted +20 in point

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9187/files
  - new: https://git.openjdk.org/jdk/pull/9187/files/fbaa185a..50321cc2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9187&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9187&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9187.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9187/head:pull/9187

PR: https://git.openjdk.org/jdk/pull/9187


From mvs at openjdk.org  Wed Jun 29 06:53:30 2022
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 29 Jun 2022 06:53:30 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v2]
In-Reply-To: <NQEn4UlI5zgecxvgj0xhYrKPFG6rzEbonM5VYHeow60=.ff995bc9-b58b-4e53-bcff-796f60abfcf7@github.com>
References: <pClI2zW5gi4TBiMW2CeftBlBN_p5Z7KWF4fpeVZqtlg=.e332bcae-1242-4227-8804-9ae8f0576381@github.com>
 <07vES8jtHcWypuL2HBv-ryMPrVDe0ti0mU_bVRdlzrk=.21082c4e-f4a3-434e-9584-05d0bc6c6c85@github.com>
 <NQEn4UlI5zgecxvgj0xhYrKPFG6rzEbonM5VYHeow60=.ff995bc9-b58b-4e53-bcff-796f60abfcf7@github.com>
Message-ID: <Yr1gnb4-3V_qnfHg6ZMspi2teENcgX9JolgJHgV4WgI=.f9dfd53a-ec07-42f6-b9fd-17f11f209e88@github.com>

On Wed, 29 Jun 2022 00:53:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments fixed: Removed -Dsun.java2d.uiScale=1, frame.getLocationOnScreen() removed from EDT, added volatile keyword for actionEventReceivedLatch
>
> test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 69:
> 
>> 67:             GraphicsConfiguration gc = sd.getDefaultConfiguration();
>> 68:             Rectangle bounds = gc.getBounds();
>> 69:             Point point = new Point(bounds.x + 20, bounds.y + 20);
> 
> Why do you need to add this additional 20 pixels? When we click on the frame we already shift the mouse click location by 130 pixels from the top of the frame.

Reverted it

> test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 119:
> 
>> 117:     private static void openPopup(final Frame frame) throws Exception {
>> 118:         robot.waitForIdle();
>> 119:         Point loc = frame.getLocationOnScreen();
> 
> Since you removed the reading the location from EDT via a separate loc variable, you do not need to rename pt here? The only meaningful change is adding the CountDownLatch?

Reverted it

-------------

PR: https://git.openjdk.org/jdk/pull/9187


From psadhukhan at openjdk.org  Wed Jun 29 07:29:43 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 29 Jun 2022 07:29:43 GMT
Subject: RFR: 8288428: javax/swing/JInternalFrame/Test6505027.java fails
 frequently in MacOS 12 machines
In-Reply-To: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
References: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
Message-ID: <kHwF4wpRdudfrO9m88NGH94PTvB-Nygh0M26N51DJ3Y=.e485a5ef-c36f-48a5-aad6-783e78cec378@github.com>

On Fri, 17 Jun 2022 14:28:15 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> javax/swing/JInternalFrame/Test6505027.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines and it fails intermittently in CI causing some noise.
> It seems to be a testbug as adding some stability improvements fix the issue.
> 
> Fix:
> Some stability improvements have been done and the test has been run 10 times per platform in mach5 and got full PASS.

I dont see this test failing in our CI systems "frequently"...last time it failed is June8 on a CI system which had some history of config issue, and that too on jdk17 binary and not on mainline..before that it fails on June1 due to some infra issue on mainline..and before that on June19 2021 on jdk11 binary again due to infra issue..so I dont think it's worth tinkering as of now..

also, the test has some quirks as I see. press() method is never called...it uses internal SwingTest class to start the test which I am not sure is needed

-------------

PR: https://git.openjdk.org/jdk/pull/9202


From dmarkov at openjdk.org  Wed Jun 29 08:30:41 2022
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Wed, 29 Jun 2022 08:30:41 GMT
Subject: RFR: 7124313: [macosx] Swing Popups should overlap taskbar
In-Reply-To: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
References: <CvC8XHwTF4y86TIa16ehwpmF2oOJltyKBmhFToQZi2s=.30165df6-9129-4a30-9a17-d9e88dbb5137@github.com>
Message-ID: <Mhuio7I_YF9zJU-qPU04dhOS-KcFqeqmgD7B1FR8qjI=.a7f94ca7-eec5-4135-a3b4-6e07ed14a81c@github.com>

On Mon, 27 Jun 2022 07:01:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In macos, popups does not overlap taskbar unlike windows, as can be seen here  in "Settings"
> so we can omit this test from macOS run.
> 
> ![image](https://user-images.githubusercontent.com/43534309/175878607-6435da8c-ae32-4512-9cbc-0b449637e93f.png)

Marked as reviewed by dmarkov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9294


From psadhukhan at openjdk.org  Wed Jun 29 08:48:12 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 29 Jun 2022 08:48:12 GMT
Subject: RFR: 8065097: [macosx] javax/swing/Popup/TaskbarPositionTest.java
 fails because Popup is one pixel off
Message-ID: <BimPX6gcNKvSz84fo1LBdTu3wBQtCmq1SKlP9JbN6GU=.4e65b93d-e1ec-4cd5-b1e1-24d82c2f750b@github.com>

Test seems to fail in macOS citing popup location is 1 pixel off compared to combobox position ie
`p.y 154 cpos.y 155`

But in macOS, popup location, if 1st entry is selected, is 1 pixel higher than combobox so it's expected as can be seen below
<img width="661" alt="Screenshot 2022-06-29 at 1 53 42 PM" src="https://user-images.githubusercontent.com/43534309/176389227-4e568117-ffce-4b4a-92d7-ab5c78c4ce08.png">

so test is updated to add 1 pixel to popup location. 
It will not affect windows and linux as popup is placed below the combobox in those platforms so 1 pixel higher will not make any difference.
Also, added some stability fixes..Test passed for several iterations in all platforms in CI..

-------------

Commit messages:
 - 8065097: [macosx] javax/swing/Popup/TaskbarPositionTest.java fails because Popup is one pixel off
 - 8065097: [macosx] javax/swing/Popup/TaskbarPositionTest.java fails because Popup is one pixel off
 - 8065097: [macosx] javax/swing/Popup/TaskbarPositionTest.java fails because Popup is one pixel off

Changes: https://git.openjdk.org/jdk/pull/9321/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9321&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8065097
  Stats: 128 lines in 2 files changed: 36 ins; 1 del; 91 mod
  Patch: https://git.openjdk.org/jdk/pull/9321.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9321/head:pull/9321

PR: https://git.openjdk.org/jdk/pull/9321


From aivanov at openjdk.org  Wed Jun 29 10:14:41 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 29 Jun 2022 10:14:41 GMT
Subject: RFR: JDK-8289238: Refactoring changes to PassFailJFrame Test
 Framework [v2]
In-Reply-To: <CuXuCDmj-jC4qLbSUsEfUuOyHjnB7QhdWkfe2SY0qps=.6d59b509-0997-4f7f-85ed-54fd430b1117@github.com>
References: <_SkmPalpZpi6t0eCeviOwNOoqE3Sq_tisiYSJXIvrSs=.12cb6181-116b-44b8-9c6e-aff6efc34132@github.com>
 <CuXuCDmj-jC4qLbSUsEfUuOyHjnB7QhdWkfe2SY0qps=.6d59b509-0997-4f7f-85ed-54fd430b1117@github.com>
Message-ID: <V0iIN0fi2BDdoGIMOwuSUlH1LxAKebcTrdmeEIBz2l8=.3a596c95-a5d4-41cc-bfb8-79502488f87b@github.com>

On Tue, 28 Jun 2022 20:30:36 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Currently PassFailJFrame.positionTestFrame() and PassFailJFrame.addTestFrame() take Frame as input parameter, this has been changed to Window.
>> 
>> Refactored the above method names to reflect the functionality & input parameter type -
>> addTestWindow(), positionTestWindow()
>> 
>> Additionally added test fail reason to `forceFail()` to avoid NPE.
>> 
>> Benefits of the change -
>> 
>> - Since Window is a parent class, this would allow the test frame to be a Window/Frame/Dialog and not be restricted to a Frame.
>> - Code reusability - no need to have separate methods to manage Frame and Window
>> - Additionally it would allow proper clean-up of window and its container subclasses which are added to the PassFailJFrame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   method doc changes

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 221:

> 219:      * the window(s) that is added via addTestWindow(Window testWindow)
> 220:      */
> 221:     private static synchronized void disposeFrames() {

Suggestion:

    private static synchronized void disposeWindows() {

-------------

PR: https://git.openjdk.org/jdk/pull/9300


From aivanov at openjdk.org  Wed Jun 29 10:19:42 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 29 Jun 2022 10:19:42 GMT
Subject: [jdk19] RFR: 8288854: getLocalGraphicsEnvironment() on for
 multi-screen setups throws exception NPE
In-Reply-To: <rBvFremdQsswOG5ynfNKjOFVDStHLAmeSgVIq8y6MrI=.dfa5031f-3b70-467e-8819-a3c8fc07e81b@github.com>
References: <rBvFremdQsswOG5ynfNKjOFVDStHLAmeSgVIq8y6MrI=.dfa5031f-3b70-467e-8819-a3c8fc07e81b@github.com>
Message-ID: <LN1V26MZWfa-QiruBtHPImLkb3eGUANT1cWLHMWe9yI=.2da0a692-8882-4c12-8a6d-db3b9d31f5b2@github.com>

On Mon, 27 Jun 2022 21:17:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the fix for a copy-paste error. The fix JDK-8076313 replaced the usage of the "screens" array from the parent class to the "devices" where the list of devices is now maintained. Since "screens" array is never used nor initialized its usage caused an NPE. That check was copied as-is, while it should use the actual number of screen devices requested early in that method.
> 
> The bug is rarely reproduced because in single screen configuration the main screen is usually 0, and in the multiscreen configuration Xinerama is usually active so the main screen is also 0 => the second part of the "if" statement is not executed.
> 
> I have validated the fix by the SwingSet, I also executed desktop tests in that config and found that even though this particular bug is fixed we still have many issues there, around ~100 tests failed.

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/81


From aivanov at openjdk.org  Wed Jun 29 10:22:53 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 29 Jun 2022 10:22:53 GMT
Subject: RFR: JDK-8289238: Refactoring changes to PassFailJFrame Test
 Framework [v2]
In-Reply-To: <CuXuCDmj-jC4qLbSUsEfUuOyHjnB7QhdWkfe2SY0qps=.6d59b509-0997-4f7f-85ed-54fd430b1117@github.com>
References: <_SkmPalpZpi6t0eCeviOwNOoqE3Sq_tisiYSJXIvrSs=.12cb6181-116b-44b8-9c6e-aff6efc34132@github.com>
 <CuXuCDmj-jC4qLbSUsEfUuOyHjnB7QhdWkfe2SY0qps=.6d59b509-0997-4f7f-85ed-54fd430b1117@github.com>
Message-ID: <Wsgf6WHuWCHPhj6qHGBz-HT-xVmIxqztHceR5DCjVGA=.a4935275-09f1-465d-8280-63be6a5fc79f@github.com>

On Tue, 28 Jun 2022 20:30:36 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Currently PassFailJFrame.positionTestFrame() and PassFailJFrame.addTestFrame() take Frame as input parameter, this has been changed to Window.
>> 
>> Refactored the above method names to reflect the functionality & input parameter type -
>> addTestWindow(), positionTestWindow()
>> 
>> Additionally added test fail reason to `forceFail()` to avoid NPE.
>> 
>> Benefits of the change -
>> 
>> - Since Window is a parent class, this would allow the test frame to be a Window/Frame/Dialog and not be restricted to a Frame.
>> - Code reusability - no need to have separate methods to manage Frame and Window
>> - Additionally it would allow proper clean-up of window and its container subclasses which are added to the PassFailJFrame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   method doc changes

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 319:

> 317:         failed = true;
> 318:         testFailedReason = "Failure Reason:\n" +
> 319:                            "Test force failed";

Maybe _"forceFail called"_?

-------------

PR: https://git.openjdk.org/jdk/pull/9300


From duke at openjdk.org  Wed Jun 29 13:16:19 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 29 Jun 2022 13:16:19 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as 1 KB
Message-ID: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>

JFileChooser - empty file size issue fixed. 
For empty file, now the size 0 bytes.
Manual Test Case "ZeroFileSizeCheck.java" created.

-------------

Commit messages:
 - JFileChooser empty file size 0 bytes fixed

Changes: https://git.openjdk.org/jdk/pull/9327/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288882
  Stats: 94 lines in 2 files changed: 90 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From aivanov at openjdk.org  Wed Jun 29 13:39:57 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 29 Jun 2022 13:39:57 GMT
Subject: RFR: 8065097: [macosx] javax/swing/Popup/TaskbarPositionTest.java
 fails because Popup is one pixel off
In-Reply-To: <BimPX6gcNKvSz84fo1LBdTu3wBQtCmq1SKlP9JbN6GU=.4e65b93d-e1ec-4cd5-b1e1-24d82c2f750b@github.com>
References: <BimPX6gcNKvSz84fo1LBdTu3wBQtCmq1SKlP9JbN6GU=.4e65b93d-e1ec-4cd5-b1e1-24d82c2f750b@github.com>
Message-ID: <fCQSURhDR7tba6ZAbD4A7tUmJ6xe-Otd-UxxIsOwRHw=.5d3fa309-a6c4-4a79-952b-99d40860933d@github.com>

On Wed, 29 Jun 2022 08:28:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seems to fail in macOS citing popup location is 1 pixel off compared to combobox position ie
> `p.y 154 cpos.y 155`
> 
> But in macOS, popup location, if 1st entry is selected, is 1 pixel higher than combobox so it's expected as can be seen below
> <img width="661" alt="Screenshot 2022-06-29 at 1 53 42 PM" src="https://user-images.githubusercontent.com/43534309/176389227-4e568117-ffce-4b4a-92d7-ab5c78c4ce08.png">
> 
> so test is updated to add 1 pixel to popup location. 
> It will not affect windows and linux as popup is placed below the combobox in those platforms so 1 pixel higher will not make any difference.
> Also, added some stability fixes..Test passed for several iterations in all platforms in CI..

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/Popup/TaskbarPositionTest.java line 108:

> 106: 
> 107:         // Place the frame near the bottom. This is a pretty wild guess.
> 108:         frame.setLocation(0, (int) screenBounds.getHeight() - 2 * frame.getHeight());

The cast to `int` is unnecessary.

Below calculations let position the frame exactly at the bottom of the screen (excluding insets):


            frame.setLocation(0, screenBounds.y + screenBounds.height - frame.getHeight());

test/jdk/javax/swing/Popup/TaskbarPositionTest.java line 121:

> 119:         }
> 120: 
> 121:         frame.setLocationRelativeTo(null);

This line puts the frame in the centre of the screen and the test becomes useless. The frame *must be located* at the bottom of the screen to verify the popup windows are shown on top of the taskbar / dock. In fact, the popups are located so that bottom of the popup is at the bottom of the combobox / menu item.

test/jdk/javax/swing/Popup/TaskbarPositionTest.java line 350:

> 348:             Point pt = new Point(2, 2);
> 349:             SwingUtilities.convertPointToScreen(pt, panel);
> 350:             robot.mouseMove((int) pt.getX(), (int) pt.getY());

Suggestion:

            robot.mouseMove(pt.getX(), pt.getY());


Cast to `int` is redundant, isn't it?

-------------

PR: https://git.openjdk.org/jdk/pull/9321


From duke at openjdk.org  Wed Jun 29 15:31:47 2022
From: duke at openjdk.org (Andy Goryachev)
Date: Wed, 29 Jun 2022 15:31:47 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <zPBsBu3-7oO4IXGsWLQ9yRptxskdeNWG5enL3pndDmg=.b23bd433-7a2b-4251-9c3d-ab4119aa40b0@github.com>

On Wed, 29 Jun 2022 13:06:21 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 bytes.
> Manual Test Case "ZeroFileSizeCheck.java" created.

src/java.desktop/share/classes/sun/swing/FilePane.java line 1198:

> 1196:                     text = MessageFormat.format(kiloByteString, len + 1);
> 1197:                 } else if (len < 1024L) {
> 1198:                     text = (len == 0L) ? 0 + " bytes" : len + " bytes";

Is this necessary?
0 + " bytes" -->  "0 bytes"

Also, will this code work correctly for non-English locales?

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From honkar at openjdk.org  Wed Jun 29 17:05:26 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 29 Jun 2022 17:05:26 GMT
Subject: RFR: JDK-8289238: Refactoring changes to PassFailJFrame Test
 Framework [v3]
In-Reply-To: <_SkmPalpZpi6t0eCeviOwNOoqE3Sq_tisiYSJXIvrSs=.12cb6181-116b-44b8-9c6e-aff6efc34132@github.com>
References: <_SkmPalpZpi6t0eCeviOwNOoqE3Sq_tisiYSJXIvrSs=.12cb6181-116b-44b8-9c6e-aff6efc34132@github.com>
Message-ID: <V2NNya3HUczKMj_4lMDQNW4e-tnWa_CrnNZi5Cosp2g=.45de379f-16ae-4e33-b16c-2c0186ee5917@github.com>

> Currently PassFailJFrame.positionTestFrame() and PassFailJFrame.addTestFrame() take Frame as input parameter, this has been changed to Window.
> 
> Refactored the above method names to reflect the functionality & input parameter type -
> addTestWindow(), positionTestWindow()
> 
> Additionally added test fail reason to `forceFail()` to avoid NPE.
> 
> Benefits of the change -
> 
> - Since Window is a parent class, this would allow the test frame to be a Window/Frame/Dialog and not be restricted to a Frame.
> - Code reusability - no need to have separate methods to manage Frame and Window
> - Additionally it would allow proper clean-up of window and its container subclasses which are added to the PassFailJFrame.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  rename changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9300/files
  - new: https://git.openjdk.org/jdk/pull/9300/files/30d379ab..1270cafa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9300&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9300&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9300.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9300/head:pull/9300

PR: https://git.openjdk.org/jdk/pull/9300


From honkar at openjdk.org  Wed Jun 29 17:17:11 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 29 Jun 2022 17:17:11 GMT
Subject: RFR: JDK-8289238: Refactoring changes to PassFailJFrame Test
 Framework [v4]
In-Reply-To: <_SkmPalpZpi6t0eCeviOwNOoqE3Sq_tisiYSJXIvrSs=.12cb6181-116b-44b8-9c6e-aff6efc34132@github.com>
References: <_SkmPalpZpi6t0eCeviOwNOoqE3Sq_tisiYSJXIvrSs=.12cb6181-116b-44b8-9c6e-aff6efc34132@github.com>
Message-ID: <xmxar9VPfTLjkaFjXi7YqNiNUC8yKYs3CRPqNaUBlco=.b3b9915e-d552-4112-b517-041a8c8cd4ea@github.com>

> Currently PassFailJFrame.positionTestFrame() and PassFailJFrame.addTestFrame() take Frame as input parameter, this has been changed to Window.
> 
> Refactored the above method names to reflect the functionality & input parameter type -
> addTestWindow(), positionTestWindow()
> 
> Additionally added test fail reason to `forceFail()` to avoid NPE.
> 
> Benefits of the change -
> 
> - Since Window is a parent class, this would allow the test frame to be a Window/Frame/Dialog and not be restricted to a Frame.
> - Code reusability - no need to have separate methods to manage Frame and Window
> - Additionally it would allow proper clean-up of window and its container subclasses which are added to the PassFailJFrame.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  minor change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9300/files
  - new: https://git.openjdk.org/jdk/pull/9300/files/1270cafa..3539873f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9300&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9300&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9300.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9300/head:pull/9300

PR: https://git.openjdk.org/jdk/pull/9300


From azvegint at openjdk.org  Wed Jun 29 17:24:23 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 29 Jun 2022 17:24:23 GMT
Subject: RFR: JDK-8289238: Refactoring changes to PassFailJFrame Test
 Framework [v4]
In-Reply-To: <xmxar9VPfTLjkaFjXi7YqNiNUC8yKYs3CRPqNaUBlco=.b3b9915e-d552-4112-b517-041a8c8cd4ea@github.com>
References: <_SkmPalpZpi6t0eCeviOwNOoqE3Sq_tisiYSJXIvrSs=.12cb6181-116b-44b8-9c6e-aff6efc34132@github.com>
 <xmxar9VPfTLjkaFjXi7YqNiNUC8yKYs3CRPqNaUBlco=.b3b9915e-d552-4112-b517-041a8c8cd4ea@github.com>
Message-ID: <f713aWbonNxsENw1oxV2s-DolgCzWswRpaNUTpHyqzM=.64d4b4b0-db74-44fc-a4d0-7cfa8e4ae15d@github.com>

On Wed, 29 Jun 2022 17:17:11 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Currently PassFailJFrame.positionTestFrame() and PassFailJFrame.addTestFrame() take Frame as input parameter, this has been changed to Window.
>> 
>> Refactored the above method names to reflect the functionality & input parameter type -
>> addTestWindow(), positionTestWindow()
>> 
>> Additionally added test fail reason to `forceFail()` to avoid NPE.
>> 
>> Benefits of the change -
>> 
>> - Since Window is a parent class, this would allow the test frame to be a Window/Frame/Dialog and not be restricted to a Frame.
>> - Code reusability - no need to have separate methods to manage Frame and Window
>> - Additionally it would allow proper clean-up of window and its container subclasses which are added to the PassFailJFrame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor change

Marked as reviewed by azvegint (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9300


From aivanov at openjdk.org  Wed Jun 29 18:23:32 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 29 Jun 2022 18:23:32 GMT
Subject: RFR: JDK-8289238: Refactoring changes to PassFailJFrame Test
 Framework [v4]
In-Reply-To: <xmxar9VPfTLjkaFjXi7YqNiNUC8yKYs3CRPqNaUBlco=.b3b9915e-d552-4112-b517-041a8c8cd4ea@github.com>
References: <_SkmPalpZpi6t0eCeviOwNOoqE3Sq_tisiYSJXIvrSs=.12cb6181-116b-44b8-9c6e-aff6efc34132@github.com>
 <xmxar9VPfTLjkaFjXi7YqNiNUC8yKYs3CRPqNaUBlco=.b3b9915e-d552-4112-b517-041a8c8cd4ea@github.com>
Message-ID: <oCQRchm9SpCLX59maz68ggfm1nWyQLWCmbinLmXHmpU=.787bc3a2-6063-4cb4-b730-02fa4dd1baea@github.com>

On Wed, 29 Jun 2022 17:17:11 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Currently PassFailJFrame.positionTestFrame() and PassFailJFrame.addTestFrame() take Frame as input parameter, this has been changed to Window.
>> 
>> Refactored the above method names to reflect the functionality & input parameter type -
>> addTestWindow(), positionTestWindow()
>> 
>> Additionally added test fail reason to `forceFail()` to avoid NPE.
>> 
>> Benefits of the change -
>> 
>> - Since Window is a parent class, this would allow the test frame to be a Window/Frame/Dialog and not be restricted to a Frame.
>> - Code reusability - no need to have separate methods to manage Frame and Window
>> - Additionally it would allow proper clean-up of window and its container subclasses which are added to the PassFailJFrame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor change

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9300


From honkar at openjdk.org  Wed Jun 29 18:39:42 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 29 Jun 2022 18:39:42 GMT
Subject: Integrated: JDK-8289238: Refactoring changes to PassFailJFrame Test
 Framework
In-Reply-To: <_SkmPalpZpi6t0eCeviOwNOoqE3Sq_tisiYSJXIvrSs=.12cb6181-116b-44b8-9c6e-aff6efc34132@github.com>
References: <_SkmPalpZpi6t0eCeviOwNOoqE3Sq_tisiYSJXIvrSs=.12cb6181-116b-44b8-9c6e-aff6efc34132@github.com>
Message-ID: <ZnZCURxXdj-Udaev2ag0dloSptIWYH9nsYnvMkz7ivo=.842c5be7-a825-4400-ba94-773a83bf0026@github.com>

On Tue, 28 Jun 2022 00:58:42 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Currently PassFailJFrame.positionTestFrame() and PassFailJFrame.addTestFrame() take Frame as input parameter, this has been changed to Window.
> 
> Refactored the above method names to reflect the functionality & input parameter type -
> addTestWindow(), positionTestWindow()
> 
> Additionally added test fail reason to `forceFail()` to avoid NPE.
> 
> Benefits of the change -
> 
> - Since Window is a parent class, this would allow the test frame to be a Window/Frame/Dialog and not be restricted to a Frame.
> - Code reusability - no need to have separate methods to manage Frame and Window
> - Additionally it would allow proper clean-up of window and its container subclasses which are added to the PassFailJFrame.

This pull request has now been integrated.

Changeset: 15efb2bd
Author:    Harshitha Onkar <honkar at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/15efb2bdeb73e4e255dcc864be1a83450a2beaa8
Stats:     43 lines in 8 files changed: 3 ins; 2 del; 38 mod

8289238: Refactoring changes to PassFailJFrame Test Framework

Reviewed-by: azvegint, aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/9300


From aivanov at openjdk.org  Wed Jun 29 19:28:41 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 29 Jun 2022 19:28:41 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <dV1Ccxduu206-uCqBxaFOaNwIphVu1aHpy_pEItZwkE=.7bc9709d-f14e-4046-b2f7-c2e848836545@github.com>

On Wed, 29 Jun 2022 13:06:21 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 bytes.
> Manual Test Case "ZeroFileSizeCheck.java" created.

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JFileChooser/ZeroFileSizeCheck.java line 56:

> 54:             JFileChooser fc = new JFileChooser();
> 55:             try {
> 56:                 Path currentDir = Paths.get(System.getProperty("java.io.tmpdir"));

Why not create it in the `test.src` value? This property is defined by jtreg. If the property is not set, default to `.`, that is the current directory.

test/jdk/javax/swing/JFileChooser/ZeroFileSizeCheck.java line 66:

> 64:                 throw new RuntimeException(ex);
> 65:             }
> 66:             frame.getContentPane().add(fc);

Usually, you don't add [`JFileChooser`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JFileChooser.html) to a container but rather use it as a dialog box:

int returnVal = chooser.showOpenDialog(parent);

where `parent` is the parent of the created `JDialog`.

However, it's basically what's done in `showDialog` / `createDialog` methods.
https://github.com/openjdk/jdk/blob/ec4fb47b90c9737dfdc285ebe98367a221c90c79/src/java.desktop/share/classes/javax/swing/JFileChooser.java#L823-L825

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From aivanov at openjdk.org  Wed Jun 29 19:28:43 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 29 Jun 2022 19:28:43 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB
In-Reply-To: <zPBsBu3-7oO4IXGsWLQ9yRptxskdeNWG5enL3pndDmg=.b23bd433-7a2b-4251-9c3d-ab4119aa40b0@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <zPBsBu3-7oO4IXGsWLQ9yRptxskdeNWG5enL3pndDmg=.b23bd433-7a2b-4251-9c3d-ab4119aa40b0@github.com>
Message-ID: <iiLFyt280_7JervKLHgpf-l5fdTYKqcoCnr9LoR0yBc=.3f5682f2-b5f8-48b7-9ec6-e64c1d738bcd@github.com>

On Wed, 29 Jun 2022 15:26:57 GMT, Andy Goryachev <duke at openjdk.org> wrote:

> Also, will this code work correctly for non-English locales?

It won't.

It has to use `MessageFormat` and it has to add a new string to the resource bundle.

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From honkar at openjdk.org  Thu Jun 30 00:05:26 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 30 Jun 2022 00:05:26 GMT
Subject: RFR: 8288444: Remove the workaround for frame.pack() in
 ModalDialogTest [v2]
In-Reply-To: <88CU8XufxULaqu9xL-G581LBMSlsAR9TU_fuKspZs20=.e576f3b0-e3ff-4037-9cb9-a92bf204cb02@github.com>
References: <88CU8XufxULaqu9xL-G581LBMSlsAR9TU_fuKspZs20=.e576f3b0-e3ff-4037-9cb9-a92bf204cb02@github.com>
Message-ID: <JtGCoxst-LpbFmHQQDqFANrG3MmP7-_b1N8OMKzSh6M=.76417975-afb2-411c-aa46-49e04c65b9be@github.com>

> Previously frame.pack() was called twice as a workaround  AWT frame sizing issue in this particular test case on Windows. This issue was fixed **[JDK-8265586](https://bugs.openjdk.org/browse/JDK-8265586)** and hence the workaround is being removed from this test.
> 
> PassFailJFrame is being used as the test framework. 
> 
> **Proposed change related to PassFailJFrame Test framework**
> 
> Instead of creating separate methods to handle AWT Windows as well as Frames, method signatures - [**PassFailJFrame.positionTestFrame()**](https://github.com/openjdk/jdk/blob/53b37fe1535388eb14e04c620a6b0118ed8884a0/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L271) and [**PassFailJFrame.addTestFrame()**](https://github.com/openjdk/jdk/blob/53b37fe1535388eb14e04c620a6b0118ed8884a0/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L294) can be changed to take in Window as input parameter instead of Frame, since Window is a superclass, this would allow the test frame to be a Window/Frame/Dialog and not be restricted to a Frame, additionally would allow proper disposal of windows added to the PassFailJFrame.

Harshitha Onkar 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 two additional commits since the last revision:

 - Merge branch 'master' into ModalTestGBr_8288444
 - ModalDialogTest changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9286/files
  - new: https://git.openjdk.org/jdk/pull/9286/files/e0f3fddd..6f9e78a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9286&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9286&range=00-01

  Stats: 55872 lines in 909 files changed: 33563 ins; 10740 del; 11569 mod
  Patch: https://git.openjdk.org/jdk/pull/9286.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9286/head:pull/9286

PR: https://git.openjdk.org/jdk/pull/9286


From honkar at openjdk.org  Thu Jun 30 00:09:27 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 30 Jun 2022 00:09:27 GMT
Subject: RFR: 8288444: Remove the workaround for frame.pack() in
 ModalDialogTest [v3]
In-Reply-To: <88CU8XufxULaqu9xL-G581LBMSlsAR9TU_fuKspZs20=.e576f3b0-e3ff-4037-9cb9-a92bf204cb02@github.com>
References: <88CU8XufxULaqu9xL-G581LBMSlsAR9TU_fuKspZs20=.e576f3b0-e3ff-4037-9cb9-a92bf204cb02@github.com>
Message-ID: <H-Yo0nznghw6-cPf7yuGxX0Lskp_zc36Ae7CPuxCTHs=.465f1b02-fb98-457d-8055-1af31dc0f314@github.com>

> Previously frame.pack() was called twice as a workaround  AWT frame sizing issue in this particular test case on Windows. This issue was fixed **[JDK-8265586](https://bugs.openjdk.org/browse/JDK-8265586)** and hence the workaround is being removed from this test.
> 
> PassFailJFrame is being used as the test framework. 
> 
> **Proposed change related to PassFailJFrame Test framework**
> 
> Instead of creating separate methods to handle AWT Windows as well as Frames, method signatures - [**PassFailJFrame.positionTestFrame()**](https://github.com/openjdk/jdk/blob/53b37fe1535388eb14e04c620a6b0118ed8884a0/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L271) and [**PassFailJFrame.addTestFrame()**](https://github.com/openjdk/jdk/blob/53b37fe1535388eb14e04c620a6b0118ed8884a0/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L294) can be changed to take in Window as input parameter instead of Frame, since Window is a superclass, this would allow the test frame to be a Window/Frame/Dialog and not be restricted to a Frame, additionally would allow proper disposal of windows added to the PassFailJFrame.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  PassFailJFrame changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9286/files
  - new: https://git.openjdk.org/jdk/pull/9286/files/6f9e78a1..1872092e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9286&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9286&range=01-02

  Stats: 29 lines in 1 file changed: 8 ins; 4 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/9286.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9286/head:pull/9286

PR: https://git.openjdk.org/jdk/pull/9286


From psadhukhan at openjdk.org  Thu Jun 30 04:08:39 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 30 Jun 2022 04:08:39 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB
In-Reply-To: <iiLFyt280_7JervKLHgpf-l5fdTYKqcoCnr9LoR0yBc=.3f5682f2-b5f8-48b7-9ec6-e64c1d738bcd@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <zPBsBu3-7oO4IXGsWLQ9yRptxskdeNWG5enL3pndDmg=.b23bd433-7a2b-4251-9c3d-ab4119aa40b0@github.com>
 <iiLFyt280_7JervKLHgpf-l5fdTYKqcoCnr9LoR0yBc=.3f5682f2-b5f8-48b7-9ec6-e64c1d738bcd@github.com>
Message-ID: <IfsD9O9_j0LoWotkRCNUx9JqW3oHQTjXs_BLR1hZ578=.d5f48ab6-e334-4a30-88a2-58928afc9f75@github.com>

On Wed, 29 Jun 2022 19:08:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/swing/FilePane.java line 1198:
>> 
>>> 1196:                     text = MessageFormat.format(kiloByteString, len + 1);
>>> 1197:                 } else if (len < 1024L) {
>>> 1198:                     text = (len == 0L) ? 0 + " bytes" : len + " bytes";
>> 
>> Is this necessary?
>> 0 + " bytes" -->  "0 bytes"
>> 
>> Also, will this code work correctly for non-English locales?
>
>> Also, will this code work correctly for non-English locales?
> 
> It won't.
> 
> It has to use `MessageFormat` and it has to add a new string to the resource bundle.

Dont think this len==0 check is needed...
One can use text = len + "bytes";

Also, this has i18n connection to it, so you need to use "byteString" similar to "kiloByteString", point it to 
UIManager.getString("FileChooser.fileSizeBytes", l); and add "FileChooser.fileSizeBytes" entry into 
share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties
share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties
share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties
share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties
share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties
share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties
share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties
share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties
share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties
share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties

I am not sure if need i18n team's intervention to update those resources as "bytes" can be translated to native in jp, zh
Maybe @naotoj can throw some light on that how to go about updating those resource file

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jun 30 06:14:44 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 30 Jun 2022 06:14:44 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v5]
In-Reply-To: <PZcKj61PMBN6ZeS_BCrdwMUiMhu9K5XyX8V3VBvXvzQ=.836e74ac-5c97-47b2-adc0-4d21e56d734e@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <PZcKj61PMBN6ZeS_BCrdwMUiMhu9K5XyX8V3VBvXvzQ=.836e74ac-5c97-47b2-adc0-4d21e56d734e@github.com>
Message-ID: <XHpHLV3CPCZXxHD7i61QW4BoaC9MSyEVGWvyc5ovWOQ=.852f8b23-b67c-45cd-b061-4bcdde8c28f5@github.com>

On Tue, 28 Jun 2022 11:15:41 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JLabel and AbstractButton's imageUpdate method description updated.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   passed in text added

Please review the CSR raised. 
https://bugs.openjdk.org/browse/JDK-8289490

-------------

PR: https://git.openjdk.org/jdk/pull/9240


From duke at openjdk.org  Thu Jun 30 08:24:21 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 30 Jun 2022 08:24:21 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB
In-Reply-To: <IfsD9O9_j0LoWotkRCNUx9JqW3oHQTjXs_BLR1hZ578=.d5f48ab6-e334-4a30-88a2-58928afc9f75@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <zPBsBu3-7oO4IXGsWLQ9yRptxskdeNWG5enL3pndDmg=.b23bd433-7a2b-4251-9c3d-ab4119aa40b0@github.com>
 <iiLFyt280_7JervKLHgpf-l5fdTYKqcoCnr9LoR0yBc=.3f5682f2-b5f8-48b7-9ec6-e64c1d738bcd@github.com>
 <IfsD9O9_j0LoWotkRCNUx9JqW3oHQTjXs_BLR1hZ578=.d5f48ab6-e334-4a30-88a2-58928afc9f75@github.com>
Message-ID: <zzI3u66CkzSb_fibwzwxh0DJRGyj9wdEI98r9DIGD3E=.be930635-4bca-4814-9b86-85df0adb17df@github.com>

On Thu, 30 Jun 2022 04:05:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> Also, will this code work correctly for non-English locales?
>> 
>> It won't.
>> 
>> It has to use `MessageFormat` and it has to add a new string to the resource bundle.
>
> Dont think this len==0 check is needed...
> One can use text = len + "bytes";
> 
> Also, this has i18n connection to it, so you need to use "byteString" similar to "kiloByteString", point it to 
> UIManager.getString("FileChooser.fileSizeBytes", l); and add "FileChooser.fileSizeBytes" entry into 
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties
> 
> I am not sure if need i18n team's intervention to update those resources as "bytes" can be translated to native in jp, zh
> Maybe @naotoj can throw some light on that how to go about updating those resource file

> > Also, will this code work correctly for non-English locales?
> 
> It won't.
> 
> It has to use `MessageFormat` and it has to add a new string to the resource bundle.

Yeah, I will check on this

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Thu Jun 30 08:55:11 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 30 Jun 2022 08:55:11 GMT
Subject: RFR: 8065097: [macosx] javax/swing/Popup/TaskbarPositionTest.java
 fails because Popup is one pixel off [v2]
In-Reply-To: <BimPX6gcNKvSz84fo1LBdTu3wBQtCmq1SKlP9JbN6GU=.4e65b93d-e1ec-4cd5-b1e1-24d82c2f750b@github.com>
References: <BimPX6gcNKvSz84fo1LBdTu3wBQtCmq1SKlP9JbN6GU=.4e65b93d-e1ec-4cd5-b1e1-24d82c2f750b@github.com>
Message-ID: <DQ06-YdKg20r_NozEWc61kYvWimXmlYHN9dt1kcxEIs=.4e503f4f-8274-451e-9a0d-dae5dde9468c@github.com>

> Test seems to fail in macOS citing popup location is 1 pixel off compared to combobox position ie
> `p.y 154 cpos.y 155`
> 
> But in macOS, popup location, if 1st entry is selected, is 1 pixel higher than combobox so it's expected as can be seen below
> <img width="661" alt="Screenshot 2022-06-29 at 1 53 42 PM" src="https://user-images.githubusercontent.com/43534309/176389227-4e568117-ffce-4b4a-92d7-ab5c78c4ce08.png">
> 
> so test is updated to add 1 pixel to popup location. 
> It will not affect windows and linux as popup is placed below the combobox in those platforms so 1 pixel higher will not make any difference.
> Also, added some stability fixes..Test passed for several iterations in all platforms in CI..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Review comments addressed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9321/files
  - new: https://git.openjdk.org/jdk/pull/9321/files/c7f06cd3..c159f874

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9321&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9321&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9321.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9321/head:pull/9321

PR: https://git.openjdk.org/jdk/pull/9321


From psadhukhan at openjdk.org  Thu Jun 30 08:57:16 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 30 Jun 2022 08:57:16 GMT
Subject: RFR: 8065097: [macosx] javax/swing/Popup/TaskbarPositionTest.java
 fails because Popup is one pixel off [v3]
In-Reply-To: <BimPX6gcNKvSz84fo1LBdTu3wBQtCmq1SKlP9JbN6GU=.4e65b93d-e1ec-4cd5-b1e1-24d82c2f750b@github.com>
References: <BimPX6gcNKvSz84fo1LBdTu3wBQtCmq1SKlP9JbN6GU=.4e65b93d-e1ec-4cd5-b1e1-24d82c2f750b@github.com>
Message-ID: <JeZzeACc8Zs25qukw8DQ3oQ_jRjLHT0NbyhOYBuFf8c=.c4d5709b-56eb-4704-9e65-da4c7df7de7d@github.com>

> Test seems to fail in macOS citing popup location is 1 pixel off compared to combobox position ie
> `p.y 154 cpos.y 155`
> 
> But in macOS, popup location, if 1st entry is selected, is 1 pixel higher than combobox so it's expected as can be seen below
> <img width="661" alt="Screenshot 2022-06-29 at 1 53 42 PM" src="https://user-images.githubusercontent.com/43534309/176389227-4e568117-ffce-4b4a-92d7-ab5c78c4ce08.png">
> 
> so test is updated to add 1 pixel to popup location. 
> It will not affect windows and linux as popup is placed below the combobox in those platforms so 1 pixel higher will not make any difference.
> Also, added some stability fixes..Test passed for several iterations in all platforms in CI..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Review comments addressed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9321/files
  - new: https://git.openjdk.org/jdk/pull/9321/files/c159f874..2ad78ef0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9321&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9321&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9321.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9321/head:pull/9321

PR: https://git.openjdk.org/jdk/pull/9321


From psadhukhan at openjdk.org  Thu Jun 30 11:20:39 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 30 Jun 2022 11:20:39 GMT
Subject: Integrated: 8288707: javax/swing/JToolBar/4529206/bug4529206.java:
 setFloating does not work correctly
In-Reply-To: <RPkNNkTmYAcBhA67ENFKO2omtGISEideYdn_oyo51Kc=.8fa3ec08-fcb2-4c72-a78b-4b52f5010e00@github.com>
References: <RPkNNkTmYAcBhA67ENFKO2omtGISEideYdn_oyo51Kc=.8fa3ec08-fcb2-4c72-a78b-4b52f5010e00@github.com>
Message-ID: <omsr-LSHmGjum_9CxoZy8iPbAListvt8QvvaPwdEIPY=.dd944cae-08e3-45b2-b528-49ff137d7747@github.com>

On Fri, 24 Jun 2022 03:42:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was failing intermittently around 1 or 2 out of 30 runs. 
> Fixed by adding stability code, wait for a sec after frame is visible, set frame to center.
> Modified test has run at least 50 times in all platforms and 100 times in linux (where it is seen intermittently) without any issue.

This pull request has now been integrated.

Changeset: feb223aa
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/feb223aacfd89d598a27b27c4b8be4601cc5eaff
Stats:     63 lines in 1 file changed: 34 ins; 9 del; 20 mod

8288707: javax/swing/JToolBar/4529206/bug4529206.java: setFloating does not work correctly

Reviewed-by: tr, serb

-------------

PR: https://git.openjdk.org/jdk/pull/9269


From naoto at openjdk.org  Thu Jun 30 16:13:26 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Jun 2022 16:13:26 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB
In-Reply-To: <zzI3u66CkzSb_fibwzwxh0DJRGyj9wdEI98r9DIGD3E=.be930635-4bca-4814-9b86-85df0adb17df@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <zPBsBu3-7oO4IXGsWLQ9yRptxskdeNWG5enL3pndDmg=.b23bd433-7a2b-4251-9c3d-ab4119aa40b0@github.com>
 <iiLFyt280_7JervKLHgpf-l5fdTYKqcoCnr9LoR0yBc=.3f5682f2-b5f8-48b7-9ec6-e64c1d738bcd@github.com>
 <IfsD9O9_j0LoWotkRCNUx9JqW3oHQTjXs_BLR1hZ578=.d5f48ab6-e334-4a30-88a2-58928afc9f75@github.com>
 <zzI3u66CkzSb_fibwzwxh0DJRGyj9wdEI98r9DIGD3E=.be930635-4bca-4814-9b86-85df0adb17df@github.com>
Message-ID: <s3q0cwpzQHtij8Z95X2tR5iVjfvZnUkEpBkYENAHmRs=.16954050-c133-4d7f-861f-6b335587edb8@github.com>

On Thu, 30 Jun 2022 08:21:14 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Dont think this len==0 check is needed...
>> One can use text = len + "bytes";
>> 
>> Also, this has i18n connection to it, so you need to use "byteString" similar to "kiloByteString", point it to 
>> UIManager.getString("FileChooser.fileSizeBytes", l); and add "FileChooser.fileSizeBytes" entry into 
>> share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties
>> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties
>> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties
>> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties
>> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties
>> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties
>> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties
>> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties
>> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties
>> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
>> share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties
>> 
>> I am not sure if need i18n team's intervention to update those resources as "bytes" can be translated to native in jp, zh
>> Maybe @naotoj can throw some light on that how to go about updating those resource file
>
>> > Also, will this code work correctly for non-English locales?
>> 
>> It won't.
>> 
>> It has to use `MessageFormat` and it has to add a new string to the resource bundle.
> 
> Yeah, I will check on this

The code should employ `MessageFormat`. You only need to modify the English resource bundles, i.e., `basic.properties`, the rest will be taken care of by the g11n process.

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jun 30 16:23:43 2022
From: duke at openjdk.org (Andy Goryachev)
Date: Thu, 30 Jun 2022 16:23:43 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB
In-Reply-To: <s3q0cwpzQHtij8Z95X2tR5iVjfvZnUkEpBkYENAHmRs=.16954050-c133-4d7f-861f-6b335587edb8@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <zPBsBu3-7oO4IXGsWLQ9yRptxskdeNWG5enL3pndDmg=.b23bd433-7a2b-4251-9c3d-ab4119aa40b0@github.com>
 <iiLFyt280_7JervKLHgpf-l5fdTYKqcoCnr9LoR0yBc=.3f5682f2-b5f8-48b7-9ec6-e64c1d738bcd@github.com>
 <IfsD9O9_j0LoWotkRCNUx9JqW3oHQTjXs_BLR1hZ578=.d5f48ab6-e334-4a30-88a2-58928afc9f75@github.com>
 <zzI3u66CkzSb_fibwzwxh0DJRGyj9wdEI98r9DIGD3E=.be930635-4bca-4814-9b86-85df0adb17df@github.com>
 <s3q0cwpzQHtij8Z95X2tR5iVjfvZnUkEpBkYENAHmRs=.16954050-c133-4d7f-861f-6b335587edb8@github.com>
Message-ID: <IvGLUD7NNq-K2hj0pJ2-z7v0rscujR6-wvO3lGk0gEY=.0560d958-453f-404d-ab4e-3684baf3be8e@github.com>

On Thu, 30 Jun 2022 16:09:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>>> > Also, will this code work correctly for non-English locales?
>>> 
>>> It won't.
>>> 
>>> It has to use `MessageFormat` and it has to add a new string to the resource bundle.
>> 
>> Yeah, I will check on this
>
> The code should employ `MessageFormat`. You only need to modify the English resource bundles, i.e., `basic.properties`, the rest will be taken care of by the g11n process.

In this case, I would suggest to use straight number.

If you notice, the lengths are listed as {0} KB, {0} MB, {0} GB (there are no terabytes, I see), and "1023 bytes" would make the string too long and might case ellipses to appear.

Also, the threshold might be set at <= 999 instead of 1024.  The reason is group separator - the user might prefer to see 1,023 instead of 1023.

Ideally, there should be a pluggable policy (formatter) to format the lengths to the user's liking.

To summarize,
0...999 -> "0" ... "999"
1000 ... 1023 -> "1 KB"

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From naoto at openjdk.org  Thu Jun 30 16:27:41 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Jun 2022 16:27:41 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB
In-Reply-To: <IvGLUD7NNq-K2hj0pJ2-z7v0rscujR6-wvO3lGk0gEY=.0560d958-453f-404d-ab4e-3684baf3be8e@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <zPBsBu3-7oO4IXGsWLQ9yRptxskdeNWG5enL3pndDmg=.b23bd433-7a2b-4251-9c3d-ab4119aa40b0@github.com>
 <iiLFyt280_7JervKLHgpf-l5fdTYKqcoCnr9LoR0yBc=.3f5682f2-b5f8-48b7-9ec6-e64c1d738bcd@github.com>
 <IfsD9O9_j0LoWotkRCNUx9JqW3oHQTjXs_BLR1hZ578=.d5f48ab6-e334-4a30-88a2-58928afc9f75@github.com>
 <zzI3u66CkzSb_fibwzwxh0DJRGyj9wdEI98r9DIGD3E=.be930635-4bca-4814-9b86-85df0adb17df@github.com>
 <s3q0cwpzQHtij8Z95X2tR5iVjfvZnUkEpBkYENAHmRs=.16954050-c133-4d7f-861f-6b335587edb8@github.com>
 <IvGLUD7NNq-K2hj0pJ2-z7v0rscujR6-wvO3lGk0gEY=.0560d958-453f-404d-ab4e-3684baf3be8e@github.com>
Message-ID: <3e6pWLgFzZw2zohuYHiWtBqvD3Bem_4jgyK2XEbVGMo=.08cc3e2b-eb94-41e5-b48d-bcab15a9966e@github.com>

On Thu, 30 Jun 2022 16:19:44 GMT, Andy Goryachev <duke at openjdk.org> wrote:

>> The code should employ `MessageFormat`. You only need to modify the English resource bundles, i.e., `basic.properties`, the rest will be taken care of by the g11n process.
>
> In this case, I would suggest to use straight number.
> 
> If you notice, the lengths are listed as {0} KB, {0} MB, {0} GB (there are no terabytes, I see), and "1023 bytes" would make the string too long and might case ellipses to appear.
> 
> Also, the threshold might be set at <= 999 instead of 1024.  The reason is group separator - the user might prefer to see 1,023 instead of 1023.
> 
> Ideally, there should be a pluggable policy (formatter) to format the lengths to the user's liking.
> 
> To summarize,
> 0...999 -> "0" ... "999"
> 1000 ... 1023 -> "1 KB"

Another option is to use `java.text.CompactNumberFormat` which can handle those K/M/B suffixes nicely.

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From honkar at openjdk.org  Thu Jun 30 16:33:39 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 30 Jun 2022 16:33:39 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <hI-a13CAwmIbDoWdUEdl3HaSGxKzYnoNSi_FqdEUIOs=.c5e9e416-f892-4b04-b9ec-cf4a48cf440e@github.com>

On Wed, 29 Jun 2022 13:06:21 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 bytes.
> Manual Test Case "ZeroFileSizeCheck.java" created.

Changes requested by honkar (Author).

test/jdk/javax/swing/JFileChooser/ZeroFileSizeCheck.java line 74:

> 72:             PassFailJFrame.positionTestFrame(frame,
> 73:                     PassFailJFrame.Position.HORIZONTAL);
> 74:         });

@kumarabhi006 You might have to update `addTestFrame & positonTestFrame` to `addTestWindow & positionTestWindow` due to recent PassFailJFrame changes. Probably pull in the latest code.

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Jun 30 16:33:41 2022
From: duke at openjdk.org (Andy Goryachev)
Date: Thu, 30 Jun 2022 16:33:41 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB
In-Reply-To: <3e6pWLgFzZw2zohuYHiWtBqvD3Bem_4jgyK2XEbVGMo=.08cc3e2b-eb94-41e5-b48d-bcab15a9966e@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <zPBsBu3-7oO4IXGsWLQ9yRptxskdeNWG5enL3pndDmg=.b23bd433-7a2b-4251-9c3d-ab4119aa40b0@github.com>
 <iiLFyt280_7JervKLHgpf-l5fdTYKqcoCnr9LoR0yBc=.3f5682f2-b5f8-48b7-9ec6-e64c1d738bcd@github.com>
 <IfsD9O9_j0LoWotkRCNUx9JqW3oHQTjXs_BLR1hZ578=.d5f48ab6-e334-4a30-88a2-58928afc9f75@github.com>
 <zzI3u66CkzSb_fibwzwxh0DJRGyj9wdEI98r9DIGD3E=.be930635-4bca-4814-9b86-85df0adb17df@github.com>
 <s3q0cwpzQHtij8Z95X2tR5iVjfvZnUkEpBkYENAHmRs=.16954050-c133-4d7f-861f-6b335587edb8@github.com>
 <IvGLUD7NNq-K2hj0pJ2-z7v0rscujR6-wvO3lGk0gEY=.0560d958-453f-404d-ab4e-3684baf3be8e@github.com>
 <3e6pWLgFzZw2zohuYHiWtBqvD3Bem_4jgyK2XEbVGMo=.08cc3e2b-eb94-41e5-b48d-bcab15a9966e@github.com>
Message-ID: <sYkEv1sAB3k5SOlW_EoB2CxJaEMTqthZjpfWG_AzunQ=.39e86011-4506-41cd-b692-ab5ed0eab21f@github.com>

On Thu, 30 Jun 2022 16:24:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> In this case, I would suggest to use straight number.
>> 
>> If you notice, the lengths are listed as {0} KB, {0} MB, {0} GB (there are no terabytes, I see), and "1023 bytes" would make the string too long and might case ellipses to appear.
>> 
>> Also, the threshold might be set at <= 999 instead of 1024.  The reason is group separator - the user might prefer to see 1,023 instead of 1023.
>> 
>> Ideally, there should be a pluggable policy (formatter) to format the lengths to the user's liking.
>> 
>> To summarize,
>> 0...999 -> "0" ... "999"
>> 1000 ... 1023 -> "1 KB"
>
> Another option is to use `java.text.CompactNumberFormat` which can handle those K/M/B suffixes nicely.

Would java.text.CompactNumberFormat work for java 8?

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From naoto at openjdk.org  Thu Jun 30 16:40:39 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Jun 2022 16:40:39 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB
In-Reply-To: <sYkEv1sAB3k5SOlW_EoB2CxJaEMTqthZjpfWG_AzunQ=.39e86011-4506-41cd-b692-ab5ed0eab21f@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <zPBsBu3-7oO4IXGsWLQ9yRptxskdeNWG5enL3pndDmg=.b23bd433-7a2b-4251-9c3d-ab4119aa40b0@github.com>
 <iiLFyt280_7JervKLHgpf-l5fdTYKqcoCnr9LoR0yBc=.3f5682f2-b5f8-48b7-9ec6-e64c1d738bcd@github.com>
 <IfsD9O9_j0LoWotkRCNUx9JqW3oHQTjXs_BLR1hZ578=.d5f48ab6-e334-4a30-88a2-58928afc9f75@github.com>
 <zzI3u66CkzSb_fibwzwxh0DJRGyj9wdEI98r9DIGD3E=.be930635-4bca-4814-9b86-85df0adb17df@github.com>
 <s3q0cwpzQHtij8Z95X2tR5iVjfvZnUkEpBkYENAHmRs=.16954050-c133-4d7f-861f-6b335587edb8@github.com>
 <IvGLUD7NNq-K2hj0pJ2-z7v0rscujR6-wvO3lGk0gEY=.0560d958-453f-404d-ab4e-3684baf3be8e@github.com>
 <3e6pWLgFzZw2zohuYHiWtBqvD3Bem_4jgyK2XEbVGMo=.08cc3e2b-eb94-41e5-b48d-bcab15a9966e@github.com>
 <sYkEv1sAB3k5SOlW_EoB2CxJaEMTqthZjpfWG_AzunQ=.39e86011-4506-41cd-b692-ab5ed0eab21f@github.com>
Message-ID: <d34UG8qsp57TeJ01CjyIhHWNIIrc5LzhoUmqM0YA8yM=.5d005b8c-84d8-458c-8c77-1fd00c81da90@github.com>

On Thu, 30 Jun 2022 16:30:04 GMT, Andy Goryachev <duke at openjdk.org> wrote:

>> Another option is to use `java.text.CompactNumberFormat` which can handle those K/M/B suffixes nicely.
>
> Would java.text.CompactNumberFormat work for java 8?

It is introduced in JDK12. If this has to be backported to 8, that's not an option.

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From aivanov at openjdk.org  Thu Jun 30 16:44:41 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 30 Jun 2022 16:44:41 GMT
Subject: RFR: 8065097: [macosx] javax/swing/Popup/TaskbarPositionTest.java
 fails because Popup is one pixel off [v3]
In-Reply-To: <JeZzeACc8Zs25qukw8DQ3oQ_jRjLHT0NbyhOYBuFf8c=.c4d5709b-56eb-4704-9e65-da4c7df7de7d@github.com>
References: <BimPX6gcNKvSz84fo1LBdTu3wBQtCmq1SKlP9JbN6GU=.4e65b93d-e1ec-4cd5-b1e1-24d82c2f750b@github.com>
 <JeZzeACc8Zs25qukw8DQ3oQ_jRjLHT0NbyhOYBuFf8c=.c4d5709b-56eb-4704-9e65-da4c7df7de7d@github.com>
Message-ID: <1QGaXbmUpOrVOVFdq-OHc4X4i91n37TaGZQv4pVdas4=.cddc153f-19b0-4d8b-a176-a83cd268433f@github.com>

On Thu, 30 Jun 2022 08:57:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test seems to fail in macOS citing popup location is 1 pixel off compared to combobox position ie
>> `p.y 154 cpos.y 155`
>> 
>> But in macOS, popup location, if 1st entry is selected, is 1 pixel higher than combobox so it's expected as can be seen below
>> <img width="661" alt="Screenshot 2022-06-29 at 1 53 42 PM" src="https://user-images.githubusercontent.com/43534309/176389227-4e568117-ffce-4b4a-92d7-ab5c78c4ce08.png">
>> 
>> so test is updated to add 1 pixel to popup location. 
>> It will not affect windows and linux as popup is placed below the combobox in those platforms so 1 pixel higher will not make any difference.
>> Also, added some stability fixes..Test passed for several iterations in all platforms in CI..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments addressed

It looks good.

However, the test does not behave as it should on macOS.
Additionally, the position of combo box popups aren't verified (except for the last one).

Anyway, these other issues are out of scope of this one.

test/jdk/javax/swing/Popup/TaskbarPositionTest.java line 107:

> 105: 
> 106:         // Place the frame near the bottom.
> 107:         frame.setLocation(0, screenBounds.y + screenBounds.height - frame.getHeight());

This should be moved below, after the insets of the graphics device are taken into account.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9321


From honkar at openjdk.org  Thu Jun 30 16:58:44 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 30 Jun 2022 16:58:44 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <GeAwin-VSzBZaFyvS7hOBMjEJvnXmjYu7Kqiz1mxwGU=.2ebefa3f-cce7-48a0-aced-a72bcb9a5f47@github.com>

On Wed, 29 Jun 2022 13:06:21 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 bytes.
> Manual Test Case "ZeroFileSizeCheck.java" created.

test/jdk/javax/swing/JFileChooser/ZeroFileSizeCheck.java line 2:

> 1: /*
> 2:  * Copyright (c) 1999, 2022, Oracle and/or its affiliates. All rights reserved.

The copyright year is usually just the current year for new files. 
Was the test case created from a reproducer code?

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From azvegint at openjdk.org  Thu Jun 30 17:10:44 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 30 Jun 2022 17:10:44 GMT
Subject: RFR: 8288444: Remove the workaround for frame.pack() in
 ModalDialogTest [v3]
In-Reply-To: <H-Yo0nznghw6-cPf7yuGxX0Lskp_zc36Ae7CPuxCTHs=.465f1b02-fb98-457d-8055-1af31dc0f314@github.com>
References: <88CU8XufxULaqu9xL-G581LBMSlsAR9TU_fuKspZs20=.e576f3b0-e3ff-4037-9cb9-a92bf204cb02@github.com>
 <H-Yo0nznghw6-cPf7yuGxX0Lskp_zc36Ae7CPuxCTHs=.465f1b02-fb98-457d-8055-1af31dc0f314@github.com>
Message-ID: <xnMNm8hnBVhxCzHgZhcCE6IFEwXQqGdXrAgUMtJIiOc=.72db0a18-9a45-4bfa-b964-28bcf1355f30@github.com>

On Thu, 30 Jun 2022 00:09:27 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Previously frame.pack() was called twice as a workaround  AWT frame sizing issue in this particular test case on Windows. This issue was fixed **[JDK-8265586](https://bugs.openjdk.org/browse/JDK-8265586)** and hence the workaround is being removed from this test.
>> 
>> PassFailJFrame is being used as the test framework. 
>> 
>> **Proposed change related to PassFailJFrame Test framework**
>> 
>> Instead of creating separate methods to handle AWT Windows as well as Frames, method signatures - [**PassFailJFrame.positionTestFrame()**](https://github.com/openjdk/jdk/blob/53b37fe1535388eb14e04c620a6b0118ed8884a0/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L271) and [**PassFailJFrame.addTestFrame()**](https://github.com/openjdk/jdk/blob/53b37fe1535388eb14e04c620a6b0118ed8884a0/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L294) can be changed to take in Window as input parameter instead of Frame, since Window is a superclass, this would allow the test frame to be a Window/Frame/Dialog and not be restricted to a Frame, additionally would allow proper disposal of windows added to the PassFailJFrame.
>> 
>> **Above PassFailJFrame changes tracked by: [JDK-8289238](https://bugs.openjdk.org/browse/JDK-8289238)**
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PassFailJFrame changes

Looks good.

-------------

Marked as reviewed by azvegint (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9286


From azvegint at openjdk.org  Thu Jun 30 17:14:50 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 30 Jun 2022 17:14:50 GMT
Subject: [jdk19] RFR: 8288854: getLocalGraphicsEnvironment() on for
 multi-screen setups throws exception NPE
In-Reply-To: <JDwnP68sBqXntWg68M-GNwnkudtVZcTuirZ5HOHUGgU=.3dbd4488-b39a-492c-9dd2-e8bfb929cb99@github.com>
References: <rBvFremdQsswOG5ynfNKjOFVDStHLAmeSgVIq8y6MrI=.dfa5031f-3b70-467e-8819-a3c8fc07e81b@github.com>
 <lWTcHrRDGZPPE6GyEAoh3-bn4Vint5Qtrjg0_O_Wvws=.76800aaa-c505-42f0-ad97-e5a1a7c28a32@github.com>
 <yNkJaf0rUP3Okm0PCwVK-zEWHNxx66yvgBIi4qxF_8o=.3bb91232-a07a-4207-a490-21447ae7eb54@github.com>
 <UQQzFnNCRrVMxTnIBMYFxWQVxH8CMAqiCdsvg0VzF6g=.b661fd27-931d-4c80-80ad-e8bef4fc6169@github.com>
 <JDwnP68sBqXntWg68M-GNwnkudtVZcTuirZ5HOHUGgU=.3dbd4488-b39a-492c-9dd2-e8bfb929cb99@github.com>
Message-ID: <IVB7llVlTkrWADIBn5iPnZRuFKu67kxKWeGYOQ-lZDM=.bc962271-b53c-4bcb-8ea6-d02f5dc5fbbc@github.com>

On Tue, 28 Jun 2022 20:32:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Since the small fix for a recent regression is ready I do not see a reason to skip it?

OK, thanks for clarification.

-------------

PR: https://git.openjdk.org/jdk19/pull/81


From aivanov at openjdk.org  Thu Jun 30 17:42:41 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 30 Jun 2022 17:42:41 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB
In-Reply-To: <SRNYZVpzfz7pEJ-MddvPYrWkiqnD1QyH05LxMeSt7Fw=.eae19d9c-fe80-4a26-afe5-01ccde0c9945@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <zPBsBu3-7oO4IXGsWLQ9yRptxskdeNWG5enL3pndDmg=.b23bd433-7a2b-4251-9c3d-ab4119aa40b0@github.com>
 <iiLFyt280_7JervKLHgpf-l5fdTYKqcoCnr9LoR0yBc=.3f5682f2-b5f8-48b7-9ec6-e64c1d738bcd@github.com>
 <IfsD9O9_j0LoWotkRCNUx9JqW3oHQTjXs_BLR1hZ578=.d5f48ab6-e334-4a30-88a2-58928afc9f75@github.com>
 <zzI3u66CkzSb_fibwzwxh0DJRGyj9wdEI98r9DIGD3E=.be930635-4bca-4814-9b86-85df0adb17df@github.com>
 <s3q0cwpzQHtij8Z95X2tR5iVjfvZnUkEpBkYENAHmRs=.16954050-c133-4d7f-861f-6b335587edb8@github.com>
 <IvGLUD7NNq-K2hj0pJ2-z7v0rscujR6-wvO3lGk0gEY=.0560d958-453f-404d-ab4e-3684baf3be8e@github.com>
 <3e6pWLgFzZw2zohuYHiWtBqvD3Bem_4jgyK2XEbVGMo=.08cc3e2b-eb94-41e5-b48d-bcab15a9966e@github.com>
 <sYkEv1sAB3k5SOlW_EoB2CxJaEMTqthZjpfWG_AzunQ=.39e86011-4506-41cd-b692-ab5ed0eab21f@github.com>
 <d34UG8qsp57TeJ01CjyIhHWNIIrc5LzhoUmqM0YA8yM=.5d005b8c-84d8-458c-8c77-1fd00c81da90@github.com>
 <SRNYZVpzfz7pEJ-MddvPYrWkiqnD1QyH05L
 xMeSt7Fw=.eae19d9c-fe80-4a26-afe5-01ccde0c9945@github.com>
Message-ID: <Cavx_IJY1dlge-9RYKF6cHu2IqOmIlWZRDCVmMASc4A=.c67143b3-16b2-4492-ab3e-565cb1554978@github.com>

On Thu, 30 Jun 2022 17:37:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It is introduced in JDK12. If this has to be backported to 8, that's not an option.
>
> I think we should follow the current format for the time being and show the file size similar to how its shown in native tools.
> 
> In Windows Explorer, 0 bytes are shown as 0 KB, 1 byte is 1 KB and so on? However, JFileChooser shows these as 0 bytes and 1 bytes in both Java/Metal and Windows L&Fs.
> 
> On macOS, Finder shows the size as "Zero bytes" and "1 byte" correspondingly. JFileChooser in Aqua L&F doesn't show the size.

> It is introduced in JDK12. If this has to be backported to 8, that's not an option.

Is this fix going to be backported to 11 and 8?

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From aivanov at openjdk.org  Thu Jun 30 17:42:40 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 30 Jun 2022 17:42:40 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB
In-Reply-To: <d34UG8qsp57TeJ01CjyIhHWNIIrc5LzhoUmqM0YA8yM=.5d005b8c-84d8-458c-8c77-1fd00c81da90@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <zPBsBu3-7oO4IXGsWLQ9yRptxskdeNWG5enL3pndDmg=.b23bd433-7a2b-4251-9c3d-ab4119aa40b0@github.com>
 <iiLFyt280_7JervKLHgpf-l5fdTYKqcoCnr9LoR0yBc=.3f5682f2-b5f8-48b7-9ec6-e64c1d738bcd@github.com>
 <IfsD9O9_j0LoWotkRCNUx9JqW3oHQTjXs_BLR1hZ578=.d5f48ab6-e334-4a30-88a2-58928afc9f75@github.com>
 <zzI3u66CkzSb_fibwzwxh0DJRGyj9wdEI98r9DIGD3E=.be930635-4bca-4814-9b86-85df0adb17df@github.com>
 <s3q0cwpzQHtij8Z95X2tR5iVjfvZnUkEpBkYENAHmRs=.16954050-c133-4d7f-861f-6b335587edb8@github.com>
 <IvGLUD7NNq-K2hj0pJ2-z7v0rscujR6-wvO3lGk0gEY=.0560d958-453f-404d-ab4e-3684baf3be8e@github.com>
 <3e6pWLgFzZw2zohuYHiWtBqvD3Bem_4jgyK2XEbVGMo=.08cc3e2b-eb94-41e5-b48d-bcab15a9966e@github.com>
 <sYkEv1sAB3k5SOlW_EoB2CxJaEMTqthZjpfWG_AzunQ=.39e86011-4506-41cd-b692-ab5ed0eab21f@github.com>
 <d34UG8qsp57TeJ01CjyIhHWNIIrc5LzhoUmqM0YA8yM=.5d005b8c-84d8-458c-8c77-1fd00c81da90@github.com>
Message-ID: <SRNYZVpzfz7pEJ-MddvPYrWkiqnD1QyH05LxMeSt7Fw=.eae19d9c-fe80-4a26-afe5-01ccde0c9945@github.com>

On Thu, 30 Jun 2022 16:36:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Would java.text.CompactNumberFormat work for java 8?
>
> It is introduced in JDK12. If this has to be backported to 8, that's not an option.

I think we should follow the current format for the time being and show the file size similar to how its shown in native tools.

In Windows Explorer, 0 bytes are shown as 0 KB, 1 byte is 1 KB and so on? However, JFileChooser shows these as 0 bytes and 1 bytes in both Java/Metal and Windows L&Fs.

On macOS, Finder shows the size as "Zero bytes" and "1 byte" correspondingly. JFileChooser in Aqua L&F doesn't show the size.

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From aivanov at openjdk.org  Thu Jun 30 20:05:45 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 30 Jun 2022 20:05:45 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB
In-Reply-To: <hI-a13CAwmIbDoWdUEdl3HaSGxKzYnoNSi_FqdEUIOs=.c5e9e416-f892-4b04-b9ec-cf4a48cf440e@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <hI-a13CAwmIbDoWdUEdl3HaSGxKzYnoNSi_FqdEUIOs=.c5e9e416-f892-4b04-b9ec-cf4a48cf440e@github.com>
Message-ID: <zoME5oGfdtBVgdxizAwoMdF6i3O4t9MaFCbH9ffkDaU=.4ccd0f69-0efd-4bea-8867-18516e306d40@github.com>

On Thu, 30 Jun 2022 16:31:21 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> test/jdk/javax/swing/JFileChooser/ZeroFileSizeCheck.java line 74:
> 
>> 72:             PassFailJFrame.positionTestFrame(frame,
>> 73:                     PassFailJFrame.Position.HORIZONTAL);
>> 74:         });
> 
> @kumarabhi006 You might have to update `addTestFrame & positonTestFrame` to `addTestWindow & positionTestWindow` due to recent PassFailJFrame changes. Probably pull in the latest code.
> PassFailJFrame changes: https://github.com/openjdk/jdk/pull/9300

> @kumarabhi006 You might have to update `addTestFrame & positonTestFrame` to `addTestWindow & positionTestWindow` due to recent PassFailJFrame changes. Probably pull in the latest code. PassFailJFrame changes: #9300

You *have* to update. Otherwise, the test will fail after integration.

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From aivanov at openjdk.org  Thu Jun 30 20:30:40 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 30 Jun 2022 20:30:40 GMT
Subject: RFR: 8065097: [macosx] javax/swing/Popup/TaskbarPositionTest.java
 fails because Popup is one pixel off [v3]
In-Reply-To: <1QGaXbmUpOrVOVFdq-OHc4X4i91n37TaGZQv4pVdas4=.cddc153f-19b0-4d8b-a176-a83cd268433f@github.com>
References: <BimPX6gcNKvSz84fo1LBdTu3wBQtCmq1SKlP9JbN6GU=.4e65b93d-e1ec-4cd5-b1e1-24d82c2f750b@github.com>
 <JeZzeACc8Zs25qukw8DQ3oQ_jRjLHT0NbyhOYBuFf8c=.c4d5709b-56eb-4704-9e65-da4c7df7de7d@github.com>
 <1QGaXbmUpOrVOVFdq-OHc4X4i91n37TaGZQv4pVdas4=.cddc153f-19b0-4d8b-a176-a83cd268433f@github.com>
Message-ID: <RGtmzv1dNkPvCdtO897o44wPQVz4bgzJuWv2iIrHWes=.07bcf946-2dec-41d3-b257-c229f72909c5@github.com>

On Thu, 30 Jun 2022 16:41:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> However, the test does not behave as it should on macOS. Additionally, the position of combo box popups aren't verified (except for the last one).
> 
> Anyway, these other issues are out of scope of this one.

I submitted [JDK-8289547](https://bugs.openjdk.org/browse/JDK-8289547): _Update javax/swing/Popup/TaskbarPositionTest.java_ to address additional issues that I had found.

-------------

PR: https://git.openjdk.org/jdk/pull/9321


From serb at openjdk.org  Thu Jun 30 22:44:42 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 30 Jun 2022 22:44:42 GMT
Subject: RFR: 8267374: (macos) Left Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v5]
In-Reply-To: <R7yJ5AYM5oIDESlxV5cYb8RUbaFe1kedi595pJxrNlY=.27ba2ed4-a275-4e28-82de-2a0f3ec81187@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <eaIqfbBPgL1ztaV0YUgcV2zF38-eR4XfmNpfAj5NWic=.2ece233e-c6f0-43f2-aa2b-2d9d4441432c@github.com>
 <2lojbp2WLFbEEIhZVeVIbHU_6g_n3zQHpyKAAU9Jl7E=.1ed34cc5-5c1e-4c45-8657-df36af1ecffe@github.com>
 <mMPsdv3R1O2pEZmuJGwJfEqds_NlYILW4x3a67G-m2k=.ce4b92a5-d146-4ce7-8d66-fe5a8c2b054a@github.com>
 <zNYj7hNRvjjkcuwZMWdB5jfYQuORSqZjvr3tqD4bs7s=.daab1253-0c99-4921-98e3-3fd8b226b693@github.com>
 <fvBYqKpKDVr14_lc2eBGaiCo38eP0xzS4SLdpoyecB0=.f6b5ef16-55c9-4aea-8ac8-12661ed5ee38@github.com>
 <tX29M6BktlMY1wairp7u5zIbdZyjZjJk1OyR24OUEfI=.d2f957db-bf91-4ea5-a12e-b03430e25ba3@github.com>
 <4upBK4eG3UJ8LItxLizG4bZaFc8UFwM3ZGkx4wNCJaw=.cc8e3214-e98c-49ce-8a96-0244347f5c13@github.com>
 <R7yJ5AYM5oIDESlxV5cYb8RUbaFe1kedi595pJxrNlY=.27ba2ed4-a275-4e28-82de-2a0f3ec81187@github.com>
Message-ID: <UNFfD5IGa142NcAH-hOXy8U0Cn_O4WVzVpTHLs2LW64=.774e58b4-1a69-4f61-8ee3-91d32bc43f28@github.com>

On Tue, 28 Jun 2022 13:13:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> That is similar issue on Windows since we unconditionally set the right alt key to be ALT_GRAPH independently of the current keyboard layout, it is just a button location which is the same on win and mac. So probably right now it is better to update the spec of that flag. 
>> 
>> To workaround that change the fix for [JDK-8194873](https://bugs.openjdk.org/browse/JDK-8194873) updated all our L&F which are used on windows, obviously the Aqua was missed. I think we should update the Aqua in a similar way.
>
> I can see "AltGr" key in windows keyboard but not mac so am not sure why should we support just because of key location.
> Anyway, I will let @prrace decide  on that.
> 
> If we need to support altgr, then present PR supports both 8151136  (alt graph) and also Right/Left Option Up/Down

One macOS you will not see the "Alt" key as well, but we use that name.

-------------

PR: https://git.openjdk.org/jdk/pull/9230


From serb at openjdk.org  Thu Jun 30 22:47:44 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 30 Jun 2022 22:47:44 GMT
Subject: RFR: 8065097: [macosx] javax/swing/Popup/TaskbarPositionTest.java
 fails because Popup is one pixel off [v3]
In-Reply-To: <JeZzeACc8Zs25qukw8DQ3oQ_jRjLHT0NbyhOYBuFf8c=.c4d5709b-56eb-4704-9e65-da4c7df7de7d@github.com>
References: <BimPX6gcNKvSz84fo1LBdTu3wBQtCmq1SKlP9JbN6GU=.4e65b93d-e1ec-4cd5-b1e1-24d82c2f750b@github.com>
 <JeZzeACc8Zs25qukw8DQ3oQ_jRjLHT0NbyhOYBuFf8c=.c4d5709b-56eb-4704-9e65-da4c7df7de7d@github.com>
Message-ID: <p72ED9f-5woRktepgdh5FIu01kztAkPUx1nBt4o3HLY=.a1c79062-3df6-4ecd-98d1-4cefc609ef31@github.com>

On Thu, 30 Jun 2022 08:57:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test seems to fail in macOS citing popup location is 1 pixel off compared to combobox position ie
>> `p.y 154 cpos.y 155`
>> 
>> But in macOS, popup location, if 1st entry is selected, is 1 pixel higher than combobox so it's expected as can be seen below
>> <img width="661" alt="Screenshot 2022-06-29 at 1 53 42 PM" src="https://user-images.githubusercontent.com/43534309/176389227-4e568117-ffce-4b4a-92d7-ab5c78c4ce08.png">
>> 
>> so test is updated to add 1 pixel to popup location. 
>> It will not affect windows and linux as popup is placed below the combobox in those platforms so 1 pixel higher will not make any difference.
>> Also, added some stability fixes..Test passed for several iterations in all platforms in CI..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments addressed

In what place of JDK do we place the popup and shift it by 1 pixel?

-------------

PR: https://git.openjdk.org/jdk/pull/9321