From serb at openjdk.java.net  Sun Aug  1 08:47:24 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 1 Aug 2021 08:47:24 GMT
Subject: <Swing Dev> RFR: 8271456: Avoid looking up standard charsets in
 "java.desktop" module
Message-ID: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>

This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module.

In many places standard charsets are looked up via their names, for example:
absolutePath.getBytes("UTF-8");

This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets:
absolutePath.getBytes(StandardCharsets.UTF_8);

The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.

Tested by the desktop headless/headful tests on linux/windows.

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

Commit messages:
 - Initial fix for JDK-8271456

Changes: https://git.openjdk.java.net/jdk/pull/4951/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4951&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271456
  Stats: 641 lines in 28 files changed: 276 ins; 237 del; 128 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4951.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4951/head:pull/4951

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

From psadhukhan at openjdk.java.net  Mon Aug  2 05:00:18 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 2 Aug 2021 05:00:18 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v2]
In-Reply-To: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
Message-ID: <e75oGeybsRKX17FZaNihsb_ZLHogIQhT5WER0pkMy-M=.b437f763-29ca-4312-bbcd-6043da0b47da@github.com>

> The Nimbus look and feel ignores the configured background color of a JTextPane and always uses white. 
> Every other look and feel tested (Metal, Motif, and Windows) correctly honors the configured background color of a JTextPane.
> Issue seems to be in the hardcoded background color in nimbus skin which is rectified via the fix. 
> After this fix, the background color is correctly updated to whatever is being set via JTextPane.setBackground().
> 
> CI all test run is green.

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - Fix
 - JEditorpane background color fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4930/files
  - new: https://git.openjdk.java.net/jdk/pull/4930/files/920f71dc..ccde17d7

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

  Stats: 116 lines in 3 files changed: 97 ins; 8 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4930.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4930/head:pull/4930

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

From psadhukhan at openjdk.java.net  Mon Aug  2 05:00:19 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 2 Aug 2021 05:00:19 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color
In-Reply-To: <ZOhehnDPS1hDmybZSxVR1ZAohdVVglyjFYrN080JU_8=.4b175970-642f-4b36-8417-f6cc8d1e34ba@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <sR3lN4mGxWnCiVnobjL1mZWyiKcem5Tlo0hapyyUXWk=.9cea8533-3046-4492-baad-987675bfccfb@github.com>
 <ZOhehnDPS1hDmybZSxVR1ZAohdVVglyjFYrN080JU_8=.4b175970-642f-4b36-8417-f6cc8d1e34ba@github.com>
Message-ID: <GF55sFnG_2xjInl9w01VaRh2VmVbnR-mbT8Ft7C1Tfc=.19a9c539-9f66-4c37-8cb0-5e2368a852b5@github.com>

On Fri, 30 Jul 2021 20:39:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> 
> 
> Does the JEditorPane have the same issue?
> https://bugs.openjdk.java.net/browse/JDK-6789980

Yes, fixed

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

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

From psadhukhan at openjdk.java.net  Mon Aug  2 05:00:22 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 2 Aug 2021 05:00:22 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v2]
In-Reply-To: <d9yEeogX3Y5DGiYY56k62I84hwwiCFBcAXu6pZHLthY=.0ac835c6-447a-45fb-bc54-77f8de546472@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <d9yEeogX3Y5DGiYY56k62I84hwwiCFBcAXu6pZHLthY=.0ac835c6-447a-45fb-bc54-77f8de546472@github.com>
Message-ID: <JY7H8u7z3GTlBH6x5vZaNsUVNI0eDIt9jeyd7IruvBs=.ccc4ee04-458b-42d2-9c12-8abfb6244bce@github.com>

On Fri, 30 Jul 2021 20:42:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix
>>  - JEditorpane background color fix
>
> test/jdk/javax/swing/plaf/nimbus/TestNimbusJTextPaneColor.java line 74:
> 
>> 72:             if (frame != null) {
>> 73:                 SwingUtilities.invokeAndWait(frame::dispose);
>> 74:             }
> 
> `frame` is accessed on main thread without synchronisation.

NimbusLookAndFeel is customized look and feel but I don't see mention of default background color to be white in spec..If it is not set explicitly, background color is drawn in "NimbusBlueGrey" background which seems to be same as what is used in SwingSet2 demos in Nimbus L&F

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

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

From psadhukhan at openjdk.java.net  Mon Aug  2 09:26:53 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 2 Aug 2021 09:26:53 GMT
Subject: <Swing Dev> RFR: 6350025: API documentation for JOptionPane using
 deprecated methods.
Message-ID: <lmHrWkmTi6rnXc7lZ8XO8PisKx648hjTesINC3C0RDU=.21f4448f-144e-4f5b-8e38-d48a36446860@github.com>

The method show() in the JOptionPane javadoc example is deprecated. The recommended method to call would be setVisible(true).

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

Commit messages:
 - 6350025: API documentation for JOptionPane using deprecated methods.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Aug  2 14:37:29 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, 2 Aug 2021 14:37:29 GMT
Subject: <Swing Dev> RFR: 8271456: Avoid looking up standard charsets in
 "java.desktop" module
In-Reply-To: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
References: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
Message-ID: <jJJrM1KPz7vA_ILxilhvUbeu1s--PeLMyCn_AJqSXrk=.8f3c6d5b-38c1-4c0a-a836-02e0ef0bfddf@github.com>

On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> Tested by the desktop headless/headful tests on linux/windows.

Marked as reviewed by stsypanov at github.com (no known OpenJDK username).

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

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

From serb at openjdk.java.net  Mon Aug  2 22:16:31 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Aug 2021 22:16:31 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v2]
In-Reply-To: <e75oGeybsRKX17FZaNihsb_ZLHogIQhT5WER0pkMy-M=.b437f763-29ca-4312-bbcd-6043da0b47da@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <e75oGeybsRKX17FZaNihsb_ZLHogIQhT5WER0pkMy-M=.b437f763-29ca-4312-bbcd-6043da0b47da@github.com>
Message-ID: <jgqxu9J5b9YaCl1Bskr7pPtEq4qpW0aoZKtn7s9-CRQ=.813bd0fb-0cf8-4b51-8b86-0f82b6bd0eda@github.com>

On Mon, 2 Aug 2021 05:00:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The Nimbus look and feel ignores the configured background color of a JTextPane and always uses white. 
>> Every other look and feel tested (Metal, Motif, and Windows) correctly honors the configured background color of a JTextPane.
>> Issue seems to be in the hardcoded background color in nimbus skin which is rectified via the fix. 
>> After this fix, the background color is correctly updated to whatever is being set via JTextPane.setBackground().
>> 
>> CI all test run is green.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix
>  - JEditorpane background color fix

src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 25750:

> (failed to retrieve contents of file, check the PR for context)
What is the difference between background and shape tags?

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

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

From serb at openjdk.java.net  Mon Aug  2 22:16:32 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Aug 2021 22:16:32 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v2]
In-Reply-To: <JY7H8u7z3GTlBH6x5vZaNsUVNI0eDIt9jeyd7IruvBs=.ccc4ee04-458b-42d2-9c12-8abfb6244bce@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <d9yEeogX3Y5DGiYY56k62I84hwwiCFBcAXu6pZHLthY=.0ac835c6-447a-45fb-bc54-77f8de546472@github.com>
 <JY7H8u7z3GTlBH6x5vZaNsUVNI0eDIt9jeyd7IruvBs=.ccc4ee04-458b-42d2-9c12-8abfb6244bce@github.com>
Message-ID: <EMD6hYGWlpLpVHPVz7Mpt76Er1w9tSIbOvj3wzHCK9g=.455ce8e6-c914-42fe-b097-2e20a592c3bd@github.com>

On Mon, 2 Aug 2021 04:52:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/plaf/nimbus/TestNimbusJTextPaneColor.java line 74:
>> 
>>> 72:             if (frame != null) {
>>> 73:                 SwingUtilities.invokeAndWait(frame::dispose);
>>> 74:             }
>> 
>> `frame` is accessed on main thread without synchronisation.
>
> NimbusLookAndFeel is customized look and feel but I don't see mention of default background color to be white in spec..If it is not set explicitly, background color is drawn in "NimbusBlueGrey" background which seems to be same as what is used in SwingSet2 demos in Nimbus L&F

This is not specified since the color of L&F are implementation details, for Nimbus, some of them are described here:
https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/_nimbusDefaults.html

So when you delete the color from the xml, does the SwingSet2 still use the same color as before? Then for what the color in the xml was responsible?

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

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

From psadhukhan at openjdk.java.net  Tue Aug  3 05:47:36 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 3 Aug 2021 05:47:36 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v2]
In-Reply-To: <jgqxu9J5b9YaCl1Bskr7pPtEq4qpW0aoZKtn7s9-CRQ=.813bd0fb-0cf8-4b51-8b86-0f82b6bd0eda@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <e75oGeybsRKX17FZaNihsb_ZLHogIQhT5WER0pkMy-M=.b437f763-29ca-4312-bbcd-6043da0b47da@github.com>
 <jgqxu9J5b9YaCl1Bskr7pPtEq4qpW0aoZKtn7s9-CRQ=.813bd0fb-0cf8-4b51-8b86-0f82b6bd0eda@github.com>
Message-ID: <8zdodK_7aqrcZDCNTVCnNp9PSm3VMGamkLBrrt4QNDI=.06d2f6fb-1f9b-4f34-a8c6-ea546d6297a1@github.com>

On Mon, 2 Aug 2021 22:13:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix
>>  - JEditorpane background color fix
>
> src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 25750:
> 
>> (failed to retrieve contents of file, check the PR for context)
> What is the difference between background and shape tags?

I have looked at https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/_nimbusDefaults.html where default color for 
EditorPane.background and TextPane.background is NimbusBlueGrey and not White what we have now, so I think we are having what is being specified in nimbus-default.
SwingSet2 background color for the demos are same before and after the fix.
I am not sure about the difference between background and shape but I have ran full JCK/JTREG tests and all are fine. I also tried passing Nimbus L&F via CI script for JCK/jtreg tests and those are also same before and after fix.

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

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

From serb at openjdk.java.net  Tue Aug  3 06:06:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 3 Aug 2021 06:06:36 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v2]
In-Reply-To: <8zdodK_7aqrcZDCNTVCnNp9PSm3VMGamkLBrrt4QNDI=.06d2f6fb-1f9b-4f34-a8c6-ea546d6297a1@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <e75oGeybsRKX17FZaNihsb_ZLHogIQhT5WER0pkMy-M=.b437f763-29ca-4312-bbcd-6043da0b47da@github.com>
 <jgqxu9J5b9YaCl1Bskr7pPtEq4qpW0aoZKtn7s9-CRQ=.813bd0fb-0cf8-4b51-8b86-0f82b6bd0eda@github.com>
 <8zdodK_7aqrcZDCNTVCnNp9PSm3VMGamkLBrrt4QNDI=.06d2f6fb-1f9b-4f34-a8c6-ea546d6297a1@github.com>
Message-ID: <7KKvg035KagQnRnnJoKuSiQKw_w_Cmi1DaRvTON_iBA=.6a2b67c6-e14c-40a7-a956-68486aa9e77a@github.com>

On Tue, 3 Aug 2021 05:44:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 25750:
>> 
>>> (failed to retrieve contents of file, check the PR for context)
>> What is the difference between background and shape tags?
>
> I have looked at https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/_nimbusDefaults.html where default color for 
> EditorPane.background and TextPane.background is NimbusBlueGrey and not White what we have now, so I think we are having what is being specified in nimbus-default.
> SwingSet2 background color for the demos are same before and after the fix.
> I am not sure about the difference between background and shape but I have ran full JCK/JTREG tests and all are fine. I also tried passing Nimbus L&F via CI script for JCK/jtreg tests and those are also same before and after fix.

In the linke above the 
nimbusBlueGrey 	#a9b0be (169,176,190)
While the "EditorPane.background and TextPane.background" are:
TextPane.background 	#d6d9df (214,217,223)
EditorPane.background 	#d6d9df (214,217,223)

It is still unclear why setting these values in the XML file prevents the user to change it later, also it will be good to understand the purpose of "shape" since it also sets some coordinates values.

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

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

From psadhukhan at openjdk.java.net  Tue Aug  3 06:28:35 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 3 Aug 2021 06:28:35 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v2]
In-Reply-To: <7KKvg035KagQnRnnJoKuSiQKw_w_Cmi1DaRvTON_iBA=.6a2b67c6-e14c-40a7-a956-68486aa9e77a@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <e75oGeybsRKX17FZaNihsb_ZLHogIQhT5WER0pkMy-M=.b437f763-29ca-4312-bbcd-6043da0b47da@github.com>
 <jgqxu9J5b9YaCl1Bskr7pPtEq4qpW0aoZKtn7s9-CRQ=.813bd0fb-0cf8-4b51-8b86-0f82b6bd0eda@github.com>
 <8zdodK_7aqrcZDCNTVCnNp9PSm3VMGamkLBrrt4QNDI=.06d2f6fb-1f9b-4f34-a8c6-ea546d6297a1@github.com>
 <7KKvg035KagQnRnnJoKuSiQKw_w_Cmi1DaRvTON_iBA=.6a2b67c6-e14c-40a7-a956-68486aa9e77a@github.com>
Message-ID: <0agJRxvFFG07422R6hyUGtN9xLr6KMwAOMBbZ8qk-wc=.0497684f-d01d-41ba-9abd-7f63703b9cf8@github.com>

On Tue, 3 Aug 2021 06:03:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I have looked at https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/_nimbusDefaults.html where default color for 
>> EditorPane.background and TextPane.background is NimbusBlueGrey and not White what we have now, so I think we are having what is being specified in nimbus-default.
>> SwingSet2 background color for the demos are same before and after the fix.
>> I am not sure about the difference between background and shape but I have ran full JCK/JTREG tests and all are fine. I also tried passing Nimbus L&F via CI script for JCK/jtreg tests and those are also same before and after fix.
>
> In the linke above the 
> nimbusBlueGrey 	#a9b0be (169,176,190)
> While the "EditorPane.background and TextPane.background" are:
> TextPane.background 	#d6d9df (214,217,223)
> EditorPane.background 	#d6d9df (214,217,223)
> 
> It is still unclear why setting these values in the XML file prevents the user to change it later, also it will be good to understand the purpose of "shape" since it also sets some coordinates values.

Yes, I meant the grey background what is being described in EditorPane.background and TextPane.background is what is being shown now, not literally NimbusBlueGrey. Till now we were showing white which is in contrary to this default.

I could not find any purpose of shape by looking at skin.laf as it is not being used in Synth source code, so that is why I ran all JCK/jtreg testsuite and found no regression.  It is also there from initial days.
I leave it for user of Synth/Nimbus L&F  or anyone from open community to highlight the need of "shape"

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

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

From serb at openjdk.java.net  Tue Aug  3 06:31:32 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 3 Aug 2021 06:31:32 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v2]
In-Reply-To: <0agJRxvFFG07422R6hyUGtN9xLr6KMwAOMBbZ8qk-wc=.0497684f-d01d-41ba-9abd-7f63703b9cf8@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <e75oGeybsRKX17FZaNihsb_ZLHogIQhT5WER0pkMy-M=.b437f763-29ca-4312-bbcd-6043da0b47da@github.com>
 <jgqxu9J5b9YaCl1Bskr7pPtEq4qpW0aoZKtn7s9-CRQ=.813bd0fb-0cf8-4b51-8b86-0f82b6bd0eda@github.com>
 <8zdodK_7aqrcZDCNTVCnNp9PSm3VMGamkLBrrt4QNDI=.06d2f6fb-1f9b-4f34-a8c6-ea546d6297a1@github.com>
 <7KKvg035KagQnRnnJoKuSiQKw_w_Cmi1DaRvTON_iBA=.6a2b67c6-e14c-40a7-a956-68486aa9e77a@github.com>
 <0agJRxvFFG07422R6hyUGtN9xLr6KMwAOMBbZ8qk-wc=.0497684f-d01d-41ba-9abd-7f63703b9cf8@github.com>
Message-ID: <-hTd-xSgW1pVbPD09s3_-sYk67LyfDYrQkZrJyhNcic=.b5d9702e-10b9-48ca-981a-fcc190482abd@github.com>

On Tue, 3 Aug 2021 06:25:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In the linke above the 
>> nimbusBlueGrey 	#a9b0be (169,176,190)
>> While the "EditorPane.background and TextPane.background" are:
>> TextPane.background 	#d6d9df (214,217,223)
>> EditorPane.background 	#d6d9df (214,217,223)
>> 
>> It is still unclear why setting these values in the XML file prevents the user to change it later, also it will be good to understand the purpose of "shape" since it also sets some coordinates values.
>
> Yes, I meant the grey background what is being described in EditorPane.background and TextPane.background is what is being shown now, not literally NimbusBlueGrey. Till now we were showing white which is in contrary to this default.
> 
> I could not find any purpose of shape by looking at skin.laf as it is not being used in Synth source code, so that is why I ran all JCK/jtreg testsuite and found no regression.  It is also there from initial days.
> I leave it for user of Synth/Nimbus L&F  or anyone from open community to highlight the need of "shape"

Does it mean that "shapes" tag is not used and we can remove all its usage in the file?

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

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

From psadhukhan at openjdk.java.net  Tue Aug  3 06:37:31 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 3 Aug 2021 06:37:31 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v2]
In-Reply-To: <-hTd-xSgW1pVbPD09s3_-sYk67LyfDYrQkZrJyhNcic=.b5d9702e-10b9-48ca-981a-fcc190482abd@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <e75oGeybsRKX17FZaNihsb_ZLHogIQhT5WER0pkMy-M=.b437f763-29ca-4312-bbcd-6043da0b47da@github.com>
 <jgqxu9J5b9YaCl1Bskr7pPtEq4qpW0aoZKtn7s9-CRQ=.813bd0fb-0cf8-4b51-8b86-0f82b6bd0eda@github.com>
 <8zdodK_7aqrcZDCNTVCnNp9PSm3VMGamkLBrrt4QNDI=.06d2f6fb-1f9b-4f34-a8c6-ea546d6297a1@github.com>
 <7KKvg035KagQnRnnJoKuSiQKw_w_Cmi1DaRvTON_iBA=.6a2b67c6-e14c-40a7-a956-68486aa9e77a@github.com>
 <0agJRxvFFG07422R6hyUGtN9xLr6KMwAOMBbZ8qk-wc=.0497684f-d01d-41ba-9abd-7f63703b9cf8@github.com>
 <-hTd-xSgW1pVbPD09s3_-sYk67LyfDYrQkZrJyhNcic=.b5d9702e-10b9-48ca-981a-fcc190482abd@github.com>
Message-ID: <O_K-9S9JjaaSMiIrDAGeCSLfMKnb2RxfjKFPYOcXcdg=.e48f2e4a-6d25-459a-87b1-3f60a864370f@github.com>

On Tue, 3 Aug 2021 06:28:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yes, I meant the grey background what is being described in EditorPane.background and TextPane.background is what is being shown now, not literally NimbusBlueGrey. Till now we were showing white which is in contrary to this default.
>> 
>> I could not find any purpose of shape by looking at skin.laf as it is not being used in Synth source code, so that is why I ran all JCK/jtreg testsuite and found no regression.  It is also there from initial days.
>> I leave it for user of Synth/Nimbus L&F  or anyone from open community to highlight the need of "shape"
>
> Does it mean that "shapes" tag is not used and we can remove all its usage in the file?

I dont know. I am only telling by looking at source code..I dont know what NimbusL&F creator meant it for...

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

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

From psadhukhan at openjdk.java.net  Tue Aug  3 08:31:49 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 3 Aug 2021 08:31:49 GMT
Subject: <Swing Dev> RFR: 4819544: SwingSet2 JTable Demo throws
 NullPointerException
Message-ID: <iIwgnxXhimiHNB5c1aqnlrPnXNC7bzSiSTGuIF3SiB4=.7266c195-3e3b-4849-8f0c-7339a5aa6243@github.com>

In the JTable demo, if we double click on the first cell in the Favorite Number column, delete the value and click on some
other cell, a java.lang.NullPointerException is getting thrown.
The flaw is in the TableDemo's TableModel getColumnClass() method which queries the value of cell 0 in the target column, and returns its Class. This logic seems to be flawed - an NPE will be thrown when the value in cell 0 is null.
Fix by checking for null.

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

Commit messages:
 - 4819544: SwingSet2 JTable Demo throws NullPointerException
 - 4819544: SwingSet2 JTable Demo throws NullPointerException

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

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

From jdv at openjdk.java.net  Tue Aug  3 09:35:30 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 3 Aug 2021 09:35:30 GMT
Subject: <Swing Dev> RFR: 8271456: Avoid looking up standard charsets in
 "java.desktop" module
In-Reply-To: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
References: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
Message-ID: <uO_UCIChothXc5o7ubVgmovdi5FTDFukv9LBlW3Dn7g=.05a0ab71-89bc-4096-8ce3-7cc43142259e@github.com>

On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> Tested by the desktop headless/headful tests on linux/windows.

Marked as reviewed by jdv (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Tue Aug  3 11:23:29 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 3 Aug 2021 11:23:29 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v2]
In-Reply-To: <O_K-9S9JjaaSMiIrDAGeCSLfMKnb2RxfjKFPYOcXcdg=.e48f2e4a-6d25-459a-87b1-3f60a864370f@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <e75oGeybsRKX17FZaNihsb_ZLHogIQhT5WER0pkMy-M=.b437f763-29ca-4312-bbcd-6043da0b47da@github.com>
 <jgqxu9J5b9YaCl1Bskr7pPtEq4qpW0aoZKtn7s9-CRQ=.813bd0fb-0cf8-4b51-8b86-0f82b6bd0eda@github.com>
 <8zdodK_7aqrcZDCNTVCnNp9PSm3VMGamkLBrrt4QNDI=.06d2f6fb-1f9b-4f34-a8c6-ea546d6297a1@github.com>
 <7KKvg035KagQnRnnJoKuSiQKw_w_Cmi1DaRvTON_iBA=.6a2b67c6-e14c-40a7-a956-68486aa9e77a@github.com>
 <0agJRxvFFG07422R6hyUGtN9xLr6KMwAOMBbZ8qk-wc=.0497684f-d01d-41ba-9abd-7f63703b9cf8@github.com>
 <-hTd-xSgW1pVbPD09s3_-sYk67LyfDYrQkZrJyhNcic=.b5d9702e-10b9-48ca-981a-fcc190482abd@github.com>
 <O_K-9S9JjaaSMiIrDAGeCSLfMKnb2RxfjKFPYOcXcdg=.e48f2e4a-6d25-459a-87b1-3f60a864370f@github.com>
Message-ID: <-rE0VwWK2tu1Bhrtq3HkqcJFehHWqaS4e40TaU9x-ZY=.6ba3197e-5319-45af-bc47-9ee9d019b208@github.com>

On Tue, 3 Aug 2021 06:34:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Does it mean that "shapes" tag is not used and we can remove all its usage in the file?
>
> I dont know. I am only telling by looking at source code..I dont know what NimbusL&F creator meant it for...

I think we should give this fix a chance...sInce this is solving 2 long-standing issue where setBackground() contract is not honoured plus causing no regression to existing tests.
If we do find any testcase with "shape" in future from open community or any other related testcase being failed for this fix, we can always work on it (or at the least roll back this)

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

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

From azvegint at openjdk.java.net  Tue Aug  3 13:40:32 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 3 Aug 2021 13:40:32 GMT
Subject: <Swing Dev> RFR: 8271456: Avoid looking up standard charsets in
 "java.desktop" module
In-Reply-To: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
References: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
Message-ID: <foOp61a2SZXqEzDwcZir9xxdnx1XTwn4WiVheu02V_k=.6f583daf-ce75-45a5-8265-34a6e2cfa9c9@github.com>

On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> Tested by the desktop headless/headful tests on linux/windows.

src/java.desktop/share/classes/com/sun/imageio/plugins/wbmp/WBMPMetadata.java line 25:

> 23:  * questions.
> 24:  */
> 25: 

Since you updating a copyright year in all other files, you probably might want to update in this file too.

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

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

From serb at openjdk.java.net  Tue Aug  3 17:05:30 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 3 Aug 2021 17:05:30 GMT
Subject: <Swing Dev> RFR: 8271456: Avoid looking up standard charsets in
 "java.desktop" module
In-Reply-To: <foOp61a2SZXqEzDwcZir9xxdnx1XTwn4WiVheu02V_k=.6f583daf-ce75-45a5-8265-34a6e2cfa9c9@github.com>
References: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
 <foOp61a2SZXqEzDwcZir9xxdnx1XTwn4WiVheu02V_k=.6f583daf-ce75-45a5-8265-34a6e2cfa9c9@github.com>
Message-ID: <44GDUiqRvJh0JOAHeby5i8wQW5YgM5fwRdXS896Pnu8=.b76fd6ac-bb13-46a3-ae22-800dfeea9553@github.com>

On Tue, 3 Aug 2021 13:30:28 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> Tested by the desktop headless/headful tests on linux/windows.
>
> src/java.desktop/share/classes/com/sun/imageio/plugins/wbmp/WBMPMetadata.java line 25:
> 
>> 23:  * questions.
>> 24:  */
>> 25: 
> 
> Since you updating a copyright year in all other files, you probably might want to update in this file too.

I did not update it since this is the only file where the imports are updated only(the UnsupportedEncodingException is removed).

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

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

From azvegint at openjdk.java.net  Tue Aug  3 18:05:32 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 3 Aug 2021 18:05:32 GMT
Subject: <Swing Dev> RFR: 8271456: Avoid looking up standard charsets in
 "java.desktop" module
In-Reply-To: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
References: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
Message-ID: <ss1cD2dnWzuO_aOIDU4gvOFGhfqGdldjBatJGGazJTM=.e41516e1-f4d9-4af7-92ec-9c7f703227ec@github.com>

On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> Tested by the desktop headless/headful tests on linux/windows.

Marked as reviewed by azvegint (Reviewer).

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

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

From serb at openjdk.java.net  Tue Aug  3 19:37:04 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 3 Aug 2021 19:37:04 GMT
Subject: <Swing Dev> RFR: 8271456: Avoid looking up standard charsets in
 "java.desktop" module [v2]
In-Reply-To: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
References: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
Message-ID: <_b2JI_4pIcqDyEX0gBXAkD4DzzL3V2IOinLOq2dGksU=.3a99501e-1444-4298-b695-1519a8a2e227@github.com>

> This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> Tested by the desktop headless/headful tests on linux/windows.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into JDK-8271456
 - Initial fix for JDK-8271456

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4951/files
  - new: https://git.openjdk.java.net/jdk/pull/4951/files/430c9b3a..886264aa

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

  Stats: 1774 lines in 83 files changed: 1230 ins; 337 del; 207 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4951.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4951/head:pull/4951

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

From aivanov at openjdk.java.net  Tue Aug  3 21:22:36 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 3 Aug 2021 21:22:36 GMT
Subject: <Swing Dev> RFR: 8271456: Avoid looking up standard charsets in
 "java.desktop" module [v2]
In-Reply-To: <_b2JI_4pIcqDyEX0gBXAkD4DzzL3V2IOinLOq2dGksU=.3a99501e-1444-4298-b695-1519a8a2e227@github.com>
References: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
 <_b2JI_4pIcqDyEX0gBXAkD4DzzL3V2IOinLOq2dGksU=.3a99501e-1444-4298-b695-1519a8a2e227@github.com>
Message-ID: <DcO0PN9RB4gp2-iUdIymjUsaSEu_xBeJPvknfnnu6tc=.bbcde860-bde0-495e-9ba0-cf4c2d59a3ab@github.com>

On Tue, 3 Aug 2021 19:37:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> Tested by the desktop headless/headful tests on linux/windows.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8271456
>  - Initial fix for JDK-8271456

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/windows/classes/sun/awt/windows/WDataTransferer.java line 270:

> 268:                     charset = new String((byte[])localeTransferable.
> 269:                         getTransferData(javaTextEncodingFlavor),
> 270:                                          StandardCharsets.UTF_8);

Suggestion:

                        getTransferData(javaTextEncodingFlavor),
                                        StandardCharsets.UTF_8);

The parameter on the second line should probably be aligned with the first parameter as it's done in the snippet above.

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

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

From serb at openjdk.java.net  Tue Aug  3 21:42:33 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 3 Aug 2021 21:42:33 GMT
Subject: <Swing Dev> RFR: 8271456: Avoid looking up standard charsets in
 "java.desktop" module [v2]
In-Reply-To: <DcO0PN9RB4gp2-iUdIymjUsaSEu_xBeJPvknfnnu6tc=.bbcde860-bde0-495e-9ba0-cf4c2d59a3ab@github.com>
References: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
 <_b2JI_4pIcqDyEX0gBXAkD4DzzL3V2IOinLOq2dGksU=.3a99501e-1444-4298-b695-1519a8a2e227@github.com>
 <DcO0PN9RB4gp2-iUdIymjUsaSEu_xBeJPvknfnnu6tc=.bbcde860-bde0-495e-9ba0-cf4c2d59a3ab@github.com>
Message-ID: <H6lNHwtJ3g7Kt7nq5-aSoPyvSwwSQMJWoqNoa0toNcY=.9ee3a3f2-24f6-483f-aac4-e5c7e9cde7d9@github.com>

On Tue, 3 Aug 2021 21:18:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8271456
>>  - Initial fix for JDK-8271456
>
> src/java.desktop/windows/classes/sun/awt/windows/WDataTransferer.java line 270:
> 
>> 268:                     charset = new String((byte[])localeTransferable.
>> 269:                         getTransferData(javaTextEncodingFlavor),
>> 270:                                          StandardCharsets.UTF_8);
> 
> Suggestion:
> 
>                         getTransferData(javaTextEncodingFlavor),
>                                         StandardCharsets.UTF_8);
> 
> The parameter on the second line should probably be aligned with the first parameter as it's done in the snippet above.

it is aligned already, the StandardCharsets.UTF_8 is parameter of "new String()", not the getTransferData.

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

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

From aivanov at openjdk.java.net  Tue Aug  3 21:57:31 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 3 Aug 2021 21:57:31 GMT
Subject: <Swing Dev> RFR: 8271456: Avoid looking up standard charsets in
 "java.desktop" module [v2]
In-Reply-To: <H6lNHwtJ3g7Kt7nq5-aSoPyvSwwSQMJWoqNoa0toNcY=.9ee3a3f2-24f6-483f-aac4-e5c7e9cde7d9@github.com>
References: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
 <_b2JI_4pIcqDyEX0gBXAkD4DzzL3V2IOinLOq2dGksU=.3a99501e-1444-4298-b695-1519a8a2e227@github.com>
 <DcO0PN9RB4gp2-iUdIymjUsaSEu_xBeJPvknfnnu6tc=.bbcde860-bde0-495e-9ba0-cf4c2d59a3ab@github.com>
 <H6lNHwtJ3g7Kt7nq5-aSoPyvSwwSQMJWoqNoa0toNcY=.9ee3a3f2-24f6-483f-aac4-e5c7e9cde7d9@github.com>
Message-ID: <4RktX4CxkaDcFgd7NqmaEM5BbHnKYkpeE2EnYiOoux0=.2b753022-90b6-48fc-9c17-3a87eda87606@github.com>

On Tue, 3 Aug 2021 21:39:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/windows/classes/sun/awt/windows/WDataTransferer.java line 270:
>> 
>>> 268:                     charset = new String((byte[])localeTransferable.
>>> 269:                         getTransferData(javaTextEncodingFlavor),
>>> 270:                                          StandardCharsets.UTF_8);
>> 
>> Suggestion:
>> 
>>                         getTransferData(javaTextEncodingFlavor),
>>                                         StandardCharsets.UTF_8);
>> 
>> The parameter on the second line should probably be aligned with the first parameter as it's done in the snippet above.
>
> it is aligned already, the StandardCharsets.UTF_8 is parameter of "new String()", not the getTransferData.

Ah, right!
But it's confusing: it looks as if `StandardCharsets.UTF_8` is a parameter to `getTransferData`. Maybe avoid breaking the line and leave `UTF_8`  on the same line? If you import `UTF_8` and `UTF_16LE` statically, line break is unnecessary.

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

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

From serb at openjdk.java.net  Tue Aug  3 22:06:29 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 3 Aug 2021 22:06:29 GMT
Subject: <Swing Dev> RFR: 8271456: Avoid looking up standard charsets in
 "java.desktop" module [v2]
In-Reply-To: <4RktX4CxkaDcFgd7NqmaEM5BbHnKYkpeE2EnYiOoux0=.2b753022-90b6-48fc-9c17-3a87eda87606@github.com>
References: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
 <_b2JI_4pIcqDyEX0gBXAkD4DzzL3V2IOinLOq2dGksU=.3a99501e-1444-4298-b695-1519a8a2e227@github.com>
 <DcO0PN9RB4gp2-iUdIymjUsaSEu_xBeJPvknfnnu6tc=.bbcde860-bde0-495e-9ba0-cf4c2d59a3ab@github.com>
 <H6lNHwtJ3g7Kt7nq5-aSoPyvSwwSQMJWoqNoa0toNcY=.9ee3a3f2-24f6-483f-aac4-e5c7e9cde7d9@github.com>
 <4RktX4CxkaDcFgd7NqmaEM5BbHnKYkpeE2EnYiOoux0=.2b753022-90b6-48fc-9c17-3a87eda87606@github.com>
Message-ID: <gHQ7k1z1Uagj9koCC_oSTAraOqh0rgfToJlXqVZAPno=.e6580c78-312f-4466-b4fe-47521a1f849a@github.com>

On Tue, 3 Aug 2021 21:54:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> it is aligned already, the StandardCharsets.UTF_8 is parameter of "new String()", not the getTransferData.
>
> Ah, right!
> But it's confusing: it looks as if `StandardCharsets.UTF_8` is a parameter to `getTransferData`. Maybe avoid breaking the line and leave `UTF_8`  on the same line? If you import `UTF_8` and `UTF_16LE` statically, line break is unnecessary.

I am fine to do that, if there are no objections I can change the whole fix.

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

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

From aivanov at openjdk.java.net  Tue Aug  3 22:45:27 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 3 Aug 2021 22:45:27 GMT
Subject: <Swing Dev> RFR: 8271456: Avoid looking up standard charsets in
 "java.desktop" module [v2]
In-Reply-To: <gHQ7k1z1Uagj9koCC_oSTAraOqh0rgfToJlXqVZAPno=.e6580c78-312f-4466-b4fe-47521a1f849a@github.com>
References: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
 <_b2JI_4pIcqDyEX0gBXAkD4DzzL3V2IOinLOq2dGksU=.3a99501e-1444-4298-b695-1519a8a2e227@github.com>
 <DcO0PN9RB4gp2-iUdIymjUsaSEu_xBeJPvknfnnu6tc=.bbcde860-bde0-495e-9ba0-cf4c2d59a3ab@github.com>
 <H6lNHwtJ3g7Kt7nq5-aSoPyvSwwSQMJWoqNoa0toNcY=.9ee3a3f2-24f6-483f-aac4-e5c7e9cde7d9@github.com>
 <4RktX4CxkaDcFgd7NqmaEM5BbHnKYkpeE2EnYiOoux0=.2b753022-90b6-48fc-9c17-3a87eda87606@github.com>
 <gHQ7k1z1Uagj9koCC_oSTAraOqh0rgfToJlXqVZAPno=.e6580c78-312f-4466-b4fe-47521a1f849a@github.com>
Message-ID: <p7qgsU5qLR21iYj7vW2tFCaA_j_3BxbIZ_vjHSMb4j8=.9dfe5b99-fb23-4e00-acb1-20d9d3701c37@github.com>

On Tue, 3 Aug 2021 22:03:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> 
> I am fine to do that, if there are no objections I can change the whole fix.

Modifying the entire changeset seems like an overkill.
Using static imports in only one file is _inconsistent_, yet it makes the places where the encodings are used clearer.

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

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

From serb at openjdk.java.net  Tue Aug  3 23:35:55 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 3 Aug 2021 23:35:55 GMT
Subject: <Swing Dev> RFR: 8271456: Avoid looking up standard charsets in
 "java.desktop" module [v3]
In-Reply-To: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
References: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
Message-ID: <uY-hBeZAMt9D0ZnWNC2SnRaTji8iJ0Bpdw1GgiCrv44=.bc003d63-e653-4f49-ad40-8e2a41e3f3fe@github.com>

> This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> Tested by the desktop headless/headful tests on linux/windows.

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  static import StandardCharsets

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4951/files
  - new: https://git.openjdk.java.net/jdk/pull/4951/files/886264aa..e4e82c83

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

  Stats: 245 lines in 31 files changed: 93 ins; 63 del; 89 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4951.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4951/head:pull/4951

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

From serb at openjdk.java.net  Tue Aug  3 23:42:55 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 3 Aug 2021 23:42:55 GMT
Subject: <Swing Dev> RFR: 8271456: Avoid looking up standard charsets in
 "java.desktop" module [v2]
In-Reply-To: <p7qgsU5qLR21iYj7vW2tFCaA_j_3BxbIZ_vjHSMb4j8=.9dfe5b99-fb23-4e00-acb1-20d9d3701c37@github.com>
References: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
 <_b2JI_4pIcqDyEX0gBXAkD4DzzL3V2IOinLOq2dGksU=.3a99501e-1444-4298-b695-1519a8a2e227@github.com>
 <DcO0PN9RB4gp2-iUdIymjUsaSEu_xBeJPvknfnnu6tc=.bbcde860-bde0-495e-9ba0-cf4c2d59a3ab@github.com>
 <H6lNHwtJ3g7Kt7nq5-aSoPyvSwwSQMJWoqNoa0toNcY=.9ee3a3f2-24f6-483f-aac4-e5c7e9cde7d9@github.com>
 <4RktX4CxkaDcFgd7NqmaEM5BbHnKYkpeE2EnYiOoux0=.2b753022-90b6-48fc-9c17-3a87eda87606@github.com>
 <gHQ7k1z1Uagj9koCC_oSTAraOqh0rgfToJlXqVZAPno=.e6580c78-312f-4466-b4fe-47521a1f849a@github.com>
 <p7qgsU5qLR21iYj7vW2tFCaA_j_3BxbIZ_vjHSMb4j8=.9dfe5b99-fb23-4e00-acb1-20d9d3701c37@github.com>
Message-ID: <MyoneDZurOmQtF8lrOAea94dj7Aykk7nTWhcPOM9yUU=.562f7b07-a33a-413b-8db0-ed646903381a@github.com>

On Tue, 3 Aug 2021 22:42:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I am fine to do that, if there are no objections I can change the whole fix.
>
>> 
>> I am fine to do that, if there are no objections I can change the whole fix.
> 
> Modifying the entire changeset seems like an overkill.
> Using static imports in only one file is _inconsistent_, yet it makes the places where the encodings are used clearer.

Updated

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

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

From serb at openjdk.java.net  Tue Aug  3 23:42:55 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 3 Aug 2021 23:42:55 GMT
Subject: <Swing Dev> RFR: 8271456: Avoid looking up standard charsets in
 "java.desktop" module [v4]
In-Reply-To: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
References: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
Message-ID: <e4xvAoV6WmG_pomJznx7SuSJtQSEfYriTuZyf6uApcE=.2c881142-bf2d-45aa-be60-a878a79666da@github.com>

> This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> Tested by the desktop headless/headful tests on linux/windows.

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  Update IPPPrintService.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4951/files
  - new: https://git.openjdk.java.net/jdk/pull/4951/files/e4e82c83..47ed1e81

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

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

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

From psadhukhan at openjdk.java.net  Wed Aug  4 09:08:47 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 4 Aug 2021 09:08:47 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE
Message-ID: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>

JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
Added null check for those cases.

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

Commit messages:
 - 5015261: JInternalFrame causes NPE

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

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

From jdv at openjdk.java.net  Wed Aug  4 09:18:32 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 4 Aug 2021 09:18:32 GMT
Subject: <Swing Dev> RFR: 6350025: API documentation for JOptionPane
 using deprecated methods.
In-Reply-To: <lmHrWkmTi6rnXc7lZ8XO8PisKx648hjTesINC3C0RDU=.21f4448f-144e-4f5b-8e38-d48a36446860@github.com>
References: <lmHrWkmTi6rnXc7lZ8XO8PisKx648hjTesINC3C0RDU=.21f4448f-144e-4f5b-8e38-d48a36446860@github.com>
Message-ID: <tXB1W7ZLes4KcqRez9Gekt_UlpCjcz66IWP68jo7ioU=.3cdb76a4-65e0-4406-9924-381613bef308@github.com>

On Mon, 2 Aug 2021 09:17:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The method show() in the JOptionPane javadoc example is deprecated. The recommended method to call would be setVisible(true).

Marked as reviewed by jdv (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Wed Aug  4 11:41:33 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 4 Aug 2021 11:41:33 GMT
Subject: <Swing Dev> Integrated: 6350025: API documentation for JOptionPane
 using deprecated methods.
In-Reply-To: <lmHrWkmTi6rnXc7lZ8XO8PisKx648hjTesINC3C0RDU=.21f4448f-144e-4f5b-8e38-d48a36446860@github.com>
References: <lmHrWkmTi6rnXc7lZ8XO8PisKx648hjTesINC3C0RDU=.21f4448f-144e-4f5b-8e38-d48a36446860@github.com>
Message-ID: <G1C_4UhNLNORiRE0_k857fqJ1zmUHczyyG8RnIcKxfM=.f31c974f-0453-4e94-a710-663ac1c35b2f@github.com>

On Mon, 2 Aug 2021 09:17:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The method show() in the JOptionPane javadoc example is deprecated. The recommended method to call would be setVisible(true).

This pull request has now been integrated.

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

6350025: API documentation for JOptionPane using deprecated methods.

Reviewed-by: jdv

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

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

From pbansal at openjdk.java.net  Wed Aug  4 13:51:28 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 4 Aug 2021 13:51:28 GMT
Subject: <Swing Dev> RFR: 4819544: SwingSet2 JTable Demo throws
 NullPointerException
In-Reply-To: <iIwgnxXhimiHNB5c1aqnlrPnXNC7bzSiSTGuIF3SiB4=.7266c195-3e3b-4849-8f0c-7339a5aa6243@github.com>
References: <iIwgnxXhimiHNB5c1aqnlrPnXNC7bzSiSTGuIF3SiB4=.7266c195-3e3b-4849-8f0c-7339a5aa6243@github.com>
Message-ID: <MYXQ3hnAwzHLVCzd0L68ylO7nTolvq6b06cZw4YPbEg=.3fdbecce-b462-4073-b0d4-b2e25e2a29c6@github.com>

On Tue, 3 Aug 2021 08:23:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In the JTable demo, if we double click on the first cell in the Favorite Number column, delete the value and click on some
> other cell, a java.lang.NullPointerException is getting thrown.
> The flaw is in the TableDemo's TableModel getColumnClass() method which queries the value of cell 0 in the target column, and returns its Class. This logic seems to be flawed - an NPE will be thrown when the value in cell 0 is null.
> Fix by checking for null.

Verified that the NPE is not happening after the fix.

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

Marked as reviewed by pbansal (Reviewer).

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

From aivanov at openjdk.java.net  Wed Aug  4 14:25:35 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 4 Aug 2021 14:25:35 GMT
Subject: <Swing Dev> RFR: 8271456: Avoid looking up standard charsets in
 "java.desktop" module [v4]
In-Reply-To: <e4xvAoV6WmG_pomJznx7SuSJtQSEfYriTuZyf6uApcE=.2c881142-bf2d-45aa-be60-a878a79666da@github.com>
References: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
 <e4xvAoV6WmG_pomJznx7SuSJtQSEfYriTuZyf6uApcE=.2c881142-bf2d-45aa-be60-a878a79666da@github.com>
Message-ID: <Mn1TV8qnberxLmW3YuBfcg6wh-HqJrqsBE_rm45D9MA=.54d7575d-6eea-46f8-8d32-85d2901cdc2a@github.com>

On Tue, 3 Aug 2021 23:42:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> Tested by the desktop headless/headful tests on linux/windows.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update IPPPrintService.java

I admit I prefer static imports in this case: the code is shorter and is as clear. It's pretty obvious where the encoding comes from.

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

Marked as reviewed by aivanov (Reviewer).

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

From serb at openjdk.java.net  Wed Aug  4 18:48:32 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 4 Aug 2021 18:48:32 GMT
Subject: <Swing Dev> Integrated: 8271456: Avoid looking up standard charsets
 in "java.desktop" module
In-Reply-To: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
References: <SQcVYp212-XHRzpNuBtCYpYtli3OdAEFCqNC7Mo6Kbw=.9dfedadd-3015-4d05-81e4-7bbfcb8db4fe@github.com>
Message-ID: <dMWtL6VVfxiFrtlh6TubyDZPGbKrBgh51vOFq8rK5ek=.a274c614-067c-4e57-b8f5-7fdcec031013@github.com>

On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> Tested by the desktop headless/headful tests on linux/windows.

This pull request has now been integrated.

Changeset: 6b55ef3b
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6b55ef3b58ae405c46f440e06b5adb03cec3a500
Stats:     761 lines in 33 files changed: 337 ins; 269 del; 155 mod

8271456: Avoid looking up standard charsets in "java.desktop" module

Reviewed-by: jdv, azvegint, aivanov

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

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

From serb at openjdk.java.net  Wed Aug  4 19:05:29 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 4 Aug 2021 19:05:29 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE
In-Reply-To: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
Message-ID: <tgnX5u_E6Kq1LPFSy_QT7hgp756Dr6hKkLivxKEeBYE=.8b284ae4-a422-44c6-b895-06f1d5475550@github.com>

On Wed, 4 Aug 2021 09:02:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
> Added null check for those cases.

Does the null desktop icon is actually supported? I have set it to null in the constructor of JInternalFrame, and check how the SwingSet2 work when jdesktop frame is minimized, under all L&F I got NPE.  But even if we fix that npe how the user will be able to "unmimimize" the window? Probably we should state that the null icon is unsupported?

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

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

From serb at openjdk.java.net  Wed Aug  4 19:14:32 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 4 Aug 2021 19:14:32 GMT
Subject: <Swing Dev> RFR: 8269269: [macos11] SystemIconTest fails with
 ClassCastException
In-Reply-To: <ZPN7_piNo8BCdPJCRlLi_Gcm_bMBnl3uzWy1dUaoucM=.4acc81be-f9fc-4979-a702-712d7eb103c0@github.com>
References: <ZPN7_piNo8BCdPJCRlLi_Gcm_bMBnl3uzWy1dUaoucM=.4acc81be-f9fc-4979-a702-712d7eb103c0@github.com>
Message-ID: <2xcZPz6xyZplHStbpUDSau-ide4CmpiisPQVInQy3AY=.859516df-abf9-4d31-8746-b7b9a244cce7@github.com>

On Wed, 14 Jul 2021 11:13:31 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Do not test situation where UIResource icon is returned
> Added a whole bunch of debug information to see what file test is filed
> upon.

Thank you!

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

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

From dcubed at openjdk.java.net  Wed Aug  4 19:26:38 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 4 Aug 2021 19:26:38 GMT
Subject: <Swing Dev> [jdk17] Integrated: 8271894: ProblemList
 javax/swing/JComponent/7154030/bug7154030.java in JDK17
Message-ID: <pdXTVfpanVX87ZBVSkwDa-RTSeX0P4E9CWEJvHBUq28=.16f1e0b5-8e07-4cce-8ca0-3318ae8546e9@github.com>

A trivial fix to ProblemList javax/swing/JComponent/7154030/bug7154030.java in JDK17
on macOS-X64.

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

Commit messages:
 - 8271894: ProblemList javax/swing/JComponent/7154030/bug7154030.java in JDK17

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

PR: https://git.openjdk.java.net/jdk17/pull/300

From darcy at openjdk.java.net  Wed Aug  4 19:26:38 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 4 Aug 2021 19:26:38 GMT
Subject: <Swing Dev> [jdk17] Integrated: 8271894: ProblemList
 javax/swing/JComponent/7154030/bug7154030.java in JDK17
In-Reply-To: <pdXTVfpanVX87ZBVSkwDa-RTSeX0P4E9CWEJvHBUq28=.16f1e0b5-8e07-4cce-8ca0-3318ae8546e9@github.com>
References: <pdXTVfpanVX87ZBVSkwDa-RTSeX0P4E9CWEJvHBUq28=.16f1e0b5-8e07-4cce-8ca0-3318ae8546e9@github.com>
Message-ID: <gTpHEW78-11Z0-6SWgeylEOtK3aZkWXYhn3mV7ox0tI=.273c6b73-abd7-408d-b4fe-a189a99c3aea@github.com>

On Wed, 4 Aug 2021 19:14:27 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JComponent/7154030/bug7154030.java in JDK17
> on macOS-X64.

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/300

From dcubed at openjdk.java.net  Wed Aug  4 19:26:38 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 4 Aug 2021 19:26:38 GMT
Subject: <Swing Dev> [jdk17] Integrated: 8271894: ProblemList
 javax/swing/JComponent/7154030/bug7154030.java in JDK17
In-Reply-To: <gTpHEW78-11Z0-6SWgeylEOtK3aZkWXYhn3mV7ox0tI=.273c6b73-abd7-408d-b4fe-a189a99c3aea@github.com>
References: <pdXTVfpanVX87ZBVSkwDa-RTSeX0P4E9CWEJvHBUq28=.16f1e0b5-8e07-4cce-8ca0-3318ae8546e9@github.com>
 <gTpHEW78-11Z0-6SWgeylEOtK3aZkWXYhn3mV7ox0tI=.273c6b73-abd7-408d-b4fe-a189a99c3aea@github.com>
Message-ID: <qUpUHk9H4Pmj9YFOcl6D0bz3K0gSpvQCE0XuqyrYXK0=.b4a944e7-eead-43a2-9c46-f277b19c1d0a@github.com>

On Wed, 4 Aug 2021 19:21:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A trivial fix to ProblemList javax/swing/JComponent/7154030/bug7154030.java in JDK17
>> on macOS-X64.
>
> Marked as reviewed by darcy (Reviewer).

@jddarcy - Thanks for the fast review!

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

PR: https://git.openjdk.java.net/jdk17/pull/300

From dcubed at openjdk.java.net  Wed Aug  4 19:26:39 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 4 Aug 2021 19:26:39 GMT
Subject: <Swing Dev> [jdk17] Integrated: 8271894: ProblemList
 javax/swing/JComponent/7154030/bug7154030.java in JDK17
In-Reply-To: <pdXTVfpanVX87ZBVSkwDa-RTSeX0P4E9CWEJvHBUq28=.16f1e0b5-8e07-4cce-8ca0-3318ae8546e9@github.com>
References: <pdXTVfpanVX87ZBVSkwDa-RTSeX0P4E9CWEJvHBUq28=.16f1e0b5-8e07-4cce-8ca0-3318ae8546e9@github.com>
Message-ID: <z6v-lin3t4YjmhWU8ExUcBQbHZIKsIl3eOrG_4UQ7Jg=.10e96b34-7751-42d5-81d3-061ad411cfef@github.com>

On Wed, 4 Aug 2021 19:14:27 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JComponent/7154030/bug7154030.java in JDK17
> on macOS-X64.

This pull request has now been integrated.

Changeset: cebcc07b
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/cebcc07b1b0572e63b420ff86eef78c6aee36393
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8271894: ProblemList javax/swing/JComponent/7154030/bug7154030.java in JDK17

Reviewed-by: darcy

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

PR: https://git.openjdk.java.net/jdk17/pull/300

From prr at openjdk.java.net  Wed Aug  4 20:10:50 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 4 Aug 2021 20:10:50 GMT
Subject: <Swing Dev> RFR: 8268824: Remove unused jdk.accessibility APIs
 deprecated for removal in JDK 9 [v2]
In-Reply-To: <TAjMVj453jPFSRgK0i5WE5XDlgIKc7z6uOr9Mcp80B8=.a3f45901-60cf-4b88-aed6-767e581e34a3@github.com>
References: <TAjMVj453jPFSRgK0i5WE5XDlgIKc7z6uOr9Mcp80B8=.a3f45901-60cf-4b88-aed6-767e581e34a3@github.com>
Message-ID: <8s65wwjUmv_ScFNISHRBT18K23VVCFxxq9e06maXvKQ=.aa16fa79-f8a0-4d1e-ba60-4954923f86c6@github.com>

> These fields
> -  have not been used by the implementation since JDK8,
> - are not supposed to be used by applications,
> - have been deprecated for removal since JDK 9
> - are non-standard, JDK not Java, classes
> - very few clients are expected to be using these classes : just those implementing ATs
> 
> 
> The CSR for this is https://bugs.openjdk.java.net/browse/JDK-8270918

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

  8268824: Remove unused jdk.accessibility APIs deprecated for removal in JDK 9

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4845/files
  - new: https://git.openjdk.java.net/jdk/pull/4845/files/ba3932f3..c376e501

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

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

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

From prr at openjdk.java.net  Wed Aug  4 20:10:52 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 4 Aug 2021 20:10:52 GMT
Subject: <Swing Dev> RFR: 8268824: Remove unused jdk.accessibility APIs
 deprecated for removal in JDK 9 [v2]
In-Reply-To: <bN3XnOaVLylb2PpYoNzXrWfAqCcbwCLi8L61jMBm-ws=.d4c57f4f-0da2-48a4-865b-0192b45b234e@github.com>
References: <TAjMVj453jPFSRgK0i5WE5XDlgIKc7z6uOr9Mcp80B8=.a3f45901-60cf-4b88-aed6-767e581e34a3@github.com>
 <bN3XnOaVLylb2PpYoNzXrWfAqCcbwCLi8L61jMBm-ws=.d4c57f4f-0da2-48a4-865b-0192b45b234e@github.com>
Message-ID: <xmdCFpKJZPW0LmOYvhlKYtEYYeXyaSd1N6-CAepOTJU=.636254e5-887a-430b-888b-453549916e09@github.com>

On Wed, 21 Jul 2021 07:19:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8268824: Remove unused jdk.accessibility APIs deprecated for removal in JDK 9
>
> src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AWTEventMonitor.java line 53:
> 
>> 51:     public AWTEventMonitor() {}
>> 52: 
>> 53:     static private Component componentWithFocus_private = null;
> 
> Can we rename the "new" "xx_private" fields to the shorter version? The javadoc for the protected fields can be applied to the "private version"(but w/o @Deprecated tag).
> 
> So in fact we can change "protected" to the "private", drop the "@Deprecated" tags, and delete the "xx_private" versions of the fields.

I don't think the javadoc is needed since these are now private fields.
I can however rename them to remove _private.

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

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

From aivanov at openjdk.java.net  Wed Aug  4 20:25:35 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 4 Aug 2021 20:25:35 GMT
Subject: <Swing Dev> RFR: 4819544: SwingSet2 JTable Demo throws
 NullPointerException
In-Reply-To: <iIwgnxXhimiHNB5c1aqnlrPnXNC7bzSiSTGuIF3SiB4=.7266c195-3e3b-4849-8f0c-7339a5aa6243@github.com>
References: <iIwgnxXhimiHNB5c1aqnlrPnXNC7bzSiSTGuIF3SiB4=.7266c195-3e3b-4849-8f0c-7339a5aa6243@github.com>
Message-ID: <7aqSOR1bscBSCHacN4juBZNJc-TcSHKb8CDkYrRu2Ho=.0218d113-dc8a-41ab-902d-365e20235411@github.com>

On Tue, 3 Aug 2021 08:23:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In the JTable demo, if we double click on the first cell in the Favorite Number column, delete the value and click on some
> other cell, a java.lang.NullPointerException is getting thrown.
> The flaw is in the TableDemo's TableModel getColumnClass() method which queries the value of cell 0 in the target column, and returns its Class. This logic seems to be flawed - an NPE will be thrown when the value in cell 0 is null.
> Fix by checking for null.

Marked as reviewed by aivanov (Reviewer).

src/demo/share/jfc/SwingSet2/TableDemo.java line 557:

> 555:                     return obj.getClass();
> 556:                 }
> 557:                 return Object.class;

Shall the ternary conditional operator be used here?
Suggestion:

                return obj != null ? obj.getClass() : Object.class;

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

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

From aivanov at openjdk.java.net  Wed Aug  4 21:11:29 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 4 Aug 2021 21:11:29 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color
In-Reply-To: <GF55sFnG_2xjInl9w01VaRh2VmVbnR-mbT8Ft7C1Tfc=.19a9c539-9f66-4c37-8cb0-5e2368a852b5@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <sR3lN4mGxWnCiVnobjL1mZWyiKcem5Tlo0hapyyUXWk=.9cea8533-3046-4492-baad-987675bfccfb@github.com>
 <ZOhehnDPS1hDmybZSxVR1ZAohdVVglyjFYrN080JU_8=.4b175970-642f-4b36-8417-f6cc8d1e34ba@github.com>
 <GF55sFnG_2xjInl9w01VaRh2VmVbnR-mbT8Ft7C1Tfc=.19a9c539-9f66-4c37-8cb0-5e2368a852b5@github.com>
Message-ID: <9NyOoUD0AVFquUISdPVMJ7JNs8Gr7F8t6VGO7fvgrJs=.8980e013-e5de-400e-b4df-3e98a818e709@github.com>

On Mon, 2 Aug 2021 04:50:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> 
> 
> > Does the JEditorPane have the same issue?
> > https://bugs.openjdk.java.net/browse/JDK-6789980
> 
> Yes, fixed

You should add JDK-6789980 as an additional issue resolved:

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

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

From aivanov at openjdk.java.net  Wed Aug  4 21:22:29 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 4 Aug 2021 21:22:29 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v2]
In-Reply-To: <-rE0VwWK2tu1Bhrtq3HkqcJFehHWqaS4e40TaU9x-ZY=.6ba3197e-5319-45af-bc47-9ee9d019b208@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <e75oGeybsRKX17FZaNihsb_ZLHogIQhT5WER0pkMy-M=.b437f763-29ca-4312-bbcd-6043da0b47da@github.com>
 <jgqxu9J5b9YaCl1Bskr7pPtEq4qpW0aoZKtn7s9-CRQ=.813bd0fb-0cf8-4b51-8b86-0f82b6bd0eda@github.com>
 <8zdodK_7aqrcZDCNTVCnNp9PSm3VMGamkLBrrt4QNDI=.06d2f6fb-1f9b-4f34-a8c6-ea546d6297a1@github.com>
 <7KKvg035KagQnRnnJoKuSiQKw_w_Cmi1DaRvTON_iBA=.6a2b67c6-e14c-40a7-a956-68486aa9e77a@github.com>
 <0agJRxvFFG07422R6hyUGtN9xLr6KMwAOMBbZ8qk-wc=.0497684f-d01d-41ba-9abd-7f63703b9cf8@github.com>
 <-hTd-xSgW1pVbPD09s3_-sYk67LyfDYrQkZrJyhNcic=.b5d9702e-10b9-48ca-981a-fcc190482abd@github.com>
 <O_K-9S9JjaaSMiIrDAGeCSLfMKnb2RxfjKFPYOcXcdg=.e48f2e4a-6d25-459a-87b1-3f60a864370f@github.com>
 <-rE0VwWK2tu1Bhrtq3HkqcJFehHWqaS4e40TaU9x-ZY=.6ba3197e-5319-45af-bc47-9ee9d019b208@github.com>
Message-ID: <nOFcTm-9k0C4u3eWJEIAHPSS_uKqFdIH83Vb8QzWcLo=.53eb6bf9-aa6e-4891-bac0-01e65dcc3e9c@github.com>

On Tue, 3 Aug 2021 11:21:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I dont know. I am only telling by looking at source code..I dont know what NimbusL&F creator meant it for...
>
> I think we should give this fix a chance...sInce this is solving 2 long-standing issue where setBackground() contract is not honoured plus causing no regression to existing tests.
> If we do find any testcase with "shape" in future from open community or any other related testcase being failed for this fix, we can always work on it (or at the least roll back this)

It looks the fix doesn't work or alternatively it works in an unexpected way.

Both JEditorPane and JTextPane used to have white background but now, with these changes, their background is the same of the panel below. It's probably know what we want.

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

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

From aivanov at openjdk.java.net  Wed Aug  4 21:26:31 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 4 Aug 2021 21:26:31 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v2]
In-Reply-To: <e75oGeybsRKX17FZaNihsb_ZLHogIQhT5WER0pkMy-M=.b437f763-29ca-4312-bbcd-6043da0b47da@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <e75oGeybsRKX17FZaNihsb_ZLHogIQhT5WER0pkMy-M=.b437f763-29ca-4312-bbcd-6043da0b47da@github.com>
Message-ID: <1dbxtHaznSK0MmQ1ReRu-E74YCUr_ubYzPLiQpDohns=.736b5294-380d-4a82-8bfe-d21324f56bb8@github.com>

On Mon, 2 Aug 2021 05:00:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The Nimbus look and feel ignores the configured background color of a JTextPane and always uses white. 
>> Every other look and feel tested (Metal, Motif, and Windows) correctly honors the configured background color of a JTextPane.
>> Issue seems to be in the hardcoded background color in nimbus skin which is rectified via the fix. 
>> After this fix, the background color is correctly updated to whatever is being set via JTextPane.setBackground().
>> 
>> CI all test run is green.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix
>  - JEditorpane background color fix

The tests are nearly the same: the only difference is the component being tested. I suggest merging the two tests into one test which tests both components one after another.

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

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

From serb at openjdk.java.net  Wed Aug  4 23:09:30 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 4 Aug 2021 23:09:30 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v2]
In-Reply-To: <nOFcTm-9k0C4u3eWJEIAHPSS_uKqFdIH83Vb8QzWcLo=.53eb6bf9-aa6e-4891-bac0-01e65dcc3e9c@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <e75oGeybsRKX17FZaNihsb_ZLHogIQhT5WER0pkMy-M=.b437f763-29ca-4312-bbcd-6043da0b47da@github.com>
 <jgqxu9J5b9YaCl1Bskr7pPtEq4qpW0aoZKtn7s9-CRQ=.813bd0fb-0cf8-4b51-8b86-0f82b6bd0eda@github.com>
 <8zdodK_7aqrcZDCNTVCnNp9PSm3VMGamkLBrrt4QNDI=.06d2f6fb-1f9b-4f34-a8c6-ea546d6297a1@github.com>
 <7KKvg035KagQnRnnJoKuSiQKw_w_Cmi1DaRvTON_iBA=.6a2b67c6-e14c-40a7-a956-68486aa9e77a@github.com>
 <0agJRxvFFG07422R6hyUGtN9xLr6KMwAOMBbZ8qk-wc=.0497684f-d01d-41ba-9abd-7f63703b9cf8@github.com>
 <-hTd-xSgW1pVbPD09s3_-sYk67LyfDYrQkZrJyhNcic=.b5d9702e-10b9-48ca-981a-fcc190482abd@github.com>
 <O_K-9S9JjaaSMiIrDAGeCSLfMKnb2RxfjKFPYOcXcdg=.e48f2e4a-6d25-459a-87b1-3f60a864370f@github.com>
 <-rE0VwWK2tu1Bhrtq3HkqcJFehHWqaS4e40TaU9x-ZY=.6ba3197e-5319-45af-bc47-9ee9d019b208@github.com>
 <nOFcTm-9k0C4u3eWJEIAHPSS_uKqFdIH83Vb8QzWcLo=.53eb6bf9-aa6e-4891-bac0-01e65dcc3e9c@github.com>
Message-ID: <Mjr61dB7SqTTSmOjQUErJF4Fi73aVi668hk3a6h3YY0=.b39e83c3-2843-4941-881f-360ba318552b@github.com>

On Wed, 4 Aug 2021 21:19:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I think we should give this fix a chance...sInce this is solving 2 long-standing issue where setBackground() contract is not honoured plus causing no regression to existing tests.
>> If we do find any testcase with "shape" in future from open community or any other related testcase being failed for this fix, we can always work on it (or at the least roll back this)
>
> It looks the fix doesn't work or alternatively it works in an unexpected way.
> 
> Both JEditorPane and JTextPane used to have white background but now, with these changes, their background is the same of the panel below. It's probably know what we want.

The last time this code was touched we get a regression https://bugs.openjdk.java.net/browse/JDK-8266510 which was not found by any tests. JCK cannot found them since this is L&F dependent. And regression tests do not have related tests because we had never bugs here, it worked this way from the beginning.

So it will be good to understand why these tags prevent the color change, how the shape tags are used, instead of some unknown changes here and there.

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

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

From serb at openjdk.java.net  Wed Aug  4 23:14:34 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 4 Aug 2021 23:14:34 GMT
Subject: <Swing Dev> RFR: 8268824: Remove unused jdk.accessibility APIs
 deprecated for removal in JDK 9 [v2]
In-Reply-To: <8s65wwjUmv_ScFNISHRBT18K23VVCFxxq9e06maXvKQ=.aa16fa79-f8a0-4d1e-ba60-4954923f86c6@github.com>
References: <TAjMVj453jPFSRgK0i5WE5XDlgIKc7z6uOr9Mcp80B8=.a3f45901-60cf-4b88-aed6-767e581e34a3@github.com>
 <8s65wwjUmv_ScFNISHRBT18K23VVCFxxq9e06maXvKQ=.aa16fa79-f8a0-4d1e-ba60-4954923f86c6@github.com>
Message-ID: <oTA-PsZ80jtHd4UUhgDTReQFntL65V4LpLjyQNViyoE=.25aca685-e663-45fe-8174-2536ba5425a0@github.com>

On Wed, 4 Aug 2021 20:10:50 GMT, Phil Race <prr at openjdk.org> wrote:

>> These fields
>> -  have not been used by the implementation since JDK8,
>> - are not supposed to be used by applications,
>> - have been deprecated for removal since JDK 9
>> - are non-standard, JDK not Java, classes
>> - very few clients are expected to be using these classes : just those implementing ATs
>> 
>> 
>> The CSR for this is https://bugs.openjdk.java.net/browse/JDK-8270918
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8268824: Remove unused jdk.accessibility APIs deprecated for removal in JDK 9

Marked as reviewed by serb (Reviewer).

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

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

From yyang at openjdk.java.net  Thu Aug  5 03:11:30 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 5 Aug 2021 03:11:30 GMT
Subject: <Swing Dev> RFR: 8270058: Use Objects.check{Index,
 FromIndexSize} for java.desktop [v3]
In-Reply-To: <Sj1ctbhJEOMTbZQwEdJmjz28i0AAbwNoUnXm9a6fOxA=.90f0249c-06f9-40fb-8fcf-40351a82b919@github.com>
References: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
 <FBiKIDgqehM1qVz94eqqkPEyXPKzc-X9qY6lz_zIXsU=.65ecec40-aa0a-4682-9c48-83a1b638abb5@github.com>
 <kD-P18tO8LtPFWAUjFH8yQ7aq_L6h_0i8hQVYfXcdsg=.87d4c55d-f688-4dcf-b415-1bd20410a952@github.com>
 <P2bSP34audQsf17W2PG7hwz4kpBsCA3eeFPTuskBLhU=.e169a20e-8ca8-422c-877e-9fadb0e219ef@github.com>
 <Sj1ctbhJEOMTbZQwEdJmjz28i0AAbwNoUnXm9a6fOxA=.90f0249c-06f9-40fb-8fcf-40351a82b919@github.com>
Message-ID: <eAAlannzLAo6Llvx8cKbh72Fq0XVOZucIuqetTxQk_Q=.e125612e-2e62-4228-83c5-b1a49a43c63a@github.com>

On Fri, 30 Jul 2021 08:59:31 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Objects.checkIndex itself throws exceptions for wrong values. So this should be ok. No?
>
> We have specific message here like "Tab count" which we are not passing and will be helpful for debugging in future.

Restored.

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

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

From yyang at openjdk.java.net  Thu Aug  5 03:11:30 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 5 Aug 2021 03:11:30 GMT
Subject: <Swing Dev> RFR: 8270058: Use Objects.check{Index,
 FromIndexSize} for java.desktop [v3]
In-Reply-To: <FBiKIDgqehM1qVz94eqqkPEyXPKzc-X9qY6lz_zIXsU=.65ecec40-aa0a-4682-9c48-83a1b638abb5@github.com>
References: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
 <FBiKIDgqehM1qVz94eqqkPEyXPKzc-X9qY6lz_zIXsU=.65ecec40-aa0a-4682-9c48-83a1b638abb5@github.com>
Message-ID: <GmzgrzjkqR4teOFgDNkGcE7EDjEYpYIPqjHSgxnSW6E=.5c6ab90b-1928-4335-ac44-d5928a1e7705@github.com>

On Thu, 22 Jul 2021 06:29:13 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>> 
>> As Mandy suggested, I create this PR for changes involving client code:
>> 
>> src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java
>> src/java.desktop/share/classes/javax/swing/JTabbedPane.java
>> test/jdk/java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
>> test/jdk/javax/imageio/AppletResourceTest.java
>> test/jdk/javax/imageio/ImageReaderReadAll.java
>> test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Thanks @mrserb @prsadhuk @jayathirthrao and @pankaj-bansal for reviews!

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

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

From yyang at openjdk.java.net  Thu Aug  5 03:25:49 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 5 Aug 2021 03:25:49 GMT
Subject: <Swing Dev> RFR: 8270058: Use Objects.check{Index,
 FromIndexSize} for java.desktop [v4]
In-Reply-To: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
References: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
Message-ID: <ZQJUJSb1WP0NHFS-StJA55LzvuhWRr8yZ21lqk30a6k=.e43d0e7a-8372-423a-b522-ef3451cbfd0e@github.com>

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
> 
> As Mandy suggested, I create this PR for changes involving client code:
> 
> src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java
> src/java.desktop/share/classes/javax/swing/JTabbedPane.java
> test/jdk/java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
> test/jdk/javax/imageio/AppletResourceTest.java
> test/jdk/javax/imageio/ImageReaderReadAll.java
> test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  review from @jayathirthrao

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4718/files
  - new: https://git.openjdk.java.net/jdk/pull/4718/files/1db9e872..83ad6590

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

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

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

From jdv at openjdk.java.net  Thu Aug  5 03:59:32 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 5 Aug 2021 03:59:32 GMT
Subject: <Swing Dev> RFR: 8270058: Use Objects.check{Index,
 FromIndexSize} for java.desktop [v4]
In-Reply-To: <ZQJUJSb1WP0NHFS-StJA55LzvuhWRr8yZ21lqk30a6k=.e43d0e7a-8372-423a-b522-ef3451cbfd0e@github.com>
References: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
 <ZQJUJSb1WP0NHFS-StJA55LzvuhWRr8yZ21lqk30a6k=.e43d0e7a-8372-423a-b522-ef3451cbfd0e@github.com>
Message-ID: <BDJWQbKk483PxE5cf0A83eE_U9lXn1nxjwfRUcd9D8c=.1de1f278-040e-4b58-a12b-4eb0f8fab35b@github.com>

On Thu, 5 Aug 2021 03:25:49 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>> 
>> As Mandy suggested, I create this PR for changes involving client code:
>> 
>> src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java
>> src/java.desktop/share/classes/javax/swing/JTabbedPane.java
>> test/jdk/java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
>> test/jdk/javax/imageio/AppletResourceTest.java
>> test/jdk/javax/imageio/ImageReaderReadAll.java
>> test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review from @jayathirthrao

Marked as reviewed by jdv (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Thu Aug  5 04:59:52 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 5 Aug 2021 04:59:52 GMT
Subject: <Swing Dev> RFR: 4819544: SwingSet2 JTable Demo throws
 NullPointerException [v2]
In-Reply-To: <iIwgnxXhimiHNB5c1aqnlrPnXNC7bzSiSTGuIF3SiB4=.7266c195-3e3b-4849-8f0c-7339a5aa6243@github.com>
References: <iIwgnxXhimiHNB5c1aqnlrPnXNC7bzSiSTGuIF3SiB4=.7266c195-3e3b-4849-8f0c-7339a5aa6243@github.com>
Message-ID: <_Z_igZRD2l2b4TTs9OjYp4JrN1jJkupxNsXYyqxT1_g=.c0f8c20e-309e-4aa3-88b5-d6eafd2df7bc@github.com>

> In the JTable demo, if we double click on the first cell in the Favorite Number column, delete the value and click on some
> other cell, a java.lang.NullPointerException is getting thrown.
> The flaw is in the TableDemo's TableModel getColumnClass() method which queries the value of cell 0 in the target column, and returns its Class. This logic seems to be flawed - an NPE will be thrown when the value in cell 0 is null.
> Fix by checking for null.

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

  Use ternary operator

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4969/files
  - new: https://git.openjdk.java.net/jdk/pull/4969/files/5b181bee..fffb3f32

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

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

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

From psadhukhan at openjdk.java.net  Thu Aug  5 04:59:52 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 5 Aug 2021 04:59:52 GMT
Subject: <Swing Dev> Integrated: 4819544: SwingSet2 JTable Demo throws
 NullPointerException
In-Reply-To: <iIwgnxXhimiHNB5c1aqnlrPnXNC7bzSiSTGuIF3SiB4=.7266c195-3e3b-4849-8f0c-7339a5aa6243@github.com>
References: <iIwgnxXhimiHNB5c1aqnlrPnXNC7bzSiSTGuIF3SiB4=.7266c195-3e3b-4849-8f0c-7339a5aa6243@github.com>
Message-ID: <vANh-nE_0r-24rsE8F-ycDToE0gXYOtuI2e0ngGJ0Hc=.0ba8e931-cd99-42b8-af68-4f3739076f26@github.com>

On Tue, 3 Aug 2021 08:23:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In the JTable demo, if we double click on the first cell in the Favorite Number column, delete the value and click on some
> other cell, a java.lang.NullPointerException is getting thrown.
> The flaw is in the TableDemo's TableModel getColumnClass() method which queries the value of cell 0 in the target column, and returns its Class. This logic seems to be flawed - an NPE will be thrown when the value in cell 0 is null.
> Fix by checking for null.

This pull request has now been integrated.

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

4819544: SwingSet2 JTable Demo throws NullPointerException

Reviewed-by: pbansal, aivanov

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

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

From psadhukhan at openjdk.java.net  Thu Aug  5 05:02:29 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 5 Aug 2021 05:02:29 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE
In-Reply-To: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
Message-ID: <MbUvZKJwX3i7ZYJr7SmxEq24SlYXzxIQYvYySnkNAdM=.d30cc8d7-9b12-4517-9962-e6efded847cb@github.com>

On Wed, 4 Aug 2021 09:02:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
> Added null check for those cases.

Will just stating null icon is unsupported do? I think in that case should we throw IAE?

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

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

From psadhukhan at openjdk.java.net  Thu Aug  5 05:21:30 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 5 Aug 2021 05:21:30 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v2]
In-Reply-To: <Mjr61dB7SqTTSmOjQUErJF4Fi73aVi668hk3a6h3YY0=.b39e83c3-2843-4941-881f-360ba318552b@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <e75oGeybsRKX17FZaNihsb_ZLHogIQhT5WER0pkMy-M=.b437f763-29ca-4312-bbcd-6043da0b47da@github.com>
 <jgqxu9J5b9YaCl1Bskr7pPtEq4qpW0aoZKtn7s9-CRQ=.813bd0fb-0cf8-4b51-8b86-0f82b6bd0eda@github.com>
 <8zdodK_7aqrcZDCNTVCnNp9PSm3VMGamkLBrrt4QNDI=.06d2f6fb-1f9b-4f34-a8c6-ea546d6297a1@github.com>
 <7KKvg035KagQnRnnJoKuSiQKw_w_Cmi1DaRvTON_iBA=.6a2b67c6-e14c-40a7-a956-68486aa9e77a@github.com>
 <0agJRxvFFG07422R6hyUGtN9xLr6KMwAOMBbZ8qk-wc=.0497684f-d01d-41ba-9abd-7f63703b9cf8@github.com>
 <-hTd-xSgW1pVbPD09s3_-sYk67LyfDYrQkZrJyhNcic=.b5d9702e-10b9-48ca-981a-fcc190482abd@github.com>
 <O_K-9S9JjaaSMiIrDAGeCSLfMKnb2RxfjKFPYOcXcdg=.e48f2e4a-6d25-459a-87b1-3f60a864370f@github.com>
 <-rE0VwWK2tu1Bhrtq3HkqcJFehHWqaS4e40TaU9x-ZY=.6ba3197e-5319-45af-bc47-9ee9d019b208@github.com>
 <nOFcTm-9k0C4u3eWJEIAHPSS_uKqFdIH83Vb8QzWcLo=.53eb6bf9-aa6e-4891-bac0-01e65dcc3e9c@github.com>
 <Mjr61dB7SqTTSmOjQUErJF4Fi73aVi668hk
 3a6h3YY0=.b39e83c3-2843-4941-881f-360ba318552b@github.com>
Message-ID: <Ha3gYu_CvLFUqeD2mlIyfb-JlRyPjRx8cMwP6C9g22w=.282e991a-3c03-4f39-8861-8dfca6a4f523@github.com>

On Wed, 4 Aug 2021 23:06:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> It looks the fix doesn't work or alternatively it works in an unexpected way.
>> 
>> Both JEditorPane and JTextPane used to have white background but now, with these changes, their background is the same of the panel below. It's probably know what we want.
>
> The last time this code was touched we get a regression https://bugs.openjdk.java.net/browse/JDK-8266510 which was not found by any tests. JCK cannot found them since this is L&F dependent. And regression tests do not have related tests because we had never bugs here, it worked this way from the beginning.
> 
> So it will be good to understand why these tags prevent the color change, how the shape tags are used, instead of some unknown changes here and there.

JDK-8266510 regression was found by SwingSet2 so it is wrong to say it was not found by any test, maybe it was not verified during fix of JDK-8249674. For this, all existing test is run.

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

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

From yyang at openjdk.java.net  Thu Aug  5 06:42:34 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 5 Aug 2021 06:42:34 GMT
Subject: <Swing Dev> Integrated: 8270058: Use Objects.check{Index,
 FromIndexSize} for java.desktop
In-Reply-To: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
References: <fC4TWKB-5TKZ_kSn1Wau2sdYCXm8kAdN-MsutORdCak=.40a666a8-9dca-4edb-8328-03d8406ea07e@github.com>
Message-ID: <CI1bwKQFUljjTXni2EfzTLMFzKxNlk29RyIw_jEUgcc=.c8dc9df4-4c02-4262-ab3c-898b591f36da@github.com>

On Thu, 8 Jul 2021 08:32:49 GMT, Yi Yang <yyang at openjdk.org> wrote:

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
> 
> As Mandy suggested, I create this PR for changes involving client code:
> 
> src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java
> src/java.desktop/share/classes/javax/swing/JTabbedPane.java
> test/jdk/java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
> test/jdk/javax/imageio/AppletResourceTest.java
> test/jdk/javax/imageio/ImageReaderReadAll.java
> test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java

This pull request has now been integrated.

Changeset: ea9a5952
Author:    Yi Yang <yyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ea9a59520de45fe1c2a6706b2a924cbc856a06c6
Stats:     41 lines in 6 files changed: 7 ins; 19 del; 15 mod

8270058: Use Objects.check{Index,FromIndexSize} for java.desktop

Reviewed-by: psadhukhan, pbansal, jdv

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

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

From psadhukhan at openjdk.java.net  Thu Aug  5 08:37:07 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 5 Aug 2021 08:37:07 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v3]
In-Reply-To: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
Message-ID: <8kKcOuRIJIzVWaiGLoLfqp0DNNFt8dtW_RU9xs6i0sw=.4d0983c8-6cb4-45a6-836d-909c17f6d22b@github.com>

> The Nimbus look and feel ignores the configured background color of a JTextPane and always uses white. 
> Every other look and feel tested (Metal, Motif, and Windows) correctly honors the configured background color of a JTextPane.
> Issue seems to be in the hardcoded background color in nimbus skin which is rectified via the fix. 
> After this fix, the background color is correctly updated to whatever is being set via JTextPane.setBackground().
> 
> CI all test run is green.

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

  Use background componentPropertyName

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4930/files
  - new: https://git.openjdk.java.net/jdk/pull/4930/files/ccde17d7..f308e231

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

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

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

From psadhukhan at openjdk.java.net  Thu Aug  5 08:46:30 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 5 Aug 2021 08:46:30 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v3]
In-Reply-To: <8kKcOuRIJIzVWaiGLoLfqp0DNNFt8dtW_RU9xs6i0sw=.4d0983c8-6cb4-45a6-836d-909c17f6d22b@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <8kKcOuRIJIzVWaiGLoLfqp0DNNFt8dtW_RU9xs6i0sw=.4d0983c8-6cb4-45a6-836d-909c17f6d22b@github.com>
Message-ID: <uj9TZVGTyv443f_mYLNqA__FcxbIJ-cviN8dyIxGN3U=.529fe49f-9e74-4732-96dd-0f5636cb3847@github.com>

On Thu, 5 Aug 2021 08:37:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The Nimbus look and feel ignores the configured background color of a JTextPane and always uses white. 
>> Every other look and feel tested (Metal, Motif, and Windows) correctly honors the configured background color of a JTextPane.
>> Issue seems to be in the hardcoded background color in nimbus skin which is rectified via the fix. 
>> After this fix, the background color is correctly updated to whatever is being set via JTextPane.setBackground().
>> 
>> CI all test run is green.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use background componentPropertyName

Restored "shape" tag and now tackling the bug from the fact that JTextField/JTextARea setbackground works unlike JTextPane/EditorPane. 
It seems TextPanePainter class is generated from skin template where for JTextField/Area we have


private void paintBackgroundEnabled(Graphics2D g) {
        this.rect = this.decodeRect1();
        g.setPaint((Color)this.componentColors[0]);
        g.fill(this.rect);
    }

but for JTextPane/EditorPane, we have



private void paintBackgroundEnabled(Graphics2D g) {
        this.rect = this.decodeRect1();
        g.setPaint((Color)this.color2);
        g.fill(this.rect);
    }



where color2 is NimubsLightBackground so it seems to always paint white. 
Proposed fix is to add background componentPropertyName for ENABLED state (for the fact 
getContext is always called with SynthContext context = getContext(comp, ENABLED);
so that correct background component color is painted.`

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

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

From serb at openjdk.java.net  Thu Aug  5 20:11:31 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 5 Aug 2021 20:11:31 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE
In-Reply-To: <MbUvZKJwX3i7ZYJr7SmxEq24SlYXzxIQYvYySnkNAdM=.d30cc8d7-9b12-4517-9962-e6efded847cb@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <MbUvZKJwX3i7ZYJr7SmxEq24SlYXzxIQYvYySnkNAdM=.d30cc8d7-9b12-4517-9962-e6efded847cb@github.com>
Message-ID: <QJ7zgakWd0vADXpDqIgVB5PDpLZkcBb_Qro5DFaI43Y=.7d303ad5-12bb-48c3-b2f5-4c852b5db61a@github.com>

On Thu, 5 Aug 2021 04:59:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Will just stating null icon is unsupported do? I think in that case should we throw IAE?

This icon field is protected so technically it can be changed w/o constructor and set method. So we have a choice:
1. Specify that the null icon is unsupported and may throw NPE any time after
2. Update the set method to throw NPE(since this is an exception already used by various parts) if a null value is passed.

We can do only the first one, or both.

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

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

From prr at openjdk.java.net  Mon Aug  9 03:28:49 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 9 Aug 2021 03:28:49 GMT
Subject: <Swing Dev> RFR: 8272123: Problem list 4 jtreg tests which
 regularly fail on macos-aach64
Message-ID: <ScnBatEpBIYySaJQ0jFDuM2sQXbc0So8FSo8s4J0_9g=.d3c85320-5786-48d8-b66f-f0c9fe513de1@github.com>

As per the bug comments, these tests fail too often on macOS arm. 
This will be too noisy for CI. So I would like to problem list them for mac-arm

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

Commit messages:
 - 8272123: Problem list 4 jtreg tests which regularly fail on macos-aarch64

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

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

From jdv at openjdk.java.net  Mon Aug  9 03:53:30 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Mon, 9 Aug 2021 03:53:30 GMT
Subject: <Swing Dev> RFR: 8272123: Problem list 4 jtreg tests which
 regularly fail on macos-aach64
In-Reply-To: <ScnBatEpBIYySaJQ0jFDuM2sQXbc0So8FSo8s4J0_9g=.d3c85320-5786-48d8-b66f-f0c9fe513de1@github.com>
References: <ScnBatEpBIYySaJQ0jFDuM2sQXbc0So8FSo8s4J0_9g=.d3c85320-5786-48d8-b66f-f0c9fe513de1@github.com>
Message-ID: <BtGIfhlR7TjZqj9Rk3Vx8b1dJlrxmSRqwXT3wusYh7c=.f967e621-9822-4fe8-96a1-75a6a049a500@github.com>

On Mon, 9 Aug 2021 03:17:20 GMT, Phil Race <prr at openjdk.org> wrote:

> As per the bug comments, these tests fail too often on macOS arm. 
> This will be too noisy for CI. So I would like to problem list them for mac-arm

Marked as reviewed by jdv (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Mon Aug  9 04:21:08 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 9 Aug 2021 04:21:08 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v2]
In-Reply-To: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
Message-ID: <vvBcOpFHoAow6pLkn9TSYGd_4kbU7tj2PkOyv69840Q=.e7fd1555-fd4f-45f0-849d-3ead26d38a11@github.com>

> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
> Added null check for those cases.

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - Remove test
 - Update javadoc clarification

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4989/files
  - new: https://git.openjdk.java.net/jdk/pull/4989/files/2a2ab50d..0c96a6e3

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

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

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

From serb at openjdk.java.net  Mon Aug  9 04:32:32 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 9 Aug 2021 04:32:32 GMT
Subject: <Swing Dev> RFR: 8272123: Problem list 4 jtreg tests which
 regularly fail on macos-aach64
In-Reply-To: <ScnBatEpBIYySaJQ0jFDuM2sQXbc0So8FSo8s4J0_9g=.d3c85320-5786-48d8-b66f-f0c9fe513de1@github.com>
References: <ScnBatEpBIYySaJQ0jFDuM2sQXbc0So8FSo8s4J0_9g=.d3c85320-5786-48d8-b66f-f0c9fe513de1@github.com>
Message-ID: <K-Ndjfj6rvnl--z88rk6PwaCYNxQvAXUhsR2cPGGGU8=.f11f19ff-afb9-4df5-a0c8-425c8ec37a12@github.com>

On Mon, 9 Aug 2021 03:17:20 GMT, Phil Race <prr at openjdk.org> wrote:

> As per the bug comments, these tests fail too often on macOS arm. 
> This will be too noisy for CI. So I would like to problem list them for mac-arm

test/jdk/ProblemList.txt line 532:

> 530: 
> 531: java/awt/Window/GetScreenLocation/GetScreenLocationTest.java 8225787 linux-x64
> 532: java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java 8252813 macosx-aarch64

Looks like this bug is a closed one, can it be open?

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

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

From psadhukhan at openjdk.java.net  Mon Aug  9 04:42:37 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 9 Aug 2021 04:42:37 GMT
Subject: <Swing Dev> RFR: 8272123: Problem list 4 jtreg tests which
 regularly fail on macos-aach64
In-Reply-To: <K-Ndjfj6rvnl--z88rk6PwaCYNxQvAXUhsR2cPGGGU8=.f11f19ff-afb9-4df5-a0c8-425c8ec37a12@github.com>
References: <ScnBatEpBIYySaJQ0jFDuM2sQXbc0So8FSo8s4J0_9g=.d3c85320-5786-48d8-b66f-f0c9fe513de1@github.com>
 <K-Ndjfj6rvnl--z88rk6PwaCYNxQvAXUhsR2cPGGGU8=.f11f19ff-afb9-4df5-a0c8-425c8ec37a12@github.com>
Message-ID: <p1JdsfIb9GfZJiHiveO_D0g0mTx52f6qLirUJD61z0A=.4e06f498-45a0-43ae-9cc8-a003e8588a85@github.com>

On Mon, 9 Aug 2021 04:28:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> As per the bug comments, these tests fail too often on macOS arm. 
>> This will be too noisy for CI. So I would like to problem list them for mac-arm
>
> test/jdk/ProblemList.txt line 532:
> 
>> 530: 
>> 531: java/awt/Window/GetScreenLocation/GetScreenLocationTest.java 8225787 linux-x64
>> 532: java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java 8252813 macosx-aarch64
> 
> Looks like this bug is a closed one, can it be open?

Maybe we should use JDK-8266243 instead. Other one has other tests as well.

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

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

From psadhukhan at openjdk.java.net  Mon Aug  9 08:36:38 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 9 Aug 2021 08:36:38 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v3]
In-Reply-To: <8kKcOuRIJIzVWaiGLoLfqp0DNNFt8dtW_RU9xs6i0sw=.4d0983c8-6cb4-45a6-836d-909c17f6d22b@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <8kKcOuRIJIzVWaiGLoLfqp0DNNFt8dtW_RU9xs6i0sw=.4d0983c8-6cb4-45a6-836d-909c17f6d22b@github.com>
Message-ID: <VB5_8nj4VtQLRk2V-k19GvzTnffTXMRh9FCIsD8NjNg=.142d09cd-3cec-4ce6-8227-f0903649658a@github.com>

On Thu, 5 Aug 2021 08:37:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The Nimbus look and feel ignores the configured background color of a JTextPane and always uses white. 
>> Every other look and feel tested (Metal, Motif, and Windows) correctly honors the configured background color of a JTextPane.
>> Issue seems to be in the hardcoded background color in nimbus skin which is rectified via the fix. 
>> After this fix, the background color is correctly updated to whatever is being set via JTextPane.setBackground().
>> 
>> CI all test run is green.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use background componentPropertyName

All CI test including JCK are green.

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

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

From psadhukhan at openjdk.java.net  Mon Aug  9 09:27:12 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 9 Aug 2021 09:27:12 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v2]
In-Reply-To: <1dbxtHaznSK0MmQ1ReRu-E74YCUr_ubYzPLiQpDohns=.736b5294-380d-4a82-8bfe-d21324f56bb8@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <e75oGeybsRKX17FZaNihsb_ZLHogIQhT5WER0pkMy-M=.b437f763-29ca-4312-bbcd-6043da0b47da@github.com>
 <1dbxtHaznSK0MmQ1ReRu-E74YCUr_ubYzPLiQpDohns=.736b5294-380d-4a82-8bfe-d21324f56bb8@github.com>
Message-ID: <vCOLstkKwEwl8CrD49iw5QK9y2qaPjTrrb2bFa0Gxbg=.25405b7e-73d4-417e-abb2-6ed75daaccca@github.com>

On Wed, 4 Aug 2021 21:23:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> 
> 
> The tests are nearly the same: the only difference is the component being tested. I suggest merging the two tests into one test which tests both components one after another.

I would rather have as separate test as the fix is in 2 different component, I could have raised separate PRs as fix area is different although fix seems to be same..and I don't see it as anyhting other than test optimization..
If you absolutely cannot approve without test merged, then please let me know. I would try to do

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

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

From aivanov at openjdk.java.net  Mon Aug  9 13:04:33 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 9 Aug 2021 13:04:33 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v2]
In-Reply-To: <vCOLstkKwEwl8CrD49iw5QK9y2qaPjTrrb2bFa0Gxbg=.25405b7e-73d4-417e-abb2-6ed75daaccca@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <e75oGeybsRKX17FZaNihsb_ZLHogIQhT5WER0pkMy-M=.b437f763-29ca-4312-bbcd-6043da0b47da@github.com>
 <1dbxtHaznSK0MmQ1ReRu-E74YCUr_ubYzPLiQpDohns=.736b5294-380d-4a82-8bfe-d21324f56bb8@github.com>
 <vCOLstkKwEwl8CrD49iw5QK9y2qaPjTrrb2bFa0Gxbg=.25405b7e-73d4-417e-abb2-6ed75daaccca@github.com>
Message-ID: <_T5IGY5AQVyB4Tlu05ewwTHO7kYFfYG6Ik741_wfX1Y=.7776e826-a79a-40a3-9bd6-61685d3caf5f@github.com>

On Mon, 9 Aug 2021 09:10:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > The tests are nearly the same: the only difference is the component being tested. I suggest merging the two tests into one test which tests both components one after another.
> 
> I would rather have as separate test as the fix is in 2 different component, I could have raised separate PRs as fix area is different although fix seems to be same..and I don't see it as anyhting other than test optimization..
> If you absolutely cannot approve without test merged, then please let me know. I would try to do

I'm for fixing these two issues under one PR. The fix is basically the same, so it makes it easier to review and track changes later.

Yes, it's kind of a test optimisation. Yet the tests are similar in nature, they exercise the same behaviour in two different components. It just makes sense to re-use the code. If a fix is necessary to one test, it is necessary for the other ? same idea why avoiding duplicate code is good.

It's not a show-stopper though if everyone agrees it's better to have two different tests.

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

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

From psadhukhan at openjdk.java.net  Mon Aug  9 13:28:11 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 9 Aug 2021 13:28:11 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v4]
In-Reply-To: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
Message-ID: <br595_14v6yNbYpG46gMc9HX0Dc5VOPefFxzKGKRTz4=.ceb473fa-3b8f-46b0-8aea-c633f5db68b9@github.com>

> The Nimbus look and feel ignores the configured background color of a JTextPane and always uses white. 
> Every other look and feel tested (Metal, Motif, and Windows) correctly honors the configured background color of a JTextPane.
> Issue seems to be in the hardcoded background color in nimbus skin which is rectified via the fix. 
> After this fix, the background color is correctly updated to whatever is being set via JTextPane.setBackground().
> 
> CI all test run is green.

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - Fix
 - Merge test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4930/files
  - new: https://git.openjdk.java.net/jdk/pull/4930/files/f308e231..8e01458d

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

  Stats: 309 lines in 3 files changed: 135 ins; 174 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4930.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4930/head:pull/4930

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

From psadhukhan at openjdk.java.net  Mon Aug  9 13:28:12 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 9 Aug 2021 13:28:12 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v2]
In-Reply-To: <_T5IGY5AQVyB4Tlu05ewwTHO7kYFfYG6Ik741_wfX1Y=.7776e826-a79a-40a3-9bd6-61685d3caf5f@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <e75oGeybsRKX17FZaNihsb_ZLHogIQhT5WER0pkMy-M=.b437f763-29ca-4312-bbcd-6043da0b47da@github.com>
 <1dbxtHaznSK0MmQ1ReRu-E74YCUr_ubYzPLiQpDohns=.736b5294-380d-4a82-8bfe-d21324f56bb8@github.com>
 <vCOLstkKwEwl8CrD49iw5QK9y2qaPjTrrb2bFa0Gxbg=.25405b7e-73d4-417e-abb2-6ed75daaccca@github.com>
 <_T5IGY5AQVyB4Tlu05ewwTHO7kYFfYG6Ik741_wfX1Y=.7776e826-a79a-40a3-9bd6-61685d3caf5f@github.com>
Message-ID: <M2D82ecB44nmMWJq3XnIDh71UOnytX0mLp5xcZ5XV5Q=.54ff2e04-ebcf-4b57-b280-dab0c736a4ef@github.com>

On Mon, 9 Aug 2021 13:01:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> 
> 
> > > The tests are nearly the same: the only difference is the component being tested. I suggest merging the two tests into one test which tests both components one after another.
> > 
> > 
> > I would rather have as separate test as the fix is in 2 different component, I could have raised separate PRs as fix area is different although fix seems to be same..and I don't see it as anyhting other than test optimization..
> > If you absolutely cannot approve without test merged, then please let me know. I would try to do
> 
> I'm for fixing these two issues under one PR. The fix is basically the same, so it makes it easier to review and track changes later.
> 
> Yes, it's kind of a test optimisation. Yet the tests are similar in nature, they exercise the same behaviour in two different components. It just makes sense to re-use the code. If a fix is necessary to one test, it is necessary for the other ? same idea why avoiding duplicate code is good.
> 
> It's not a show-stopper though if everyone agrees it's better to have two different tests.

OK..Not a problem. Merged...

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

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

From psadhukhan at openjdk.java.net  Mon Aug  9 15:03:10 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 9 Aug 2021 15:03:10 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v5]
In-Reply-To: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
Message-ID: <NEBcgKe_kGWsRs4ON5o7C3CuN3FtWprO0kq8be2Za6w=.e1e565de-eac4-49bc-9010-934bf89a701f@github.com>

> The Nimbus look and feel ignores the configured background color of a JTextPane and always uses white. 
> Every other look and feel tested (Metal, Motif, and Windows) correctly honors the configured background color of a JTextPane.
> Issue seems to be in the hardcoded background color in nimbus skin which is rectified via the fix. 
> After this fix, the background color is correctly updated to whatever is being set via JTextPane.setBackground().
> 
> CI all test run is green.

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

  Optimize test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4930/files
  - new: https://git.openjdk.java.net/jdk/pull/4930/files/8e01458d..31676791

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

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

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

From prr at openjdk.java.net  Mon Aug  9 15:06:55 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 9 Aug 2021 15:06:55 GMT
Subject: <Swing Dev> RFR: 8272123: Problem list 4 jtreg tests which
 regularly fail on macos-aach64 [v2]
In-Reply-To: <ScnBatEpBIYySaJQ0jFDuM2sQXbc0So8FSo8s4J0_9g=.d3c85320-5786-48d8-b66f-f0c9fe513de1@github.com>
References: <ScnBatEpBIYySaJQ0jFDuM2sQXbc0So8FSo8s4J0_9g=.d3c85320-5786-48d8-b66f-f0c9fe513de1@github.com>
Message-ID: <a6HFG5wH7uvgEoAKH_xVWEGqYDtlqaz8hu4vtR-ZQaY=.f0e131cb-0e1a-45a9-b19d-333c0d305d93@github.com>

> As per the bug comments, these tests fail too often on macOS arm. 
> This will be too noisy for CI. So I would like to problem list them for mac-arm

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

  8272123: Problem list 4 jtreg tests which regularly fail on macos-aarch64

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5044/files
  - new: https://git.openjdk.java.net/jdk/pull/5044/files/3cabf620..ecbbca3d

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

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

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

From prr at openjdk.java.net  Mon Aug  9 15:06:55 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 9 Aug 2021 15:06:55 GMT
Subject: <Swing Dev> RFR: 8272123: Problem list 4 jtreg tests which
 regularly fail on macos-aach64 [v2]
In-Reply-To: <p1JdsfIb9GfZJiHiveO_D0g0mTx52f6qLirUJD61z0A=.4e06f498-45a0-43ae-9cc8-a003e8588a85@github.com>
References: <ScnBatEpBIYySaJQ0jFDuM2sQXbc0So8FSo8s4J0_9g=.d3c85320-5786-48d8-b66f-f0c9fe513de1@github.com>
 <K-Ndjfj6rvnl--z88rk6PwaCYNxQvAXUhsR2cPGGGU8=.f11f19ff-afb9-4df5-a0c8-425c8ec37a12@github.com>
 <p1JdsfIb9GfZJiHiveO_D0g0mTx52f6qLirUJD61z0A=.4e06f498-45a0-43ae-9cc8-a003e8588a85@github.com>
Message-ID: <8vTTZFCJKpGIPriTxdL5pyNa9Rlxh_maNZ9_AZiJSKc=.ee728df0-e20f-4193-9bdb-765c36ec6141@github.com>

On Mon, 9 Aug 2021 04:39:02 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Maybe we should use JDK-8266243 instead. Other one has other tests as well.

I can do that. Somehow my search missed that as an option.

> Looks like this bug is a closed one, can it be open?

I think it can be open but it won't be listed here with the changeI just made  to reference 8266243

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

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

From psadhukhan at openjdk.java.net  Mon Aug  9 15:22:34 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 9 Aug 2021 15:22:34 GMT
Subject: <Swing Dev> RFR: 8272123: Problem list 4 jtreg tests which
 regularly fail on macos-aach64 [v2]
In-Reply-To: <a6HFG5wH7uvgEoAKH_xVWEGqYDtlqaz8hu4vtR-ZQaY=.f0e131cb-0e1a-45a9-b19d-333c0d305d93@github.com>
References: <ScnBatEpBIYySaJQ0jFDuM2sQXbc0So8FSo8s4J0_9g=.d3c85320-5786-48d8-b66f-f0c9fe513de1@github.com>
 <a6HFG5wH7uvgEoAKH_xVWEGqYDtlqaz8hu4vtR-ZQaY=.f0e131cb-0e1a-45a9-b19d-333c0d305d93@github.com>
Message-ID: <SACT1xi8PVA49EgefnjfZy-l5IeUK7dsvyrHtQhURFY=.4b9ad0e6-1ed8-410c-96ee-f2d1f76407b1@github.com>

On Mon, 9 Aug 2021 15:06:55 GMT, Phil Race <prr at openjdk.org> wrote:

>> As per the bug comments, these tests fail too often on macOS arm. 
>> This will be too noisy for CI. So I would like to problem list them for mac-arm
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8272123: Problem list 4 jtreg tests which regularly fail on macos-aarch64

Marked as reviewed by psadhukhan (Reviewer).

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

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

From aivanov at openjdk.java.net  Mon Aug  9 16:01:33 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 9 Aug 2021 16:01:33 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v4]
In-Reply-To: <br595_14v6yNbYpG46gMc9HX0Dc5VOPefFxzKGKRTz4=.ceb473fa-3b8f-46b0-8aea-c633f5db68b9@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <br595_14v6yNbYpG46gMc9HX0Dc5VOPefFxzKGKRTz4=.ceb473fa-3b8f-46b0-8aea-c633f5db68b9@github.com>
Message-ID: <JYEgjtke-23O9GsntJjN4t1mv2MNBP-UuCd584KAMtQ=.4e36a8af-69fe-43ea-bfd9-62b2a460390a@github.com>

On Mon, 9 Aug 2021 13:28:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The Nimbus look and feel ignores the configured background color of a JTextPane and always uses white. 
>> Every other look and feel tested (Metal, Motif, and Windows) correctly honors the configured background color of a JTextPane.
>> Issue seems to be in the hardcoded background color in nimbus skin which is rectified via the fix. 
>> After this fix, the background color is correctly updated to whatever is being set via JTextPane.setBackground().
>> 
>> CI all test run is green.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix
>  - Merge test

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/plaf/nimbus/TestNimbusBGColor.java line 25:

> 23: /*
> 24:  * @test
> 25:  * @bug 8058704

I believe both bugs should be listed.

test/jdk/javax/swing/plaf/nimbus/TestNimbusBGColor.java line 27:

> 25:  * @bug 8058704
> 26:  * @key headful
> 27:  * @summary  Verifies if Nimbus honor JTextPane background color

?JTextPane and JEditorPane?

test/jdk/javax/swing/plaf/nimbus/TestNimbusBGColor.java line 65:

> 63:                 tp.setForeground(Color.WHITE);
> 64:                 tp.setBackground(Color.BLACK);
> 65:                 tp.setText("This text should be white on black");

I meant to pass a component as a parameter to a generic test method.


private static void testComponent(ComponentCreator<? extends JTextComponent> creator) {
        // Set Look and Feel
        JComponent tc = creator.createComponent();
        // set foreground etc and verify
}


I implemented [what I had in mind](https://github.com/aivanov-jdk/jdk/commit/ba9cbc12c10ba6950a3cd491a9c9c022ab0dad2f). I don't think it's important what background color you use for each component. The updated test fails without the fix and passes with your fix.

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

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

From prr at openjdk.java.net  Mon Aug  9 16:01:37 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 9 Aug 2021 16:01:37 GMT
Subject: <Swing Dev> Integrated: 8272123: Problem list 4 jtreg tests which
 regularly fail on macos-aarch64
In-Reply-To: <ScnBatEpBIYySaJQ0jFDuM2sQXbc0So8FSo8s4J0_9g=.d3c85320-5786-48d8-b66f-f0c9fe513de1@github.com>
References: <ScnBatEpBIYySaJQ0jFDuM2sQXbc0So8FSo8s4J0_9g=.d3c85320-5786-48d8-b66f-f0c9fe513de1@github.com>
Message-ID: <1i8F6oTq_1WfVRbdhod0iy-Bvq2RHztFLZDM2dLrF5w=.c6364a09-230e-4229-a43f-635d8f567d6d@github.com>

On Mon, 9 Aug 2021 03:17:20 GMT, Phil Race <prr at openjdk.org> wrote:

> As per the bug comments, these tests fail too often on macOS arm. 
> This will be too noisy for CI. So I would like to problem list them for mac-arm

This pull request has now been integrated.

Changeset: 0ac2be9b
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0ac2be9b35c56b4b1574cf03fe81111d3f39bedb
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8272123: Problem list 4 jtreg tests which regularly fail on macos-aarch64

Reviewed-by: jdv, psadhukhan

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

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

From prr at openjdk.java.net  Mon Aug  9 18:18:35 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 9 Aug 2021 18:18:35 GMT
Subject: <Swing Dev> Integrated: 8268824: Remove unused jdk.accessibility
 APIs deprecated for removal in JDK 9
In-Reply-To: <TAjMVj453jPFSRgK0i5WE5XDlgIKc7z6uOr9Mcp80B8=.a3f45901-60cf-4b88-aed6-767e581e34a3@github.com>
References: <TAjMVj453jPFSRgK0i5WE5XDlgIKc7z6uOr9Mcp80B8=.a3f45901-60cf-4b88-aed6-767e581e34a3@github.com>
Message-ID: <BrBlsBJwOIgQ4yPo24cOm5sAYe6Uge4SoyHrh3WJnP8=.d2d4e31b-34a6-4a73-a117-0f2ba5fa1ae2@github.com>

On Tue, 20 Jul 2021 19:34:30 GMT, Phil Race <prr at openjdk.org> wrote:

> These fields
> -  have not been used by the implementation since JDK8,
> - are not supposed to be used by applications,
> - have been deprecated for removal since JDK 9
> - are non-standard, JDK not Java, classes
> - very few clients are expected to be using these classes : just those implementing ATs
> 
> 
> The CSR for this is https://bugs.openjdk.java.net/browse/JDK-8270918

This pull request has now been integrated.

Changeset: 4548677e
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4548677e89fb7807639602d29b87dcaabe7b6d8d
Stats:     277 lines in 1 file changed: 0 ins; 143 del; 134 mod

8268824: Remove unused jdk.accessibility APIs deprecated for removal in JDK 9

Reviewed-by: serb

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

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

From aivanov at openjdk.java.net  Mon Aug  9 18:28:33 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 9 Aug 2021 18:28:33 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v3]
In-Reply-To: <uj9TZVGTyv443f_mYLNqA__FcxbIJ-cviN8dyIxGN3U=.529fe49f-9e74-4732-96dd-0f5636cb3847@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <8kKcOuRIJIzVWaiGLoLfqp0DNNFt8dtW_RU9xs6i0sw=.4d0983c8-6cb4-45a6-836d-909c17f6d22b@github.com>
 <uj9TZVGTyv443f_mYLNqA__FcxbIJ-cviN8dyIxGN3U=.529fe49f-9e74-4732-96dd-0f5636cb3847@github.com>
Message-ID: <3zEfGGC19yrZzVEohqlTZlT7nKAkMrSAtqFzBxEwD6A=.d83dec40-64f1-476e-a023-8d179c115c56@github.com>

On Thu, 5 Aug 2021 08:43:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Restored "shape" tag and now tackling the bug from the fact that JTextField/JTextARea setbackground works unlike JTextPane/EditorPane.

Now both JTextPane and JEditorPane have white background by default. The changes to the background color are honored.

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

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

From psadhukhan at openjdk.java.net  Tue Aug 10 09:41:11 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 10 Aug 2021 09:41:11 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v6]
In-Reply-To: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
Message-ID: <-AUA3cRM4vuCXWMFHs4-WwE-aizpIM6LCQzDsHiwdZg=.f344b490-c166-4949-bb96-4c1cad3e2d13@github.com>

> The Nimbus look and feel ignores the configured background color of a JTextPane and always uses white. 
> Every other look and feel tested (Metal, Motif, and Windows) correctly honors the configured background color of a JTextPane.
> Issue seems to be in the hardcoded background color in nimbus skin which is rectified via the fix. 
> After this fix, the background color is correctly updated to whatever is being set via JTextPane.setBackground().
> 
> CI all test run is green.

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

  Update test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4930/files
  - new: https://git.openjdk.java.net/jdk/pull/4930/files/31676791..45f3f4c5

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

  Stats: 64 lines in 1 file changed: 14 ins; 34 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4930.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4930/head:pull/4930

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

From psadhukhan at openjdk.java.net  Tue Aug 10 09:41:13 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 10 Aug 2021 09:41:13 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v4]
In-Reply-To: <JYEgjtke-23O9GsntJjN4t1mv2MNBP-UuCd584KAMtQ=.4e36a8af-69fe-43ea-bfd9-62b2a460390a@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <br595_14v6yNbYpG46gMc9HX0Dc5VOPefFxzKGKRTz4=.ceb473fa-3b8f-46b0-8aea-c633f5db68b9@github.com>
 <JYEgjtke-23O9GsntJjN4t1mv2MNBP-UuCd584KAMtQ=.4e36a8af-69fe-43ea-bfd9-62b2a460390a@github.com>
Message-ID: <_vFjs7KhNLwWOEv4M8oVIDUGFUTCbf7x21jEnzH8tFk=.e4c56992-748c-4a16-b2a3-0fa7e084b029@github.com>

On Mon, 9 Aug 2021 15:08:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix
>>  - Merge test
>
> test/jdk/javax/swing/plaf/nimbus/TestNimbusBGColor.java line 25:
> 
>> 23: /*
>> 24:  * @test
>> 25:  * @bug 8058704
> 
> I believe both bugs should be listed.

Done

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

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

From aivanov at openjdk.java.net  Tue Aug 10 11:56:29 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 10 Aug 2021 11:56:29 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v6]
In-Reply-To: <-AUA3cRM4vuCXWMFHs4-WwE-aizpIM6LCQzDsHiwdZg=.f344b490-c166-4949-bb96-4c1cad3e2d13@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <-AUA3cRM4vuCXWMFHs4-WwE-aizpIM6LCQzDsHiwdZg=.f344b490-c166-4949-bb96-4c1cad3e2d13@github.com>
Message-ID: <Kzy7nM0xPk8D3aCtBVGsCD4sauVZUrPbth6ECA6wf9E=.d87dd014-0cca-4486-a076-432dac6e0131@github.com>

On Tue, 10 Aug 2021 09:41:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The Nimbus look and feel ignores the configured background color of a JTextPane and always uses white. 
>> Every other look and feel tested (Metal, Motif, and Windows) correctly honors the configured background color of a JTextPane.
>> Issue seems to be in the hardcoded background color in nimbus skin which is rectified via the fix. 
>> After this fix, the background color is correctly updated to whatever is being set via JTextPane.setBackground().
>> 
>> CI all test run is green.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test

Marked as reviewed by aivanov (Reviewer).

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

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

From serb at openjdk.java.net  Tue Aug 10 19:26:30 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 10 Aug 2021 19:26:30 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v6]
In-Reply-To: <-AUA3cRM4vuCXWMFHs4-WwE-aizpIM6LCQzDsHiwdZg=.f344b490-c166-4949-bb96-4c1cad3e2d13@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <-AUA3cRM4vuCXWMFHs4-WwE-aizpIM6LCQzDsHiwdZg=.f344b490-c166-4949-bb96-4c1cad3e2d13@github.com>
Message-ID: <kH70OowVbF-CK5drw7pp2QtmXd8IXPuwADy88GkSL90=.9f7de668-6cc0-48a9-811d-0198dc690259@github.com>

On Tue, 10 Aug 2021 09:41:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The Nimbus look and feel ignores the configured background color of a JTextPane and always uses white. 
>> Every other look and feel tested (Metal, Motif, and Windows) correctly honors the configured background color of a JTextPane.
>> Issue seems to be in the hardcoded background color in nimbus skin which is rectified via the fix. 
>> After this fix, the background color is correctly updated to whatever is being set via JTextPane.setBackground().
>> 
>> CI all test run is green.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test

This looks fine, please double-check other usages of "shapes and matte" in "skin.laf" probably we have similar bugs in other components?

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

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

From serb at openjdk.java.net  Tue Aug 10 21:09:28 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 10 Aug 2021 21:09:28 GMT
Subject: <Swing Dev> RFR: 8058704: Nimbus does not honor JTextPane
 background color [v6]
In-Reply-To: <-AUA3cRM4vuCXWMFHs4-WwE-aizpIM6LCQzDsHiwdZg=.f344b490-c166-4949-bb96-4c1cad3e2d13@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
 <-AUA3cRM4vuCXWMFHs4-WwE-aizpIM6LCQzDsHiwdZg=.f344b490-c166-4949-bb96-4c1cad3e2d13@github.com>
Message-ID: <sRy3bJoalOS3aeMBb1KqUT_gXNpBtL-xL1_I3ViqMyA=.e7080a22-12dd-436c-829a-f44ebdd13d3a@github.com>

On Tue, 10 Aug 2021 09:41:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The Nimbus look and feel ignores the configured background color of a JTextPane and always uses white. 
>> Every other look and feel tested (Metal, Motif, and Windows) correctly honors the configured background color of a JTextPane.
>> Issue seems to be in the hardcoded background color in nimbus skin which is rectified via the fix. 
>> After this fix, the background color is correctly updated to whatever is being set via JTextPane.setBackground().
>> 
>> CI all test run is green.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test

Marked as reviewed by serb (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Wed Aug 11 09:11:43 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 11 Aug 2021 09:11:43 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'."
Message-ID: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>

The test fails in CI testing citing expected "rededited" but found "redEDITED", which seems to point to fact that either there is a CAPS_LOCK key switched on or some other test did not use SHIFT key corectly  ie, pressed but not released.

Considering many more tests would have failed if CAPS_LOCK is turned on, I tried to find if some tests uses SHIFT key mistakenly and it seems JRadioButton test has press/release order wrong and it uses SHIFT. Rectified that.

In addition, corrected some known CI issues ie waiting after frame is made visible, made frame to centre. Along with that, also modified testcase to check lowercase string. Since the original JDK-4275046 issue is about newly entered text is made part of cell or not, it does not matter if it's in lowercase/uppercase and if such CAPS_LOCK or Shift key problem happens again, this test will not be affected.

CI run for several iterations running these 2 tests one after another in all platforms is green.

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

Commit messages:
 - 8272232: javax/swing/JTable/4275046/bug4275046.java failed with Expected value in the cell: 'rededited' but found 'redEDITED'.

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

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

From kizune at openjdk.java.net  Wed Aug 11 11:30:41 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 11 Aug 2021 11:30:41 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton when
 setBorderPainted(false) is invoked
Message-ID: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>

Initial implementation and a test case.

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

Commit messages:
 - Test fixes
 - 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked

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

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

From psadhukhan at openjdk.java.net  Wed Aug 11 15:19:26 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 11 Aug 2021 15:19:26 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked
In-Reply-To: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
Message-ID: <aJWFIjGXCgEkSiXzwHy8piQVK49hUGzkBhEl9_IWy5Y=.925924f3-18de-47b2-8dd8-2317333b5731@github.com>

On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Initial implementation and a test case.
> 
> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways.

src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 333:

> 331:         final Border border = b.getBorder();
> 332:         if (border instanceof AquaButtonBorder) {
> 333:             ((AquaButtonBorder)border).paintButton(b, g, 0, 0, b.getWidth(), b.getHeight());

Does having 0,0 not create a problem in multiscreen environment?

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

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

From psadhukhan at openjdk.java.net  Wed Aug 11 15:20:26 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 11 Aug 2021 15:20:26 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v2]
In-Reply-To: <vvBcOpFHoAow6pLkn9TSYGd_4kbU7tj2PkOyv69840Q=.e7fd1555-fd4f-45f0-849d-3ead26d38a11@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <vvBcOpFHoAow6pLkn9TSYGd_4kbU7tj2PkOyv69840Q=.e7fd1555-fd4f-45f0-849d-3ead26d38a11@github.com>
Message-ID: <TpPoxb5B4TkWe41dhAN6yFK3aGBnofUPuoP2fHhrv1I=.a91ae713-f1fd-49dd-a83f-45e565e2430b@github.com>

On Mon, 9 Aug 2021 04:21:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
>> Added null check for those cases.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove test
>  - Update javadoc clarification

Any more comment on the modification?

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

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

From kizune at openjdk.java.net  Wed Aug 11 16:58:23 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 11 Aug 2021 16:58:23 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked
In-Reply-To: <aJWFIjGXCgEkSiXzwHy8piQVK49hUGzkBhEl9_IWy5Y=.925924f3-18de-47b2-8dd8-2317333b5731@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <aJWFIjGXCgEkSiXzwHy8piQVK49hUGzkBhEl9_IWy5Y=.925924f3-18de-47b2-8dd8-2317333b5731@github.com>
Message-ID: <7rcRtKuC6P2b8dD_70Q7a3IEf_p2wJ7TGKyNzZXfIKI=.ee7486d9-238b-4c84-a29c-fafe16520253@github.com>

On Wed, 11 Aug 2021 15:16:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Does having 0,0 not create a problem in multiscreen environment?

These coordinates are relative within the Graphics clip of the button so no, that does not cause any issue. Plus, if it would then button painting would be broken already since that's exactly what is passed to the border painter in case when borders are not switched off.

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

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

From serb at openjdk.java.net  Thu Aug 12 02:15:22 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 12 Aug 2021 02:15:22 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'."
In-Reply-To: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
Message-ID: <3S0ZvayHj1OnLfkXfLPwMqcDpmCC97_ycCQJtHVD7Qk=.f21b53d5-f0bb-468c-b9f0-cf8d95692a1f@github.com>

On Wed, 11 Aug 2021 09:03:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The test fails in CI testing citing expected "rededited" but found "redEDITED", which seems to point to fact that either there is a CAPS_LOCK key switched on or some other test did not use SHIFT key corectly  ie, pressed but not released.
> 
> Considering many more tests would have failed if CAPS_LOCK is turned on, I tried to find if some tests uses SHIFT key mistakenly and it seems JRadioButton test has press/release order wrong and it uses SHIFT. Rectified that.
> 
> In addition, corrected some known CI issues ie waiting after frame is made visible, made frame to centre. Along with that, also modified testcase to check lowercase string. Since the original JDK-4275046 issue is about newly entered text is made part of cell or not, it does not matter if it's in lowercase/uppercase and if such CAPS_LOCK or Shift key problem happens again, this test will not be affected.
> 
> CI run for several iterations running these 2 tests one after another in all platforms is green.

I am not sure how it is possible that the shift was pressed while this test tried to type the text, the "redEDITED" mean that initially, the shift was unpressed? Looks like somebody login into the system and accidentally press that button, no?

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

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

From serb at openjdk.java.net  Thu Aug 12 02:18:23 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 12 Aug 2021 02:18:23 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked
In-Reply-To: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
Message-ID: <6S6M60JTVZPGTJJjpiBJ74VJeKSD-c8B-va8Mkt5Llc=.b9675135-6c08-4e87-8090-63f0bf4c5144@github.com>

On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Initial implementation and a test case.
> 
> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways.

Painting the border while the user tries to disable the border via setBorderPainted(false) does not look like a correct solution. The user might be drawn something there already. I remember we discussed a similar a11y bug related to focus and the only possible solution was to draw the focus ourselves or request this feature in the JRS.

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

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

From serb at openjdk.java.net  Thu Aug 12 02:23:30 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 12 Aug 2021 02:23:30 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v2]
In-Reply-To: <vvBcOpFHoAow6pLkn9TSYGd_4kbU7tj2PkOyv69840Q=.e7fd1555-fd4f-45f0-849d-3ead26d38a11@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <vvBcOpFHoAow6pLkn9TSYGd_4kbU7tj2PkOyv69840Q=.e7fd1555-fd4f-45f0-849d-3ead26d38a11@github.com>
Message-ID: <at2zcz92-l3CNwSkuAymwmU8kRSnaivpFbuXwMIamss=.010d56bb-d0ef-4a4d-bc9e-b7d2aaa2eb3e@github.com>

On Mon, 9 Aug 2021 04:21:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
>> Added null check for those cases.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove test
>  - Update javadoc clarification

src/java.desktop/share/classes/javax/swing/JInternalFrame.java line 1308:

> 1306:      * Sets the <code>JDesktopIcon</code> associated with this
> 1307:      * <code>JInternalFrame</code>.
> 1308:      * Setting <code>null</code> icon is unsupported and may throw NPE if used.

The field itself is protected and can be changed by the user.

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

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

From psadhukhan at openjdk.java.net  Thu Aug 12 04:12:25 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 12 Aug 2021 04:12:25 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v2]
In-Reply-To: <at2zcz92-l3CNwSkuAymwmU8kRSnaivpFbuXwMIamss=.010d56bb-d0ef-4a4d-bc9e-b7d2aaa2eb3e@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <vvBcOpFHoAow6pLkn9TSYGd_4kbU7tj2PkOyv69840Q=.e7fd1555-fd4f-45f0-849d-3ead26d38a11@github.com>
 <at2zcz92-l3CNwSkuAymwmU8kRSnaivpFbuXwMIamss=.010d56bb-d0ef-4a4d-bc9e-b7d2aaa2eb3e@github.com>
Message-ID: <mVaiRy_h-iWVozI9AG-TLSNEwFJr0G-wybHTYRy2wwc=.f1f11734-4bdf-4ea1-9f3e-9dd464fa59be@github.com>

On Thu, 12 Aug 2021 02:20:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove test
>>  - Update javadoc clarification
>
> src/java.desktop/share/classes/javax/swing/JInternalFrame.java line 1308:
> 
>> 1306:      * Sets the <code>JDesktopIcon</code> associated with this
>> 1307:      * <code>JInternalFrame</code>.
>> 1308:      * Setting <code>null</code> icon is unsupported and may throw NPE if used.
> 
> The field itself is protected and can be changed by the user.

I guess that is why we are putting up this statement, no so that user thinks twice before making it null? Should we make the field private?

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

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

From psadhukhan at openjdk.java.net  Thu Aug 12 04:16:22 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 12 Aug 2021 04:16:22 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'."
In-Reply-To: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
Message-ID: <gTERskLjOPUxEs2ho38YOdEXWto7RqCVVI-6JbfGzuw=.c089827d-ea77-4de9-9785-e399b1e2c9f6@github.com>

On Wed, 11 Aug 2021 09:03:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The test fails in CI testing citing expected "rededited" but found "redEDITED", which seems to point to fact that either there is a CAPS_LOCK key switched on or some other test did not use SHIFT key corectly  ie, pressed but not released.
> 
> Considering many more tests would have failed if CAPS_LOCK is turned on, I tried to find if some tests uses SHIFT key mistakenly and it seems JRadioButton test has press/release order wrong and it uses SHIFT. Rectified that.
> 
> In addition, corrected some known CI issues ie waiting after frame is made visible, made frame to centre. Along with that, also modified testcase to check lowercase string. Since the original JDK-4275046 issue is about newly entered text is made part of cell or not, it does not matter if it's in lowercase/uppercase and if such CAPS_LOCK or Shift key problem happens again, this test will not be affected.
> 
> CI run for several iterations running these 2 tests one after another in all platforms is green.

I am not sure of the actual reason...But I thought physically accessing the system at this time and pressing CAPS will be less possible at this time of pandemic than some test doing something wrong..
In Anycase, I have taken care of that in the test by checking lowercase so that if CAPS or shift is pressed by anyone/anytest, it willnot affect this test (and as I told original bug is about new characters being part of field, lowercsae/uppercase does not matter)

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

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

From kizune at openjdk.java.net  Thu Aug 12 11:09:26 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 12 Aug 2021 11:09:26 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked
In-Reply-To: <6S6M60JTVZPGTJJjpiBJ74VJeKSD-c8B-va8Mkt5Llc=.b9675135-6c08-4e87-8090-63f0bf4c5144@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <6S6M60JTVZPGTJJjpiBJ74VJeKSD-c8B-va8Mkt5Llc=.b9675135-6c08-4e87-8090-63f0bf4c5144@github.com>
Message-ID: <cPlZw_h78GbEt44XSlxZ-oVg3AgbneBZO-Xe0EUodLc=.34f67352-9ddd-4c8b-88c0-e49c8203cbfb@github.com>

On Thu, 12 Aug 2021 02:15:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Painting the border while the user tries to disable the border via setBorderPainted(false) does not look like a correct solution. The user might be drawn something there already. I remember we discussed a similar a11y bug related to focus and the only possible solution was to draw the focus ourselves or request this feature in the JRS.

There is no other way on Mac OS to indicate focused button but the glowing border. The same situation happens on Motif L&F - the only way to differentiate focused button from unfocused is by the border and in Motif - just as in Aqua - once border painting is disabled there is no way to tell if button is focused or not. User might draw something but if button becomes focused the focus indication will be drawn over it. If focus indicator disrupts user's painting on top of the button insets area user can always disable focus painting on such a component deliberately by calling JButton.setFocusPainted(boolean)

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

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

From serb at openjdk.java.net  Thu Aug 12 18:20:23 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 12 Aug 2021 18:20:23 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked
In-Reply-To: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
Message-ID: <7JolkPWVae9EMn_gAZuzIXB-PqUWGqH79SrivV7KC8A=.53bff0f3-27c0-471b-b0ef-8c86e4af8359@github.com>

On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Initial implementation and a test case.
> 
> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways.

The motif L&F is not supported for a while and is ready to remove, so that L&F behavior cannot be referenced as a proper way to work.

The focused button on macOS is highlighted by the "blue" rounded rectangle. There are two choices: draw this rectangle ourselves or request this feature from the JRS. But the change should not break the behavior of the "setBorderPainted(false)".

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

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

From serb at openjdk.java.net  Thu Aug 12 18:29:24 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 12 Aug 2021 18:29:24 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'."
In-Reply-To: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
Message-ID: <kSMNFk_7rPZbJj1uNjVMQZeQdSjZhyKfcrbpmQgxkBc=.05c4ed26-b6a6-461e-8d48-27914806f708@github.com>

On Wed, 11 Aug 2021 09:03:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The test fails in CI testing citing expected "rededited" but found "redEDITED", which seems to point to fact that either there is a CAPS_LOCK key switched on or some other test did not use SHIFT key corectly  ie, pressed but not released.
> 
> Considering many more tests would have failed if CAPS_LOCK is turned on, I tried to find if some tests uses SHIFT key mistakenly and it seems JRadioButton test has press/release order wrong and it uses SHIFT. Rectified that.
> 
> In addition, corrected some known CI issues ie waiting after frame is made visible, made frame to centre. Along with that, also modified testcase to check lowercase string. Since the original JDK-4275046 issue is about newly entered text is made part of cell or not, it does not matter if it's in lowercase/uppercase and if such CAPS_LOCK or Shift key problem happens again, this test will not be affected.
> 
> CI run for several iterations running these 2 tests one after another in all platforms is green.

Marked as reviewed by serb (Reviewer).

Yes this cleanup looks fine, I just would like to highlight that the actual root cause of this issue is one of:
 - Someone presses the buttons while the test is executed
 - A few tests are executed in parallel(bug in jtreg or mach5?)
 - Bug in KVM which generates this button press.
All of them are more important than the current cleanup, and I suggest investigating those possibilities on the lab_support+client_team chats

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

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

From serb at openjdk.java.net  Thu Aug 12 18:47:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 12 Aug 2021 18:47:25 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked
In-Reply-To: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
Message-ID: <uCsY2EH2xvipQ8Th0cF4_V8fPdYVqScAt_5AezyIhNQ=.d31f048d-4deb-4c8b-af92-a34bb0eefb53@github.com>

On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Initial implementation and a test case.
> 
> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways.

BTW this issue was known for a long time, and even the spec was updated specifically for it:
https://bugs.openjdk.java.net/browse/JDK-4416026

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

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

From serb at openjdk.java.net  Thu Aug 12 18:54:24 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 12 Aug 2021 18:54:24 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked
In-Reply-To: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
Message-ID: <0X2hUh3oRZws_7VsKtvtCxGet3P-pgy0gEWCtIHPZkk=.f3586214-d01e-4232-9791-93ca72c943b6@github.com>

On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Initial implementation and a test case.
> 
> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways.

Probably solution should be somewhere similar to this one:
https://github.com/openjdk/jdk/commit/440db35e

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

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

From serb at openjdk.java.net  Thu Aug 12 22:34:24 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 12 Aug 2021 22:34:24 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v2]
In-Reply-To: <mVaiRy_h-iWVozI9AG-TLSNEwFJr0G-wybHTYRy2wwc=.f1f11734-4bdf-4ea1-9f3e-9dd464fa59be@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <vvBcOpFHoAow6pLkn9TSYGd_4kbU7tj2PkOyv69840Q=.e7fd1555-fd4f-45f0-849d-3ead26d38a11@github.com>
 <at2zcz92-l3CNwSkuAymwmU8kRSnaivpFbuXwMIamss=.010d56bb-d0ef-4a4d-bc9e-b7d2aaa2eb3e@github.com>
 <mVaiRy_h-iWVozI9AG-TLSNEwFJr0G-wybHTYRy2wwc=.f1f11734-4bdf-4ea1-9f3e-9dd464fa59be@github.com>
Message-ID: <vMiAF4DFnCE-tNlvPTsMDG4iPxZ2yPJketIasGLx2ac=.2226513a-2ce3-4305-83da-ef1b10ee97dc@github.com>

On Thu, 12 Aug 2021 04:09:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JInternalFrame.java line 1308:
>> 
>>> 1306:      * Sets the <code>JDesktopIcon</code> associated with this
>>> 1307:      * <code>JInternalFrame</code>.
>>> 1308:      * Setting <code>null</code> icon is unsupported and may throw NPE if used.
>> 
>> The field itself is protected and can be changed by the user.
>
> I guess that is why we are putting up this statement, no so that user thinks twice before making it null? Should we make the field private?

We cannot make it private, we can only update the spec there as well.

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

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

From psadhukhan at openjdk.java.net  Fri Aug 13 04:34:52 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 13 Aug 2021 04:34:52 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v3]
In-Reply-To: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
Message-ID: <PbaZFYp_makXd2CG_F2ic7MnuETGyUobZEv8SzlTL0w=.b33e4d07-f4a3-4132-be4d-fbac989f24d2@github.com>

> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
> Added null check for those cases.

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

  Spec clarification

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4989/files
  - new: https://git.openjdk.java.net/jdk/pull/4989/files/0c96a6e3..f69c24a1

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

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

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

From psadhukhan at openjdk.java.net  Fri Aug 13 04:34:52 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 13 Aug 2021 04:34:52 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v2]
In-Reply-To: <vMiAF4DFnCE-tNlvPTsMDG4iPxZ2yPJketIasGLx2ac=.2226513a-2ce3-4305-83da-ef1b10ee97dc@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <vvBcOpFHoAow6pLkn9TSYGd_4kbU7tj2PkOyv69840Q=.e7fd1555-fd4f-45f0-849d-3ead26d38a11@github.com>
 <at2zcz92-l3CNwSkuAymwmU8kRSnaivpFbuXwMIamss=.010d56bb-d0ef-4a4d-bc9e-b7d2aaa2eb3e@github.com>
 <mVaiRy_h-iWVozI9AG-TLSNEwFJr0G-wybHTYRy2wwc=.f1f11734-4bdf-4ea1-9f3e-9dd464fa59be@github.com>
 <vMiAF4DFnCE-tNlvPTsMDG4iPxZ2yPJketIasGLx2ac=.2226513a-2ce3-4305-83da-ef1b10ee97dc@github.com>
Message-ID: <ED5ho3ly03koxjZzLsp07i7pA-udF7qADlY88LkmBH8=.070dbb4e-c989-4661-9f30-9dc16198a088@github.com>

On Thu, 12 Aug 2021 22:31:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I guess that is why we are putting up this statement, no so that user thinks twice before making it null? Should we make the field private?
>
> We cannot make it private, we can only update the spec there as well.

done

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

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

From psadhukhan at openjdk.java.net  Fri Aug 13 05:19:31 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 13 Aug 2021 05:19:31 GMT
Subject: <Swing Dev> Integrated: 8058704: Nimbus does not honor JTextPane
 background color
In-Reply-To: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
References: <sxFc1H2HNFUgDQx9JHhKWGPEMirgcfgZKgqMHwGHbo8=.265f43c4-d60b-4eab-a1e6-9450df1a62e1@github.com>
Message-ID: <9s6wipYQqE1DCdxF9_r1P7_z2Hq9K8tH306E_2xu6WY=.8cbec067-05e8-4461-b580-10ffaaae48f3@github.com>

On Thu, 29 Jul 2021 11:44:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The Nimbus look and feel ignores the configured background color of a JTextPane and always uses white. 
> Every other look and feel tested (Metal, Motif, and Windows) correctly honors the configured background color of a JTextPane.
> Issue seems to be in the hardcoded background color in nimbus skin which is rectified via the fix. 
> After this fix, the background color is correctly updated to whatever is being set via JTextPane.setBackground().
> 
> CI all test run is green.

This pull request has now been integrated.

Changeset: 0c4be76f
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0c4be76f7ff3cd5e32c8eb4e04e6986d5f33fbee
Stats:     114 lines in 2 files changed: 112 ins; 0 del; 2 mod

8058704: Nimbus does not honor JTextPane background color
6789980: JEditorPane background color not honored with Nimbus L&F

Reviewed-by: aivanov, serb

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

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

From kizune at openjdk.java.net  Fri Aug 13 06:06:49 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 13 Aug 2021 06:06:49 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v2]
In-Reply-To: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
Message-ID: <JmGtozGATQUHzXVwq_CnX2VbCgmanJ3iwE9wHd84WjA=.b7f8eeea-70b7-472e-98a5-97afa4c98ad6@github.com>

> Initial implementation and a test case.
> 
> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways.

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

  Changed to only paing focus ring without the entire border painting

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5082/files
  - new: https://git.openjdk.java.net/jdk/pull/5082/files/d4b21edc..bda91782

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

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

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

From kizune at openjdk.java.net  Fri Aug 13 06:06:49 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 13 Aug 2021 06:06:49 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked
In-Reply-To: <7JolkPWVae9EMn_gAZuzIXB-PqUWGqH79SrivV7KC8A=.53bff0f3-27c0-471b-b0ef-8c86e4af8359@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <7JolkPWVae9EMn_gAZuzIXB-PqUWGqH79SrivV7KC8A=.53bff0f3-27c0-471b-b0ef-8c86e4af8359@github.com>
Message-ID: <WfFmX5tpRglHzq1nt6XZ3Z4qGgKujKeMFY8zBfGXFvw=.7a043a38-f2d2-4f0c-9eac-ec24df9d2caf@github.com>

On Thu, 12 Aug 2021 18:17:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> There are two choices: draw this rectangle ourselves or request this feature from the JRS.

There i pushed the code that only draws the focus ring without the rest of the border.

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

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

From kizune at openjdk.java.net  Fri Aug 13 06:18:49 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 13 Aug 2021 06:18:49 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v3]
In-Reply-To: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
Message-ID: <zQz0tGUQKfw8CcHdARvh2Vp0CGQ9TZdNYY40Xd_bvO4=.a2b995ef-6512-4591-b4dd-1b41d62ba89b@github.com>

> Initial implementation and a test case.
> 
> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways.

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

  Update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5082/files
  - new: https://git.openjdk.java.net/jdk/pull/5082/files/bda91782..fefcd37d

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

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

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

From psadhukhan at openjdk.java.net  Fri Aug 13 12:18:23 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 13 Aug 2021 12:18:23 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v3]
In-Reply-To: <zQz0tGUQKfw8CcHdARvh2Vp0CGQ9TZdNYY40Xd_bvO4=.a2b995ef-6512-4591-b4dd-1b41d62ba89b@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <zQz0tGUQKfw8CcHdARvh2Vp0CGQ9TZdNYY40Xd_bvO4=.a2b995ef-6512-4591-b4dd-1b41d62ba89b@github.com>
Message-ID: <FQcBLbVVpfUcHCmjDRWsuUrEGn5YKN1kXDfeLrE_gDw=.454648c7-5ed1-413e-92d6-d0a817ae4f2a@github.com>

On Fri, 13 Aug 2021 06:18:49 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Initial implementation and a test case.
>> 
>> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 338:

> 336: 
> 337:         }
> 338:         Color ringColor = UIManager.getLookAndFeelDefaults().getColor("Focus.color");

I guess we normally call like this in Basic L&F which is extended by different L&Fs so that it will pick up the defaults from the particular L&F in question, otherwise UIManager.getColor(). should suffice as Focus.color is defined in AquaLookAndFeel. 
But I am not sure with this hardcoded values..Can't we leverage viewRect or textRect to get the required coordinates?

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

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

From kizune at openjdk.java.net  Fri Aug 13 19:17:13 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 13 Aug 2021 19:17:13 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v4]
In-Reply-To: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
Message-ID: <cNuWSI3hDvi2hVL6jZVbvOqCo4jvHp_oDS-FsUeDeVI=.8acdad17-0c62-45e7-a48c-45c7ff8c28bd@github.com>

> Initial implementation and a test case.
> 
> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways.

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

  Remove getLookAndFeelDefaults() call

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5082/files
  - new: https://git.openjdk.java.net/jdk/pull/5082/files/fefcd37d..df34ab0b

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

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

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

From kizune at openjdk.java.net  Fri Aug 13 19:26:29 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 13 Aug 2021 19:26:29 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v3]
In-Reply-To: <FQcBLbVVpfUcHCmjDRWsuUrEGn5YKN1kXDfeLrE_gDw=.454648c7-5ed1-413e-92d6-d0a817ae4f2a@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <zQz0tGUQKfw8CcHdARvh2Vp0CGQ9TZdNYY40Xd_bvO4=.a2b995ef-6512-4591-b4dd-1b41d62ba89b@github.com>
 <FQcBLbVVpfUcHCmjDRWsuUrEGn5YKN1kXDfeLrE_gDw=.454648c7-5ed1-413e-92d6-d0a817ae4f2a@github.com>
Message-ID: <O5USIoLl-Zy-fLcJW4TzxjxFHOajhRed3pyW-8Apc_s=.6d69bd7b-2480-4335-b45d-44a8a62e6bd9@github.com>

On Fri, 13 Aug 2021 12:15:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> UIManager.getColor(). should suffice

Fixed.

> But I am not sure with this hardcoded values..Can't we leverage viewRect or textRect to get the required coordinates?

viewRect is set to be exactly (0, 0, b.width, b.height). Insets are buried deep inside JRS classes and used as hardcoded valued, i can not  get them from there and both textRect and iconRect are not representing what needs to be drawn to be consistent with the way OS draws focus. Plus they are being initialized only later down the code and at the time of this call they are empty. Not that it would matter.

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

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

From prr at openjdk.java.net  Sat Aug 14 18:54:23 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 14 Aug 2021 18:54:23 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v3]
In-Reply-To: <PbaZFYp_makXd2CG_F2ic7MnuETGyUobZEv8SzlTL0w=.b33e4d07-f4a3-4132-be4d-fbac989f24d2@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <PbaZFYp_makXd2CG_F2ic7MnuETGyUobZEv8SzlTL0w=.b33e4d07-f4a3-4132-be4d-fbac989f24d2@github.com>
Message-ID: <16FHZi0ahiUyGYEh8k9UFzSUsOAMP0Hz_CPrJsLGPWs=.b39a6faf-1ad8-40d8-ae28-dae856e4a34f@github.com>

On Fri, 13 Aug 2021 04:34:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
>> Added null check for those cases.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spec clarification

JInternalFrame.JDesktopIcon seems to be a bit of a mess overall.

The class doc :
https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/javax/swing/JInternalFrame.JDesktopIcon.html
says :

This component represents an iconified version of a JInternalFrame. This API should NOT BE USED by Swing applications,
as it will go away in future versions of Swing as its functionality is moved into JInternalFrame. ...
If an application wants to display a desktop icon, it should create a JInternalFrame instance and iconify it.

I am not sure what that implies -iconification of a JInternalFrame isn't the same thing as setting it.

Are the setter and getter there only for the benefit of a L&F and really should not be public at all ?

The words "may" throw an NPE are not clear about when - I guess we aren't throwing an NPE right
at the moment you set it but aybe if you iconify the JInternalFrame it'll happen later ?
That's not great.

We should either prevent null being set or catch all those nulls.

And what if it is null some action needs to be taken - as Shannon wrote - "whatever that is"

On the basis that we need an icon else more problems occur I think we should just prevent it
and take the incompatibility of throwing NPE immediately  you try to set null.
Folks who are doing it are likely seeing random exceptions anyway at a later time !

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

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

From prr at openjdk.java.net  Sat Aug 14 19:17:22 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 14 Aug 2021 19:17:22 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'."
In-Reply-To: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
Message-ID: <dEClr_neMK_kATfN8e2wtn3K6D9z7O7UCBzfHTel0E8=.b455a0df-af21-41ba-a71a-67848ac7e07f@github.com>

On Wed, 11 Aug 2021 09:03:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The test fails in CI testing citing expected "rededited" but found "redEDITED", which seems to point to fact that either there is a CAPS_LOCK key switched on or some other test did not use SHIFT key corectly  ie, pressed but not released.
> 
> Considering many more tests would have failed if CAPS_LOCK is turned on, I tried to find if some tests uses SHIFT key mistakenly and it seems JRadioButton test has press/release order wrong and it uses SHIFT. Rectified that.
> 
> In addition, corrected some known CI issues ie waiting after frame is made visible, made frame to centre. Along with that, also modified testcase to check lowercase string. Since the original JDK-4275046 issue is about newly entered text is made part of cell or not, it does not matter if it's in lowercase/uppercase and if such CAPS_LOCK or Shift key problem happens again, this test will not be affected.
> 
> CI run for several iterations running these 2 tests one after another in all platforms is green.

Someone presses the buttons while the test is executed
    A few tests are executed in parallel(bug in jtreg or mach5?)
    Bug in KVM which generates this button press.
    All of them are more important than the current cleanup, and I suggest investigating those possibilities on the lab_support+client_team chats

I don't believe any of the scenarios.


As you well know these headful tests will be re-run 2 more times if they fail.

It seems improbable some one was sitting there waiting to jump on the keyboard and interfere

with the test at the exact moment 3 different times.

And the same for a KVM error.

As for in parallel we'd have hundreds of failures in such a case and we do not see that

And looking at the test log for when this failed 4 tests in total failed and they all have similar problems

===

java\awt\SplashScreen\MultiResolutionSplash\MultiResolutionSplashTest.java

Execution failed: `main' threw exception: java.lang.RuntimeException: Focus is lost! Expected 'ab' got 'AB'.

---

java/awt/Toolkit/RealSync/Test.java

Test failed: testType
[2021-08-10T04:06:59,103Z] Cause: Expected 'a' got 'A'.

----

javax/swing/JFileChooser/8041694/bug8041694.java

java.lang.RuntimeException: The selected directory name is not the expected 'd ' but 'D '.

======

Moreover this test isn't even the first that failed - that was MultiResolutionSplashTest - so the problem was
already there

So some test left SHIFT pressed. I can imagine a timing problem where a test was exited before it managed to release.

I am curious how Prasanta decided test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java might be the problem

It was executed long after these tests were already failing.

So the root cause test is not yet identified.

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

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

From serb at openjdk.java.net  Sat Aug 14 22:16:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 14 Aug 2021 22:16:25 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'."
In-Reply-To: <dEClr_neMK_kATfN8e2wtn3K6D9z7O7UCBzfHTel0E8=.b455a0df-af21-41ba-a71a-67848ac7e07f@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
 <dEClr_neMK_kATfN8e2wtn3K6D9z7O7UCBzfHTel0E8=.b455a0df-af21-41ba-a71a-67848ac7e07f@github.com>
Message-ID: <CQtyNXJiEFd4P4blqCKNHqt_GZEUpWKakM9AsPQpG00=.093674d5-ad4c-4979-95f9-8e54009e6dc8@github.com>

On Sat, 14 Aug 2021 19:14:06 GMT, Phil Race <prr at openjdk.org> wrote:

> I don't believe any of the scenarios.
> 
> As you well know these headful tests will be re-run 2 more times if they fail.

But we know the log information only for the last failure, probably the button was pressed only for the last rerun. And according to this log, the shift or capslock was pressed during the test case execution. How it could be?

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

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

From serb at openjdk.java.net  Sat Aug 14 22:18:23 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 14 Aug 2021 22:18:23 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v3]
In-Reply-To: <16FHZi0ahiUyGYEh8k9UFzSUsOAMP0Hz_CPrJsLGPWs=.b39a6faf-1ad8-40d8-ae28-dae856e4a34f@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <PbaZFYp_makXd2CG_F2ic7MnuETGyUobZEv8SzlTL0w=.b33e4d07-f4a3-4132-be4d-fbac989f24d2@github.com>
 <16FHZi0ahiUyGYEh8k9UFzSUsOAMP0Hz_CPrJsLGPWs=.b39a6faf-1ad8-40d8-ae28-dae856e4a34f@github.com>
Message-ID: <mNeqJKn_NKeBYo4YIWskKa-BDtP2X0AJC0c8miX39tU=.1b6731e5-dc79-4c6d-b72e-f3e1a16e0af5@github.com>

On Sat, 14 Aug 2021 18:50:58 GMT, Phil Race <prr at openjdk.org> wrote:

> Folks who are doing it are likely seeing random exceptions anyway at a later time !

What we will do if the field will be set to null directly? Throw NPE at any point later when we will found null?

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

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

From prr at openjdk.java.net  Sat Aug 14 22:34:20 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 14 Aug 2021 22:34:20 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'."
In-Reply-To: <CQtyNXJiEFd4P4blqCKNHqt_GZEUpWKakM9AsPQpG00=.093674d5-ad4c-4979-95f9-8e54009e6dc8@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
 <dEClr_neMK_kATfN8e2wtn3K6D9z7O7UCBzfHTel0E8=.b455a0df-af21-41ba-a71a-67848ac7e07f@github.com>
 <CQtyNXJiEFd4P4blqCKNHqt_GZEUpWKakM9AsPQpG00=.093674d5-ad4c-4979-95f9-8e54009e6dc8@github.com>
Message-ID: <mS8FzNv2fQggqIwce_hOgxp9HW0e9zSR_TT6WU91ZTs=.7239794a-de49-4dfb-b696-c38df2466ff7@github.com>

On Sat, 14 Aug 2021 22:12:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I don't believe any of the scenarios.
> > As you well know these headful tests will be re-run 2 more times if they fail.
> 
> But we know the log information only for the last failure, probably the button was pressed only for the last rerun. And according to this log, the shift or capslock was pressed during the test case execution. How it could be?

Not true ! stdout has everything ! All runs.Just a summary for a pass but all the data for a failure In one contoguous log file so there is no question.

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

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

From prr at openjdk.java.net  Sat Aug 14 22:40:29 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 14 Aug 2021 22:40:29 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v3]
In-Reply-To: <mNeqJKn_NKeBYo4YIWskKa-BDtP2X0AJC0c8miX39tU=.1b6731e5-dc79-4c6d-b72e-f3e1a16e0af5@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <PbaZFYp_makXd2CG_F2ic7MnuETGyUobZEv8SzlTL0w=.b33e4d07-f4a3-4132-be4d-fbac989f24d2@github.com>
 <16FHZi0ahiUyGYEh8k9UFzSUsOAMP0Hz_CPrJsLGPWs=.b39a6faf-1ad8-40d8-ae28-dae856e4a34f@github.com>
 <mNeqJKn_NKeBYo4YIWskKa-BDtP2X0AJC0c8miX39tU=.1b6731e5-dc79-4c6d-b72e-f3e1a16e0af5@github.com>
Message-ID: <xZqmyvZyu38SvYODuGbjrh0p88HdCvHhc77XyBYu6Ts=.809c1c01-78aa-4914-8928-3a84992de740@github.com>

On Sat, 14 Aug 2021 22:15:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Folks who are doing it are likely seeing random exceptions anyway at a later time !
> 
> What we will do if the field will be set to null directly? Throw NPE at any point later when we will found null?

The field is protected. If a subclasser wants to destroy the functionality of a class they are subclassing there are lots of ways they can do that. Just add advisory doc on the protected field too.

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

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

From serb at openjdk.java.net  Sat Aug 14 22:40:29 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 14 Aug 2021 22:40:29 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v3]
In-Reply-To: <xZqmyvZyu38SvYODuGbjrh0p88HdCvHhc77XyBYu6Ts=.809c1c01-78aa-4914-8928-3a84992de740@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <PbaZFYp_makXd2CG_F2ic7MnuETGyUobZEv8SzlTL0w=.b33e4d07-f4a3-4132-be4d-fbac989f24d2@github.com>
 <16FHZi0ahiUyGYEh8k9UFzSUsOAMP0Hz_CPrJsLGPWs=.b39a6faf-1ad8-40d8-ae28-dae856e4a34f@github.com>
 <mNeqJKn_NKeBYo4YIWskKa-BDtP2X0AJC0c8miX39tU=.1b6731e5-dc79-4c6d-b72e-f3e1a16e0af5@github.com>
 <xZqmyvZyu38SvYODuGbjrh0p88HdCvHhc77XyBYu6Ts=.809c1c01-78aa-4914-8928-3a84992de740@github.com>
Message-ID: <67gDLZleu07duenwhCnG5sOB7Y6_SonZ500joQDOzKI=.64f49fbe-fa10-49f6-a8cc-1610661002e8@github.com>

On Sat, 14 Aug 2021 22:34:37 GMT, Phil Race <prr at openjdk.org> wrote:

> Just add advisory doc on the protected field too.

ok, this is part of what this change do, probably the text should be rephrased there?

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

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

From serb at openjdk.java.net  Sun Aug 15 05:07:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 15 Aug 2021 05:07:14 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'."
In-Reply-To: <mS8FzNv2fQggqIwce_hOgxp9HW0e9zSR_TT6WU91ZTs=.7239794a-de49-4dfb-b696-c38df2466ff7@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
 <dEClr_neMK_kATfN8e2wtn3K6D9z7O7UCBzfHTel0E8=.b455a0df-af21-41ba-a71a-67848ac7e07f@github.com>
 <CQtyNXJiEFd4P4blqCKNHqt_GZEUpWKakM9AsPQpG00=.093674d5-ad4c-4979-95f9-8e54009e6dc8@github.com>
 <mS8FzNv2fQggqIwce_hOgxp9HW0e9zSR_TT6WU91ZTs=.7239794a-de49-4dfb-b696-c38df2466ff7@github.com>
Message-ID: <T1tD-_pNHUyKE-Nls8EQtU4F-KfRqKfsa-xZ8PvCI6g=.64260626-8c90-4536-85a0-7bc6e63bf8bf@github.com>

On Sat, 14 Aug 2021 22:31:42 GMT, Phil Race <prr at openjdk.org> wrote:

> Not true ! stdout has everything ! All runs.Just a summary for a pass but all the data for a failure In one contoguous log file so there is no question.

Ok, so now we know that: according to this "contiguous log", the shift or capslock was pressed during the test case execution a few times in a row. How it could be?"

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

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

From serb at openjdk.java.net  Sun Aug 15 05:12:32 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 15 Aug 2021 05:12:32 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'."
In-Reply-To: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
Message-ID: <KCvr7IB3Ibl3Gict5V9hrJSJYPKmpF3uol9I3PT_5PU=.5d2c7520-8d24-41ae-a6e7-842d7c18a0d7@github.com>

On Wed, 11 Aug 2021 09:03:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The test fails in CI testing citing expected "rededited" but found "redEDITED", which seems to point to fact that either there is a CAPS_LOCK key switched on or some other test did not use SHIFT key corectly  ie, pressed but not released.
> 
> Considering many more tests would have failed if CAPS_LOCK is turned on, I tried to find if some tests uses SHIFT key mistakenly and it seems JRadioButton test has press/release order wrong and it uses SHIFT. Rectified that.
> 
> In addition, corrected some known CI issues ie waiting after frame is made visible, made frame to centre. Along with that, also modified testcase to check lowercase string. Since the original JDK-4275046 issue is about newly entered text is made part of cell or not, it does not matter if it's in lowercase/uppercase and if such CAPS_LOCK or Shift key problem happens again, this test will not be affected.
> 
> CI run for several iterations running these 2 tests one after another in all platforms is green.

Actually, the answer is simple. The test edits the cell in the table, the initial text in that cell is "red", the test appended the "edited" text. Since the capslock was enabled the actual result became "redEDITED".

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

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

From kizune at openjdk.java.net  Sun Aug 15 11:31:30 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sun, 15 Aug 2021 11:31:30 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked
In-Reply-To: <0X2hUh3oRZws_7VsKtvtCxGet3P-pgy0gEWCtIHPZkk=.f3586214-d01e-4232-9791-93ca72c943b6@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <0X2hUh3oRZws_7VsKtvtCxGet3P-pgy0gEWCtIHPZkk=.f3586214-d01e-4232-9791-93ca72c943b6@github.com>
Message-ID: <A3JoWYW4AIz7XmEbFowgrWN7wSIn_t43A5o8U8K6Po8=.ab91db44-9056-49de-95a1-9ff2c821bc78@github.com>

On Thu, 12 Aug 2021 18:51:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Probably solution should be somewhere similar to this one

That works for icons but for text it would create a terrible mess, text with glow effect will be unreadable. I made code that draws the focus ring instead without drawing the rest of the border.

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

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

From prr at openjdk.java.net  Sun Aug 15 16:29:39 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 15 Aug 2021 16:29:39 GMT
Subject: <Swing Dev> RFR: 8272491: Problem list
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java on macos
Message-ID: <E3g-bFvI2woZvts1r3RV4PvAQ8lKfoyQ5J77jG4CWSk=.274713d9-56e3-4613-b1fd-b3417093abe3@github.com>

This will fail regularly so problem list it.

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

Commit messages:
 - 8272491: Problem list javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java on macos

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

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

From pbansal at openjdk.java.net  Sun Aug 15 16:43:26 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sun, 15 Aug 2021 16:43:26 GMT
Subject: <Swing Dev> RFR: 8272491: Problem list
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java on macos
In-Reply-To: <E3g-bFvI2woZvts1r3RV4PvAQ8lKfoyQ5J77jG4CWSk=.274713d9-56e3-4613-b1fd-b3417093abe3@github.com>
References: <E3g-bFvI2woZvts1r3RV4PvAQ8lKfoyQ5J77jG4CWSk=.274713d9-56e3-4613-b1fd-b3417093abe3@github.com>
Message-ID: <1-PdtKfKMtJ8Q4j0sU-2wTV3lzL80Kpx8CFH8PCq3Jo=.66db6093-ce51-4898-b75d-9ffcc2dd15e1@github.com>

On Sun, 15 Aug 2021 16:23:52 GMT, Phil Race <prr at openjdk.org> wrote:

> This will fail regularly so problem list it.

Marked as reviewed by pbansal (Reviewer).

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

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

From prr at openjdk.java.net  Sun Aug 15 16:54:30 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 15 Aug 2021 16:54:30 GMT
Subject: <Swing Dev> Integrated: 8272491: Problem list
 javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java on macos
In-Reply-To: <E3g-bFvI2woZvts1r3RV4PvAQ8lKfoyQ5J77jG4CWSk=.274713d9-56e3-4613-b1fd-b3417093abe3@github.com>
References: <E3g-bFvI2woZvts1r3RV4PvAQ8lKfoyQ5J77jG4CWSk=.274713d9-56e3-4613-b1fd-b3417093abe3@github.com>
Message-ID: <ES99TD9p9uPyJdg8HmZ3wb92BbBUuQnL0oSV-j44LuQ=.000eac54-5462-4579-b294-74193e605414@github.com>

On Sun, 15 Aug 2021 16:23:52 GMT, Phil Race <prr at openjdk.org> wrote:

> This will fail regularly so problem list it.

This pull request has now been integrated.

Changeset: 6a5241c3
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6a5241c3adfd3ba886e469156dea56ed5b9673ff
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8272491: Problem list javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java on macos

Reviewed-by: pbansal

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

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

From serb at openjdk.java.net  Mon Aug 16 02:19:28 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 16 Aug 2021 02:19:28 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v4]
In-Reply-To: <cNuWSI3hDvi2hVL6jZVbvOqCo4jvHp_oDS-FsUeDeVI=.8acdad17-0c62-45e7-a48c-45c7ff8c28bd@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <cNuWSI3hDvi2hVL6jZVbvOqCo4jvHp_oDS-FsUeDeVI=.8acdad17-0c62-45e7-a48c-45c7ff8c28bd@github.com>
Message-ID: <7LY1Ss4dbeqC0gRlccImv8WTfFBz3GbVFsehmXYZMX0=.7eda8ed7-3d51-4dd8-87c6-ff0282711188@github.com>

On Fri, 13 Aug 2021 19:17:13 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Initial implementation and a test case.
>> 
>> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove getLookAndFeelDefaults() call

Can you please create of blend of two images, one for common focused button(with border) and another one w/o. Just to check that the border is drawn in the similar location and using similar "shape".

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

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

From psadhukhan at openjdk.java.net  Mon Aug 16 04:30:26 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 16 Aug 2021 04:30:26 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'."
In-Reply-To: <dEClr_neMK_kATfN8e2wtn3K6D9z7O7UCBzfHTel0E8=.b455a0df-af21-41ba-a71a-67848ac7e07f@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
 <dEClr_neMK_kATfN8e2wtn3K6D9z7O7UCBzfHTel0E8=.b455a0df-af21-41ba-a71a-67848ac7e07f@github.com>
Message-ID: <_T_e0nCc99b7vcWAHbsdgg_7o2oK3r52aq1WENzwoxc=.9f622e94-585a-401a-a2ef-d41ad9be4b3f@github.com>

On Sat, 14 Aug 2021 19:14:06 GMT, Phil Race <prr at openjdk.org> wrote:

>  am curious how Prasanta decided test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java might be the problem

As I told in initial explanation, I thought it will be either CAPS_LOCK key switched on or some other test did not use SHIFT key corectly ie, pressed but not released. I could not do anything about if someone press CAPS_LOCK so I search for VK_SHIFT being used in all javax/swing reg test and I found this test bug8033699.java is having a wrong order. I am not saying this was the root cause but it needs rectifying, I presume..
Also, the fix I proposed will not have any impact on this test testing 4275046 fix because of the reason mentioned above (original bug is about new characters being part of field, lowercsae/uppercase does not matter)

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

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

From psadhukhan at openjdk.java.net  Mon Aug 16 04:39:27 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 16 Aug 2021 04:39:27 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v3]
In-Reply-To: <16FHZi0ahiUyGYEh8k9UFzSUsOAMP0Hz_CPrJsLGPWs=.b39a6faf-1ad8-40d8-ae28-dae856e4a34f@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <PbaZFYp_makXd2CG_F2ic7MnuETGyUobZEv8SzlTL0w=.b33e4d07-f4a3-4132-be4d-fbac989f24d2@github.com>
 <16FHZi0ahiUyGYEh8k9UFzSUsOAMP0Hz_CPrJsLGPWs=.b39a6faf-1ad8-40d8-ae28-dae856e4a34f@github.com>
Message-ID: <5Q8sBOlCSBkwppm0ztZgX5x6ulm6AldAaizQQOxgthk=.b319c144-bf9f-49fe-bca1-b915b0d700ab@github.com>

On Sat, 14 Aug 2021 18:50:58 GMT, Phil Race <prr at openjdk.org> wrote:

> We should either prevent null being set or catch all those nulls.

I did that in 1st iteration of this PR..https://github.com/openjdk/jdk/pull/4989/files/2a2ab50ded3305f3a9e0f01e90417b484a0b2db4 

@prrace Should I bring that fix back?

> Just add advisory doc on the protected field too.

> ok, this is part of what this change do, probably the text should be rephrased there?
What should be the advisory phrase? Will the text I have added in the protected field doc not suffice?

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

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

From pbansal at openjdk.java.net  Mon Aug 16 09:25:38 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 16 Aug 2021 09:25:38 GMT
Subject: <Swing Dev> RFR: 8272148: JDesktopPane:getComponentCount() returns
 one extra than expected with GTKLookAndFeel
Message-ID: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>

A container may include few default components as children, which are added to it during creation. Due to this, calling function getChildrenCount on a new created instance may return non zero value. This behaviour may vary according to L&F also, as some L&F may add some default components to a container, but other L&F may choose not to do so.

The current bugs reports that this behaviour looks suspicious as it is expected that a newly created container will have zero  children.

Current specification is not clear on this whether it is allowed for a container to contain default components or not. The fix make changes to the specification to clarify the same.

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

Commit messages:
 - 8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel

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

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

From psadhukhan at openjdk.java.net  Mon Aug 16 10:04:32 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 16 Aug 2021 10:04:32 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'."
In-Reply-To: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
Message-ID: <4N4Q61oZfsmhW2nIk4jitC6eAJ6ZSSNoMsPtz6AHdqU=.179298f0-b291-4093-844f-91bd17c2e7c5@github.com>

On Wed, 11 Aug 2021 09:03:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The test fails in CI testing citing expected "rededited" but found "redEDITED", which seems to point to fact that either there is a CAPS_LOCK key switched on or some other test did not use SHIFT key corectly  ie, pressed but not released.
> 
> Considering many more tests would have failed if CAPS_LOCK is turned on, I tried to find if some tests uses SHIFT key mistakenly and it seems JRadioButton test has press/release order wrong and it uses SHIFT. Rectified that.
> 
> In addition, corrected some known CI issues ie waiting after frame is made visible, made frame to centre. Along with that, also modified testcase to check lowercase string. Since the original JDK-4275046 issue is about newly entered text is made part of cell or not, it does not matter if it's in lowercase/uppercase and if such CAPS_LOCK or Shift key problem happens again, this test will not be affected.
> 
> CI run for several iterations running these 2 tests one after another in all platforms is green.

There was one fix done way back regarding almost same tests being failed due to CAPS_LOCK not turned off by test
https://github.com/openjdk/jdk/commit/51837b8a13d24279b8f9a1e36dee7320901a9cc9
but I could not find any other test doing something similar with setLockingState...
One was in java/awt/Toolkit/Headless/HeadlessToolkit.java but it is marked headless so would not affect headful test so I was thinking it's more of VK_SHIFT issue

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

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

From psadhukhan at openjdk.java.net  Mon Aug 16 13:45:49 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 16 Aug 2021 13:45:49 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'." [v2]
In-Reply-To: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
Message-ID: <0nqEMU7qXaWsN5FR_XWliFSnFbYqyHunxOBVLbBaijo=.478c7b30-c9c9-4657-b3a6-e07a18f4f45b@github.com>

> The test fails in CI testing citing expected "rededited" but found "redEDITED", which seems to point to fact that either there is a CAPS_LOCK key switched on or some other test did not use SHIFT key corectly  ie, pressed but not released.
> 
> Considering many more tests would have failed if CAPS_LOCK is turned on, I tried to find if some tests uses SHIFT key mistakenly and it seems JRadioButton test has press/release order wrong and it uses SHIFT. Rectified that.
> 
> In addition, corrected some known CI issues ie waiting after frame is made visible, made frame to centre. Along with that, also modified testcase to check lowercase string. Since the original JDK-4275046 issue is about newly entered text is made part of cell or not, it does not matter if it's in lowercase/uppercase and if such CAPS_LOCK or Shift key problem happens again, this test will not be affected.
> 
> CI run for several iterations running these 2 tests one after another in all platforms is green.

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

  Testfix for inadvertent CAPS_LOCK enable problem

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5079/files
  - new: https://git.openjdk.java.net/jdk/pull/5079/files/404b86ab..dd910c58

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

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

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

From aivanov at openjdk.java.net  Mon Aug 16 16:00:32 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 16 Aug 2021 16:00:32 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'."
In-Reply-To: <_T_e0nCc99b7vcWAHbsdgg_7o2oK3r52aq1WENzwoxc=.9f622e94-585a-401a-a2ef-d41ad9be4b3f@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
 <dEClr_neMK_kATfN8e2wtn3K6D9z7O7UCBzfHTel0E8=.b455a0df-af21-41ba-a71a-67848ac7e07f@github.com>
 <_T_e0nCc99b7vcWAHbsdgg_7o2oK3r52aq1WENzwoxc=.9f622e94-585a-401a-a2ef-d41ad9be4b3f@github.com>
Message-ID: <5owbtgZ5sJ-NYpHLBtQVeAZU0DeStnnl--fYj0b3HC8=.2515793e-6ec3-4a1d-bda5-0e9f67fa00bb@github.com>

On Mon, 16 Aug 2021 04:27:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> As I told in initial explanation, I thought it will be either CAPS_LOCK key switched on or some other test did not use SHIFT key corectly ie, pressed but not released.

This seems the likely cause. And in this case we have to find the test which leaves Shift presses or uses Caps Lock.

> I could not do anything about if someone press CAPS_LOCK so I search for VK_SHIFT being used in all javax/swing reg test and I found this test bug8033699.java is having a wrong order. I am not saying this was the root cause but it needs rectifying, I presume..

In this test, bug8033699.java, the Shift key _is released_, however, it's released before Tab is released whereas (modifier) keys are usually released in the reverse order to the order they are pressed.

Have you already submitted a bug to fix the release order?

> Also, the fix I proposed will not have any impact on this test testing 4275046 fix because of the reason mentioned above (original bug is about new characters being part of field, lowercsae/uppercase does not matter)

Yes, you're right the test is about getting the new text committed into the table cell. Yet the test didn't press Shift key, nor did it turn Caps Lock on, which means the problem is external to the test itself. If Shift key remains pressed, some other test could fails, for example, bug8033699.java will liked fail if it's started with Shift key press because focus will be traversed in the reverse order rather than forward order.

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

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

From kizune at openjdk.java.net  Mon Aug 16 18:38:29 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 16 Aug 2021 18:38:29 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v4]
In-Reply-To: <7LY1Ss4dbeqC0gRlccImv8WTfFBz3GbVFsehmXYZMX0=.7eda8ed7-3d51-4dd8-87c6-ff0282711188@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <cNuWSI3hDvi2hVL6jZVbvOqCo4jvHp_oDS-FsUeDeVI=.8acdad17-0c62-45e7-a48c-45c7ff8c28bd@github.com>
 <7LY1Ss4dbeqC0gRlccImv8WTfFBz3GbVFsehmXYZMX0=.7eda8ed7-3d51-4dd8-87c6-ff0282711188@github.com>
Message-ID: <Bghfix_lRDUWNIA1Zq5ZSECg3LgzKqNIq5nElntbUls=.80703ead-250e-4bc6-abae-7a305cc683b8@github.com>

On Mon, 16 Aug 2021 02:15:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Can you please create of blend of two images, one for common focused button(with border) and another one w/o. Just to check that the border is drawn in the similar location and using similar "shape".

Here is the overlap of two images - with and without borders painted, the without borders painted has 80% opacity so borders look faint. I do not think that the focus ring will always be pixel perfect match with the natively painted - but they are close enough that switching border painting on and off i can not tell difference visually and the new focus ring is always contained within the button shape so it will not disrupt anything beyond it.

![focus1b](https://user-images.githubusercontent.com/69642324/129612749-21283e4f-b97e-4aa0-aee1-451b9e60f151.png)

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

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

From serb at openjdk.java.net  Mon Aug 16 18:52:27 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 16 Aug 2021 18:52:27 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v4]
In-Reply-To: <cNuWSI3hDvi2hVL6jZVbvOqCo4jvHp_oDS-FsUeDeVI=.8acdad17-0c62-45e7-a48c-45c7ff8c28bd@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <cNuWSI3hDvi2hVL6jZVbvOqCo4jvHp_oDS-FsUeDeVI=.8acdad17-0c62-45e7-a48c-45c7ff8c28bd@github.com>
Message-ID: <Rqk3DrUEVURp4C5HxAQwCZC-jPBWocyRDnCDdi5oFJs=.b17039b6-43a0-4762-8fbf-980252dce9ee@github.com>

On Fri, 13 Aug 2021 19:17:13 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Initial implementation and a test case.
>> 
>> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove getLookAndFeelDefaults() call

That looks great.

src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 340:

> 338:         Color ringColor = UIManager.getColor("Focus.color");
> 339:         g.setColor(ringColor);
> 340:         g.drawRoundRect(5, 3, b.getWidth() - 10, b.getHeight() - 7, 15, 15);

Don't you need to restore the properties of Graphics2D?

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

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

From serb at openjdk.java.net  Mon Aug 16 19:14:31 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 16 Aug 2021 19:14:31 GMT
Subject: <Swing Dev> RFR: 8272148: JDesktopPane:getComponentCount()
 returns one extra than expected with GTKLookAndFeel
In-Reply-To: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
References: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
Message-ID: <JUeC4CVzHpZLBh-HSpoEhQAaC68_CPPlVmfifBa8g8g=.58e3cf41-0b62-40f9-9887-7e2bc248265a@github.com>

On Mon, 16 Aug 2021 08:22:35 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> A container may include few default components as children, which are added to it during creation. Due to this, calling function getChildrenCount on a new created instance may return non zero value. This behaviour may vary according to L&F also, as some L&F may add some default components to a container, but other L&F may choose not to do so.
> 
> The current bugs reports that this behaviour looks suspicious as it is expected that a newly created container will have zero  children.
> 
> Current specification is not clear on this whether it is allowed for a container to contain default components or not. The fix make changes to the specification to clarify the same.
> 
> Note: I think this will need a CSR, I will file one after the review is completed

Can you please clarify why the GTK L&F is affected only?

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

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

From kizune at openjdk.java.net  Mon Aug 16 19:49:57 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 16 Aug 2021 19:49:57 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v4]
In-Reply-To: <Rqk3DrUEVURp4C5HxAQwCZC-jPBWocyRDnCDdi5oFJs=.b17039b6-43a0-4762-8fbf-980252dce9ee@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <cNuWSI3hDvi2hVL6jZVbvOqCo4jvHp_oDS-FsUeDeVI=.8acdad17-0c62-45e7-a48c-45c7ff8c28bd@github.com>
 <Rqk3DrUEVURp4C5HxAQwCZC-jPBWocyRDnCDdi5oFJs=.b17039b6-43a0-4762-8fbf-980252dce9ee@github.com>
Message-ID: <ygpo7KPRaB7FjyctAWqohlM1tkfvWSla8fFVpH8knKk=.776e8e74-6e76-45ed-b580-7543879b421c@github.com>

On Mon, 16 Aug 2021 18:49:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Don't you need to restore the properties of Graphics2D?

I might as well.

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

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

From kizune at openjdk.java.net  Mon Aug 16 19:49:56 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 16 Aug 2021 19:49:56 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v5]
In-Reply-To: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
Message-ID: <kHu44L1qaP8VM6e3S5By-BG0NvUrAsakf8fQcJTF4to=.bd21eb74-bc35-4087-ba56-1f19708327b1@github.com>

> Initial implementation and a test case.
> 
> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways.

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

  Restore Graphics2D rendering state so we do not interfere with next stages of button painting.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5082/files
  - new: https://git.openjdk.java.net/jdk/pull/5082/files/df34ab0b..87ab3e3a

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

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

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

From pbansal at openjdk.java.net  Mon Aug 16 20:51:27 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 16 Aug 2021 20:51:27 GMT
Subject: <Swing Dev> RFR: 8272148: JDesktopPane:getComponentCount()
 returns one extra than expected with GTKLookAndFeel
In-Reply-To: <JUeC4CVzHpZLBh-HSpoEhQAaC68_CPPlVmfifBa8g8g=.58e3cf41-0b62-40f9-9887-7e2bc248265a@github.com>
References: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
 <JUeC4CVzHpZLBh-HSpoEhQAaC68_CPPlVmfifBa8g8g=.58e3cf41-0b62-40f9-9887-7e2bc248265a@github.com>
Message-ID: <lUxopCEx6RHq178RzAu3io3E1NyZKmNynN0FOvpXtHc=.bbcc34fa-3d04-40ed-95b3-0fa9035ddac7@github.com>

On Mon, 16 Aug 2021 19:11:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Can you please clarify why the GTK L&F is affected only?

Synth L&F is adding a Taskbar in SynthDesktopPaneUI class if the "InternalFrame.useTaskBar" is set true. The "InternalFrame.useTaskBar" is set true in case of GTKL&F only, so this issue is happening. I think L&Fs are allowed to customize these things.
I think this happening in GTK L&F is not really much to do with GTK L&F. This can happen for any default/custom container for any L&F which adds some default components as children. The spec does not stop anyone from doing so. So the spec should be modified to clarify the expected behaviour.

https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java#L109
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java#L660

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

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

From serb at openjdk.java.net  Mon Aug 16 20:57:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 16 Aug 2021 20:57:25 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v4]
In-Reply-To: <ygpo7KPRaB7FjyctAWqohlM1tkfvWSla8fFVpH8knKk=.776e8e74-6e76-45ed-b580-7543879b421c@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <cNuWSI3hDvi2hVL6jZVbvOqCo4jvHp_oDS-FsUeDeVI=.8acdad17-0c62-45e7-a48c-45c7ff8c28bd@github.com>
 <Rqk3DrUEVURp4C5HxAQwCZC-jPBWocyRDnCDdi5oFJs=.b17039b6-43a0-4762-8fbf-980252dce9ee@github.com>
 <ygpo7KPRaB7FjyctAWqohlM1tkfvWSla8fFVpH8knKk=.776e8e74-6e76-45ed-b580-7543879b421c@github.com>
Message-ID: <zqWRNPwRgUC3ZuHHaaBW9o30dOR1PVk0ygT27Z5_4kA=.f93299b5-5fb8-4238-93d1-4934de034f62@github.com>

On Mon, 16 Aug 2021 19:45:11 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 340:
>> 
>>> 338:         Color ringColor = UIManager.getColor("Focus.color");
>>> 339:         g.setColor(ringColor);
>>> 340:         g.drawRoundRect(5, 3, b.getWidth() - 10, b.getHeight() - 7, 15, 15);
>> 
>> Don't you need to restore the properties of Graphics2D?
>
>> Don't you need to restore the properties of Graphics2D?
> 
> I might as well.

What about the color property?

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

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

From prr at openjdk.java.net  Mon Aug 16 21:00:25 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 16 Aug 2021 21:00:25 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'." [v2]
In-Reply-To: <0nqEMU7qXaWsN5FR_XWliFSnFbYqyHunxOBVLbBaijo=.478c7b30-c9c9-4657-b3a6-e07a18f4f45b@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
 <0nqEMU7qXaWsN5FR_XWliFSnFbYqyHunxOBVLbBaijo=.478c7b30-c9c9-4657-b3a6-e07a18f4f45b@github.com>
Message-ID: <n9aOrH_KqjJRqQKREuTTzUJzCswfG4ZliInJqGR3yVg=.39329c3f-3876-47e3-b23c-70fdde8474b3@github.com>

On Mon, 16 Aug 2021 13:45:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The test fails in CI testing citing expected "rededited" but found "redEDITED", which seems to point to fact that either there is a CAPS_LOCK key switched on or some other test did not use SHIFT key corectly  ie, pressed but not released.
>> 
>> Considering many more tests would have failed if CAPS_LOCK is turned on, I tried to find if some tests uses SHIFT key mistakenly and it seems JRadioButton test has press/release order wrong and it uses SHIFT. Rectified that.
>> 
>> In addition, corrected some known CI issues ie waiting after frame is made visible, made frame to centre. Along with that, also modified testcase to check lowercase string. Since the original JDK-4275046 issue is about newly entered text is made part of cell or not, it does not matter if it's in lowercase/uppercase and if such CAPS_LOCK or Shift key problem happens again, this test will not be affected.
>> 
>> CI run for several iterations running these 2 tests one after another in all platforms is green.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Testfix for inadvertent CAPS_LOCK enable problem

test/jdk/javax/swing/JTable/4275046/bug4275046.java line 180:

> 178:             // Read the edited value of from the cell
> 179:             editedValue = table.getModel().getValueAt(0, 1);
> 180:             editedValue = ((String)editedValue).toLowerCase();

So this just masks that some other test is the real problem.

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

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

From prr at openjdk.java.net  Mon Aug 16 21:06:27 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 16 Aug 2021 21:06:27 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'." [v2]
In-Reply-To: <0nqEMU7qXaWsN5FR_XWliFSnFbYqyHunxOBVLbBaijo=.478c7b30-c9c9-4657-b3a6-e07a18f4f45b@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
 <0nqEMU7qXaWsN5FR_XWliFSnFbYqyHunxOBVLbBaijo=.478c7b30-c9c9-4657-b3a6-e07a18f4f45b@github.com>
Message-ID: <jfS91zBKq0v7pYDb0nF48oq7rGgcQuG5ZHzIXwQSm2I=.7bb6c62f-6fd3-4aad-a931-d1e64b7ac524@github.com>

On Mon, 16 Aug 2021 13:45:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The test fails in CI testing citing expected "rededited" but found "redEDITED", which seems to point to fact that either there is a CAPS_LOCK key switched on or some other test did not use SHIFT key corectly  ie, pressed but not released.
>> 
>> Considering many more tests would have failed if CAPS_LOCK is turned on, I tried to find if some tests uses SHIFT key mistakenly and it seems JRadioButton test has press/release order wrong and it uses SHIFT. Rectified that.
>> 
>> In addition, corrected some known CI issues ie waiting after frame is made visible, made frame to centre. Along with that, also modified testcase to check lowercase string. Since the original JDK-4275046 issue is about newly entered text is made part of cell or not, it does not matter if it's in lowercase/uppercase and if such CAPS_LOCK or Shift key problem happens again, this test will not be affected.
>> 
>> CI run for several iterations running these 2 tests one after another in all platforms is green.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Testfix for inadvertent CAPS_LOCK enable problem

I think what you need to do is take the list of tests that were run before the FIRST failure - not this one.
Keep them in order - very important
Now find all of them those that use SHIFT (more likey) or CAPS_LOCK
It should be at least easy to get that candidate list

Then work (backwards) through those to see which might have let SHIFT down which may be harder.

One thing I don't know (or understand) is why some other test that presses SHIFT did not release it and solve the problem.

Oh, and finding prior tests which would have failed if SHIFT was down but "pass" might also help the search.

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

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

From prr at openjdk.java.net  Mon Aug 16 21:13:26 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 16 Aug 2021 21:13:26 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v3]
In-Reply-To: <5Q8sBOlCSBkwppm0ztZgX5x6ulm6AldAaizQQOxgthk=.b319c144-bf9f-49fe-bca1-b915b0d700ab@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <PbaZFYp_makXd2CG_F2ic7MnuETGyUobZEv8SzlTL0w=.b33e4d07-f4a3-4132-be4d-fbac989f24d2@github.com>
 <16FHZi0ahiUyGYEh8k9UFzSUsOAMP0Hz_CPrJsLGPWs=.b39a6faf-1ad8-40d8-ae28-dae856e4a34f@github.com>
 <5Q8sBOlCSBkwppm0ztZgX5x6ulm6AldAaizQQOxgthk=.b319c144-bf9f-49fe-bca1-b915b0d700ab@github.com>
Message-ID: <Ee7hcajqxmHbH-bDdfa7nQh0HiLbcg5r917h3YFCNH8=.47047184-4f9a-4838-9e22-579d204f48c0@github.com>

On Mon, 16 Aug 2021 04:36:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > We should either prevent null being set or catch all those nulls.
> 
> I did that in 1st iteration of this PR..https://github.com/openjdk/jdk/pull/4989/files/2a2ab50ded3305f3a9e0f01e90417b484a0b2db4
> 
> @prrace Should I bring that fix back?
> 

You are reading my "there are two options text" and the code you propose to bring back is NOT the option
I recommended.

> > Just add advisory doc on the protected field too.
> 
> > ok, this is part of what this change do, probably the text should be rephrased there?
> > What should be the advisory phrase? Will the text I have added in the protected field doc not suffice?

Something like "subclassers must ensure this is set to a non-null value during construction and not set this to null"

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

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

From kizune at openjdk.java.net  Mon Aug 16 23:42:30 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 16 Aug 2021 23:42:30 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v4]
In-Reply-To: <zqWRNPwRgUC3ZuHHaaBW9o30dOR1PVk0ygT27Z5_4kA=.f93299b5-5fb8-4238-93d1-4934de034f62@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <cNuWSI3hDvi2hVL6jZVbvOqCo4jvHp_oDS-FsUeDeVI=.8acdad17-0c62-45e7-a48c-45c7ff8c28bd@github.com>
 <Rqk3DrUEVURp4C5HxAQwCZC-jPBWocyRDnCDdi5oFJs=.b17039b6-43a0-4762-8fbf-980252dce9ee@github.com>
 <ygpo7KPRaB7FjyctAWqohlM1tkfvWSla8fFVpH8knKk=.776e8e74-6e76-45ed-b580-7543879b421c@github.com>
 <zqWRNPwRgUC3ZuHHaaBW9o30dOR1PVk0ygT27Z5_4kA=.f93299b5-5fb8-4238-93d1-4934de034f62@github.com>
Message-ID: <pFcKeG2KG7xlEDQ9Kgxihlhfz-1WO5VIXD6vKVrhsSU=.fca89062-2421-4d82-a71f-9fa68944dd1a@github.com>

On Mon, 16 Aug 2021 20:53:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> What about the color property?

That would be unnecessary, whoever does painting does not just assumes that the color is set to his preferred choice, everywhere in the code color is set up before doing any painting and i do not see anywhere that old color being preserved.

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

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

From serb at openjdk.java.net  Mon Aug 16 23:49:30 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 16 Aug 2021 23:49:30 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v4]
In-Reply-To: <pFcKeG2KG7xlEDQ9Kgxihlhfz-1WO5VIXD6vKVrhsSU=.fca89062-2421-4d82-a71f-9fa68944dd1a@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <cNuWSI3hDvi2hVL6jZVbvOqCo4jvHp_oDS-FsUeDeVI=.8acdad17-0c62-45e7-a48c-45c7ff8c28bd@github.com>
 <Rqk3DrUEVURp4C5HxAQwCZC-jPBWocyRDnCDdi5oFJs=.b17039b6-43a0-4762-8fbf-980252dce9ee@github.com>
 <ygpo7KPRaB7FjyctAWqohlM1tkfvWSla8fFVpH8knKk=.776e8e74-6e76-45ed-b580-7543879b421c@github.com>
 <zqWRNPwRgUC3ZuHHaaBW9o30dOR1PVk0ygT27Z5_4kA=.f93299b5-5fb8-4238-93d1-4934de034f62@github.com>
 <pFcKeG2KG7xlEDQ9Kgxihlhfz-1WO5VIXD6vKVrhsSU=.fca89062-2421-4d82-a71f-9fa68944dd1a@github.com>
Message-ID: <BiHeLyP7Pob2DhNf9mBe1gXsYAGLTG8XW5BeX5Gr85g=.de9b2eb2-4609-4cc7-b0f3-eb656e94cadb@github.com>

On Mon, 16 Aug 2021 23:39:05 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> What about the color property?
>
>> What about the color property?
> 
> That would be unnecessary, whoever does painting does not just assumes that the color is set to his preferred choice, everywhere in the code color is set up before doing any painting and i do not see anywhere that old color being preserved.

You can trace the usage of graphics.getColor() for example in AquaMenuItemUI/WindowsMenuUI/BevelBorder/etc to check that the old color property is usually saved and then restored.

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

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

From psadhukhan at openjdk.java.net  Tue Aug 17 04:47:43 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 17 Aug 2021 04:47:43 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v4]
In-Reply-To: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
Message-ID: <aZAZ1Cr_eKIEXilMcv2Uyc6fQS7qr3Z9J4Pv39GYJSw=.e2711c46-ccc7-48de-8e5c-8d5c99b42896@github.com>

> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
> Added null check for those cases.

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - Prevent null being set
 - Prevent null being set

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4989/files
  - new: https://git.openjdk.java.net/jdk/pull/4989/files/f69c24a1..3e1a444d

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

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

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

From serb at openjdk.java.net  Tue Aug 17 05:12:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 17 Aug 2021 05:12:25 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v4]
In-Reply-To: <aZAZ1Cr_eKIEXilMcv2Uyc6fQS7qr3Z9J4Pv39GYJSw=.e2711c46-ccc7-48de-8e5c-8d5c99b42896@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <aZAZ1Cr_eKIEXilMcv2Uyc6fQS7qr3Z9J4Pv39GYJSw=.e2711c46-ccc7-48de-8e5c-8d5c99b42896@github.com>
Message-ID: <XzblaprRJh7l0t3UcIUoo-oRrF53vT9IJ1HwIj46DPo=.73e6ef72-3024-4194-a88f-7b5880457fd1@github.com>

On Tue, 17 Aug 2021 04:47:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
>> Added null check for those cases.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Prevent null being set
>  - Prevent null being set

src/java.desktop/share/classes/javax/swing/JInternalFrame.java line 1321:

> 1319:             desktopIcon = d;
> 1320:             firePropertyChange("desktopIcon", oldValue, d);
> 1321:         }

Probably NPE is better in this case? Either way the specification should say something about the new behaviour.

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

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

From psadhukhan at openjdk.java.net  Tue Aug 17 05:26:26 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 17 Aug 2021 05:26:26 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v4]
In-Reply-To: <XzblaprRJh7l0t3UcIUoo-oRrF53vT9IJ1HwIj46DPo=.73e6ef72-3024-4194-a88f-7b5880457fd1@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <aZAZ1Cr_eKIEXilMcv2Uyc6fQS7qr3Z9J4Pv39GYJSw=.e2711c46-ccc7-48de-8e5c-8d5c99b42896@github.com>
 <XzblaprRJh7l0t3UcIUoo-oRrF53vT9IJ1HwIj46DPo=.73e6ef72-3024-4194-a88f-7b5880457fd1@github.com>
Message-ID: <7lfC0exlnHyQgRVTNx-RSkVueMocniCX8RiQ2eAdzs4=.6c88153f-a4a8-4675-92a5-8ac8cb5ba4a6@github.com>

On Tue, 17 Aug 2021 05:09:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Prevent null being set
>>  - Prevent null being set
>
> src/java.desktop/share/classes/javax/swing/JInternalFrame.java line 1321:
> 
>> 1319:             desktopIcon = d;
>> 1320:             firePropertyChange("desktopIcon", oldValue, d);
>> 1321:         }
> 
> Probably NPE is better in this case? Either way the specification should say something about the new behaviour.

Are you saying to throw NPE upfront here?
Regarding the specification, we are just preventing null as per recommendation..How should it be documented (that we are preventing null from being thrown later on)?

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

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

From psadhukhan at openjdk.java.net  Tue Aug 17 05:37:47 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 17 Aug 2021 05:37:47 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'." [v3]
In-Reply-To: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
Message-ID: <leQdMA7uzQ8u1KbOXSuTdsp0RPhzcpmETXkS1bGMya8=.b40ddf4b-a595-416f-973a-1c46b53cfdbb@github.com>

> The test fails in CI testing citing expected "rededited" but found "redEDITED", which seems to point to fact that either there is a CAPS_LOCK key switched on or some other test did not use SHIFT key corectly  ie, pressed but not released.
> 
> Considering many more tests would have failed if CAPS_LOCK is turned on, I tried to find if some tests uses SHIFT key mistakenly and it seems JRadioButton test has press/release order wrong and it uses SHIFT. Rectified that.
> 
> In addition, corrected some known CI issues ie waiting after frame is made visible, made frame to centre. Along with that, also modified testcase to check lowercase string. Since the original JDK-4275046 issue is about newly entered text is made part of cell or not, it does not matter if it's in lowercase/uppercase and if such CAPS_LOCK or Shift key problem happens again, this test will not be affected.
> 
> CI run for several iterations running these 2 tests one after another in all platforms is green.

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

  VK_SHIFT test anomaly fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5079/files
  - new: https://git.openjdk.java.net/jdk/pull/5079/files/dd910c58..1de7e162

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

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

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

From psadhukhan at openjdk.java.net  Tue Aug 17 05:40:27 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 17 Aug 2021 05:40:27 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'." [v2]
In-Reply-To: <0nqEMU7qXaWsN5FR_XWliFSnFbYqyHunxOBVLbBaijo=.478c7b30-c9c9-4657-b3a6-e07a18f4f45b@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
 <0nqEMU7qXaWsN5FR_XWliFSnFbYqyHunxOBVLbBaijo=.478c7b30-c9c9-4657-b3a6-e07a18f4f45b@github.com>
Message-ID: <yZPTAQJp55aOPLthzqEltNxdPn8xrwQHCmPlP7gAzbw=.376e58a8-85c2-4440-b3e9-c2c45fb99566@github.com>

On Mon, 16 Aug 2021 13:45:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The test fails in CI testing citing expected "rededited" but found "redEDITED", which seems to point to fact that either there is a CAPS_LOCK key switched on or some other test did not use SHIFT key corectly  ie, pressed but not released.
>> 
>> Considering many more tests would have failed if CAPS_LOCK is turned on, I tried to find if some tests uses SHIFT key mistakenly and it seems JRadioButton test has press/release order wrong and it uses SHIFT. Rectified that.
>> 
>> In addition, corrected some known CI issues ie waiting after frame is made visible, made frame to centre. Along with that, also modified testcase to check lowercase string. Since the original JDK-4275046 issue is about newly entered text is made part of cell or not, it does not matter if it's in lowercase/uppercase and if such CAPS_LOCK or Shift key problem happens again, this test will not be affected.
>> 
>> CI run for several iterations running these 2 tests one after another in all platforms is green.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Testfix for inadvertent CAPS_LOCK enable problem

Since FIRST failure is java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java
I tried to find tests that uses VK_SHIFT key which are


java/awt/Debug/DumpOnKey/DumpOnKey.java
	java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
	java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java
	java/awt/dnd/RecognizedActionTest/RecognizedActionTest.java
	java/awt/event/KeyEvent/8020209/bug8020209.java
	java/awt/event/KeyEvent/ExtendedModifiersTest/ExtendedModifiersTest.java
	java/awt/event/KeyEvent/KeyMaskTest/KeyMaskTest.java
	java/awt/event/KeyEvent/SwallowKeyEvents/SwallowKeyEvents.java
	java/awt/event/MouseEvent/MouseButtonsAndKeyMasksTest/MouseButtonsAndKeyMasksTest.java
	java/awt/FileDialog/MacOSGoToFolderCrash.java
	java/awt/Focus/8073453/AWTFocusTransitionTest.java
	java/awt/Focus/8073453/SwingFocusTransitionTest.java
	java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java
	java/awt/FullScreen/AltTabCrashTest/AltTabCrashTest.java
	java/awt/keyboard/AllKeyCode/AllKeyCode.java
	java/awt/List/ActionEventTest/ActionEventTest.java
	java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java
	java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java
	java/awt/Robot/ModifierRobotKey/ModifierRobotEnhancedKeyTest.java
	java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java


and CAPS_LOCK keys


java/awt/keyboard/AllKeyCode/AllKeyCode.java
	java/awt/Toolkit/Headless/HeadlessToolkit.java
	java/awt/Toolkit/LockingKeyStateTest/LockingKeyStateTest.java



I could not find any misuse of VK_SHIFT apart from in 
test/jdk/java/awt/List/ActionEventTest/ActionEventTest.java
test/jdk/java/awt/dnd/RecognizedActionTest/RecognizedActionTest.java
which I rectified. 

For CAPS_LOCK, LockingKeyState was already rectified as I mentioned in previous comment and 
HeadlessToolkit is headless which will not affect headful tests

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

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

From kizune at openjdk.java.net  Tue Aug 17 06:09:51 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 17 Aug 2021 06:09:51 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v4]
In-Reply-To: <BiHeLyP7Pob2DhNf9mBe1gXsYAGLTG8XW5BeX5Gr85g=.de9b2eb2-4609-4cc7-b0f3-eb656e94cadb@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <cNuWSI3hDvi2hVL6jZVbvOqCo4jvHp_oDS-FsUeDeVI=.8acdad17-0c62-45e7-a48c-45c7ff8c28bd@github.com>
 <Rqk3DrUEVURp4C5HxAQwCZC-jPBWocyRDnCDdi5oFJs=.b17039b6-43a0-4762-8fbf-980252dce9ee@github.com>
 <ygpo7KPRaB7FjyctAWqohlM1tkfvWSla8fFVpH8knKk=.776e8e74-6e76-45ed-b580-7543879b421c@github.com>
 <zqWRNPwRgUC3ZuHHaaBW9o30dOR1PVk0ygT27Z5_4kA=.f93299b5-5fb8-4238-93d1-4934de034f62@github.com>
 <pFcKeG2KG7xlEDQ9Kgxihlhfz-1WO5VIXD6vKVrhsSU=.fca89062-2421-4d82-a71f-9fa68944dd1a@github.com>
 <BiHeLyP7Pob2DhNf9mBe1gXsYAGLTG8XW5BeX5Gr85g=.de9b2eb2-4609-4cc7-b0f3-eb656e94cadb@github.com>
Message-ID: <7i1w0_Dw8390kdsrRbvwMpNn1t8B_uhL4CfzRlOw2iM=.a0b35600-ea7a-483d-8a3e-060075938fa7@github.com>

On Mon, 16 Aug 2021 23:46:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> You can trace the usage of graphics.getColor() for example in AquaMenuItemUI/WindowsMenuUI/BevelBorder/etc to check that the old color property is usually saved and then restored.

A few lines above paintFocus() is called there is a section that sets color to something different in case of opaque button and that does not affect the next step - text painting - since text painter will grab text color and set the graphics draw color to it. However in the interest of moving forward i will ad saving the color - after al it is not a performance critical task.

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

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

From kizune at openjdk.java.net  Tue Aug 17 06:09:51 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 17 Aug 2021 06:09:51 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v6]
In-Reply-To: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
Message-ID: <tGjFDHKjayfYb5b1x8p3Q6DRIjXKU-oDAvICjhRQCCI=.0fcb9f07-02dc-40f4-948f-61bd0fce8e7b@github.com>

> Initial implementation and a test case.
> 
> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways.

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

  Restore Graphics color before leaving paintFocus()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5082/files
  - new: https://git.openjdk.java.net/jdk/pull/5082/files/87ab3e3a..3b81c977

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

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

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

From aivanov at openjdk.java.net  Tue Aug 17 12:38:24 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 17 Aug 2021 12:38:24 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'." [v2]
In-Reply-To: <yZPTAQJp55aOPLthzqEltNxdPn8xrwQHCmPlP7gAzbw=.376e58a8-85c2-4440-b3e9-c2c45fb99566@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
 <0nqEMU7qXaWsN5FR_XWliFSnFbYqyHunxOBVLbBaijo=.478c7b30-c9c9-4657-b3a6-e07a18f4f45b@github.com>
 <yZPTAQJp55aOPLthzqEltNxdPn8xrwQHCmPlP7gAzbw=.376e58a8-85c2-4440-b3e9-c2c45fb99566@github.com>
Message-ID: <SB02HXrKY_4BX1x4_BRWFimGyUzEphyyTdTVFwc5Bj4=.aed71f2a-11cb-45c2-9a6b-3987e2216af3@github.com>

On Tue, 17 Aug 2021 05:37:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Since FIRST failure is java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java
> I tried to find tests that uses VK_SHIFT key which are ?

Can you reproduce the failure locally if the tests are run in the same order?

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

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

From aivanov at openjdk.java.net  Tue Aug 17 12:38:25 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 17 Aug 2021 12:38:25 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'." [v3]
In-Reply-To: <leQdMA7uzQ8u1KbOXSuTdsp0RPhzcpmETXkS1bGMya8=.b40ddf4b-a595-416f-973a-1c46b53cfdbb@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
 <leQdMA7uzQ8u1KbOXSuTdsp0RPhzcpmETXkS1bGMya8=.b40ddf4b-a595-416f-973a-1c46b53cfdbb@github.com>
Message-ID: <2XXcJRcx5akfy7hmlH5IoF5Krcho6OW3ZGOg6AK7b1Q=.d4418b2b-9e94-4bcb-9335-8848275d8cdc@github.com>

On Tue, 17 Aug 2021 05:37:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The test fails in CI testing citing expected "rededited" but found "redEDITED", which seems to point to fact that either there is a CAPS_LOCK key switched on or some other test did not use SHIFT key corectly  ie, pressed but not released.
>> 
>> Considering many more tests would have failed if CAPS_LOCK is turned on, I tried to find if some tests uses SHIFT key mistakenly and it seems JRadioButton test has press/release order wrong and it uses SHIFT. Rectified that.
>> 
>> In addition, corrected some known CI issues ie waiting after frame is made visible, made frame to centre. Along with that, also modified testcase to check lowercase string. Since the original JDK-4275046 issue is about newly entered text is made part of cell or not, it does not matter if it's in lowercase/uppercase and if such CAPS_LOCK or Shift key problem happens again, this test will not be affected.
>> 
>> CI run for several iterations running these 2 tests one after another in all platforms is green.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   VK_SHIFT test anomaly fix

test/jdk/java/awt/List/ActionEventTest/ActionEventTest.java line 79:

> 77:                     dispose();
> 78:                     throw new RuntimeException("Action Event modifiers are not"
> 79:                         + " set correctly.");

This exception should be thrown from the main thread. An action listener is called on EDT, thus the exception won't fail the test, will it?

And using robot to release keys from EDT as part of the clean-up doesn't seem right.

test/jdk/javax/swing/JFileChooser/8041694/bug8041694.java line 109:

> 107:                     "JFileChooser removed trailing spaces in the selected directory name. " +
> 108:                     "Expected 'd ' got '" + selectedDir.getName() + "'.");
> 109:             } else if (!selectedDir.getName().toLowerCase().equals("d ")) {

I believe @prrace's comment also applies here: _So this just masks that some other test is the real problem._

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

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

From psadhukhan at openjdk.java.net  Tue Aug 17 12:42:27 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 17 Aug 2021 12:42:27 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'." [v3]
In-Reply-To: <2XXcJRcx5akfy7hmlH5IoF5Krcho6OW3ZGOg6AK7b1Q=.d4418b2b-9e94-4bcb-9335-8848275d8cdc@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
 <leQdMA7uzQ8u1KbOXSuTdsp0RPhzcpmETXkS1bGMya8=.b40ddf4b-a595-416f-973a-1c46b53cfdbb@github.com>
 <2XXcJRcx5akfy7hmlH5IoF5Krcho6OW3ZGOg6AK7b1Q=.d4418b2b-9e94-4bcb-9335-8848275d8cdc@github.com>
Message-ID: <6fUtGU7sl40wrZfwvxuS8KX3wOqf2FpA7bMpTUwCO7M=.8d1b2e10-cd22-4615-a90f-ac8478ff9c57@github.com>

On Tue, 17 Aug 2021 12:27:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> And using robot to release keys from EDT as part of the clean-up doesn't seem right.

I am just rectifying the order of the key release..It was pressed in order ALT SHIFT CONTROL and the release was ALT SHIFT CONTROL.. which I rectified to be release in order CONTROL SHIFT ALT

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

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

From serb at openjdk.java.net  Tue Aug 17 20:02:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 17 Aug 2021 20:02:25 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v6]
In-Reply-To: <tGjFDHKjayfYb5b1x8p3Q6DRIjXKU-oDAvICjhRQCCI=.0fcb9f07-02dc-40f4-948f-61bd0fce8e7b@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <tGjFDHKjayfYb5b1x8p3Q6DRIjXKU-oDAvICjhRQCCI=.0fcb9f07-02dc-40f4-948f-61bd0fce8e7b@github.com>
Message-ID: <-oDUkyBkkN9MrkW3JuW47Tj7d5CeJ34bpzv2QPgmbkc=.d2ad0753-c689-42a8-b669-54fa75a20758@github.com>

On Tue, 17 Aug 2021 06:09:51 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Initial implementation and a test case.
>> 
>> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore Graphics color before leaving paintFocus()

Marked as reviewed by serb (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Wed Aug 18 04:22:23 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 18 Aug 2021 04:22:23 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v3]
In-Reply-To: <Ee7hcajqxmHbH-bDdfa7nQh0HiLbcg5r917h3YFCNH8=.47047184-4f9a-4838-9e22-579d204f48c0@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <PbaZFYp_makXd2CG_F2ic7MnuETGyUobZEv8SzlTL0w=.b33e4d07-f4a3-4132-be4d-fbac989f24d2@github.com>
 <16FHZi0ahiUyGYEh8k9UFzSUsOAMP0Hz_CPrJsLGPWs=.b39a6faf-1ad8-40d8-ae28-dae856e4a34f@github.com>
 <5Q8sBOlCSBkwppm0ztZgX5x6ulm6AldAaizQQOxgthk=.b319c144-bf9f-49fe-bca1-b915b0d700ab@github.com>
 <Ee7hcajqxmHbH-bDdfa7nQh0HiLbcg5r917h3YFCNH8=.47047184-4f9a-4838-9e22-579d204f48c0@github.com>
Message-ID: <wv_rZBcciWC0s7cnOJIea2Jo7b1ljj62kt1-QDCoqmU=.4c6171db-eacd-4c7f-b585-4abf3b759dbf@github.com>

On Mon, 16 Aug 2021 21:10:10 GMT, Phil Race <prr at openjdk.org> wrote:

>>> We should either prevent null being set or catch all those nulls.
>> 
>> I did that in 1st iteration of this PR..https://github.com/openjdk/jdk/pull/4989/files/2a2ab50ded3305f3a9e0f01e90417b484a0b2db4 
>> 
>> @prrace Should I bring that fix back?
>> 
>>> Just add advisory doc on the protected field too.
>> 
>>> ok, this is part of what this change do, probably the text should be rephrased there?
>> What should be the advisory phrase? Will the text I have added in the protected field doc not suffice?
>
>> > We should either prevent null being set or catch all those nulls.
>> 
>> I did that in 1st iteration of this PR..https://github.com/openjdk/jdk/pull/4989/files/2a2ab50ded3305f3a9e0f01e90417b484a0b2db4
>> 
>> @prrace Should I bring that fix back?
>> 
> 
> You are reading my "there are two options text" and the code you propose to bring back is NOT the option
> I recommended.
> 
>> > Just add advisory doc on the protected field too.
>> 
>> > ok, this is part of what this change do, probably the text should be rephrased there?
>> > What should be the advisory phrase? Will the text I have added in the protected field doc not suffice?
> 
> Something like "subclassers must ensure this is set to a non-null value during construction and not set this to null"

@prrace Any comment on this? I am just preventing "null being set" as was recommended.

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

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

From psadhukhan at openjdk.java.net  Wed Aug 18 05:02:23 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 18 Aug 2021 05:02:23 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v4]
In-Reply-To: <7i1w0_Dw8390kdsrRbvwMpNn1t8B_uhL4CfzRlOw2iM=.a0b35600-ea7a-483d-8a3e-060075938fa7@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <cNuWSI3hDvi2hVL6jZVbvOqCo4jvHp_oDS-FsUeDeVI=.8acdad17-0c62-45e7-a48c-45c7ff8c28bd@github.com>
 <Rqk3DrUEVURp4C5HxAQwCZC-jPBWocyRDnCDdi5oFJs=.b17039b6-43a0-4762-8fbf-980252dce9ee@github.com>
 <ygpo7KPRaB7FjyctAWqohlM1tkfvWSla8fFVpH8knKk=.776e8e74-6e76-45ed-b580-7543879b421c@github.com>
 <zqWRNPwRgUC3ZuHHaaBW9o30dOR1PVk0ygT27Z5_4kA=.f93299b5-5fb8-4238-93d1-4934de034f62@github.com>
 <pFcKeG2KG7xlEDQ9Kgxihlhfz-1WO5VIXD6vKVrhsSU=.fca89062-2421-4d82-a71f-9fa68944dd1a@github.com>
 <BiHeLyP7Pob2DhNf9mBe1gXsYAGLTG8XW5BeX5Gr85g=.de9b2eb2-4609-4cc7-b0f3-eb656e94cadb@github.com>
 <7i1w0_Dw8390kdsrRbvwMpNn1t8B_uhL4CfzRlOw2iM=.a0b35600-ea7a-483d-8a3e-060075938fa7@github.com>
Message-ID: <Atl6xMdpi2hXD7TtT0jbkfUxhmXKQcYxvvncH9FtxWA=.b3b1dda8-24d2-4b8e-9aed-d2b2aca78567@github.com>

On Tue, 17 Aug 2021 06:04:39 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> You can trace the usage of graphics.getColor() for example in AquaMenuItemUI/WindowsMenuUI/BevelBorder/etc to check that the old color property is usually saved and then restored.
>
>> You can trace the usage of graphics.getColor() for example in AquaMenuItemUI/WindowsMenuUI/BevelBorder/etc to check that the old color property is usually saved and then restored.
> 
> A few lines above paintFocus() is called there is a section that sets color to something different in case of opaque button and that does not affect the next step - text painting - since text painter will grab text color and set the graphics draw color to it. However in the interest of moving forward i will ad saving the color - after al it is not a performance critical task.

Have you checked if button does not have any text? It might affect the drawRoundRect values which are hardcoded now...In MetalButtonUI#paintFocus, it seems they cater to Button focus ring with and without text by taking care of setBounds(). Do we need to do something similar here?

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

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

From kizune at openjdk.java.net  Wed Aug 18 05:35:29 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 18 Aug 2021 05:35:29 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v4]
In-Reply-To: <Atl6xMdpi2hXD7TtT0jbkfUxhmXKQcYxvvncH9FtxWA=.b3b1dda8-24d2-4b8e-9aed-d2b2aca78567@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <cNuWSI3hDvi2hVL6jZVbvOqCo4jvHp_oDS-FsUeDeVI=.8acdad17-0c62-45e7-a48c-45c7ff8c28bd@github.com>
 <Rqk3DrUEVURp4C5HxAQwCZC-jPBWocyRDnCDdi5oFJs=.b17039b6-43a0-4762-8fbf-980252dce9ee@github.com>
 <ygpo7KPRaB7FjyctAWqohlM1tkfvWSla8fFVpH8knKk=.776e8e74-6e76-45ed-b580-7543879b421c@github.com>
 <zqWRNPwRgUC3ZuHHaaBW9o30dOR1PVk0ygT27Z5_4kA=.f93299b5-5fb8-4238-93d1-4934de034f62@github.com>
 <pFcKeG2KG7xlEDQ9Kgxihlhfz-1WO5VIXD6vKVrhsSU=.fca89062-2421-4d82-a71f-9fa68944dd1a@github.com>
 <BiHeLyP7Pob2DhNf9mBe1gXsYAGLTG8XW5BeX5Gr85g=.de9b2eb2-4609-4cc7-b0f3-eb656e94cadb@github.com>
 <7i1w0_Dw8390kdsrRbvwMpNn1t8B_uhL4CfzRlOw2iM=.a0b35600-ea7a-483d-8a3e-060075938fa7@github.com>
 <Atl6xMdpi2hXD7TtT0jbkfUxhmXKQcYxvvncH9FtxWA=.b3b1dda8-24d2-4b8e-9aed-d2b2aca78567@github.com>
Message-ID: <HM0VqBDspEc4hx0qCeHXsaaE6-vYV6e7dvmcnqwf63g=.cd62b04b-feed-42ac-8135-657cad2b2502@github.com>

On Wed, 18 Aug 2021 04:59:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Have you checked if button does not have any text?

Yes, i did. Neither my code nor native focus painter is affected by it.

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

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

From psadhukhan at openjdk.java.net  Wed Aug 18 05:41:29 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 18 Aug 2021 05:41:29 GMT
Subject: <Swing Dev> RFR: 8269951: [macos] Focus not painted in JButton
 when setBorderPainted(false) is invoked [v6]
In-Reply-To: <tGjFDHKjayfYb5b1x8p3Q6DRIjXKU-oDAvICjhRQCCI=.0fcb9f07-02dc-40f4-948f-61bd0fce8e7b@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
 <tGjFDHKjayfYb5b1x8p3Q6DRIjXKU-oDAvICjhRQCCI=.0fcb9f07-02dc-40f4-948f-61bd0fce8e7b@github.com>
Message-ID: <O_n1N6LFApsaItBhllugnucgKt6CIus6cgudkgcCzqE=.ec62f961-a233-4bf9-a7aa-bd47b8ad4efc@github.com>

On Tue, 17 Aug 2021 06:09:51 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Initial implementation and a test case.
>> 
>> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore Graphics color before leaving paintFocus()

Marked as reviewed by psadhukhan (Reviewer).

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

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

From kizune at openjdk.java.net  Wed Aug 18 05:52:36 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 18 Aug 2021 05:52:36 GMT
Subject: <Swing Dev> Integrated: 8269951: [macos] Focus not painted in
 JButton when setBorderPainted(false) is invoked
In-Reply-To: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
References: <OS2ZfwFc4SpucFIBVonm3KMHU8OYw5nR8utaUfdeNaY=.f2e1dea5-bb3d-498a-905b-641b83a9ef60@github.com>
Message-ID: <HHrwnP5izht6tR7HfKCrC1Hbc-yUtznUPlqMw-R7490=.630c641a-8bcb-4399-a42e-20aef8d2b091@github.com>

On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Initial implementation and a test case.
> 
> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways.

This pull request has now been integrated.

Changeset: 481c1f05
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/481c1f0549e361e8e83fcf0530acc4ebdb60104b
Stats:     121 lines in 2 files changed: 120 ins; 0 del; 1 mod

8269951: [macos] Focus not painted in JButton when  setBorderPainted(false) is invoked

Reviewed-by: serb, psadhukhan

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

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

From psadhukhan at openjdk.java.net  Thu Aug 19 06:21:45 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 19 Aug 2021 06:21:45 GMT
Subject: <Swing Dev> RFR: 8271315: Redo: Nimbus JTree renderer properties
 persist across L&F changes
Message-ID: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>

This is another attempt of fixing JDK-8249674 which created a regression JDK-8266510 for which it was backed out.
This fix reinstates the UIResource properties  for "Tree.leafIcon", "Tree.closedIcon",  "Tree.openIcon", "Tree.selectionForeground",
 "Tree.textForeground", "Tree.selectionBackground", "Tree.textBackground", "Tree.selectionBorderColor" for NimbusLookAndFeel.

The regression which was "when a JTree node is selected, the text should be painted using the selected text color (white), matching the color of the expansion control. Instead, it is painted using the standard color (black)"  is also fixed by this fix, although I could not find any mention of this behaviour in the spec that selected text color should match the expanded icon color
but it's a long standing behaviour, so catered to it.
It was happening because SynthLabelUI#paint when it tries to paint textForeground for cell label, it calls

g.setColor(context.getStyle().getColor(context,
                    ColorType.TEXT_FOREGROUND));


which then calls SynthStyle#getColor where even though cell renderer correctly gets the foreground color, it gets overridden by getColorForState()  because the color is a UIResource and there's no corresponding color defined for that state for Tree.CellRenderer so it uses default "black" color for "text" as defined in skin.laf

else if (type == ColorType.TEXT_FOREGROUND) {
                color = c.getForeground();
            }
        }

        if (color == null || color instanceof UIResource) {
            // Then use what we've locally defined
            color = getColorForState(context, type);
        }


Proposed fix is to check if current foregroundColor for DefaultTreeCellRenderer is UIResouce, then use that color itself.

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

Commit messages:
 - 8271315: Redo: Nimbus JTree renderer properties persist across L&F changes
 - 8271315: Redo: Nimbus JTree renderer properties persist across L&F changes

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

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

From psadhukhan at openjdk.java.net  Thu Aug 19 06:52:26 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 19 Aug 2021 06:52:26 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'." [v2]
In-Reply-To: <SB02HXrKY_4BX1x4_BRWFimGyUzEphyyTdTVFwc5Bj4=.aed71f2a-11cb-45c2-9a6b-3987e2216af3@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
 <0nqEMU7qXaWsN5FR_XWliFSnFbYqyHunxOBVLbBaijo=.478c7b30-c9c9-4657-b3a6-e07a18f4f45b@github.com>
 <yZPTAQJp55aOPLthzqEltNxdPn8xrwQHCmPlP7gAzbw=.376e58a8-85c2-4440-b3e9-c2c45fb99566@github.com>
 <SB02HXrKY_4BX1x4_BRWFimGyUzEphyyTdTVFwc5Bj4=.aed71f2a-11cb-45c2-9a6b-3987e2216af3@github.com>
Message-ID: <kbb8xswAqhM6PxJrbMq-LBygQflZ6haHB--wBDfz0bs=.892a73b8-8ef3-4575-9ed3-730119f075fe@github.com>

On Tue, 17 Aug 2021 12:35:02 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> 
> 
> > Since FIRST failure is java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java
> > I tried to find tests that uses VK_SHIFT key which are ?
> 
> Can you reproduce the failure locally if the tests are run in the same order?

Yes and no. These tests fail in my local system but not with same error message.
It is known that some CI test failures is difficult to reproduce locally due to system configuration and environment configuration(via KVM) in CI is quite different from local personal laptop so timing matters.
Also, it seems that these failures are intermittent. I waited for few days but it has not happened since, so it 's difficult to pinpoint what test timing issue is causing that.

Also, I admit that the test changes are masking this timing issues, but the changes are not wrong. If the original test author had used toLowerCase() initially, I don't think anyone would have objected as the test just checks for new characters without any distinction between lowercase/uppercase and this change would prevent this swing tests from failing.

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

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

From psadhukhan at openjdk.java.net  Thu Aug 19 12:14:24 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 19 Aug 2021 12:14:24 GMT
Subject: <Swing Dev> RFR: 8272148: JDesktopPane:getComponentCount()
 returns one extra than expected with GTKLookAndFeel
In-Reply-To: <lUxopCEx6RHq178RzAu3io3E1NyZKmNynN0FOvpXtHc=.bbcc34fa-3d04-40ed-95b3-0fa9035ddac7@github.com>
References: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
 <JUeC4CVzHpZLBh-HSpoEhQAaC68_CPPlVmfifBa8g8g=.58e3cf41-0b62-40f9-9887-7e2bc248265a@github.com>
 <lUxopCEx6RHq178RzAu3io3E1NyZKmNynN0FOvpXtHc=.bbcc34fa-3d04-40ed-95b3-0fa9035ddac7@github.com>
Message-ID: <nIf-KE8Fa3KFyVr4aTVYQz5J2otGyzgUtS68SWsYxuo=.c7cf6bd1-40ca-42d0-929a-55f46317d858@github.com>

On Mon, 16 Aug 2021 20:48:45 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> The "InternalFrame.useTaskBar" is set true in case of GTKL&F only,

What if we set this property to false and only set under some condition for GTK L&F, what sort of problem we can expect?  Does any jtreg/jck test gets affected if we set it to false?

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

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

From psadhukhan at openjdk.java.net  Thu Aug 19 16:48:46 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 19 Aug 2021 16:48:46 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v5]
In-Reply-To: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
Message-ID: <PU8Rpfyo14yRWHkgl7X4zECibU5t_yRzM4HZon8k634=.c31aeb42-e249-4612-81e2-026849da9cef@github.com>

> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
> Added null check for those cases.

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

  Throw NPE upfront in setter

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4989/files
  - new: https://git.openjdk.java.net/jdk/pull/4989/files/3e1a444d..1351b93c

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

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

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

From aivanov at openjdk.java.net  Thu Aug 19 17:13:21 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 Aug 2021 17:13:21 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'." [v2]
In-Reply-To: <kbb8xswAqhM6PxJrbMq-LBygQflZ6haHB--wBDfz0bs=.892a73b8-8ef3-4575-9ed3-730119f075fe@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
 <0nqEMU7qXaWsN5FR_XWliFSnFbYqyHunxOBVLbBaijo=.478c7b30-c9c9-4657-b3a6-e07a18f4f45b@github.com>
 <yZPTAQJp55aOPLthzqEltNxdPn8xrwQHCmPlP7gAzbw=.376e58a8-85c2-4440-b3e9-c2c45fb99566@github.com>
 <SB02HXrKY_4BX1x4_BRWFimGyUzEphyyTdTVFwc5Bj4=.aed71f2a-11cb-45c2-9a6b-3987e2216af3@github.com>
 <kbb8xswAqhM6PxJrbMq-LBygQflZ6haHB--wBDfz0bs=.892a73b8-8ef3-4575-9ed3-730119f075fe@github.com>
Message-ID: <t_AAkl1ThzkMbOgQHnOR-fgm3_bpbus20IzcpmDZD38=.8b2138a4-463b-4512-b30c-d5443d04055c@github.com>

On Thu, 19 Aug 2021 06:49:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > > Since FIRST failure is java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java
> > > I tried to find tests that uses VK_SHIFT key which are ?
> > 
> > 
> > Can you reproduce the failure locally if the tests are run in the same order?
> 
> Yes and no. These tests fail in my local system but not with same error message.
> It is known that some CI test failures is difficult to reproduce locally due to system configuration and environment configuration(via KVM) in CI is quite different from local personal laptop so timing matters.

Yeah, I know. Local environment is usually faster and more responsive.

> Also, it seems that these failures are intermittent. I waited for few days but it has not happened since, so it 's difficult to pinpoint what test timing issue is causing that.

Do you mean that none of these tests has failed recently?  
Could it be that another test stopped failing and, as a consequence, this test doesn't fail either?

> Also, I admit that the test changes are masking this timing issues, but the changes are not wrong. If the original test author had used toLowerCase() initially, I don't think anyone would have objected as the test just checks for new characters without any distinction between lowercase/uppercase and this change would prevent this swing tests from failing.

I don't see why the original author would've bothered with `toLowerCase` when Shift or Caps Lock is never pressed in the test.

The test doesn't fail if it's run outside the long running test suite, does it? This means the test is correct as it is written now, its failure is caused by another misbehaving test which most likely has left Shift key pressed.

As an experiment, is it possible to log the current state of modifier keys, i.e. Shift, Control, Alt, before the key events are sent to edited table cell? This would confirm our guess whether Shift key is left pressed by a test which ran before.

To be clear, I'm not objecting this change, however, it doesn't feel right to me. At the same time, it's the quickest way to make the test pass. I'm pretty sure most of the tests dealing with text input don't use `toLowerCase` when the actual and expected values are compared.

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

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

From pbansal at openjdk.java.net  Thu Aug 19 19:48:27 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 19 Aug 2021 19:48:27 GMT
Subject: <Swing Dev> RFR: 8272148: JDesktopPane:getComponentCount()
 returns one extra than expected with GTKLookAndFeel
In-Reply-To: <nIf-KE8Fa3KFyVr4aTVYQz5J2otGyzgUtS68SWsYxuo=.c7cf6bd1-40ca-42d0-929a-55f46317d858@github.com>
References: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
 <JUeC4CVzHpZLBh-HSpoEhQAaC68_CPPlVmfifBa8g8g=.58e3cf41-0b62-40f9-9887-7e2bc248265a@github.com>
 <lUxopCEx6RHq178RzAu3io3E1NyZKmNynN0FOvpXtHc=.bbcc34fa-3d04-40ed-95b3-0fa9035ddac7@github.com>
 <nIf-KE8Fa3KFyVr4aTVYQz5J2otGyzgUtS68SWsYxuo=.c7cf6bd1-40ca-42d0-929a-55f46317d858@github.com>
Message-ID: <jmLelIPwF16zPzSwPKEPTZJy-QDVFc6XicH-023pBCU=.b16618c6-8e62-43c3-a9c6-47a5165e4f84@github.com>

On Thu, 19 Aug 2021 12:11:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > The "InternalFrame.useTaskBar" is set true in case of GTKL&F only,
> 
> What if we set this property to false and only set under some condition for GTK L&F, what sort of problem we can expect? Does any jtreg/jck test gets affected if we set it to false?

I just ran a mach5 job with the "InternalFrame.useTaskBar" set to true with GTKL&F. Link in JBS. I do not see any issue due to this. The failures are not related to this change.

My point is that, as discussed in the meeting, this is not related to GTKL&F. Anyone can make a custom container and add some default components and this test will fail for that container. So rather than setting "InternalFrame.useTaskBar" to TRUE for GTL L&F just to solve this issue quickly but wrong way, we should make changes to the spec and state that this is allowed. Similar things could have been done in other components for other L&Fs, which may have not yet been reported.

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

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

From serb at openjdk.java.net  Thu Aug 19 22:44:21 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 19 Aug 2021 22:44:21 GMT
Subject: <Swing Dev> RFR: 8272148: JDesktopPane:getComponentCount()
 returns one extra than expected with GTKLookAndFeel
In-Reply-To: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
References: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
Message-ID: <UKqNodz64IN5ZOQ5W3gnIJuUfI2V2sNOWCEUN7o_spo=.7a75b907-4aa4-4428-8e40-f5b8a5c55c09@github.com>

On Mon, 16 Aug 2021 08:22:35 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> A container may include few default components as children, which are added to it during creation. Due to this, calling function getChildrenCount on a new created instance may return non zero value. This behaviour may vary according to L&F also, as some L&F may add some default components to a container, but other L&F may choose not to do so.
> 
> The current bugs reports that this behaviour looks suspicious as it is expected that a newly created container will have zero  children.
> 
> Current specification is not clear on this whether it is allowed for a container to contain default components or not. The fix make changes to the specification to clarify the same.
> 
> Note: I think this will need a CSR, I will file one after the review is completed

I wonder how the other components handle that. For example, the JComboBox in Aqua L&F is a "compound" element and it contains a text field and button, what does the "getComponentCount" return in that case, wIll we hide internal data from the user?

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

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

From serb at openjdk.java.net  Thu Aug 19 23:03:28 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 19 Aug 2021 23:03:28 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v5]
In-Reply-To: <PU8Rpfyo14yRWHkgl7X4zECibU5t_yRzM4HZon8k634=.c31aeb42-e249-4612-81e2-026849da9cef@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <PU8Rpfyo14yRWHkgl7X4zECibU5t_yRzM4HZon8k634=.c31aeb42-e249-4612-81e2-026849da9cef@github.com>
Message-ID: <axB1rOtK94_5rkkxhs-qUdwAWJ3MtYsFofYjXpz8pGU=.1992c0b7-490d-4a7b-9a21-b4103b1ffadb@github.com>

On Thu, 19 Aug 2021 16:48:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
>> Added null check for those cases.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw NPE upfront in setter

Marked as reviewed by serb (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Fri Aug 20 04:45:26 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 20 Aug 2021 04:45:26 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v5]
In-Reply-To: <PU8Rpfyo14yRWHkgl7X4zECibU5t_yRzM4HZon8k634=.c31aeb42-e249-4612-81e2-026849da9cef@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <PU8Rpfyo14yRWHkgl7X4zECibU5t_yRzM4HZon8k634=.c31aeb42-e249-4612-81e2-026849da9cef@github.com>
Message-ID: <8u_XVzoCTxtSPsnJ5zf-pgqPAZhVv80u9RRaPDgZEPY=.ab0af4e4-fd1c-45d2-9c25-ba976e73807b@github.com>

On Thu, 19 Aug 2021 16:48:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
>> Added null check for those cases.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw NPE upfront in setter

Please review CSR https://bugs.openjdk.java.net/browse/JDK-8272748

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

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

From pbansal at openjdk.java.net  Fri Aug 20 05:44:27 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 20 Aug 2021 05:44:27 GMT
Subject: <Swing Dev> RFR: 8272148: JDesktopPane:getComponentCount()
 returns one extra than expected with GTKLookAndFeel
In-Reply-To: <UKqNodz64IN5ZOQ5W3gnIJuUfI2V2sNOWCEUN7o_spo=.7a75b907-4aa4-4428-8e40-f5b8a5c55c09@github.com>
References: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
 <UKqNodz64IN5ZOQ5W3gnIJuUfI2V2sNOWCEUN7o_spo=.7a75b907-4aa4-4428-8e40-f5b8a5c55c09@github.com>
Message-ID: <sSXOrt1DNAIHe3j-AULkn0YvuQZY1NBAjsmo2AAKjyw=.13766cf4-0de6-42fa-8d6f-7e65627e9b02@github.com>

On Thu, 19 Aug 2021 22:41:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I wonder how the other components handle that. For example, the JComboBox in Aqua L&F is a "compound" element and it contains a text field and button, what does the "getComponentCount" return in that case, wIll we hide internal data from the user?

I just ran the following test for JComboBox for all L&Fs on my Mac. It fails for everyone of them. The test and output is as below. Looks like this test is not being run for all components for all L&Fs. It should give lot of failures I guess.

`

        public static void main(String[] args) throws Exception{
        for (UIManager.LookAndFeelInfo info : UIManager.getInstalledLookAndFeels()) {
            JComboBox<String> container = new JComboBox();
            System.out.println("**************");
            UIManager.setLookAndFeel(info.getClassName());
            System.out.println("Current Look and Feel is "+info.getName());
            if (container.getComponentCount() == 0) {
                System.out.println("Expected : no child components present");
            } else {
                System.out.println("Unexpected : by default the Container has components size " + container.getComponentCount());
                System.out.println("Following are the components present");
                for (Component c : container.getComponents())
                    System.out.println(c);
            }
            System.out.println("**************");
            System.out.println();
        }
    }
   
`

`

**************
Current Look and Feel is Metal
Unexpected : by default the Container has components size 2
Following are the components present
com.apple.laf.AquaComboBoxButton[,0,0,0x0,invalid,alignmentX=0.0,alignmentY=0.5,border=com.apple.laf.AquaButtonBorder$Named at 3bfdc050,flags=12583200,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=javax.swing.plaf.InsetsUIResource[top=0,left=2,bottom=0,right=2],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=false,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=,defaultCapable=true]
javax.swing.CellRendererPane[,0,0,0x0,invalid,hidden]
**************

**************
Current Look and Feel is Nimbus
Unexpected : by default the Container has components size 2
Following are the components present
javax.swing.plaf.metal.MetalComboBoxButton[,0,0,0x0,invalid,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource at 5bb21b69,flags=12583208,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=java.awt.Insets[top=0,left=1,bottom=1,right=3],paintBorder=true,paintFocus=false,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=,defaultCapable=true]
javax.swing.CellRendererPane[,0,0,0x0,invalid,hidden]
**************

**************
Current Look and Feel is CDE/Motif
Unexpected : by default the Container has components size 2
Following are the components present
javax.swing.plaf.synth.SynthArrowButton[ComboBox.arrowButton,0,0,0x0,invalid,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.synth.SynthBorder at 4690b489,flags=12583200,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=javax.swing.plaf.InsetsUIResource[top=0,left=0,bottom=0,right=0],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=,defaultCapable=false]
javax.swing.CellRendererPane[,0,0,0x0,invalid,hidden]
**************

**************
Current Look and Feel is Mac OS X
Unexpected : by default the Container has components size 1
Following are the components present
javax.swing.CellRendererPane[,0,0,0x0,invalid,hidden]
**************

`

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Fri Aug 20 09:48:36 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 20 Aug 2021 09:48:36 GMT
Subject: <Swing Dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop
Message-ID: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>

This is a continuation of

- https://bugs.openjdk.java.net/browse/JDK-6736490
- https://bugs.openjdk.java.net/browse/JDK-8035284
- https://bugs.openjdk.java.net/browse/JDK-8145680
- https://bugs.openjdk.java.net/browse/JDK-8251548

As mentioned in JDK-6736490:

_An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._

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

Commit messages:
 - 8272756: Remove unnecessary explicit initialization of volatile fields in java.desktop

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

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

From psadhukhan at openjdk.java.net  Fri Aug 20 13:08:26 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 20 Aug 2021 13:08:26 GMT
Subject: <Swing Dev> RFR: 8272232:
 javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in
 the cell: 'rededited' but found 'redEDITED'." [v2]
In-Reply-To: <t_AAkl1ThzkMbOgQHnOR-fgm3_bpbus20IzcpmDZD38=.8b2138a4-463b-4512-b30c-d5443d04055c@github.com>
References: <FBhXXyQzZhCETkvNPNgz5kolTVDnRIEhqHAC22g3Xpc=.a7bef483-9299-41ad-bc8e-f9e10d04806d@github.com>
 <0nqEMU7qXaWsN5FR_XWliFSnFbYqyHunxOBVLbBaijo=.478c7b30-c9c9-4657-b3a6-e07a18f4f45b@github.com>
 <yZPTAQJp55aOPLthzqEltNxdPn8xrwQHCmPlP7gAzbw=.376e58a8-85c2-4440-b3e9-c2c45fb99566@github.com>
 <SB02HXrKY_4BX1x4_BRWFimGyUzEphyyTdTVFwc5Bj4=.aed71f2a-11cb-45c2-9a6b-3987e2216af3@github.com>
 <kbb8xswAqhM6PxJrbMq-LBygQflZ6haHB--wBDfz0bs=.892a73b8-8ef3-4575-9ed3-730119f075fe@github.com>
 <t_AAkl1ThzkMbOgQHnOR-fgm3_bpbus20IzcpmDZD38=.8b2138a4-463b-4512-b30c-d5443d04055c@github.com>
Message-ID: <hfMWz8pTPad1RLYokz_pj8ReWJHgE-49j8YS3lF0OR4=.cc5c2e21-3bff-4e90-b7a5-b1190ad12cae@github.com>

On Thu, 19 Aug 2021 17:10:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> As an experiment, is it possible to log the current state of modifier keys, i.e. Shift, Control, Alt, before the key events are sent to edited table cell? This would confirm our guess whether Shift key is left pressed by a test which ran before.

It seems Toolkit.getLockingKetState() can only be called for CAPS_LOCK, NUM_LOCK, SCROLL_LOCK etc and not for modifiers. So, modifier keys can only be obtained from InputEvent.  I used my own event listener inside the MultiResolutionSplashTest to get shift key via isSHiftDown() and run whole java_awt test in CI and it is shown to be "false" in that test so it seems no shift key is pressed at least for this run. 




---------configuration:(4/107)----------
Boot Layer
  add modules: java.desktop            
  add exports: java.desktop/sun.java2d ALL-UNNAMED


----------System.out:(3/102)----------
VK_CAPS_LOCK key state: false
VK_SHIFT pressed key state: false
VK_SHIFT released key state: false
----------System.err:(1/16)----------
STATUS:Passed.
----------rerun:(48/5388)*----------





Maybe someother thing or some other timing issues happened the time these test fails.

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

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

From serb at openjdk.java.net  Fri Aug 20 21:29:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 20 Aug 2021 21:29:25 GMT
Subject: <Swing Dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop
In-Reply-To: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
Message-ID: <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com>

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

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

src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java line 64:

> 62:         Set<Integer> tags = essentialTags;
> 63:         if (tags == null) {
> 64:             essentialTags = Set.of(

What is the purpose of the local tags here?

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

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

From prr at openjdk.java.net  Sun Aug 22 04:15:33 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 22 Aug 2021 04:15:33 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v5]
In-Reply-To: <PU8Rpfyo14yRWHkgl7X4zECibU5t_yRzM4HZon8k634=.c31aeb42-e249-4612-81e2-026849da9cef@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <PU8Rpfyo14yRWHkgl7X4zECibU5t_yRzM4HZon8k634=.c31aeb42-e249-4612-81e2-026849da9cef@github.com>
Message-ID: <3zKhUfwJBq6E0lzazaOS6QDTslMSLSB702Miyz7muqM=.baa845b9-0d92-4157-82b4-b4c6be96486d@github.com>

On Thu, 19 Aug 2021 16:48:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
>> Added null check for those cases.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw NPE upfront in setter

Could you change the bug and CSR summary, and of course the title of this PR ?
I think JinternalFrame does not cause the NPE. It is caused by setting a null desktop icon
Something like
"NPE may be thrown if JDesktopIcon is set to null on a JInternalFrame"

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

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

From serb at openjdk.java.net  Sun Aug 22 06:28:18 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 22 Aug 2021 06:28:18 GMT
Subject: <Swing Dev> RFR: 8272805: Avoid looking up standard charsets
Message-ID: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>

This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
See https://github.com/openjdk/jdk/pull/5063 and https://github.com/openjdk/jdk/pull/4951

In many places standard charsets are looked up via their names, for example:
absolutePath.getBytes("UTF-8");

This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
absolutePath.getBytes(StandardCharsets.UTF_8);

The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.

This change includes:
 * demo/utils
 * jdk.xx packages
 * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. Also checked for "aliases" usage.

Some performance discussion: https://github.com/openjdk/jdk/pull/5063

Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the "java.naming"(the change there is not straightforward, will do it later).

Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

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

Commit messages:
 - Fix related imports
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Cleanup UnsupportedEncodingException
 - Update PacketStream.java
 - Rollback TextTests, should be compatible with jdk1.4
 - Rollback TextRenderTests, should be compatible with jdk1.4
 - Cleanup the UnsupportedEncodingException
 - aliases for ISO_8859_1
 - Update imageio
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/5210/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272805
  Stats: 333 lines in 48 files changed: 91 ins; 123 del; 119 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210

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

From weijun at openjdk.java.net  Sun Aug 22 13:22:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sun, 22 Aug 2021 13:22:38 GMT
Subject: <Swing Dev> RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <0eO4SD_N9lrP5k5bhEejUKXeMauRC8zuc_slUJSrc5c=.c886ae36-5039-450f-9293-5f9910ce432d@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

The security related change looks fine to me.

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

Marked as reviewed by weijun (Reviewer).

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

From alanb at openjdk.java.net  Sun Aug 22 15:12:26 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 22 Aug 2021 15:12:26 GMT
Subject: <Swing Dev> RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <OvTvFnSa61RYUr_VO3fRcnjTkxDwYX0VdqwiiGnveBs=.78ea3741-9e90-447b-909c-be7fedf40f8f@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 342:

> 340: 
> 341:         try {
> 342:             for (String line : Files.readAllLines(statusPath, UTF_8)) {

The 1-arg readAllLines is specified to use UTF-8 so you can drop the second parameter here if you want.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Aug 22 18:34:26 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 22 Aug 2021 18:34:26 GMT
Subject: <Swing Dev> RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <Ng1z8PAjPNJ8IC8xxYp_Px4NlXJ8DWqs6e12eGb5wP0=.09ad1ed7-2788-48cb-a067-76955b5e912c@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

I think it's worth to update _static_ initializer in `sun.datatransfer.DataFlavorUtil.CharsetComparator` too.
![???????????](https://user-images.githubusercontent.com/741251/130366051-ef093bf1-d7d9-4ad1-91e7-5df5af8678af.png)

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

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

From serb at openjdk.java.net  Sun Aug 22 23:02:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 22 Aug 2021 23:02:06 GMT
Subject: <Swing Dev> RFR: 8272805: Avoid looking up standard charsets
 [v2]
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:

 - Update the usage of Files.readAllLines()
 - Update datatransfer
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Fix related imports
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Cleanup UnsupportedEncodingException
 - Update PacketStream.java
 - Rollback TextTests, should be compatible with jdk1.4
 - Rollback TextRenderTests, should be compatible with jdk1.4
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/37357100...e7127644

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5210/files
  - new: https://git.openjdk.java.net/jdk/pull/5210/files/2d9c80b8..e7127644

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

  Stats: 3598 lines in 210 files changed: 2055 ins; 1115 del; 428 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210

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

From naoto at openjdk.java.net  Mon Aug 23 00:26:31 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 23 Aug 2021 00:26:31 GMT
Subject: <Swing Dev> RFR: 8272805: Avoid looking up standard charsets
 [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <YDjqMHQFk2IHLNrmd3MahBp6vvL4D3x4ncTa3PvvQWY=.39eace25-57d6-4981-a1ad-31901c061b25@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/c262b06f...e7127644

Looks good.

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

Marked as reviewed by naoto (Reviewer).

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

From psadhukhan at openjdk.java.net  Mon Aug 23 03:58:49 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 23 Aug 2021 03:58:49 GMT
Subject: <Swing Dev> RFR: 5015261: JInternalFrame causes NPE [v6]
In-Reply-To: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
Message-ID: <Q4SiDAmwknSF7p0wBxUjeLQ9qYj28xhWPDUcaTZJbeI=.2b9f65d4-a040-48eb-8aa4-81799c894d07@github.com>

> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
> Added null check for those cases.

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

  Field spec wording corrected

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4989/files
  - new: https://git.openjdk.java.net/jdk/pull/4989/files/1351b93c..213b2351

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

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Aug 23 06:38:27 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, 23 Aug 2021 06:38:27 GMT
Subject: <Swing Dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop
In-Reply-To: <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com>
Message-ID: <umwDn9Nke1Bnse87ZiQp9k_MyZDXpO45YUFtEXnFU80=.92a2b18b-f32d-4201-94ff-4c75b20e7bd8@github.com>

On Fri, 20 Aug 2021 21:26:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is a continuation of
>> 
>> - https://bugs.openjdk.java.net/browse/JDK-6736490
>> - https://bugs.openjdk.java.net/browse/JDK-8035284
>> - https://bugs.openjdk.java.net/browse/JDK-8145680
>> - https://bugs.openjdk.java.net/browse/JDK-8251548
>> 
>> As mentioned in JDK-6736490:
>> 
>> _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._
>
> src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java line 64:
> 
>> 62:         Set<Integer> tags = essentialTags;
>> 63:         if (tags == null) {
>> 64:             essentialTags = Set.of(
> 
> What is the purpose of the local tags here?

Looks like there's no purpose, `tags` is not used after assignment

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

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

From dfuchs at openjdk.java.net  Mon Aug 23 09:36:40 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 23 Aug 2021 09:36:40 GMT
Subject: <Swing Dev> RFR: 8272805: Avoid looking up standard charsets
 [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <iwz79djzNlUzGYlpBbrLcycsmNcDy3bZF7qc4vozQAI=.e4aa79aa-f9cd-413a-bb5a-dc95023dc410@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/db47f6e1...e7127644

Changes to http server look good to me.

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

Marked as reviewed by dfuchs (Reviewer).

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

From pbansal at openjdk.java.net  Mon Aug 23 11:46:29 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 23 Aug 2021 11:46:29 GMT
Subject: <Swing Dev> RFR: 8272148: JDesktopPane:getComponentCount()
 returns one extra than expected with GTKLookAndFeel
In-Reply-To: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
References: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
Message-ID: <M2DH15krEnnC2tf1ZPou_WPuugHLK0d_k2ln0UCO-JE=.ad0d0249-9f0b-4474-835c-3c660d704b4a@github.com>

On Mon, 16 Aug 2021 08:22:35 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> A container may include few default components as children, which are added to it during creation. Due to this, calling function getChildrenCount on a new created instance may return non zero value. This behaviour may vary according to L&F also, as some L&F may add some default components to a container, but other L&F may choose not to do so.
> 
> The current bugs reports that this behaviour looks suspicious as it is expected that a newly created container will have zero  children.
> 
> Current specification is not clear on this whether it is allowed for a container to contain default components or not. The fix make changes to the specification to clarify the same.
> 
> Note: I think this will need a CSR, I will file one after the review is completed

Gentle Reminder to the reviewers

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

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

From psadhukhan at openjdk.java.net  Mon Aug 23 12:45:53 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 23 Aug 2021 12:45:53 GMT
Subject: <Swing Dev> RFR: 8271923: [macos] the text color on the selected
 disabled tabbed pane button remains white making text unreadable
Message-ID: <CfPWU8kqPqInYwtW5Ddzdj_C1yWCBrEIFDf9buMJixo=.d526022a-431d-4b53-93d2-e827a91bff44@github.com>

It is seen that  if a JTabbedPane is unfocused, it's title is painted with **white** text on grey background 
as opposed to **black** text on grey background in unfoucsed native app on macOSX Catalina
and is somewhat not legible. 
This can be seen with SwingSet2 demo with InternalFrame or JTabbedPane demo and any native app, making focus toggle between the two.

Issue was TabbedPane always draw with "selectedTabTitleNormalColor" which is white. Although Aqua L&F defined selectedTabTitleDisabledColor but it is not used as TabbedPane does not check if focus is there in current frame and draw accordingly, which native app does.

Proposed fix is to check for frame is active or not and draw text color accordingly. 
Since it is not affecting BigSur (where even if native app active or not text is always drawn in same color), it is only restricted to Catalina and lower.

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

Commit messages:
 - Fix
 - Fix

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

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

From aivanov at openjdk.java.net  Mon Aug 23 13:11:29 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 23 Aug 2021 13:11:29 GMT
Subject: <Swing Dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop
In-Reply-To: <umwDn9Nke1Bnse87ZiQp9k_MyZDXpO45YUFtEXnFU80=.92a2b18b-f32d-4201-94ff-4c75b20e7bd8@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com>
 <umwDn9Nke1Bnse87ZiQp9k_MyZDXpO45YUFtEXnFU80=.92a2b18b-f32d-4201-94ff-4c75b20e7bd8@github.com>
Message-ID: <QeTE-KIuatog_Q5dU4BCp8u-U3HarxmHCSfw9uvyEd4=.0ea2627a-d2d5-4185-92cd-2069d9bb3f91@github.com>

On Mon, 23 Aug 2021 06:35:34 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java line 64:
>> 
>>> 62:         Set<Integer> tags = essentialTags;
>>> 63:         if (tags == null) {
>>> 64:             essentialTags = Set.of(
>> 
>> What is the purpose of the local tags here?
>
> Looks like there's no purpose, `tags` is not used after assignment

Maybe it's kind of a protection from a race. Yet it's possible either way: another thread could see `essentialTags == null` before this one initialises the field.

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

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

From prr at openjdk.java.net  Mon Aug 23 16:58:32 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 23 Aug 2021 16:58:32 GMT
Subject: <Swing Dev> RFR: 5015261: NPE may be thrown if JDesktopIcon is
 set to null on a JInternalFrame [v6]
In-Reply-To: <Q4SiDAmwknSF7p0wBxUjeLQ9qYj28xhWPDUcaTZJbeI=.2b9f65d4-a040-48eb-8aa4-81799c894d07@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <Q4SiDAmwknSF7p0wBxUjeLQ9qYj28xhWPDUcaTZJbeI=.2b9f65d4-a040-48eb-8aa4-81799c894d07@github.com>
Message-ID: <6o-u-FsBsNdhiva_Rvky8-7C6es4o1tXe-nvx0Dul3g=.c6045365-5738-4c32-b7cb-28e173302847@github.com>

On Mon, 23 Aug 2021 03:58:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
>> Added null check for those cases.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Field spec wording corrected

Marked as reviewed by prr (Reviewer).

src/java.desktop/share/classes/javax/swing/JInternalFrame.java line 192:

> 190:      * The icon that is displayed when this internal frame is iconified.
> 191:      * Subclassers must ensure this is set to a non-null value
> 192:      * during construction and nor subsequently set this to null.

nor->not (looks like a typo I made in the CSR) as r and t keys are adjacent. I fixed the CSR but you'll have to to fix it here, otherwise seems fine

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

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

From prr at openjdk.java.net  Mon Aug 23 17:08:28 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 23 Aug 2021 17:08:28 GMT
Subject: <Swing Dev> RFR: 8272148: JDesktopPane:getComponentCount()
 returns one extra than expected with GTKLookAndFeel
In-Reply-To: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
References: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
Message-ID: <Wd4xK5VVKVosY-xnDZ00vpiRIiXZvHrQnpr5r1kdLNs=.e0fdf97c-7a8c-42ab-89ba-1f5f66ba6d9d@github.com>

On Mon, 16 Aug 2021 08:22:35 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> A container may include few default components as children, which are added to it during creation. Due to this, calling function getChildrenCount on a new created instance may return non zero value. This behaviour may vary according to L&F also, as some L&F may add some default components to a container, but other L&F may choose not to do so.
> 
> The current bugs reports that this behaviour looks suspicious as it is expected that a newly created container will have zero  children.
> 
> Current specification is not clear on this whether it is allowed for a container to contain default components or not. The fix make changes to the specification to clarify the same.
> 
> Note: I think this will need a CSR, I will file one after the review is completed

> > I wonder how the other components handle that. For example, the JComboBox in Aqua L&F is a "compound" element and it contains a text field and button, what does the "getComponentCount" return in that case, wIll we hide internal data from the user?
> 
> I just ran the following test for JComboBox for all L&Fs on my Mac. It fails for everyone of them. The test and output is as below. Looks like this test is not being run for all components for all L&Fs. It should give lot of failures I guess.

Yep not unexpected which is why I said this needed to be documented at least as high up as JComponent.
And FWIW since nothing said that JComponents are created with no children it is a very weak bug/complaint to begin with !

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

> 183:  * <p>
> 184:  * Containers inherited from <code>JComponent</code> can contain any
> 185:  * number of default components as children. This behaviour can also

can we say "default or initial"

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

> 186:  * change according to look and feel, as some look and feels may add a
> 187:  * default component to a container, where as other look and feels may
> 188:  * choose not to do so.

"a" is not "any number" so you need to make your wording consistent.
Also I think you need to say that even for a specific L&F it may vary depending on configuration properties of the 
JComponent.

And perhaps finish with
"In summary, it is not valid to assume a JComponent has no children just because the application did not directly add them"  ?

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

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

From serb at openjdk.java.net  Mon Aug 23 18:00:28 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 23 Aug 2021 18:00:28 GMT
Subject: <Swing Dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop
In-Reply-To: <QeTE-KIuatog_Q5dU4BCp8u-U3HarxmHCSfw9uvyEd4=.0ea2627a-d2d5-4185-92cd-2069d9bb3f91@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com>
 <umwDn9Nke1Bnse87ZiQp9k_MyZDXpO45YUFtEXnFU80=.92a2b18b-f32d-4201-94ff-4c75b20e7bd8@github.com>
 <QeTE-KIuatog_Q5dU4BCp8u-U3HarxmHCSfw9uvyEd4=.0ea2627a-d2d5-4185-92cd-2069d9bb3f91@github.com>
Message-ID: <aQwgzJ4B4oswyjPwlUna8_ccoFwQsnwtUz9TgUCxVmg=.7802c612-eb73-4b5d-b512-6fa6f829cebc@github.com>

On Mon, 23 Aug 2021 13:08:02 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Looks like there's no purpose, `tags` is not used after assignment
>
> Maybe it's kind of a protection from a race. Yet it's possible either way: another thread could see `essentialTags == null` before this one initialises the field.

I think we can drop it completely.

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

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

From aivanov at openjdk.java.net  Mon Aug 23 18:34:24 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 23 Aug 2021 18:34:24 GMT
Subject: <Swing Dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop
In-Reply-To: <aQwgzJ4B4oswyjPwlUna8_ccoFwQsnwtUz9TgUCxVmg=.7802c612-eb73-4b5d-b512-6fa6f829cebc@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com>
 <umwDn9Nke1Bnse87ZiQp9k_MyZDXpO45YUFtEXnFU80=.92a2b18b-f32d-4201-94ff-4c75b20e7bd8@github.com>
 <QeTE-KIuatog_Q5dU4BCp8u-U3HarxmHCSfw9uvyEd4=.0ea2627a-d2d5-4185-92cd-2069d9bb3f91@github.com>
 <aQwgzJ4B4oswyjPwlUna8_ccoFwQsnwtUz9TgUCxVmg=.7802c612-eb73-4b5d-b512-6fa6f829cebc@github.com>
Message-ID: <xVBLj997Laf-N2IwD8dfI2bzfHvtV1P2ji63kXcc10g=.7127c961-2ddb-49e7-a565-4c3351303952@github.com>

On Mon, 23 Aug 2021 17:57:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Maybe it's kind of a protection from a race. Yet it's possible either way: another thread could see `essentialTags == null` before this one initialises the field.
>
> I think we can drop it completely.

Agree.

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

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

From serb at openjdk.java.net  Mon Aug 23 19:34:34 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 23 Aug 2021 19:34:34 GMT
Subject: <Swing Dev> RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <Ng1z8PAjPNJ8IC8xxYp_Px4NlXJ8DWqs6e12eGb5wP0=.09ad1ed7-2788-48cb-a067-76955b5e912c@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <Ng1z8PAjPNJ8IC8xxYp_Px4NlXJ8DWqs6e12eGb5wP0=.09ad1ed7-2788-48cb-a067-76955b5e912c@github.com>
Message-ID: <KyQxSd0IYEEoEC0acPE16G5CIvwqPTVGVZOP1M9Me8o=.f1d93383-8174-4731-8e16-ef72b415b34a@github.com>

On Sun, 22 Aug 2021 18:31:02 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I think it's worth to update _static_ initializer in `sun.datatransfer.DataFlavorUtil.CharsetComparator` too.

Updated as suggested.

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

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

From serb at openjdk.java.net  Mon Aug 23 19:34:38 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 23 Aug 2021 19:34:38 GMT
Subject: <Swing Dev> RFR: 8272805: Avoid looking up standard charsets
 [v2]
In-Reply-To: <OvTvFnSa61RYUr_VO3fRcnjTkxDwYX0VdqwiiGnveBs=.78ea3741-9e90-447b-909c-be7fedf40f8f@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <OvTvFnSa61RYUr_VO3fRcnjTkxDwYX0VdqwiiGnveBs=.78ea3741-9e90-447b-909c-be7fedf40f8f@github.com>
Message-ID: <aKpPQPgoXRthV1BM7HdtVLagya1bBbQnwQNj68kW_q8=.12c01c5d-b0d5-42a7-b7ce-6a03b5d05b59@github.com>

On Sun, 22 Aug 2021 15:09:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
>> 
>>  - Update the usage of Files.readAllLines()
>>  - Update datatransfer
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Fix related imports
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Cleanup UnsupportedEncodingException
>>  - Update PacketStream.java
>>  - Rollback TextTests, should be compatible with jdk1.4
>>  - Rollback TextRenderTests, should be compatible with jdk1.4
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/465eb90c...e7127644
>
> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 342:
> 
>> 340: 
>> 341:         try {
>> 342:             for (String line : Files.readAllLines(statusPath, UTF_8)) {
> 
> The 1-arg readAllLines is specified to use UTF-8 so you can drop the second parameter here if you want.

Thank you for the suggestion, I have fixed this and a few other places as well.

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

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

From aivanov at openjdk.java.net  Mon Aug 23 19:43:28 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 23 Aug 2021 19:43:28 GMT
Subject: <Swing Dev> RFR: 5015261: NPE may be thrown if JDesktopIcon is
 set to null on a JInternalFrame [v6]
In-Reply-To: <Q4SiDAmwknSF7p0wBxUjeLQ9qYj28xhWPDUcaTZJbeI=.2b9f65d4-a040-48eb-8aa4-81799c894d07@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
 <Q4SiDAmwknSF7p0wBxUjeLQ9qYj28xhWPDUcaTZJbeI=.2b9f65d4-a040-48eb-8aa4-81799c894d07@github.com>
Message-ID: <GV5glk6E4RYCM4Jby5swe112OG160MVz5pL9Y4B3vkE=.a00e22df-eeb4-4db1-a255-66f964670588@github.com>

On Mon, 23 Aug 2021 03:58:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
>> Added null check for those cases.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Field spec wording corrected

Marked as reviewed by aivanov (Reviewer).

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

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

From aivanov at openjdk.java.net  Mon Aug 23 20:07:34 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 23 Aug 2021 20:07:34 GMT
Subject: <Swing Dev> RFR: 8271315: Redo: Nimbus JTree renderer
 properties persist across L&F changes
In-Reply-To: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
References: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
Message-ID: <lJeqzPY9gWeUxKa5TGhMabWgnaPANRHRjMarpRgrxc0=.a8e1d4b0-485d-4671-a7d0-b1009fda4f71@github.com>

On Thu, 19 Aug 2021 06:13:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This is another attempt of fixing JDK-8249674 which created a regression JDK-8266510 for which it was backed out.
> This fix reinstates the UIResource properties  for "Tree.leafIcon", "Tree.closedIcon",  "Tree.openIcon", "Tree.selectionForeground",
>  "Tree.textForeground", "Tree.selectionBackground", "Tree.textBackground", "Tree.selectionBorderColor" for NimbusLookAndFeel.
> 
> The regression which was "when a JTree node is selected, the text should be painted using the selected text color (white), matching the color of the expansion control. Instead, it is painted using the standard color (black)"  is also fixed by this fix, although I could not find any mention of this behaviour in the spec that selected text color should match the expanded icon color
> but it's a long standing behaviour, so catered to it.
> It was happening because SynthLabelUI#paint when it tries to paint textForeground for cell label, it calls
> 
> g.setColor(context.getStyle().getColor(context,
>                     ColorType.TEXT_FOREGROUND));
> 
> 
> which then calls SynthStyle#getColor where even though cell renderer correctly gets the foreground color, it gets overridden by getColorForState()  because the color is a UIResource and there's no corresponding color defined for that state for Tree.CellRenderer so it uses default "black" color for "text" as defined in skin.laf
> 
> else if (type == ColorType.TEXT_FOREGROUND) {
>                 color = c.getForeground();
>             }
>         }
> 
>         if (color == null || color instanceof UIResource) {
>             // Then use what we've locally defined
>             color = getColorForState(context, type);
>         }
> 
> 
> Proposed fix is to check if current foregroundColor for DefaultTreeCellRenderer is UIResouce, then use that color itself.

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/plaf/nimbus/NimbusPropertiesDoNotImplUIResource.java line 45:

> 43:             "Tree.textBackground", "Tree.selectionBorderColor"};
> 44: 
> 45:     private static String failedKeys = null;

This is unnecessary, you initialise it to `null` before the loop over the properties.

test/jdk/javax/swing/plaf/nimbus/NimbusPropertiesDoNotImplUIResource.java line 58:

> 56:                     verifyProperty(propertyKey);
> 57:                 }
> 58:                 if(failedKeys != null) {

Suggestion:

                if (failedKeys != null) {

And in other places too, please.

test/jdk/javax/swing/plaf/nimbus/NimbusPropertiesDoNotImplUIResource.java line 63:

> 61:                             + LF.getClassName());
> 62:                 }
> 63:             } catch(UnsupportedLookAndFeelException e) {

Suggestion:

            } catch (UnsupportedLookAndFeelException e) {

test/jdk/javax/swing/plaf/nimbus/NimbusPropertiesDoNotImplUIResource.java line 70:

> 68: 
> 69:         //Check that the both uiResource option true and false are working for
> 70:         //getDerivedColor method of NimbusLookAndFeel

Suggestion:

        // Check that both uiResource options true and false work for
        // getDerivedColor method of NimbusLookAndFeel

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Aug 23 20:54:36 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 23 Aug 2021 20:54:36 GMT
Subject: <Swing Dev> RFR: 8272805: Avoid looking up standard charsets
 [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <N67-urPlw_TC9qhch8RkndEzRrP3vUMmVDk-e_nEt-g=.b05fa6c6-04b4-449b-8f93-b00ce5f3e81e@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/aaa7beaf...e7127644

Marked as reviewed by turbanoff at github.com (no known OpenJDK username).

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

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

From serb at openjdk.java.net  Mon Aug 23 23:07:29 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 23 Aug 2021 23:07:29 GMT
Subject: <Swing Dev> RFR: 8272148: JDesktopPane:getComponentCount()
 returns one extra than expected with GTKLookAndFeel
In-Reply-To: <Wd4xK5VVKVosY-xnDZ00vpiRIiXZvHrQnpr5r1kdLNs=.e0fdf97c-7a8c-42ab-89ba-1f5f66ba6d9d@github.com>
References: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
 <Wd4xK5VVKVosY-xnDZ00vpiRIiXZvHrQnpr5r1kdLNs=.e0fdf97c-7a8c-42ab-89ba-1f5f66ba6d9d@github.com>
Message-ID: <kMY4SWkjiKOJO5rqTvOQRooF1GGlW4_Yl7XrHavso3k=.4353880b-d73e-419d-bd69-85e9e13c4034@github.com>

On Mon, 23 Aug 2021 16:58:51 GMT, Phil Race <prr at openjdk.org> wrote:

>> A container may include few default components as children, which are added to it during creation. Due to this, calling function getChildrenCount on a new created instance may return non zero value. This behaviour may vary according to L&F also, as some L&F may add some default components to a container, but other L&F may choose not to do so.
>> 
>> The current bugs reports that this behaviour looks suspicious as it is expected that a newly created container will have zero  children.
>> 
>> Current specification is not clear on this whether it is allowed for a container to contain default components or not. The fix make changes to the specification to clarify the same.
>> 
>> Note: I think this will need a CSR, I will file one after the review is completed
>
> src/java.desktop/share/classes/javax/swing/JComponent.java line 185:
> 
>> 183:  * <p>
>> 184:  * Containers inherited from <code>JComponent</code> can contain any
>> 185:  * number of default components as children. This behaviour can also
> 
> can we say "default or initial"

Do we need to say "Containers inherited from JComponent"? For example, JComboBox is just a component, and it is not necessary will be used as a container by the user.
I meant all components inherited from the JComponent are Containers per specification, but not all of them are used as such. And this new statement is applicable to all "JComponents".

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

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

From psadhukhan at openjdk.java.net  Tue Aug 24 04:01:45 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 24 Aug 2021 04:01:45 GMT
Subject: <Swing Dev> RFR: 5015261: NPE may be thrown if JDesktopIcon is
 set to null on a JInternalFrame [v7]
In-Reply-To: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
Message-ID: <yP_FTip2twY446jk8_jD5UNbxRgTQjV69S5J3GskLKQ=.7f43606c-2c7b-466a-920d-8238aa3aa8bf@github.com>

> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
> Added null check for those cases.

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

  Fix typo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4989/files
  - new: https://git.openjdk.java.net/jdk/pull/4989/files/213b2351..7883ce2a

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

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

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

From psadhukhan at openjdk.java.net  Tue Aug 24 04:07:32 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 24 Aug 2021 04:07:32 GMT
Subject: <Swing Dev> Integrated: 5015261: NPE may be thrown if JDesktopIcon
 is set to null on a JInternalFrame
In-Reply-To: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
References: <MKORQ63rDuKQNeubsm9QrtMDIGTpjoJYcvyryu0eVLA=.09228e66-2e57-4544-853e-0470659c0eda@github.com>
Message-ID: <1AqiQVxwTks98PdcSeD_xVQMMUmzjNFzC_h2zpLjv80=.90308e73-136e-4413-8c17-63fe846fb7a2@github.com>

On Wed, 4 Aug 2021 09:02:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called with null value. There are many places in JInternalFrame where getDesktopIcon() is accessed without null check which might cause NPE. 
> Added null check for those cases.

This pull request has now been integrated.

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

5015261: NPE may be thrown if JDesktopIcon is set to null on a JInternalFrame

Reviewed-by: serb, prr, aivanov

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

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

From serb at openjdk.java.net  Tue Aug 24 06:22:38 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 24 Aug 2021 06:22:38 GMT
Subject: <Swing Dev> RFR: 8272863: Replace usages of Collections.sort
 with List.sort call in public java modules
In-Reply-To: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
References: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
Message-ID: <n22FG3rhdgUujlKpiQ-VLosHP3xn9iIgMNNEfAKIi5Q=.54d8b167-2b88-45f2-82cf-009deeead7f4@github.com>

On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Collections.sort is just a wrapper, so it is better to use an instance method directly.

The changes in the src/java.desktop/ looks fine.

Filed: https://bugs.openjdk.java.net/browse/JDK-8272863

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

Marked as reviewed by serb (Reviewer).

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Aug 24 06:22:38 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 24 Aug 2021 06:22:38 GMT
Subject: <Swing Dev> RFR: 8272863: Replace usages of Collections.sort with
 List.sort call in public java modules
Message-ID: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>

Collections.sort is just a wrapper, so it is better to use an instance method directly.

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

Commit messages:
 - [PATCH] Replace usages of Collections.sort with List.sort call in public java modules

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

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

From dfuchs at openjdk.java.net  Tue Aug 24 10:59:27 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 24 Aug 2021 10:59:27 GMT
Subject: <Swing Dev> RFR: 8272863: Replace usages of Collections.sort
 with List.sort call in public java modules
In-Reply-To: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
References: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
Message-ID: <rgQGADaBadgE0VVmCxVNYb43LFPEzx0ESjqwTAuMaJw=.a0e417fb-d421-4744-b285-6c3aae21cf1a@github.com>

On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Collections.sort is just a wrapper, so it is better to use an instance method directly.

java/net and sun/net changes LGTM

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

Marked as reviewed by dfuchs (Reviewer).

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

From azvegint at openjdk.java.net  Tue Aug 24 11:51:26 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 24 Aug 2021 11:51:26 GMT
Subject: <Swing Dev> RFR: 8272863: Replace usages of Collections.sort
 with List.sort call in public java modules
In-Reply-To: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
References: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
Message-ID: <k5Ck1_4soREWDpeZgoGvudNP37O95TDDa26bUugO0kM=.f5a288d4-cd39-46a5-8eff-e161edb549ea@github.com>

On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Collections.sort is just a wrapper, so it is better to use an instance method directly.

There are a bunch of calls to `Collections.sort()` without a comparator specified  (at least in java.desktop):

https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/Spans.java#L144
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/awt/DebugSettings.java#L278
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/swing/text/TextComponentPrintable.java#L787
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultRowSorter.java#L1070
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultRowSorter.java#L1204
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/GroupLayout.java#L2137

It is also a wrapper to `list.sort(null)`. 

Is there any reason to not touch them along with this fix?

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

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

From azvegint at openjdk.java.net  Tue Aug 24 13:09:37 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 24 Aug 2021 13:09:37 GMT
Subject: <Swing Dev> RFR: 8272805: Avoid looking up standard charsets
 [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <cI5w9AqyTY2y-cy5LJA9fbGFkB2s_-hhoVOCP6w0CaE=.d56a95c4-0a92-45e2-944b-0d0e3dce165e@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/8c6e27c3...e7127644

Marked as reviewed by azvegint (Reviewer).

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

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

From naoto at openjdk.java.net  Tue Aug 24 15:55:30 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 24 Aug 2021 15:55:30 GMT
Subject: <Swing Dev> RFR: 8272863: Replace usages of Collections.sort
 with List.sort call in public java modules
In-Reply-To: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
References: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
Message-ID: <tllOTdK7bDrKiMAmTM_BWC7PMLOaUHUnhClUh7gy9fg=.f52bbc1e-f230-4f42-960d-2056e42479a3@github.com>

On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Collections.sort is just a wrapper, so it is better to use an instance method directly.

java.time changes look good.

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

Marked as reviewed by naoto (Reviewer).

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Aug 24 20:21:52 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 24 Aug 2021 20:21:52 GMT
Subject: <Swing Dev> RFR: 8272863: Replace usages of Collections.sort
 with List.sort call in public java modules [v2]
In-Reply-To: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
References: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
Message-ID: <E9Lb_9YqG7u_CsWAoLSmGx9O9eAEUnQdwgaKnHWaGiw=.c6fd6b3b-07ef-4d20-ad85-418bac5c05b6@github.com>

> Collections.sort is just a wrapper, so it is better to use an instance method directly.

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

  8272863: Replace usages of Collections.sort with List.sort call in public java modules
  replace Collections.sort without comparator too

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5229/files
  - new: https://git.openjdk.java.net/jdk/pull/5229/files/e31936a5..d6dfc8bf

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

  Stats: 21 lines in 10 files changed: 0 ins; 4 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5229.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5229/head:pull/5229

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Aug 24 20:21:52 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 24 Aug 2021 20:21:52 GMT
Subject: <Swing Dev> RFR: 8272863: Replace usages of Collections.sort
 with List.sort call in public java modules
In-Reply-To: <k5Ck1_4soREWDpeZgoGvudNP37O95TDDa26bUugO0kM=.f5a288d4-cd39-46a5-8eff-e161edb549ea@github.com>
References: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
 <k5Ck1_4soREWDpeZgoGvudNP37O95TDDa26bUugO0kM=.f5a288d4-cd39-46a5-8eff-e161edb549ea@github.com>
Message-ID: <W1v5nwRtFbMhOUUkevncb8qvoaMKowc4Wd4A5WivgSo=.078449a5-2397-42ba-8b64-d2738e9e0e46@github.com>

On Tue, 24 Aug 2021 11:48:46 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Is there any reason to not touch them along with this fix?

Update them too.

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

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

From serb at openjdk.java.net  Wed Aug 25 04:02:27 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 25 Aug 2021 04:02:27 GMT
Subject: <Swing Dev> RFR: 8271315: Redo: Nimbus JTree renderer
 properties persist across L&F changes
In-Reply-To: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
References: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
Message-ID: <YEw-PS0R2tLhQG4nnJXvBMBw0VgESoTO19cpb4QQy9A=.78afe78b-bfc7-4095-a125-4282879437c7@github.com>

On Thu, 19 Aug 2021 06:13:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This is another attempt of fixing JDK-8249674 which created a regression JDK-8266510 for which it was backed out.
> This fix reinstates the UIResource properties  for "Tree.leafIcon", "Tree.closedIcon",  "Tree.openIcon", "Tree.selectionForeground",
>  "Tree.textForeground", "Tree.selectionBackground", "Tree.textBackground", "Tree.selectionBorderColor" for NimbusLookAndFeel.
> 
> The regression which was "when a JTree node is selected, the text should be painted using the selected text color (white), matching the color of the expansion control. Instead, it is painted using the standard color (black)"  is also fixed by this fix, although I could not find any mention of this behaviour in the spec that selected text color should match the expanded icon color
> but it's a long standing behaviour, so catered to it.
> It was happening because SynthLabelUI#paint when it tries to paint textForeground for cell label, it calls
> 
> g.setColor(context.getStyle().getColor(context,
>                     ColorType.TEXT_FOREGROUND));
> 
> 
> which then calls SynthStyle#getColor where even though cell renderer correctly gets the foreground color, it gets overridden by getColorForState()  because the color is a UIResource and there's no corresponding color defined for that state for Tree.CellRenderer so it uses default "black" color for "text" as defined in skin.laf
> 
> else if (type == ColorType.TEXT_FOREGROUND) {
>                 color = c.getForeground();
>             }
>         }
> 
>         if (color == null || color instanceof UIResource) {
>             // Then use what we've locally defined
>             color = getColorForState(context, type);
>         }
> 
> 
> Proposed fix is to check if current foregroundColor for DefaultTreeCellRenderer is UIResouce, then use that color itself.

I suggest checking that this new test catches the missed JDK-8266510 regression, and improve it if necessary.

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

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

From psadhukhan at openjdk.java.net  Wed Aug 25 04:07:31 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 25 Aug 2021 04:07:31 GMT
Subject: <Swing Dev> RFR: 8271315: Redo: Nimbus JTree renderer
 properties persist across L&F changes
In-Reply-To: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
References: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
Message-ID: <nmbKe7U2_kDL2CsReJ31SIx_cp5tVA5K3WlJ1Ed7gvk=.8e11e925-b2ea-4d3e-a809-409f46d56009@github.com>

On Thu, 19 Aug 2021 06:13:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This is another attempt of fixing JDK-8249674 which created a regression JDK-8266510 for which it was backed out.
> This fix reinstates the UIResource properties  for "Tree.leafIcon", "Tree.closedIcon",  "Tree.openIcon", "Tree.selectionForeground",
>  "Tree.textForeground", "Tree.selectionBackground", "Tree.textBackground", "Tree.selectionBorderColor" for NimbusLookAndFeel.
> 
> The regression which was "when a JTree node is selected, the text should be painted using the selected text color (white), matching the color of the expansion control. Instead, it is painted using the standard color (black)"  is also fixed by this fix, although I could not find any mention of this behaviour in the spec that selected text color should match the expanded icon color
> but it's a long standing behaviour, so catered to it.
> It was happening because SynthLabelUI#paint when it tries to paint textForeground for cell label, it calls
> 
> g.setColor(context.getStyle().getColor(context,
>                     ColorType.TEXT_FOREGROUND));
> 
> 
> which then calls SynthStyle#getColor where even though cell renderer correctly gets the foreground color, it gets overridden by getColorForState()  because the color is a UIResource and there's no corresponding color defined for that state for Tree.CellRenderer so it uses default "black" color for "text" as defined in skin.laf
> 
> else if (type == ColorType.TEXT_FOREGROUND) {
>                 color = c.getForeground();
>             }
>         }
> 
>         if (color == null || color instanceof UIResource) {
>             // Then use what we've locally defined
>             color = getColorForState(context, type);
>         }
> 
> 
> Proposed fix is to check if current foregroundColor for DefaultTreeCellRenderer is UIResouce, then use that color itself.

I tried creating automated test for that but not able to..I can create manual test but sInce it is easily seen in SwingSet2 JTree demo, we can verify that using SwingSet2..

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

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

From psadhukhan at openjdk.java.net  Wed Aug 25 04:11:55 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 25 Aug 2021 04:11:55 GMT
Subject: <Swing Dev> RFR: 8271315: Redo: Nimbus JTree renderer
 properties persist across L&F changes [v2]
In-Reply-To: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
References: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
Message-ID: <i09yzZkiAtzNhvw8xtbcZwQqdpdwhGBA2UwgGh1OGlo=.75afe3d6-5ee0-4912-b439-2ccf080eee8b@github.com>

> This is another attempt of fixing JDK-8249674 which created a regression JDK-8266510 for which it was backed out.
> This fix reinstates the UIResource properties  for "Tree.leafIcon", "Tree.closedIcon",  "Tree.openIcon", "Tree.selectionForeground",
>  "Tree.textForeground", "Tree.selectionBackground", "Tree.textBackground", "Tree.selectionBorderColor" for NimbusLookAndFeel.
> 
> The regression which was "when a JTree node is selected, the text should be painted using the selected text color (white), matching the color of the expansion control. Instead, it is painted using the standard color (black)"  is also fixed by this fix, although I could not find any mention of this behaviour in the spec that selected text color should match the expanded icon color
> but it's a long standing behaviour, so catered to it.
> It was happening because SynthLabelUI#paint when it tries to paint textForeground for cell label, it calls
> 
> g.setColor(context.getStyle().getColor(context,
>                     ColorType.TEXT_FOREGROUND));
> 
> 
> which then calls SynthStyle#getColor where even though cell renderer correctly gets the foreground color, it gets overridden by getColorForState()  because the color is a UIResource and there's no corresponding color defined for that state for Tree.CellRenderer so it uses default "black" color for "text" as defined in skin.laf
> 
> else if (type == ColorType.TEXT_FOREGROUND) {
>                 color = c.getForeground();
>             }
>         }
> 
>         if (color == null || color instanceof UIResource) {
>             // Then use what we've locally defined
>             color = getColorForState(context, type);
>         }
> 
> 
> Proposed fix is to check if current foregroundColor for DefaultTreeCellRenderer is UIResouce, then use that color itself.

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

  Test update

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5178/files
  - new: https://git.openjdk.java.net/jdk/pull/5178/files/ae916628..fb56b957

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

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

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

From serb at openjdk.java.net  Wed Aug 25 04:19:26 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 25 Aug 2021 04:19:26 GMT
Subject: <Swing Dev> RFR: 8271315: Redo: Nimbus JTree renderer
 properties persist across L&F changes
In-Reply-To: <nmbKe7U2_kDL2CsReJ31SIx_cp5tVA5K3WlJ1Ed7gvk=.8e11e925-b2ea-4d3e-a809-409f46d56009@github.com>
References: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
 <nmbKe7U2_kDL2CsReJ31SIx_cp5tVA5K3WlJ1Ed7gvk=.8e11e925-b2ea-4d3e-a809-409f46d56009@github.com>
Message-ID: <xJ1i7LhvIoE4RmIT6o7GHT67KpMF8rsEOX6G-tmpVX8=.9610510f-11ee-487e-b031-62cfeae2221c@github.com>

On Wed, 25 Aug 2021 04:03:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I tried creating automated test for that but not able to..I can create manual test but sInce it is easily seen in SwingSet2 JTree demo, we can verify that using SwingSet2.

I do not think it is so easy reproducible, it was reported externally around nine months after the fix. So it was missed by all our test cycles.

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

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

From psadhukhan at openjdk.java.net  Wed Aug 25 04:22:25 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 25 Aug 2021 04:22:25 GMT
Subject: <Swing Dev> RFR: 8271315: Redo: Nimbus JTree renderer
 properties persist across L&F changes [v2]
In-Reply-To: <i09yzZkiAtzNhvw8xtbcZwQqdpdwhGBA2UwgGh1OGlo=.75afe3d6-5ee0-4912-b439-2ccf080eee8b@github.com>
References: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
 <i09yzZkiAtzNhvw8xtbcZwQqdpdwhGBA2UwgGh1OGlo=.75afe3d6-5ee0-4912-b439-2ccf080eee8b@github.com>
Message-ID: <62IzZePiQiV3UXrxwfkYldiXG_l9Mn3n-wDvw9SW3ME=.a439be7c-9a45-4f07-b8a2-f56aa1d26fcd@github.com>

On Wed, 25 Aug 2021 04:11:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This is another attempt of fixing JDK-8249674 which created a regression JDK-8266510 for which it was backed out.
>> This fix reinstates the UIResource properties  for "Tree.leafIcon", "Tree.closedIcon",  "Tree.openIcon", "Tree.selectionForeground",
>>  "Tree.textForeground", "Tree.selectionBackground", "Tree.textBackground", "Tree.selectionBorderColor" for NimbusLookAndFeel.
>> 
>> The regression which was "when a JTree node is selected, the text should be painted using the selected text color (white), matching the color of the expansion control. Instead, it is painted using the standard color (black)"  is also fixed by this fix, although I could not find any mention of this behaviour in the spec that selected text color should match the expanded icon color
>> but it's a long standing behaviour, so catered to it.
>> It was happening because SynthLabelUI#paint when it tries to paint textForeground for cell label, it calls
>> 
>> g.setColor(context.getStyle().getColor(context,
>>                     ColorType.TEXT_FOREGROUND));
>> 
>> 
>> which then calls SynthStyle#getColor where even though cell renderer correctly gets the foreground color, it gets overridden by getColorForState()  because the color is a UIResource and there's no corresponding color defined for that state for Tree.CellRenderer so it uses default "black" color for "text" as defined in skin.laf
>> 
>> else if (type == ColorType.TEXT_FOREGROUND) {
>>                 color = c.getForeground();
>>             }
>>         }
>> 
>>         if (color == null || color instanceof UIResource) {
>>             // Then use what we've locally defined
>>             color = getColorForState(context, type);
>>         }
>> 
>> 
>> Proposed fix is to check if current foregroundColor for DefaultTreeCellRenderer is UIResouce, then use that color itself.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

It is reproducible but since is only color we tend to miss it since there is no rule that it has to be of that color...As I told, I can create manual test if that is what is needed..

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

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

From psadhukhan at openjdk.java.net  Wed Aug 25 06:11:57 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 25 Aug 2021 06:11:57 GMT
Subject: <Swing Dev> RFR: 8271315: Redo: Nimbus JTree renderer
 properties persist across L&F changes [v3]
In-Reply-To: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
References: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
Message-ID: <ZSaRf7J8330nvYQQGaU3U0WfTI1IonpTDH2iDSEarlI=.e71fcb33-ee5f-4e29-80be-b492255bfd81@github.com>

> This is another attempt of fixing JDK-8249674 which created a regression JDK-8266510 for which it was backed out.
> This fix reinstates the UIResource properties  for "Tree.leafIcon", "Tree.closedIcon",  "Tree.openIcon", "Tree.selectionForeground",
>  "Tree.textForeground", "Tree.selectionBackground", "Tree.textBackground", "Tree.selectionBorderColor" for NimbusLookAndFeel.
> 
> The regression which was "when a JTree node is selected, the text should be painted using the selected text color (white), matching the color of the expansion control. Instead, it is painted using the standard color (black)"  is also fixed by this fix, although I could not find any mention of this behaviour in the spec that selected text color should match the expanded icon color
> but it's a long standing behaviour, so catered to it.
> It was happening because SynthLabelUI#paint when it tries to paint textForeground for cell label, it calls
> 
> g.setColor(context.getStyle().getColor(context,
>                     ColorType.TEXT_FOREGROUND));
> 
> 
> which then calls SynthStyle#getColor where even though cell renderer correctly gets the foreground color, it gets overridden by getColorForState()  because the color is a UIResource and there's no corresponding color defined for that state for Tree.CellRenderer so it uses default "black" color for "text" as defined in skin.laf
> 
> else if (type == ColorType.TEXT_FOREGROUND) {
>                 color = c.getForeground();
>             }
>         }
> 
>         if (color == null || color instanceof UIResource) {
>             // Then use what we've locally defined
>             color = getColorForState(context, type);
>         }
> 
> 
> Proposed fix is to check if current foregroundColor for DefaultTreeCellRenderer is UIResouce, then use that color itself.

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

  Add test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5178/files
  - new: https://git.openjdk.java.net/jdk/pull/5178/files/fb56b957..7be3b9b9

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

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

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

From psadhukhan at openjdk.java.net  Wed Aug 25 06:17:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 25 Aug 2021 06:17:56 GMT
Subject: <Swing Dev> RFR: 8271315: Redo: Nimbus JTree renderer
 properties persist across L&F changes [v4]
In-Reply-To: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
References: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
Message-ID: <iCNef2YGeZNh51uwXuxH0WzlPmDk0RKedCQAoM_VmEM=.a96a1517-00f1-41be-8e5e-ef35261b8f4a@github.com>

> This is another attempt of fixing JDK-8249674 which created a regression JDK-8266510 for which it was backed out.
> This fix reinstates the UIResource properties  for "Tree.leafIcon", "Tree.closedIcon",  "Tree.openIcon", "Tree.selectionForeground",
>  "Tree.textForeground", "Tree.selectionBackground", "Tree.textBackground", "Tree.selectionBorderColor" for NimbusLookAndFeel.
> 
> The regression which was "when a JTree node is selected, the text should be painted using the selected text color (white), matching the color of the expansion control. Instead, it is painted using the standard color (black)"  is also fixed by this fix, although I could not find any mention of this behaviour in the spec that selected text color should match the expanded icon color
> but it's a long standing behaviour, so catered to it.
> It was happening because SynthLabelUI#paint when it tries to paint textForeground for cell label, it calls
> 
> g.setColor(context.getStyle().getColor(context,
>                     ColorType.TEXT_FOREGROUND));
> 
> 
> which then calls SynthStyle#getColor where even though cell renderer correctly gets the foreground color, it gets overridden by getColorForState()  because the color is a UIResource and there's no corresponding color defined for that state for Tree.CellRenderer so it uses default "black" color for "text" as defined in skin.laf
> 
> else if (type == ColorType.TEXT_FOREGROUND) {
>                 color = c.getForeground();
>             }
>         }
> 
>         if (color == null || color instanceof UIResource) {
>             // Then use what we've locally defined
>             color = getColorForState(context, type);
>         }
> 
> 
> Proposed fix is to check if current foregroundColor for DefaultTreeCellRenderer is UIResouce, then use that color itself.

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

  Add test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5178/files
  - new: https://git.openjdk.java.net/jdk/pull/5178/files/7be3b9b9..95b9fb64

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

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

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

From dfuchs at openjdk.java.net  Wed Aug 25 08:33:26 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 25 Aug 2021 08:33:26 GMT
Subject: <Swing Dev> RFR: 8272863: Replace usages of Collections.sort
 with List.sort call in public java modules [v2]
In-Reply-To: <E9Lb_9YqG7u_CsWAoLSmGx9O9eAEUnQdwgaKnHWaGiw=.c6fd6b3b-07ef-4d20-ad85-418bac5c05b6@github.com>
References: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
 <E9Lb_9YqG7u_CsWAoLSmGx9O9eAEUnQdwgaKnHWaGiw=.c6fd6b3b-07ef-4d20-ad85-418bac5c05b6@github.com>
Message-ID: <LPODesgv69r-RQSp7wjCrkrrdLPh0xn5sA-YiWICdOo=.2b690c71-fb37-498d-a794-1d6207a61702@github.com>

On Tue, 24 Aug 2021 20:21:52 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Collections.sort is just a wrapper, so it is better to use an instance method directly.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8272863: Replace usages of Collections.sort with List.sort call in public java modules
>   replace Collections.sort without comparator too

src/java.base/share/classes/java/net/URLPermission.java line 222:

> 220: 
> 221:         List<String> l = normalizeMethods(methods);
> 222:         l.sort(null);

I am not opposed to this change, but I find this is slightly more ugly than `Collections.sort(l)`; so I have to ask: Is there any noticeable benefit?

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

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

From pbansal at openjdk.java.net  Wed Aug 25 10:39:42 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 25 Aug 2021 10:39:42 GMT
Subject: <Swing Dev> RFR: 8272148: JDesktopPane:getComponentCount()
 returns one extra than expected with GTKLookAndFeel [v2]
In-Reply-To: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
References: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
Message-ID: <HhPPilZzDcSakcZDRIOHtY5kNQ1oAvzUrMmH0DEMhRU=.d0e6565b-1bb0-451f-a68b-e198de988d95@github.com>

> A container may include few default components as children, which are added to it during creation. Due to this, calling function getChildrenCount on a new created instance may return non zero value. This behaviour may vary according to L&F also, as some L&F may add some default components to a container, but other L&F may choose not to do so.
> 
> The current bugs reports that this behaviour looks suspicious as it is expected that a newly created container will have zero  children.
> 
> Current specification is not clear on this whether it is allowed for a container to contain default components or not. The fix make changes to the specification to clarify the same.
> 
> Note: I think this will need a CSR, I will file one after the review is completed

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

  Review Comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5121/files
  - new: https://git.openjdk.java.net/jdk/pull/5121/files/86a488c5..ff7edbde

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

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

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

From pbansal at openjdk.java.net  Wed Aug 25 10:39:42 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 25 Aug 2021 10:39:42 GMT
Subject: <Swing Dev> RFR: 8272148: JDesktopPane:getComponentCount()
 returns one extra than expected with GTKLookAndFeel [v2]
In-Reply-To: <kMY4SWkjiKOJO5rqTvOQRooF1GGlW4_Yl7XrHavso3k=.4353880b-d73e-419d-bd69-85e9e13c4034@github.com>
References: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
 <Wd4xK5VVKVosY-xnDZ00vpiRIiXZvHrQnpr5r1kdLNs=.e0fdf97c-7a8c-42ab-89ba-1f5f66ba6d9d@github.com>
 <kMY4SWkjiKOJO5rqTvOQRooF1GGlW4_Yl7XrHavso3k=.4353880b-d73e-419d-bd69-85e9e13c4034@github.com>
Message-ID: <MpZuAq3AdX9GhCLn-OFBN5_uafreton9sjmREhAtgSg=.38ebdd76-c650-4fc6-afef-e8f3e56cf0e3@github.com>

On Mon, 23 Aug 2021 23:04:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JComponent.java line 185:
>> 
>>> 183:  * <p>
>>> 184:  * Containers inherited from <code>JComponent</code> can contain any
>>> 185:  * number of default components as children. This behaviour can also
>> 
>> can we say "default or initial"
>
> Do we need to say "Containers inherited from JComponent"? For example, JComboBox is just a component, and it is not necessary will be used as a container by the user.
> I meant all components inherited from the JComponent are Containers per specification, but not all of them are used as such. And this new statement is applicable to all "JComponents".

I have changed default to "default or initial". I also changed "Containers inherited from JComponent" to just JComponent as I feel Sergey's point makes sense.

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

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

From pbansal at openjdk.java.net  Wed Aug 25 10:39:43 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 25 Aug 2021 10:39:43 GMT
Subject: <Swing Dev> RFR: 8272148: JDesktopPane:getComponentCount()
 returns one extra than expected with GTKLookAndFeel [v2]
In-Reply-To: <Wd4xK5VVKVosY-xnDZ00vpiRIiXZvHrQnpr5r1kdLNs=.e0fdf97c-7a8c-42ab-89ba-1f5f66ba6d9d@github.com>
References: <X1HXBPgdRElywfyaRf5_NO2JXBx-btWPWlk6ANJbtz0=.3bc2da84-d4b7-4451-8493-1bddaca4c977@github.com>
 <Wd4xK5VVKVosY-xnDZ00vpiRIiXZvHrQnpr5r1kdLNs=.e0fdf97c-7a8c-42ab-89ba-1f5f66ba6d9d@github.com>
Message-ID: <5_7Qc-ZQbf3nnDirf4428nwf1QAtlk4cqeKjnZwKDEc=.6f07d725-992f-4466-84e9-6855043243fa@github.com>

On Mon, 23 Aug 2021 17:01:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review Comments
>
> src/java.desktop/share/classes/javax/swing/JComponent.java line 188:
> 
>> 186:  * change according to look and feel, as some look and feels may add a
>> 187:  * default component to a container, where as other look and feels may
>> 188:  * choose not to do so.
> 
> "a" is not "any number" so you need to make your wording consistent.
> Also I think you need to say that even for a specific L&F it may vary depending on configuration properties of the 
> JComponent.
> 
> And perhaps finish with
> "In summary, it is not valid to assume a JComponent has no children just because the application did not directly add them"  ?

Done

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Aug 25 12:50:27 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 25 Aug 2021 12:50:27 GMT
Subject: <Swing Dev> RFR: 8272863: Replace usages of Collections.sort
 with List.sort call in public java modules [v2]
In-Reply-To: <LPODesgv69r-RQSp7wjCrkrrdLPh0xn5sA-YiWICdOo=.2b690c71-fb37-498d-a794-1d6207a61702@github.com>
References: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
 <E9Lb_9YqG7u_CsWAoLSmGx9O9eAEUnQdwgaKnHWaGiw=.c6fd6b3b-07ef-4d20-ad85-418bac5c05b6@github.com>
 <LPODesgv69r-RQSp7wjCrkrrdLPh0xn5sA-YiWICdOo=.2b690c71-fb37-498d-a794-1d6207a61702@github.com>
Message-ID: <cO0fy6NoadcTTsQe3a-IFXKfBz8CwBqTT2biHLwM84g=.0a0639f9-6e95-4b47-a124-71a3308e5fd8@github.com>

On Wed, 25 Aug 2021 08:29:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8272863: Replace usages of Collections.sort with List.sort call in public java modules
>>   replace Collections.sort without comparator too
>
> src/java.base/share/classes/java/net/URLPermission.java line 222:
> 
>> 220: 
>> 221:         List<String> l = normalizeMethods(methods);
>> 222:         l.sort(null);
> 
> I am not opposed to this change, but I find this is slightly more ugly than `Collections.sort(l)`; so I have to ask: Is there any noticeable benefit?

Actually I agree with you.
One more point is that List.sort(null) doesn't check at compile time that class implements `Comparable`. But Collections.sort have this check.
I will revert last commit.
@azvegint are you ok with that?

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

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

From azvegint at openjdk.java.net  Wed Aug 25 13:36:23 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 25 Aug 2021 13:36:23 GMT
Subject: <Swing Dev> RFR: 8272863: Replace usages of Collections.sort
 with List.sort call in public java modules [v2]
In-Reply-To: <cO0fy6NoadcTTsQe3a-IFXKfBz8CwBqTT2biHLwM84g=.0a0639f9-6e95-4b47-a124-71a3308e5fd8@github.com>
References: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
 <E9Lb_9YqG7u_CsWAoLSmGx9O9eAEUnQdwgaKnHWaGiw=.c6fd6b3b-07ef-4d20-ad85-418bac5c05b6@github.com>
 <LPODesgv69r-RQSp7wjCrkrrdLPh0xn5sA-YiWICdOo=.2b690c71-fb37-498d-a794-1d6207a61702@github.com>
 <cO0fy6NoadcTTsQe3a-IFXKfBz8CwBqTT2biHLwM84g=.0a0639f9-6e95-4b47-a124-71a3308e5fd8@github.com>
Message-ID: <tklHDx_kxeaeuPUZAiryIKYa93BfL0fhsP4qR6oito0=.b57528c2-1f66-40e3-ad1f-c01d197ff57c@github.com>

On Wed, 25 Aug 2021 12:47:41 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/URLPermission.java line 222:
>> 
>>> 220: 
>>> 221:         List<String> l = normalizeMethods(methods);
>>> 222:         l.sort(null);
>> 
>> I am not opposed to this change, but I find this is slightly more ugly than `Collections.sort(l)`; so I have to ask: Is there any noticeable benefit?
>
> Actually I agree with you.
> One more point is that List.sort(null) doesn't check at compile time that class implements `Comparable`. But Collections.sort have this check.
> I will revert last commit.
> @azvegint are you ok with that?

No objections.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Aug 25 13:55:50 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 25 Aug 2021 13:55:50 GMT
Subject: <Swing Dev> RFR: 8272863: Replace usages of Collections.sort
 with List.sort call in public java modules [v3]
In-Reply-To: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
References: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
Message-ID: <8nANT75G1bu4pd892DJuQUV-g2p7jm9m5jQb82EWjfs=.0452ad76-845c-49ed-b0f7-df6641ec2102@github.com>

> Collections.sort is just a wrapper, so it is better to use an instance method directly.

Andrey Turbanov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5229/files
  - new: https://git.openjdk.java.net/jdk/pull/5229/files/d6dfc8bf..e31936a5

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

  Stats: 21 lines in 10 files changed: 4 ins; 0 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5229.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5229/head:pull/5229

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

From pbansal at openjdk.java.net  Thu Aug 26 07:25:38 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 26 Aug 2021 07:25:38 GMT
Subject: <Swing Dev> RFR: 8272229:
 BasicSplitPaneDivider:oneTouchExpandableChanged() returns letButton and
 rightButton as null with GTKLookAndFeel.
Message-ID: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>

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

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

Commit messages:
 - 8272229: BasicSplitPaneDivider:oneTouchExpandableChanged() returns leftButton and rightButton as null with GTKLookAndFeel.

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

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

From psadhukhan at openjdk.java.net  Thu Aug 26 12:07:36 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 26 Aug 2021 12:07:36 GMT
Subject: <Swing Dev> Integrated: 8271315: Redo: Nimbus JTree renderer
 properties persist across L&F changes
In-Reply-To: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
References: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
Message-ID: <SH4jTvBEDj_zCRvFepZrceuZW9WFiu7vHcFXBYV2C1s=.1d554074-f6d1-4cd7-a10d-ae1c414d6b31@github.com>

On Thu, 19 Aug 2021 06:13:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This is another attempt of fixing JDK-8249674 which created a regression JDK-8266510 for which it was backed out.
> This fix reinstates the UIResource properties  for "Tree.leafIcon", "Tree.closedIcon",  "Tree.openIcon", "Tree.selectionForeground",
>  "Tree.textForeground", "Tree.selectionBackground", "Tree.textBackground", "Tree.selectionBorderColor" for NimbusLookAndFeel.
> 
> The regression which was "when a JTree node is selected, the text should be painted using the selected text color (white), matching the color of the expansion control. Instead, it is painted using the standard color (black)"  is also fixed by this fix, although I could not find any mention of this behaviour in the spec that selected text color should match the expanded icon color
> but it's a long standing behaviour, so catered to it.
> It was happening because SynthLabelUI#paint when it tries to paint textForeground for cell label, it calls
> 
> g.setColor(context.getStyle().getColor(context,
>                     ColorType.TEXT_FOREGROUND));
> 
> 
> which then calls SynthStyle#getColor where even though cell renderer correctly gets the foreground color, it gets overridden by getColorForState()  because the color is a UIResource and there's no corresponding color defined for that state for Tree.CellRenderer so it uses default "black" color for "text" as defined in skin.laf
> 
> else if (type == ColorType.TEXT_FOREGROUND) {
>                 color = c.getForeground();
>             }
>         }
> 
>         if (color == null || color instanceof UIResource) {
>             // Then use what we've locally defined
>             color = getColorForState(context, type);
>         }
> 
> 
> Proposed fix is to check if current foregroundColor for DefaultTreeCellRenderer is UIResouce, then use that color itself.

This pull request has now been integrated.

Changeset: e43a907f
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e43a907f20f99fa1f788fcbe2e99631dd01578d4
Stats:     279 lines in 5 files changed: 271 ins; 0 del; 8 mod

8271315: Redo: Nimbus JTree renderer properties persist across L&F changes

Reviewed-by: aivanov

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

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

From aivanov at openjdk.java.net  Thu Aug 26 12:29:30 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 26 Aug 2021 12:29:30 GMT
Subject: <Swing Dev> RFR: 8271315: Redo: Nimbus JTree renderer
 properties persist across L&F changes [v2]
In-Reply-To: <62IzZePiQiV3UXrxwfkYldiXG_l9Mn3n-wDvw9SW3ME=.a439be7c-9a45-4f07-b8a2-f56aa1d26fcd@github.com>
References: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
 <i09yzZkiAtzNhvw8xtbcZwQqdpdwhGBA2UwgGh1OGlo=.75afe3d6-5ee0-4912-b439-2ccf080eee8b@github.com>
 <62IzZePiQiV3UXrxwfkYldiXG_l9Mn3n-wDvw9SW3ME=.a439be7c-9a45-4f07-b8a2-f56aa1d26fcd@github.com>
Message-ID: <AKXgo75SBo74p6rBotbuzwTIrzOuSG7Yyfp-voawUF0=.9b930c46-ea94-4017-b7d2-2840e2b9d00a@github.com>

On Wed, 25 Aug 2021 04:19:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is reproducible but since is only color we tend to miss it since there is no rule that it has to be of that color...As I told, I can create manual test if that is what is needed..

A manual test could be better: this way *the issue gets documented*. You could reproduce the issue with SwingSet2 but you have to look for it and remember what to do.

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

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

From aivanov at openjdk.java.net  Thu Aug 26 14:13:27 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 26 Aug 2021 14:13:27 GMT
Subject: <Swing Dev> RFR: 8271315: Redo: Nimbus JTree renderer
 properties persist across L&F changes [v4]
In-Reply-To: <iCNef2YGeZNh51uwXuxH0WzlPmDk0RKedCQAoM_VmEM=.a96a1517-00f1-41be-8e5e-ef35261b8f4a@github.com>
References: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
 <iCNef2YGeZNh51uwXuxH0WzlPmDk0RKedCQAoM_VmEM=.a96a1517-00f1-41be-8e5e-ef35261b8f4a@github.com>
Message-ID: <kxpKWUYiamHQgpQf1PIxoX4v0S6wB3uIMXj-S4vNpds=.e9263aca-83ff-49d7-9874-6d37fa9af94e@github.com>

On Wed, 25 Aug 2021 06:17:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This is another attempt of fixing JDK-8249674 which created a regression JDK-8266510 for which it was backed out.
>> This fix reinstates the UIResource properties  for "Tree.leafIcon", "Tree.closedIcon",  "Tree.openIcon", "Tree.selectionForeground",
>>  "Tree.textForeground", "Tree.selectionBackground", "Tree.textBackground", "Tree.selectionBorderColor" for NimbusLookAndFeel.
>> 
>> The regression which was "when a JTree node is selected, the text should be painted using the selected text color (white), matching the color of the expansion control. Instead, it is painted using the standard color (black)"  is also fixed by this fix, although I could not find any mention of this behaviour in the spec that selected text color should match the expanded icon color
>> but it's a long standing behaviour, so catered to it.
>> It was happening because SynthLabelUI#paint when it tries to paint textForeground for cell label, it calls
>> 
>> g.setColor(context.getStyle().getColor(context,
>>                     ColorType.TEXT_FOREGROUND));
>> 
>> 
>> which then calls SynthStyle#getColor where even though cell renderer correctly gets the foreground color, it gets overridden by getColorForState()  because the color is a UIResource and there's no corresponding color defined for that state for Tree.CellRenderer so it uses default "black" color for "text" as defined in skin.laf
>> 
>> else if (type == ColorType.TEXT_FOREGROUND) {
>>                 color = c.getForeground();
>>             }
>>         }
>> 
>>         if (color == null || color instanceof UIResource) {
>>             // Then use what we've locally defined
>>             color = getColorForState(context, type);
>>         }
>> 
>> 
>> Proposed fix is to check if current foregroundColor for DefaultTreeCellRenderer is UIResouce, then use that color itself.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

I see you've added the manual test. Great!

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

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

From serb at openjdk.java.net  Thu Aug 26 17:42:33 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Aug 2021 17:42:33 GMT
Subject: <Swing Dev> RFR: 8272805: Avoid looking up standard charsets
 [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/be695a9b...e7127644

Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer?

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

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

From github.com+5709644+fdesu at openjdk.java.net  Thu Aug 26 18:33:27 2021
From: github.com+5709644+fdesu at openjdk.java.net (Sergei Ustimenko)
Date: Thu, 26 Aug 2021 18:33:27 GMT
Subject: <Swing Dev> RFR: 8272805: Avoid looking up standard charsets
 [v2]
In-Reply-To: <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
 <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
Message-ID: <vjfSSXTwCTncHGyKQOw5M3cV_bCdmb89ZEFgZ8ggTkQ=.b617da20-0a0c-4b55-8011-184d1932e2aa@github.com>

On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
>> 
>>  - Update the usage of Files.readAllLines()
>>  - Update datatransfer
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Fix related imports
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Cleanup UnsupportedEncodingException
>>  - Update PacketStream.java
>>  - Rollback TextTests, should be compatible with jdk1.4
>>  - Rollback TextRenderTests, should be compatible with jdk1.4
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/810191b6...e7127644
>
> Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer?

@mrserb Not sure if it applies but there are couple of classes in `java.xml` that use charset names instead of standard charsets. Here they are:
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/AnyURIDV.java
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java
- src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.java

would it make sense to go through them as well?

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

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

From serb at openjdk.java.net  Thu Aug 26 18:38:26 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Aug 2021 18:38:26 GMT
Subject: <Swing Dev> RFR: 8272805: Avoid looking up standard charsets
 [v2]
In-Reply-To: <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
 <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
Message-ID: <a97uQJLcPbeqHP6UVqNXMtqDq4bf4GytTvBLl4C5HPk=.3a50dcbe-d199-4df4-9af7-a94f7755bfe3@github.com>

On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
>> 
>>  - Update the usage of Files.readAllLines()
>>  - Update datatransfer
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Fix related imports
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Cleanup UnsupportedEncodingException
>>  - Update PacketStream.java
>>  - Rollback TextTests, should be compatible with jdk1.4
>>  - Rollback TextRenderTests, should be compatible with jdk1.4
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/e5c71cd0...e7127644
>
> Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer?

> @mrserb Not sure if it applies but there are couple of classes in `java.xml` that use charset names instead of standard charsets. 
> would it make sense to go through them as well?

Most of the cases in the XML module are related to the Xerces library, I have skipped it to make the future merges from upstream of that library simpler.

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

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

From serb at openjdk.java.net  Thu Aug 26 19:07:27 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Aug 2021 19:07:27 GMT
Subject: <Swing Dev> RFR: 8271315: Redo: Nimbus JTree renderer
 properties persist across L&F changes [v4]
In-Reply-To: <iCNef2YGeZNh51uwXuxH0WzlPmDk0RKedCQAoM_VmEM=.a96a1517-00f1-41be-8e5e-ef35261b8f4a@github.com>
References: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
 <iCNef2YGeZNh51uwXuxH0WzlPmDk0RKedCQAoM_VmEM=.a96a1517-00f1-41be-8e5e-ef35261b8f4a@github.com>
Message-ID: <SN8ei-2C4n26aK424ttFHhuBmPucP3JspuFBLUHhScs=.4e9701c7-fb08-4816-82ac-422d9874c0b0@github.com>

On Wed, 25 Aug 2021 06:17:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This is another attempt of fixing JDK-8249674 which created a regression JDK-8266510 for which it was backed out.
>> This fix reinstates the UIResource properties  for "Tree.leafIcon", "Tree.closedIcon",  "Tree.openIcon", "Tree.selectionForeground",
>>  "Tree.textForeground", "Tree.selectionBackground", "Tree.textBackground", "Tree.selectionBorderColor" for NimbusLookAndFeel.
>> 
>> The regression which was "when a JTree node is selected, the text should be painted using the selected text color (white), matching the color of the expansion control. Instead, it is painted using the standard color (black)"  is also fixed by this fix, although I could not find any mention of this behaviour in the spec that selected text color should match the expanded icon color
>> but it's a long standing behaviour, so catered to it.
>> It was happening because SynthLabelUI#paint when it tries to paint textForeground for cell label, it calls
>> 
>> g.setColor(context.getStyle().getColor(context,
>>                     ColorType.TEXT_FOREGROUND));
>> 
>> 
>> which then calls SynthStyle#getColor where even though cell renderer correctly gets the foreground color, it gets overridden by getColorForState()  because the color is a UIResource and there's no corresponding color defined for that state for Tree.CellRenderer so it uses default "black" color for "text" as defined in skin.laf
>> 
>> else if (type == ColorType.TEXT_FOREGROUND) {
>>                 color = c.getForeground();
>>             }
>>         }
>> 
>>         if (color == null || color instanceof UIResource) {
>>             // Then use what we've locally defined
>>             color = getColorForState(context, type);
>>         }
>> 
>> 
>> Proposed fix is to check if current foregroundColor for DefaultTreeCellRenderer is UIResouce, then use that color itself.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

I think it was pushed too fast, w/o looking into the new test.

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

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

From aivanov at openjdk.java.net  Thu Aug 26 19:12:27 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 26 Aug 2021 19:12:27 GMT
Subject: <Swing Dev> RFR: 8271315: Redo: Nimbus JTree renderer
 properties persist across L&F changes [v4]
In-Reply-To: <SN8ei-2C4n26aK424ttFHhuBmPucP3JspuFBLUHhScs=.4e9701c7-fb08-4816-82ac-422d9874c0b0@github.com>
References: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
 <iCNef2YGeZNh51uwXuxH0WzlPmDk0RKedCQAoM_VmEM=.a96a1517-00f1-41be-8e5e-ef35261b8f4a@github.com>
 <SN8ei-2C4n26aK424ttFHhuBmPucP3JspuFBLUHhScs=.4e9701c7-fb08-4816-82ac-422d9874c0b0@github.com>
Message-ID: <O4BiAQFUwB4sqnzEUs83X1CUWwCJO9uYqZKjlfj4RQk=.2c86e687-8255-4970-8298-fb8a7ac8a608@github.com>

On Thu, 26 Aug 2021 19:04:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I think it was pushed too fast, w/o looking into the new test.

Yep, it seems so.

I've submitted [JDK-8273043](https://bugs.openjdk.java.net/browse/JDK-8273043) and made the test automatic. I'll create PR after running the test in the CI.

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

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

From aivanov at openjdk.java.net  Thu Aug 26 19:27:32 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 26 Aug 2021 19:27:32 GMT
Subject: <Swing Dev> RFR: 8271315: Redo: Nimbus JTree renderer
 properties persist across L&F changes [v4]
In-Reply-To: <O4BiAQFUwB4sqnzEUs83X1CUWwCJO9uYqZKjlfj4RQk=.2c86e687-8255-4970-8298-fb8a7ac8a608@github.com>
References: <iHNyK8ejd4gF7UF-R7fua1Y5tfTTs4rrJmhGEXCYq54=.e9a7e83d-539f-41ad-9a7e-f7a9e8bb1a06@github.com>
 <iCNef2YGeZNh51uwXuxH0WzlPmDk0RKedCQAoM_VmEM=.a96a1517-00f1-41be-8e5e-ef35261b8f4a@github.com>
 <SN8ei-2C4n26aK424ttFHhuBmPucP3JspuFBLUHhScs=.4e9701c7-fb08-4816-82ac-422d9874c0b0@github.com>
 <O4BiAQFUwB4sqnzEUs83X1CUWwCJO9uYqZKjlfj4RQk=.2c86e687-8255-4970-8298-fb8a7ac8a608@github.com>
Message-ID: <b1zROXAF4zqX_DnGHgR67ETzGpKsDaf8kxXWqkq-0YA=.ee4964d3-80bb-4802-9551-e3c64d1dde84@github.com>

On Thu, 26 Aug 2021 19:09:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I've submitted [JDK-8273043](https://bugs.openjdk.java.net/browse/JDK-8273043) and made the test automatic. I'll create PR after running the test in the CI.

I've open the PR #5269. Testing is in progress.

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

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

From aivanov at openjdk.java.net  Thu Aug 26 19:28:39 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 26 Aug 2021 19:28:39 GMT
Subject: <Swing Dev> RFR: 8273043: [TEST_BUG] Automate
 NimbusJTreeSelTextColor.java
Message-ID: <_106A4do7gAjpYA6dBKdawZoC912qVdEiPNn3fRhG1M=.effe33ed-0e83-44b0-b047-5d4d7ad5dc3d@github.com>

Automated NimbusJTreeSelTextColor.java test which is added under [JDK-8271315](https://bugs.openjdk.java.net/browse/JDK-8271315).

It passes with the recent build of JDK 18.  
It fails with JDK 18 build 7 where [JDK-8266510](https://bugs.openjdk.java.net/browse/JDK-8266510) is not fixed yet:


Exception in thread "main" java.lang.RuntimeException: Unexpected color found: ff000000 at (4, 9);
foreground: ffffffff; background: ff39698a - check image.png
        at NimbusJTreeSelTextColor.checkColors(NimbusJTreeSelTextColor.java:106)
        at NimbusJTreeSelTextColor.main(NimbusJTreeSelTextColor.java:70)


The line is wrapped for readability. In this case the text is black instead of white.

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

Commit messages:
 - 8273043: [TEST_BUG] Automate NimbusJTreeSelTextColor.java

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

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

From serb at openjdk.java.net  Thu Aug 26 20:32:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Aug 2021 20:32:25 GMT
Subject: <Swing Dev> RFR: 8273043: [TEST_BUG] Automate
 NimbusJTreeSelTextColor.java
In-Reply-To: <_106A4do7gAjpYA6dBKdawZoC912qVdEiPNn3fRhG1M=.effe33ed-0e83-44b0-b047-5d4d7ad5dc3d@github.com>
References: <_106A4do7gAjpYA6dBKdawZoC912qVdEiPNn3fRhG1M=.effe33ed-0e83-44b0-b047-5d4d7ad5dc3d@github.com>
Message-ID: <X3GnyZ5JrXCGFPNgVNOyrXbGMJIh-YK0xEEZQZAdA9A=.263b98da-b7c3-4ced-b422-bbc5eb2a85c3@github.com>

On Thu, 26 Aug 2021 19:21:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Automated NimbusJTreeSelTextColor.java test which is added under [JDK-8271315](https://bugs.openjdk.java.net/browse/JDK-8271315).
> 
> It passes with the recent build of JDK 18.  
> It fails with JDK 18 build 7 where [JDK-8266510](https://bugs.openjdk.java.net/browse/JDK-8266510) is not fixed yet:
> 
> 
> Exception in thread "main" java.lang.RuntimeException: Unexpected color found: ff000000 at (4, 9);
> foreground: ffffffff; background: ff39698a - check image.png
>         at NimbusJTreeSelTextColor.checkColors(NimbusJTreeSelTextColor.java:106)
>         at NimbusJTreeSelTextColor.main(NimbusJTreeSelTextColor.java:70)
> 
> 
> The line is wrapped for readability. In this case the text is black instead of white.

test/jdk/javax/swing/plaf/nimbus/NimbusJTreeSelTextColor.java line 70:

> 68:             treeBounds.width -= iconOffset;
> 69:             treeBounds.width -= 2; // crop selection border on the right
> 70:             BufferedImage image = robot.createScreenCapture(treeBounds);

Can we skip the usage of the robot and render it directly to the buffered image? probably this will allow running the test in a headless envirement?

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

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

From aivanov at openjdk.java.net  Thu Aug 26 20:47:29 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 26 Aug 2021 20:47:29 GMT
Subject: <Swing Dev> RFR: 8273043: [TEST_BUG] Automate
 NimbusJTreeSelTextColor.java
In-Reply-To: <X3GnyZ5JrXCGFPNgVNOyrXbGMJIh-YK0xEEZQZAdA9A=.263b98da-b7c3-4ced-b422-bbc5eb2a85c3@github.com>
References: <_106A4do7gAjpYA6dBKdawZoC912qVdEiPNn3fRhG1M=.effe33ed-0e83-44b0-b047-5d4d7ad5dc3d@github.com>
 <X3GnyZ5JrXCGFPNgVNOyrXbGMJIh-YK0xEEZQZAdA9A=.263b98da-b7c3-4ced-b422-bbc5eb2a85c3@github.com>
Message-ID: <X-xHyIg7dfL9KAfPTC88pGfMjUoUQqlTuoYHiZqoTBU=.b956378d-5912-4618-b2ef-d648efcc2907@github.com>

On Thu, 26 Aug 2021 20:29:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Automated NimbusJTreeSelTextColor.java test which is added under [JDK-8271315](https://bugs.openjdk.java.net/browse/JDK-8271315).
>> 
>> It passes with the recent build of JDK 18.  
>> It fails with JDK 18 build 7 where [JDK-8266510](https://bugs.openjdk.java.net/browse/JDK-8266510) is not fixed yet:
>> 
>> 
>> Exception in thread "main" java.lang.RuntimeException: Unexpected color found: ff000000 at (4, 9);
>> foreground: ffffffff; background: ff39698a - check image.png
>>         at NimbusJTreeSelTextColor.checkColors(NimbusJTreeSelTextColor.java:106)
>>         at NimbusJTreeSelTextColor.main(NimbusJTreeSelTextColor.java:70)
>> 
>> 
>> The line is wrapped for readability. In this case the text is black instead of white.
>
> test/jdk/javax/swing/plaf/nimbus/NimbusJTreeSelTextColor.java line 70:
> 
>> 68:             treeBounds.width -= iconOffset;
>> 69:             treeBounds.width -= 2; // crop selection border on the right
>> 70:             BufferedImage image = robot.createScreenCapture(treeBounds);
> 
> Can we skip the usage of the robot and render it directly to the buffered image? probably this will allow running the test in a headless envirement?

I thought about it yet I didn't try that. It should work. Moreover, the test fails on macOS because the UI gets scaled, rendering to BufferedImage directly could avoid this problem.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Aug 26 20:50:27 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 26 Aug 2021 20:50:27 GMT
Subject: <Swing Dev> Integrated: 8272863: Replace usages of Collections.sort
 with List.sort call in public java modules
In-Reply-To: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
References: <qS6vO2ahvJa81M_kLF1dZjoxSyOY4RUtuyVKXowFhY8=.55747b4f-0219-42c8-b606-411c853fedca@github.com>
Message-ID: <lqYPa-rqtUuxTyKEDK843ToLc4_dM0D17PRPBd31L0Y=.168df700-441b-4b85-a3b4-a7a9e8c37df8@github.com>

On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Collections.sort is just a wrapper, so it is better to use an instance method directly.

This pull request has now been integrated.

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

8272863: Replace usages of Collections.sort with List.sort call in public java modules

Reviewed-by: serb, dfuchs, naoto

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

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

From serb at openjdk.java.net  Thu Aug 26 22:13:26 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Aug 2021 22:13:26 GMT
Subject: <Swing Dev> RFR: 8272229:
 BasicSplitPaneDivider:oneTouchExpandableChanged() returns letButton and
 rightButton as null with GTKLookAndFeel.
In-Reply-To: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
Message-ID: <bIp9wRw-hW7IMoPvO2KtZud5c65Jq0cGPEKdLamS_0w=.e8ed72f9-b889-45c8-8fa3-2baac947ad7a@github.com>

On Thu, 26 Aug 2021 07:18:43 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

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

I think that the current test case is wrong, the oneTouchExpandableChanged() should not be called directly, only when the "oneTouchExpandable" property is changed.

So to consider this as a bug the test should trigger the call to the oneTouchExpandableChanged() as a result of the " oneTouchExpandable value change" and then validate the state of the buttons.

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

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

From aivanov at openjdk.java.net  Thu Aug 26 22:22:54 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 26 Aug 2021 22:22:54 GMT
Subject: <Swing Dev> RFR: 8273043: [TEST_BUG] Automate
 NimbusJTreeSelTextColor.java [v2]
In-Reply-To: <_106A4do7gAjpYA6dBKdawZoC912qVdEiPNn3fRhG1M=.effe33ed-0e83-44b0-b047-5d4d7ad5dc3d@github.com>
References: <_106A4do7gAjpYA6dBKdawZoC912qVdEiPNn3fRhG1M=.effe33ed-0e83-44b0-b047-5d4d7ad5dc3d@github.com>
Message-ID: <ty8BOXlbbfie6x7z7cwZNiJxKA2RhURAhjguxxcKAk8=.8b570d90-c43a-4f09-b488-835ea01224e1@github.com>

> Automated NimbusJTreeSelTextColor.java test which is added under [JDK-8271315](https://bugs.openjdk.java.net/browse/JDK-8271315).
> 
> It passes with the recent build of JDK 18.  
> It fails with JDK 18 build 7 where [JDK-8266510](https://bugs.openjdk.java.net/browse/JDK-8266510) is not fixed yet:
> 
> 
> Exception in thread "main" java.lang.RuntimeException: Unexpected color found: ff000000 at (4, 9);
> foreground: ffffffff; background: ff39698a - check image.png
>         at NimbusJTreeSelTextColor.checkColors(NimbusJTreeSelTextColor.java:106)
>         at NimbusJTreeSelTextColor.main(NimbusJTreeSelTextColor.java:70)
> 
> 
> The line is wrapped for readability. In this case the text is black instead of white.

Alexey Ivanov has updated the pull request incrementally with two additional commits since the last revision:

 - Mark the test headless
 - Paint JTree into BufferedImage

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5269/files
  - new: https://git.openjdk.java.net/jdk/pull/5269/files/76a173dd..4bf4e2e2

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

  Stats: 77 lines in 1 file changed: 32 ins; 20 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5269.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5269/head:pull/5269

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

From pbansal at openjdk.java.net  Fri Aug 27 06:41:27 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 27 Aug 2021 06:41:27 GMT
Subject: <Swing Dev> Withdrawn: 8272229:
 BasicSplitPaneDivider:oneTouchExpandableChanged() returns letButton and
 rightButton as null with GTKLookAndFeel.
In-Reply-To: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
Message-ID: <VEGnkgcZ-r1JumQjTcTd7nybnRp5E7dq6IzdxyPUusI=.512e377a-b68c-4bc8-ad42-f2416702846a@github.com>

On Thu, 26 Aug 2021 07:18:43 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

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

This pull request has been closed without being integrated.

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

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

From pbansal at openjdk.java.net  Fri Aug 27 08:53:22 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 27 Aug 2021 08:53:22 GMT
Subject: <Swing Dev> RFR: 8273043: [TEST_BUG] Automate
 NimbusJTreeSelTextColor.java [v2]
In-Reply-To: <ty8BOXlbbfie6x7z7cwZNiJxKA2RhURAhjguxxcKAk8=.8b570d90-c43a-4f09-b488-835ea01224e1@github.com>
References: <_106A4do7gAjpYA6dBKdawZoC912qVdEiPNn3fRhG1M=.effe33ed-0e83-44b0-b047-5d4d7ad5dc3d@github.com>
 <ty8BOXlbbfie6x7z7cwZNiJxKA2RhURAhjguxxcKAk8=.8b570d90-c43a-4f09-b488-835ea01224e1@github.com>
Message-ID: <SfgBu1OqQM-vUZZ9UQO4TGA5GfRk-KY2My5jzCx24mI=.a8462c49-06f4-47c1-a12a-a7f93b58f394@github.com>

On Thu, 26 Aug 2021 22:22:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Automated NimbusJTreeSelTextColor.java test which is added under [JDK-8271315](https://bugs.openjdk.java.net/browse/JDK-8271315).
>> 
>> It passes with the recent build of JDK 18.  
>> It fails with JDK 18 build 7 where [JDK-8266510](https://bugs.openjdk.java.net/browse/JDK-8266510) is not fixed yet:
>> 
>> 
>> Exception in thread "main" java.lang.RuntimeException: Unexpected color found: ff000000 at (4, 9);
>> foreground: ffffffff; background: ff39698a - check image.png
>>         at NimbusJTreeSelTextColor.checkColors(NimbusJTreeSelTextColor.java:106)
>>         at NimbusJTreeSelTextColor.main(NimbusJTreeSelTextColor.java:70)
>> 
>> 
>> The line is wrapped for readability. In this case the text is black instead of white.
>
> Alexey Ivanov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Mark the test headless
>  - Paint JTree into BufferedImage

I assume you must have tested this on headless environment and it must have passed. But is it really necessary to make this headless as we are showing JFrame and setting L&F. I mean these things mostly associate with headful environment.

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

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

From aivanov at openjdk.java.net  Fri Aug 27 09:14:22 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 27 Aug 2021 09:14:22 GMT
Subject: <Swing Dev> RFR: 8273043: [TEST_BUG] Automate
 NimbusJTreeSelTextColor.java [v2]
In-Reply-To: <SfgBu1OqQM-vUZZ9UQO4TGA5GfRk-KY2My5jzCx24mI=.a8462c49-06f4-47c1-a12a-a7f93b58f394@github.com>
References: <_106A4do7gAjpYA6dBKdawZoC912qVdEiPNn3fRhG1M=.effe33ed-0e83-44b0-b047-5d4d7ad5dc3d@github.com>
 <ty8BOXlbbfie6x7z7cwZNiJxKA2RhURAhjguxxcKAk8=.8b570d90-c43a-4f09-b488-835ea01224e1@github.com>
 <SfgBu1OqQM-vUZZ9UQO4TGA5GfRk-KY2My5jzCx24mI=.a8462c49-06f4-47c1-a12a-a7f93b58f394@github.com>
Message-ID: <1b7BynFIBAt5ttaDJ5bLDWnIQwFfw76Ve_3qrix6Swg=.f1bf4ffe-9d6c-45b3-8fb9-856ec9fdf3e6@github.com>

On Fri, 27 Aug 2021 08:50:34 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> I assume you must have tested this on headless environment and it must have passed.

Yes, the test passes. The only exception is macOS: the test fails there either way because the text is rendered with antialiasing and I can't disable font smoothing on macOS. Does anyone know how to disable it?

I'm thinking about skipping macOS altogher.

> But is it really necessary to make this headless as we are showing JFrame and setting L&F. I mean these things mostly associate with headful environment.

We're not showing the frame unless `-show` option is passed to the test. This is mostly for debugging to see the frame and JTree. Showing the frame on a headless host will throw an exception.

There are more headless hosts which can run the test, so a headless test could be run easier and faster than a headful one.

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

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

From serb at openjdk.java.net  Fri Aug 27 16:44:26 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 27 Aug 2021 16:44:26 GMT
Subject: <Swing Dev> RFR: 8273043: [TEST_BUG] Automate
 NimbusJTreeSelTextColor.java [v2]
In-Reply-To: <1b7BynFIBAt5ttaDJ5bLDWnIQwFfw76Ve_3qrix6Swg=.f1bf4ffe-9d6c-45b3-8fb9-856ec9fdf3e6@github.com>
References: <_106A4do7gAjpYA6dBKdawZoC912qVdEiPNn3fRhG1M=.effe33ed-0e83-44b0-b047-5d4d7ad5dc3d@github.com>
 <ty8BOXlbbfie6x7z7cwZNiJxKA2RhURAhjguxxcKAk8=.8b570d90-c43a-4f09-b488-835ea01224e1@github.com>
 <SfgBu1OqQM-vUZZ9UQO4TGA5GfRk-KY2My5jzCx24mI=.a8462c49-06f4-47c1-a12a-a7f93b58f394@github.com>
 <1b7BynFIBAt5ttaDJ5bLDWnIQwFfw76Ve_3qrix6Swg=.f1bf4ffe-9d6c-45b3-8fb9-856ec9fdf3e6@github.com>
Message-ID: <PaCmSUHbdLZo0Y69H6APc4v7Lt2z3ZPPQ2AfGSL1jV4=.96f3f9cb-53e7-452e-bbde-193c88a61419@github.com>

On Fri, 27 Aug 2021 09:10:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Yes, the test passes. The only exception is macOS: the test fails there either way because the text is rendered with antialiasing and I can't disable font smoothing on macOS. Does anyone know how to disable it?
> 
> I'm thinking about skipping macOS altogher.

You can try to change the foregound color in the Nimbus defaults then render it, then compare the part of the images which have the text. If the images are identical then your color was ignored and the bug exists.

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

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

From erikj at openjdk.java.net  Fri Aug 27 17:51:31 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 27 Aug 2021 17:51:31 GMT
Subject: <Swing Dev> RFR: 8272805: Avoid looking up standard charsets
 [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <LEmAelLl1suWas8ISeUc4p87XtgSBWwBTRPz5YSPguo=.6a717c6e-1d62-405e-9f65-2b2949f33c30@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/6af90a19...e7127644

Build tool change looks good.

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

Marked as reviewed by erikj (Reviewer).

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

From pbansal at openjdk.java.net  Mon Aug 30 08:10:28 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 30 Aug 2021 08:10:28 GMT
Subject: <Swing Dev> RFR: 8272229:
 BasicSplitPaneDivider:oneTouchExpandableChanged() returns letButton and
 rightButton as null with GTKLookAndFeel.
In-Reply-To: <bIp9wRw-hW7IMoPvO2KtZud5c65Jq0cGPEKdLamS_0w=.e8ed72f9-b889-45c8-8fa3-2baac947ad7a@github.com>
References: <MrXkTa4QbWSCq9faDzChDIeMUGC6X378JEHy4jfIpd8=.d71d00f8-3e7d-4656-b3b0-575fe1471431@github.com>
 <bIp9wRw-hW7IMoPvO2KtZud5c65Jq0cGPEKdLamS_0w=.e8ed72f9-b889-45c8-8fa3-2baac947ad7a@github.com>
Message-ID: <BlQS42kGWKqxI-oA9yB1k49hvbUBpLfpdK268khj1ms=.cd97d2f9-676b-4530-9159-0a307be7f8b8@github.com>

On Thu, 26 Aug 2021 22:10:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I think that the current test case is wrong, the oneTouchExpandableChanged() should not be called directly, only when the "oneTouchExpandable" property is changed.
> 
> So to consider this as a bug the test should trigger the call to the oneTouchExpandableChanged() as a result of the " oneTouchExpandable value change" and then validate the state of the buttons.

The bug is filled to make the specification to clarify that the behaviour mentioned in specification can change according to the L&F currently being used. That is what the current change is doing. If some L&F does not support oneTouchButtons, the function will not do anything and return.

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

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

From serb at openjdk.java.net  Mon Aug 30 23:46:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Aug 2021 23:46:15 GMT
Subject: <Swing Dev> RFR: 8272805: Avoid looking up standard charsets
 [v3]
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <TqRtp_210_WAMsWmEo00_0RH7ZdcoPgWKC0f5bt0YMQ=.a0f183a7-969d-4601-940e-d8a9558bddee@github.com>

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:

 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Update the usage of Files.readAllLines()
 - Update datatransfer
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Fix related imports
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Cleanup UnsupportedEncodingException
 - Update PacketStream.java
 - Rollback TextTests, should be compatible with jdk1.4
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/22865adf...79829ec8

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5210/files
  - new: https://git.openjdk.java.net/jdk/pull/5210/files/e7127644..79829ec8

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

  Stats: 9423 lines in 339 files changed: 5247 ins; 1917 del; 2259 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210

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

From psadhukhan at openjdk.java.net  Tue Aug 31 06:26:45 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 31 Aug 2021 06:26:45 GMT
Subject: <Swing Dev> RFR: 8268084: [macos] Disabled JMenuItem arrow is not
 disabled
Message-ID: <WxRHHau9pg90x90bi1YkZJP_fOTR4oLoA8UOswtNQH8=.0064bb1c-68d1-4226-ae6f-648fd5afdebd@github.com>

It is seen in macos disabled JMenuItem arrow is not disabled even though JMenuItem itself is disabled.
In native app, same menuitem arrow is disabled for disabled menuitem.

Issue is when AquaMenuPainter#paintMenuItem() is called, it tries to draw a ImageIcon image of the arrow via ImageIcon#paintIcon which tries to generate MultiResolutionCachedImage via getResolutionVariant() by calling AquaUtils#generateFilteredImage.
It does not take into account if disabled arrow icon image needs to be drawn or not, so it is always enabled.

Proposed fix is to generate a disabled ImageIcon image of the same arrow icon and use it for disabled state.

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

Commit messages:
 - 8268084: [macos] Disabled JMenuItem arrow is not disabled

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Aug 31 08:37:36 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 31 Aug 2021 08:37:36 GMT
Subject: <Swing Dev> RFR: 8273168: Remove superfluous use of boxing in
 java.desktop
Message-ID: <ENddbU3bDr91U0nC1Gztf9pIio2dIOzXFlitpqNmoso=.a201e7b5-184c-4424-9609-645095752540@github.com>

parseInt/parseLong/parseShort/parseByte/parseFloat should be preferred, as they return primitives. While valueOf returns boxed object.

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

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

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

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

From aivanov at openjdk.java.net  Tue Aug 31 19:10:53 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 31 Aug 2021 19:10:53 GMT
Subject: <Swing Dev> RFR: 8273043: [TEST_BUG] Automate
 NimbusJTreeSelTextColor.java [v3]
In-Reply-To: <_106A4do7gAjpYA6dBKdawZoC912qVdEiPNn3fRhG1M=.effe33ed-0e83-44b0-b047-5d4d7ad5dc3d@github.com>
References: <_106A4do7gAjpYA6dBKdawZoC912qVdEiPNn3fRhG1M=.effe33ed-0e83-44b0-b047-5d4d7ad5dc3d@github.com>
Message-ID: <mFOcoLLOvrt1yD_m-nnS8eEelpHJUP7GTexNBAqnieQ=.252b5903-8e24-4958-a7c9-632e2f96848b@github.com>

> Automated NimbusJTreeSelTextColor.java test which is added under [JDK-8271315](https://bugs.openjdk.java.net/browse/JDK-8271315).
> 
> It passes with the recent build of JDK 18.  
> It fails with JDK 18 build 7 where [JDK-8266510](https://bugs.openjdk.java.net/browse/JDK-8266510) is not fixed yet:
> 
> 
> Exception in thread "main" java.lang.RuntimeException: Unexpected color found: ff000000 at (4, 9);
> foreground: ffffffff; background: ff39698a - check image.png
>         at NimbusJTreeSelTextColor.checkColors(NimbusJTreeSelTextColor.java:106)
>         at NimbusJTreeSelTextColor.main(NimbusJTreeSelTextColor.java:70)
> 
> 
> The line is wrapped for readability. In this case the text is black instead of white.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Skip macOS: can't disable text antialiasing

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5269/files
  - new: https://git.openjdk.java.net/jdk/pull/5269/files/4bf4e2e2..e3b10bdc

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

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

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

From aivanov at openjdk.java.net  Tue Aug 31 19:32:20 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 31 Aug 2021 19:32:20 GMT
Subject: <Swing Dev> RFR: 8273043: [TEST_BUG] Automate
 NimbusJTreeSelTextColor.java [v2]
In-Reply-To: <PaCmSUHbdLZo0Y69H6APc4v7Lt2z3ZPPQ2AfGSL1jV4=.96f3f9cb-53e7-452e-bbde-193c88a61419@github.com>
References: <_106A4do7gAjpYA6dBKdawZoC912qVdEiPNn3fRhG1M=.effe33ed-0e83-44b0-b047-5d4d7ad5dc3d@github.com>
 <ty8BOXlbbfie6x7z7cwZNiJxKA2RhURAhjguxxcKAk8=.8b570d90-c43a-4f09-b488-835ea01224e1@github.com>
 <SfgBu1OqQM-vUZZ9UQO4TGA5GfRk-KY2My5jzCx24mI=.a8462c49-06f4-47c1-a12a-a7f93b58f394@github.com>
 <1b7BynFIBAt5ttaDJ5bLDWnIQwFfw76Ve_3qrix6Swg=.f1bf4ffe-9d6c-45b3-8fb9-856ec9fdf3e6@github.com>
 <PaCmSUHbdLZo0Y69H6APc4v7Lt2z3ZPPQ2AfGSL1jV4=.96f3f9cb-53e7-452e-bbde-193c88a61419@github.com>
Message-ID: <ayMgvC2eXzThLPLw8t0_D9NdNg1BhzDfWQBnWr20rg4=.2893167a-c922-4578-80ec-f05da5b58b4c@github.com>

On Fri, 27 Aug 2021 16:41:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Yes, the test passes. The only exception is macOS: the test fails there either way because the text is rendered with antialiasing and I can't disable font smoothing on macOS. Does anyone know how to disable it?
> > I'm thinking about skipping macOS altogher.
> 
> You can try to change the foregound color in the Nimbus defaults then render it, then compare the part of the images which have the text. If the images are identical then your color was ignored and the bug exists.

This should work, however, I think it's not worth the effort. Changing the defaults and comparing the two images entirely will make the test more complicated. Nimbus is a platform-independent Look and Feel, the issue is not specific to macOS. The problem is caught on Windows and Linux where one can easily disable text anti-aliasing.

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

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

From serb at openjdk.java.net  Tue Aug 31 20:17:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 31 Aug 2021 20:17:25 GMT
Subject: <Swing Dev> RFR: 8272805: Avoid looking up standard charsets
 [v4]
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <0BjXWeJE25KSeovjDycar9nGsqSQ4vehXgMBrqwWGHQ=.e83aec87-77a8-414d-9acb-bdbdd6bb27ca@github.com>

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:

 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Update the usage of Files.readAllLines()
 - Update datatransfer
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Fix related imports
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Cleanup UnsupportedEncodingException
 - Update PacketStream.java
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/7289121a...7fe0327e

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5210/files
  - new: https://git.openjdk.java.net/jdk/pull/5210/files/79829ec8..7fe0327e

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

  Stats: 949 lines in 30 files changed: 678 ins; 166 del; 105 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210

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

From serb at openjdk.java.net  Tue Aug 31 22:37:47 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 31 Aug 2021 22:37:47 GMT
Subject: <Swing Dev> RFR: 8268084: [macos] Disabled JMenuItem arrow is
 not disabled
In-Reply-To: <WxRHHau9pg90x90bi1YkZJP_fOTR4oLoA8UOswtNQH8=.0064bb1c-68d1-4226-ae6f-648fd5afdebd@github.com>
References: <WxRHHau9pg90x90bi1YkZJP_fOTR4oLoA8UOswtNQH8=.0064bb1c-68d1-4226-ae6f-648fd5afdebd@github.com>
Message-ID: <iEpDN4Vb7o4X8iPkyhTDz5JvMAd5lFGrKS9Ik988W8k=.0a71fbc3-8ba0-4733-81db-23deb08804a9@github.com>

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

> In native app, same menuitem arrow is disabled for disabled menuitem.

How it will work if the "apple.laf.useScreenMenuBar" property is set, will the arrow look the same(disabled) as after this fix?

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

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