From psadhukhan at openjdk.java.net  Mon Mar  1 04:11:39 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 1 Mar 2021 04:11:39 GMT
Subject: <Swing Dev> RFR: 8262085: Hovering Metal HTML Tooltips in
 different windows cause IllegalArgExc on Linux [v2]
In-Reply-To: <7KUD9AtdNmMg876dcEPh2JLSyN54GozkIAozZTW6ZeE=.21dd9dc9-f4cc-4a3e-a8fd-f94eb6762bf6@github.com>
References: <wsA2dM8EiS6JnMPQAZFS605wOCObbLZYzWkbjjVwylE=.8ac2d62f-d865-41a9-ac17-0bef98694486@github.com>
 <7KUD9AtdNmMg876dcEPh2JLSyN54GozkIAozZTW6ZeE=.21dd9dc9-f4cc-4a3e-a8fd-f94eb6762bf6@github.com>
Message-ID: <e2KHxI6AFLk7CwrexfmQbqp4Q8X_HrxDDg-3lJ1v7HY=.b140b62c-5054-46b8-af3a-0fb4375fdb72@github.com>

On Sun, 28 Feb 2021 07:39:20 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This issue occurs only under `MetalLookAndFeel` on Linux. 
>> 
>> It was introduced by [JDK-8040630](https://bugs.openjdk.java.net/browse/JDK-8040630) fix.
>> 
>>> component.setBounds(ownerX, ownerY, 1, 1);
>> 
>> This line adds an extra reshape call with `1x1` size right before getting another one with correct sizes.
>> 
>> If `MetalToolTipUI#paint()` call happens before getting correct sizes,  it calculates `paintTextR` with negative sizes for component with `1x1` size,  thus IAE is thrown.
>> 
>> The fix is to do not proceed with `paint()` for negative sizes.
>> The provided test fails for me in 0-30s interval(before the fix), other testing(client-tier1,2,3) looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplified test

test/jdk/javax/swing/JToolTip/FastTooltipSwitchIAE.java line 61:

> 59:         } catch (ClassNotFoundException | InstantiationException |
> 60:                 UnsupportedLookAndFeelException | IllegalAccessException e) {
> 61:             throw new RuntimeException(e);

Normally for UnsupportedLookAndFeelException, we dont throw Exception, rather print and continue to next L&F.

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

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

From psadhukhan at openjdk.java.net  Mon Mar  1 04:52:39 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 1 Mar 2021 04:52:39 GMT
Subject: <Swing Dev> RFR: 8262085: Hovering Metal HTML Tooltips in
 different windows cause IllegalArgExc on Linux [v2]
In-Reply-To: <7KUD9AtdNmMg876dcEPh2JLSyN54GozkIAozZTW6ZeE=.21dd9dc9-f4cc-4a3e-a8fd-f94eb6762bf6@github.com>
References: <wsA2dM8EiS6JnMPQAZFS605wOCObbLZYzWkbjjVwylE=.8ac2d62f-d865-41a9-ac17-0bef98694486@github.com>
 <7KUD9AtdNmMg876dcEPh2JLSyN54GozkIAozZTW6ZeE=.21dd9dc9-f4cc-4a3e-a8fd-f94eb6762bf6@github.com>
Message-ID: <wyntC7Yk7_FERZ60SFWql9LFCTYse8N4yLW_k7Fl070=.722ec3ea-7c0f-4828-8fc5-efabe76668b7@github.com>

On Sun, 28 Feb 2021 07:39:20 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This issue occurs only under `MetalLookAndFeel` on Linux. 
>> 
>> It was introduced by [JDK-8040630](https://bugs.openjdk.java.net/browse/JDK-8040630) fix.
>> 
>>> component.setBounds(ownerX, ownerY, 1, 1);
>> 
>> This line adds an extra reshape call with `1x1` size right before getting another one with correct sizes.
>> 
>> If `MetalToolTipUI#paint()` call happens before getting correct sizes,  it calculates `paintTextR` with negative sizes for component with `1x1` size,  thus IAE is thrown.
>> 
>> The fix is to do not proceed with `paint()` for negative sizes.
>> The provided test fails for me in 0-30s interval(before the fix), other testing(client-tier1,2,3) looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplified test

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java line 124:

> 122:         if (paintTextR.width <= 0 || paintTextR.height <= 0) {
> 123:             return;
> 124:         }

Any idea why only MetalToolTip is affected only? JDK-8040630 fix was generic so shouldn't we apply this fix in BasicToolTipUI#paint instead?

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

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

From trebari at openjdk.java.net  Mon Mar  1 10:58:39 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Mon, 1 Mar 2021 10:58:39 GMT
Subject: <Swing Dev> RFR: 8049700: Deprecate obsolete classes and
 methods in javax/swing/plaf/basic [v6]
In-Reply-To: <Kw7JLwhazwV5j1vwr4KVrOOLaLwjk03ApIaXPiOF9XM=.457c6b46-8cfc-4035-9ac8-4c7553079e99@github.com>
References: <LcIvlc2HZGDo6ErOfqf_QZlwCpO2a7o2pPIDeaCb40E=.80fa98b5-728e-4198-a4fd-8d70e21302fc@github.com>
 <Omn4vN7y_rSL1kyekfnJfwZpaUl7AKun4Sq9XqE7AVk=.077cd2e8-3be4-4769-b781-2f9da780fed0@github.com>
 <oXYDIU1R0lheFPOmsKpg5FJko0rIggaVfcMktIChkj8=.c3ca1f34-c5a6-4e4c-b097-0406908b0ec9@github.com>
 <Kw7JLwhazwV5j1vwr4KVrOOLaLwjk03ApIaXPiOF9XM=.457c6b46-8cfc-4035-9ac8-4c7553079e99@github.com>
Message-ID: <p9ts3oc4WtG7FEM-FfypX-zv3DHJaKhLYjJYCEQ3aOw=.4c3330a3-430b-45bc-b958-8383c176a049@github.com>

On Fri, 19 Feb 2021 15:45:55 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

> Are these methods all expected to be used only by a L&F rather than an application ?
> If by an application, then forRemoval seems too strong to me.
> If by a L&F then I think you need to go research what open source L&Fs there are out there and see how many of them are affected. Then we can decide about forRemoval.

There are open source LAFs which will be affected by removing these.
Like FlatLaf https://www.formdev.com/flatlaf/ uses BasicScrollPaneUI$PropertyChangeHandler.
Also i have removed the "forRemoval" for now.

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

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

From azvegint at openjdk.java.net  Mon Mar  1 11:15:09 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 1 Mar 2021 11:15:09 GMT
Subject: <Swing Dev> RFR: 8262085: Hovering Metal HTML Tooltips in
 different windows cause IllegalArgExc on Linux [v3]
In-Reply-To: <wsA2dM8EiS6JnMPQAZFS605wOCObbLZYzWkbjjVwylE=.8ac2d62f-d865-41a9-ac17-0bef98694486@github.com>
References: <wsA2dM8EiS6JnMPQAZFS605wOCObbLZYzWkbjjVwylE=.8ac2d62f-d865-41a9-ac17-0bef98694486@github.com>
Message-ID: <UKbERD1zkplrrxUnLC0iebNAzxhl0S2EqlMrJEB9tSk=.a21400d9-2e04-4704-99da-a3cff17ba6f9@github.com>

> This issue occurs only under `MetalLookAndFeel` on Linux. 
> 
> It was introduced by [JDK-8040630](https://bugs.openjdk.java.net/browse/JDK-8040630) fix.
> 
>> component.setBounds(ownerX, ownerY, 1, 1);
> 
> This line adds an extra reshape call with `1x1` size right before getting another one with correct sizes.
> 
> If `MetalToolTipUI#paint()` call happens before getting correct sizes,  it calculates `paintTextR` with negative sizes for component with `1x1` size,  thus IAE is thrown.
> 
> The fix is to do not proceed with `paint()` for negative sizes.
> The provided test fails for me in 0-30s interval(before the fix), other testing(client-tier1,2,3) looks good.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  Do not fail on UnsupportedLookAndFeelException.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2761/files
  - new: https://git.openjdk.java.net/jdk/pull/2761/files/034425b0..1651de87

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

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

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

From azvegint at openjdk.java.net  Mon Mar  1 11:15:10 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 1 Mar 2021 11:15:10 GMT
Subject: <Swing Dev> RFR: 8262085: Hovering Metal HTML Tooltips in
 different windows cause IllegalArgExc on Linux [v2]
In-Reply-To: <e2KHxI6AFLk7CwrexfmQbqp4Q8X_HrxDDg-3lJ1v7HY=.b140b62c-5054-46b8-af3a-0fb4375fdb72@github.com>
References: <wsA2dM8EiS6JnMPQAZFS605wOCObbLZYzWkbjjVwylE=.8ac2d62f-d865-41a9-ac17-0bef98694486@github.com>
 <7KUD9AtdNmMg876dcEPh2JLSyN54GozkIAozZTW6ZeE=.21dd9dc9-f4cc-4a3e-a8fd-f94eb6762bf6@github.com>
 <e2KHxI6AFLk7CwrexfmQbqp4Q8X_HrxDDg-3lJ1v7HY=.b140b62c-5054-46b8-af3a-0fb4375fdb72@github.com>
Message-ID: <TXvi2OVi11cPh8VxR_dyBCm5NpiFckkH14ERoJwkAmk=.3a5cd50d-e327-4087-bd57-1165b8dd401c@github.com>

On Mon, 1 Mar 2021 04:08:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simplified test
>
> test/jdk/javax/swing/JToolTip/FastTooltipSwitchIAE.java line 61:
> 
>> 59:         } catch (ClassNotFoundException | InstantiationException |
>> 60:                 UnsupportedLookAndFeelException | IllegalAccessException e) {
>> 61:             throw new RuntimeException(e);
> 
> Normally for UnsupportedLookAndFeelException, we dont throw Exception, rather print and continue to next L&F.

Done.

> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java line 124:
> 
>> 122:         if (paintTextR.width <= 0 || paintTextR.height <= 0) {
>> 123:             return;
>> 124:         }
> 
> Any idea why only MetalToolTip is affected only? JDK-8040630 fix was generic so shouldn't we apply this fix in BasicToolTipUI#paint instead?

Only Metal LaF uses `BasicHTML#getHTMLBaseline` for HTML tooltips painting.

Changing of `BasicToolTipUI#paint` will have no effect since it is not on the call stack.

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

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

From psadhukhan at openjdk.java.net  Mon Mar  1 11:44:39 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 1 Mar 2021 11:44:39 GMT
Subject: <Swing Dev> RFR: 8262085: Hovering Metal HTML Tooltips in
 different windows cause IllegalArgExc on Linux [v3]
In-Reply-To: <UKbERD1zkplrrxUnLC0iebNAzxhl0S2EqlMrJEB9tSk=.a21400d9-2e04-4704-99da-a3cff17ba6f9@github.com>
References: <wsA2dM8EiS6JnMPQAZFS605wOCObbLZYzWkbjjVwylE=.8ac2d62f-d865-41a9-ac17-0bef98694486@github.com>
 <UKbERD1zkplrrxUnLC0iebNAzxhl0S2EqlMrJEB9tSk=.a21400d9-2e04-4704-99da-a3cff17ba6f9@github.com>
Message-ID: <MEaiSiMRQf3hFJQ-_9J2YwOOSxMGdBS5IDZMVQWlLMc=.76d6ef98-8593-4d97-a728-1a45f6e5507d@github.com>

On Mon, 1 Mar 2021 11:15:09 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This issue occurs only under `MetalLookAndFeel` on Linux. 
>> 
>> It was introduced by [JDK-8040630](https://bugs.openjdk.java.net/browse/JDK-8040630) fix.
>> 
>>> component.setBounds(ownerX, ownerY, 1, 1);
>> 
>> This line adds an extra reshape call with `1x1` size right before getting another one with correct sizes.
>> 
>> If `MetalToolTipUI#paint()` call happens before getting correct sizes,  it calculates `paintTextR` with negative sizes for component with `1x1` size,  thus IAE is thrown.
>> 
>> The fix is to do not proceed with `paint()` for negative sizes.
>> The provided test fails for me in 0-30s interval(before the fix), other testing(client-tier1,2,3) looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not fail on UnsupportedLookAndFeelException.

Marked as reviewed by psadhukhan (Reviewer).

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

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

From azvegint at openjdk.java.net  Mon Mar  1 14:34:44 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 1 Mar 2021 14:34:44 GMT
Subject: <Swing Dev> Integrated: 8262085: Hovering Metal HTML Tooltips in
 different windows cause IllegalArgExc on Linux
In-Reply-To: <wsA2dM8EiS6JnMPQAZFS605wOCObbLZYzWkbjjVwylE=.8ac2d62f-d865-41a9-ac17-0bef98694486@github.com>
References: <wsA2dM8EiS6JnMPQAZFS605wOCObbLZYzWkbjjVwylE=.8ac2d62f-d865-41a9-ac17-0bef98694486@github.com>
Message-ID: <1tghFPpohICn9uiO89BmhD7Tzqw5gKw-8m1sDfKQGYc=.26654aee-5176-43bb-850b-b9c649cdac7d@github.com>

On Sat, 27 Feb 2021 17:02:13 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This issue occurs only under `MetalLookAndFeel` on Linux. 
> 
> It was introduced by [JDK-8040630](https://bugs.openjdk.java.net/browse/JDK-8040630) fix.
> 
>> component.setBounds(ownerX, ownerY, 1, 1);
> 
> This line adds an extra reshape call with `1x1` size right before getting another one with correct sizes.
> 
> If `MetalToolTipUI#paint()` call happens before getting correct sizes,  it calculates `paintTextR` with negative sizes for component with `1x1` size,  thus IAE is thrown.
> 
> The fix is to do not proceed with `paint()` for negative sizes.
> The provided test fails for me in 0-30s interval(before the fix), other testing(client-tier1,2,3) looks good.

This pull request has now been integrated.

Changeset: c569f1d6
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c569f1d6
Stats:     89 lines in 2 files changed: 86 ins; 2 del; 1 mod

8262085: Hovering Metal HTML Tooltips in different windows cause IllegalArgExc on Linux

Reviewed-by: serb, psadhukhan

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

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

From kizune at openjdk.java.net  Tue Mar  2 09:26:59 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 2 Mar 2021 09:26:59 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button"
Message-ID: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>

8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

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

Commit messages:
 - 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

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

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

From kizune at openjdk.java.net  Tue Mar  2 09:26:59 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 2 Mar 2021 09:26:59 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button"
In-Reply-To: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
Message-ID: <IRRBFJsloqhJXiF7ij6uxYKHdI8ZxRLyE8Q9V-zNnkE=.913a5127-06b0-44cd-b6dd-7a2370fd662b@github.com>

On Tue, 2 Mar 2021 09:15:22 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

I finally was able to get the failure on the test system and it seems like that was a result of the incomplete drawing of the frame at the time of screenshot taking. Here's the screenshot in full resolution - note the black part at the right part of the frame.
![fullScreenInit](https://user-images.githubusercontent.com/69642324/109626290-359d2780-7af5-11eb-8138-c8dee43222a7.png)
Setting min/max size of the frame and the content pane inside it fixes the issue so after couple of hundred of the runs i see no failures. Plus in the future should failure occur we will have better information in order to analyze the failure.

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

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

From azvegint at openjdk.java.net  Tue Mar  2 12:15:41 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 2 Mar 2021 12:15:41 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button"
In-Reply-To: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
Message-ID: <3GmHWARv70z9nHUngYZf_Zbk3wCrBjNos_Bx9uULyvo=.4a25a769-f3ce-453d-b6df-83eea1a8a092@github.com>

On Tue, 2 Mar 2021 09:15:22 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 112:

> 110:             frh = bounds.height - insets.top - insets.bottom;
> 111: 
> 112:             imageInit = robot.createScreenCapture(new Rectangle(locx, locy, frw, frh));

Looks like the result of this screen capture is unused.

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

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

From aivanov at openjdk.java.net  Tue Mar  2 13:57:40 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 2 Mar 2021 13:57:40 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button"
In-Reply-To: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
Message-ID: <meG04Ki_z1feuLR5pKphLSAb85ZVd29A4dATMtgutj0=.6a9c139b-1119-41ba-a1d1-5b65c7113755@github.com>

On Tue, 2 Mar 2021 09:15:22 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

Should `frame` be declared as `volatile`? It's accessed on main thread in finally block.
In addition to it, `frame.getBounds()` and `frame.getInsets()` are called on main thread instead of EDT.

test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 116:

> 114:             Graphics g = fullScreen.getGraphics();
> 115:             g.setColor(Color.RED);
> 116:             g.drawRect(locx-1, locy-1, frw+1, frh+1);

Suggestion:

            g.drawRect(locx - 1, locy - 1, frw + 1, frh + 1);

test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 93:

> 91:                     frame.setMinimumSize(new Dimension(350, 350));
> 92:                     frame.setMaximumSize(new Dimension(350, 350));
> 93:                     frame.pack();

Wouldn't it make {{desktop}} larger than 300,300?

test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 133:

> 131:                 ImageIO.write(imageShow, "png", new File("imageShow.png"));
> 132:                 ImageIO.write(fullScreen, "png", new File("fullScreenInit.png"));
> 133:                 throw new Exception("Failed to show opaque button");

<del>I suggest moving saving the images into a new method.</del>

I see the set of images is different each time. Probably it makes sense to save all the images which are non-null, what do you think?

test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 192:

> 190:                 ImageIO.write(fullScreen, "png", new File("fullScreenInit.png"));
> 191:                 throw new Exception("Failed to show non-opaque button");
> 192:             }

Does it make sense to move this block above before `invokeAndWait` to make the sequence of actions consistent?

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

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

From serb at openjdk.java.net  Tue Mar  2 18:16:45 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 2 Mar 2021 18:16:45 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button"
In-Reply-To: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
Message-ID: <1WdJ5jLL_-oVKe4zgi4X6UIuluW6sqdLx_Q82_1QIV4=.18ff99f6-6fca-4e33-80fa-089c6f7e8f94@github.com>

On Tue, 2 Mar 2021 09:15:22 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 101:

> 99: 
> 100:             robot.waitForIdle(1000);
> 101:             robot.delay(1000);

I doubt that this is a test issue, 2 seconds was not enough to properly show the frame?

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

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

From kizune at openjdk.java.net  Tue Mar  2 20:56:42 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 2 Mar 2021 20:56:42 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button"
In-Reply-To: <3GmHWARv70z9nHUngYZf_Zbk3wCrBjNos_Bx9uULyvo=.4a25a769-f3ce-453d-b6df-83eea1a8a092@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
 <3GmHWARv70z9nHUngYZf_Zbk3wCrBjNos_Bx9uULyvo=.4a25a769-f3ce-453d-b6df-83eea1a8a092@github.com>
Message-ID: <_CuA4_zfNMELgzJT2PG-UdpiGUk5tu2tcvwjOzwQy7k=.118a4f5c-340c-4b82-aeea-15dfd08aac4f@github.com>

On Tue, 2 Mar 2021 12:06:26 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"
>
> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 112:
> 
>> 110:             frh = bounds.height - insets.top - insets.bottom;
>> 111: 
>> 112:             imageInit = robot.createScreenCapture(new Rectangle(locx, locy, frw, frh));
> 
> Looks like the result of this screen capture is unused.

Yes, accidentally copied line instead of moving it.

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

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

From kizune at openjdk.java.net  Tue Mar  2 20:56:43 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 2 Mar 2021 20:56:43 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button"
In-Reply-To: <meG04Ki_z1feuLR5pKphLSAb85ZVd29A4dATMtgutj0=.6a9c139b-1119-41ba-a1d1-5b65c7113755@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
 <meG04Ki_z1feuLR5pKphLSAb85ZVd29A4dATMtgutj0=.6a9c139b-1119-41ba-a1d1-5b65c7113755@github.com>
Message-ID: <Ic0BzSm0vkAlsHp9r_ZJym3LOpdgPfivNIn7jU4IM_8=.eb6a5428-9d5f-437c-a6a0-b92157d1146a@github.com>

On Tue, 2 Mar 2021 13:26:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"
>
> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 116:
> 
>> 114:             Graphics g = fullScreen.getGraphics();
>> 115:             g.setColor(Color.RED);
>> 116:             g.drawRect(locx-1, locy-1, frw+1, frh+1);
> 
> Suggestion:
> 
>             g.drawRect(locx - 1, locy - 1, frw + 1, frh + 1);

Fixed.

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

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

From kizune at openjdk.java.net  Tue Mar  2 21:46:41 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 2 Mar 2021 21:46:41 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button"
In-Reply-To: <meG04Ki_z1feuLR5pKphLSAb85ZVd29A4dATMtgutj0=.6a9c139b-1119-41ba-a1d1-5b65c7113755@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
 <meG04Ki_z1feuLR5pKphLSAb85ZVd29A4dATMtgutj0=.6a9c139b-1119-41ba-a1d1-5b65c7113755@github.com>
Message-ID: <lfuyLU2hw01v3bWqVmfd1sfl96uHGQJIekiO_I5DMqU=.bfa0e4d2-11e0-4cb6-95d9-72a679c209ab@github.com>

On Tue, 2 Mar 2021 13:28:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"
>
> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 93:
> 
>> 91:                     frame.setMinimumSize(new Dimension(350, 350));
>> 92:                     frame.setMaximumSize(new Dimension(350, 350));
>> 93:                     frame.pack();
> 
> Wouldn't it make {{desktop}} larger than 300,300?

It will but it forces the invalidation and repainting of the content so test does not fail.

> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 133:
> 
>> 131:                 ImageIO.write(imageShow, "png", new File("imageShow.png"));
>> 132:                 ImageIO.write(fullScreen, "png", new File("fullScreenInit.png"));
>> 133:                 throw new Exception("Failed to show opaque button");
> 
> <del>I suggest moving saving the images into a new method.</del>
> 
> I see the set of images is different each time. Probably it makes sense to save all the images which are non-null, what do you think?

I don't think it is necessary. And since this is an existing test i'm trying not to change its overall behavior and having screenshots at other stages of the testing is not beneficial in the test debugging.

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

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

From kizune at openjdk.java.net  Tue Mar  2 22:02:40 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 2 Mar 2021 22:02:40 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button"
In-Reply-To: <meG04Ki_z1feuLR5pKphLSAb85ZVd29A4dATMtgutj0=.6a9c139b-1119-41ba-a1d1-5b65c7113755@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
 <meG04Ki_z1feuLR5pKphLSAb85ZVd29A4dATMtgutj0=.6a9c139b-1119-41ba-a1d1-5b65c7113755@github.com>
Message-ID: <UyUGvU3u0-vha3O02xpIBXPT_VaIK05YUJGBfEcmDpI=.40f03b20-cd23-46e6-babf-a0854761ad67@github.com>

On Tue, 2 Mar 2021 13:45:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"
>
> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 192:
> 
>> 190:                 ImageIO.write(fullScreen, "png", new File("fullScreenInit.png"));
>> 191:                 throw new Exception("Failed to show non-opaque button");
>> 192:             }
> 
> Does it make sense to move this block above before `invokeAndWait` to make the sequence of actions consistent?

Well, functionally it will not make any difference, we are analyzing the screenshots and the only thing that matters is at which time screenshot was taken. The only reason we don't take all screenshots in the beginning and analyze them later is to save test run time if test runs early. At the end it is not critical anymore. And as i said this is an existing test so i'm trying not to change it unless it affects its functionality.

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

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

From kizune at openjdk.java.net  Tue Mar  2 22:12:52 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 2 Mar 2021 22:12:52 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button" [v2]
In-Reply-To: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
Message-ID: <MZ1CyD4EbAaBNNvQsM4IfIa8k3xLjfb4EkxtmT_mmqk=.916103fd-074e-4f0f-8618-655df1b5c2b2@github.com>

> 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Minor fixes.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2790/files
  - new: https://git.openjdk.java.net/jdk/pull/2790/files/c0a2cd4e..2c6594c6

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

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

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

From kizune at openjdk.java.net  Tue Mar  2 22:12:53 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 2 Mar 2021 22:12:53 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button" [v2]
In-Reply-To: <1WdJ5jLL_-oVKe4zgi4X6UIuluW6sqdLx_Q82_1QIV4=.18ff99f6-6fca-4e33-80fa-089c6f7e8f94@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
 <1WdJ5jLL_-oVKe4zgi4X6UIuluW6sqdLx_Q82_1QIV4=.18ff99f6-6fca-4e33-80fa-089c6f7e8f94@github.com>
Message-ID: <qUsbXprrt89euhpd9T_Q3T0BQO-1rQ_3jCYP2cCazPs=.711f93d2-30aa-43fb-a4c7-da7a1f6e3678@github.com>

On Tue, 2 Mar 2021 18:14:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor fixes.
>
> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 101:
> 
>> 99: 
>> 100:             robot.waitForIdle(1000);
>> 101:             robot.delay(1000);
> 
> I doubt that this is a test issue, 2 seconds was not enough to properly show the frame?

The problem is that i tried to reproduce this behavior locally on Ubuntu running this test (and the simplified version of it) literally millions of times. The only time it fails is when it is run on mach5 and even then it fails very rarely - once per hundreds of runs. The changes here - especially forcing the resize - seems to eliminate the problem with mach5.

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

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

From aivanov at openjdk.java.net  Tue Mar  2 23:21:40 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 2 Mar 2021 23:21:40 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button" [v2]
In-Reply-To: <UyUGvU3u0-vha3O02xpIBXPT_VaIK05YUJGBfEcmDpI=.40f03b20-cd23-46e6-babf-a0854761ad67@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
 <meG04Ki_z1feuLR5pKphLSAb85ZVd29A4dATMtgutj0=.6a9c139b-1119-41ba-a1d1-5b65c7113755@github.com>
 <UyUGvU3u0-vha3O02xpIBXPT_VaIK05YUJGBfEcmDpI=.40f03b20-cd23-46e6-babf-a0854761ad67@github.com>
Message-ID: <KM56qszOzHGf_jPg2DgLPQIYtj8qlGQwentlKKijFtI=.ce808a6e-2987-46d8-b220-ed60e79fb093@github.com>

On Tue, 2 Mar 2021 21:59:31 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 192:
>> 
>>> 190:                 ImageIO.write(fullScreen, "png", new File("fullScreenInit.png"));
>>> 191:                 throw new Exception("Failed to show non-opaque button");
>>> 192:             }
>> 
>> Does it make sense to move this block above before `invokeAndWait` to make the sequence of actions consistent?
>
> Well, functionally it will not make any difference, we are analyzing the screenshots and the only thing that matters is at which time screenshot was taken. The only reason we don't take all screenshots in the beginning and analyze them later is to save test run time if test runs early. At the end it is not critical anymore. And as i said this is an existing test so i'm trying not to change it unless it affects its functionality.

Yes, I agree it makes no difference. Yet when you read the test code, the pattern ? show or hide the button, take screenshot, analyze it ? gets broken. This place is the only exception to the pattern; here the button is shown, screenshot is taken, then the button is hidden and only after hiding the button the screenshot is analyzed, which could give the wrong impression as if the screenshot after hiding the button is being analyzed here.

> It will but it forces the invalidation and repainting of the content so test does not fail.

Got it! It's the intention to cause additional repaint.

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

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

From aivanov at openjdk.java.net  Tue Mar  2 23:24:45 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 2 Mar 2021 23:24:45 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button" [v2]
In-Reply-To: <meG04Ki_z1feuLR5pKphLSAb85ZVd29A4dATMtgutj0=.6a9c139b-1119-41ba-a1d1-5b65c7113755@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
 <meG04Ki_z1feuLR5pKphLSAb85ZVd29A4dATMtgutj0=.6a9c139b-1119-41ba-a1d1-5b65c7113755@github.com>
Message-ID: <GK9bA_Y3767ap12bw99DJDK4pY46FrOOdRekFn9jO0g=.ae95a994-48da-48d0-af02-4cbcfa95726f@github.com>

On Tue, 2 Mar 2021 13:54:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Should `frame` be declared as `volatile`? It's accessed on main thread in finally block.
> In addition to it, `frame.getBounds()` and `frame.getInsets()` are called on main thread instead of EDT.

I couldn't link this comment to the code because GitHub does not allow adding comments to unmodified lines. Do I understand correctly that you're for leaving it as is?

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

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

From kizune at openjdk.java.net  Wed Mar  3 04:56:39 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 3 Mar 2021 04:56:39 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button" [v2]
In-Reply-To: <GK9bA_Y3767ap12bw99DJDK4pY46FrOOdRekFn9jO0g=.ae95a994-48da-48d0-af02-4cbcfa95726f@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
 <meG04Ki_z1feuLR5pKphLSAb85ZVd29A4dATMtgutj0=.6a9c139b-1119-41ba-a1d1-5b65c7113755@github.com>
 <GK9bA_Y3767ap12bw99DJDK4pY46FrOOdRekFn9jO0g=.ae95a994-48da-48d0-af02-4cbcfa95726f@github.com>
Message-ID: <dDDDpNrBIrMR_Y9n221cJ3eYy0DrVxCym2z5md4f8Iw=.f62dc072-4337-47e5-8d10-c9e2ab40d8c9@github.com>

On Tue, 2 Mar 2021 23:21:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > Should `frame` be declared as `volatile`? It's accessed on main thread in finally block.
> > In addition to it, `frame.getBounds()` and `frame.getInsets()` are called on main thread instead of EDT.
> 
> I couldn't link this comment to the code because GitHub does not allow adding comments to unmodified lines. Do I understand correctly that you're for leaving it as is?

Pretty much. Making frame volatile will not change the behavior, the assignment to it made in one place and it's on EDT inside invokeAndWait block, making it volatile will change nothing, it will be fully assigned by the time we leave EDT. And calling non-disruptive getters such getInsets or getBounds from main thread is not a problem either. By that time frame should be visible and in position - otherwise we will have much more interesting problems.

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

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

From kizune at openjdk.java.net  Wed Mar  3 05:09:38 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 3 Mar 2021 05:09:38 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button" [v2]
In-Reply-To: <KM56qszOzHGf_jPg2DgLPQIYtj8qlGQwentlKKijFtI=.ce808a6e-2987-46d8-b220-ed60e79fb093@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
 <meG04Ki_z1feuLR5pKphLSAb85ZVd29A4dATMtgutj0=.6a9c139b-1119-41ba-a1d1-5b65c7113755@github.com>
 <UyUGvU3u0-vha3O02xpIBXPT_VaIK05YUJGBfEcmDpI=.40f03b20-cd23-46e6-babf-a0854761ad67@github.com>
 <KM56qszOzHGf_jPg2DgLPQIYtj8qlGQwentlKKijFtI=.ce808a6e-2987-46d8-b220-ed60e79fb093@github.com>
Message-ID: <eEAHFMcu94_IN-thdI0JGBVXbTY5fNXrQFJu6DnKup4=.dc497399-376d-4caf-aca0-ff04f7c0b13d@github.com>

On Tue, 2 Mar 2021 23:17:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Well, functionally it will not make any difference, we are analyzing the screenshots and the only thing that matters is at which time screenshot was taken. The only reason we don't take all screenshots in the beginning and analyze them later is to save test run time if test runs early. At the end it is not critical anymore. And as i said this is an existing test so i'm trying not to change it unless it affects its functionality.
>
> Yes, I agree it makes no difference. Yet when you read the test code, the pattern ? show or hide the button, take screenshot, analyze it ? gets broken. This place is the only exception to the pattern; here the button is shown, screenshot is taken, then the button is hidden and only after hiding the button the screenshot is analyzed, which could give the wrong impression as if the screenshot after hiding the button is being analyzed here.

Ok, i give up, you won - i'll fix it.

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

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

From kizune at openjdk.java.net  Wed Mar  3 05:14:11 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 3 Mar 2021 05:14:11 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button" [v3]
In-Reply-To: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
Message-ID: <Vo0cd_B5FLmQ03_2QNkhsLbxFjYfjm1HqJ-t82oDpPM=.7d87a95d-290d-4268-8e24-ed32b6b93815@github.com>

> 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Moved checking block up to keep consistency of operations.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2790/files
  - new: https://git.openjdk.java.net/jdk/pull/2790/files/2c6594c6..0bfe02fd

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

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

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

From serb at openjdk.java.net  Wed Mar  3 06:34:52 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 3 Mar 2021 06:34:52 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button" [v3]
In-Reply-To: <qUsbXprrt89euhpd9T_Q3T0BQO-1rQ_3jCYP2cCazPs=.711f93d2-30aa-43fb-a4c7-da7a1f6e3678@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
 <1WdJ5jLL_-oVKe4zgi4X6UIuluW6sqdLx_Q82_1QIV4=.18ff99f6-6fca-4e33-80fa-089c6f7e8f94@github.com>
 <qUsbXprrt89euhpd9T_Q3T0BQO-1rQ_3jCYP2cCazPs=.711f93d2-30aa-43fb-a4c7-da7a1f6e3678@github.com>
Message-ID: <EtpvwoGoR0ngm4RMYgJ17Mo6kh2Z4qjVuJy9Qdtmfeo=.a0dadcbf-6b38-45ed-a442-2aaedf04a69b@github.com>

On Tue, 2 Mar 2021 22:08:48 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 101:
>> 
>>> 99: 
>>> 100:             robot.waitForIdle(1000);
>>> 101:             robot.delay(1000);
>> 
>> I doubt that this is a test issue, 2 seconds was not enough to properly show the frame?
>
> The problem is that i tried to reproduce this behavior locally on Ubuntu running this test (and the simplified version of it) literally millions of times. The only time it fails is when it is run on mach5 and even then it fails very rarely - once per hundreds of runs. The changes here - especially forcing the resize - seems to eliminate the problem with mach5.

Then it is a product bug, If the problem is unrelated to the performance and the root cause is in the wrong/broken final layout. Do we want to suggest the same thing if the user will get the same issue in their app?

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

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

From kizune at openjdk.java.net  Wed Mar  3 07:17:47 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 3 Mar 2021 07:17:47 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button" [v3]
In-Reply-To: <EtpvwoGoR0ngm4RMYgJ17Mo6kh2Z4qjVuJy9Qdtmfeo=.a0dadcbf-6b38-45ed-a442-2aaedf04a69b@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
 <1WdJ5jLL_-oVKe4zgi4X6UIuluW6sqdLx_Q82_1QIV4=.18ff99f6-6fca-4e33-80fa-089c6f7e8f94@github.com>
 <qUsbXprrt89euhpd9T_Q3T0BQO-1rQ_3jCYP2cCazPs=.711f93d2-30aa-43fb-a4c7-da7a1f6e3678@github.com>
 <EtpvwoGoR0ngm4RMYgJ17Mo6kh2Z4qjVuJy9Qdtmfeo=.a0dadcbf-6b38-45ed-a442-2aaedf04a69b@github.com>
Message-ID: <abteJDtvodSNTlkZkG4uhoe1txhiOimadN-6cjUQdCk=.08b23dcd-6b93-4d95-90c1-c086eafa3c9d@github.com>

On Wed, 3 Mar 2021 06:31:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The problem is that i tried to reproduce this behavior locally on Ubuntu running this test (and the simplified version of it) literally millions of times. The only time it fails is when it is run on mach5 and even then it fails very rarely - once per hundreds of runs. The changes here - especially forcing the resize - seems to eliminate the problem with mach5.
>
> Then it is a product bug, If the problem is unrelated to the performance and the root cause is in the wrong/broken final layout. Do we want to suggest the same thing if the user will get the same issue in their app?

It might be a product bug. Or it might be something specific to the machines with mach5 system. Or to some specific machine having hardware issue (i noticed that in my case all failures happened on one specific Linux test system). That's the problem. I have a simplified test case that should check for that specific problem and i'm running a dedicated Linux host in my home office with the same OS version than problematic machine that does nothing but runs this test in interactive mode for days. Today only i ran this test over 700000 times - 0 failures. If i would have a way to at least semi-reliable reproduce the problem i would create a new bug and would debug and fix it. But i don't. And the changes i made is simply a way to let this test to run even on the problematic host because the problem that happens have nothing to do with the functionality related to the test itself.

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

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

From aivanov at openjdk.java.net  Wed Mar  3 10:13:49 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 3 Mar 2021 10:13:49 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button" [v3]
In-Reply-To: <Vo0cd_B5FLmQ03_2QNkhsLbxFjYfjm1HqJ-t82oDpPM=.7d87a95d-290d-4268-8e24-ed32b6b93815@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
 <Vo0cd_B5FLmQ03_2QNkhsLbxFjYfjm1HqJ-t82oDpPM=.7d87a95d-290d-4268-8e24-ed32b6b93815@github.com>
Message-ID: <30KF0qD4EajxUuNscl2MWAGD1g-c5xhV_Txej7bhgZM=.283d8cad-1946-4d99-bd3c-735f20e9873f@github.com>

On Wed, 3 Mar 2021 05:14:11 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved checking block up to keep consistency of operations.

Marked as reviewed by aivanov (Reviewer).

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

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

From azvegint at openjdk.java.net  Wed Mar  3 10:50:41 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 3 Mar 2021 10:50:41 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button" [v3]
In-Reply-To: <Vo0cd_B5FLmQ03_2QNkhsLbxFjYfjm1HqJ-t82oDpPM=.7d87a95d-290d-4268-8e24-ed32b6b93815@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
 <Vo0cd_B5FLmQ03_2QNkhsLbxFjYfjm1HqJ-t82oDpPM=.7d87a95d-290d-4268-8e24-ed32b6b93815@github.com>
Message-ID: <ua1sGullGRjLtwonY5bgdwTBjWZQ3wQvVWZM1TNCLYw=.f2c098f3-ad29-4527-bb76-a81ca53eb232@github.com>

On Wed, 3 Mar 2021 05:14:11 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved checking block up to keep consistency of operations.

Marked as reviewed by azvegint (Reviewer).

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

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

From philip.race at oracle.com  Wed Mar  3 21:51:05 2021
From: philip.race at oracle.com (Philip Race)
Date: Wed, 3 Mar 2021 13:51:05 -0800
Subject: <Swing Dev> Project Lanai (New Metal Java 2D Rendering pipeline for
 macOS) EA build 10 has been released
Message-ID: <d012d25b-e6db-fcbf-619b-ed9324e3713b@oracle.com>

All,

We have prepared an EA 10 build of Project Lanai for JEP 382 [1] 
incorporating fixes to feed back during the ongoing code review [2]
EA 10 can be downloaded from https://jdk.java.net/lanai/.

Note the open issues and testing suggestions given there.

Please test with your apps and hardware and provide feedback via the 
lanai-dev at openjdk.java.net mailing list.

-Phil

[1] https://openjdk.java.net/jeps/382
[2] https://mail.openjdk.java.net/pipermail/2d-dev/2021-February/011902.html


From psadhukhan at openjdk.java.net  Thu Mar  4 03:44:54 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 4 Mar 2021 03:44:54 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button" [v3]
In-Reply-To: <Vo0cd_B5FLmQ03_2QNkhsLbxFjYfjm1HqJ-t82oDpPM=.7d87a95d-290d-4268-8e24-ed32b6b93815@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
 <Vo0cd_B5FLmQ03_2QNkhsLbxFjYfjm1HqJ-t82oDpPM=.7d87a95d-290d-4268-8e24-ed32b6b93815@github.com>
Message-ID: <lwEUAxqSFbXM1o8E9hjqux4ld7jUyEQZgyqZYc9hhwI=.cbca2206-704f-4ff2-a7e2-0bb7ca43bc8e@github.com>

On Wed, 3 Mar 2021 05:14:11 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved checking block up to keep consistency of operations.

test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 115:

> 113:             Graphics g = fullScreen.getGraphics();
> 114:             g.setColor(Color.RED);
> 115:             g.drawRect(locx - 1, locy - 1, frw + 1, frh + 1);

I believe we need to call g.dispose to dispose this object which we normallydo after getGraphics() call.

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

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

From trebari at openjdk.java.net  Thu Mar  4 05:50:18 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Thu, 4 Mar 2021 05:50:18 GMT
Subject: <Swing Dev> RFR: 8049700: Deprecate obsolete classes and
 methods in javax/swing/plaf/basic [v8]
In-Reply-To: <LcIvlc2HZGDo6ErOfqf_QZlwCpO2a7o2pPIDeaCb40E=.80fa98b5-728e-4198-a4fd-8d70e21302fc@github.com>
References: <LcIvlc2HZGDo6ErOfqf_QZlwCpO2a7o2pPIDeaCb40E=.80fa98b5-728e-4198-a4fd-8d70e21302fc@github.com>
Message-ID: <2qYuQ3q4_mqTbzdGse7HOVNhEjfHt8JddLX8S9Xx_v4=.569c94da-ab0a-497c-a8ba-2e3d34e192af@github.com>

> Please review the following fix for jdk17.
> In this fix i have deprecated and marked for removal following classes and methods 
>    public void intervalAdded(ListDataEvent e)
>    public void intervalRemoved(ListDataEvent e)
>    protected boolean lt(File a, File b) in BasicDirectoryModel.java
> 
>    inner class PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
>    ViewportChangeHandler in BasicScrollPaneUI.java
>    inner class MouseInputHandler in BasicMenuItemUI.java
>    method BasicToolBarUI.java#createFloatingFrame
> 
> From 8049700 not deprecated the paintText(Graphics g, JComponent c, Rectangle textRect, String text) method in BasicButtonUI  as AquaButtonUI, MetalButtonUI and MetalToggleButtonUI overrides it.
> Similarly not deprecated ChangeHandler of BasicMenuUI as AquaMenuUI and MotifMenuUI uses this class.

Tejpal Rebari 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 eight additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8049700
 - removed forRemoval
 - removed deprecation from methods of class which is also getting deprecated
 - removed jdk version from @deprecated javadoc tag
 - updated documentation
 - Merge remote-tracking branch 'upstream/master' into 8049700
 - minor correction
 - initial fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1958/files
  - new: https://git.openjdk.java.net/jdk/pull/1958/files/7dd2b39a..88a8c475

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

  Stats: 69867 lines in 2030 files changed: 41455 ins; 17817 del; 10595 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1958.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1958/head:pull/1958

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

From kizune at openjdk.java.net  Thu Mar  4 17:24:43 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 4 Mar 2021 17:24:43 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button" [v3]
In-Reply-To: <lwEUAxqSFbXM1o8E9hjqux4ld7jUyEQZgyqZYc9hhwI=.cbca2206-704f-4ff2-a7e2-0bb7ca43bc8e@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
 <Vo0cd_B5FLmQ03_2QNkhsLbxFjYfjm1HqJ-t82oDpPM=.7d87a95d-290d-4268-8e24-ed32b6b93815@github.com>
 <lwEUAxqSFbXM1o8E9hjqux4ld7jUyEQZgyqZYc9hhwI=.cbca2206-704f-4ff2-a7e2-0bb7ca43bc8e@github.com>
Message-ID: <ULPSSHTH6hnEdnWoU8wyeHzswgHjCwZWNWiKX1C5U4Q=.227adc21-0945-49cc-9e96-e2febcd78bac@github.com>

On Thu, 4 Mar 2021 02:56:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved checking block up to keep consistency of operations.
>
> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 115:
> 
>> 113:             Graphics g = fullScreen.getGraphics();
>> 114:             g.setColor(Color.RED);
>> 115:             g.drawRect(locx - 1, locy - 1, frw + 1, frh + 1);
> 
> I believe we need to call g.dispose to dispose this object which we normallydo after getGraphics() call.

It is not necessary in such a short test, JVM will exit after test ends which will clear all the resources captured by this Graphics instance.

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

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

From serb at openjdk.java.net  Thu Mar  4 22:45:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 4 Mar 2021 22:45:41 GMT
Subject: <Swing Dev> RFR: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button" [v3]
In-Reply-To: <ULPSSHTH6hnEdnWoU8wyeHzswgHjCwZWNWiKX1C5U4Q=.227adc21-0945-49cc-9e96-e2febcd78bac@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
 <Vo0cd_B5FLmQ03_2QNkhsLbxFjYfjm1HqJ-t82oDpPM=.7d87a95d-290d-4268-8e24-ed32b6b93815@github.com>
 <lwEUAxqSFbXM1o8E9hjqux4ld7jUyEQZgyqZYc9hhwI=.cbca2206-704f-4ff2-a7e2-0bb7ca43bc8e@github.com>
 <ULPSSHTH6hnEdnWoU8wyeHzswgHjCwZWNWiKX1C5U4Q=.227adc21-0945-49cc-9e96-e2febcd78bac@github.com>
Message-ID: <RhyVYhJ9ErHAh7DfMu2mfMcGkuFg9AKd-pKhTWR-6Fs=.12164d50-3562-4420-85e5-d603799a22ff@github.com>

On Thu, 4 Mar 2021 17:21:43 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 115:
>> 
>>> 113:             Graphics g = fullScreen.getGraphics();
>>> 114:             g.setColor(Color.RED);
>>> 115:             g.drawRect(locx - 1, locy - 1, frw + 1, frh + 1);
>> 
>> I believe we need to call g.dispose to dispose this object which we normallydo after getGraphics() call.
>
> It is not necessary in such a short test, JVM will exit after test ends which will clear all the resources captured by this Graphics instance.

BTW it will be closed/released only if the tests are run in the othervm mode, but jtreg tests might share the single VM for a group of tests.

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

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

From trebari at openjdk.java.net  Fri Mar  5 06:14:40 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Fri, 5 Mar 2021 06:14:40 GMT
Subject: <Swing Dev> RFR: 8049700: Deprecate obsolete classes and
 methods in javax/swing/plaf/basic [v6]
In-Reply-To: <oXYDIU1R0lheFPOmsKpg5FJko0rIggaVfcMktIChkj8=.c3ca1f34-c5a6-4e4c-b097-0406908b0ec9@github.com>
References: <LcIvlc2HZGDo6ErOfqf_QZlwCpO2a7o2pPIDeaCb40E=.80fa98b5-728e-4198-a4fd-8d70e21302fc@github.com>
 <Omn4vN7y_rSL1kyekfnJfwZpaUl7AKun4Sq9XqE7AVk=.077cd2e8-3be4-4769-b781-2f9da780fed0@github.com>
 <oXYDIU1R0lheFPOmsKpg5FJko0rIggaVfcMktIChkj8=.c3ca1f34-c5a6-4e4c-b097-0406908b0ec9@github.com>
Message-ID: <wR0b3OzTjGsxqer65jPWY8h__YnPfHqQe7_tpJdJ_BI=.a6aa0eac-f003-4ec3-b0e5-cc1934764733@github.com>

On Wed, 10 Feb 2021 18:04:16 GMT, Phil Race <prr at openjdk.org> wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed deprecation from methods of class which is also getting deprecated
>
> Are these methods all expected to be used only by a L&F rather than an application ?
> If by an application, then forRemoval seems too strong to me.
> If by a L&F then I think you need to go research what open source L&Fs there are out there and see how many of them are affected. Then we can decide about forRemoval.

@prrace Please take a look.

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

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

From philip.race at oracle.com  Sat Mar  6 02:41:39 2021
From: philip.race at oracle.com (Philip Race)
Date: Fri, 5 Mar 2021 18:41:39 -0800
Subject: <Swing Dev> Suspicious field assignment in StrikeMetrics
In-Reply-To: <CAF+DQ5c7K7e3UV8nN4G+_SWGYS9kVtkfi0WZEwsftikPQJi77Q@mail.gmail.com>
References: <CAF+DQ5cKLZv0m0byeH68s0SVMC=+HcuLaaWabb0g=nWxxGnmwQ@mail.gmail.com>
 <AM0PR02MB365190EBF8BF2D91550B2F91FED10@AM0PR02MB3651.eurprd02.prod.outlook.com>
 <CAF+DQ5c7K7e3UV8nN4G+_SWGYS9kVtkfi0WZEwsftikPQJi77Q@mail.gmail.com>
Message-ID: <bb65f8e8-425a-5ec8-5e81-a95d4fc91cb2@oracle.com>


Raising this on the right (2d) list would have helped. 
https://bugs.openjdk.java.net/browse/JDK-8263124

-phil.

On 1/5/21 6:23 AM, Andrey Turbanov wrote:
> I don't have a JBS account yet, so I can't create a bug.
> I hope someone, who read it can create it.
>
> Andrey Turbanov
>
> ??, 5 ???. 2021 ?. ? 15:14, Volodin, Vladislav <vladislav.volodin at sap.com>:
>> Hello Andrey,
>>
>> Nice catch! You can create a bug and prepare a pull request, so maintainers can review it.
>> What I have just personally noticed, all fields have the type float, so probably instead of "Integer.MIN_VALUE", I would recommend to use "-Float.MAX_VALUE". But since this code is about 13-years old, I don't know if reviewers can accept your PR without additional tests.
>>
>> Kind regards,
>> Vlad
>>
>> -----Original Message-----
>> From: swing-dev <swing-dev-retn at openjdk.java.net> On Behalf Of Andrey Turbanov
>> Sent: Dienstag, 5. Januar 2021 12:40
>> To: swing-dev at openjdk.java.net
>> Subject: <Swing Dev> Suspicious field assignment in StrikeMetrics
>>
>> Hello.
>> I've found suspicious code in constructor sun.font.StrikeMetrics#StrikeMetrics()
>>
>> StrikeMetrics() {
>>      ascentX = ascentY = Integer.MAX_VALUE;
>>      descentX = descentY = leadingX = leadingY = Integer.MIN_VALUE;
>>      baselineX = baselineX = maxAdvanceX = maxAdvanceY = Integer.MIN_VALUE;
>> }
>>
>> As you can see, basLineX field is assigned twice.
>> Looks like it's supposed to be like this:
>>
>> baselineX = baselineY = maxAdvanceX = maxAdvanceY = Integer.MIN_VALUE;
>>
>>
>>
>> Found by SpotBugs
>> https://spotbugs.readthedocs.io/en/stable/bugDescriptions.html#sa-double-assignment-of-field-sa-field-double-assignment
>>
>> Andrey Turbanov


From kizune at openjdk.java.net  Sat Mar  6 09:15:07 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 6 Mar 2021 09:15:07 GMT
Subject: <Swing Dev> Integrated: 8261689:
 javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception:
 Failed to hide opaque button"
In-Reply-To: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
References: <v5tBiiuqlcbFc0lzZdZiieI8_tSFS5bpxlAx6CSlMJQ=.f2a45bcc-5d90-4500-bfec-04ed1ddcf890@github.com>
Message-ID: <GkD1rB9IWiUWOYMR6GQ6VcYYXG4Sdv-jgESIZJHUFkk=.0a2961f0-56a8-4dc2-9953-d3ae9f4fa4f3@github.com>

On Tue, 2 Mar 2021 09:15:22 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

This pull request has now been integrated.

Changeset: 5eb2091a
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5eb2091a
Stats:     32 lines in 1 file changed: 24 ins; 7 del; 1 mod

8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

Reviewed-by: aivanov, azvegint

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

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

From prr at openjdk.java.net  Sun Mar  7 16:22:12 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 7 Mar 2021 16:22:12 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge
In-Reply-To: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
Message-ID: <4nc_mGufPdSzb6W33lt9L3EwiCBQLU99DTPF-q5NuCQ=.53a235e8-e82a-449b-82fa-3b93d3e6199b@github.com>

On Sun, 7 Mar 2021 03:18:53 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I saw C4530 with VS 2019 (16.9.0) as following (on Japanese locale):
> 
> AccessBridgeDebug.cpp
> ??: ?????? ????: d:\github-forked\jdk\src\jdk.accessibility\windows\native\common\AccessBridgeDebug.h
> 
>     :
> 
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\ostream(611): error C2220: ???
> ??????????????
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\ostream(611): warning C4530: C++
> ??????????????????? ??????????????????/EHsc ??????????
> ??: ?????? ????: c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\string
> 
> `/EHsc` has been already passed in other makefiles, and also AccessBridgeDebug.cpp uses some STL classes (e.g. `chrono` namespace). So `/EHsc` is a solution for this problem.

translate.google.com says the error in (almost) English is : 
c: \ program ~ 2 \ micros ~ 2 \ 2019 \ commun ~ 1 \ vc \ tools \ msvc \ 1428 ~ 1.299 \ include \ ostream (611): warning C4530: C ++ 
I'm using exception handling, but unwind semantics aren't enabled. Please specify / EHsc.

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

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

From stuefe at openjdk.java.net  Sun Mar  7 19:37:08 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sun, 7 Mar 2021 19:37:08 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge
In-Reply-To: <4nc_mGufPdSzb6W33lt9L3EwiCBQLU99DTPF-q5NuCQ=.53a235e8-e82a-449b-82fa-3b93d3e6199b@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
 <4nc_mGufPdSzb6W33lt9L3EwiCBQLU99DTPF-q5NuCQ=.53a235e8-e82a-449b-82fa-3b93d3e6199b@github.com>
Message-ID: <aRlcv7autVLkv9aYuC1fu6tD-0pd2yIeycwa-NBuTx4=.8e319c88-cde2-4bef-b587-94e97adc9fac@github.com>

On Sun, 7 Mar 2021 16:19:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> I saw C4530 with VS 2019 (16.9.0) as following (on Japanese locale):
>> 
>> AccessBridgeDebug.cpp
>> ??: ?????? ????: d:\github-forked\jdk\src\jdk.accessibility\windows\native\common\AccessBridgeDebug.h
>> 
>>     :
>> 
>> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\ostream(611): error C2220: ???
>> ??????????????
>> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\ostream(611): warning C4530: C++
>> ??????????????????? ??????????????????/EHsc ??????????
>> ??: ?????? ????: c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\string
>> 
>> `/EHsc` has been already passed in other makefiles, and also AccessBridgeDebug.cpp uses some STL classes (e.g. `chrono` namespace). So `/EHsc` is a solution for this problem.
>
> translate.google.com says the error in (almost) English is : 
> c: \ program ~ 2 \ micros ~ 2 \ 2019 \ commun ~ 1 \ vc \ tools \ msvc \ 1428 ~ 1.299 \ include \ ostream (611): warning C4530: C ++ 
> I'm using exception handling, but unwind semantics aren't enabled. Please specify / EHsc.

Yes, including c++ standard library headers like <ostream> means you need to deal with C++ exceptions thrown from library functions, and the code needs to be compiled with unwind capabilities. If its not switched on, and a C++ exception happens, the behavior is undefined. In my experience it results in the process being terminated.

I wondered why C++ std headers are even used. The source code looks C-ish; but "8196681: Java Access Bridge logging and debug flags dynamically controlled" added some coding, adding a bunch of C++11x semantics and included C++ std headers. Using "/Ehsc" had even been discussed: https://mail.openjdk.java.net/pipermail/awt-dev/2018-December/014847.html but not done.

Adding /Ehsc is fine of course, but I think thats not enough. Now C++ exceptions can pass through the code, but if they do, then what? E.g. this function `getTimeStamp()` added with 8196681:

https://github.com/openjdk/jdk/blob/113b5184cfc78fde057a7fe4d5872b463930da00/src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp#L85

calls into the C++ standard library to get a time stamp. Can't these function not throw C++ exceptions? Is that not what the compiler is warning about? If they throw, exceptions propagate through the code unbounded, until they either end the process or cause havoc at the next upper C-only-interface.

Or, maybe, rewrite this coding to use standard C- and Windows-APIs.  I think 8196681 could had been done with traditional windows- or standard C APIs. In particular, `getTimeStamp()` could probably be done simply with `GetTickCount` or `GetSystemTime` or functions from time.h.

Cheers, Thomas

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

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

From serb at openjdk.java.net  Sun Mar  7 22:03:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 7 Mar 2021 22:03:06 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge
In-Reply-To: <aRlcv7autVLkv9aYuC1fu6tD-0pd2yIeycwa-NBuTx4=.8e319c88-cde2-4bef-b587-94e97adc9fac@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
 <4nc_mGufPdSzb6W33lt9L3EwiCBQLU99DTPF-q5NuCQ=.53a235e8-e82a-449b-82fa-3b93d3e6199b@github.com>
 <aRlcv7autVLkv9aYuC1fu6tD-0pd2yIeycwa-NBuTx4=.8e319c88-cde2-4bef-b587-94e97adc9fac@github.com>
Message-ID: <yJLSKHwQkhyylJ5wlekNSNUi-6Rd2EPUrtEPB5ctGew=.6d25af6f-01c6-4437-b29d-86b6edf8e2cb@github.com>

On Sun, 7 Mar 2021 19:34:36 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I wondered why C++ std headers are even used. The source code looks C-ish; but "8196681: Java Access Bridge logging and debug flags dynamically controlled" added some coding, adding a bunch of C++11x semantics and included C++ std headers. Using "/Ehsc" had even been discussed: https://mail.openjdk.java.net/pipermail/awt-dev/2018-December/014847.html but not done.

After that discussion the usage of "string.h"/etc was dropped and "C string manipulation API" was used instead, and that suppressed the warning. I do not know why it was not complaining about "getTimeStamp". I think the fix should refactor the code again.

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

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

From ysuenaga at openjdk.java.net  Mon Mar  8 00:56:24 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 8 Mar 2021 00:56:24 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge [v2]
In-Reply-To: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
Message-ID: <T1QW3aeoxbygF0Kb0zKHjChMCoXRQvojX6fr_ds7lcA=.71a4065b-486b-4934-ac96-a2021c0865e5@github.com>

> I saw C4530 with VS 2019 (16.9.0) as following (on Japanese locale):
> 
> AccessBridgeDebug.cpp
> ??: ?????? ????: d:\github-forked\jdk\src\jdk.accessibility\windows\native\common\AccessBridgeDebug.h
> 
>     :
> 
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\ostream(611): error C2220: ???
> ??????????????
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\ostream(611): warning C4530: C++
> ??????????????????? ??????????????????/EHsc ??????????
> ??: ?????? ????: c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\string
> 
> `/EHsc` has been already passed in other makefiles, and also AccessBridgeDebug.cpp uses some STL classes (e.g. `chrono` namespace). So `/EHsc` is a solution for this problem.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Refactoring

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2859/files
  - new: https://git.openjdk.java.net/jdk/pull/2859/files/f68a1281..4a357eb9

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

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

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

From ysuenaga at openjdk.java.net  Mon Mar  8 01:01:06 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 8 Mar 2021 01:01:06 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge
In-Reply-To: <yJLSKHwQkhyylJ5wlekNSNUi-6Rd2EPUrtEPB5ctGew=.6d25af6f-01c6-4437-b29d-86b6edf8e2cb@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
 <4nc_mGufPdSzb6W33lt9L3EwiCBQLU99DTPF-q5NuCQ=.53a235e8-e82a-449b-82fa-3b93d3e6199b@github.com>
 <aRlcv7autVLkv9aYuC1fu6tD-0pd2yIeycwa-NBuTx4=.8e319c88-cde2-4bef-b587-94e97adc9fac@github.com>
 <yJLSKHwQkhyylJ5wlekNSNUi-6Rd2EPUrtEPB5ctGew=.6d25af6f-01c6-4437-b29d-86b6edf8e2cb@github.com>
Message-ID: <Cpi8DvpYpBLxXGGYDPxhTI5WQBDR43RufTF1sPw_dPg=.3d19fd2b-8353-4ac8-afd3-d9afae4dd638@github.com>

On Sun, 7 Mar 2021 22:00:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yes, including c++ standard library headers like <ostream> means you need to deal with C++ exceptions thrown from library functions, and the code needs to be compiled with unwind capabilities. If its not switched on, and a C++ exception happens, the behavior is undefined. In my experience it results in the process being terminated.
>> 
>> I wondered why C++ std headers are even used. The source code looks C-ish; but "8196681: Java Access Bridge logging and debug flags dynamically controlled" added some coding, adding a bunch of C++11x semantics and included C++ std headers. Using "/Ehsc" had even been discussed: https://mail.openjdk.java.net/pipermail/awt-dev/2018-December/014847.html but not done.
>> 
>> Adding /Ehsc is fine of course, but I think thats not enough. Now C++ exceptions can pass through the code, but if they do, then what? E.g. this function `getTimeStamp()` added with 8196681:
>> 
>> https://github.com/openjdk/jdk/blob/113b5184cfc78fde057a7fe4d5872b463930da00/src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp#L85
>> 
>> calls into the C++ standard library to get a time stamp. Can't these function not throw C++ exceptions? Is that not what the compiler is warning about? If they throw, exceptions propagate through the code unbounded, until they either end the process or cause havoc at the next upper C-only-interface.
>> 
>> Or, maybe, rewrite this coding to use standard C- and Windows-APIs.  I think 8196681 could had been done with traditional windows- or standard C APIs. In particular, `getTimeStamp()` could probably be done simply with `GetTickCount` or `GetSystemTime` or functions from time.h.
>> 
>> Cheers, Thomas
>
>> I wondered why C++ std headers are even used. The source code looks C-ish; but "8196681: Java Access Bridge logging and debug flags dynamically controlled" added some coding, adding a bunch of C++11x semantics and included C++ std headers. Using "/Ehsc" had even been discussed: https://mail.openjdk.java.net/pipermail/awt-dev/2018-December/014847.html but not done.
> 
> After that discussion the usage of "string.h"/etc was dropped and "C string manipulation API" was used instead, and that suppressed the warning. I do not know why it was not complaining about "getTimeStamp". I think the fix should refactor the code again.

Thank you for comments! I refactored `getTimeStamp()` not to use STL functions in new commit. The error messages have gone without /EHsc.
I use `11644473600000ULL` to rebase Epoch from 1601 to 1970, it comes from ProcessHandleImpl_win.c:
https://github.com/openjdk/jdk/blob/22a3117d229cba10c690a4e66baf9c754a09e57c/src/java.base/windows/native/libjava/ProcessHandleImpl_win.c#L342

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

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

From stuefe at openjdk.java.net  Mon Mar  8 06:28:07 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 8 Mar 2021 06:28:07 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge
In-Reply-To: <yJLSKHwQkhyylJ5wlekNSNUi-6Rd2EPUrtEPB5ctGew=.6d25af6f-01c6-4437-b29d-86b6edf8e2cb@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
 <4nc_mGufPdSzb6W33lt9L3EwiCBQLU99DTPF-q5NuCQ=.53a235e8-e82a-449b-82fa-3b93d3e6199b@github.com>
 <aRlcv7autVLkv9aYuC1fu6tD-0pd2yIeycwa-NBuTx4=.8e319c88-cde2-4bef-b587-94e97adc9fac@github.com>
 <yJLSKHwQkhyylJ5wlekNSNUi-6Rd2EPUrtEPB5ctGew=.6d25af6f-01c6-4437-b29d-86b6edf8e2cb@github.com>
Message-ID: <RF8IJYXvNaAlD1Y8kLPMhkd0vcBfCf7g0rMQMen1nAA=.514d14d2-b7f3-4d8a-9d30-14029660052b@github.com>

On Sun, 7 Mar 2021 22:00:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I wondered why C++ std headers are even used. The source code looks C-ish; but "8196681: Java Access Bridge logging and debug flags dynamically controlled" added some coding, adding a bunch of C++11x semantics and included C++ std headers. Using "/Ehsc" had even been discussed: https://mail.openjdk.java.net/pipermail/awt-dev/2018-December/014847.html but not done.
> 
> After that discussion the usage of "string.h"/etc was dropped and "C string manipulation API" was used instead, and that suppressed the warning. I do not know why it was not complaining about "getTimeStamp". I think the fix should refactor the code again.

Ah, I missed that part. Thanks for clarifying the history :)

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

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

From stuefe at openjdk.java.net  Mon Mar  8 06:41:08 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 8 Mar 2021 06:41:08 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge [v2]
In-Reply-To: <T1QW3aeoxbygF0Kb0zKHjChMCoXRQvojX6fr_ds7lcA=.71a4065b-486b-4934-ac96-a2021c0865e5@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
 <T1QW3aeoxbygF0Kb0zKHjChMCoXRQvojX6fr_ds7lcA=.71a4065b-486b-4934-ac96-a2021c0865e5@github.com>
Message-ID: <Rmb9h2DdsZl26XPdMFUPmD9qxM9RFF2IHCkFJDLsnj0=.af52b701-10cf-45e6-a766-33895f808a5e@github.com>

On Mon, 8 Mar 2021 00:56:24 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I saw C4530 with VS 2019 (16.9.0) as following (on Japanese locale):
>> 
>> AccessBridgeDebug.cpp
>> ??: ?????? ????: d:\github-forked\jdk\src\jdk.accessibility\windows\native\common\AccessBridgeDebug.h
>> 
>>     :
>> 
>> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\ostream(611): error C2220: ???
>> ??????????????
>> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\ostream(611): warning C4530: C++
>> ??????????????????? ??????????????????/EHsc ??????????
>> ??: ?????? ????: c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\string
>> 
>> `/EHsc` has been already passed in other makefiles, and also AccessBridgeDebug.cpp uses some STL classes (e.g. `chrono` namespace). So `/EHsc` is a solution for this problem.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring

Hi Yasumasa,

small nits below. But this looks fine to me as it is already so I leave it up to you and the others whether to change anything. Thank you for taking my suggestion.

Cheers, Thomas

src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp line 80:

> 78:     uli.LowPart = ft.dwLowDateTime;
> 79:     uli.HighPart = ft.dwHighDateTime;
> 80:     return (uli.QuadPart / 10000ULL) - 11644473600000ULL; // Rebase Epoch from 1601 to 1970

This is good and true to the original change; 

I am not even sure the epoch rebase is needed. All 8196681 did was to print out the timestamps verbatim. I do not know enough about how that debug trace is used, and if the timestamps really have to be 1970 based.

src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp line 35:

> 33: #include <windows.h>
> 34: #include <cstdlib>
> 35: #include <cstring>

Matter of taste, but I would prefer stdlib.h and string.h instead of cxxx. Just to keep in line with the rest of the coding. Weird mix of styles otherwise (I mean this code still uses 16bit era Windows APIs).

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

Marked as reviewed by stuefe (Reviewer).

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

From ysuenaga at openjdk.java.net  Mon Mar  8 07:50:10 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 8 Mar 2021 07:50:10 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge [v2]
In-Reply-To: <Rmb9h2DdsZl26XPdMFUPmD9qxM9RFF2IHCkFJDLsnj0=.af52b701-10cf-45e6-a766-33895f808a5e@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
 <T1QW3aeoxbygF0Kb0zKHjChMCoXRQvojX6fr_ds7lcA=.71a4065b-486b-4934-ac96-a2021c0865e5@github.com>
 <Rmb9h2DdsZl26XPdMFUPmD9qxM9RFF2IHCkFJDLsnj0=.af52b701-10cf-45e6-a766-33895f808a5e@github.com>
Message-ID: <S0o-7c81rJxXU6M2AdBpskZJuGN5zqlAsRY1Ime0AgE=.e46a19cb-5dde-4c6e-b908-4d3d0bf69f40@github.com>

On Mon, 8 Mar 2021 06:34:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactoring
>
> src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp line 80:
> 
>> 78:     uli.LowPart = ft.dwLowDateTime;
>> 79:     uli.HighPart = ft.dwHighDateTime;
>> 80:     return (uli.QuadPart / 10000ULL) - 11644473600000ULL; // Rebase Epoch from 1601 to 1970
> 
> This is good and true to the original change; 
> 
> I am not even sure the epoch rebase is needed. All 8196681 did was to print out the timestamps verbatim. I do not know enough about how that debug trace is used, and if the timestamps really have to be 1970 based.

It seems to be fine not to use UNIX epoch at first glance as long as we can know the timing of events, but I'm not sure (Thus I rewrote to comply with the original code). So I want to hear from the others.

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

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

From ysuenaga at openjdk.java.net  Mon Mar  8 07:54:07 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 8 Mar 2021 07:54:07 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge [v2]
In-Reply-To: <Rmb9h2DdsZl26XPdMFUPmD9qxM9RFF2IHCkFJDLsnj0=.af52b701-10cf-45e6-a766-33895f808a5e@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
 <T1QW3aeoxbygF0Kb0zKHjChMCoXRQvojX6fr_ds7lcA=.71a4065b-486b-4934-ac96-a2021c0865e5@github.com>
 <Rmb9h2DdsZl26XPdMFUPmD9qxM9RFF2IHCkFJDLsnj0=.af52b701-10cf-45e6-a766-33895f808a5e@github.com>
Message-ID: <j7wS-dEkNzW56UgQV9Llfy52KArZhV8DDLafgi8pIjY=.16f6b248-4006-4e0e-a640-45acdc6a9654@github.com>

On Mon, 8 Mar 2021 06:37:07 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactoring
>
> src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp line 35:
> 
>> 33: #include <windows.h>
>> 34: #include <cstdlib>
>> 35: #include <cstring>
> 
> Matter of taste, but I would prefer stdlib.h and string.h instead of cxxx. Just to keep in line with the rest of the coding. Weird mix of styles otherwise (I mean this code still uses 16bit era Windows APIs).

AccessBridgeDebug has `.cpp` in its extension, so the compiler can handle it as C++ code, and also "cstring" seems to be prefer to "string.h" in @mrserb 's comment. It's nature to use "cstring" in C++ source code IMHO. Let's see comments from the others.

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

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

From kizune at openjdk.java.net  Mon Mar  8 13:27:28 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 8 Mar 2021 13:27:28 GMT
Subject: <Swing Dev> RFR: 8182043: Access to Windows Large Icons
In-Reply-To: <e1blsXETihJeuQUW6-ERVupKC2uGEq56ZCnX0x3h-vA=.007de252-fc87-4e4c-9c6d-180e90f38e9a@github.com>
References: <e1blsXETihJeuQUW6-ERVupKC2uGEq56ZCnX0x3h-vA=.007de252-fc87-4e4c-9c6d-180e90f38e9a@github.com>
Message-ID: <Xj2xcoi5vCQg0gxZizxxEvomvz32LRd6DbBdwqOa1yA=.f677bea5-7cb5-4ce8-85e8-e53c63162bf2@github.com>

On Mon, 8 Mar 2021 13:22:07 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Fix updated after first round of review.

Continuation of review at https://github.com/openjdk/jdk/pull/380

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

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

From kizune at openjdk.java.net  Mon Mar  8 13:27:28 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 8 Mar 2021 13:27:28 GMT
Subject: <Swing Dev> RFR: 8182043: Access to Windows Large Icons
Message-ID: <e1blsXETihJeuQUW6-ERVupKC2uGEq56ZCnX0x3h-vA=.007de252-fc87-4e4c-9c6d-180e90f38e9a@github.com>

Fix updated after first round of review.

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

Commit messages:
 - 8182043: Access to Windows Large Icons

Changes: https://git.openjdk.java.net/jdk/pull/2875/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8182043
  Stats: 335 lines in 6 files changed: 270 ins; 29 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2875.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875

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

From serb at openjdk.java.net  Mon Mar  8 19:33:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 8 Mar 2021 19:33:08 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge [v2]
In-Reply-To: <S0o-7c81rJxXU6M2AdBpskZJuGN5zqlAsRY1Ime0AgE=.e46a19cb-5dde-4c6e-b908-4d3d0bf69f40@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
 <T1QW3aeoxbygF0Kb0zKHjChMCoXRQvojX6fr_ds7lcA=.71a4065b-486b-4934-ac96-a2021c0865e5@github.com>
 <Rmb9h2DdsZl26XPdMFUPmD9qxM9RFF2IHCkFJDLsnj0=.af52b701-10cf-45e6-a766-33895f808a5e@github.com>
 <S0o-7c81rJxXU6M2AdBpskZJuGN5zqlAsRY1Ime0AgE=.e46a19cb-5dde-4c6e-b908-4d3d0bf69f40@github.com>
Message-ID: <BXa7BAfnGWZ8uurRWn7fO0sICPO4MygopzHKjI4udL8=.849592c6-c398-4370-9ec6-53a3896a390a@github.com>

On Mon, 8 Mar 2021 07:46:54 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp line 80:
>> 
>>> 78:     uli.LowPart = ft.dwLowDateTime;
>>> 79:     uli.HighPart = ft.dwHighDateTime;
>>> 80:     return (uli.QuadPart / 10000ULL) - 11644473600000ULL; // Rebase Epoch from 1601 to 1970
>> 
>> This is good and true to the original change; 
>> 
>> I am not even sure the epoch rebase is needed. All 8196681 did was to print out the timestamps verbatim. I do not know enough about how that debug trace is used, and if the timestamps really have to be 1970 based.
>
> It seems to be fine not to use UNIX epoch at first glance as long as we can know the timing of events, but I'm not sure (Thus I rewrote to comply with the original code). So I want to hear from the others.

Did you check via some a11y tool that the new code actually works?

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

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

From ysuenaga at openjdk.java.net  Tue Mar  9 00:52:06 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Mar 2021 00:52:06 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge [v2]
In-Reply-To: <BXa7BAfnGWZ8uurRWn7fO0sICPO4MygopzHKjI4udL8=.849592c6-c398-4370-9ec6-53a3896a390a@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
 <T1QW3aeoxbygF0Kb0zKHjChMCoXRQvojX6fr_ds7lcA=.71a4065b-486b-4934-ac96-a2021c0865e5@github.com>
 <Rmb9h2DdsZl26XPdMFUPmD9qxM9RFF2IHCkFJDLsnj0=.af52b701-10cf-45e6-a766-33895f808a5e@github.com>
 <S0o-7c81rJxXU6M2AdBpskZJuGN5zqlAsRY1Ime0AgE=.e46a19cb-5dde-4c6e-b908-4d3d0bf69f40@github.com>
 <BXa7BAfnGWZ8uurRWn7fO0sICPO4MygopzHKjI4udL8=.849592c6-c398-4370-9ec6-53a3896a390a@github.com>
Message-ID: <nci2NpmndUlC3aKzH0TmhqGAiniBoFSW3ueF1k7ryW0=.104864ab-186c-4a5d-b47e-347ad3265a20@github.com>

On Mon, 8 Mar 2021 19:30:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> It seems to be fine not to use UNIX epoch at first glance as long as we can know the timing of events, but I'm not sure (Thus I rewrote to comply with the original code). So I want to hear from the others.
>
> Did you check via some a11y tool that the new code actually works?

No, can you help?

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar  9 01:40:07 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 9 Mar 2021 01:40:07 GMT
Subject: <Swing Dev> Integrated: 8262161: Refactor manual I/O stream copying
 in java.desktop to use new convenience APIs
In-Reply-To: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
References: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
Message-ID: <-jLk_NzWGP-TyHwzQnXyexoqtktQBH3wUO52Fx6XlHc=.9c023cb6-db0f-429c-abbd-d565db439826@github.com>

On Mon, 21 Dec 2020 07:54:17 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Cleanup code to use new handy methods in `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy:
> 1. java.io.InputStream#readAllBytes
> 2. java.io.InputStream#transferTo
> 3. java.nio.file.Files#copy

This pull request has now been integrated.

Changeset: 39b11138
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/39b11138
Stats:     134 lines in 11 files changed: 3 ins; 102 del; 29 mod

8262161: Refactor manual I/O stream copying in java.desktop to use new convenience APIs

Reviewed-by: serb, prr

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

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

From psadhukhan at openjdk.java.net  Tue Mar  9 04:16:11 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 9 Mar 2021 04:16:11 GMT
Subject: <Swing Dev> RFR: 8263170: ComboBoxModel documentation refers to a
 nonexistant type
Message-ID: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>

javadoc of ComboBoxModel incorrectly specifies "extends ListDataModel" but actually it extends ListModel and there is no such interface as ListDataModel. Rectified the anomaly.

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

Commit messages:
 - 8263170: ComboBoxModel documentation refers to a nonexistant type

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

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

From psadhukhan at openjdk.java.net  Tue Mar  9 08:14:17 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 9 Mar 2021 08:14:17 GMT
Subject: <Swing Dev> RFR: 6251901: BasicTextUI: installDefaults method are
 contrary to the documentation
Message-ID: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>

BasicTextUI: installDefaults javadoc specifies only font, foreground and background properties are set  if their current value is either null or a UIResource
and other properties are set if the current value is null
but in reality all properties such as font, foreground, background, caret color, selection color, selected text color, disabled text color, and border color are set if their current value is either null or a UIResource.
Fixed the javadoc to specify the same.

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

Commit messages:
 - 6251901: BasicTextUI: installDefaults method are contrary to the documentation

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

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

From azvegint at openjdk.java.net  Tue Mar  9 14:04:07 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 9 Mar 2021 14:04:07 GMT
Subject: <Swing Dev> RFR: 6251901: BasicTextUI: installDefaults method
 are contrary to the documentation
In-Reply-To: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
References: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
Message-ID: <dE7YUKA0hRMr6EaOCMtrpQGW0rO6jmNcHoBsqSaEZBE=.eef2fd80-cbf8-44bd-9803-853d5e65f59e@github.com>

On Tue, 9 Mar 2021 08:09:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> BasicTextUI: installDefaults javadoc specifies only font, foreground and background properties are set  if their current value is either null or a UIResource
> and other properties are set if the current value is null
> but in reality all properties such as font, foreground, background, caret color, selection color, selected text color, disabled text color, and border color are set if their current value is either null or a UIResource.
> Fixed the javadoc to specify the same.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 306:

> 304:      * Initializes component properties, such as font, foreground,
> 305:      * background, caret color, selection color, selected text color,
> 306:      * disabled text color, and border color.  All properties are set

This method is also affects a margin, but it is does not mentioned in the javadoc.

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

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

From azvegint at openjdk.java.net  Tue Mar  9 14:10:07 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 9 Mar 2021 14:10:07 GMT
Subject: <Swing Dev> RFR: 8263170: ComboBoxModel documentation refers to
 a nonexistant type
In-Reply-To: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>
References: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>
Message-ID: <CGmTypqUzNIJL9iAv-yPOv5DFsfeWIxNjnmMNn2I_7g=.8fc74c86-b4bd-4136-8fc6-ec12f72124fe@github.com>

On Tue, 9 Mar 2021 04:10:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javadoc of ComboBoxModel incorrectly specifies "extends ListDataModel" but actually it extends ListModel and there is no such interface as ListDataModel. Rectified the anomaly.

Marked as reviewed by azvegint (Reviewer).

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

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

From trebari at openjdk.java.net  Tue Mar  9 14:28:08 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Tue, 9 Mar 2021 14:28:08 GMT
Subject: <Swing Dev> RFR: 8263170: ComboBoxModel documentation refers to
 a nonexistant type
In-Reply-To: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>
References: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>
Message-ID: <ertuyYPV7fJNN5PDjOXvQ6euBFgXRwVe6x1LbqZIvsA=.7471779f-c38b-4028-9348-64102c28e33a@github.com>

On Tue, 9 Mar 2021 04:10:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javadoc of ComboBoxModel incorrectly specifies "extends ListDataModel" but actually it extends ListModel and there is no such interface as ListDataModel. Rectified the anomaly.

Marked as reviewed by trebari (Committer).

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

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

From pbansal at openjdk.java.net  Tue Mar  9 16:55:07 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 9 Mar 2021 16:55:07 GMT
Subject: <Swing Dev> RFR: 8263170: ComboBoxModel documentation refers to
 a nonexistant type
In-Reply-To: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>
References: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>
Message-ID: <XXZ3XDaz_5oz7yJmu8bLWGUyJFfOYFINIZOEnA7_PcY=.3782d87a-acc9-48bd-85df-85b71c6e3ceb@github.com>

On Tue, 9 Mar 2021 04:10:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javadoc of ComboBoxModel incorrectly specifies "extends ListDataModel" but actually it extends ListModel and there is no such interface as ListDataModel. Rectified the anomaly.

Marked as reviewed by pbansal (Reviewer).

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

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

From pbansal at openjdk.java.net  Tue Mar  9 17:25:19 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 9 Mar 2021 17:25:19 GMT
Subject: <Swing Dev> RFR: 8262981: Create implementation for
 NSAccessibilitySlider protocol
Message-ID: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>

Create implementation of NSAccessibilitySlider protocol https://developer.apple.com/documentation/appkit/nsaccessibilityslider

The implementation has the function performIncrement and performDecrement to increase/decrease the value of slider using the VoiceOver. To implement this functionality, I could think of  following two ways. I have chosen the first one here though it is more intrusive.
1. Make the AccessibleJSlider class implement the AccessibleAction interface. This makes AccessibleJSlider consistent with the AccessibleJSpinner class. It is more clear and the logic to increase/decrease Slider value can be changed easily. But this changes AccessibleJSlider class and will need a CSR.
2. Get the current Accessible Value from the component and  just increment/decrement it in SliderAccessibility.m  class itself and then set the current accessible value fro there only. This will not need any changes in AccessibleJSlider class, but this does not look correct way and I have not used this.

The changes can be easily tested by using a JSlider example, like the following example. VO should announce the correct the slider values. To change the slider values, use ctrl+opt+shift+down key to start interacting with the slider, then use ctrl+opt+up/down arrow keys to increment/decrement slider values.

      import javax.swing.JFrame;
      import javax.swing.JSlider;
      
      public class JSliderDemo{
          public static void main(String[] args) throws Exception {
              JFrame jframe = new JFrame("JSlider Demo");
              jframe.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
              jframe.add(new JSlider());
      
              jframe.setLocationRelativeTo(null);
              jframe.pack();
              jframe.setVisible(true);
          }
      }

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

Commit messages:
 - Remove whitespaces
 - remove SpinboxAccessibility.m changes
 - Code cleanup
 - cleanup
 - 8262981: Create implementation for NSAccessibilitySlider protocol

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

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

From aivanov at openjdk.java.net  Tue Mar  9 21:00:08 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 9 Mar 2021 21:00:08 GMT
Subject: <Swing Dev> RFR: 8263170: ComboBoxModel documentation refers to
 a nonexistant type
In-Reply-To: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>
References: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>
Message-ID: <MWv_KHWg5dif0Ciu_iYm-NWfr6fvEcMgtaVQk1r_ndE=.4a04f037-c5e7-489d-a935-0ab72e4832ec@github.com>

On Tue, 9 Mar 2021 04:10:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javadoc of ComboBoxModel incorrectly specifies "extends ListDataModel" but actually it extends ListModel and there is no such interface as ListDataModel. Rectified the anomaly.

Marked as reviewed by aivanov (Reviewer).

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

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

From aivanov at openjdk.java.net  Tue Mar  9 21:20:07 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 9 Mar 2021 21:20:07 GMT
Subject: <Swing Dev> RFR: 6251901: BasicTextUI: installDefaults method
 are contrary to the documentation
In-Reply-To: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
References: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
Message-ID: <EE8uM3qc_RvT_QTgU58rz2gS5sbcGnMAjPafdvJKb-A=.1b025eac-41de-4d9f-bdf4-25aae9da2662@github.com>

On Tue, 9 Mar 2021 08:09:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> BasicTextUI: installDefaults javadoc specifies only font, foreground and background properties are set  if their current value is either null or a UIResource
> and other properties are set if the current value is null
> but in reality all properties such as font, foreground, background, caret color, selection color, selected text color, disabled text color, and border color are set if their current value is either null or a UIResource.
> Fixed the javadoc to specify the same.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 307:

> 305:      * background, caret color, selection color, selected text color,
> 306:      * disabled text color, and border color.  All properties are set
> 307:      * if their current value is either null or a UIResource.

Suggestion:

     * disabled text color, and border color.  Each property is set,
     * if its current value is either null or a UIResource.

I think this conveys the behavior better. Each property is checked separately, independently from other properties.

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

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

From aivanov at openjdk.java.net  Tue Mar  9 21:20:10 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 9 Mar 2021 21:20:10 GMT
Subject: <Swing Dev> RFR: 6251901: BasicTextUI: installDefaults method
 are contrary to the documentation
In-Reply-To: <dE7YUKA0hRMr6EaOCMtrpQGW0rO6jmNcHoBsqSaEZBE=.eef2fd80-cbf8-44bd-9803-853d5e65f59e@github.com>
References: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
 <dE7YUKA0hRMr6EaOCMtrpQGW0rO6jmNcHoBsqSaEZBE=.eef2fd80-cbf8-44bd-9803-853d5e65f59e@github.com>
Message-ID: <8gtdMKbn2YxGO4eAhGUBk8cdsoCU1srL_sXE2fDziak=.d9d240f9-c7e8-4fd3-b1f3-d233971d8ddb@github.com>

On Tue, 9 Mar 2021 13:34:20 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> BasicTextUI: installDefaults javadoc specifies only font, foreground and background properties are set  if their current value is either null or a UIResource
>> and other properties are set if the current value is null
>> but in reality all properties such as font, foreground, background, caret color, selection color, selected text color, disabled text color, and border color are set if their current value is either null or a UIResource.
>> Fixed the javadoc to specify the same.
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 306:
> 
>> 304:      * Initializes component properties, such as font, foreground,
>> 305:      * background, caret color, selection color, selected text color,
>> 306:      * disabled text color, and border color.  All properties are set
> 
> This method is also affects a margin, but it is does not mentioned in the javadoc.

Does the list of properties listed in the javadoc have to be comprehensive? However, `margin` seems to be the only property omitted from the list.

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

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

From kizune at openjdk.java.net  Tue Mar  9 21:30:09 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 9 Mar 2021 21:30:09 GMT
Subject: <Swing Dev> RFR: 8262981: Create implementation for
 NSAccessibilitySlider protocol
In-Reply-To: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
References: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
Message-ID: <t13BqkCYG8qk0aLtw6azywTui3POwmMR_RtG4YJ7FwQ=.449b47de-456a-43b3-a936-021778920f73@github.com>

On Mon, 8 Mar 2021 12:51:56 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> Create implementation of NSAccessibilitySlider protocol https://developer.apple.com/documentation/appkit/nsaccessibilityslider
> 
> The implementation has the function performIncrement and performDecrement to increase/decrease the value of slider using the VoiceOver. To implement this functionality, I could think of  following two ways. I have chosen the first one here though it is more intrusive.
> 1. Make the AccessibleJSlider class implement the AccessibleAction interface. This makes AccessibleJSlider consistent with the AccessibleJSpinner class. It is more clear and the logic to increase/decrease Slider value can be changed easily. But this changes AccessibleJSlider class and will need a CSR.
> 2. Get the current Accessible Value from the component and  just increment/decrement it in SliderAccessibility.m  class itself and then set the current accessible value fro there only. This will not need any changes in AccessibleJSlider class, but this does not look correct way and I have not used this.
> 
> The changes can be easily tested by using a JSlider example, like the following example. VO should announce the correct the slider values. To change the slider values, use ctrl+opt+shift+down key to start interacting with the slider, then use ctrl+opt+up/down arrow keys to increment/decrement slider values.
> 
>       import javax.swing.JFrame;
>       import javax.swing.JSlider;
>       
>       public class JSliderDemo{
>           public static void main(String[] args) throws Exception {
>               JFrame jframe = new JFrame("JSlider Demo");
>               jframe.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>               jframe.add(new JSlider());
>       
>               jframe.setLocationRelativeTo(null);
>               jframe.pack();
>               jframe.setVisible(true);
>           }
>       }

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m line 59:

> 57:     [rolesMap setObject:@"RadiobuttonAccessibility" forKey:@"radiobutton"];
> 58:     [rolesMap setObject:@"CheckboxAccessibility" forKey:@"checkbox"];
> 59:     [rolesMap setObject:@"SliderAccessibility" forKey:@"slider"];

Shouldn't you also increase the rolesMap initial capacity?

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

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

From kizune at openjdk.java.net  Tue Mar  9 21:34:10 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 9 Mar 2021 21:34:10 GMT
Subject: <Swing Dev> RFR: 6251901: BasicTextUI: installDefaults method
 are contrary to the documentation
In-Reply-To: <EE8uM3qc_RvT_QTgU58rz2gS5sbcGnMAjPafdvJKb-A=.1b025eac-41de-4d9f-bdf4-25aae9da2662@github.com>
References: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
 <EE8uM3qc_RvT_QTgU58rz2gS5sbcGnMAjPafdvJKb-A=.1b025eac-41de-4d9f-bdf4-25aae9da2662@github.com>
Message-ID: <lH0jYR0piT-dQhKVP7isGZHOg6qQjviteXJimeioDzs=.f9024ec9-0947-44c3-9243-b4b6b046aa23@github.com>

On Tue, 9 Mar 2021 21:12:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> BasicTextUI: installDefaults javadoc specifies only font, foreground and background properties are set  if their current value is either null or a UIResource
>> and other properties are set if the current value is null
>> but in reality all properties such as font, foreground, background, caret color, selection color, selected text color, disabled text color, and border color are set if their current value is either null or a UIResource.
>> Fixed the javadoc to specify the same.
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 307:
> 
>> 305:      * background, caret color, selection color, selected text color,
>> 306:      * disabled text color, and border color.  All properties are set
>> 307:      * if their current value is either null or a UIResource.
> 
> Suggestion:
> 
>      * disabled text color, and border color.  Each property is set,
>      * if its current value is either null or a UIResource.
> 
> I think this conveys the behavior better. Each property is checked separately, independently from other properties.

I'm not an expert in English but i think comma after set is not needed.

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

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

From kizune at openjdk.java.net  Tue Mar  9 21:35:07 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 9 Mar 2021 21:35:07 GMT
Subject: <Swing Dev> RFR: 8263170: ComboBoxModel documentation refers to
 a nonexistant type
In-Reply-To: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>
References: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>
Message-ID: <TIWzcpNqfFx_D_mtfoAF3VBl-hMkFlJFLDGpslbZNRA=.2c5ee7c6-8e70-444e-9047-c59fb08b482d@github.com>

On Tue, 9 Mar 2021 04:10:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javadoc of ComboBoxModel incorrectly specifies "extends ListDataModel" but actually it extends ListModel and there is no such interface as ListDataModel. Rectified the anomaly.

Marked as reviewed by kizune (Reviewer).

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

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

From aivanov at openjdk.java.net  Tue Mar  9 21:54:09 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 9 Mar 2021 21:54:09 GMT
Subject: <Swing Dev> RFR: 6251901: BasicTextUI: installDefaults method
 are contrary to the documentation
In-Reply-To: <lH0jYR0piT-dQhKVP7isGZHOg6qQjviteXJimeioDzs=.f9024ec9-0947-44c3-9243-b4b6b046aa23@github.com>
References: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
 <EE8uM3qc_RvT_QTgU58rz2gS5sbcGnMAjPafdvJKb-A=.1b025eac-41de-4d9f-bdf4-25aae9da2662@github.com>
 <lH0jYR0piT-dQhKVP7isGZHOg6qQjviteXJimeioDzs=.f9024ec9-0947-44c3-9243-b4b6b046aa23@github.com>
Message-ID: <CWtXve5CpF4MVMyVUgCy115dlnT0njBtNl_1DTsHQ2k=.108b9c9e-c544-464e-b0c9-3341d4d4ef13@github.com>

On Tue, 9 Mar 2021 21:31:03 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> I'm not an expert in English but i think comma after set is not needed.

You're right, comma is not needed in this case. I updated my comment and removed the comma.

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

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

From serb at openjdk.java.net  Wed Mar 10 00:58:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 10 Mar 2021 00:58:06 GMT
Subject: <Swing Dev> RFR: 8182043: Access to Windows Large Icons
In-Reply-To: <Xj2xcoi5vCQg0gxZizxxEvomvz32LRd6DbBdwqOa1yA=.f677bea5-7cb5-4ce8-85e8-e53c63162bf2@github.com>
References: <e1blsXETihJeuQUW6-ERVupKC2uGEq56ZCnX0x3h-vA=.007de252-fc87-4e4c-9c6d-180e90f38e9a@github.com>
 <Xj2xcoi5vCQg0gxZizxxEvomvz32LRd6DbBdwqOa1yA=.f677bea5-7cb5-4ce8-85e8-e53c63162bf2@github.com>
Message-ID: <k14k-HWeBnOeJgnLPhjGYzBT4vg2lUeXebzd7c95ydo=.acc86f18-fab8-4d9d-bb45-22e72dea7fd9@github.com>

On Mon, 8 Mar 2021 13:23:00 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Fix updated after first round of review.
>
> Continuation of review at https://github.com/openjdk/jdk/pull/380

Just to continue the thread from the old review, did you have a chance to look at the possibility of loading all existed icons embedded in the file? It was discussed here:
https://github.com/openjdk/jdk/pull/380#issuecomment-702999573

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

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

From serb at openjdk.java.net  Wed Mar 10 01:01:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 10 Mar 2021 01:01:09 GMT
Subject: <Swing Dev> RFR: 8263170: ComboBoxModel documentation refers to
 a nonexistant type
In-Reply-To: <TIWzcpNqfFx_D_mtfoAF3VBl-hMkFlJFLDGpslbZNRA=.2c5ee7c6-8e70-444e-9047-c59fb08b482d@github.com>
References: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>
 <TIWzcpNqfFx_D_mtfoAF3VBl-hMkFlJFLDGpslbZNRA=.2c5ee7c6-8e70-444e-9047-c59fb08b482d@github.com>
Message-ID: <hc2jz0hTJ6FER7YHYZqatGX__nrg9ym0F3BpttFmDSo=.a281355c-3c7f-44b8-b390-2364466c50a4@github.com>

On Tue, 9 Mar 2021 21:32:08 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> javadoc of ComboBoxModel incorrectly specifies "extends ListDataModel" but actually it extends ListModel and there is no such interface as ListDataModel. Rectified the anomaly.
>
> Marked as reviewed by kizune (Reviewer).

I suggest always update the copyright.

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

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

From serb at openjdk.java.net  Wed Mar 10 01:03:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 10 Mar 2021 01:03:08 GMT
Subject: <Swing Dev> RFR: 8262981: Create implementation for
 NSAccessibilitySlider protocol
In-Reply-To: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
References: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
Message-ID: <3kHCT6j_xnm9mbA2jeP35p9rY4nxOD61PInSB9mglT8=.71c3b9df-0cc3-40f7-b339-15b382e36b6f@github.com>

On Mon, 8 Mar 2021 12:51:56 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> Create implementation of NSAccessibilitySlider protocol https://developer.apple.com/documentation/appkit/nsaccessibilityslider
> 
> The implementation has the function performIncrement and performDecrement to increase/decrease the value of slider using the VoiceOver. To implement this functionality, I could think of  following two ways. I have chosen the first one here though it is more intrusive.
> 1. Make the AccessibleJSlider class implement the AccessibleAction interface. This makes AccessibleJSlider consistent with the AccessibleJSpinner class. It is more clear and the logic to increase/decrease Slider value can be changed easily. But this changes AccessibleJSlider class and will need a CSR.
> 2. Get the current Accessible Value from the component and  just increment/decrement it in SliderAccessibility.m  class itself and then set the current accessible value fro there only. This will not need any changes in AccessibleJSlider class, but this does not look correct way and I have not used this.
> 
> The changes can be easily tested by using a JSlider example, like the following example. VO should announce the correct the slider values. To change the slider values, use ctrl+opt+shift+down key to start interacting with the slider, then use ctrl+opt+up/down arrow keys to increment/decrement slider values.
> 
>       import javax.swing.JFrame;
>       import javax.swing.JSlider;
>       
>       public class JSliderDemo{
>           public static void main(String[] args) throws Exception {
>               JFrame jframe = new JFrame("JSlider Demo");
>               jframe.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>               jframe.add(new JSlider());
>       
>               jframe.setLocationRelativeTo(null);
>               jframe.pack();
>               jframe.setVisible(true);
>           }
>       }

If you need a new functionality and CSR I wonder how it currently works on Windows and macOS, or it does not work?

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

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

From serb at openjdk.java.net  Wed Mar 10 01:43:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 10 Mar 2021 01:43:06 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge [v2]
In-Reply-To: <nci2NpmndUlC3aKzH0TmhqGAiniBoFSW3ueF1k7ryW0=.104864ab-186c-4a5d-b47e-347ad3265a20@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
 <T1QW3aeoxbygF0Kb0zKHjChMCoXRQvojX6fr_ds7lcA=.71a4065b-486b-4934-ac96-a2021c0865e5@github.com>
 <Rmb9h2DdsZl26XPdMFUPmD9qxM9RFF2IHCkFJDLsnj0=.af52b701-10cf-45e6-a766-33895f808a5e@github.com>
 <S0o-7c81rJxXU6M2AdBpskZJuGN5zqlAsRY1Ime0AgE=.e46a19cb-5dde-4c6e-b908-4d3d0bf69f40@github.com>
 <BXa7BAfnGWZ8uurRWn7fO0sICPO4MygopzHKjI4udL8=.849592c6-c398-4370-9ec6-53a3896a390a@github.com>
 <nci2NpmndUlC3aKzH0TmhqGAiniBoFSW3ueF1k7ryW0=.104864ab-186c-4a5d-b47e-347ad3265a20@github.com>
Message-ID: <8IiVqESA2inNmd8VD9dMWgBxSHXfBqd3RXfDMCVEjQI=.61290b1f-aa2b-4166-b8c0-6548b930b116@github.com>

On Tue, 9 Mar 2021 00:49:09 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Did you check via some a11y tool that the new code actually works?
>
> No, can you help?

I'll check.

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

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

From psadhukhan at openjdk.java.net  Wed Mar 10 04:27:28 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 10 Mar 2021 04:27:28 GMT
Subject: <Swing Dev> RFR: 8263170: ComboBoxModel documentation refers to
 a nonexistent type [v2]
In-Reply-To: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>
References: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>
Message-ID: <t6Z9lp5MPJvRatl5FuDMsePWA1PM2X093wHzPeCdRr0=.4edfd849-2dc9-4511-b39d-31d234a5b072@github.com>

> javadoc of ComboBoxModel incorrectly specifies "extends ListDataModel" but actually it extends ListModel and there is no such interface as ListDataModel. Rectified the anomaly.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Copyright change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2886/files
  - new: https://git.openjdk.java.net/jdk/pull/2886/files/68b4fbe6..87c89395

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

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

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

From psadhukhan at openjdk.java.net  Wed Mar 10 04:32:29 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 10 Mar 2021 04:32:29 GMT
Subject: <Swing Dev> RFR: 6251901: BasicTextUI: installDefaults method
 are contrary to the documentation [v2]
In-Reply-To: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
References: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
Message-ID: <75E9PBbMXciz6Iv8KtUCLxV-ZrNkH_ykTdupmcJ96l0=.29152987-b340-4156-b912-e97e2ca8b209@github.com>

> BasicTextUI: installDefaults javadoc specifies only font, foreground and background properties are set  if their current value is either null or a UIResource
> and other properties are set if the current value is null
> but in reality all properties such as font, foreground, background, caret color, selection color, selected text color, disabled text color, and border color are set if their current value is either null or a UIResource.
> Fixed the javadoc to specify the same.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  javadoc change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2888/files
  - new: https://git.openjdk.java.net/jdk/pull/2888/files/96ae8509..b27104e5

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

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

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

From psadhukhan at openjdk.java.net  Wed Mar 10 04:38:19 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 10 Mar 2021 04:38:19 GMT
Subject: <Swing Dev> RFR: 6251901: BasicTextUI: installDefaults method
 are contrary to the documentation [v3]
In-Reply-To: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
References: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
Message-ID: <J1Tg2KjfnkxA81I1mIaf11DTI7EfsQGtD6UiOnfWiy8=.8113c32b-a7e2-4d3a-a10e-8452cea1d9e8@github.com>

> BasicTextUI: installDefaults javadoc specifies only font, foreground and background properties are set  if their current value is either null or a UIResource
> and other properties are set if the current value is null
> but in reality all properties such as font, foreground, background, caret color, selection color, selected text color, disabled text color, and border color are set if their current value is either null or a UIResource.
> Fixed the javadoc to specify the same.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  copyright change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2888/files
  - new: https://git.openjdk.java.net/jdk/pull/2888/files/b27104e5..fad21b0d

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

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

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

From psadhukhan at openjdk.java.net  Wed Mar 10 04:38:20 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 10 Mar 2021 04:38:20 GMT
Subject: <Swing Dev> RFR: 6251901: BasicTextUI: installDefaults method
 are contrary to the documentation [v3]
In-Reply-To: <8gtdMKbn2YxGO4eAhGUBk8cdsoCU1srL_sXE2fDziak=.d9d240f9-c7e8-4fd3-b1f3-d233971d8ddb@github.com>
References: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
 <dE7YUKA0hRMr6EaOCMtrpQGW0rO6jmNcHoBsqSaEZBE=.eef2fd80-cbf8-44bd-9803-853d5e65f59e@github.com>
 <8gtdMKbn2YxGO4eAhGUBk8cdsoCU1srL_sXE2fDziak=.d9d240f9-c7e8-4fd3-b1f3-d233971d8ddb@github.com>
Message-ID: <GrN90atCD0hvQKLR2iBawDNAYLNmt0ea7A8MI__HZkU=.3d2f0bb3-8ee9-48b4-9cfa-5edf8a1efa32@github.com>

On Tue, 9 Mar 2021 21:17:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 306:
>> 
>>> 304:      * Initializes component properties, such as font, foreground,
>>> 305:      * background, caret color, selection color, selected text color,
>>> 306:      * disabled text color, and border color.  All properties are set
>> 
>> This method is also affects a margin, but it is does not mentioned in the javadoc.
>
> Does the list of properties listed in the javadoc have to be comprehensive? However, `margin` seems to be the only property omitted from the list.

I have added margin too,

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

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

From kizune at openjdk.java.net  Wed Mar 10 05:39:06 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 10 Mar 2021 05:39:06 GMT
Subject: <Swing Dev> RFR: 8182043: Access to Windows Large Icons
In-Reply-To: <k14k-HWeBnOeJgnLPhjGYzBT4vg2lUeXebzd7c95ydo=.acc86f18-fab8-4d9d-bb45-22e72dea7fd9@github.com>
References: <e1blsXETihJeuQUW6-ERVupKC2uGEq56ZCnX0x3h-vA=.007de252-fc87-4e4c-9c6d-180e90f38e9a@github.com>
 <Xj2xcoi5vCQg0gxZizxxEvomvz32LRd6DbBdwqOa1yA=.f677bea5-7cb5-4ce8-85e8-e53c63162bf2@github.com>
 <k14k-HWeBnOeJgnLPhjGYzBT4vg2lUeXebzd7c95ydo=.acc86f18-fab8-4d9d-bb45-22e72dea7fd9@github.com>
Message-ID: <nDqbq827JWyJKW1wODZOgFD7V5_lhNXnqM0Ed-RS9MI=.02fe6931-6c30-4ad9-a577-20768bcf1b69@github.com>

On Wed, 10 Mar 2021 00:55:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Continuation of review at https://github.com/openjdk/jdk/pull/380
>
> Just to continue the thread from the old review, did you have a chance to look at the possibility of loading all existed icons embedded in the file? It was discussed here:
> https://github.com/openjdk/jdk/pull/380#issuecomment-702999573

> Just to continue the thread from the old review, did you have a chance to look at the possibility of loading all existed icons embedded in the file? It was discussed here:
> [#380 (comment)](https://github.com/openjdk/jdk/pull/380#issuecomment-702999573)

Yes, i did. There were 3 shortcomings: 1. It works in about 10% of the cases in all other cases it reports only one icon available (32x32) even if there are other resolution icons. 2. It is quite  slow, especially on network drives. 3. Does not work at all in files that are within AppData\Roaming folder - returning list is just empty.

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

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

From psadhukhan at openjdk.java.net  Wed Mar 10 06:42:06 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 10 Mar 2021 06:42:06 GMT
Subject: <Swing Dev> Integrated: 8263170: ComboBoxModel documentation refers
 to a nonexistent type
In-Reply-To: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>
References: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>
Message-ID: <RDHQ6tZUQKC7EtNWxNirVII_VWsjYZekfyiZavWCn20=.6421a3c1-b870-4ee6-b148-50e81d99a68c@github.com>

On Tue, 9 Mar 2021 04:10:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javadoc of ComboBoxModel incorrectly specifies "extends ListDataModel" but actually it extends ListModel and there is no such interface as ListDataModel. Rectified the anomaly.

This pull request has now been integrated.

Changeset: 3fe8a466
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3fe8a466
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8263170: ComboBoxModel documentation refers to a nonexistent type

Reviewed-by: azvegint, trebari, pbansal, aivanov, kizune

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

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

From azvegint at openjdk.java.net  Wed Mar 10 10:44:07 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 10 Mar 2021 10:44:07 GMT
Subject: <Swing Dev> RFR: 6251901: BasicTextUI: installDefaults method
 are contrary to the documentation [v3]
In-Reply-To: <J1Tg2KjfnkxA81I1mIaf11DTI7EfsQGtD6UiOnfWiy8=.8113c32b-a7e2-4d3a-a10e-8452cea1d9e8@github.com>
References: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
 <J1Tg2KjfnkxA81I1mIaf11DTI7EfsQGtD6UiOnfWiy8=.8113c32b-a7e2-4d3a-a10e-8452cea1d9e8@github.com>
Message-ID: <G6iGxyupLaQ5tpcMumw9j4_PqTnIve2eFnWRLZAo9Tc=.898eb7cd-28ff-4aba-936e-638b93dc94d2@github.com>

On Wed, 10 Mar 2021 04:38:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> BasicTextUI: installDefaults javadoc specifies only font, foreground and background properties are set  if their current value is either null or a UIResource
>> and other properties are set if the current value is null
>> but in reality all properties such as font, foreground, background, caret color, selection color, selected text color, disabled text color, and border color are set if their current value is either null or a UIResource.
>> Fixed the javadoc to specify the same.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright change

Marked as reviewed by azvegint (Reviewer).

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

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

From kizune at openjdk.java.net  Wed Mar 10 11:08:08 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 10 Mar 2021 11:08:08 GMT
Subject: <Swing Dev> RFR: 6251901: BasicTextUI: installDefaults method
 are contrary to the documentation [v3]
In-Reply-To: <J1Tg2KjfnkxA81I1mIaf11DTI7EfsQGtD6UiOnfWiy8=.8113c32b-a7e2-4d3a-a10e-8452cea1d9e8@github.com>
References: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
 <J1Tg2KjfnkxA81I1mIaf11DTI7EfsQGtD6UiOnfWiy8=.8113c32b-a7e2-4d3a-a10e-8452cea1d9e8@github.com>
Message-ID: <yVxqB3I85elL7P6r_VJPiFIJ-ywo7uPBLKADF-9ELlM=.709aae6a-c5a1-4424-897d-d6e7047a01c8@github.com>

On Wed, 10 Mar 2021 04:38:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> BasicTextUI: installDefaults javadoc specifies only font, foreground and background properties are set  if their current value is either null or a UIResource
>> and other properties are set if the current value is null
>> but in reality all properties such as font, foreground, background, caret color, selection color, selected text color, disabled text color, and border color are set if their current value is either null or a UIResource.
>> Fixed the javadoc to specify the same.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright change

Marked as reviewed by kizune (Reviewer).

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

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

From aivanov at openjdk.java.net  Wed Mar 10 11:53:09 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 10 Mar 2021 11:53:09 GMT
Subject: <Swing Dev> RFR: 6251901: BasicTextUI: installDefaults method
 are contrary to the documentation [v3]
In-Reply-To: <J1Tg2KjfnkxA81I1mIaf11DTI7EfsQGtD6UiOnfWiy8=.8113c32b-a7e2-4d3a-a10e-8452cea1d9e8@github.com>
References: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
 <J1Tg2KjfnkxA81I1mIaf11DTI7EfsQGtD6UiOnfWiy8=.8113c32b-a7e2-4d3a-a10e-8452cea1d9e8@github.com>
Message-ID: <BbrnZVmS7isVL0HHWfGXJvr7gHKLTDedDQUq-hQPT8E=.18d84c2a-4edb-4462-8161-da253dd908f2@github.com>

On Wed, 10 Mar 2021 04:38:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> BasicTextUI: installDefaults javadoc specifies only font, foreground and background properties are set  if their current value is either null or a UIResource
>> and other properties are set if the current value is null
>> but in reality all properties such as font, foreground, background, caret color, selection color, selected text color, disabled text color, and border color are set if their current value is either null or a UIResource.
>> Fixed the javadoc to specify the same.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright change

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 306:

> 304:      * Initializes component properties, such as font, foreground,
> 305:      * background, caret color, selection color, selected text color,
> 306:      * disabled text color, border and margin. Each property is set

Suggestion:

     * disabled text color, border, and margin. Each property is set
I suggest keeping the command before ?and? as it was before.

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

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

From psadhukhan at openjdk.java.net  Wed Mar 10 12:16:09 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 10 Mar 2021 12:16:09 GMT
Subject: <Swing Dev> RFR: 6251901: BasicTextUI: installDefaults method
 are contrary to the documentation [v3]
In-Reply-To: <BbrnZVmS7isVL0HHWfGXJvr7gHKLTDedDQUq-hQPT8E=.18d84c2a-4edb-4462-8161-da253dd908f2@github.com>
References: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
 <J1Tg2KjfnkxA81I1mIaf11DTI7EfsQGtD6UiOnfWiy8=.8113c32b-a7e2-4d3a-a10e-8452cea1d9e8@github.com>
 <BbrnZVmS7isVL0HHWfGXJvr7gHKLTDedDQUq-hQPT8E=.18d84c2a-4edb-4462-8161-da253dd908f2@github.com>
Message-ID: <lOZLI3DnVyQzRED2PZLb7fW9kLks8juy91GYWY59-1k=.1dc3dd78-4033-4a63-92f8-eefff587c497@github.com>

On Wed, 10 Mar 2021 11:49:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright change
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 306:
> 
>> 304:      * Initializes component properties, such as font, foreground,
>> 305:      * background, caret color, selection color, selected text color,
>> 306:      * disabled text color, border and margin. Each property is set
> 
> Suggestion:
> 
>      * disabled text color, border, and margin. Each property is set
> I suggest keeping the command before ?and? as it was before.

I think these are nouns and as per I know, we shouldn't place comma before "and" when we are simply listing the items.

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

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

From aivanov at openjdk.java.net  Wed Mar 10 12:22:09 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 10 Mar 2021 12:22:09 GMT
Subject: <Swing Dev> RFR: 6251901: BasicTextUI: installDefaults method
 are contrary to the documentation [v3]
In-Reply-To: <lOZLI3DnVyQzRED2PZLb7fW9kLks8juy91GYWY59-1k=.1dc3dd78-4033-4a63-92f8-eefff587c497@github.com>
References: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
 <J1Tg2KjfnkxA81I1mIaf11DTI7EfsQGtD6UiOnfWiy8=.8113c32b-a7e2-4d3a-a10e-8452cea1d9e8@github.com>
 <BbrnZVmS7isVL0HHWfGXJvr7gHKLTDedDQUq-hQPT8E=.18d84c2a-4edb-4462-8161-da253dd908f2@github.com>
 <lOZLI3DnVyQzRED2PZLb7fW9kLks8juy91GYWY59-1k=.1dc3dd78-4033-4a63-92f8-eefff587c497@github.com>
Message-ID: <k6mV8Y4BUKnmQVY7DLaRqEhlmZQm6Lbezo85sX2av38=.80b27d92-e5ec-42d5-a6f0-dd44d1c2e4a6@github.com>

On Wed, 10 Mar 2021 12:13:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I think these are nouns and as per I know, we shouldn't place comma before "and" when we are simply listing the items.

This is called [Oxford Comma](https://www.grammarly.com/blog/what-is-the-oxford-comma-and-why-do-people-care-so-much-about-it/). It is quite standard in American English and javadoc uses American English. The comma was present before therefore I suggest following the style and add the now missing comma.

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

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

From psadhukhan at openjdk.java.net  Wed Mar 10 12:28:18 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 10 Mar 2021 12:28:18 GMT
Subject: <Swing Dev> RFR: 6251901: BasicTextUI: installDefaults method
 are contrary to the documentation [v4]
In-Reply-To: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
References: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
Message-ID: <gBWIZ22YcE7MH-L2_H2ELfehU0FSsAjAwfWfBXluH_w=.4d0b0399-5261-4a5c-8977-919572432ce9@github.com>

> BasicTextUI: installDefaults javadoc specifies only font, foreground and background properties are set  if their current value is either null or a UIResource
> and other properties are set if the current value is null
> but in reality all properties such as font, foreground, background, caret color, selection color, selected text color, disabled text color, and border color are set if their current value is either null or a UIResource.
> Fixed the javadoc to specify the same.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Add Oxford Comma

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2888/files
  - new: https://git.openjdk.java.net/jdk/pull/2888/files/fad21b0d..fb7aa827

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

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

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

From psadhukhan at openjdk.java.net  Wed Mar 10 12:28:19 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 10 Mar 2021 12:28:19 GMT
Subject: <Swing Dev> RFR: 6251901: BasicTextUI: installDefaults method
 are contrary to the documentation [v3]
In-Reply-To: <k6mV8Y4BUKnmQVY7DLaRqEhlmZQm6Lbezo85sX2av38=.80b27d92-e5ec-42d5-a6f0-dd44d1c2e4a6@github.com>
References: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
 <J1Tg2KjfnkxA81I1mIaf11DTI7EfsQGtD6UiOnfWiy8=.8113c32b-a7e2-4d3a-a10e-8452cea1d9e8@github.com>
 <BbrnZVmS7isVL0HHWfGXJvr7gHKLTDedDQUq-hQPT8E=.18d84c2a-4edb-4462-8161-da253dd908f2@github.com>
 <lOZLI3DnVyQzRED2PZLb7fW9kLks8juy91GYWY59-1k=.1dc3dd78-4033-4a63-92f8-eefff587c497@github.com>
 <k6mV8Y4BUKnmQVY7DLaRqEhlmZQm6Lbezo85sX2av38=.80b27d92-e5ec-42d5-a6f0-dd44d1c2e4a6@github.com>
Message-ID: <fZIrgMWxB9Ahz4jS9tUDoByCo-Os4zL_FH9uekR9kjA=.831bf674-ff51-4021-8e6c-6a7d31060416@github.com>

On Wed, 10 Mar 2021 12:19:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I think these are nouns and as per I know, we shouldn't place comma before "and" when we are simply listing the items.
>
>> I think these are nouns and as per I know, we shouldn't place comma before "and" when we are simply listing the items.
> 
> This is called [Oxford Comma](https://www.grammarly.com/blog/what-is-the-oxford-comma-and-why-do-people-care-so-much-about-it/). It is quite standard in American English and javadoc uses American English. The comma was present before therefore I suggest following the style and add the now missing comma.

ok

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

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

From aivanov at openjdk.java.net  Wed Mar 10 12:33:07 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 10 Mar 2021 12:33:07 GMT
Subject: <Swing Dev> RFR: 6251901: BasicTextUI: installDefaults method
 are contrary to the documentation [v4]
In-Reply-To: <gBWIZ22YcE7MH-L2_H2ELfehU0FSsAjAwfWfBXluH_w=.4d0b0399-5261-4a5c-8977-919572432ce9@github.com>
References: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
 <gBWIZ22YcE7MH-L2_H2ELfehU0FSsAjAwfWfBXluH_w=.4d0b0399-5261-4a5c-8977-919572432ce9@github.com>
Message-ID: <V4cn0vzVBFSDH6Fz9mPYpxsBh0s90r-5YlrB1PWfayo=.2ee92d3f-7fe4-4978-bd8e-b8a8a7d85e29@github.com>

On Wed, 10 Mar 2021 12:28:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> BasicTextUI: installDefaults javadoc specifies only font, foreground and background properties are set  if their current value is either null or a UIResource
>> and other properties are set if the current value is null
>> but in reality all properties such as font, foreground, background, caret color, selection color, selected text color, disabled text color, and border color are set if their current value is either null or a UIResource.
>> Fixed the javadoc to specify the same.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Oxford Comma

Marked as reviewed by aivanov (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Wed Mar 10 12:51:08 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 10 Mar 2021 12:51:08 GMT
Subject: <Swing Dev> Integrated: 6251901: BasicTextUI: installDefaults
 method are contrary to the documentation
In-Reply-To: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
References: <F0Zu1H0HgvON2sSVHLfLM-96xKY7o53f2uKAtJmH3OE=.64967472-9144-4d99-a707-152bb4f4e2ff@github.com>
Message-ID: <6-CsTjt25AQV6rkK8yKSrTERqWTlricS3nq3wSAXq8c=.c48512d7-e4d9-41a8-ac75-05030305afa9@github.com>

On Tue, 9 Mar 2021 08:09:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> BasicTextUI: installDefaults javadoc specifies only font, foreground and background properties are set  if their current value is either null or a UIResource
> and other properties are set if the current value is null
> but in reality all properties such as font, foreground, background, caret color, selection color, selected text color, disabled text color, and border color are set if their current value is either null or a UIResource.
> Fixed the javadoc to specify the same.

This pull request has now been integrated.

Changeset: c0542ed8
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c0542ed8
Stats:     4 lines in 1 file changed: 0 ins; 2 del; 2 mod

6251901: BasicTextUI: installDefaults method are contrary to the documentation

Reviewed-by: azvegint, kizune, aivanov

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

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

From kizune at openjdk.java.net  Wed Mar 10 13:35:08 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 10 Mar 2021 13:35:08 GMT
Subject: <Swing Dev> RFR: 8262981: Create implementation for
 NSAccessibilitySlider protocol
In-Reply-To: <3kHCT6j_xnm9mbA2jeP35p9rY4nxOD61PInSB9mglT8=.71c3b9df-0cc3-40f7-b339-15b382e36b6f@github.com>
References: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
 <3kHCT6j_xnm9mbA2jeP35p9rY4nxOD61PInSB9mglT8=.71c3b9df-0cc3-40f7-b339-15b382e36b6f@github.com>
Message-ID: <WaDY3XBH6a6nPencpEbkyZjTnX5iqzxX9wZZ5eKI6KI=.a32e0717-0736-417c-84c0-bbb858bc2e35@github.com>

On Wed, 10 Mar 2021 01:00:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> If you need a new functionality and CSR I wonder how it currently works on Windows and macOS, or it does not work?

Haven't tested this functionality on Windows, on macOS with current JDK it does not work at all. After entering the JSlider interaction mode VoiceOver does not announce the a11y shortcuts and the attempt to invoke said shortcuts do nothing.

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

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

From pbansal at openjdk.java.net  Wed Mar 10 13:55:07 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 10 Mar 2021 13:55:07 GMT
Subject: <Swing Dev> RFR: 8262981: Create implementation for
 NSAccessibilitySlider protocol
In-Reply-To: <WaDY3XBH6a6nPencpEbkyZjTnX5iqzxX9wZZ5eKI6KI=.a32e0717-0736-417c-84c0-bbb858bc2e35@github.com>
References: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
 <3kHCT6j_xnm9mbA2jeP35p9rY4nxOD61PInSB9mglT8=.71c3b9df-0cc3-40f7-b339-15b382e36b6f@github.com>
 <WaDY3XBH6a6nPencpEbkyZjTnX5iqzxX9wZZ5eKI6KI=.a32e0717-0736-417c-84c0-bbb858bc2e35@github.com>
Message-ID: <cT1qePiXMvURZ_3c2AJmII18NuajOWOzIHAZn17OSxs=.ea2baf8f-e3a3-4e75-8ff1-46b46105086e@github.com>

On Wed, 10 Mar 2021 13:32:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> If you need a new functionality and CSR I wonder how it currently works on Windows and macOS, or it does not work?

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

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

From pbansal at openjdk.java.net  Wed Mar 10 14:50:11 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 10 Mar 2021 14:50:11 GMT
Subject: <Swing Dev> RFR: 8262981: Create implementation for
 NSAccessibilitySlider protocol
In-Reply-To: <t13BqkCYG8qk0aLtw6azywTui3POwmMR_RtG4YJ7FwQ=.449b47de-456a-43b3-a936-021778920f73@github.com>
References: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
 <t13BqkCYG8qk0aLtw6azywTui3POwmMR_RtG4YJ7FwQ=.449b47de-456a-43b3-a936-021778920f73@github.com>
Message-ID: <zXunuRsLWTTAkHbKdNZtjWnIxUIBIfJG0Uaf43hwyMQ=.8beb5dd7-122b-45ef-8618-b8aa89137353@github.com>

On Tue, 9 Mar 2021 21:27:39 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Shouldn't you also increase the rolesMap initial capacity?

ok, I will do that in next commit.

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

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

From pbansal at openjdk.java.net  Wed Mar 10 14:50:08 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 10 Mar 2021 14:50:08 GMT
Subject: <Swing Dev> RFR: 8262981: Create implementation for
 NSAccessibilitySlider protocol
In-Reply-To: <WaDY3XBH6a6nPencpEbkyZjTnX5iqzxX9wZZ5eKI6KI=.a32e0717-0736-417c-84c0-bbb858bc2e35@github.com>
References: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
 <3kHCT6j_xnm9mbA2jeP35p9rY4nxOD61PInSB9mglT8=.71c3b9df-0cc3-40f7-b339-15b382e36b6f@github.com>
 <WaDY3XBH6a6nPencpEbkyZjTnX5iqzxX9wZZ5eKI6KI=.a32e0717-0736-417c-84c0-bbb858bc2e35@github.com>
Message-ID: <4SZRIR695DBooSWt-1aatGx-CKPy6EwuRpXS29A8wro=.4ba37fe2-6017-482f-83c4-33d7a11fc320@github.com>

On Wed, 10 Mar 2021 13:32:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> > If you need a new functionality and CSR I wonder how it currently works on Windows and macOS, or it does not work?
> 
> Haven't tested this functionality on Windows, on macOS with current JDK it does not work at all. After entering the JSlider interaction mode VoiceOver does not announce the a11y shortcuts and the attempt to invoke said shortcuts do nothing.

Yes, as Alex pointed out, it does not work on MacOS. The VO only announces the value and user can not modify the slider values using VO shortcut keys.

I saw the windows code and I did not see anything where the current value of a component is being set. I tested this by running JAWS as well. When a JSlider is in focus, JAWS announces the slider values and then says "To increase or decrease, use the arrow keys". The keys are being handled by JAVA only and JAWS is not doing any part in it. To verify this, I commented the code to handle keys events in Java and slider value does not change. So looks like this does not work on Windows as well.

If these changes are too intrusive, I can go with the second approach of getting and setting the current values of slider in performincrement/performdecrement functions in SliderAccessibility.m. I am not sure if this will be correct approach, but it will be less intrusive and will not need a CSR.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Mar 10 18:12:08 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 10 Mar 2021 18:12:08 GMT
Subject: <Swing Dev> RFR: 8263170: ComboBoxModel documentation refers to
 a nonexistent type [v2]
In-Reply-To: <hc2jz0hTJ6FER7YHYZqatGX__nrg9ym0F3BpttFmDSo=.a281355c-3c7f-44b8-b390-2364466c50a4@github.com>
References: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>
 <TIWzcpNqfFx_D_mtfoAF3VBl-hMkFlJFLDGpslbZNRA=.2c5ee7c6-8e70-444e-9047-c59fb08b482d@github.com>
 <hc2jz0hTJ6FER7YHYZqatGX__nrg9ym0F3BpttFmDSo=.a281355c-3c7f-44b8-b390-2364466c50a4@github.com>
Message-ID: <LV2pzPlofJLKsjWAWxUZ3Jd4xgw9nv2923mMaWinbng=.e3db8835-ab95-478d-a39e-ad95e26c386b@github.com>

On Wed, 10 Mar 2021 00:58:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Marked as reviewed by kizune (Reviewer).
>
> I suggest always update the copyright.

There is one more occurrence of `ListDataModel` in JDK code - https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/ListModel.java#L34
Perhaps it's worth to fix it too.

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

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

From aivanov at openjdk.java.net  Wed Mar 10 21:01:14 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 10 Mar 2021 21:01:14 GMT
Subject: <Swing Dev> RFR: 8182043: Access to Windows Large Icons
In-Reply-To: <e1blsXETihJeuQUW6-ERVupKC2uGEq56ZCnX0x3h-vA=.007de252-fc87-4e4c-9c6d-180e90f38e9a@github.com>
References: <e1blsXETihJeuQUW6-ERVupKC2uGEq56ZCnX0x3h-vA=.007de252-fc87-4e4c-9c6d-180e90f38e9a@github.com>
Message-ID: <t5ysQOmFRTcCh3mbaeMa0YICTaquTspXV-9XyZd2rfc=.0dd1be0c-1e4c-412a-9530-601ee70cbebf@github.com>

On Mon, 8 Mar 2021 13:22:07 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Fix updated after first round of review.

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1044:

> 1042:                         new BufferedImage(iconSize, iconSize, BufferedImage.TYPE_INT_ARGB);
> 1043:                 img.setRGB(0, 0, iconSize, iconSize, iconBits, 0, iconSize);
> 1044:                 return img;

There are cases where the size of the buffered image is different from the requested size. It could affect the layout because it breaks the assumption that the returned image has the requested size but it may be larger. (Or is it no longer possible?) I think it should be wrapped into `MultiResolutionIconImage` in this case.

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1114:

> 1112:                                     bothIcons.put(getLargeIcon? SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2);
> 1113:                                     newIcon = new MultiResolutionIconImage(getLargeIcon ? LARGE_ICON_SIZE
> 1114:                                             : SMALL_ICON_SIZE, bothIcons);

I still propose to refactor this code to make it clearer. The code always returns two icons: _small + large_ or _large + small_ ? combined in `MultiResolutionIconImage`.

You can get `smallIcon` and `largeIcon` and then wrap them into `MultiResolutionIconImage` in the correct order and store each icon in the cache.

My opinion hasn't changed here.

I still think there's not much value in getting smaller icon size in addition to larger one. Or does it provide an alternative image for the case where the system scaling is 200% and the window is moved to a monitor with scaling of 100%?

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1195:

> 1193:      */
> 1194:     static Image getShell32Icon(int iconID, int size) {
> 1195:         boolean useVGAColors = true; // Will be ignored on XP and later

I cannot see where `useVGAColors` is used. Since the supported OS are later than XP, it can be removed, can't it?

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

> 981:                 size = 16;
> 982:             }
> 983:             hres = pIcon->Extract(szBuf, index, &hIcon, NULL, (16 << 16) + size);

Suggestion:

            hres = pIcon->Extract(szBuf, index, &hIcon, NULL, size);
Now you request only one icon.

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 64:

> 62:             }
> 63: 
> 64:             if (icon.getIconWidth() != size) {

Does it make sense to check that the icon is a multi-resolution image with the expected sizes?
We know for sure `explorer.exe` contains the entire set of icons.

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 264:

> 262:     * <p>
> 263:     * The default implementation gets information from the
> 264:     * <code>ShellFolder</code> class. Whenever possible, the icon

Do we continue using `<code>` elements? I thought that {@code} is the preferred way to markup class names.

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1112:

> 1110:                                     Map<Integer, Image> bothIcons = new HashMap<>(2);
> 1111:                                     bothIcons.put(getLargeIcon? LARGE_ICON_SIZE : SMALL_ICON_SIZE, newIcon);
> 1112:                                     bothIcons.put(getLargeIcon? SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2);

Suggestion:

                                    bothIcons.put(getLargeIcon ? LARGE_ICON_SIZE : SMALL_ICON_SIZE, newIcon);
                                    bothIcons.put(getLargeIcon ? SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2);

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1146:

> 1144:             }
> 1145:             Map<Integer, Image> multiResolutionIcon = new HashMap<>();
> 1146:             int start = size > MAX_QUALITY_ICON ? ICON_RESOLUTIONS.length - 1 : 0;

Does it make sense to always start at zero?
The icons of smaller size will never be used, will they?
Thus it's safe to start at the index which corresponds to the requested size if `size` matches, or the index such as `ICON_RESOLUTIONS[index] < size && ICON_RESOLUTIONS[index + 1] > size`.

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1149:

> 1147:             int increment = size > MAX_QUALITY_ICON ? -1 : 1;
> 1148:             int end = size > MAX_QUALITY_ICON ? -1 : ICON_RESOLUTIONS.length;
> 1149:             for (int i = start; i != end; i+=increment) {

Suggestion:

            for (int i = start; i != end; i += increment) {

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1422:

> 1420:             int w = (int) width;
> 1421:             int retindex = 0;
> 1422:             for (Integer i: resolutionVariants.keySet()) {

Suggestion:

            for (Integer i : resolutionVariants.keySet()) {

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

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

From serb at openjdk.java.net  Wed Mar 10 23:12:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 10 Mar 2021 23:12:09 GMT
Subject: <Swing Dev> RFR: 8262981: Create implementation for
 NSAccessibilitySlider protocol
In-Reply-To: <4SZRIR695DBooSWt-1aatGx-CKPy6EwuRpXS29A8wro=.4ba37fe2-6017-482f-83c4-33d7a11fc320@github.com>
References: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
 <3kHCT6j_xnm9mbA2jeP35p9rY4nxOD61PInSB9mglT8=.71c3b9df-0cc3-40f7-b339-15b382e36b6f@github.com>
 <WaDY3XBH6a6nPencpEbkyZjTnX5iqzxX9wZZ5eKI6KI=.a32e0717-0736-417c-84c0-bbb858bc2e35@github.com>
 <4SZRIR695DBooSWt-1aatGx-CKPy6EwuRpXS29A8wro=.4ba37fe2-6017-482f-83c4-33d7a11fc320@github.com>
Message-ID: <B0hF7cV-7O7pclnhmX7C4Biw20C5CLtIM11C6z5Tin0=.f06fa7ce-9049-454e-80f8-36935f3e0301@github.com>

On Wed, 10 Mar 2021 14:47:02 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>>> If you need a new functionality and CSR I wonder how it currently works on Windows and macOS, or it does not work?
>> 
>> Haven't tested this functionality on Windows, on macOS with current JDK it does not work at all. After entering the JSlider interaction mode VoiceOver does not announce the a11y shortcuts and the attempt to invoke said shortcuts do nothing.
>
>> > If you need a new functionality and CSR I wonder how it currently works on Windows and macOS, or it does not work?
>> 
>> Haven't tested this functionality on Windows, on macOS with current JDK it does not work at all. After entering the JSlider interaction mode VoiceOver does not announce the a11y shortcuts and the attempt to invoke said shortcuts do nothing.
> 
> Yes, as Alex pointed out, it does not work on MacOS. The VO only announces the value and user can not modify the slider values using VO shortcut keys.
> 
> I saw the windows code and I did not see anything where the current value of a component is being set. I tested this by running JAWS as well. When a JSlider is in focus, JAWS announces the slider values and then says "To increase or decrease, use the arrow keys". The keys are being handled by JAVA only and JAWS is not doing any part in it. To verify this, I commented the code to handle keys events in Java and slider value does not change. So looks like this does not work on Windows as well.
> 
> If these changes are too intrusive, I can go with the second approach of getting and setting the current values of slider in performincrement/performdecrement functions in SliderAccessibility.m. I am not sure if this will be correct approach, but it will be less intrusive and will not need a CSR.

If it does not work on Windows then I suggest checking that the new functionality requested via CSR will help it as well.

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

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

From kizune at openjdk.java.net  Thu Mar 11 01:47:07 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 11 Mar 2021 01:47:07 GMT
Subject: <Swing Dev> RFR: 8262981: Create implementation for
 NSAccessibilitySlider protocol
In-Reply-To: <4SZRIR695DBooSWt-1aatGx-CKPy6EwuRpXS29A8wro=.4ba37fe2-6017-482f-83c4-33d7a11fc320@github.com>
References: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
 <3kHCT6j_xnm9mbA2jeP35p9rY4nxOD61PInSB9mglT8=.71c3b9df-0cc3-40f7-b339-15b382e36b6f@github.com>
 <WaDY3XBH6a6nPencpEbkyZjTnX5iqzxX9wZZ5eKI6KI=.a32e0717-0736-417c-84c0-bbb858bc2e35@github.com>
 <4SZRIR695DBooSWt-1aatGx-CKPy6EwuRpXS29A8wro=.4ba37fe2-6017-482f-83c4-33d7a11fc320@github.com>
Message-ID: <LVG1rOozDM-FkppLSoeu-s47oUgYELAyOKpoJqBJQjc=.c765b3ed-6ffd-46ad-81f0-f976a2f0e332@github.com>

On Wed, 10 Mar 2021 14:47:02 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> If these changes are too intrusive, I can go with the second approach of getting and setting the current values of slider in performincrement/performdecrement functions in SliderAccessibility.m. I am not sure if this will be correct approach, but it will be less intrusive and will not need a CSR.

I would suggest to fix it properly by filing CSR for the functional change. The idea of new implementation is not only to make it compatible with the new Apple API, but also to make it cleaner, more consistent and easier to support in the future.

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

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

From psadhukhan at openjdk.java.net  Thu Mar 11 04:00:10 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 11 Mar 2021 04:00:10 GMT
Subject: <Swing Dev> RFR: 8263170: ComboBoxModel documentation refers to
 a nonexistent type [v2]
In-Reply-To: <LV2pzPlofJLKsjWAWxUZ3Jd4xgw9nv2923mMaWinbng=.e3db8835-ab95-478d-a39e-ad95e26c386b@github.com>
References: <Voouans-1AgwTkGyFiR4_QQmQNHaF1Yub8oM7EQINqY=.404515fe-0147-43a7-8c60-bb7adacacd44@github.com>
 <TIWzcpNqfFx_D_mtfoAF3VBl-hMkFlJFLDGpslbZNRA=.2c5ee7c6-8e70-444e-9047-c59fb08b482d@github.com>
 <hc2jz0hTJ6FER7YHYZqatGX__nrg9ym0F3BpttFmDSo=.a281355c-3c7f-44b8-b390-2364466c50a4@github.com>
 <LV2pzPlofJLKsjWAWxUZ3Jd4xgw9nv2923mMaWinbng=.e3db8835-ab95-478d-a39e-ad95e26c386b@github.com>
Message-ID: <Vv_TeL4uZ1ZCwHx5c0MWvYt6KZbDJDwOK49ILwrRK4U=.ced0d0d2-a3d8-49f8-a7bb-819ca425fb8b@github.com>

On Wed, 10 Mar 2021 18:09:37 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 
> 
> There is one more occurrence of `ListDataModel` in JDK code - https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/ListModel.java#L34
> Perhaps it's worth to fix it too.

ok. will take a look.

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

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

From psadhukhan at openjdk.java.net  Thu Mar 11 04:37:17 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 11 Mar 2021 04:37:17 GMT
Subject: <Swing Dev> RFR: 8263410: ListModel javadoc refers to non-existent
 interface
Message-ID: <N52F1WlX1hSNzOqAgwI10E4RTuaNE-vVGjWU_JIC040=.3e52da2f-d4a7-488c-bac4-8055971275cd@github.com>

ListModel class javadoc refers to ListDataModel interface but there is no ListDataModel interface. Rectified the anomaly.

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

Commit messages:
 - 8263410: ListModel javadoc refers to non-existent interface

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

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

From psadhukhan at openjdk.java.net  Thu Mar 11 04:40:25 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 11 Mar 2021 04:40:25 GMT
Subject: <Swing Dev> RFR: 8263410: ListModel javadoc refers to
 non-existent interface [v2]
In-Reply-To: <N52F1WlX1hSNzOqAgwI10E4RTuaNE-vVGjWU_JIC040=.3e52da2f-d4a7-488c-bac4-8055971275cd@github.com>
References: <N52F1WlX1hSNzOqAgwI10E4RTuaNE-vVGjWU_JIC040=.3e52da2f-d4a7-488c-bac4-8055971275cd@github.com>
Message-ID: <5tteNI8tzgKO2jGYeg5bH07UAb6e5O317G-OmpTV1bc=.4d517d4a-2f86-46f8-9291-872cf7d67d25@github.com>

> ListModel class javadoc refers to ListDataModel interface but there is no ListDataModel interface. Rectified the anomaly.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Copyright change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2931/files
  - new: https://git.openjdk.java.net/jdk/pull/2931/files/64908df5..26d4df72

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

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

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

From azvegint at openjdk.java.net  Thu Mar 11 13:02:09 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 11 Mar 2021 13:02:09 GMT
Subject: <Swing Dev> RFR: 8263410: ListModel javadoc refers to
 non-existent interface [v2]
In-Reply-To: <5tteNI8tzgKO2jGYeg5bH07UAb6e5O317G-OmpTV1bc=.4d517d4a-2f86-46f8-9291-872cf7d67d25@github.com>
References: <N52F1WlX1hSNzOqAgwI10E4RTuaNE-vVGjWU_JIC040=.3e52da2f-d4a7-488c-bac4-8055971275cd@github.com>
 <5tteNI8tzgKO2jGYeg5bH07UAb6e5O317G-OmpTV1bc=.4d517d4a-2f86-46f8-9291-872cf7d67d25@github.com>
Message-ID: <Q0IQqQ1yvpzoXljjtPHhsC9rNJpfD4X9zWxAelbZ1Ko=.429159dc-314c-4646-814d-33d7bf771641@github.com>

On Thu, 11 Mar 2021 04:40:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> ListModel class javadoc refers to ListDataModel interface but there is no ListDataModel interface. Rectified the anomaly.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright change

Marked as reviewed by azvegint (Reviewer).

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

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

From pbansal at openjdk.java.net  Thu Mar 11 13:29:07 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 11 Mar 2021 13:29:07 GMT
Subject: <Swing Dev> RFR: 8263410: ListModel javadoc refers to
 non-existent interface [v2]
In-Reply-To: <5tteNI8tzgKO2jGYeg5bH07UAb6e5O317G-OmpTV1bc=.4d517d4a-2f86-46f8-9291-872cf7d67d25@github.com>
References: <N52F1WlX1hSNzOqAgwI10E4RTuaNE-vVGjWU_JIC040=.3e52da2f-d4a7-488c-bac4-8055971275cd@github.com>
 <5tteNI8tzgKO2jGYeg5bH07UAb6e5O317G-OmpTV1bc=.4d517d4a-2f86-46f8-9291-872cf7d67d25@github.com>
Message-ID: <yDUI53esL_gmbananr7ti6GuHam_j9aTPpGPx_0--rA=.aac6687c-be87-407c-8630-2686efc0ea08@github.com>

On Thu, 11 Mar 2021 04:40:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> ListModel class javadoc refers to ListDataModel interface but there is no ListDataModel interface. Rectified the anomaly.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright change

Marked as reviewed by pbansal (Reviewer).

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

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

From pbansal at openjdk.java.net  Thu Mar 11 17:13:05 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 11 Mar 2021 17:13:05 GMT
Subject: <Swing Dev> RFR: 8262981: Create implementation for
 NSAccessibilitySlider protocol
In-Reply-To: <B0hF7cV-7O7pclnhmX7C4Biw20C5CLtIM11C6z5Tin0=.f06fa7ce-9049-454e-80f8-36935f3e0301@github.com>
References: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
 <3kHCT6j_xnm9mbA2jeP35p9rY4nxOD61PInSB9mglT8=.71c3b9df-0cc3-40f7-b339-15b382e36b6f@github.com>
 <WaDY3XBH6a6nPencpEbkyZjTnX5iqzxX9wZZ5eKI6KI=.a32e0717-0736-417c-84c0-bbb858bc2e35@github.com>
 <4SZRIR695DBooSWt-1aatGx-CKPy6EwuRpXS29A8wro=.4ba37fe2-6017-482f-83c4-33d7a11fc320@github.com>
 <B0hF7cV-7O7pclnhmX7C4Biw20C5CLtIM11C6z5Tin0=.f06fa7ce-9049-454e-80f8-36935f3e0301@github.com>
Message-ID: <zHiKUzH6bz3rwjjzbRQv4DgwaQ-J8FjFnTrKTKi_7kM=.5cb87998-4512-4c73-a673-038426b71171@github.com>

On Wed, 10 Mar 2021 23:09:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> If it does not work on Windows then I suggest checking that the new functionality requested via CSR will help it as well.

I could not find any key shortcuts where JAWS will consume the key pressed and will be used to interact with the component like the VO is doing here. This similar functionality is present in JSpinner already and JAWS says similar thing when a Spinner is in focus "To set the value, press the arrow keys or type the value". When user presses the keys, it is consumed by Java and value is incremented/decremented as expected. But the value is not being set by JAWS like VO if used with VO keys. So I am not sure how to verify if the changes will be useful for windows as well. I think if there is a way user can interact with Spinner or Slider, then these changes should be useful and if it is not possible, it will not be useful in both. These changes does make the Slider more consistent with Spinner and easy to maintain and cleaner.
If you happen to have some idea about how can a user interact with Sliders or Spinners using JAWS, please let me know. I will definitely verify if the changes would be helpful for Windows.

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

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

From aivanov at openjdk.java.net  Thu Mar 11 21:52:07 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 11 Mar 2021 21:52:07 GMT
Subject: <Swing Dev> RFR: 8263410: ListModel javadoc refers to
 non-existent interface [v2]
In-Reply-To: <5tteNI8tzgKO2jGYeg5bH07UAb6e5O317G-OmpTV1bc=.4d517d4a-2f86-46f8-9291-872cf7d67d25@github.com>
References: <N52F1WlX1hSNzOqAgwI10E4RTuaNE-vVGjWU_JIC040=.3e52da2f-d4a7-488c-bac4-8055971275cd@github.com>
 <5tteNI8tzgKO2jGYeg5bH07UAb6e5O317G-OmpTV1bc=.4d517d4a-2f86-46f8-9291-872cf7d67d25@github.com>
Message-ID: <IZ-OSUXSWe_ZY4fyUQbsyB_8ySM2uArvZVxzUQYccOQ=.f1a991e8-2779-40d4-ae8b-561602db36e2@github.com>

On Thu, 11 Mar 2021 04:40:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> ListModel class javadoc refers to ListDataModel interface but there is no ListDataModel interface. Rectified the anomaly.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright change

Marked as reviewed by aivanov (Reviewer).

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

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

From serb at openjdk.java.net  Fri Mar 12 03:29:11 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 12 Mar 2021 03:29:11 GMT
Subject: <Swing Dev> RFR: 8262981: Create implementation for
 NSAccessibilitySlider protocol
In-Reply-To: <zHiKUzH6bz3rwjjzbRQv4DgwaQ-J8FjFnTrKTKi_7kM=.5cb87998-4512-4c73-a673-038426b71171@github.com>
References: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
 <3kHCT6j_xnm9mbA2jeP35p9rY4nxOD61PInSB9mglT8=.71c3b9df-0cc3-40f7-b339-15b382e36b6f@github.com>
 <WaDY3XBH6a6nPencpEbkyZjTnX5iqzxX9wZZ5eKI6KI=.a32e0717-0736-417c-84c0-bbb858bc2e35@github.com>
 <4SZRIR695DBooSWt-1aatGx-CKPy6EwuRpXS29A8wro=.4ba37fe2-6017-482f-83c4-33d7a11fc320@github.com>
 <B0hF7cV-7O7pclnhmX7C4Biw20C5CLtIM11C6z5Tin0=.f06fa7ce-9049-454e-80f8-36935f3e0301@github.com>
 <zHiKUzH6bz3rwjjzbRQv4DgwaQ-J8FjFnTrKTKi_7kM=.5cb87998-4512-4c73-a673-038426b71171@github.com>
Message-ID: <60QaQ3ISOvoR5RMWU1hTSCsiBHfy7xU2QjvLzrGaSvA=.c02ab62e-5176-4015-a16c-849a71088452@github.com>

On Thu, 11 Mar 2021 17:10:01 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> If you happen to have some idea about how can a user interact with Sliders or Spinners using JAWS, please let me know. I will definitely verify if the changes would be helpful for Windows.

How the native applications works under JAWS?

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

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

From psadhukhan at openjdk.java.net  Fri Mar 12 04:38:19 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 12 Mar 2021 04:38:19 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing
Message-ID: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>

It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.

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

Commit messages:
 - 8263472: Specification of JComponent::updateUI doesn't mention that the original implementaiton does nothing

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

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

From github.com+72060147+amresh-sahu at openjdk.java.net  Fri Mar 12 05:36:23 2021
From: github.com+72060147+amresh-sahu at openjdk.java.net (Amresh Sahu)
Date: Fri, 12 Mar 2021 05:36:23 GMT
Subject: <Swing Dev> RFR: JDK-8263235 :
 sanity/client/SwingSet/src/ColorChooserDemoTest.java failed throwing
 java.lang.NoClassDefFoundError
Message-ID: <7wHhDXuqX0oZMwq82WEmTlzRxsHYy7IBhsehPKFwtIo=.7565e4dc-175a-46b4-9cc7-dc3d4b23f240@github.com>

Added @build org.jemmy2ext.JemmyExt.

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

Commit messages:
 - JDK-8263235:Added @build org.jemmy2ext.JemmyExt
 - Merge pull request #2 from openjdk/master

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

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

From github.com+72060147+amresh-sahu at openjdk.java.net  Fri Mar 12 05:43:06 2021
From: github.com+72060147+amresh-sahu at openjdk.java.net (Amresh Sahu)
Date: Fri, 12 Mar 2021 05:43:06 GMT
Subject: <Swing Dev> RFR: JDK-8263235 :
 sanity/client/SwingSet/src/ColorChooserDemoTest.java failed throwing
 java.lang.NoClassDefFoundError
In-Reply-To: <7wHhDXuqX0oZMwq82WEmTlzRxsHYy7IBhsehPKFwtIo=.7565e4dc-175a-46b4-9cc7-dc3d4b23f240@github.com>
References: <7wHhDXuqX0oZMwq82WEmTlzRxsHYy7IBhsehPKFwtIo=.7565e4dc-175a-46b4-9cc7-dc3d4b23f240@github.com>
Message-ID: <0BoiMhMpzmk9jiDBv4ZNkV0MdYyPKYGqZeu0JeE2v-8=.e3dc5ed5-57b6-42d4-a3dd-14c1f9466d76@github.com>

On Fri, 12 Mar 2021 05:29:01 GMT, Amresh Sahu <github.com+72060147+amresh-sahu at openjdk.org> wrote:

> Added @build org.jemmy2ext.JemmyExt.

@shurymury , @akolarkunnu 
Kindly review my changes.

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

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

From akolarkunnu at openjdk.java.net  Fri Mar 12 06:30:06 2021
From: akolarkunnu at openjdk.java.net (Abdul Kolarkunnu)
Date: Fri, 12 Mar 2021 06:30:06 GMT
Subject: <Swing Dev> RFR: JDK-8263235 :
 sanity/client/SwingSet/src/ColorChooserDemoTest.java failed throwing
 java.lang.NoClassDefFoundError
In-Reply-To: <0BoiMhMpzmk9jiDBv4ZNkV0MdYyPKYGqZeu0JeE2v-8=.e3dc5ed5-57b6-42d4-a3dd-14c1f9466d76@github.com>
References: <7wHhDXuqX0oZMwq82WEmTlzRxsHYy7IBhsehPKFwtIo=.7565e4dc-175a-46b4-9cc7-dc3d4b23f240@github.com>
 <0BoiMhMpzmk9jiDBv4ZNkV0MdYyPKYGqZeu0JeE2v-8=.e3dc5ed5-57b6-42d4-a3dd-14c1f9466d76@github.com>
Message-ID: <HuCzUOTL4HadSE0hqUogRtyo8wmd_5U4XmMAOB6-2us=.7ed59698-a834-486f-b1f3-1dcc45504d0c@github.com>

On Fri, 12 Mar 2021 05:40:35 GMT, Amresh Sahu <github.com+72060147+amresh-sahu at openjdk.org> wrote:

>> Added @build org.jemmy2ext.JemmyExt.
>
> @shurymury , @akolarkunnu 
> Kindly review my changes.

looks good to me

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

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

From psadhukhan at openjdk.java.net  Fri Mar 12 08:11:14 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 12 Mar 2021 08:11:14 GMT
Subject: <Swing Dev> RFR: JDK-8263235 :
 sanity/client/SwingSet/src/ColorChooserDemoTest.java failed throwing
 java.lang.NoClassDefFoundError
In-Reply-To: <7wHhDXuqX0oZMwq82WEmTlzRxsHYy7IBhsehPKFwtIo=.7565e4dc-175a-46b4-9cc7-dc3d4b23f240@github.com>
References: <7wHhDXuqX0oZMwq82WEmTlzRxsHYy7IBhsehPKFwtIo=.7565e4dc-175a-46b4-9cc7-dc3d4b23f240@github.com>
Message-ID: <Pu6u8pY2qwFnVKASAcgb_TCxmGZZgmZKM_XyGNbvI0Y=.6294fcc8-f96f-4cb0-95d6-9b193b7803fa@github.com>

On Fri, 12 Mar 2021 05:29:01 GMT, Amresh Sahu <github.com+72060147+amresh-sahu at openjdk.org> wrote:

> Added @build org.jemmy2ext.JemmyExt.

test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java line 66:

> 64: *          java.logging
> 65: * @build org.jemmy2ext.JemmyExt
> 66: * @build com.sun.swingset3.demos.colorchooser.ColorChooserDemo

I guess you also need to update GridBagLayoutDemoTest.java with the same.

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

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

From github.com+72060147+amresh-sahu at openjdk.java.net  Fri Mar 12 14:39:23 2021
From: github.com+72060147+amresh-sahu at openjdk.java.net (Amresh Sahu)
Date: Fri, 12 Mar 2021 14:39:23 GMT
Subject: <Swing Dev> RFR: JDK-8263235 :
 sanity/client/SwingSet/src/ColorChooserDemoTest.java failed throwing
 java.lang.NoClassDefFoundError [v2]
In-Reply-To: <7wHhDXuqX0oZMwq82WEmTlzRxsHYy7IBhsehPKFwtIo=.7565e4dc-175a-46b4-9cc7-dc3d4b23f240@github.com>
References: <7wHhDXuqX0oZMwq82WEmTlzRxsHYy7IBhsehPKFwtIo=.7565e4dc-175a-46b4-9cc7-dc3d4b23f240@github.com>
Message-ID: <GVCDxshdTSdGBdY9rmKBpOXkyXc-tE1ttvHYXBwJSv0=.44a9a3d8-40d7-456d-a318-98e60fc8b411@github.com>

> Added @build org.jemmy2ext.JemmyExt.

Amresh Sahu has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8263235:Added @build org.jemmy2ext.JemmyExt

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2958/files
  - new: https://git.openjdk.java.net/jdk/pull/2958/files/ce31d169..6673b53b

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

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

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

From herrick at openjdk.java.net  Fri Mar 12 16:13:36 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 12 Mar 2021 16:13:36 GMT
Subject: <Swing Dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
Message-ID: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>

implementation of
JDK-8256145: JEP 398: Deprecate the Applet API for Removal

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

Commit messages:
 - 8189198: Add "forRemoval = true" to Applet API deprecations

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

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

From iris at openjdk.java.net  Fri Mar 12 18:20:06 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 12 Mar 2021 18:20:06 GMT
Subject: <Swing Dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <ZSNT5qc_BugwWIZl4x2ueqQObQFJgUQ6jzi5TZTrPhg=.57cc693b-41f8-43f2-92fb-f7c9d6b4d493@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

Marked as reviewed by iris (Reviewer).

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

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

From aivanov at openjdk.java.net  Fri Mar 12 21:40:09 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 12 Mar 2021 21:40:09 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing
In-Reply-To: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
Message-ID: <jc6iQdmat_AYFTq4xx9Zs0Gxlcoatm5ggPG09bhCENQ=.5eeabeed-e364-4d9c-a6c3-669b057f31b5@github.com>

On Fri, 12 Mar 2021 04:33:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.

src/java.desktop/share/classes/javax/swing/JComponent.java line 660:

> 658:     /**
> 659:      * Resets the UI property to a value from the current look and feel.
> 660:      * Since default implementation of this method don't do anything,

Suggestion:

     * Since the default implementation of this method doesn't do anything,
Or maybe even:
Suggestion:

     * The default implementation of this method does nothing;
It's a statement. Then it continues with ??subclasses must override this method??.

src/java.desktop/share/classes/javax/swing/JComponent.java line 659:

> 657: 
> 658:     /**
> 659:      * Resets the UI property to a value from the current look and feel.

Shall it rather use plural?
Suggestion:

     * Resets the UI properties to values from the current look and feel.
There are usually several properties that get updated, *all the properties* in fact.

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

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

From serb at openjdk.java.net  Fri Mar 12 22:27:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 12 Mar 2021 22:27:06 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing
In-Reply-To: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
Message-ID: <LwAOfCQX4cShZw1Zcti_dNxytcDQinkYXVqyTd8IJcE=.93691252-d5fc-41bb-a1ba-473533843f62@github.com>

On Fri, 12 Mar 2021 04:33:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.

Do we really want to specify this as a noop method? In this case, we will not be able to change this implementation in the future.

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

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

From almatvee at openjdk.java.net  Sat Mar 13 00:46:07 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Sat, 13 Mar 2021 00:46:07 GMT
Subject: <Swing Dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

Marked as reviewed by almatvee (Committer).

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

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

From serb at openjdk.java.net  Sat Mar 13 02:01:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 13 Mar 2021 02:01:07 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge [v2]
In-Reply-To: <T1QW3aeoxbygF0Kb0zKHjChMCoXRQvojX6fr_ds7lcA=.71a4065b-486b-4934-ac96-a2021c0865e5@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
 <T1QW3aeoxbygF0Kb0zKHjChMCoXRQvojX6fr_ds7lcA=.71a4065b-486b-4934-ac96-a2021c0865e5@github.com>
Message-ID: <th-TiwaiP-cFB2Ph4Lxxlgrhz1sLBbUdzCv5g2a0Wds=.91d8956e-b9a7-4b4c-8d65-0b95ab0138f2@github.com>

On Mon, 8 Mar 2021 00:56:24 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I saw C4530 with VS 2019 (16.9.0) as following (on Japanese locale):
>> 
>> AccessBridgeDebug.cpp
>> ??: ?????? ????: d:\github-forked\jdk\src\jdk.accessibility\windows\native\common\AccessBridgeDebug.h
>> 
>>     :
>> 
>> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\ostream(611): error C2220: ???
>> ??????????????
>> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\ostream(611): warning C4530: C++
>> ??????????????????? ??????????????????/EHsc ??????????
>> ??: ?????? ????: c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\string
>> 
>> `/EHsc` has been already passed in other makefiles, and also AccessBridgeDebug.cpp uses some STL classes (e.g. `chrono` namespace). So `/EHsc` is a solution for this problem.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Sat Mar 13 02:01:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 13 Mar 2021 02:01:08 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge [v2]
In-Reply-To: <8IiVqESA2inNmd8VD9dMWgBxSHXfBqd3RXfDMCVEjQI=.61290b1f-aa2b-4166-b8c0-6548b930b116@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
 <T1QW3aeoxbygF0Kb0zKHjChMCoXRQvojX6fr_ds7lcA=.71a4065b-486b-4934-ac96-a2021c0865e5@github.com>
 <Rmb9h2DdsZl26XPdMFUPmD9qxM9RFF2IHCkFJDLsnj0=.af52b701-10cf-45e6-a766-33895f808a5e@github.com>
 <S0o-7c81rJxXU6M2AdBpskZJuGN5zqlAsRY1Ime0AgE=.e46a19cb-5dde-4c6e-b908-4d3d0bf69f40@github.com>
 <BXa7BAfnGWZ8uurRWn7fO0sICPO4MygopzHKjI4udL8=.849592c6-c398-4370-9ec6-53a3896a390a@github.com>
 <nci2NpmndUlC3aKzH0TmhqGAiniBoFSW3ueF1k7ryW0=.104864ab-186c-4a5d-b47e-347ad3265a20@github.com>
 <8IiVqESA2inNmd8VD9dMWgBxSHXfBqd3RXfDMCVEjQI=.61290b1f-aa2b-4166-b8c0-6548b930b116@github.com>
Message-ID: <Qs1V8NWiixLZUx8kTGfOdL4SL6Gpaw_gdLFAHG46NZw=.36118636-db06-4993-9b19-a7eb0fc8efca@github.com>

On Wed, 10 Mar 2021 01:40:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> No, can you help?
>
> I'll check.

This change looks fine, I was able to see the proper logs in the java_access_bridge.log, but I cannot find the logs from the windows_access_bridge.log. It seems unrelated to this fix. @pankaj-bansal please take a look at why the windows log might be missed if "JAVA_ACCESSBRIDGE_LOGDIR" is set.

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

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

From serb at openjdk.java.net  Sat Mar 13 02:01:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 13 Mar 2021 02:01:08 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge [v2]
In-Reply-To: <Qs1V8NWiixLZUx8kTGfOdL4SL6Gpaw_gdLFAHG46NZw=.36118636-db06-4993-9b19-a7eb0fc8efca@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
 <T1QW3aeoxbygF0Kb0zKHjChMCoXRQvojX6fr_ds7lcA=.71a4065b-486b-4934-ac96-a2021c0865e5@github.com>
 <Rmb9h2DdsZl26XPdMFUPmD9qxM9RFF2IHCkFJDLsnj0=.af52b701-10cf-45e6-a766-33895f808a5e@github.com>
 <S0o-7c81rJxXU6M2AdBpskZJuGN5zqlAsRY1Ime0AgE=.e46a19cb-5dde-4c6e-b908-4d3d0bf69f40@github.com>
 <BXa7BAfnGWZ8uurRWn7fO0sICPO4MygopzHKjI4udL8=.849592c6-c398-4370-9ec6-53a3896a390a@github.com>
 <nci2NpmndUlC3aKzH0TmhqGAiniBoFSW3ueF1k7ryW0=.104864ab-186c-4a5d-b47e-347ad3265a20@github.com>
 <8IiVqESA2inNmd8VD9dMWgBxSHXfBqd3RXfDMCVEjQI=.61290b1f-aa2b-4166-b8c0-6548b930b116@github.com>
 <Qs1V8NWiixLZUx8kTGfOdL4SL6Gpaw_gdLFAHG46NZw=.36118636-db06-4993-9b19-a7eb0fc8efca@github.com>
Message-ID: <O_Z6svnvzlX7x-u9Qtpqs0JZKTADcEV3tKfirBG98K0=.930ae65e-3213-4291-8dab-1a9032c2c6c9@github.com>

On Sat, 13 Mar 2021 01:56:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I'll check.
>
> This change looks fine, I was able to see the proper logs in the java_access_bridge.log, but I cannot find the logs from the windows_access_bridge.log. It seems unrelated to this fix. @pankaj-bansal please take a look at why the windows log might be missed if "JAVA_ACCESSBRIDGE_LOGDIR" is set.

For the record: the jaws J2021.2102.34.400 was used for testing.

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

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

From ysuenaga at openjdk.java.net  Sat Mar 13 02:08:05 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 13 Mar 2021 02:08:05 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge [v2]
In-Reply-To: <O_Z6svnvzlX7x-u9Qtpqs0JZKTADcEV3tKfirBG98K0=.930ae65e-3213-4291-8dab-1a9032c2c6c9@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
 <T1QW3aeoxbygF0Kb0zKHjChMCoXRQvojX6fr_ds7lcA=.71a4065b-486b-4934-ac96-a2021c0865e5@github.com>
 <Rmb9h2DdsZl26XPdMFUPmD9qxM9RFF2IHCkFJDLsnj0=.af52b701-10cf-45e6-a766-33895f808a5e@github.com>
 <S0o-7c81rJxXU6M2AdBpskZJuGN5zqlAsRY1Ime0AgE=.e46a19cb-5dde-4c6e-b908-4d3d0bf69f40@github.com>
 <BXa7BAfnGWZ8uurRWn7fO0sICPO4MygopzHKjI4udL8=.849592c6-c398-4370-9ec6-53a3896a390a@github.com>
 <nci2NpmndUlC3aKzH0TmhqGAiniBoFSW3ueF1k7ryW0=.104864ab-186c-4a5d-b47e-347ad3265a20@github.com>
 <8IiVqESA2inNmd8VD9dMWgBxSHXfBqd3RXfDMCVEjQI=.61290b1f-aa2b-4166-b8c0-6548b930b116@github.com>
 <Qs1V8NWiixLZUx8kTGfOdL4SL6Gpaw_gdLFAHG46NZw=.36118636-db06-4993-9b19-a7eb0fc8efca@github.com>
 <O_Z6svnvzlX7x-u9Qtpqs0JZKTADcEV3tKfirBG98K0=.930ae65e-3213-4291-8dab-1a9032c2c6c9@github.com>
Message-ID: <8x8s2aklV8X1RcrW9OkE1I8pnCYP5on1EtmMFNsH-2Q=.54c4ede0-00f7-458a-826c-bf28aa627f96@github.com>

On Sat, 13 Mar 2021 01:57:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This change looks fine, I was able to see the proper logs in the java_access_bridge.log, but I cannot find the logs from the windows_access_bridge.log. It seems unrelated to this fix. @pankaj-bansal please take a look at why the windows log might be missed if "JAVA_ACCESSBRIDGE_LOGDIR" is set.
>
> For the record: the jaws J2021.2102.34.400 was used for testing.

Thanks @mrserb for the test!

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

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

From ysuenaga at openjdk.java.net  Sat Mar 13 09:46:07 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 13 Mar 2021 09:46:07 GMT
Subject: <Swing Dev> Integrated: 8263136: C4530 was reported from VS 2019 at
 access bridge
In-Reply-To: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
Message-ID: <iz7PCUw1lqjQnB8voPRThM-bdxqXk0KWZVHCyMGJm00=.e4db0970-8fc1-4612-ab22-a56ba96ce765@github.com>

On Sun, 7 Mar 2021 03:18:53 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I saw C4530 with VS 2019 (16.9.0) as following (on Japanese locale):
> 
> AccessBridgeDebug.cpp
> ??: ?????? ????: d:\github-forked\jdk\src\jdk.accessibility\windows\native\common\AccessBridgeDebug.h
> 
>     :
> 
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\ostream(611): error C2220: ???
> ??????????????
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\ostream(611): warning C4530: C++
> ??????????????????? ??????????????????/EHsc ??????????
> ??: ?????? ????: c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\string
> 
> `/EHsc` has been already passed in other makefiles, and also AccessBridgeDebug.cpp uses some STL classes (e.g. `chrono` namespace). So `/EHsc` is a solution for this problem.

This pull request has now been integrated.

Changeset: d339320e
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d339320e
Stats:     9 lines in 1 file changed: 2 ins; 1 del; 6 mod

8263136: C4530 was reported from VS 2019 at access bridge

Reviewed-by: stuefe, serb

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

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

From redestad at openjdk.java.net  Sat Mar 13 15:22:08 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sat, 13 Mar 2021 15:22:08 GMT
Subject: <Swing Dev> RFR: 8263552: Use String.valueOf() for
 char-to-String conversion in ObjectStreamClass
In-Reply-To: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
Message-ID: <mPDSY0J8ZkHazzBv6PWN4HPt-uuvx0FIyTGOVKvgjUU=.f3e27cbe-8a04-494a-9d67-06d48512d897@github.com>

On Sat, 20 Feb 2021 12:17:32 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array

LGTM

src/java.base/share/classes/java/io/ObjectStreamClass.java line 833:

> 831:             String fname = in.readUTF();
> 832:             String signature = ((tcode == 'L') || (tcode == '[')) ?
> 833:                 in.readTypeString() : String.valueOf(tcode);

Since the result of String.valueOf here will be equal to one of the primitive signatures strings ("I", "J", ...) (otherwise ObjectStreamField will throw an exception) it might make sense to turn this into a switch expression and simplify the whole thing. I can't tell how performance sensitive this piece of code is, though.

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

Marked as reviewed by redestad (Reviewer).

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

From github.com+10835776+stsypanov at openjdk.java.net  Sat Mar 13 15:56:08 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sat, 13 Mar 2021 15:56:08 GMT
Subject: <Swing Dev> RFR: 8263552: Use String.valueOf() for
 char-to-String conversion in ObjectStreamClass
In-Reply-To: <mPDSY0J8ZkHazzBv6PWN4HPt-uuvx0FIyTGOVKvgjUU=.f3e27cbe-8a04-494a-9d67-06d48512d897@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <mPDSY0J8ZkHazzBv6PWN4HPt-uuvx0FIyTGOVKvgjUU=.f3e27cbe-8a04-494a-9d67-06d48512d897@github.com>
Message-ID: <VuzFbMSi1PtToBmHe1GaotOCzne8plEczAVShPtnu2o=.286a0ba5-38fa-4588-9b30-6127c45ddc10@github.com>

On Sat, 13 Mar 2021 15:18:59 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array
>
> src/java.base/share/classes/java/io/ObjectStreamClass.java line 833:
> 
>> 831:             String fname = in.readUTF();
>> 832:             String signature = ((tcode == 'L') || (tcode == '[')) ?
>> 833:                 in.readTypeString() : String.valueOf(tcode);
> 
> Since the result of String.valueOf here will be equal to one of the primitive signatures strings ("I", "J", ...) (otherwise ObjectStreamField will throw an exception) it might make sense to turn this into a switch expression and simplify the whole thing. I can't tell how performance sensitive this piece of code is, though.

Hi, I'll check and add one more PR if it makes sense

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

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

From redestad at openjdk.java.net  Sun Mar 14 00:05:07 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 14 Mar 2021 00:05:07 GMT
Subject: <Swing Dev> RFR: 8263552: Use String.valueOf() for
 char-to-String conversion in ObjectStreamClass
In-Reply-To: <mPDSY0J8ZkHazzBv6PWN4HPt-uuvx0FIyTGOVKvgjUU=.f3e27cbe-8a04-494a-9d67-06d48512d897@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <mPDSY0J8ZkHazzBv6PWN4HPt-uuvx0FIyTGOVKvgjUU=.f3e27cbe-8a04-494a-9d67-06d48512d897@github.com>
Message-ID: <hCj2wgg1ufKSvex73ZhVxHbJo4sxkBdrylwt79bT6yY=.eeec6588-2974-4ce5-bc89-5d30adfc9f30@github.com>

On Sat, 13 Mar 2021 15:19:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array
>
> LGTM

I'll sponsor when I'm back to work on Monday, assuming there are no objections.

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

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

From pbansal at openjdk.java.net  Sun Mar 14 11:13:07 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sun, 14 Mar 2021 11:13:07 GMT
Subject: <Swing Dev> RFR: 8262981: Create implementation for
 NSAccessibilitySlider protocol
In-Reply-To: <60QaQ3ISOvoR5RMWU1hTSCsiBHfy7xU2QjvLzrGaSvA=.c02ab62e-5176-4015-a16c-849a71088452@github.com>
References: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
 <3kHCT6j_xnm9mbA2jeP35p9rY4nxOD61PInSB9mglT8=.71c3b9df-0cc3-40f7-b339-15b382e36b6f@github.com>
 <WaDY3XBH6a6nPencpEbkyZjTnX5iqzxX9wZZ5eKI6KI=.a32e0717-0736-417c-84c0-bbb858bc2e35@github.com>
 <4SZRIR695DBooSWt-1aatGx-CKPy6EwuRpXS29A8wro=.4ba37fe2-6017-482f-83c4-33d7a11fc320@github.com>
 <B0hF7cV-7O7pclnhmX7C4Biw20C5CLtIM11C6z5Tin0=.f06fa7ce-9049-454e-80f8-36935f3e0301@github.com>
 <zHiKUzH6bz3rwjjzbRQv4DgwaQ-J8FjFnTrKTKi_7kM=.5cb87998-4512-4c73-a673-038426b71171@github.com>
 <60QaQ3ISOvoR5RMWU1hTSCsiBHfy7xU2QjvLzrGaSvA=.c02ab62e-5176-4015-a16c-849a71088452@github.com>
Message-ID: <yaOXyCB7ZJx5mE_xkXh0bwZPQXDzusbe55a-UAYPSEk=.f1928607-0fa6-4b04-bc2b-a089acfcb628@github.com>

On Fri, 12 Mar 2021 03:26:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > If you happen to have some idea about how can a user interact with Sliders or Spinners using JAWS, please let me know. I will definitely verify if the changes would be helpful for Windows.
> 
> How the native applications works under JAWS?

I tried running a Windows native settings app like "Display Settings" with JAWS. It has a Slider "Brightness". JAWS says same thing when the Slider was brought in focus like "To increase or decrease, use the arrow keys". When I press the arrow keys, the values change. But I don't know if the value changed because the Windows Native dialog handles the keys and changed the value, or JAWS consumed the event and then changed the value. It looks like the Dialog must have handled the keys as there are no special keys mentioned for JAWS to interact with the component like the VO.  I am not sure how I can verify this on Windows native apps. 
I did try to run the JSpinner with JAWS and I see that if Java does not handle the keys, the value in Spinner does not change. This means JAWS does not interact with the component and the accessibility functionality was added for MacOS only. Same thing is being done for JSlider.

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

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

From pbansal at openjdk.java.net  Sun Mar 14 11:18:25 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sun, 14 Mar 2021 11:18:25 GMT
Subject: <Swing Dev> RFR: 8262981: Create implementation for
 NSAccessibilitySlider protocol [v2]
In-Reply-To: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
References: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
Message-ID: <r6cHZZ7n0pRhLeU5PY6kttCoXpkvoQI8eZdTRhG8YV4=.40bc3b79-0999-4bda-b7ab-f0c138f5cddf@github.com>

> Create implementation of NSAccessibilitySlider protocol https://developer.apple.com/documentation/appkit/nsaccessibilityslider
> 
> The implementation has the function performIncrement and performDecrement to increase/decrease the value of slider using the VoiceOver. To implement this functionality, I could think of  following two ways. I have chosen the first one here though it is more intrusive.
> 1. Make the AccessibleJSlider class implement the AccessibleAction interface. This makes AccessibleJSlider consistent with the AccessibleJSpinner class. It is more clear and the logic to increase/decrease Slider value can be changed easily. But this changes AccessibleJSlider class and will need a CSR.
> 2. Get the current Accessible Value from the component and  just increment/decrement it in SliderAccessibility.m  class itself and then set the current accessible value fro there only. This will not need any changes in AccessibleJSlider class, but this does not look correct way and I have not used this.
> 
> The changes can be easily tested by using a JSlider example, like the following example. VO should announce the correct the slider values. To change the slider values, use ctrl+opt+shift+down key to start interacting with the slider, then use ctrl+opt+up/down arrow keys to increment/decrement slider values.
> 
>       import javax.swing.JFrame;
>       import javax.swing.JSlider;
>       
>       public class JSliderDemo{
>           public static void main(String[] args) throws Exception {
>               JFrame jframe = new JFrame("JSlider Demo");
>               jframe.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>               jframe.add(new JSlider());
>       
>               jframe.setLocationRelativeTo(null);
>               jframe.pack();
>               jframe.setVisible(true);
>           }
>       }

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

  increase initial capacity for rolesMap

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2874/files
  - new: https://git.openjdk.java.net/jdk/pull/2874/files/dac91ff1..a1944fee

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

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

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

From pbansal at openjdk.java.net  Sun Mar 14 11:18:25 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sun, 14 Mar 2021 11:18:25 GMT
Subject: <Swing Dev> RFR: 8262981: Create implementation for
 NSAccessibilitySlider protocol [v2]
In-Reply-To: <zXunuRsLWTTAkHbKdNZtjWnIxUIBIfJG0Uaf43hwyMQ=.8beb5dd7-122b-45ef-8618-b8aa89137353@github.com>
References: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
 <t13BqkCYG8qk0aLtw6azywTui3POwmMR_RtG4YJ7FwQ=.449b47de-456a-43b3-a936-021778920f73@github.com>
 <zXunuRsLWTTAkHbKdNZtjWnIxUIBIfJG0Uaf43hwyMQ=.8beb5dd7-122b-45ef-8618-b8aa89137353@github.com>
Message-ID: <LGQ_ua84qeg0mfFQ1K-19CbGJYtAS2sdCX7ubCtchYc=.6a1ab5d2-78a6-424d-9b41-1513326d7f2f@github.com>

On Wed, 10 Mar 2021 14:47:38 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m line 59:
>> 
>>> 57:     [rolesMap setObject:@"RadiobuttonAccessibility" forKey:@"radiobutton"];
>>> 58:     [rolesMap setObject:@"CheckboxAccessibility" forKey:@"checkbox"];
>>> 59:     [rolesMap setObject:@"SliderAccessibility" forKey:@"slider"];
>> 
>> Shouldn't you also increase the rolesMap initial capacity?
>
>> Shouldn't you also increase the rolesMap initial capacity?
> 
> ok, I will do that in next commit.

Done

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

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

From alanb at openjdk.java.net  Sun Mar 14 12:09:05 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 14 Mar 2021 12:09:05 GMT
Subject: <Swing Dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
In-Reply-To: <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
Message-ID: <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>

On Sat, 13 Mar 2021 00:43:33 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Marked as reviewed by almatvee (Committer).

Have you looked at narrowing the use of the SuppressWarnings to local variable declarations to avoid adding it to some of these methods?

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

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

From pbansal at openjdk.java.net  Sun Mar 14 17:32:07 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sun, 14 Mar 2021 17:32:07 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge [v2]
In-Reply-To: <O_Z6svnvzlX7x-u9Qtpqs0JZKTADcEV3tKfirBG98K0=.930ae65e-3213-4291-8dab-1a9032c2c6c9@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
 <T1QW3aeoxbygF0Kb0zKHjChMCoXRQvojX6fr_ds7lcA=.71a4065b-486b-4934-ac96-a2021c0865e5@github.com>
 <Rmb9h2DdsZl26XPdMFUPmD9qxM9RFF2IHCkFJDLsnj0=.af52b701-10cf-45e6-a766-33895f808a5e@github.com>
 <S0o-7c81rJxXU6M2AdBpskZJuGN5zqlAsRY1Ime0AgE=.e46a19cb-5dde-4c6e-b908-4d3d0bf69f40@github.com>
 <BXa7BAfnGWZ8uurRWn7fO0sICPO4MygopzHKjI4udL8=.849592c6-c398-4370-9ec6-53a3896a390a@github.com>
 <nci2NpmndUlC3aKzH0TmhqGAiniBoFSW3ueF1k7ryW0=.104864ab-186c-4a5d-b47e-347ad3265a20@github.com>
 <8IiVqESA2inNmd8VD9dMWgBxSHXfBqd3RXfDMCVEjQI=.61290b1f-aa2b-4166-b8c0-6548b930b116@github.com>
 <Qs1V8NWiixLZUx8kTGfOdL4SL6Gpaw_gdLFAHG46NZw=.36118636-db06-4993-9b19-a7eb0fc8efca@github.com>
 <O_Z6svnvzlX7x-u9Qtpqs0JZKTADcEV3tKfirBG98K0=.930ae65e-3213-4291-8dab-1a9032c2c6c9@github.com>
Message-ID: <AZ1-xA9wTre9MKYil9jH97afgQCjMoTyGQI--5853TE=.d5beed4f-0ec2-4a1e-abaa-ab90442c8b4f@github.com>

On Sat, 13 Mar 2021 01:57:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This change looks fine, I was able to see the proper logs in the java_access_bridge.log, but I cannot find the logs from the windows_access_bridge.log. It seems unrelated to this fix. @pankaj-bansal please take a look at why the windows log might be missed if "JAVA_ACCESSBRIDGE_LOGDIR" is set.
>
> For the record: the jaws J2021.2102.34.400 was used for testing.

@mrserb Did you close the JAWS after running the program. I have seen that the logs for windows_access_bridge are flushed only after the JAWS is closed.

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

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

From vtewari at openjdk.java.net  Sun Mar 14 17:48:07 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Sun, 14 Mar 2021 17:48:07 GMT
Subject: <Swing Dev> RFR: 8263552: Use String.valueOf() for
 char-to-String conversion in ObjectStreamClass
In-Reply-To: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
Message-ID: <7gdjb_onDfovaFwTFHONcf_r-zYx80Lp13JZmbjx0Gw=.0f0225b1-2fba-43ff-ae80-a754a62372c2@github.com>

On Sat, 20 Feb 2021 12:17:32 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array

LGTM

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

Marked as reviewed by vtewari (Committer).

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

From serb at openjdk.java.net  Sun Mar 14 23:05:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 14 Mar 2021 23:05:08 GMT
Subject: <Swing Dev> RFR: 8263136: C4530 was reported from VS 2019 at
 access bridge [v2]
In-Reply-To: <AZ1-xA9wTre9MKYil9jH97afgQCjMoTyGQI--5853TE=.d5beed4f-0ec2-4a1e-abaa-ab90442c8b4f@github.com>
References: <9Jzp6b6MjrFSOBV1DePBT7BpVO460EH6BDxLzVc2x8E=.d6dd0334-5e7e-4493-beee-cbf9f61c062f@github.com>
 <T1QW3aeoxbygF0Kb0zKHjChMCoXRQvojX6fr_ds7lcA=.71a4065b-486b-4934-ac96-a2021c0865e5@github.com>
 <Rmb9h2DdsZl26XPdMFUPmD9qxM9RFF2IHCkFJDLsnj0=.af52b701-10cf-45e6-a766-33895f808a5e@github.com>
 <S0o-7c81rJxXU6M2AdBpskZJuGN5zqlAsRY1Ime0AgE=.e46a19cb-5dde-4c6e-b908-4d3d0bf69f40@github.com>
 <BXa7BAfnGWZ8uurRWn7fO0sICPO4MygopzHKjI4udL8=.849592c6-c398-4370-9ec6-53a3896a390a@github.com>
 <nci2NpmndUlC3aKzH0TmhqGAiniBoFSW3ueF1k7ryW0=.104864ab-186c-4a5d-b47e-347ad3265a20@github.com>
 <8IiVqESA2inNmd8VD9dMWgBxSHXfBqd3RXfDMCVEjQI=.61290b1f-aa2b-4166-b8c0-6548b930b116@github.com>
 <Qs1V8NWiixLZUx8kTGfOdL4SL6Gpaw_gdLFAHG46NZw=.36118636-db06-4993-9b19-a7eb0fc8efca@github.com>
 <O_Z6svnvzlX7x-u9Qtpqs0JZKTADcEV3tKfirBG98K0=.930ae65e-3213-4291-8dab-1a9032c2c6c9@github.com>
 <AZ1-xA9wTre9MKYil9jH97afgQCjMoTyGQI--5853TE=.d5beed4f-0ec2-4a1e-abaa-ab90442c8b4f@github.com>
Message-ID: <DbPkQugYDVXUGlLewBGoYYUWjWJnadRjnSeOdocurHA=.76afd454-467a-4a1d-93df-00e1af5a1a25@github.com>

On Sun, 14 Mar 2021 17:27:58 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> For the record: the jaws J2021.2102.34.400 was used for testing.
>
> @mrserb Did you close the JAWS after running the program. I have seen that the logs for windows_access_bridge are flushed only after the JAWS is closed.

Nope! thank you for confirmation that win logs it works as well.

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

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

From psadhukhan at openjdk.java.net  Mon Mar 15 04:17:15 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 15 Mar 2021 04:17:15 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing
In-Reply-To: <LwAOfCQX4cShZw1Zcti_dNxytcDQinkYXVqyTd8IJcE=.93691252-d5fc-41bb-a1ba-473533843f62@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <LwAOfCQX4cShZw1Zcti_dNxytcDQinkYXVqyTd8IJcE=.93691252-d5fc-41bb-a1ba-473533843f62@github.com>
Message-ID: <ULgMEWiDvjmY1rEa1zSxA3Qxv9CmH1Yutd5PwTWyX1g=.c3afcc5c-85fe-4359-ae49-196ef8ac8b40@github.com>

On Fri, 12 Mar 2021 22:24:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> 
> 
> Do we really want to specify this as a noop method? In this case, we will not be able to change this implementation in the future.

I thought about it earlier but I raised this PR as I don't see this method was updated from inception so I was not sure if it will be in future and also since it already says "JComponent subclasses **must** override this method" so a noop default implementation will not be a problem, I guess.

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

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

From psadhukhan at openjdk.java.net  Mon Mar 15 04:23:26 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 15 Mar 2021 04:23:26 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v2]
In-Reply-To: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
Message-ID: <jHdTf9dqakyixIAXp3mRg9TZLKVTmw8pYt8VsY_rJyw=.db44bdb4-f1e0-4cc4-b703-bdb1cab31a27@github.com>

> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  javadoc change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2955/files
  - new: https://git.openjdk.java.net/jdk/pull/2955/files/9a0b2751..2d5e9112

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

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

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

From psadhukhan at openjdk.java.net  Mon Mar 15 04:23:27 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 15 Mar 2021 04:23:27 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v2]
In-Reply-To: <jc6iQdmat_AYFTq4xx9Zs0Gxlcoatm5ggPG09bhCENQ=.5eeabeed-e364-4d9c-a6c3-669b057f31b5@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <jc6iQdmat_AYFTq4xx9Zs0Gxlcoatm5ggPG09bhCENQ=.5eeabeed-e364-4d9c-a6c3-669b057f31b5@github.com>
Message-ID: <zskwJ2YEHPeeDFdTWShJbYkcrCtWVIrrQV_vciazV40=.c2118e40-cd00-40ec-b552-f4c23ab91185@github.com>

On Fri, 12 Mar 2021 21:36:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc change
>
> src/java.desktop/share/classes/javax/swing/JComponent.java line 659:
> 
>> 657: 
>> 658:     /**
>> 659:      * Resets the UI property to a value from the current look and feel.
> 
> Shall it rather use plural?
> Suggestion:
> 
>      * Resets the UI properties to values from the current look and feel.
> There are usually several properties that get updated, *all the properties* in fact.

I see that all subclass of JComponent implementing updateUI() cites this sentence so changing only here may not be proper unless we change it everywhere, so I guess let it be as it is.

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

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

From psadhukhan at openjdk.java.net  Mon Mar 15 04:32:08 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 15 Mar 2021 04:32:08 GMT
Subject: <Swing Dev> RFR: JDK-8263235 :
 sanity/client/SwingSet/src/ColorChooserDemoTest.java failed throwing
 java.lang.NoClassDefFoundError [v2]
In-Reply-To: <GVCDxshdTSdGBdY9rmKBpOXkyXc-tE1ttvHYXBwJSv0=.44a9a3d8-40d7-456d-a318-98e60fc8b411@github.com>
References: <7wHhDXuqX0oZMwq82WEmTlzRxsHYy7IBhsehPKFwtIo=.7565e4dc-175a-46b4-9cc7-dc3d4b23f240@github.com>
 <GVCDxshdTSdGBdY9rmKBpOXkyXc-tE1ttvHYXBwJSv0=.44a9a3d8-40d7-456d-a318-98e60fc8b411@github.com>
Message-ID: <EiTFo-8bbyphjXGCQ3DabZG38mzYzXJbiFdKdV-rcHE=.52a3a57a-0ce4-4b28-983c-4ca7e1756b2c@github.com>

On Fri, 12 Mar 2021 14:39:23 GMT, Amresh Sahu <github.com+72060147+amresh-sahu at openjdk.org> wrote:

>> Added @build org.jemmy2ext.JemmyExt.
>
> Amresh Sahu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8263235:Added @build org.jemmy2ext.JemmyExt

Marked as reviewed by psadhukhan (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Mon Mar 15 06:57:24 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 15 Mar 2021 06:57:24 GMT
Subject: <Swing Dev> RFR: 8263481: Specification of
 JComponent::setDefaultLocale doesn't mention that passing 'null' restores
 VM's default locale
Message-ID: <lbzrBGzrlcadhS6WspD4WHpmdYaiAQ35DF5naqDri3g=.315c49d7-e1ba-4a50-b434-9d92ff8e5b50@github.com>

The current state of specification for
https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/JComponent.html#setDefaultLocale(java.util.Locale)
doesn't mention anything about passing 'null' as a new default locale.

In fact for OpenJDK implementation passing 'null' restores the default VM's locale. 
This is now explicitly stated in javadoc.

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

Commit messages:
 - 8263481: Specification of JComponent::setDefaultLocale doesn't mention that passing 'null' restores VM's default locale

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

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

From azvegint at openjdk.java.net  Mon Mar 15 09:32:12 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 15 Mar 2021 09:32:12 GMT
Subject: <Swing Dev> RFR: 8263552: Use String.valueOf() for
 char-to-String conversion in ObjectStreamClass
In-Reply-To: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
Message-ID: <EtwbH_n_U-IvQEls9X-BIc64aDgoeG9cID_z4Znl_R8=.69bbcedf-6ec8-497d-826b-698d41fea3ba@github.com>

On Sat, 20 Feb 2021 12:17:32 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array

Marked as reviewed by azvegint (Reviewer).

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

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

From aivanov at openjdk.java.net  Mon Mar 15 10:48:10 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 15 Mar 2021 10:48:10 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v2]
In-Reply-To: <jHdTf9dqakyixIAXp3mRg9TZLKVTmw8pYt8VsY_rJyw=.db44bdb4-f1e0-4cc4-b703-bdb1cab31a27@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <jHdTf9dqakyixIAXp3mRg9TZLKVTmw8pYt8VsY_rJyw=.db44bdb4-f1e0-4cc4-b703-bdb1cab31a27@github.com>
Message-ID: <FVnALi5_mJ_81qLfbIlFiQyUVWvBiYrYn6C1CauGcZ4=.5a44487c-a426-4766-8840-87e5b9a30ea1@github.com>

On Mon, 15 Mar 2021 04:23:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc change

Marked as reviewed by aivanov (Reviewer).

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

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

From aivanov at openjdk.java.net  Mon Mar 15 10:48:11 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 15 Mar 2021 10:48:11 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v2]
In-Reply-To: <zskwJ2YEHPeeDFdTWShJbYkcrCtWVIrrQV_vciazV40=.c2118e40-cd00-40ec-b552-f4c23ab91185@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <jc6iQdmat_AYFTq4xx9Zs0Gxlcoatm5ggPG09bhCENQ=.5eeabeed-e364-4d9c-a6c3-669b057f31b5@github.com>
 <zskwJ2YEHPeeDFdTWShJbYkcrCtWVIrrQV_vciazV40=.c2118e40-cd00-40ec-b552-f4c23ab91185@github.com>
Message-ID: <r5hO3SPne5tUOnbzddMN3k_tZPJMIm-RKK6pRZ76T3k=.520512f7-e28d-4ad6-a026-0294f20f9e92@github.com>

On Mon, 15 Mar 2021 04:17:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JComponent.java line 659:
>> 
>>> 657: 
>>> 658:     /**
>>> 659:      * Resets the UI property to a value from the current look and feel.
>> 
>> Shall it rather use plural?
>> Suggestion:
>> 
>>      * Resets the UI properties to values from the current look and feel.
>> There are usually several properties that get updated, *all the properties* in fact.
>
> I see that all subclass of JComponent implementing updateUI() cites this sentence so changing only here may not be proper unless we change it everywhere, so I guess let it be as it is.

Agreed.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 10:54:07 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 10:54:07 GMT
Subject: <Swing Dev> RFR: 8263552: Use String.valueOf() for
 char-to-String conversions
In-Reply-To: <BJqCMMGcUYg78Kk-SggLkooddMLE35GZUnjf_g9g5GI=.1d96cfad-9b28-4b06-a59f-5607619eb33d@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <EtwbH_n_U-IvQEls9X-BIc64aDgoeG9cID_z4Znl_R8=.69bbcedf-6ec8-497d-826b-698d41fea3ba@github.com>
 <BJqCMMGcUYg78Kk-SggLkooddMLE35GZUnjf_g9g5GI=.1d96cfad-9b28-4b06-a59f-5607619eb33d@github.com>
Message-ID: <Hv_MEmDU3ku0pbMDZTiDamhQyMwAamWXUdEUtsDUvhY=.2882b823-9b17-4876-b742-e4a079b692de@github.com>

On Mon, 15 Mar 2021 10:51:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Marked as reviewed by azvegint (Reviewer).
>
> Ok if we change the summary to "Use String.valueOf() for char-to-String conversions"?

@cl4es done

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

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

From redestad at openjdk.java.net  Mon Mar 15 10:54:07 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 15 Mar 2021 10:54:07 GMT
Subject: <Swing Dev> RFR: 8263552: Use String.valueOf() for
 char-to-String conversions
In-Reply-To: <EtwbH_n_U-IvQEls9X-BIc64aDgoeG9cID_z4Znl_R8=.69bbcedf-6ec8-497d-826b-698d41fea3ba@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <EtwbH_n_U-IvQEls9X-BIc64aDgoeG9cID_z4Znl_R8=.69bbcedf-6ec8-497d-826b-698d41fea3ba@github.com>
Message-ID: <BJqCMMGcUYg78Kk-SggLkooddMLE35GZUnjf_g9g5GI=.1d96cfad-9b28-4b06-a59f-5607619eb33d@github.com>

On Mon, 15 Mar 2021 09:29:00 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array
>
> Marked as reviewed by azvegint (Reviewer).

Ok if we change the summary to "Use String.valueOf() for char-to-String conversions"?

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

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

From chegar at openjdk.java.net  Mon Mar 15 10:58:07 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 15 Mar 2021 10:58:07 GMT
Subject: <Swing Dev> RFR: 8263552: Use String.valueOf() for
 char-to-String conversions
In-Reply-To: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
Message-ID: <xIQgEqCqv172qDtja19_KNFvA-GI3iY-7OQzIqbw-zc=.a1fbeb74-4cd9-418f-b240-1e4b543aceb9@github.com>

On Sat, 20 Feb 2021 12:17:32 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array

Marked as reviewed by chegar (Reviewer).

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

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

From redestad at openjdk.java.net  Mon Mar 15 11:17:06 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 15 Mar 2021 11:17:06 GMT
Subject: <Swing Dev> RFR: 8263552: Use String.valueOf() for
 char-to-String conversions
In-Reply-To: <xIQgEqCqv172qDtja19_KNFvA-GI3iY-7OQzIqbw-zc=.a1fbeb74-4cd9-418f-b240-1e4b543aceb9@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <xIQgEqCqv172qDtja19_KNFvA-GI3iY-7OQzIqbw-zc=.a1fbeb74-4cd9-418f-b240-1e4b543aceb9@github.com>
Message-ID: <pOxo62rJLFCeKk5mzRhK6RXopd7a7S37Y8hA4Hdl0M4=.22f1f0a1-3b98-49ba-8508-a3b5a0fca8b7@github.com>

On Mon, 15 Mar 2021 10:55:12 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array
>
> Marked as reviewed by chegar (Reviewer).

It seems the bots haven't seen that I changed the bug summary to match yet.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 11:17:06 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 11:17:06 GMT
Subject: <Swing Dev> RFR: 8263552: Use String.valueOf() for
 char-to-String conversions
In-Reply-To: <pOxo62rJLFCeKk5mzRhK6RXopd7a7S37Y8hA4Hdl0M4=.22f1f0a1-3b98-49ba-8508-a3b5a0fca8b7@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <xIQgEqCqv172qDtja19_KNFvA-GI3iY-7OQzIqbw-zc=.a1fbeb74-4cd9-418f-b240-1e4b543aceb9@github.com>
 <pOxo62rJLFCeKk5mzRhK6RXopd7a7S37Y8hA4Hdl0M4=.22f1f0a1-3b98-49ba-8508-a3b5a0fca8b7@github.com>
Message-ID: <hL7EElcYSd1bH0vuMfE4MpnZG8TPLMLCpdrFUqOdKo8=.44395a4c-e76d-4474-a55e-bf549388dcc6@github.com>

On Mon, 15 Mar 2021 11:11:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Marked as reviewed by chegar (Reviewer).
>
> It seems the bots haven't seen that I changed the bug summary to match yet.

@cl4es could you try `/sponsor` again? I think this time it should be fine.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 11:22:11 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 11:22:11 GMT
Subject: <Swing Dev> Integrated: 8263552: Use String.valueOf() for
 char-to-String conversions
In-Reply-To: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
Message-ID: <WUyCZxO8OLLd2sylZrUbGrKpqcnn_8E0nz-hB4nQcNY=.7422c3e9-0b26-4095-b1bb-398a2f7434c3@github.com>

On Sat, 20 Feb 2021 12:17:32 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array

This pull request has now been integrated.

Changeset: c0176c42
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c0176c42
Stats:     6 lines in 6 files changed: 0 ins; 0 del; 6 mod

8263552: Use String.valueOf() for char-to-String conversions

Reviewed-by: redestad, vtewari, azvegint, chegar

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

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

From serb at openjdk.java.net  Mon Mar 15 17:40:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 15 Mar 2021 17:40:06 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v2]
In-Reply-To: <FVnALi5_mJ_81qLfbIlFiQyUVWvBiYrYn6C1CauGcZ4=.5a44487c-a426-4766-8840-87e5b9a30ea1@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <jHdTf9dqakyixIAXp3mRg9TZLKVTmw8pYt8VsY_rJyw=.db44bdb4-f1e0-4cc4-b703-bdb1cab31a27@github.com>
 <FVnALi5_mJ_81qLfbIlFiQyUVWvBiYrYn6C1CauGcZ4=.5a44487c-a426-4766-8840-87e5b9a30ea1@github.com>
Message-ID: <qbwk2R2_fja6bex3AD1TygQjQQouRQ8f3yw912wN08A=.d9a9eada-b313-44a5-aa83-52a8dc13dbfe@github.com>

On Mon, 15 Mar 2021 10:44:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc change
>
> Marked as reviewed by aivanov (Reviewer).

> I thought about it earlier but I raised this PR as I don't see this method was updated from inception so I was not sure if it will be in future and also since it already says "JComponent subclasses **must** override this method" so a noop default implementation will not be a problem, I guess.

Based on the current spec we may add some kind of assertion that this method must not be called.

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

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

From serb at openjdk.java.net  Mon Mar 15 17:40:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 15 Mar 2021 17:40:10 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v2]
In-Reply-To: <jHdTf9dqakyixIAXp3mRg9TZLKVTmw8pYt8VsY_rJyw=.db44bdb4-f1e0-4cc4-b703-bdb1cab31a27@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <jHdTf9dqakyixIAXp3mRg9TZLKVTmw8pYt8VsY_rJyw=.db44bdb4-f1e0-4cc4-b703-bdb1cab31a27@github.com>
Message-ID: <BaNIgS-nmXVD-TH4imLaAgZbAvsiGLcZxFCROqpQNdg=.0db0eeac-8bd7-4b63-ae3e-015bb5ba4f03@github.com>

On Mon, 15 Mar 2021 04:23:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc change

src/java.desktop/share/classes/javax/swing/JComponent.java line 660:

> 658:     /**
> 659:      * Resets the UI property to a value from the current look and feel.
> 660:      * Since the default implementation of this method doesn't do anything,

The reason why this method should be overridden is that the subclasses only can implement it properly, and it is not because the current method is empty.

Probably we can move the new text to the @implnote tag?

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

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

From aivanov at openjdk.java.net  Mon Mar 15 18:09:20 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 15 Mar 2021 18:09:20 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v2]
In-Reply-To: <BaNIgS-nmXVD-TH4imLaAgZbAvsiGLcZxFCROqpQNdg=.0db0eeac-8bd7-4b63-ae3e-015bb5ba4f03@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <jHdTf9dqakyixIAXp3mRg9TZLKVTmw8pYt8VsY_rJyw=.db44bdb4-f1e0-4cc4-b703-bdb1cab31a27@github.com>
 <BaNIgS-nmXVD-TH4imLaAgZbAvsiGLcZxFCROqpQNdg=.0db0eeac-8bd7-4b63-ae3e-015bb5ba4f03@github.com>
Message-ID: <y4g_QKJ6TcCF5gUmgqnBpMf_v-MS57c_cCltwHLYw18=.77e1a575-66f4-4a3e-96b5-468bfef2b3be@github.com>

On Mon, 15 Mar 2021 17:37:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc change
>
> src/java.desktop/share/classes/javax/swing/JComponent.java line 660:
> 
>> 658:     /**
>> 659:      * Resets the UI property to a value from the current look and feel.
>> 660:      * Since the default implementation of this method doesn't do anything,
> 
> The reason why this method should be overridden is that the subclasses only can implement it properly, and it is not because the current method is empty.
> 
> Probably we can move the new text to the @implnote tag?

Yet specifying that this method is empty implies overridden methods do not need to call `super.updateUI()`.

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

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

From aivanov at openjdk.java.net  Mon Mar 15 18:12:10 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 15 Mar 2021 18:12:10 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v2]
In-Reply-To: <qbwk2R2_fja6bex3AD1TygQjQQouRQ8f3yw912wN08A=.d9a9eada-b313-44a5-aa83-52a8dc13dbfe@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <jHdTf9dqakyixIAXp3mRg9TZLKVTmw8pYt8VsY_rJyw=.db44bdb4-f1e0-4cc4-b703-bdb1cab31a27@github.com>
 <FVnALi5_mJ_81qLfbIlFiQyUVWvBiYrYn6C1CauGcZ4=.5a44487c-a426-4766-8840-87e5b9a30ea1@github.com>
 <qbwk2R2_fja6bex3AD1TygQjQQouRQ8f3yw912wN08A=.d9a9eada-b313-44a5-aa83-52a8dc13dbfe@github.com>
Message-ID: <cy_64f9FeSVVRVcICPR15-yArSIxe53FrMk2qYS31MY=.223ce4bd-d2fa-46b8-bb22-0f912ccaabb1@github.com>

On Mon, 15 Mar 2021 17:34:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I thought about it earlier but I raised this PR as I don't see this method was updated from inception so I was not sure if it will be in future and also since it already says "JComponent subclasses **must** override this method" so a noop default implementation will not be a problem, I guess.
> 
> Based on the current spec we may add some kind of assertion that this method must not be called.

I'm afraid this can be interpreted in a wrong way: *never* call `JComponent.updateUI()`, which is not what we want to say, is it?

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

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

From serb at openjdk.java.net  Mon Mar 15 21:15:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 15 Mar 2021 21:15:10 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v2]
In-Reply-To: <y4g_QKJ6TcCF5gUmgqnBpMf_v-MS57c_cCltwHLYw18=.77e1a575-66f4-4a3e-96b5-468bfef2b3be@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <jHdTf9dqakyixIAXp3mRg9TZLKVTmw8pYt8VsY_rJyw=.db44bdb4-f1e0-4cc4-b703-bdb1cab31a27@github.com>
 <BaNIgS-nmXVD-TH4imLaAgZbAvsiGLcZxFCROqpQNdg=.0db0eeac-8bd7-4b63-ae3e-015bb5ba4f03@github.com>
 <y4g_QKJ6TcCF5gUmgqnBpMf_v-MS57c_cCltwHLYw18=.77e1a575-66f4-4a3e-96b5-468bfef2b3be@github.com>
Message-ID: <JNey0HfJatgJNf_tz2snaCCFhGNfL2-s5PrXNIYuPvI=.19f6c7d2-bc17-4e5b-a457-6f49245ef12b@github.com>

On Mon, 15 Mar 2021 18:06:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JComponent.java line 660:
>> 
>>> 658:     /**
>>> 659:      * Resets the UI property to a value from the current look and feel.
>>> 660:      * Since the default implementation of this method doesn't do anything,
>> 
>> The reason why this method should be overridden is that the subclasses only can implement it properly, and it is not because the current method is empty.
>> 
>> Probably we can move the new text to the @implnote tag?
>
> Yet specifying that this method is empty implies overridden methods do not need to call `super.updateUI()`.

But probably it might be changed in the future? If for example, we will move some common functionality from the standard subclasses to this method.

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

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

From aivanov at openjdk.java.net  Mon Mar 15 21:40:09 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 15 Mar 2021 21:40:09 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v2]
In-Reply-To: <JNey0HfJatgJNf_tz2snaCCFhGNfL2-s5PrXNIYuPvI=.19f6c7d2-bc17-4e5b-a457-6f49245ef12b@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <jHdTf9dqakyixIAXp3mRg9TZLKVTmw8pYt8VsY_rJyw=.db44bdb4-f1e0-4cc4-b703-bdb1cab31a27@github.com>
 <BaNIgS-nmXVD-TH4imLaAgZbAvsiGLcZxFCROqpQNdg=.0db0eeac-8bd7-4b63-ae3e-015bb5ba4f03@github.com>
 <y4g_QKJ6TcCF5gUmgqnBpMf_v-MS57c_cCltwHLYw18=.77e1a575-66f4-4a3e-96b5-468bfef2b3be@github.com>
 <JNey0HfJatgJNf_tz2snaCCFhGNfL2-s5PrXNIYuPvI=.19f6c7d2-bc17-4e5b-a457-6f49245ef12b@github.com>
Message-ID: <GZDlGw3TLMqCsNFECsdjgr7AI77s-c_QvcT-DRB3WSE=.ff8eadd4-8f9e-4c85-bb0e-0ad1fd6e2de7@github.com>

On Mon, 15 Mar 2021 21:12:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yet specifying that this method is empty implies overridden methods do not need to call `super.updateUI()`.
>
> But probably it might be changed in the future? If for example, we will move some common functionality from the standard subclasses to this method.

It hasn't changed over all these years? In addition to that, the specification says you *must* override and shows the example without calling `super.updateUI()`.
My take is it's unlikely to change. Yet I understand your concern: Stating explicitly `JComponent.updateUI` is empty, there's no way back. So being cautious wouldn't hurt. From this point of view, `@implnote` still gives some flexibility rather than being cast in stone.

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

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

From psadhukhan at openjdk.java.net  Tue Mar 16 04:22:27 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 16 Mar 2021 04:22:27 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v3]
In-Reply-To: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
Message-ID: <9WVbrtv5baEH4JOvgvQLZkODDBRI2ajgS4V6_Zka9Hg=.066073da-b76f-470a-9386-d7b97d363216@github.com>

> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  added @implnote

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2955/files
  - new: https://git.openjdk.java.net/jdk/pull/2955/files/2d5e9112..a6484203

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

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

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

From psadhukhan at openjdk.java.net  Tue Mar 16 04:27:06 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 16 Mar 2021 04:27:06 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v2]
In-Reply-To: <GZDlGw3TLMqCsNFECsdjgr7AI77s-c_QvcT-DRB3WSE=.ff8eadd4-8f9e-4c85-bb0e-0ad1fd6e2de7@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <jHdTf9dqakyixIAXp3mRg9TZLKVTmw8pYt8VsY_rJyw=.db44bdb4-f1e0-4cc4-b703-bdb1cab31a27@github.com>
 <BaNIgS-nmXVD-TH4imLaAgZbAvsiGLcZxFCROqpQNdg=.0db0eeac-8bd7-4b63-ae3e-015bb5ba4f03@github.com>
 <y4g_QKJ6TcCF5gUmgqnBpMf_v-MS57c_cCltwHLYw18=.77e1a575-66f4-4a3e-96b5-468bfef2b3be@github.com>
 <JNey0HfJatgJNf_tz2snaCCFhGNfL2-s5PrXNIYuPvI=.19f6c7d2-bc17-4e5b-a457-6f49245ef12b@github.com>
 <GZDlGw3TLMqCsNFECsdjgr7AI77s-c_QvcT-DRB3WSE=.ff8eadd4-8f9e-4c85-bb0e-0ad1fd6e2de7@github.com>
Message-ID: <Fixf9Ax9JdEqMCyJiKsIHONEYjBo0ROwOz2imrOQ-gU=.e2a7d3be-ec20-429f-aedb-b4acbec1376c@github.com>

On Mon, 15 Mar 2021 21:35:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> But probably it might be changed in the future? If for example, we will move some common functionality from the standard subclasses to this method.
>
> It hasn't changed over all these years? In addition to that, the specification says you *must* override and shows the example without calling `super.updateUI()`.
> My take is it's unlikely to change. Yet I understand your concern: Stating explicitly `JComponent.updateUI` is empty means there's no way back. So being cautious wouldn't hurt. From this point of view, `@implnote` still gives some flexibility rather than being cast in stone.

`@implnote` added

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

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

From aivanov at openjdk.java.net  Tue Mar 16 12:14:09 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 16 Mar 2021 12:14:09 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v3]
In-Reply-To: <9WVbrtv5baEH4JOvgvQLZkODDBRI2ajgS4V6_Zka9Hg=.066073da-b76f-470a-9386-d7b97d363216@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <9WVbrtv5baEH4JOvgvQLZkODDBRI2ajgS4V6_Zka9Hg=.066073da-b76f-470a-9386-d7b97d363216@github.com>
Message-ID: <55Hw-ozFF1oDwP4-efljRKHVTTN1Muzk7SOw8o42Cs4=.4f9c2842-7468-4c5e-bdc0-12db118ad866@github.com>

On Tue, 16 Mar 2021 04:22:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added @implnote

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/JComponent.java line 660:

> 658:     /**
> 659:      * Resets the UI property to a value from the current look and feel.
> 660:      * @implnote Since the default implementation of this method doesn't do anything,

Suggestion:

     * @implNote Since the default implementation of this method doesn't do anything,
The correct tag is `@implNote` with capital N.

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

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

From psadhukhan at openjdk.java.net  Tue Mar 16 12:25:34 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 16 Mar 2021 12:25:34 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v4]
In-Reply-To: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
Message-ID: <Dy3BIom_8vqFhYv1m3209PBcIyC3qUINE8equuaH3gE=.48a6f544-308a-4cde-99f0-ad49e17b1e4a@github.com>

> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Use @implNote

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2955/files
  - new: https://git.openjdk.java.net/jdk/pull/2955/files/a6484203..39c4a720

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

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

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

From psadhukhan at openjdk.java.net  Tue Mar 16 12:25:35 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 16 Mar 2021 12:25:35 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v3]
In-Reply-To: <55Hw-ozFF1oDwP4-efljRKHVTTN1Muzk7SOw8o42Cs4=.4f9c2842-7468-4c5e-bdc0-12db118ad866@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <9WVbrtv5baEH4JOvgvQLZkODDBRI2ajgS4V6_Zka9Hg=.066073da-b76f-470a-9386-d7b97d363216@github.com>
 <55Hw-ozFF1oDwP4-efljRKHVTTN1Muzk7SOw8o42Cs4=.4f9c2842-7468-4c5e-bdc0-12db118ad866@github.com>
Message-ID: <n878KVyoySTfTo3sYLo5u1ItIyb2x_5oekbzJ8VCZhU=.a6f09357-980e-4386-abcf-5ac11a963d47@github.com>

On Tue, 16 Mar 2021 12:11:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added @implnote
>
> src/java.desktop/share/classes/javax/swing/JComponent.java line 660:
> 
>> 658:     /**
>> 659:      * Resets the UI property to a value from the current look and feel.
>> 660:      * @implnote Since the default implementation of this method doesn't do anything,
> 
> Suggestion:
> 
>      * @implNote Since the default implementation of this method doesn't do anything,
> The correct tag is `@implNote` with capital N.

It was suggested to use @implnote tag and I saw that couple of places in jdk repo, we used that in Unsafe.java and TrayIcon.java so I used that, although in majority of places, @implNote is used, so I thought maybe both can be used at our discretion.
Anyway, will change to @implNote.

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

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

From aivanov at openjdk.java.net  Tue Mar 16 12:25:36 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 16 Mar 2021 12:25:36 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v2]
In-Reply-To: <Fixf9Ax9JdEqMCyJiKsIHONEYjBo0ROwOz2imrOQ-gU=.e2a7d3be-ec20-429f-aedb-b4acbec1376c@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <jHdTf9dqakyixIAXp3mRg9TZLKVTmw8pYt8VsY_rJyw=.db44bdb4-f1e0-4cc4-b703-bdb1cab31a27@github.com>
 <BaNIgS-nmXVD-TH4imLaAgZbAvsiGLcZxFCROqpQNdg=.0db0eeac-8bd7-4b63-ae3e-015bb5ba4f03@github.com>
 <y4g_QKJ6TcCF5gUmgqnBpMf_v-MS57c_cCltwHLYw18=.77e1a575-66f4-4a3e-96b5-468bfef2b3be@github.com>
 <JNey0HfJatgJNf_tz2snaCCFhGNfL2-s5PrXNIYuPvI=.19f6c7d2-bc17-4e5b-a457-6f49245ef12b@github.com>
 <GZDlGw3TLMqCsNFECsdjgr7AI77s-c_QvcT-DRB3WSE=.ff8eadd4-8f9e-4c85-bb0e-0ad1fd6e2de7@github.com>
 <Fixf9Ax9JdEqMCyJiKsIHONEYjBo0ROwOz2imrOQ-gU=.e2a7d3be-ec20-429f-aedb-b4acbec1376c@github.com>
Message-ID: <PiCVoHgq0hD13GW3vHTh3NBMR7N8ycl9uDJk9brrjUk=.15e0c68c-4f66-48c8-97ed-d54ef056b334@github.com>

On Tue, 16 Mar 2021 04:24:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It hasn't changed over all these years? In addition to that, the specification says you *must* override and shows the example without calling `super.updateUI()`.
>> My take is it's unlikely to change. Yet I understand your concern: Stating explicitly `JComponent.updateUI` is empty means there's no way back. So being cautious wouldn't hurt. From this point of view, `@implnote` still gives some flexibility rather than being cast in stone.
>
> `@implnote` added

It feels wrong with this `@implNote`.

Subclasses *must still override* the default implementation. Should this statement be included in the regular spec text as it was before? Implementation note could say, ?The default implementation doesn't do anything.?

Or alternatively, this change can be rejected at all, leaving the spec as it is now.

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

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

From aivanov at openjdk.java.net  Tue Mar 16 12:29:11 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 16 Mar 2021 12:29:11 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v3]
In-Reply-To: <n878KVyoySTfTo3sYLo5u1ItIyb2x_5oekbzJ8VCZhU=.a6f09357-980e-4386-abcf-5ac11a963d47@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <9WVbrtv5baEH4JOvgvQLZkODDBRI2ajgS4V6_Zka9Hg=.066073da-b76f-470a-9386-d7b97d363216@github.com>
 <55Hw-ozFF1oDwP4-efljRKHVTTN1Muzk7SOw8o42Cs4=.4f9c2842-7468-4c5e-bdc0-12db118ad866@github.com>
 <n878KVyoySTfTo3sYLo5u1ItIyb2x_5oekbzJ8VCZhU=.a6f09357-980e-4386-abcf-5ac11a963d47@github.com>
Message-ID: <RgYEMvg0lUptmUOLsNQ4dRfAWD8_JY34pqL9laxkYNc=.167fc5e5-abab-4b48-9784-2305ea3b902d@github.com>

On Tue, 16 Mar 2021 12:17:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JComponent.java line 660:
>> 
>>> 658:     /**
>>> 659:      * Resets the UI property to a value from the current look and feel.
>>> 660:      * @implnote Since the default implementation of this method doesn't do anything,
>> 
>> Suggestion:
>> 
>>      * @implNote Since the default implementation of this method doesn't do anything,
>> The correct tag is `@implNote` with capital N.
>
> It was suggested to use @implnote tag and I saw that couple of places in jdk repo, we used that in Unsafe.java and TrayIcon.java so I used that, although in majority of places, @implNote is used, so I thought maybe both can be used at our discretion.
> Anyway, will change to @implNote.

I understand it. I just built the docs to see how it looks and the text after `@implnote` was missing ? it's absolutely wrong this way. With `@implNote`, the text is displayed below *Implementation Note:* sub-heading.

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

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

From psadhukhan at openjdk.java.net  Tue Mar 16 12:43:06 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 16 Mar 2021 12:43:06 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v3]
In-Reply-To: <RgYEMvg0lUptmUOLsNQ4dRfAWD8_JY34pqL9laxkYNc=.167fc5e5-abab-4b48-9784-2305ea3b902d@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <9WVbrtv5baEH4JOvgvQLZkODDBRI2ajgS4V6_Zka9Hg=.066073da-b76f-470a-9386-d7b97d363216@github.com>
 <55Hw-ozFF1oDwP4-efljRKHVTTN1Muzk7SOw8o42Cs4=.4f9c2842-7468-4c5e-bdc0-12db118ad866@github.com>
 <n878KVyoySTfTo3sYLo5u1ItIyb2x_5oekbzJ8VCZhU=.a6f09357-980e-4386-abcf-5ac11a963d47@github.com>
 <RgYEMvg0lUptmUOLsNQ4dRfAWD8_JY34pqL9laxkYNc=.167fc5e5-abab-4b48-9784-2305ea3b902d@github.com>
Message-ID: <aGA74NAcPN5iZjZPaPdupVujAIVAjHrSGaXYR3cqj_4=.80ded6aa-a197-4976-a10a-a35e647ada41@github.com>

On Tue, 16 Mar 2021 12:26:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It was suggested to use @implnote tag and I saw that couple of places in jdk repo, we used that in Unsafe.java and TrayIcon.java so I used that, although in majority of places, @implNote is used, so I thought maybe both can be used at our discretion.
>> Anyway, will change to @implNote.
>
> I understand it. I just built the docs to see how it looks and the text after `@implnote` was missing ? it's absolutely wrong this way. With `@implNote`, the text is displayed below *Implementation Note:* sub-heading.

I can remove `Since` and have "@implNote The default implementation of this method doesn't do anything.
leaving other sentence `<code>JComponent</code> subclasses must override this method` separate. I guess that will keep the spec same as before and also keep the submitter satisfied.

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

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

From psadhukhan at openjdk.java.net  Tue Mar 16 12:56:19 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 16 Mar 2021 12:56:19 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v5]
In-Reply-To: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
Message-ID: <4cngvXvMR-PITjQmCKTmekcbzO7wp29PKfnW8i4XGUM=.4718b2f6-e4c4-4304-a991-a28c3ef4a473@github.com>

> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  @implNote change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2955/files
  - new: https://git.openjdk.java.net/jdk/pull/2955/files/39c4a720..50b997de

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

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

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

From serb at openjdk.java.net  Wed Mar 17 01:51:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 17 Mar 2021 01:51:10 GMT
Subject: <Swing Dev> RFR: 8262981: Create implementation for
 NSAccessibilitySlider protocol
In-Reply-To: <yaOXyCB7ZJx5mE_xkXh0bwZPQXDzusbe55a-UAYPSEk=.f1928607-0fa6-4b04-bc2b-a089acfcb628@github.com>
References: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
 <3kHCT6j_xnm9mbA2jeP35p9rY4nxOD61PInSB9mglT8=.71c3b9df-0cc3-40f7-b339-15b382e36b6f@github.com>
 <WaDY3XBH6a6nPencpEbkyZjTnX5iqzxX9wZZ5eKI6KI=.a32e0717-0736-417c-84c0-bbb858bc2e35@github.com>
 <4SZRIR695DBooSWt-1aatGx-CKPy6EwuRpXS29A8wro=.4ba37fe2-6017-482f-83c4-33d7a11fc320@github.com>
 <B0hF7cV-7O7pclnhmX7C4Biw20C5CLtIM11C6z5Tin0=.f06fa7ce-9049-454e-80f8-36935f3e0301@github.com>
 <zHiKUzH6bz3rwjjzbRQv4DgwaQ-J8FjFnTrKTKi_7kM=.5cb87998-4512-4c73-a673-038426b71171@github.com>
 <60QaQ3ISOvoR5RMWU1hTSCsiBHfy7xU2QjvLzrGaSvA=.c02ab62e-5176-4015-a16c-849a71088452@github.com>
 <yaOXyCB7ZJx5mE_xkXh0bwZPQXDzusbe55a-UAYPSEk=.f1928607-0fa6-4b04-bc2b-a089acfcb628@github.com>
Message-ID: <DCrevod6zxfkoOzlPjkMNHD1P0fDn_JTwhozVOSUWLc=.e631377d-e7f7-4a11-9dd1-6f63859ce515@github.com>

On Sun, 14 Mar 2021 11:10:09 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> It looks like the Dialog must have handled the keys as there are no special keys mentioned for JAWS to interact with the component like the VO

Did you check this list of hotkeys?
https://www.freedomscientific.com/training/jaws/hotkeys
https://freedomscientific.github.io/VFO-standards-support/aria.html
Something like:
    RIGHT ARROW and UP ARROW increase the value of the slider.
    LEFT ARROW and DOWN ARROW decrease the value of the slider.
    HOME and END move to the minimum and maximum values of the slider.
    PAGE UP and PAGE DOWN increment or decrement the slider by a given amount.

=======================
My main point is that if we will change some shared code we should care about both supported platforms.

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

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

From psadhukhan at openjdk.java.net  Wed Mar 17 07:58:06 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 17 Mar 2021 07:58:06 GMT
Subject: <Swing Dev> Integrated: 8263410: ListModel javadoc refers to
 non-existent interface
In-Reply-To: <N52F1WlX1hSNzOqAgwI10E4RTuaNE-vVGjWU_JIC040=.3e52da2f-d4a7-488c-bac4-8055971275cd@github.com>
References: <N52F1WlX1hSNzOqAgwI10E4RTuaNE-vVGjWU_JIC040=.3e52da2f-d4a7-488c-bac4-8055971275cd@github.com>
Message-ID: <wcFTJiQJyOoERN6zrruTczcdiSpx3Z4goajF44A-6bU=.b35083e3-d1da-440b-a84b-56b2cd90709d@github.com>

On Thu, 11 Mar 2021 04:32:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> ListModel class javadoc refers to ListDataModel interface but there is no ListDataModel interface. Rectified the anomaly.

This pull request has now been integrated.

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

8263410: ListModel javadoc refers to non-existent interface

Reviewed-by: azvegint, pbansal, aivanov

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

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

From psadhukhan at openjdk.java.net  Wed Mar 17 08:03:39 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 17 Mar 2021 08:03:39 GMT
Subject: <Swing Dev> RFR: 8263481: Specification of
 JComponent::setDefaultLocale doesn't mention that passing 'null' restores
 VM's default locale [v2]
In-Reply-To: <lbzrBGzrlcadhS6WspD4WHpmdYaiAQ35DF5naqDri3g=.315c49d7-e1ba-4a50-b434-9d92ff8e5b50@github.com>
References: <lbzrBGzrlcadhS6WspD4WHpmdYaiAQ35DF5naqDri3g=.315c49d7-e1ba-4a50-b434-9d92ff8e5b50@github.com>
Message-ID: <BI8XiOwMALkra374ZdT7bRXX5rbIZnQOWp0pIDXfMno=.ff29b97d-3514-4aae-bea4-d16b80848b14@github.com>

> The current state of specification for
> https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/JComponent.html#setDefaultLocale(java.util.Locale)
> doesn't mention anything about passing 'null' as a new default locale.
> 
> In fact for OpenJDK implementation passing 'null' restores the default VM's locale. 
> This is now explicitly stated in javadoc.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Test modification

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3003/files
  - new: https://git.openjdk.java.net/jdk/pull/3003/files/acc270ea..d35284f6

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

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

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

From herrick at openjdk.java.net  Wed Mar 17 15:35:49 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 17 Mar 2021 15:35:49 GMT
Subject: <Swing Dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
In-Reply-To: <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
Message-ID: <4WfIqOQTCLxtbCQnD2xn4Doku9I1K5cnZ3FOv_JfeJQ=.09c24289-7e79-4592-9043-36b3b790701f@github.com>

On Sun, 14 Mar 2021 12:06:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> the

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

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

From herrick at openjdk.java.net  Wed Mar 17 15:35:49 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 17 Mar 2021 15:35:49 GMT
Subject: <Swing Dev> Withdrawn: 8189198: Add "forRemoval = true" to Applet
 API deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <HTWVY7MhXEo0XsFT0RVMz53wTcGRnOg8SwGNghVgDtk=.7c738703-a42a-4f3e-9466-df2cf05cf2d0@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

This pull request has been closed without being integrated.

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

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

From herrick at openjdk.java.net  Wed Mar 17 16:46:49 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 17 Mar 2021 16:46:49 GMT
Subject: <Swing Dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
In-Reply-To: <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
Message-ID: <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>

On Sun, 14 Mar 2021 12:06:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 
> 
> Have you looked at narrowing the use of the SuppressWarnings to local variable declarations to avoid adding it to some of these methods?

in all cases either:
 - the class or method itself is being deprecated
 - the method takes a deprecated arg .
 - there is no local variable involved, such as testing if something  is an instanceOf a class being deprecated, or calling a deprecated method.

I cannot find any instances where the scope can be narrowed

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

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

From alanb at openjdk.java.net  Wed Mar 17 19:05:52 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 17 Mar 2021 19:05:52 GMT
Subject: <Swing Dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
In-Reply-To: <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
 <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>
Message-ID: <fDHwQZqPpR9I3bBnnq67JsK1C55ItjUaig2dmaT3PAs=.1121b4e3-7c5b-4b50-8bdc-b0f4631510d9@github.com>

On Wed, 17 Mar 2021 16:44:19 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> I cannot find any instances where the scope can be narrowed

Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged, and other non-trivial methods?

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

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

From herrick at openjdk.java.net  Wed Mar 17 20:35:54 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 17 Mar 2021 20:35:54 GMT
Subject: <Swing Dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
In-Reply-To: <fDHwQZqPpR9I3bBnnq67JsK1C55ItjUaig2dmaT3PAs=.1121b4e3-7c5b-4b50-8bdc-b0f4631510d9@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
 <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>
 <fDHwQZqPpR9I3bBnnq67JsK1C55ItjUaig2dmaT3PAs=.1121b4e3-7c5b-4b50-8bdc-b0f4631510d9@github.com>
Message-ID: <qiZi_Vbv_HUnvOdDXWkOYXX34-TZXgn5RfVZ10RKPbA=.2a14f73b-832e-4dbb-92c9-bee2ff7b62ec@github.com>

On Wed, 17 Mar 2021 19:02:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 
> 
> > I cannot find any instances where the scope can be narrowed
> 
> Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged, and other non-trivial methods?

These have the code pattern such as: 
} else if (c instanceof JApplet) {
putting '@SuppressWarnings("removal")' before the declaration of 'c' does not help, because the code is not an assignment to 'c'

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

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

From psadhukhan at openjdk.java.net  Thu Mar 18 04:51:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 18 Mar 2021 04:51:56 GMT
Subject: <Swing Dev> RFR: 8263768:
 JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
 spec doesn't mention what the default impls return and what does it mean
Message-ID: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>

Default implementation of JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() returns null but it is not mentioned in the spec.
It is now explicitly mentioned in the spec by @impNote tag.

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

Commit messages:
 - 8263768: JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() spec doesn't mention what the default impls return and what does it mean

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

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

From aivanov at openjdk.java.net  Thu Mar 18 10:55:39 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 18 Mar 2021 10:55:39 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v2]
In-Reply-To: <PiCVoHgq0hD13GW3vHTh3NBMR7N8ycl9uDJk9brrjUk=.15e0c68c-4f66-48c8-97ed-d54ef056b334@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <jHdTf9dqakyixIAXp3mRg9TZLKVTmw8pYt8VsY_rJyw=.db44bdb4-f1e0-4cc4-b703-bdb1cab31a27@github.com>
 <BaNIgS-nmXVD-TH4imLaAgZbAvsiGLcZxFCROqpQNdg=.0db0eeac-8bd7-4b63-ae3e-015bb5ba4f03@github.com>
 <y4g_QKJ6TcCF5gUmgqnBpMf_v-MS57c_cCltwHLYw18=.77e1a575-66f4-4a3e-96b5-468bfef2b3be@github.com>
 <JNey0HfJatgJNf_tz2snaCCFhGNfL2-s5PrXNIYuPvI=.19f6c7d2-bc17-4e5b-a457-6f49245ef12b@github.com>
 <GZDlGw3TLMqCsNFECsdjgr7AI77s-c_QvcT-DRB3WSE=.ff8eadd4-8f9e-4c85-bb0e-0ad1fd6e2de7@github.com>
 <Fixf9Ax9JdEqMCyJiKsIHONEYjBo0ROwOz2imrOQ-gU=.e2a7d3be-ec20-429f-aedb-b4acbec1376c@github.com>
 <PiCVoHgq0hD13GW3vHTh3NBMR7N8ycl9uDJk9brrjUk=.15e0c68c-4f66-48c8-97ed-d54ef056b334@github.com>
Message-ID: <jRzZR4B50tshBCO40weCZaQDmIDEXBwLC2BfZ0EBNWQ=.298e5f07-6488-41e0-af23-b3d3de3c7142@github.com>

On Tue, 16 Mar 2021 12:22:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> `@implnote` added
>
> It feels wrong with this `@implNote`.
> 
> Subclasses *must still override* the default implementation. Should this statement be included in the regular spec text as it was before? Implementation note could say, ?The default implementation doesn't do anything.?
> 
> Or alternatively, this change can be rejected at all, leaving the spec as it is now.

> It feels wrong with this `@implNote`.
> 
> Subclasses _must still override_ the default implementation. Should this statement be included in the regular spec text as it was before? Implementation note could say, ?The default implementation doesn't do anything.?
> 
> Or alternatively, this change can be rejected at all, leaving the spec as it is now.

To make it clearer, what I suggest is keeping the old text as it was and adding `@implNote` below like this:
    /**
     * Resets the UI property to a value from the current look and feel.
     * <code>JComponent</code> subclasses must override this method
     * like this:
     * <pre>
     *   public void updateUI() {
     *      setUI((SliderUI)UIManager.getUI(this);
     *   }
     *  </pre>
     * 
     * @implNote The default implementation of this method doesn't do anything.
     *
     * @see #setUI
     * @see UIManager#getLookAndFeel
     * @see UIManager#getUI
     */

This way, it's more *highlighted* that `JComponent` subclasses must override `updateUI` as shown for the correct behaviour. Then the implementation note will add the missing detail: The default implementation does nothing. So it's not necessary to call the super method from the overridden one.

What do you, @prsadhuk and @mrserb, think?

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

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

From psadhukhan at openjdk.java.net  Thu Mar 18 10:59:41 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 18 Mar 2021 10:59:41 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v2]
In-Reply-To: <jRzZR4B50tshBCO40weCZaQDmIDEXBwLC2BfZ0EBNWQ=.298e5f07-6488-41e0-af23-b3d3de3c7142@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <jHdTf9dqakyixIAXp3mRg9TZLKVTmw8pYt8VsY_rJyw=.db44bdb4-f1e0-4cc4-b703-bdb1cab31a27@github.com>
 <BaNIgS-nmXVD-TH4imLaAgZbAvsiGLcZxFCROqpQNdg=.0db0eeac-8bd7-4b63-ae3e-015bb5ba4f03@github.com>
 <y4g_QKJ6TcCF5gUmgqnBpMf_v-MS57c_cCltwHLYw18=.77e1a575-66f4-4a3e-96b5-468bfef2b3be@github.com>
 <JNey0HfJatgJNf_tz2snaCCFhGNfL2-s5PrXNIYuPvI=.19f6c7d2-bc17-4e5b-a457-6f49245ef12b@github.com>
 <GZDlGw3TLMqCsNFECsdjgr7AI77s-c_QvcT-DRB3WSE=.ff8eadd4-8f9e-4c85-bb0e-0ad1fd6e2de7@github.com>
 <Fixf9Ax9JdEqMCyJiKsIHONEYjBo0ROwOz2imrOQ-gU=.e2a7d3be-ec20-429f-aedb-b4acbec1376c@github.com>
 <PiCVoHgq0hD13GW3vHTh3NBMR7N8ycl9uDJk9brrjUk=.15e0c68c-4f66-48c8-97ed-d54ef056b334@github.com>
 <jRzZR4B50tshBCO40weCZaQDmIDEXBwLC2BfZ0EBNWQ=.298e5f07-6488-41e0-af23-b3d3de3c7142@github.com>
Message-ID: <w1bRcIqGzCG2nuZkiOK-S9VDjJkYmT9p7sn_QKI7Gls=.74f1ea0a-e3a7-4cfc-aa91-d9f39bc1d9b1@github.com>

On Thu, 18 Mar 2021 10:52:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It feels wrong with this `@implNote`.
>> 
>> Subclasses *must still override* the default implementation. Should this statement be included in the regular spec text as it was before? Implementation note could say, ?The default implementation doesn't do anything.?
>> 
>> Or alternatively, this change can be rejected at all, leaving the spec as it is now.
>
>> It feels wrong with this `@implNote`.
>> 
>> Subclasses _must still override_ the default implementation. Should this statement be included in the regular spec text as it was before? Implementation note could say, ?The default implementation doesn't do anything.?
>> 
>> Or alternatively, this change can be rejected at all, leaving the spec as it is now.
> 
> To make it clearer, what I suggest is keeping the old text as it was and adding `@implNote` below like this:
>     /**
>      * Resets the UI property to a value from the current look and feel.
>      * <code>JComponent</code> subclasses must override this method
>      * like this:
>      * <pre>
>      *   public void updateUI() {
>      *      setUI((SliderUI)UIManager.getUI(this);
>      *   }
>      *  </pre>
>      * 
>      * @implNote The default implementation of this method doesn't do anything.
>      *
>      * @see #setUI
>      * @see UIManager#getLookAndFeel
>      * @see UIManager#getUI
>      */
> 
> This way, it's more *highlighted* that `JComponent` subclasses must override `updateUI` as shown for the correct behaviour. Then the implementation note will add the missing detail: The default implementation does nothing. So it's not necessary to call the super method from the overridden one.
> 
> What do you, @prsadhuk and @mrserb, think?

OK. Seems fair enough for me.

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

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

From psadhukhan at openjdk.java.net  Thu Mar 18 11:05:55 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 18 Mar 2021 11:05:55 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v6]
In-Reply-To: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
Message-ID: <ZD-sx489PP2iAqzOFRhPi_UEavVIO7LH4Cr_Mv6zr5E=.bc71a153-e920-4611-843c-4e9df3c64a05@github.com>

> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - javadoc change
 - implNote change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2955/files
  - new: https://git.openjdk.java.net/jdk/pull/2955/files/50b997de..5b15e87f

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

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

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

From aivanov at openjdk.java.net  Thu Mar 18 11:09:39 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 18 Mar 2021 11:09:39 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v6]
In-Reply-To: <ZD-sx489PP2iAqzOFRhPi_UEavVIO7LH4Cr_Mv6zr5E=.bc71a153-e920-4611-843c-4e9df3c64a05@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <ZD-sx489PP2iAqzOFRhPi_UEavVIO7LH4Cr_Mv6zr5E=.bc71a153-e920-4611-843c-4e9df3c64a05@github.com>
Message-ID: <U7SGB0FdTbRFmx3W4oEZc_nQFYK9YKFH-j0YmUrHGqY=.0b17abf2-27f4-4a6a-8042-cb016571c03e@github.com>

On Thu, 18 Mar 2021 11:05:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - javadoc change
>  - implNote change

Marked as reviewed by aivanov (Reviewer).

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

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

From trebari at openjdk.java.net  Thu Mar 18 13:10:42 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Thu, 18 Mar 2021 13:10:42 GMT
Subject: <Swing Dev> RFR: 8263768:
 JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
 spec doesn't mention what the default impls return and what does it mean
In-Reply-To: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
References: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
Message-ID: <pEy4s8gJSpgu4tjN2OoJf-p6v-BbvJXwQGNBJq5965I=.a4cee30b-25f6-4f25-82c4-5a0216e3096c@github.com>

On Thu, 18 Mar 2021 04:46:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Default implementation of JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() returns null but it is not mentioned in the spec.
> It is now explicitly mentioned in the spec by @impNote tag.

Marked as reviewed by trebari (Committer).

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

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

From aivanov at openjdk.java.net  Thu Mar 18 22:19:39 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 18 Mar 2021 22:19:39 GMT
Subject: <Swing Dev> RFR: 8263481: Specification of
 JComponent::setDefaultLocale doesn't mention that passing 'null' restores
 VM's default locale [v2]
In-Reply-To: <BI8XiOwMALkra374ZdT7bRXX5rbIZnQOWp0pIDXfMno=.ff29b97d-3514-4aae-bea4-d16b80848b14@github.com>
References: <lbzrBGzrlcadhS6WspD4WHpmdYaiAQ35DF5naqDri3g=.315c49d7-e1ba-4a50-b434-9d92ff8e5b50@github.com>
 <BI8XiOwMALkra374ZdT7bRXX5rbIZnQOWp0pIDXfMno=.ff29b97d-3514-4aae-bea4-d16b80848b14@github.com>
Message-ID: <-mFsKDI0yNsYS5snBu1gYkIQIQJHjezEWGtjlmJA2ts=.5a13a35a-c0f7-4632-a3ab-ea389cde2428@github.com>

On Wed, 17 Mar 2021 08:03:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The current state of specification for
>> https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/JComponent.html#setDefaultLocale(java.util.Locale)
>> doesn't mention anything about passing 'null' as a new default locale.
>> 
>> In fact for OpenJDK implementation passing 'null' restores the default VM's locale. 
>> This is now explicitly stated in javadoc.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test modification

Marked as reviewed by aivanov (Reviewer).

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

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

From aivanov at openjdk.java.net  Thu Mar 18 22:23:37 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 18 Mar 2021 22:23:37 GMT
Subject: <Swing Dev> RFR: 8263768:
 JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
 spec doesn't mention what the default impls return and what does it mean
In-Reply-To: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
References: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
Message-ID: <zhvQBC-vOrauxHsecAbHlcPOiQlbWrmJpqhrOgseFaY=.c5ed6085-2a70-4434-a208-3789430288db@github.com>

On Thu, 18 Mar 2021 04:46:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Default implementation of JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() returns null but it is not mentioned in the spec.
> It is now explicitly mentioned in the spec by @impNote tag.

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/JFormattedTextField.java line 1089:

> 1087: 
> 1088:         /**
> 1089:          * @implNote Default implementation returns null.

I suggest moving `@implNote` to the end of the spec, otherwise the entire spec is the implementation note, which is wrong, isn't it?

Suggestion:

         * @implNote The default implementation returns <code>null</code>.
It requires the definite article.

Both points above also apply to `getNavigationFilter` method below.

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

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

From serb at openjdk.java.net  Thu Mar 18 22:52:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 18 Mar 2021 22:52:40 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v6]
In-Reply-To: <U7SGB0FdTbRFmx3W4oEZc_nQFYK9YKFH-j0YmUrHGqY=.0b17abf2-27f4-4a6a-8042-cb016571c03e@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <ZD-sx489PP2iAqzOFRhPi_UEavVIO7LH4Cr_Mv6zr5E=.bc71a153-e920-4611-843c-4e9df3c64a05@github.com>
 <U7SGB0FdTbRFmx3W4oEZc_nQFYK9YKFH-j0YmUrHGqY=.0b17abf2-27f4-4a6a-8042-cb016571c03e@github.com>
Message-ID: <KLPpDM2kyotC-enhwAK-dBui2IB9kZRjEnvOsl4M8Ko=.f70d2114-fcd2-42a1-b25a-8a9ca06a824a@github.com>

On Thu, 18 Mar 2021 11:07:14 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - javadoc change
>>  - implNote change
>
> Marked as reviewed by aivanov (Reviewer).

Do we need a CSR?

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

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

From psadhukhan at openjdk.java.net  Fri Mar 19 04:31:41 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 19 Mar 2021 04:31:41 GMT
Subject: <Swing Dev> Integrated: 8263481: Specification of
 JComponent::setDefaultLocale doesn't mention that passing 'null' restores
 VM's default locale
In-Reply-To: <lbzrBGzrlcadhS6WspD4WHpmdYaiAQ35DF5naqDri3g=.315c49d7-e1ba-4a50-b434-9d92ff8e5b50@github.com>
References: <lbzrBGzrlcadhS6WspD4WHpmdYaiAQ35DF5naqDri3g=.315c49d7-e1ba-4a50-b434-9d92ff8e5b50@github.com>
Message-ID: <Ud3MAmAy-FGWF8VoRYYJSTBekpY2iko3-nmIDvjXauQ=.6ddbd997-3ee1-46f7-b64d-4c13ae6db92a@github.com>

On Mon, 15 Mar 2021 06:52:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The current state of specification for
> https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/JComponent.html#setDefaultLocale(java.util.Locale)
> doesn't mention anything about passing 'null' as a new default locale.
> 
> In fact for OpenJDK implementation passing 'null' restores the default VM's locale. 
> This is now explicitly stated in javadoc.

This pull request has now been integrated.

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

8263481: Specification of JComponent::setDefaultLocale doesn't mention that passing 'null' restores VM's default locale

Reviewed-by: aivanov

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

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

From psadhukhan at openjdk.java.net  Fri Mar 19 04:40:38 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 19 Mar 2021 04:40:38 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v6]
In-Reply-To: <KLPpDM2kyotC-enhwAK-dBui2IB9kZRjEnvOsl4M8Ko=.f70d2114-fcd2-42a1-b25a-8a9ca06a824a@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <ZD-sx489PP2iAqzOFRhPi_UEavVIO7LH4Cr_Mv6zr5E=.bc71a153-e920-4611-843c-4e9df3c64a05@github.com>
 <U7SGB0FdTbRFmx3W4oEZc_nQFYK9YKFH-j0YmUrHGqY=.0b17abf2-27f4-4a6a-8042-cb016571c03e@github.com>
 <KLPpDM2kyotC-enhwAK-dBui2IB9kZRjEnvOsl4M8Ko=.f70d2114-fcd2-42a1-b25a-8a9ca06a824a@github.com>
Message-ID: <WSG1yahW7RtfRp0nc2X3USfeHrjoetgkuA4LN1hdhT8=.a261984f-bfe3-456e-9c0f-22673837c978@github.com>

On Thu, 18 Mar 2021 22:50:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Marked as reviewed by aivanov (Reviewer).
>
> Do we need a CSR?

I have added CSR just in case...https://bugs.openjdk.java.net/browse/JDK-8263845....please review

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

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

From psadhukhan at openjdk.java.net  Fri Mar 19 08:59:12 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 19 Mar 2021 08:59:12 GMT
Subject: <Swing Dev> RFR: 8263768:
 JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
 spec doesn't mention what the default impls return and what does it mean
 [v2]
In-Reply-To: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
References: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
Message-ID: <N0FZ-hVvglTTeucQXFFnwV-qwuRoZfVyAgOOb1ChyoU=.148e9d30-daa7-4c78-8e5d-c554f3eeeb23@github.com>

> Default implementation of JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() returns null but it is not mentioned in the spec.
> It is now explicitly mentioned in the spec by @impNote tag.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  @implNote change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3064/files
  - new: https://git.openjdk.java.net/jdk/pull/3064/files/e2b547b2..4ffa0d08

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

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

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

From aivanov at openjdk.java.net  Fri Mar 19 11:07:40 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 19 Mar 2021 11:07:40 GMT
Subject: <Swing Dev> RFR: 8263768:
 JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
 spec doesn't mention what the default impls return and what does it mean
 [v2]
In-Reply-To: <N0FZ-hVvglTTeucQXFFnwV-qwuRoZfVyAgOOb1ChyoU=.148e9d30-daa7-4c78-8e5d-c554f3eeeb23@github.com>
References: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
 <N0FZ-hVvglTTeucQXFFnwV-qwuRoZfVyAgOOb1ChyoU=.148e9d30-daa7-4c78-8e5d-c554f3eeeb23@github.com>
Message-ID: <SnKffsugbIM1MpnYB-sj3W6Kfm_wsukgQ9znAEINZTY=.b1c8e8a6-0531-4d59-8157-93a678e13ed5@github.com>

On Fri, 19 Mar 2021 08:59:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Default implementation of JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() returns null but it is not mentioned in the spec.
>> It is now explicitly mentioned in the spec by @impNote tag.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @implNote change

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/JFormattedTextField.java line 1089:

> 1087: 
> 1088:         /**
> 1089:          * Subclass must override if you wish to provide a

It think the original text was correct: Subclass was used as a verb in imperative. You have to *subclass* before you can override.

src/java.desktop/share/classes/javax/swing/JFormattedTextField.java line 1108:

> 1106:          * the <code>JFormattedTextField</code>.
> 1107:          *
> 1108:          * @implNote The default implementation returns <code>null</code>

Suggestion:

         * @implNote The default implementation returns <code>null</code>.
Full stop for consistency.

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

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

From psadhukhan at openjdk.java.net  Fri Mar 19 11:15:03 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 19 Mar 2021 11:15:03 GMT
Subject: <Swing Dev> RFR: 8263768:
 JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
 spec doesn't mention what the default impls return and what does it mean
 [v3]
In-Reply-To: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
References: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
Message-ID: <vKareGGIk17T85oXUUphlI8wEOCH7QdRJ1gqB1q5mV8=.73a86e17-7403-4c27-91af-585334450d85@github.com>

> Default implementation of JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() returns null but it is not mentioned in the spec.
> It is now explicitly mentioned in the spec by @impNote tag.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  @implNote added

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3064/files
  - new: https://git.openjdk.java.net/jdk/pull/3064/files/4ffa0d08..cea2f171

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

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

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

From aivanov at openjdk.java.net  Fri Mar 19 11:21:38 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 19 Mar 2021 11:21:38 GMT
Subject: <Swing Dev> RFR: 8263768:
 JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
 spec doesn't mention what the default impls return and what does it mean
 [v3]
In-Reply-To: <vKareGGIk17T85oXUUphlI8wEOCH7QdRJ1gqB1q5mV8=.73a86e17-7403-4c27-91af-585334450d85@github.com>
References: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
 <vKareGGIk17T85oXUUphlI8wEOCH7QdRJ1gqB1q5mV8=.73a86e17-7403-4c27-91af-585334450d85@github.com>
Message-ID: <4Bc-fJWQEMC_co3jPFFn69o3LGujydfNjstWqlR7-qk=.f2da0b4d-0028-40b8-aab4-0a80c7717d19@github.com>

On Fri, 19 Mar 2021 11:15:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Default implementation of JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() returns null but it is not mentioned in the spec.
>> It is now explicitly mentioned in the spec by @impNote tag.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @implNote added

Marked as reviewed by aivanov (Reviewer).

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

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

From azvegint at openjdk.java.net  Fri Mar 19 19:52:41 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 19 Mar 2021 19:52:41 GMT
Subject: <Swing Dev> RFR: 8263768:
 JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
 spec doesn't mention what the default impls return and what does it mean
 [v3]
In-Reply-To: <vKareGGIk17T85oXUUphlI8wEOCH7QdRJ1gqB1q5mV8=.73a86e17-7403-4c27-91af-585334450d85@github.com>
References: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
 <vKareGGIk17T85oXUUphlI8wEOCH7QdRJ1gqB1q5mV8=.73a86e17-7403-4c27-91af-585334450d85@github.com>
Message-ID: <WKRwbKqFSTVsbfyZKjLZ-2fn3iuSoEWmyVLXmXrCTMM=.f2073aa2-f536-4dd3-95ee-f81c8fa9c2b4@github.com>

On Fri, 19 Mar 2021 11:15:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Default implementation of JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() returns null but it is not mentioned in the spec.
>> It is now explicitly mentioned in the spec by @impNote tag.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @implNote added

The bug's title is `JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() spec doesn't mention what the default impls return and what does it mean`
The fix mentions what default implementation returns, but it looks like `what does it mean` is still not addressed.

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

Marked as reviewed by azvegint (Reviewer).

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

From serb at openjdk.java.net  Fri Mar 19 22:43:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 19 Mar 2021 22:43:40 GMT
Subject: <Swing Dev> RFR: 8263768:
 JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
 spec doesn't mention what the default impls return and what does it mean
 [v3]
In-Reply-To: <WKRwbKqFSTVsbfyZKjLZ-2fn3iuSoEWmyVLXmXrCTMM=.f2073aa2-f536-4dd3-95ee-f81c8fa9c2b4@github.com>
References: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
 <vKareGGIk17T85oXUUphlI8wEOCH7QdRJ1gqB1q5mV8=.73a86e17-7403-4c27-91af-585334450d85@github.com>
 <WKRwbKqFSTVsbfyZKjLZ-2fn3iuSoEWmyVLXmXrCTMM=.f2073aa2-f536-4dd3-95ee-f81c8fa9c2b4@github.com>
Message-ID: <tyTBtYV3MS1x4g-0VzeV_roKgWxiLvx5Oy_cCt1B7Wo=.2d3e806e-d58d-43a4-9fcf-c587e5705ba5@github.com>

On Fri, 19 Mar 2021 19:50:20 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @implNote added
>
> The bug's title is `JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() spec doesn't mention what the default impls return and what does it mean`
> The fix mentions what default implementation returns, but it looks like `what does it mean` is still not addressed.

csr?

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

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

From psadhukhan at openjdk.java.net  Mon Mar 22 04:36:00 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 22 Mar 2021 04:36:00 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 doesn't mention that the original implementaiton does nothing [v7]
In-Reply-To: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
Message-ID: <cFJSTsq6SU8TGsBnAz4OeAp_I-f6D3v9qAEUm4h_2VQ=.c70acd05-6258-4fc4-90fa-6148b14d9da4@github.com>

> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Modified as per Phil's comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2955/files
  - new: https://git.openjdk.java.net/jdk/pull/2955/files/5b15e87f..36cccdab

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

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

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

From psadhukhan at openjdk.java.net  Mon Mar 22 05:01:43 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 22 Mar 2021 05:01:43 GMT
Subject: <Swing Dev> RFR: 8263768:
 JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
 spec doesn't mention what the default impls return and what does it mean
 [v3]
In-Reply-To: <tyTBtYV3MS1x4g-0VzeV_roKgWxiLvx5Oy_cCt1B7Wo=.2d3e806e-d58d-43a4-9fcf-c587e5705ba5@github.com>
References: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
 <vKareGGIk17T85oXUUphlI8wEOCH7QdRJ1gqB1q5mV8=.73a86e17-7403-4c27-91af-585334450d85@github.com>
 <WKRwbKqFSTVsbfyZKjLZ-2fn3iuSoEWmyVLXmXrCTMM=.f2073aa2-f536-4dd3-95ee-f81c8fa9c2b4@github.com>
 <tyTBtYV3MS1x4g-0VzeV_roKgWxiLvx5Oy_cCt1B7Wo=.2d3e806e-d58d-43a4-9fcf-c587e5705ba5@github.com>
Message-ID: <N-FGelliGfuU1C6eKO7sECQm4zHdkMYU-s2ctlK9nf0=.5534c5d0-8be3-4853-affe-879c843f643a@github.com>

On Fri, 19 Mar 2021 22:40:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The bug's title is `JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() spec doesn't mention what the default impls return and what does it mean`
>> The fix mentions what default implementation returns, but it looks like `what does it mean` is still not addressed.
>
> csr?

Added CSR https://bugs.openjdk.java.net/browse/JDK-8263922...Please review..

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

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

From shade at openjdk.java.net  Mon Mar 22 15:45:58 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 22 Mar 2021 15:45:58 GMT
Subject: <Swing Dev> RFR: 8263977: GTK L&F: Cleanup duplicate checks in
 GTKStyle and GTKLookAndFeel
Message-ID: <ooySEK-401Bvzy5LUTAIx9YD0yAQOqaONJpIsjBG4p8=.a6f8d1b4-0da8-4ce3-98ea-bdaee0ae5586@github.com>

SonarCloud reports a few minor problems in GTKStyle and GTKLookAndFeel: Correct one of the identical sub-expressions on both sides of operator "||".

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

Commit messages:
 - 8263977: GTK L&F: Cleanup duplicate checks in GTKStyle and GTKLookAndFeel

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

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

From serb at openjdk.java.net  Mon Mar 22 17:29:45 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 22 Mar 2021 17:29:45 GMT
Subject: <Swing Dev> RFR: 8263977: GTK L&F: Cleanup duplicate checks in
 GTKStyle and GTKLookAndFeel
In-Reply-To: <ooySEK-401Bvzy5LUTAIx9YD0yAQOqaONJpIsjBG4p8=.a6f8d1b4-0da8-4ce3-98ea-bdaee0ae5586@github.com>
References: <ooySEK-401Bvzy5LUTAIx9YD0yAQOqaONJpIsjBG4p8=.a6f8d1b4-0da8-4ce3-98ea-bdaee0ae5586@github.com>
Message-ID: <J2-TdHvXQ8LEtVMqiz00OXJlAF-QMXWc7k26R_cftDo=.f7b71f65-ea23-4f24-8c26-daf54a2105f7@github.com>

On Mon, 22 Mar 2021 15:40:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports a few minor problems in GTKStyle and GTKLookAndFeel: Correct one of the identical sub-expressions on both sides of operator "||".

Looks fine, please update the dates.

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

Marked as reviewed by serb (Reviewer).

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

From pbansal at openjdk.java.net  Mon Mar 22 17:35:47 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 22 Mar 2021 17:35:47 GMT
Subject: <Swing Dev> RFR: 8263977: GTK L&F: Cleanup duplicate checks in
 GTKStyle and GTKLookAndFeel
In-Reply-To: <ooySEK-401Bvzy5LUTAIx9YD0yAQOqaONJpIsjBG4p8=.a6f8d1b4-0da8-4ce3-98ea-bdaee0ae5586@github.com>
References: <ooySEK-401Bvzy5LUTAIx9YD0yAQOqaONJpIsjBG4p8=.a6f8d1b4-0da8-4ce3-98ea-bdaee0ae5586@github.com>
Message-ID: <-55PXhSDbQ2uuB8JJim6vhfx4pOH_SxS62wpmG0QHVc=.50f95742-c8d6-4ff8-81ce-72762817163d@github.com>

On Mon, 22 Mar 2021 15:40:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports a few minor problems in GTKStyle and GTKLookAndFeel: Correct one of the identical sub-expressions on both sides of operator "||".

Marked as reviewed by pbansal (Reviewer).

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

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

From kizune at openjdk.java.net  Mon Mar 22 17:35:48 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 22 Mar 2021 17:35:48 GMT
Subject: <Swing Dev> RFR: 8263977: GTK L&F: Cleanup duplicate checks in
 GTKStyle and GTKLookAndFeel
In-Reply-To: <ooySEK-401Bvzy5LUTAIx9YD0yAQOqaONJpIsjBG4p8=.a6f8d1b4-0da8-4ce3-98ea-bdaee0ae5586@github.com>
References: <ooySEK-401Bvzy5LUTAIx9YD0yAQOqaONJpIsjBG4p8=.a6f8d1b4-0da8-4ce3-98ea-bdaee0ae5586@github.com>
Message-ID: <Y5MlekdEhNBIYLqqU6OfqfWt-ABMw9UF1VBtIWdZ3rM=.99920a55-f671-4b3a-aab9-ae4660766e1f@github.com>

On Mon, 22 Mar 2021 15:40:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports a few minor problems in GTKStyle and GTKLookAndFeel: Correct one of the identical sub-expressions on both sides of operator "||".

Marked as reviewed by kizune (Reviewer).

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

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

From shade at openjdk.java.net  Mon Mar 22 18:25:57 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 22 Mar 2021 18:25:57 GMT
Subject: <Swing Dev> RFR: 8263977: GTK L&F: Cleanup duplicate checks in
 GTKStyle and GTKLookAndFeel [v2]
In-Reply-To: <ooySEK-401Bvzy5LUTAIx9YD0yAQOqaONJpIsjBG4p8=.a6f8d1b4-0da8-4ce3-98ea-bdaee0ae5586@github.com>
References: <ooySEK-401Bvzy5LUTAIx9YD0yAQOqaONJpIsjBG4p8=.a6f8d1b4-0da8-4ce3-98ea-bdaee0ae5586@github.com>
Message-ID: <EfbYycLcNmji7AKJTTdlTr2J5lqR2lttdqAJqhlvL6I=.3500e15f-2eec-43cb-b92b-c41b3a336ff3@github.com>

> SonarCloud reports a few minor problems in GTKStyle and GTKLookAndFeel: Correct one of the identical sub-expressions on both sides of operator "||".

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Update copyrights

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3121/files
  - new: https://git.openjdk.java.net/jdk/pull/3121/files/285cefc5..2c434a57

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

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

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

From pbansal at openjdk.java.net  Mon Mar 22 19:30:52 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 22 Mar 2021 19:30:52 GMT
Subject: <Swing Dev> RFR: 8263977: GTK L&F: Cleanup duplicate checks in
 GTKStyle and GTKLookAndFeel [v2]
In-Reply-To: <EfbYycLcNmji7AKJTTdlTr2J5lqR2lttdqAJqhlvL6I=.3500e15f-2eec-43cb-b92b-c41b3a336ff3@github.com>
References: <ooySEK-401Bvzy5LUTAIx9YD0yAQOqaONJpIsjBG4p8=.a6f8d1b4-0da8-4ce3-98ea-bdaee0ae5586@github.com>
 <EfbYycLcNmji7AKJTTdlTr2J5lqR2lttdqAJqhlvL6I=.3500e15f-2eec-43cb-b92b-c41b3a336ff3@github.com>
Message-ID: <zrNy0YuXw19Xr-u66yPMLu0H7jW-8bouhMw_ND_LJlM=.2bb406a7-e0f3-4c7c-9932-2195602e6ea2@github.com>

On Mon, 22 Mar 2021 18:25:57 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> SonarCloud reports a few minor problems in GTKStyle and GTKLookAndFeel: Correct one of the identical sub-expressions on both sides of operator "||".
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyrights

Marked as reviewed by pbansal (Reviewer).

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

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

From azvegint at openjdk.java.net  Mon Mar 22 22:25:51 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 22 Mar 2021 22:25:51 GMT
Subject: <Swing Dev> RFR: 8263454: com.apple.laf.AquaFileChooserUI ignores
 the result of String.trim()
Message-ID: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>

Looks like the original idea was to set `fallbacktext` on strings containing only spaces.

I decided to remove the `trim()` call to keep the same behavior and to allows to set such meaningless space only titles/tooltips(same as on other platforms, maybe someone want empty label for some reason).

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

Commit messages:
 - initial

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

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

From serb at openjdk.java.net  Mon Mar 22 22:34:38 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 22 Mar 2021 22:34:38 GMT
Subject: <Swing Dev> RFR: 8263454: com.apple.laf.AquaFileChooserUI
 ignores the result of String.trim()
In-Reply-To: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
References: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
Message-ID: <w83imLT0p7WuVdAsgYZSDe3nVXdBsdF7ZUfWVRe5V2Q=.c50ff17f-f095-4731-864f-7e99beb73b43@github.com>

On Mon, 22 Mar 2021 22:19:18 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Looks like the original idea was to set `fallbacktext` on strings containing only spaces.
> 
> I decided to remove the `trim()` call to keep the same behavior and to allows to set such meaningless space only titles/tooltips(same as on other platforms, maybe someone want empty label for some reason).

Marked as reviewed by serb (Reviewer).

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

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

From pbansal at openjdk.java.net  Tue Mar 23 04:55:40 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 23 Mar 2021 04:55:40 GMT
Subject: <Swing Dev> RFR: 8263454: com.apple.laf.AquaFileChooserUI
 ignores the result of String.trim()
In-Reply-To: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
References: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
Message-ID: <1XGtSANAL_K0KnV0pUsrIfNX8OlcX4DsPaZk7bMZR20=.c8ef8358-cd11-4684-94d4-ac5c742b7e7c@github.com>

On Mon, 22 Mar 2021 22:19:18 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Looks like the original idea was to set `fallbacktext` on strings containing only spaces.
> 
> I decided to remove the `trim()` call to keep the same behavior and to allows to set such meaningless space only titles/tooltips(same as on other platforms, maybe someone want empty label for some reason).

Marked as reviewed by pbansal (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Tue Mar 23 05:03:41 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 23 Mar 2021 05:03:41 GMT
Subject: <Swing Dev> RFR: 8263454: com.apple.laf.AquaFileChooserUI
 ignores the result of String.trim()
In-Reply-To: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
References: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
Message-ID: <SOskF3ImbIQoKQ1BsVouDc0Fzigvgk_qn4to34PdrlM=.0aa5ab72-fac2-4b42-8cb5-27269250d3ef@github.com>

On Mon, 22 Mar 2021 22:19:18 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Looks like the original idea was to set `fallbacktext` on strings containing only spaces.
> 
> I decided to remove the `trim()` call to keep the same behavior and to allows to set such meaningless space only titles/tooltips(same as on other platforms, maybe someone want empty label for some reason).

src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java line 2059:

> 2057:             final String tooltipText = fc.getApproveButtonToolTipText();
> 2058:             if (tooltipText != null) {
> 2059:                 if (!tooltipText.isEmpty()) return tooltipText;

In other L&F like Metal, Basic even empty text is allowed.. there's no check for isEmpty()....Should we do the same here too?

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

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

From psadhukhan at openjdk.java.net  Tue Mar 23 05:58:55 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 23 Mar 2021 05:58:55 GMT
Subject: <Swing Dev> RFR: 8263766: Confusing specification of
 JEditorPaneAccessibleHypertextSupport constructor
Message-ID: <V4FmD14OljdG_TOcqU2qXmAB-MWdaM6ttM1iSIlNUfM=.fc4e5a14-2e5a-4cf3-8f5a-9b90cc5fcaa9@github.com>

The constructor JEditorPaneAccessibleHypertextSupport  javadoc wording is wrong. Rectified the anomaly.

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

Commit messages:
 - 8263766: Confusing specification of JEditorPaneAccessibleHypertextSupport constructor

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

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

From psadhukhan at openjdk.java.net  Tue Mar 23 06:15:55 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 23 Mar 2021 06:15:55 GMT
Subject: <Swing Dev> RFR: 8263907: Specification of
 CellRendererPane::paintComponent(..Rectangle) should clearly mention which
 method it delegates the call to
Message-ID: <N9rI-cIDRLk6MO9Kp6i-PnlS6wDhdyIMl11c_sRg7Is=.9dab0ee5-54ef-4fb1-9f98-3ec0fa860e37@github.com>

Specification for method
javax/swing/CellRendererPane.html#paintComponent(java.awt.Graphics,java.awt.Component,java.awt.Container,java.awt.Rectangle)
is not perfectly clear which method the call is delegated to. 

Updated spec to clarify.

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

Commit messages:
 - 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to

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

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

From shade at openjdk.java.net  Tue Mar 23 06:57:51 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 23 Mar 2021 06:57:51 GMT
Subject: <Swing Dev> Integrated: 8263977: GTK L&F: Cleanup duplicate checks
 in GTKStyle and GTKLookAndFeel
In-Reply-To: <ooySEK-401Bvzy5LUTAIx9YD0yAQOqaONJpIsjBG4p8=.a6f8d1b4-0da8-4ce3-98ea-bdaee0ae5586@github.com>
References: <ooySEK-401Bvzy5LUTAIx9YD0yAQOqaONJpIsjBG4p8=.a6f8d1b4-0da8-4ce3-98ea-bdaee0ae5586@github.com>
Message-ID: <iZSX9SC6m4dH7ZSMYS_CTk7NqkhXRlFXe60KGzCDTfs=.2eefc3d4-6f6f-4378-ad12-b13905f6ce42@github.com>

On Mon, 22 Mar 2021 15:40:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports a few minor problems in GTKStyle and GTKLookAndFeel: Correct one of the identical sub-expressions on both sides of operator "||".

This pull request has now been integrated.

Changeset: df01b15b
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/df01b15b
Stats:     5 lines in 2 files changed: 0 ins; 2 del; 3 mod

8263977: GTK L&F: Cleanup duplicate checks in GTKStyle and GTKLookAndFeel

Reviewed-by: serb, pbansal, kizune

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

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

From kizune at openjdk.java.net  Tue Mar 23 07:10:40 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 23 Mar 2021 07:10:40 GMT
Subject: <Swing Dev> RFR: 8263454: com.apple.laf.AquaFileChooserUI
 ignores the result of String.trim()
In-Reply-To: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
References: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
Message-ID: <3kLOV_bM-ShTLL-w3R1oySQvN7ws9je9UX8x0RSUrmk=.6be6e9cc-404c-43d8-91ae-6f97a2124076@github.com>

On Mon, 22 Mar 2021 22:19:18 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Looks like the original idea was to set `fallbacktext` on strings containing only spaces.
> 
> I decided to remove the `trim()` call to keep the same behavior and to allows to set such meaningless space only titles/tooltips(same as on other platforms, maybe someone want empty label for some reason).

Marked as reviewed by kizune (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Tue Mar 23 10:32:07 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 23 Mar 2021 10:32:07 GMT
Subject: <Swing Dev> RFR: 8263496:
 MetalHighContrastTheme.getControlHighlight cleanup
Message-ID: <rOYqgr_YJpr8B1P7AF2etcXxx4LBwiiTfIH1UhmFRN8=.46ea3b85-c2f7-4613-b2ba-36cc955a77a8@github.com>

SonarCloud reports the potential issue with MetalHighContrastTheme.getControlHighlight where `controlHighlight ` field is not used and the getControlHighlight() uses secondary field.
public ColorUIResource getControlHighlight() {
        // This was super.getSecondary3();
        return secondary2;
    } 
Removed the unused field.

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

Commit messages:
 - 8263496: MetalHighContrastTheme.getControlHighlight cleanup

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

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

From azvegint at openjdk.java.net  Tue Mar 23 10:38:40 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 23 Mar 2021 10:38:40 GMT
Subject: <Swing Dev> RFR: 8263766: Confusing specification of
 JEditorPaneAccessibleHypertextSupport constructor
In-Reply-To: <V4FmD14OljdG_TOcqU2qXmAB-MWdaM6ttM1iSIlNUfM=.fc4e5a14-2e5a-4cf3-8f5a-9b90cc5fcaa9@github.com>
References: <V4FmD14OljdG_TOcqU2qXmAB-MWdaM6ttM1iSIlNUfM=.fc4e5a14-2e5a-4cf3-8f5a-9b90cc5fcaa9@github.com>
Message-ID: <baYJst8Aes3bhe2qkuqzkh8aAaczFx8Q7DBPcTR89AU=.d203c9ab-d132-4e90-bae8-f3bfc567f507@github.com>

On Tue, 23 Mar 2021 05:53:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The constructor JEditorPaneAccessibleHypertextSupport  javadoc wording is wrong. Rectified the anomaly.

Marked as reviewed by azvegint (Reviewer).

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

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

From pbansal at openjdk.java.net  Tue Mar 23 10:42:39 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 23 Mar 2021 10:42:39 GMT
Subject: <Swing Dev> RFR: 8263766: Confusing specification of
 JEditorPaneAccessibleHypertextSupport constructor
In-Reply-To: <V4FmD14OljdG_TOcqU2qXmAB-MWdaM6ttM1iSIlNUfM=.fc4e5a14-2e5a-4cf3-8f5a-9b90cc5fcaa9@github.com>
References: <V4FmD14OljdG_TOcqU2qXmAB-MWdaM6ttM1iSIlNUfM=.fc4e5a14-2e5a-4cf3-8f5a-9b90cc5fcaa9@github.com>
Message-ID: <poysjwtHIJJ_kz13bhPzLQkWvwyOOgtXmxmxi7exeO8=.10f6c063-3e64-4848-a7ae-257521a20eba@github.com>

On Tue, 23 Mar 2021 05:53:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The constructor JEditorPaneAccessibleHypertextSupport  javadoc wording is wrong. Rectified the anomaly.

Marked as reviewed by pbansal (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Tue Mar 23 12:18:39 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 23 Mar 2021 12:18:39 GMT
Subject: <Swing Dev> Integrated: 8263766: Confusing specification of
 JEditorPaneAccessibleHypertextSupport constructor
In-Reply-To: <V4FmD14OljdG_TOcqU2qXmAB-MWdaM6ttM1iSIlNUfM=.fc4e5a14-2e5a-4cf3-8f5a-9b90cc5fcaa9@github.com>
References: <V4FmD14OljdG_TOcqU2qXmAB-MWdaM6ttM1iSIlNUfM=.fc4e5a14-2e5a-4cf3-8f5a-9b90cc5fcaa9@github.com>
Message-ID: <gwWPaTucYK2Dlz6S4j8lr1-pZOkCleqtLmjpjBX3cKg=.2054ffe2-c0d2-4171-b805-74d1fcaf72dc@github.com>

On Tue, 23 Mar 2021 05:53:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The constructor JEditorPaneAccessibleHypertextSupport  javadoc wording is wrong. Rectified the anomaly.

This pull request has now been integrated.

Changeset: 8c1ab38e
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8c1ab38e
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8263766: Confusing specification of JEditorPaneAccessibleHypertextSupport constructor

Reviewed-by: azvegint, pbansal

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

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

From azvegint at openjdk.java.net  Tue Mar 23 14:55:58 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 23 Mar 2021 14:55:58 GMT
Subject: <Swing Dev> RFR: 8263454: com.apple.laf.AquaFileChooserUI
 ignores the result of String.trim() [v2]
In-Reply-To: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
References: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
Message-ID: <r18itIj3mwtYkOwow8Sl09JzsJUpUBsPign7jBcpqL8=.f42edaea-faf1-4258-8ada-ad1e6e302248@github.com>

> Looks like the original idea was to set `fallbacktext` on strings containing only spaces.
> 
> I decided to remove the `trim()` call to keep the same behavior and to allows to set such meaningless space only titles/tooltips(same as on other platforms, maybe someone want empty label for some reason).

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  allow empty text

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3136/files
  - new: https://git.openjdk.java.net/jdk/pull/3136/files/06c5322d..9e4f2a35

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

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

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

From azvegint at openjdk.java.net  Tue Mar 23 15:36:43 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 23 Mar 2021 15:36:43 GMT
Subject: <Swing Dev> RFR: 8263454: com.apple.laf.AquaFileChooserUI
 ignores the result of String.trim() [v2]
In-Reply-To: <SOskF3ImbIQoKQ1BsVouDc0Fzigvgk_qn4to34PdrlM=.0aa5ab72-fac2-4b42-8cb5-27269250d3ef@github.com>
References: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
 <SOskF3ImbIQoKQ1BsVouDc0Fzigvgk_qn4to34PdrlM=.0aa5ab72-fac2-4b42-8cb5-27269250d3ef@github.com>
Message-ID: <Vv-IO2H7qklYUkOYXuF3GhbzD6h-AJA83QtAjPFLyN0=.71f16509-cbcd-4e43-9546-55d79ab73a2a@github.com>

On Tue, 23 Mar 2021 05:00:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   allow empty text
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java line 2059:
> 
>> 2057:             final String tooltipText = fc.getApproveButtonToolTipText();
>> 2058:             if (tooltipText != null) {
>> 2059:                 if (!tooltipText.isEmpty()) return tooltipText;
> 
> In other L&F like Metal, Basic even empty text is allowed.. there's no check for isEmpty()....Should we do the same here too?

Yes, I think it would be better to allow to set empty text to conform with other LaF behavior.

Also `JFileChooser.getApproveButtonText()` and `JFileChooser.getApproveButtonToolTipText()` will now return correct values for empty strings.
e.g. before the fix if we call `setApproveButtonText("")` subsequent call to `getApproveButtonText()` will return passed string, but in fact fallback string is used.

I've also labeled the issue with `noreg-hard`.

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

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

From serb at openjdk.java.net  Tue Mar 23 17:33:43 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 23 Mar 2021 17:33:43 GMT
Subject: <Swing Dev> RFR: 8263766: Confusing specification of
 JEditorPaneAccessibleHypertextSupport constructor
In-Reply-To: <poysjwtHIJJ_kz13bhPzLQkWvwyOOgtXmxmxi7exeO8=.10f6c063-3e64-4848-a7ae-257521a20eba@github.com>
References: <V4FmD14OljdG_TOcqU2qXmAB-MWdaM6ttM1iSIlNUfM=.fc4e5a14-2e5a-4cf3-8f5a-9b90cc5fcaa9@github.com>
 <poysjwtHIJJ_kz13bhPzLQkWvwyOOgtXmxmxi7exeO8=.10f6c063-3e64-4848-a7ae-257521a20eba@github.com>
Message-ID: <hUhcfom0LXrVNJH97UuHAvFr3CMI5AgcsNZheH5PSIY=.2e9bdd17-3102-434e-b8e8-0e7b08586da4@github.com>

On Tue, 23 Mar 2021 10:39:58 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> The constructor JEditorPaneAccessibleHypertextSupport  javadoc wording is wrong. Rectified the anomaly.
>
> Marked as reviewed by pbansal (Reviewer).

where is a csr?

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

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

From serb at openjdk.java.net  Tue Mar 23 22:16:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 23 Mar 2021 22:16:41 GMT
Subject: <Swing Dev> RFR: 8263454: com.apple.laf.AquaFileChooserUI
 ignores the result of String.trim() [v2]
In-Reply-To: <Vv-IO2H7qklYUkOYXuF3GhbzD6h-AJA83QtAjPFLyN0=.71f16509-cbcd-4e43-9546-55d79ab73a2a@github.com>
References: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
 <SOskF3ImbIQoKQ1BsVouDc0Fzigvgk_qn4to34PdrlM=.0aa5ab72-fac2-4b42-8cb5-27269250d3ef@github.com>
 <Vv-IO2H7qklYUkOYXuF3GhbzD6h-AJA83QtAjPFLyN0=.71f16509-cbcd-4e43-9546-55d79ab73a2a@github.com>
Message-ID: <0V3Yd3Cb5a2EaEYVCV_ilvA-aOOyP36hczjCH0qgUe4=.a7dabd86-6d32-4b63-8406-d28781d53742@github.com>

On Tue, 23 Mar 2021 15:33:43 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java line 2059:
>> 
>>> 2057:             final String tooltipText = fc.getApproveButtonToolTipText();
>>> 2058:             if (tooltipText != null) {
>>> 2059:                 if (!tooltipText.isEmpty()) return tooltipText;
>> 
>> In other L&F like Metal, Basic even empty text is allowed.. there's no check for isEmpty()....Should we do the same here too?
>
> Yes, I think it would be better to allow to set empty text to conform with other LaF behavior.
> 
> Also `JFileChooser.getApproveButtonText()` and `JFileChooser.getApproveButtonToolTipText()` will now return correct values for empty strings.
> e.g. before the fix if we call `setApproveButtonText("")` subsequent call to `getApproveButtonText()` will return passed string, but in fact fallback string is used.
> 
> I've also labeled the issue with `noreg-hard`.

Is it possible to set an empty label in the native file chooser on macOS?

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

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

From psadhukhan at openjdk.java.net  Wed Mar 24 04:22:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 24 Mar 2021 04:22:56 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 should document that the default implementation does nothing [v8]
In-Reply-To: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
Message-ID: <ExiFu-OAqZRJrGr4H2iFm1QZ5RfVmVSlYdYgI9__nL0=.ffcee1e9-38e1-49b2-9c2f-0d5998549713@github.com>

> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Add @implSpec as per JoeDarcy's recommendation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2955/files
  - new: https://git.openjdk.java.net/jdk/pull/2955/files/36cccdab..ec7755a4

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

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

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

From psadhukhan at openjdk.java.net  Wed Mar 24 04:32:01 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 24 Mar 2021 04:32:01 GMT
Subject: <Swing Dev> RFR: 8263768:
 JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
 spec doesn't mention what the default impls return and what does it mean
 [v4]
In-Reply-To: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
References: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
Message-ID: <N84ID8TAupWqdZu85sQ1i7PTvoqGkjABgiJ1UZM0c8Y=.ff470734-a00f-4346-8ab5-16d7bc1fc651@github.com>

> Default implementation of JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() returns null but it is not mentioned in the spec.
> It is now explicitly mentioned in the spec by @impNote tag.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Add @implSpec as per JoeDarcy's recommendation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3064/files
  - new: https://git.openjdk.java.net/jdk/pull/3064/files/cea2f171..0fdd15f4

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

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

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

From trebari at openjdk.java.net  Wed Mar 24 06:22:57 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Wed, 24 Mar 2021 06:22:57 GMT
Subject: <Swing Dev> RFR: 8253266 : JList and JTable constructors should
 clear OPAQUE_SET before calling updateUI
Message-ID: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com>

Hi All,
Please review the following fix for jdk17.

Issue : LookAndFeel.installProperty(list, "opaque", false) is not able to set the opaque property for JList and JTable.
LookAndFeel.installProperty calls the setUIProperty, and setUIProperty checks for OPAQUE_SET to change the opaque property as requested by the client.
OPAQUE_SET is always set to true when there is call to setOpaque(boolean).So when the constructor calls setOpaque(true) OPAQUE_SET is set to true and wont allow the setUIProperty to change the opaque property.
installProperty should work as the opaque property is not set by the client.

Fix. Fix is to remove the call to the setOpaque() from the constructor of JList and JTable. This will allow the client to change the opaque property calling LookAndFeel.installProperty() when the property is already not set.

Test : Added a  test  to check the same. Also tested internal tests which all are passing.
Link is in JBS.

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

Commit messages:
 - intial changes

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

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

From trebari at openjdk.java.net  Wed Mar 24 06:37:39 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Wed, 24 Mar 2021 06:37:39 GMT
Subject: <Swing Dev> RFR: 8263454: com.apple.laf.AquaFileChooserUI
 ignores the result of String.trim() [v2]
In-Reply-To: <r18itIj3mwtYkOwow8Sl09JzsJUpUBsPign7jBcpqL8=.f42edaea-faf1-4258-8ada-ad1e6e302248@github.com>
References: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
 <r18itIj3mwtYkOwow8Sl09JzsJUpUBsPign7jBcpqL8=.f42edaea-faf1-4258-8ada-ad1e6e302248@github.com>
Message-ID: <a9rZgcMXYf2CA9-93o4kNSOnXckQpqkeeQm0rFwgFd4=.0dd12686-4215-489f-9fab-f200ff3caf5e@github.com>

On Tue, 23 Mar 2021 14:55:58 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Looks like the original idea was to set `fallbacktext` on strings containing only spaces.
>> 
>> I decided to remove the `trim()` call to keep the same behavior and to allows to set such meaningless space only titles/tooltips(same as on other platforms, maybe someone want empty label for some reason).
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   allow empty text

Marked as reviewed by trebari (Committer).

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

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

From psadhukhan at openjdk.java.net  Wed Mar 24 08:30:41 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 24 Mar 2021 08:30:41 GMT
Subject: <Swing Dev> RFR: 8253266 : JList and JTable constructors should
 clear OPAQUE_SET before calling updateUI
In-Reply-To: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com>
References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com>
Message-ID: <lYEyAPYiL2u-exOk4EStTVHQ9Y0TINhxOIhUC8kHleE=.2e5b493b-158f-4c7c-9159-c07e1685da0f@github.com>

On Wed, 24 Mar 2021 06:17:04 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

> Hi All,
> Please review the following fix for jdk17.
> 
> Issue : LookAndFeel.installProperty(list, "opaque", false) is not able to set the opaque property for JList and JTable.
> LookAndFeel.installProperty calls the setUIProperty, and setUIProperty checks for OPAQUE_SET to change the opaque property as requested by the client.
> OPAQUE_SET is always set to true when there is call to setOpaque(boolean).So when the constructor calls setOpaque(true) OPAQUE_SET is set to true and wont allow the setUIProperty to change the opaque property.
> installProperty should work as the opaque property is not set by the client.
> 
> Fix. Fix is to remove the call to the setOpaque() from the constructor of JList and JTable. This will allow the client to change the opaque property calling LookAndFeel.installProperty() when the property is already not set.
> 
> Test : Added a  test  to check the same. Also tested internal tests which all are passing.
> Link is in JBS.

I am not sure if this is the correct fix, as then we would have to remove setOpaque call for JTree, JToolTip, JRootPane etc where we might face same installProperty issue. 
Also, if we have to change this, we then need to change "autoScrolls" property too which is set in this 2 component and setUIProperty() can change those too.
Probably, we need to check if the value to be set is different in setUIProperty and then set it 
or 
override setUIProperty per component basis (as it is done for JTable) and then not check for OPAQUE_SET flag for opaque property accordingly.

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

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

From azvegint at openjdk.java.net  Wed Mar 24 11:15:40 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 24 Mar 2021 11:15:40 GMT
Subject: <Swing Dev> RFR: 8263454: com.apple.laf.AquaFileChooserUI
 ignores the result of String.trim() [v2]
In-Reply-To: <0V3Yd3Cb5a2EaEYVCV_ilvA-aOOyP36hczjCH0qgUe4=.a7dabd86-6d32-4b63-8406-d28781d53742@github.com>
References: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
 <SOskF3ImbIQoKQ1BsVouDc0Fzigvgk_qn4to34PdrlM=.0aa5ab72-fac2-4b42-8cb5-27269250d3ef@github.com>
 <Vv-IO2H7qklYUkOYXuF3GhbzD6h-AJA83QtAjPFLyN0=.71f16509-cbcd-4e43-9546-55d79ab73a2a@github.com>
 <0V3Yd3Cb5a2EaEYVCV_ilvA-aOOyP36hczjCH0qgUe4=.a7dabd86-6d32-4b63-8406-d28781d53742@github.com>
Message-ID: <4NaDfuDk_bN7C4FQe7oxotqd5k3Vq2igTpNsUKBu_3k=.ac588d55-b0e3-4ad4-b969-3805727db448@github.com>

On Tue, 23 Mar 2021 22:13:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yes, I think it would be better to allow to set empty text to conform with other LaF behavior.
>> 
>> Also `JFileChooser.getApproveButtonText()` and `JFileChooser.getApproveButtonToolTipText()` will now return correct values for empty strings.
>> e.g. before the fix if we call `setApproveButtonText("")` subsequent call to `getApproveButtonText()` will return passed string, but in fact fallback string is used.
>> 
>> I've also labeled the issue with `noreg-hard`.
>
> Is it possible to set an empty label in the native file chooser on macOS?

Yes, and it looks the same as the one with `" "` label.
<img width="662" alt="image" src="https://user-images.githubusercontent.com/77687766/112301125-ea140e80-8c99-11eb-8588-b1730d43124f.png">

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

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

From psadhukhan at openjdk.java.net  Wed Mar 24 11:26:41 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 24 Mar 2021 11:26:41 GMT
Subject: <Swing Dev> RFR: 8263454: com.apple.laf.AquaFileChooserUI
 ignores the result of String.trim() [v2]
In-Reply-To: <r18itIj3mwtYkOwow8Sl09JzsJUpUBsPign7jBcpqL8=.f42edaea-faf1-4258-8ada-ad1e6e302248@github.com>
References: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
 <r18itIj3mwtYkOwow8Sl09JzsJUpUBsPign7jBcpqL8=.f42edaea-faf1-4258-8ada-ad1e6e302248@github.com>
Message-ID: <GMzO2VJskK_xkGaiPJroSzuyD4ypzU8fW6TG7SOrxFM=.cb42f275-4cfb-49f1-a61a-fa68032baa94@github.com>

On Tue, 23 Mar 2021 14:55:58 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Looks like the original idea was to set `fallbacktext` on strings containing only spaces.
>> 
>> I decided to remove the `trim()` call to keep the same behavior and to allows to set such meaningless space only titles/tooltips(same as on other platforms, maybe someone want empty label for some reason).
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   allow empty text

Marked as reviewed by psadhukhan (Reviewer).

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

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

From azvegint at openjdk.java.net  Wed Mar 24 17:56:45 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 24 Mar 2021 17:56:45 GMT
Subject: <Swing Dev> RFR: 8263496:
 MetalHighContrastTheme.getControlHighlight cleanup
In-Reply-To: <rOYqgr_YJpr8B1P7AF2etcXxx4LBwiiTfIH1UhmFRN8=.46ea3b85-c2f7-4613-b2ba-36cc955a77a8@github.com>
References: <rOYqgr_YJpr8B1P7AF2etcXxx4LBwiiTfIH1UhmFRN8=.46ea3b85-c2f7-4613-b2ba-36cc955a77a8@github.com>
Message-ID: <j-UfEXzm_7T2XUumbxXH08DXTK8yG0LUYIkVWfmyf7w=.047c26e1-8318-4c30-97a8-4d97f2bf9753@github.com>

On Tue, 23 Mar 2021 10:26:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> SonarCloud reports the potential issue with MetalHighContrastTheme.getControlHighlight where `controlHighlight ` field is not used and the getControlHighlight() uses secondary field.
> public ColorUIResource getControlHighlight() {
>         // This was super.getSecondary3();
>         return secondary2;
>     } 
> Removed the unused field.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalHighContrastTheme.java line 55:

> 53:                               255, 255, 255);
> 54:     private static final ColorUIResource controlHighlight = new
> 55:                               ColorUIResource(102, 102, 102);

I didn't check it on Windows(AFAICS it is used for Windows only), but I've done a quick check how it looks on Linux with both colors.

Using `controlHighlight`  in `getControlHighlight()`:
![using controlHighlight](https://user-images.githubusercontent.com/77687766/112357602-bf00dd80-8ce0-11eb-9a8d-0faeb6d1940b.png)

Using `secondary2`  in `getControlHighlight()`:
![using secondary2](https://user-images.githubusercontent.com/77687766/112357736-db9d1580-8ce0-11eb-8e1a-527ec327874f.png)

And it seems that the option with unused `controlHighlight` color is more fits the definition of high contrast.

Have you checked why its usage was removed?

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

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

From aivanov at openjdk.java.net  Wed Mar 24 19:57:40 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 24 Mar 2021 19:57:40 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 should document that the default implementation does nothing [v8]
In-Reply-To: <ExiFu-OAqZRJrGr4H2iFm1QZ5RfVmVSlYdYgI9__nL0=.ffcee1e9-38e1-49b2-9c2f-0d5998549713@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <ExiFu-OAqZRJrGr4H2iFm1QZ5RfVmVSlYdYgI9__nL0=.ffcee1e9-38e1-49b2-9c2f-0d5998549713@github.com>
Message-ID: <PPWdTWvxYIzM9TJcOKIO3AlguziSci_YRchL-q_oO24=.85698714-06c1-496d-b00e-c01eb25dcb1f@github.com>

On Wed, 24 Mar 2021 04:22:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @implSpec as per JoeDarcy's recommendation

Marked as reviewed by aivanov (Reviewer).

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

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

From aivanov at openjdk.java.net  Wed Mar 24 20:04:40 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 24 Mar 2021 20:04:40 GMT
Subject: <Swing Dev> RFR: 8263768:
 JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
 spec doesn't mention what the default impls return and what does it mean
 [v4]
In-Reply-To: <N84ID8TAupWqdZu85sQ1i7PTvoqGkjABgiJ1UZM0c8Y=.ff470734-a00f-4346-8ab5-16d7bc1fc651@github.com>
References: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
 <N84ID8TAupWqdZu85sQ1i7PTvoqGkjABgiJ1UZM0c8Y=.ff470734-a00f-4346-8ab5-16d7bc1fc651@github.com>
Message-ID: <WqPvU-XI1o1NGrsf_JkY7JZThF2Ut7Peld5O28faiX0=.b3b17958-fcd9-4799-a004-2f7a9911baa2@github.com>

On Wed, 24 Mar 2021 04:32:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Default implementation of JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() returns null but it is not mentioned in the spec.
>> It is now explicitly mentioned in the spec by @impNote tag.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @implSpec as per JoeDarcy's recommendation

Marked as reviewed by aivanov (Reviewer).

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

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

From prr at openjdk.java.net  Wed Mar 24 20:10:42 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 24 Mar 2021 20:10:42 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 should document that the default implementation does nothing [v8]
In-Reply-To: <ExiFu-OAqZRJrGr4H2iFm1QZ5RfVmVSlYdYgI9__nL0=.ffcee1e9-38e1-49b2-9c2f-0d5998549713@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <ExiFu-OAqZRJrGr4H2iFm1QZ5RfVmVSlYdYgI9__nL0=.ffcee1e9-38e1-49b2-9c2f-0d5998549713@github.com>
Message-ID: <64rUDtNqIIkh9uKfu0MmrQxqd13gJGvLtBf-fsz59o4=.f0a4a2c0-1a05-4cc5-9323-c4061b4bc63c@github.com>

On Wed, 24 Mar 2021 04:22:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @implSpec as per JoeDarcy's recommendation

src/java.desktop/share/classes/javax/swing/JComponent.java line 670:

> 668:      *
> 669:      * @implSpec The default implementation of this method doesn't do anything.
> 670:      *

I prefer "does nothing"

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

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

From aivanov at openjdk.java.net  Wed Mar 24 20:12:41 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 24 Mar 2021 20:12:41 GMT
Subject: <Swing Dev> RFR: 8263768:
 JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
 spec doesn't mention what the default impls return and what does it mean
 [v4]
In-Reply-To: <WqPvU-XI1o1NGrsf_JkY7JZThF2Ut7Peld5O28faiX0=.b3b17958-fcd9-4799-a004-2f7a9911baa2@github.com>
References: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
 <N84ID8TAupWqdZu85sQ1i7PTvoqGkjABgiJ1UZM0c8Y=.ff470734-a00f-4346-8ab5-16d7bc1fc651@github.com>
 <WqPvU-XI1o1NGrsf_JkY7JZThF2Ut7Peld5O28faiX0=.b3b17958-fcd9-4799-a004-2f7a9911baa2@github.com>
Message-ID: <q7ndaeD1ZBut9yPANwxmkvnUx1f2_frDfNm2-cv4J54=.aeef35d9-bc96-431b-814a-06a8ffe1b5b9@github.com>

On Wed, 24 Mar 2021 20:01:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @implSpec as per JoeDarcy's recommendation
>
> Marked as reviewed by aivanov (Reviewer).

> csr?

For my own clarification, does any change to the javadoc require a CSR?

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

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

From serb at openjdk.java.net  Wed Mar 24 20:12:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 24 Mar 2021 20:12:41 GMT
Subject: <Swing Dev> RFR: 8263768:
 JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
 spec doesn't mention what the default impls return and what does it mean
 [v4]
In-Reply-To: <q7ndaeD1ZBut9yPANwxmkvnUx1f2_frDfNm2-cv4J54=.aeef35d9-bc96-431b-814a-06a8ffe1b5b9@github.com>
References: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
 <N84ID8TAupWqdZu85sQ1i7PTvoqGkjABgiJ1UZM0c8Y=.ff470734-a00f-4346-8ab5-16d7bc1fc651@github.com>
 <WqPvU-XI1o1NGrsf_JkY7JZThF2Ut7Peld5O28faiX0=.b3b17958-fcd9-4799-a004-2f7a9911baa2@github.com>
 <q7ndaeD1ZBut9yPANwxmkvnUx1f2_frDfNm2-cv4J54=.aeef35d9-bc96-431b-814a-06a8ffe1b5b9@github.com>
Message-ID: <REmWoOxUx3cpli_tDJ9cmZiS1zprU6hY4TKH1M6oepc=.1802a4f4-d305-4c2f-ab5e-a7d0a50c6a9a@github.com>

On Wed, 24 Mar 2021 20:07:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> For my own clarification, does any change to the javadoc require a CSR?

Any changes which add the new testable statements. Actually most change except typos/renames/format.

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

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

From serb at openjdk.java.net  Wed Mar 24 20:15:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 24 Mar 2021 20:15:40 GMT
Subject: <Swing Dev> RFR: 8263454: com.apple.laf.AquaFileChooserUI
 ignores the result of String.trim() [v2]
In-Reply-To: <r18itIj3mwtYkOwow8Sl09JzsJUpUBsPign7jBcpqL8=.f42edaea-faf1-4258-8ada-ad1e6e302248@github.com>
References: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
 <r18itIj3mwtYkOwow8Sl09JzsJUpUBsPign7jBcpqL8=.f42edaea-faf1-4258-8ada-ad1e6e302248@github.com>
Message-ID: <m25B6dC-x0LWgtVHXkDuml5d8IBgMukdTO0HO5fproM=.e36841e0-2867-4c28-84c8-aeafab7ebe24@github.com>

On Tue, 23 Mar 2021 14:55:58 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Looks like the original idea was to set `fallbacktext` on strings containing only spaces.
>> 
>> I decided to remove the `trim()` call to keep the same behavior and to allows to set such meaningless space only titles/tooltips(same as on other platforms, maybe someone want empty label for some reason).
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   allow empty text

Marked as reviewed by serb (Reviewer).

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

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

From aivanov at openjdk.java.net  Wed Mar 24 20:19:39 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 24 Mar 2021 20:19:39 GMT
Subject: <Swing Dev> RFR: 8263768:
 JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
 spec doesn't mention what the default impls return and what does it mean
 [v4]
In-Reply-To: <REmWoOxUx3cpli_tDJ9cmZiS1zprU6hY4TKH1M6oepc=.1802a4f4-d305-4c2f-ab5e-a7d0a50c6a9a@github.com>
References: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
 <N84ID8TAupWqdZu85sQ1i7PTvoqGkjABgiJ1UZM0c8Y=.ff470734-a00f-4346-8ab5-16d7bc1fc651@github.com>
 <WqPvU-XI1o1NGrsf_JkY7JZThF2Ut7Peld5O28faiX0=.b3b17958-fcd9-4799-a004-2f7a9911baa2@github.com>
 <q7ndaeD1ZBut9yPANwxmkvnUx1f2_frDfNm2-cv4J54=.aeef35d9-bc96-431b-814a-06a8ffe1b5b9@github.com>
 <REmWoOxUx3cpli_tDJ9cmZiS1zprU6hY4TKH1M6oepc=.1802a4f4-d305-4c2f-ab5e-a7d0a50c6a9a@github.com>
Message-ID: <_eGfAqvYAV9D1A2ghgqDhOJKdEGw0fzhVdgO1ARyKnM=.8adde3d8-9df6-4167-b502-49c8c247dd04@github.com>

On Wed, 24 Mar 2021 20:10:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > For my own clarification, does any change to the javadoc require a CSR?
> 
> Any changes which add the new testable statements. Actually most change except typos/renames/format.

Thank you.

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

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

From darcy at openjdk.java.net  Thu Mar 25 00:42:43 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 25 Mar 2021 00:42:43 GMT
Subject: <Swing Dev> RFR: 8263768:
 JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
 spec doesn't mention what the default impls return and what does it mean
 [v4]
In-Reply-To: <N84ID8TAupWqdZu85sQ1i7PTvoqGkjABgiJ1UZM0c8Y=.ff470734-a00f-4346-8ab5-16d7bc1fc651@github.com>
References: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
 <N84ID8TAupWqdZu85sQ1i7PTvoqGkjABgiJ1UZM0c8Y=.ff470734-a00f-4346-8ab5-16d7bc1fc651@github.com>
Message-ID: <0bwLPzYWzn4TC98rX0pJbuaunqCoLDCRgC8soUr6vQo=.cbfc2c82-0ad2-4550-82cc-674f83472715@github.com>

On Wed, 24 Mar 2021 04:32:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Default implementation of JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() returns null but it is not mentioned in the spec.
>> It is now explicitly mentioned in the spec by @impNote tag.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @implSpec as per JoeDarcy's recommendation

Marked as reviewed by darcy (Reviewer).

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

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

From darcy at openjdk.java.net  Thu Mar 25 00:44:40 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 25 Mar 2021 00:44:40 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 should document that the default implementation does nothing [v8]
In-Reply-To: <ExiFu-OAqZRJrGr4H2iFm1QZ5RfVmVSlYdYgI9__nL0=.ffcee1e9-38e1-49b2-9c2f-0d5998549713@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
 <ExiFu-OAqZRJrGr4H2iFm1QZ5RfVmVSlYdYgI9__nL0=.ffcee1e9-38e1-49b2-9c2f-0d5998549713@github.com>
Message-ID: <MHBtYXayywyV2a0juUDvEFAE5Ol1PmNOa_DmwbeJ3FU=.3aa7ef06-d099-4263-912c-b51c177546ee@github.com>

On Wed, 24 Mar 2021 04:22:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @implSpec as per JoeDarcy's recommendation

Marked as reviewed by darcy (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Thu Mar 25 04:09:07 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 25 Mar 2021 04:09:07 GMT
Subject: <Swing Dev> RFR: 8263472: Specification of JComponent::updateUI
 should document that the default implementation does nothing [v9]
In-Reply-To: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
Message-ID: <Tg84NPm4gnzPwFVvmt4WkMdMjE_Oj3v36FctBNmgAkI=.5a7fb88c-379f-4ea7-a657-4283360812a4@github.com>

> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  javadoc change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2955/files
  - new: https://git.openjdk.java.net/jdk/pull/2955/files/ec7755a4..f48a043c

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

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

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

From psadhukhan at openjdk.java.net  Thu Mar 25 04:10:43 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 25 Mar 2021 04:10:43 GMT
Subject: <Swing Dev> Integrated: 8263768:
 JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
 spec doesn't mention what the default impls return and what does it mean
In-Reply-To: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
References: <2AnuIGqLl43fddio2YRmB3os98OGVUh5F7vuaSjKB_c=.2932ec8c-9ee9-4999-ac20-0eecda62458d@github.com>
Message-ID: <31Cy6cAMHmt1YGazGjo5yFSvhQxY4yj5ctSFJnInu4Y=.644a1499-4fca-48d2-81a6-00c6f8bd8cd4@github.com>

On Thu, 18 Mar 2021 04:46:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Default implementation of JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() returns null but it is not mentioned in the spec.
> It is now explicitly mentioned in the spec by @impNote tag.

This pull request has now been integrated.

Changeset: 3fcb499c
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3fcb499c
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8263768: JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() spec doesn't mention what the default impls return and what does it mean

Reviewed-by: trebari, aivanov, azvegint, darcy

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

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

From psadhukhan at openjdk.java.net  Thu Mar 25 04:16:47 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 25 Mar 2021 04:16:47 GMT
Subject: <Swing Dev> RFR: 8263496:
 MetalHighContrastTheme.getControlHighlight cleanup
In-Reply-To: <j-UfEXzm_7T2XUumbxXH08DXTK8yG0LUYIkVWfmyf7w=.047c26e1-8318-4c30-97a8-4d97f2bf9753@github.com>
References: <rOYqgr_YJpr8B1P7AF2etcXxx4LBwiiTfIH1UhmFRN8=.46ea3b85-c2f7-4613-b2ba-36cc955a77a8@github.com>
 <j-UfEXzm_7T2XUumbxXH08DXTK8yG0LUYIkVWfmyf7w=.047c26e1-8318-4c30-97a8-4d97f2bf9753@github.com>
Message-ID: <dSH4dCZlY0kRntK8XXKU7bI6VInBRLR9qHLgAvFZ_y0=.e2ccd189-0fc5-464f-924f-2a563dc9cd5a@github.com>

On Wed, 24 Mar 2021 17:51:44 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> SonarCloud reports the potential issue with MetalHighContrastTheme.getControlHighlight where `controlHighlight ` field is not used and the getControlHighlight() uses secondary field.
>> public ColorUIResource getControlHighlight() {
>>         // This was super.getSecondary3();
>>         return secondary2;
>>     } 
>> Removed the unused field.
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalHighContrastTheme.java line 55:
> 
>> 53:                               255, 255, 255);
>> 54:     private static final ColorUIResource controlHighlight = new
>> 55:                               ColorUIResource(102, 102, 102);
> 
> I didn't check it on Windows(AFAICS it is used for Windows only), but I've done a quick check how it looks on Linux with both colors.
> 
> Using `controlHighlight`  in `getControlHighlight()`:
> ![using controlHighlight](https://user-images.githubusercontent.com/77687766/112357602-bf00dd80-8ce0-11eb-9a8d-0faeb6d1940b.png)
> 
> Using `secondary2`  in `getControlHighlight()`:
> ![using secondary2](https://user-images.githubusercontent.com/77687766/112357736-db9d1580-8ce0-11eb-8e1a-527ec327874f.png)
> 
> And it seems that the option with unused `controlHighlight` color is more fits the definition of high contrast.
> 
> Have you checked why its usage was removed?

As far I see in the history of this file, it was `secondary2` that was used from beginning, so I kept it and removed the unused.

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

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

From trebari at openjdk.java.net  Thu Mar 25 06:36:40 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Thu, 25 Mar 2021 06:36:40 GMT
Subject: <Swing Dev> RFR: 8253266 : JList and JTable constructors should
 clear OPAQUE_SET before calling updateUI
In-Reply-To: <lYEyAPYiL2u-exOk4EStTVHQ9Y0TINhxOIhUC8kHleE=.2e5b493b-158f-4c7c-9159-c07e1685da0f@github.com>
References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com>
 <lYEyAPYiL2u-exOk4EStTVHQ9Y0TINhxOIhUC8kHleE=.2e5b493b-158f-4c7c-9159-c07e1685da0f@github.com>
Message-ID: <DiuqVkIOVSYm6QfobGCJBkMt6SdOaXTsgDjPo4FLb08=.62441db7-98a2-47b7-acad-24a770a5393a@github.com>

On Wed, 24 Mar 2021 08:27:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I am not sure if this is the correct fix, as then we would have to remove setOpaque call for JTree, JToolTip, JRootPane etc where we might face same installProperty issue.

Yes we face the same issue in JTree, JToolTip, and JViewport , 
but many of the components do not  have this problem like JButton JRootPane , JCheckbox, JInternalFrame, JMenuItem, JCheckBoxMenuItem, JPopupMenu, JMenu ..etc
We can fix the issue with JTree, JTooltip and JViewport same way.

> Also, if we have to change this, we then need to change "autoScrolls" property too which is set in this 2 component and setUIProperty() can change those too.
> Probably, we need to check if the value to be set is different in setUIProperty and then set it 
> or
> override setUIProperty per component basis (as it is done for JTable) and then not check for OPAQUE_SET flag for opaque property accordingly.

OPAQUE_SET is private variable and can not be accessed in JTable or JTree. 
>From the spec of LookAndFeel.installProperty and setUIProperty it
  * Sets the property with the specified name to the specified value if
     * the property has not already been set by the client program.*
 is clear that once the property is set by the client setUIProperty can not change it. And OPAUQE_SET  is  used  for  that
.

Removing the setOpaque() from the constructor of these component will not make any initial difference as it is also set to true in BasicListUI, BasicTableUI, BasicTreeUI, BasicTooltipUI and BasicViewportUI by calling LookAndFeel.installProperty.
The difference which it will make is now by calling LookAndFeel.installProperty(c,opaque,false) will clear the opaque property.

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

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

From serb at openjdk.java.net  Thu Mar 25 06:46:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 25 Mar 2021 06:46:40 GMT
Subject: <Swing Dev> RFR: 8253266 : JList and JTable constructors should
 clear OPAQUE_SET before calling updateUI
In-Reply-To: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com>
References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com>
Message-ID: <NhrlyQitaQ_ML3Yn5_ptdjN3WAOyxlKISpAk-xEsxfk=.ce4a6250-d8c0-426b-8e47-b46acd168449@github.com>

On Wed, 24 Mar 2021 06:17:04 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

> Hi All,
> Please review the following fix for jdk17.
> 
> Issue : LookAndFeel.installProperty(list, "opaque", false) is not able to set the opaque property for JList and JTable.
> LookAndFeel.installProperty calls the setUIProperty, and setUIProperty checks for OPAQUE_SET to change the opaque property as requested by the client.
> OPAQUE_SET is always set to true when there is call to setOpaque(boolean).So when the constructor calls setOpaque(true) OPAQUE_SET is set to true and wont allow the setUIProperty to change the opaque property.
> installProperty should work as the opaque property is not set by the client.
> 
> Fix. Fix is to remove the call to the setOpaque() from the constructor of JList and JTable. This will allow the client to change the opaque property calling LookAndFeel.installProperty() when the property is already not set.
> 
> Test : Added a  test  to check the same. Also tested internal tests which all are passing.
> Link is in JBS.

test/jdk/javax/swing/JList/TestOpaqueListTable.java line 38:

> 36: 
> 37:     public static void main(String[] args) throws Exception {
> 38:         UIManager.LookAndFeelInfo[] installedLookAndFeels;

I did not look close to the fix, but you need to check that the default value of the "opaque" property will not be changed. So all default L&F will set it to true, as before the fix.

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

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

From trebari at openjdk.java.net  Thu Mar 25 07:45:42 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Thu, 25 Mar 2021 07:45:42 GMT
Subject: <Swing Dev> RFR: 8253266 : JList and JTable constructors should
 clear OPAQUE_SET before calling updateUI
In-Reply-To: <NhrlyQitaQ_ML3Yn5_ptdjN3WAOyxlKISpAk-xEsxfk=.ce4a6250-d8c0-426b-8e47-b46acd168449@github.com>
References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com>
 <NhrlyQitaQ_ML3Yn5_ptdjN3WAOyxlKISpAk-xEsxfk=.ce4a6250-d8c0-426b-8e47-b46acd168449@github.com>
Message-ID: <D_Nf_vYCODQ6vdOWHTfBuoZY93yARaGlXhGsaa2MSiQ=.2bb5a20d-5206-4011-8daa-bff153414b3b@github.com>

On Thu, 25 Mar 2021 06:44:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Hi All,
>> Please review the following fix for jdk17.
>> 
>> Issue : LookAndFeel.installProperty(list, "opaque", false) is not able to set the opaque property for JList and JTable.
>> LookAndFeel.installProperty calls the setUIProperty, and setUIProperty checks for OPAQUE_SET to change the opaque property as requested by the client.
>> OPAQUE_SET is always set to true when there is call to setOpaque(boolean).So when the constructor calls setOpaque(true) OPAQUE_SET is set to true and wont allow the setUIProperty to change the opaque property.
>> installProperty should work as the opaque property is not set by the client.
>> 
>> Fix. Fix is to remove the call to the setOpaque() from the constructor of JList and JTable. This will allow the client to change the opaque property calling LookAndFeel.installProperty() when the property is already not set.
>> 
>> Test : Added a  test  to check the same. Also tested internal tests which all are passing.
>> Link is in JBS.
>
> test/jdk/javax/swing/JList/TestOpaqueListTable.java line 38:
> 
>> 36: 
>> 37:     public static void main(String[] args) throws Exception {
>> 38:         UIManager.LookAndFeelInfo[] installedLookAndFeels;
> 
> I did not look close to the fix, but you need to check that the default value of the "opaque" property will not be changed. So all default L&F will set it to true, as before the fix.

Yeah, the default value for "opaque" property will not be changed.
It will be true for All L&F after the fix as well , I will add  that check to the test.

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

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

From trebari at openjdk.java.net  Thu Mar 25 08:03:21 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Thu, 25 Mar 2021 08:03:21 GMT
Subject: <Swing Dev> RFR: 8253266 : JList and JTable constructors should
 clear OPAQUE_SET before calling updateUI [v2]
In-Reply-To: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com>
References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com>
Message-ID: <XUYiefJZ2r3vJj2D2LvCcaFAC1_KP4jh5t0-LZHkM5c=.05bb873f-c75d-4d3b-b0c5-78e367885f89@github.com>

> Hi All,
> Please review the following fix for jdk17.
> 
> Issue : LookAndFeel.installProperty(list, "opaque", false) is not able to set the opaque property for JList and JTable.
> LookAndFeel.installProperty calls the setUIProperty, and setUIProperty checks for OPAQUE_SET to change the opaque property as requested by the client.
> OPAQUE_SET is always set to true when there is call to setOpaque(boolean).So when the constructor calls setOpaque(true) OPAQUE_SET is set to true and wont allow the setUIProperty to change the opaque property.
> installProperty should work as the opaque property is not set by the client.
> 
> Fix. Fix is to remove the call to the setOpaque() from the constructor of JList and JTable. This will allow the client to change the opaque property calling LookAndFeel.installProperty() when the property is already not set.
> 
> Test : Added a  test  to check the same. Also tested internal tests which all are passing.
> Link is in JBS.

Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:

  Added default value check for opaque property

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3167/files
  - new: https://git.openjdk.java.net/jdk/pull/3167/files/aafac8f2..eec8b913

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

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

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

From azvegint at openjdk.java.net  Thu Mar 25 13:55:27 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 25 Mar 2021 13:55:27 GMT
Subject: <Swing Dev> Integrated: 8263454: com.apple.laf.AquaFileChooserUI
 ignores the result of String.trim()
In-Reply-To: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
References: <Co0ZZMRyhnb01jUvO9lDGNn2dVlIDMs2F4zYDeSE-rQ=.13c495a7-61c1-4855-9503-061979dc773b@github.com>
Message-ID: <Mgs12w3Qwrxz1xu_Fh56leWXT65YDUk5qicOAWMnjtI=.dabd3f5f-3448-4b86-ae86-6b22c911ac48@github.com>

On Mon, 22 Mar 2021 22:19:18 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Looks like the original idea was to set `fallbacktext` on strings containing only spaces.
> 
> I decided to remove the `trim()` call to keep the same behavior and to allows to set such meaningless space only titles/tooltips(same as on other platforms, maybe someone want empty label for some reason).

This pull request has now been integrated.

Changeset: c037e1ed
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c037e1ed
Stats:     11 lines in 1 file changed: 0 ins; 4 del; 7 mod

8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()

Reviewed-by: serb, pbansal, kizune, trebari, psadhukhan

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

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

From kcr at openjdk.java.net  Thu Mar 25 20:19:27 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 25 Mar 2021 20:19:27 GMT
Subject: <Swing Dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <8Vo0sYp5M4FNk6DKP2URAChl60rTHV-MpMsSUQi0-Nk=.c1f6ac22-cc67-4072-8d75-80032979db2f@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

src/java.desktop/share/classes/java/applet/package-info.java line 39:

> 37:  * applet development environment.
> 38:  * <p>
> 39:  * @deprecated.  This package has been deprecated and may be removed in

Package declarations cannot have `@deprecated` tags, so `make docs` fails with this change. Also, since there is a tag here, the previous `<p>` is now empty and causes a warning. Both problems will be fixed by removing the `@deprecated` tag, while leaving the added text.

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

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

From herrick at openjdk.java.net  Thu Mar 25 22:58:53 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 25 Mar 2021 22:58:53 GMT
Subject: <Swing Dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations [v2]
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

Andy Herrick 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 301 additional commits since the last revision:

 - 8189198: Add "forRemoval = true" to Applet API deprecations
 - Merge branch 'master' into 8189198
 - 8260862: JFR: New configure command for the jfr tool
   
   Reviewed-by: mgronlun
 - 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
   
   Reviewed-by: bpb
 - 8262081: vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "ERROR: eventSet1.size() != 3 :: 2"
   
   Reviewed-by: cjplummer, lmesnik, sspitsyn
 - 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling
   
   Reviewed-by: jnimeh
 - 8253795: Implementation of JEP 391: macOS/AArch64 Port
   8253816: Support macOS W^X
   8253817: Support macOS Aarch64 ABI in Interpreter
   8253818: Support macOS Aarch64 ABI for compiled wrappers
   8253819: Implement os/cpu for macOS/AArch64
   8253839: Update tests and JDK code for macOS/Aarch64
   8254941: Implement Serviceability Agent for macOS/AArch64
   8255776: Change build system for macOS/AArch64
   8262903: [macos_aarch64] Thread::current() called on detached thread
   
   Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
   Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
   Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
   Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
   Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry
 - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced
   
   Reviewed-by: adinn
 - 8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters
   
   Reviewed-by: herrick, dcubed
 - 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()
   
   Reviewed-by: serb, pbansal, kizune, trebari, psadhukhan
 - ... and 291 more: https://git.openjdk.java.net/jdk/compare/ddfe8ec5...026f09c8

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2920/files
  - new: https://git.openjdk.java.net/jdk/pull/2920/files/1148f208..026f09c8

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

  Stats: 64315 lines in 2948 files changed: 41333 ins; 13022 del; 9960 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2920.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2920/head:pull/2920

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

From herrick at openjdk.java.net  Thu Mar 25 22:58:53 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 25 Mar 2021 22:58:53 GMT
Subject: <Swing Dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations [v2]
In-Reply-To: <qiZi_Vbv_HUnvOdDXWkOYXX34-TZXgn5RfVZ10RKPbA=.2a14f73b-832e-4dbb-92c9-bee2ff7b62ec@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
 <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>
 <fDHwQZqPpR9I3bBnnq67JsK1C55ItjUaig2dmaT3PAs=.1121b4e3-7c5b-4b50-8bdc-b0f4631510d9@github.com>
 <qiZi_Vbv_HUnvOdDXWkOYXX34-TZXgn5RfVZ10RKPbA=.2a14f73b-832e-4dbb-92c9-bee2ff7b62ec@github.com>
Message-ID: <tArFXdLPW8vkB0tQ-hZLGWSCFii-IBVY2md9t8TNSD8=.fcac7aad-39cc-4449-a046-6140be9cfbde@github.com>

On Wed, 17 Mar 2021 20:33:09 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>>> I cannot find any instances where the scope can be narrowed
>> 
>> Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged, and other non-trivial methods?
>
>> 
>> 
>> > I cannot find any instances where the scope can be narrowed
>> 
>> Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged, and other non-trivial methods?
> 
> These have the code pattern such as: 
> } else if (c instanceof JApplet) {
> putting '@SuppressWarnings("removal")' before the declaration of 'c' does not help, because the code is not an assignment to 'c'

pushed minor change to src/java.desktop/share/classes/java/applet/package-info.java as well as merge with master.

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

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

From kcr at openjdk.java.net  Thu Mar 25 23:27:37 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 25 Mar 2021 23:27:37 GMT
Subject: <Swing Dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations [v2]
In-Reply-To: <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
Message-ID: <LC2l3Zo5eUjQhM6QcVCXZJ7PFh4op_NJSj15xFWPblg=.c02e5303-8b79-4ad8-bc4c-eab62698228f@github.com>

On Thu, 25 Mar 2021 22:58:53 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Andy Herrick 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 301 additional commits since the last revision:
> 
>  - 8189198: Add "forRemoval = true" to Applet API deprecations
>  - Merge branch 'master' into 8189198
>  - 8260862: JFR: New configure command for the jfr tool
>    
>    Reviewed-by: mgronlun
>  - 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
>    
>    Reviewed-by: bpb
>  - 8262081: vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "ERROR: eventSet1.size() != 3 :: 2"
>    
>    Reviewed-by: cjplummer, lmesnik, sspitsyn
>  - 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling
>    
>    Reviewed-by: jnimeh
>  - 8253795: Implementation of JEP 391: macOS/AArch64 Port
>    8253816: Support macOS W^X
>    8253817: Support macOS Aarch64 ABI in Interpreter
>    8253818: Support macOS Aarch64 ABI for compiled wrappers
>    8253819: Implement os/cpu for macOS/AArch64
>    8253839: Update tests and JDK code for macOS/Aarch64
>    8254941: Implement Serviceability Agent for macOS/AArch64
>    8255776: Change build system for macOS/AArch64
>    8262903: [macos_aarch64] Thread::current() called on detached thread
>    
>    Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
>    Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
>    Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
>    Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
>    Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry
>  - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced
>    
>    Reviewed-by: adinn
>  - 8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters
>    
>    Reviewed-by: herrick, dcubed
>  - 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()
>    
>    Reviewed-by: serb, pbansal, kizune, trebari, psadhukhan
>  - ... and 291 more: https://git.openjdk.java.net/jdk/compare/e2285595...026f09c8

Looks good.

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

Marked as reviewed by kcr (Author).

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

From iris at openjdk.java.net  Thu Mar 25 23:38:33 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 25 Mar 2021 23:38:33 GMT
Subject: <Swing Dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations [v2]
In-Reply-To: <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
Message-ID: <Ge5orwjsQQS4sJiLXFYz2nVh9v4HCBf1tz3WlVpSGlU=.f6a8deb3-c66a-4eea-b35e-76a82c2fbf73@github.com>

On Thu, 25 Mar 2021 22:58:53 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Andy Herrick 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 301 additional commits since the last revision:
> 
>  - 8189198: Add "forRemoval = true" to Applet API deprecations
>  - Merge branch 'master' into 8189198
>  - 8260862: JFR: New configure command for the jfr tool
>    
>    Reviewed-by: mgronlun
>  - 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
>    
>    Reviewed-by: bpb
>  - 8262081: vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "ERROR: eventSet1.size() != 3 :: 2"
>    
>    Reviewed-by: cjplummer, lmesnik, sspitsyn
>  - 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling
>    
>    Reviewed-by: jnimeh
>  - 8253795: Implementation of JEP 391: macOS/AArch64 Port
>    8253816: Support macOS W^X
>    8253817: Support macOS Aarch64 ABI in Interpreter
>    8253818: Support macOS Aarch64 ABI for compiled wrappers
>    8253819: Implement os/cpu for macOS/AArch64
>    8253839: Update tests and JDK code for macOS/Aarch64
>    8254941: Implement Serviceability Agent for macOS/AArch64
>    8255776: Change build system for macOS/AArch64
>    8262903: [macos_aarch64] Thread::current() called on detached thread
>    
>    Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
>    Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
>    Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
>    Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
>    Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry
>  - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced
>    
>    Reviewed-by: adinn
>  - 8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters
>    
>    Reviewed-by: herrick, dcubed
>  - 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()
>    
>    Reviewed-by: serb, pbansal, kizune, trebari, psadhukhan
>  - ... and 291 more: https://git.openjdk.java.net/jdk/compare/8fcfe0bd...026f09c8

Marked as reviewed by iris (Reviewer).

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

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

From prr at openjdk.java.net  Thu Mar 25 23:51:33 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 25 Mar 2021 23:51:33 GMT
Subject: <Swing Dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations [v2]
In-Reply-To: <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
Message-ID: <rX_M7QysdLlKt6uprI4OE3kPj_x721_7gNHPw8Q52aQ=.952d1e25-d194-408d-a50d-b92cc8c5c7c4@github.com>

On Thu, 25 Mar 2021 22:58:53 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Andy Herrick 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 301 additional commits since the last revision:
> 
>  - 8189198: Add "forRemoval = true" to Applet API deprecations
>  - Merge branch 'master' into 8189198
>  - 8260862: JFR: New configure command for the jfr tool
>    
>    Reviewed-by: mgronlun
>  - 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
>    
>    Reviewed-by: bpb
>  - 8262081: vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "ERROR: eventSet1.size() != 3 :: 2"
>    
>    Reviewed-by: cjplummer, lmesnik, sspitsyn
>  - 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling
>    
>    Reviewed-by: jnimeh
>  - 8253795: Implementation of JEP 391: macOS/AArch64 Port
>    8253816: Support macOS W^X
>    8253817: Support macOS Aarch64 ABI in Interpreter
>    8253818: Support macOS Aarch64 ABI for compiled wrappers
>    8253819: Implement os/cpu for macOS/AArch64
>    8253839: Update tests and JDK code for macOS/Aarch64
>    8254941: Implement Serviceability Agent for macOS/AArch64
>    8255776: Change build system for macOS/AArch64
>    8262903: [macos_aarch64] Thread::current() called on detached thread
>    
>    Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
>    Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
>    Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
>    Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
>    Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry
>  - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced
>    
>    Reviewed-by: adinn
>  - 8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters
>    
>    Reviewed-by: herrick, dcubed
>  - 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()
>    
>    Reviewed-by: serb, pbansal, kizune, trebari, psadhukhan
>  - ... and 291 more: https://git.openjdk.java.net/jdk/compare/00b7b36f...026f09c8

Marked as reviewed by prr (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Fri Mar 26 11:33:32 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 26 Mar 2021 11:33:32 GMT
Subject: <Swing Dev> Integrated: 8263472: Specification of
 JComponent::updateUI should document that the default implementation does
 nothing
In-Reply-To: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
References: <-7UierpUJBT3_Y0GOUbxPUy8F434Yel9N597P_pD288=.59f3f1ed-22d2-495c-84ea-8354b8c23ae1@github.com>
Message-ID: <pBzref9gVu2185vNZX-VhlRPJWjghO8BPnyaWnXw8YU=.dbbab3de-b781-4be1-831f-1c9742e7a739@github.com>

On Fri, 12 Mar 2021 04:33:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It's unclear from the spec that the original implementation of the method JComponent.updateUI() does nothing which needs to be explicitly stated in the javadoc.

This pull request has now been integrated.

Changeset: 4fbb7c24
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4fbb7c24
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8263472: Specification of JComponent::updateUI should document that the default implementation does nothing

Reviewed-by: aivanov, darcy

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

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

From psadhukhan at openjdk.java.net  Fri Mar 26 11:37:33 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 26 Mar 2021 11:37:33 GMT
Subject: <Swing Dev> RFR: 8264218: Public method
 javax.swing.JMenu.setComponentOrientation() has no spec
Message-ID: <fE_D6hYcS325YttYkBA0vtYvoy-zcbHxeq_Ej0qOJr4=.93a225ad-dbc5-4f41-990d-d24f7ff12b1f@github.com>

A public overriding method JMenu.setComponentOrientation(java.awt.ComponentOrientation)
has no spec.
Added spec for the method.

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

Commit messages:
 - 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec

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

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

From azvegint at openjdk.java.net  Fri Mar 26 12:05:26 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 26 Mar 2021 12:05:26 GMT
Subject: <Swing Dev> RFR: 8263496:
 MetalHighContrastTheme.getControlHighlight cleanup
In-Reply-To: <rOYqgr_YJpr8B1P7AF2etcXxx4LBwiiTfIH1UhmFRN8=.46ea3b85-c2f7-4613-b2ba-36cc955a77a8@github.com>
References: <rOYqgr_YJpr8B1P7AF2etcXxx4LBwiiTfIH1UhmFRN8=.46ea3b85-c2f7-4613-b2ba-36cc955a77a8@github.com>
Message-ID: <UXsxElPauI_dUWveBJfa26lXwvs310g7JQNiqjz1uus=.09fa3796-4822-4d08-a4be-db6415912e6f@github.com>

On Tue, 23 Mar 2021 10:26:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> SonarCloud reports the potential issue with MetalHighContrastTheme.getControlHighlight where `controlHighlight ` field is not used and the getControlHighlight() uses secondary field.
> public ColorUIResource getControlHighlight() {
>         // This was super.getSecondary3();
>         return secondary2;
>     } 
> Removed the unused field.

Marked as reviewed by azvegint (Reviewer).

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

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

From herrick at openjdk.java.net  Fri Mar 26 14:51:28 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 26 Mar 2021 14:51:28 GMT
Subject: <Swing Dev> Integrated: 8189198: Add "forRemoval = true" to Applet
 API deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <4WWT8Ziy2C8n3V8-SQqJ_SNHpYlyB1uO26I-Szzm29c=.d2041dca-362a-4285-a961-7f71635df559@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

This pull request has now been integrated.

Changeset: 57115fa2
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/57115fa2
Stats:     73 lines in 22 files changed: 14 ins; 0 del; 59 mod

8189198: Add "forRemoval = true" to Applet API deprecations

Reviewed-by: iris, almatvee, kcr, prr

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

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

From serb at openjdk.java.net  Sat Mar 27 01:23:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 27 Mar 2021 01:23:25 GMT
Subject: <Swing Dev> RFR: 8264218: Public method
 javax.swing.JMenu.setComponentOrientation() has no spec
In-Reply-To: <fE_D6hYcS325YttYkBA0vtYvoy-zcbHxeq_Ej0qOJr4=.93a225ad-dbc5-4f41-990d-d24f7ff12b1f@github.com>
References: <fE_D6hYcS325YttYkBA0vtYvoy-zcbHxeq_Ej0qOJr4=.93a225ad-dbc5-4f41-990d-d24f7ff12b1f@github.com>
Message-ID: <KpKx6Bsibq7d0rTq98P50G5SpOG9k2hIBnKjkDRlRZw=.ad5da6ab-3ef0-4e4b-9aea-02122110bb07@github.com>

On Fri, 26 Mar 2021 11:30:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> A public overriding method JMenu.setComponentOrientation(java.awt.ComponentOrientation)
> has no spec.
> Added spec for the method.

Looks like the JavaDoc bug, the spec was there in jdk7:
https://docs.oracle.com/javase/7/docs/api/javax/swing/JMenu.html#setComponentOrientation(java.awt.ComponentOrientation)

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

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

From serb at openjdk.java.net  Sun Mar 28 00:30:44 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 28 Mar 2021 00:30:44 GMT
Subject: <Swing Dev> RFR: 8264328: Broken license in
 javax/swing/JComboBox/8072767/bug8072767.java
Message-ID: <-B4T2kagAgO1uCf0SCBm2F5i_Uwuz7azy74v1AUt48I=.aeae9cf7-5126-4c25-9122-1df181925e2e@github.com>

This test has a broken license:
/*
 * To change this license header, choose License Headers in Project Properties.
 * To change this template file, choose Tools | Templates
 /*
 * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

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

Commit messages:
 - Update bug8072767.java

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

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

From kizune at openjdk.java.net  Sun Mar 28 07:45:33 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sun, 28 Mar 2021 07:45:33 GMT
Subject: <Swing Dev> RFR: 8264328: Broken license in
 javax/swing/JComboBox/8072767/bug8072767.java
In-Reply-To: <-B4T2kagAgO1uCf0SCBm2F5i_Uwuz7azy74v1AUt48I=.aeae9cf7-5126-4c25-9122-1df181925e2e@github.com>
References: <-B4T2kagAgO1uCf0SCBm2F5i_Uwuz7azy74v1AUt48I=.aeae9cf7-5126-4c25-9122-1df181925e2e@github.com>
Message-ID: <-TDhQcmsCjsUNNXfOxjN9H1DD3bdMKIBgMyEnfEndhI=.d12b2d1b-1630-4a62-9e7d-5a8476b9f377@github.com>

On Sun, 28 Mar 2021 00:21:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This test has a broken license:
> /*
>  * To change this license header, choose License Headers in Project Properties.
>  * To change this template file, choose Tools | Templates
>  /*
>  * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Marked as reviewed by kizune (Reviewer).

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

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

From trebari at openjdk.java.net  Sun Mar 28 07:50:42 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Sun, 28 Mar 2021 07:50:42 GMT
Subject: <Swing Dev> RFR: 8264328: Broken license in
 javax/swing/JComboBox/8072767/bug8072767.java
In-Reply-To: <-B4T2kagAgO1uCf0SCBm2F5i_Uwuz7azy74v1AUt48I=.aeae9cf7-5126-4c25-9122-1df181925e2e@github.com>
References: <-B4T2kagAgO1uCf0SCBm2F5i_Uwuz7azy74v1AUt48I=.aeae9cf7-5126-4c25-9122-1df181925e2e@github.com>
Message-ID: <Mh791JWCEzzm-grHjcaZMgq7QP_OqeB8-8scqpiIHYQ=.db7a1c8b-e98f-4bff-a349-4797978a8dad@github.com>

On Sun, 28 Mar 2021 00:21:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This test has a broken license:
> /*
>  * To change this license header, choose License Headers in Project Properties.
>  * To change this template file, choose Tools | Templates
>  /*
>  * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Marked as reviewed by trebari (Committer).

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

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

From pbansal at openjdk.java.net  Sun Mar 28 08:05:33 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sun, 28 Mar 2021 08:05:33 GMT
Subject: <Swing Dev> RFR: 8264328: Broken license in
 javax/swing/JComboBox/8072767/bug8072767.java
In-Reply-To: <-B4T2kagAgO1uCf0SCBm2F5i_Uwuz7azy74v1AUt48I=.aeae9cf7-5126-4c25-9122-1df181925e2e@github.com>
References: <-B4T2kagAgO1uCf0SCBm2F5i_Uwuz7azy74v1AUt48I=.aeae9cf7-5126-4c25-9122-1df181925e2e@github.com>
Message-ID: <5ODLYs1f8SNU82hRKnSj4JgI-mjddF-nUQtYiCs-9vQ=.1a216316-66cd-4b24-8e4a-5b924282b2bc@github.com>

On Sun, 28 Mar 2021 00:21:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This test has a broken license:
> /*
>  * To change this license header, choose License Headers in Project Properties.
>  * To change this template file, choose Tools | Templates
>  /*
>  * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Marked as reviewed by pbansal (Reviewer).

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

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

From serb at openjdk.java.net  Mon Mar 29 03:45:30 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 29 Mar 2021 03:45:30 GMT
Subject: <Swing Dev> Integrated: 8264328: Broken license in
 javax/swing/JComboBox/8072767/bug8072767.java
In-Reply-To: <-B4T2kagAgO1uCf0SCBm2F5i_Uwuz7azy74v1AUt48I=.aeae9cf7-5126-4c25-9122-1df181925e2e@github.com>
References: <-B4T2kagAgO1uCf0SCBm2F5i_Uwuz7azy74v1AUt48I=.aeae9cf7-5126-4c25-9122-1df181925e2e@github.com>
Message-ID: <DQBYvCtRCCwvk7rypzvepfVG9FZtOJzeZm3xYOABl9g=.a0d5d747-27d3-4830-a51f-076a65496281@github.com>

On Sun, 28 Mar 2021 00:21:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This test has a broken license:
> /*
>  * To change this license header, choose License Headers in Project Properties.
>  * To change this template file, choose Tools | Templates
>  /*
>  * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

This pull request has now been integrated.

Changeset: 6678b01c
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6678b01c
Stats:     4 lines in 1 file changed: 0 ins; 3 del; 1 mod

8264328: Broken license in javax/swing/JComboBox/8072767/bug8072767.java

Reviewed-by: kizune, trebari, pbansal

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

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

From pbansal at openjdk.java.net  Tue Mar 30 09:49:47 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 30 Mar 2021 09:49:47 GMT
Subject: <Swing Dev> RFR: 8262981: Create implementation for
 NSAccessibilitySlider protocol
In-Reply-To: <DCrevod6zxfkoOzlPjkMNHD1P0fDn_JTwhozVOSUWLc=.e631377d-e7f7-4a11-9dd1-6f63859ce515@github.com>
References: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
 <3kHCT6j_xnm9mbA2jeP35p9rY4nxOD61PInSB9mglT8=.71c3b9df-0cc3-40f7-b339-15b382e36b6f@github.com>
 <WaDY3XBH6a6nPencpEbkyZjTnX5iqzxX9wZZ5eKI6KI=.a32e0717-0736-417c-84c0-bbb858bc2e35@github.com>
 <4SZRIR695DBooSWt-1aatGx-CKPy6EwuRpXS29A8wro=.4ba37fe2-6017-482f-83c4-33d7a11fc320@github.com>
 <B0hF7cV-7O7pclnhmX7C4Biw20C5CLtIM11C6z5Tin0=.f06fa7ce-9049-454e-80f8-36935f3e0301@github.com>
 <zHiKUzH6bz3rwjjzbRQv4DgwaQ-J8FjFnTrKTKi_7kM=.5cb87998-4512-4c73-a673-038426b71171@github.com>
 <60QaQ3ISOvoR5RMWU1hTSCsiBHfy7xU2QjvLzrGaSvA=.c02ab62e-5176-4015-a16c-849a71088452@github.com>
 <yaOXyCB7ZJx5mE_xkXh0bwZPQXDzusbe55a-UAYPSEk=.f1928607-0fa6-4b04-bc2b-a089acfcb628@github.com>
 <DCrevod6zxfkoOzlPjkMNHD1P0fDn_JTwhozVOSUWLc=.e631377d-e7f7-4a11-9dd1-6f63859ce515@github.com>
Message-ID: <k5Gk0fgUXf7yuAv5tMJzJ4S4wYfAWHmKz7rYRyZ0UIs=.efdfba09-a9fa-403d-b0d2-0605729e9eb0@github.com>

On Wed, 17 Mar 2021 01:48:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > It looks like the Dialog must have handled the keys as there are no special keys mentioned for JAWS to interact with the component like the VO
> 
> Did you check this list of hotkeys?
> https://www.freedomscientific.com/training/jaws/hotkeys
> https://freedomscientific.github.io/VFO-standards-support/aria.html
> Something like:
> RIGHT ARROW and UP ARROW increase the value of the slider.
> LEFT ARROW and DOWN ARROW decrease the value of the slider.
> HOME and END move to the minimum and maximum values of the slider.
> PAGE UP and PAGE DOWN increment or decrement the slider by a given amount.
> 
> =======================
> My main point is that if we will change some shared code we should care about both supported platforms.

I tried the hot keys with the both native dialog ("Display Settings" with a "Brightness" Slider ) and java applications. 
Both Java and native dialog  are themselves handling the RIGHT ARROW, UP ARROW, LEFT ARROW, DOWN ARROW, HOME and END buttons for JSlider and user can change slider value using these keys without JAWS also. but they are not handling the PAGE UP and PAGE DOWN button.
PAGE UP and PAGE DOWN button don't work with JAWS either, meaning JAWS is not able to handle the keys and is not able to change component values for both native dialogs and Java application. Also, I am not able to find any component in Swing, where JAWS can change the component values using any hot key. Please correct me if I am wrong in this and JAWS can actually manipulate some component. Also, in the old implementation for MacOS , the VO can not change the Spinner/Slider values and we are adding this functionality now only. 
In addition to this, the functionality we are adding in slider can be used with JAWS also if we decide to provide the support for the same later. Currently, I do not see JAWS being able to change any component value in swing, so it will not be able to change Slider value too.

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

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

From shade at openjdk.java.net  Tue Mar 30 13:02:33 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 30 Mar 2021 13:02:33 GMT
Subject: <Swing Dev> RFR: 8264428: Replace uses of StringBuffer with
 StringBuilder in java.desktop
In-Reply-To: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>
References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>
Message-ID: <OYj2953f0x9pdKEhuSH42Z6esy3iynF4-3F9WZA8EO0=.0c964e47-3802-45b3-9839-17e358981868@github.com>

On Mon, 29 Mar 2021 20:50:14 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.desktop`
> Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029

Submitted: https://bugs.openjdk.java.net/browse/JDK-8264428, please rename PR to "8264428: Replace uses of StringBuffer with StringBuilder in java.desktop".

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar 30 13:02:32 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 30 Mar 2021 13:02:32 GMT
Subject: <Swing Dev> RFR: 8264428: Replace uses of StringBuffer with
 StringBuilder in java.desktop
Message-ID: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>

Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.desktop`
Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029

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

Commit messages:
 - [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar 30 18:34:08 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 30 Mar 2021 18:34:08 GMT
Subject: <Swing Dev> RFR: 8264428: Replace uses of StringBuffer with
 StringBuilder in java.desktop
In-Reply-To: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>
References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>
Message-ID: <HMCzNL_mAseqa95XZS9iKIG6K6ecqtxxWAVUDtKv8gI=.4aa9b5bd-495d-4488-821d-2ebd1c77cdcb@github.com>

On Mon, 29 Mar 2021 20:50:14 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.desktop`
> Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029

src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFFieldNode.java line 127:

> 125:                 StringBuilder sb = new StringBuilder();
> 126:                 for (int i = 0; i < count; i++) {
> 127:                     sb.append((data[i] & 0xff));

Remove redundant parentheses

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar 30 19:05:38 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 30 Mar 2021 19:05:38 GMT
Subject: <Swing Dev> RFR: 8264428: Replace uses of StringBuffer with
 StringBuilder in java.desktop [v2]
In-Reply-To: <HMCzNL_mAseqa95XZS9iKIG6K6ecqtxxWAVUDtKv8gI=.4aa9b5bd-495d-4488-821d-2ebd1c77cdcb@github.com>
References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>
 <HMCzNL_mAseqa95XZS9iKIG6K6ecqtxxWAVUDtKv8gI=.4aa9b5bd-495d-4488-821d-2ebd1c77cdcb@github.com>
Message-ID: <sr4g3rzUpV-N1GUFK5Ips4ZZ5KAUJGw0BvnkaXdepbQ=.98f7e224-64bc-46ac-baaa-6430a92130bf@github.com>

On Tue, 30 Mar 2021 18:31:34 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop
>
> src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFFieldNode.java line 127:
> 
>> 125:                 StringBuilder sb = new StringBuilder();
>> 126:                 for (int i = 0; i < count; i++) {
>> 127:                     sb.append((data[i] & 0xff));
> 
> Remove redundant parentheses

fixed.
It's suspicious that IDEA wasn't able to remove them by itself. Reported https://youtrack.jetbrains.com/issue/IDEA-265548

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar 30 19:05:37 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 30 Mar 2021 19:05:37 GMT
Subject: <Swing Dev> RFR: 8264428: Replace uses of StringBuffer with
 StringBuilder in java.desktop [v2]
In-Reply-To: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>
References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>
Message-ID: <YjutOPE7zU7j6mJgKHbFBZXDVijxc7dQvabEPdPhHHU=.def4ecf3-5d0f-4885-8331-9695a6cbee89@github.com>

> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.desktop`
> Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029

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

  [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3251/files
  - new: https://git.openjdk.java.net/jdk/pull/3251/files/9bd4e523..80bff1db

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

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

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

From trebari at openjdk.java.net  Wed Mar 31 05:22:20 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Wed, 31 Mar 2021 05:22:20 GMT
Subject: <Swing Dev> RFR: 8253266 : JList and JTable constructors should
 clear OPAQUE_SET before calling updateUI [v2]
In-Reply-To: <lYEyAPYiL2u-exOk4EStTVHQ9Y0TINhxOIhUC8kHleE=.2e5b493b-158f-4c7c-9159-c07e1685da0f@github.com>
References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com>
 <lYEyAPYiL2u-exOk4EStTVHQ9Y0TINhxOIhUC8kHleE=.2e5b493b-158f-4c7c-9159-c07e1685da0f@github.com>
Message-ID: <TcG4QPQIpJPZdexEP5yeZwbqAt57BSWxNmny3zK4DF0=.1167640a-c452-43c7-a24f-46f19760b5ed@github.com>

On Wed, 24 Mar 2021 08:27:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added default value check for opaque property
>
> I am not sure if this is the correct fix, as then we would have to remove setOpaque call for JTree, JToolTip, JRootPane etc where we might face same installProperty issue. 
> Also, if we have to change this, we then need to change "autoScrolls" property too which is set in this 2 component and setUIProperty() can change those too.
> Probably, we need to check if the value to be set is different in setUIProperty and then set it 
> or 
> override setUIProperty per component basis (as it is done for JTable) and then not check for OPAQUE_SET flag for opaque property accordingly.

@prsadhuk  @mrserb is there any more comments on this.

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

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

From trebari at openjdk.java.net  Wed Mar 31 05:25:21 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Wed, 31 Mar 2021 05:25:21 GMT
Subject: <Swing Dev> RFR: 8049700: Deprecate obsolete classes and
 methods in javax/swing/plaf/basic [v6]
In-Reply-To: <oXYDIU1R0lheFPOmsKpg5FJko0rIggaVfcMktIChkj8=.c3ca1f34-c5a6-4e4c-b097-0406908b0ec9@github.com>
References: <LcIvlc2HZGDo6ErOfqf_QZlwCpO2a7o2pPIDeaCb40E=.80fa98b5-728e-4198-a4fd-8d70e21302fc@github.com>
 <Omn4vN7y_rSL1kyekfnJfwZpaUl7AKun4Sq9XqE7AVk=.077cd2e8-3be4-4769-b781-2f9da780fed0@github.com>
 <oXYDIU1R0lheFPOmsKpg5FJko0rIggaVfcMktIChkj8=.c3ca1f34-c5a6-4e4c-b097-0406908b0ec9@github.com>
Message-ID: <SN8-Y2UG221XIOGsj0hp87mjNv27bQX2HeR5rHUx77o=.59bf13e3-1c60-47d9-8b13-b2ef5d5d5625@github.com>

On Wed, 10 Feb 2021 18:04:16 GMT, Phil Race <prr at openjdk.org> wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed deprecation from methods of class which is also getting deprecated
>
> Are these methods all expected to be used only by a L&F rather than an application ?
> If by an application, then forRemoval seems too strong to me.
> If by a L&F then I think you need to go research what open source L&Fs there are out there and see how many of them are affected. Then we can decide about forRemoval.

@prrace any more comments on this ?

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

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

From jiefu at openjdk.java.net  Wed Mar 31 16:38:24 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 31 Mar 2021 16:38:24 GMT
Subject: <Swing Dev> RFR: 8264526:
 javax/swing/text/html/parser/Parser/8078268/bug8078268.java timeout
Message-ID: <ddDvBGsuZ8Mn1uBVY5ISoRrpsdCas3v2CwsCld73Zes=.44f38ab9-e030-42d6-b1df-e34eb03aac0b@github.com>

Hi all,

I'd like to fix the timeout of javax/swing/text/html/parser/Parser/8078268/bug8078268.java. 
It seems to take about 6~7 seconds to run on some of our testing platforms.
But the timeout of the test is hard-coded as 5 seconds.

The fix just increases the timeout from 5 seconds to 10 seconds.

Thanks.
Best regards,
Jie

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

Commit messages:
 - Update the copyright year
 - 8264526: javax/swing/text/html/parser/Parser/8078268/bug8078268.java timeout

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

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

From azvegint at openjdk.java.net  Wed Mar 31 19:01:26 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 31 Mar 2021 19:01:26 GMT
Subject: <Swing Dev> RFR: 8264526:
 javax/swing/text/html/parser/Parser/8078268/bug8078268.java timeout
In-Reply-To: <ddDvBGsuZ8Mn1uBVY5ISoRrpsdCas3v2CwsCld73Zes=.44f38ab9-e030-42d6-b1df-e34eb03aac0b@github.com>
References: <ddDvBGsuZ8Mn1uBVY5ISoRrpsdCas3v2CwsCld73Zes=.44f38ab9-e030-42d6-b1df-e34eb03aac0b@github.com>
Message-ID: <p5B_-m6ZjDkPxxCF2WZ283Kv_HcgO1t3P8maayxB2fo=.079f01a7-2a7b-41db-a580-5db9f270c252@github.com>

On Wed, 31 Mar 2021 16:23:23 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> I'd like to fix the timeout of javax/swing/text/html/parser/Parser/8078268/bug8078268.java. 
> It seems to take about 6~7 seconds to run on some of our testing platforms.
> But the timeout of the test is hard-coded as 5 seconds.
> 
> The fix just increases the timeout from 5 seconds to 10 seconds.
> 
> Thanks.
> Best regards,
> Jie

[JDK-8078268](https://bugs.openjdk.java.net/browse/JDK-8078268) description says that it takes minutes to parse to complete before the fix. So 10 seconds is not a big deal comparing to minutes. However it might indicate a slight drop in performance. 

> It seems to take about 6~7 seconds to run on some of our testing platforms.

Did it fail on these platforms from the beginning of your testing with `bug8078268`?

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

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

From serb at openjdk.java.net  Wed Mar 31 19:59:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 31 Mar 2021 19:59:25 GMT
Subject: <Swing Dev> RFR: 8262981: Create implementation for
 NSAccessibilitySlider protocol
In-Reply-To: <k5Gk0fgUXf7yuAv5tMJzJ4S4wYfAWHmKz7rYRyZ0UIs=.efdfba09-a9fa-403d-b0d2-0605729e9eb0@github.com>
References: <Vj1FL5dPDocBzqxo-S--CAKnjDzvJYLrXRdIGI3yAL0=.342b48bb-f6cf-40a1-8df6-fc1b192abaf5@github.com>
 <3kHCT6j_xnm9mbA2jeP35p9rY4nxOD61PInSB9mglT8=.71c3b9df-0cc3-40f7-b339-15b382e36b6f@github.com>
 <WaDY3XBH6a6nPencpEbkyZjTnX5iqzxX9wZZ5eKI6KI=.a32e0717-0736-417c-84c0-bbb858bc2e35@github.com>
 <4SZRIR695DBooSWt-1aatGx-CKPy6EwuRpXS29A8wro=.4ba37fe2-6017-482f-83c4-33d7a11fc320@github.com>
 <B0hF7cV-7O7pclnhmX7C4Biw20C5CLtIM11C6z5Tin0=.f06fa7ce-9049-454e-80f8-36935f3e0301@github.com>
 <zHiKUzH6bz3rwjjzbRQv4DgwaQ-J8FjFnTrKTKi_7kM=.5cb87998-4512-4c73-a673-038426b71171@github.com>
 <60QaQ3ISOvoR5RMWU1hTSCsiBHfy7xU2QjvLzrGaSvA=.c02ab62e-5176-4015-a16c-849a71088452@github.com>
 <yaOXyCB7ZJx5mE_xkXh0bwZPQXDzusbe55a-UAYPSEk=.f1928607-0fa6-4b04-bc2b-a089acfcb628@github.com>
 <DCrevod6zxfkoOzlPjkMNHD1P0fDn_JTwhozVOSUWLc=.e631377d-e7f7-4a11-9dd1-6f63859ce515@github.com>
 <k5Gk0fgUXf7yuAv5tMJzJ4S4wYfAWHmKz7rYRyZ0UIs=.efdfba09-a9fa-403d-b0d2-0605729e9eb0@github.com>
Message-ID: <qboUVTZL9llN5fFpdFtHfBeCUfuVI_OlBvgcUDU0xcg=.2eae929b-b10d-4644-b36f-dda1a3d8b1d4@github.com>

On Tue, 30 Mar 2021 09:46:45 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>>> It looks like the Dialog must have handled the keys as there are no special keys mentioned for JAWS to interact with the component like the VO
>> 
>> Did you check this list of hotkeys?
>> https://www.freedomscientific.com/training/jaws/hotkeys
>> https://freedomscientific.github.io/VFO-standards-support/aria.html
>> Something like:
>>     RIGHT ARROW and UP ARROW increase the value of the slider.
>>     LEFT ARROW and DOWN ARROW decrease the value of the slider.
>>     HOME and END move to the minimum and maximum values of the slider.
>>     PAGE UP and PAGE DOWN increment or decrement the slider by a given amount.
>> 
>> =======================
>> My main point is that if we will change some shared code we should care about both supported platforms.
>
>> > It looks like the Dialog must have handled the keys as there are no special keys mentioned for JAWS to interact with the component like the VO
>> 
>> Did you check this list of hotkeys?
>> https://www.freedomscientific.com/training/jaws/hotkeys
>> https://freedomscientific.github.io/VFO-standards-support/aria.html
>> Something like:
>> RIGHT ARROW and UP ARROW increase the value of the slider.
>> LEFT ARROW and DOWN ARROW decrease the value of the slider.
>> HOME and END move to the minimum and maximum values of the slider.
>> PAGE UP and PAGE DOWN increment or decrement the slider by a given amount.
>> 
>> =======================
>> My main point is that if we will change some shared code we should care about both supported platforms.
> 
> I tried the hot keys with the both native dialog ("Display Settings" with a "Brightness" Slider ) and java applications. 
> Both Java and native dialog  are themselves handling the RIGHT ARROW, UP ARROW, LEFT ARROW, DOWN ARROW, HOME and END buttons for JSlider and user can change slider value using these keys without JAWS also. but they are not handling the PAGE UP and PAGE DOWN button.
> PAGE UP and PAGE DOWN button don't work with JAWS either, meaning JAWS is not able to handle the keys and is not able to change component values for both native dialogs and Java application. Also, I am not able to find any component in Swing, where JAWS can change the component values using any hot key. Please correct me if I am wrong in this and JAWS can actually manipulate some component. Also, in the old implementation for MacOS , the VO can not change the Spinner/Slider values and we are adding this functionality now only. 
> In addition to this, the functionality we are adding in slider can be used with JAWS also if we decide to provide the support for the same later. Currently, I do not see JAWS being able to change any component value in swing, so it will not be able to change Slider value too.

Ok, please file a similar bug for the windows platform.

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

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

From serb at openjdk.java.net  Wed Mar 31 20:33:27 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 31 Mar 2021 20:33:27 GMT
Subject: <Swing Dev> RFR: JDK-8263235 :
 sanity/client/SwingSet/src/ColorChooserDemoTest.java failed throwing
 java.lang.NoClassDefFoundError [v2]
In-Reply-To: <GVCDxshdTSdGBdY9rmKBpOXkyXc-tE1ttvHYXBwJSv0=.44a9a3d8-40d7-456d-a318-98e60fc8b411@github.com>
References: <7wHhDXuqX0oZMwq82WEmTlzRxsHYy7IBhsehPKFwtIo=.7565e4dc-175a-46b4-9cc7-dc3d4b23f240@github.com>
 <GVCDxshdTSdGBdY9rmKBpOXkyXc-tE1ttvHYXBwJSv0=.44a9a3d8-40d7-456d-a318-98e60fc8b411@github.com>
Message-ID: <RPDSttcdpbEqw6XHD_7W9JM4xV3_hVcQSdmza9nL890=.f13dc020-f301-4ae5-b798-db95f458fbf2@github.com>

On Fri, 12 Mar 2021 14:39:23 GMT, Amresh Sahu <github.com+72060147+amresh-sahu at openjdk.org> wrote:

>> Added @build org.jemmy2ext.JemmyExt.
>
> Amresh Sahu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8263235:Added @build org.jemmy2ext.JemmyExt

Marked as reviewed by serb (Reviewer).

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

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

From github.com+72060147+amresh-sahu at openjdk.java.net  Wed Mar 31 20:36:25 2021
From: github.com+72060147+amresh-sahu at openjdk.java.net (Amresh Sahu)
Date: Wed, 31 Mar 2021 20:36:25 GMT
Subject: <Swing Dev> Integrated: JDK-8263235 :
 sanity/client/SwingSet/src/ColorChooserDemoTest.java failed throwing
 java.lang.NoClassDefFoundError
In-Reply-To: <7wHhDXuqX0oZMwq82WEmTlzRxsHYy7IBhsehPKFwtIo=.7565e4dc-175a-46b4-9cc7-dc3d4b23f240@github.com>
References: <7wHhDXuqX0oZMwq82WEmTlzRxsHYy7IBhsehPKFwtIo=.7565e4dc-175a-46b4-9cc7-dc3d4b23f240@github.com>
Message-ID: <mGE_nLrAxp080JtNGtsrgBVkugQzlLxX4mCDG1ovVdo=.0fabaf27-87b9-46eb-862f-8b2cfc0f3741@github.com>

On Fri, 12 Mar 2021 05:29:01 GMT, Amresh Sahu <github.com+72060147+amresh-sahu at openjdk.org> wrote:

> Added @build org.jemmy2ext.JemmyExt.

This pull request has now been integrated.

Changeset: cb70ab0c
Author:    Your Name <you at example.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cb70ab0c
Stats:     2 lines in 2 files changed: 2 ins; 0 del; 0 mod

8263235: sanity/client/SwingSet/src/ColorChooserDemoTest.java failed throwing java.lang.NoClassDefFoundError

Reviewed-by: psadhukhan, serb

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

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

From serb at openjdk.java.net  Wed Mar 31 20:38:22 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 31 Mar 2021 20:38:22 GMT
Subject: <Swing Dev> RFR: 8253266 : JList and JTable constructors should
 clear OPAQUE_SET before calling updateUI [v2]
In-Reply-To: <XUYiefJZ2r3vJj2D2LvCcaFAC1_KP4jh5t0-LZHkM5c=.05bb873f-c75d-4d3b-b0c5-78e367885f89@github.com>
References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com>
 <XUYiefJZ2r3vJj2D2LvCcaFAC1_KP4jh5t0-LZHkM5c=.05bb873f-c75d-4d3b-b0c5-78e367885f89@github.com>
Message-ID: <ne6QcZIyq6DehRNJrg0UNw_FXBxKdIXdwCJtZQPHCYM=.af153a38-9ab7-437f-a934-1b611377008c@github.com>

On Thu, 25 Mar 2021 08:03:21 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> Hi All,
>> Please review the following fix for jdk17.
>> 
>> Issue : LookAndFeel.installProperty(list, "opaque", false) is not able to set the opaque property for JList and JTable.
>> LookAndFeel.installProperty calls the setUIProperty, and setUIProperty checks for OPAQUE_SET to change the opaque property as requested by the client.
>> OPAQUE_SET is always set to true when there is call to setOpaque(boolean).So when the constructor calls setOpaque(true) OPAQUE_SET is set to true and wont allow the setUIProperty to change the opaque property.
>> installProperty should work as the opaque property is not set by the client.
>> 
>> Fix. Fix is to remove the call to the setOpaque() from the constructor of JList and JTable. This will allow the client to change the opaque property calling LookAndFeel.installProperty() when the property is already not set.
>> 
>> Test : Added a  test  to check the same. Also tested internal tests which all are passing.
>> Link is in JBS.
>
> Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added default value check for opaque property

Please wait for the @prsadhuk approval as well.

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

Marked as reviewed by serb (Reviewer).

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

From serb at openjdk.java.net  Wed Mar 31 21:15:30 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 31 Mar 2021 21:15:30 GMT
Subject: <Swing Dev> RFR: 8264428: Replace uses of StringBuffer with
 StringBuilder in java.desktop
In-Reply-To: <OYj2953f0x9pdKEhuSH42Z6esy3iynF4-3F9WZA8EO0=.0c964e47-3802-45b3-9839-17e358981868@github.com>
References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>
 <OYj2953f0x9pdKEhuSH42Z6esy3iynF4-3F9WZA8EO0=.0c964e47-3802-45b3-9839-17e358981868@github.com>
Message-ID: <27yKI-MoNpdtE7_qYEHLNj-tmphsEvwwT7NunRjEY5c=.d585ed9c-b74c-4b82-8c24-fca05d944f58@github.com>

On Tue, 30 Mar 2021 12:39:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
>> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.desktop`
>> Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029
>
> Submitted: https://bugs.openjdk.java.net/browse/JDK-8264428, please rename PR to "8264428: Replace uses of StringBuffer with StringBuilder in java.desktop".

Looks like this change goes beyond of simple replacement of  StringBuffer with StringBuilder. Please update the description of the bug and PR description.

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

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

From jiefu at openjdk.java.net  Wed Mar 31 23:32:07 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 31 Mar 2021 23:32:07 GMT
Subject: <Swing Dev> RFR: 8264526:
 javax/swing/text/html/parser/Parser/8078268/bug8078268.java timeout
In-Reply-To: <p5B_-m6ZjDkPxxCF2WZ283Kv_HcgO1t3P8maayxB2fo=.079f01a7-2a7b-41db-a580-5db9f270c252@github.com>
References: <ddDvBGsuZ8Mn1uBVY5ISoRrpsdCas3v2CwsCld73Zes=.44f38ab9-e030-42d6-b1df-e34eb03aac0b@github.com>
 <p5B_-m6ZjDkPxxCF2WZ283Kv_HcgO1t3P8maayxB2fo=.079f01a7-2a7b-41db-a580-5db9f270c252@github.com>
Message-ID: <jJ9H7_o0xFf73hS2lqwSa8ohnjeyqjiUuTiOzYeZddk=.b59a25c6-bf6b-40ef-b8fb-d7a3f74511b1@github.com>

On Wed, 31 Mar 2021 18:57:50 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Did it fail on these platforms from the beginning of your testing with `bug8078268`?

No.

This week I add some testing infrastructure on dockers.
The timeout seems only to be observed on these dockers intermittently.
Thanks.

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

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