From aturbanov at openjdk.org  Thu Sep  1 06:28:11 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 1 Sep 2022 06:28:11 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click
In-Reply-To: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
Message-ID: <8DX6ByDjUI9pIhOkGyzozxV2di1b7XI0dXcDTpWkI2E=.1fc54dee-f22b-4dab-912b-3313cadf44ac@github.com>

On Wed, 24 Aug 2022 07:44:52 GMT, Tejesh R <tr at openjdk.org> wrote:

> JFileChooser.getSelectedFiles() failed to retrieve files with multi-selection and double-click. This occurs when a single file is selected then enable multi-selection then select the same file through mouse double-click(Two file chooser dialogs used before and after multi-selection enabled). SelectedFiles are updated when a change in files/directory selection is done or when selection is made through keyboard selection. In this case since a single file is selected before multi-selection is enabled and same file is selected again without changing the selection index/directory, leaving selected Files un-updated. 
> **Proposed Fix** : Whenever Multi-Selection is enabled check if any files are selected, if yes update the selected Files of JFileChoooser.

src/java.desktop/share/classes/sun/swing/FilePane.java line 1760:

> 1758:             //If selected, retain them and update the selected files in FileChooser class.
> 1759:             File[] selectedFiles = null;
> 1760:             if(getFileChooser().getSelectedFiles().length != 0) {

let's add space after `if`s

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

PR: https://git.openjdk.org/jdk/pull/9996


From tr at openjdk.org  Thu Sep  1 06:40:08 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 1 Sep 2022 06:40:08 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v2]
In-Reply-To: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
Message-ID: <CffGJYwFN0vfbFSdzLpwGGGivp4BcLuX_KbQoBNwPzE=.56090a62-5906-4dc8-a6fe-605392db07ea@github.com>

> JFileChooser.getSelectedFiles() failed to retrieve files with multi-selection and double-click. This occurs when a single file is selected then enable multi-selection then select the same file through mouse double-click(Two file chooser dialogs used before and after multi-selection enabled). SelectedFiles are updated when a change in files/directory selection is done or when selection is made through keyboard selection. In this case since a single file is selected before multi-selection is enabled and same file is selected again without changing the selection index/directory, leaving selected Files un-updated. 
> **Proposed Fix** : Whenever Multi-Selection is enabled check if any files are selected, if yes update the selected Files of JFileChoooser.

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

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9996/files
  - new: https://git.openjdk.org/jdk/pull/9996/files/7129054a..71c936a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9996&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9996&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/9996


From duke at openjdk.org  Thu Sep  1 16:12:49 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 1 Sep 2022 16:12:49 GMT
Subject: RFR: 8287912: GTK L&F : Background of tree icons are red
Message-ID: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>

The background of tree icons are not red in GTK LAF when setOpaque is set to false for tree component.
It has been observed that while painting tree cell background in GTK LAF, a rectangular area is also painted with background color (white). 

Proposed solution is to check the opacity of tree component before drawing tree cell background. If the opacity is set to "false" then the background shouldn't be painted.

An automated test case has been added and checked in CI, link is added in JBS.

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

Commit messages:
 - Whitespace error fixed
 - Fix for tree icon background in GTK LAF

Changes: https://git.openjdk.org/jdk/pull/10112/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10112&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287912
  Stats: 116 lines in 2 files changed: 114 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10112.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10112/head:pull/10112

PR: https://git.openjdk.org/jdk/pull/10112


From prr at openjdk.org  Thu Sep  1 16:15:43 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 Sep 2022 16:15:43 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v22]
In-Reply-To: <Z-TGx99-lIFcZtVy3HVXAK_YQZpx__xyJ9qKtFgSRLc=.c882e45b-1c34-49eb-b806-e1a67d74bf4a@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <NViC-ENZFMOxUzMlAta92OURfx31rHaUaVTeK2jnAXg=.889c8747-a819-44ea-b1af-712c91ccc7b9@github.com>
 <1vIZK9GjFmvSFEiDeXaRrYIm6pF9vwHZkOvGjuhKQ_E=.628cf54f-af74-45ca-81bd-51f99a723753@github.com>
 <Z-TGx99-lIFcZtVy3HVXAK_YQZpx__xyJ9qKtFgSRLc=.c882e45b-1c34-49eb-b806-e1a67d74bf4a@github.com>
Message-ID: <WpACU8gTJx70mWq_zfoVFWdArGaISxMPDlzQgvbDog0=.7b796562-7a3b-4924-a8ee-443ba846ba95@github.com>

On Mon, 22 Aug 2022 09:46:22 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> Since we are displaying file size in one decimal precision, files having size from 1 to 199 byte will be 0.1 KB.

Yes, I see that. My point is it seems wrong.

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

PR: https://git.openjdk.org/jdk/pull/9327


From prr at openjdk.org  Thu Sep  1 16:22:19 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 Sep 2022 16:22:19 GMT
Subject: RFR: 8293088: Fix compilation with the new Visual Studio
 preprocessor
In-Reply-To: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
References: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
Message-ID: <xpxCdT38u_gJD8FpwrKs_xFZp6bj6YPjsaYuyqT2poE=.f4dcefea-3da9-4cf4-9113-cffa25068e5a@github.com>

On Tue, 30 Aug 2022 12:08:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Fix compilation with Zc:preprocessor enabled. 
> 
> The flag itself will be enabled in [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283); I enabled the flag using instructions found in Magnus's comment on that issue.
> 
> Windows 10 SDK version 2104 (10.0.20348.0) is required for successful compilation. Compilation fails with a warning (treated as error by default) with older versions of Windows 10 SDK.
> 
> I verified that the compilation completes successfully with this patch, both in debug and in release mode, both with and without Zc:preprocessor.

Fixing the compilation is one thing. But did you verify that it actually works as intended ?

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

PR: https://git.openjdk.org/jdk/pull/10080


From prr at openjdk.org  Thu Sep  1 16:26:19 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 Sep 2022 16:26:19 GMT
Subject: RFR: 7148092: [macosx] When Alt+down arrow key is pressed,
 the combobox popup does not appear. [v3]
In-Reply-To: <9_6m09UHBqjqrDWnuPS7Imjl3tciQr1q7RCxyOY0xXs=.47f6bcbe-38db-40c5-86b5-4329d5c365ef@github.com>
References: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
 <9_6m09UHBqjqrDWnuPS7Imjl3tciQr1q7RCxyOY0xXs=.47f6bcbe-38db-40c5-86b5-4329d5c365ef@github.com>
Message-ID: <qZ73vv-_D5w5uwUVAnkfn5PSgFn6BY2PO3PO65sAy7g=.2f4cde9e-2601-4499-81b2-c34ffcb3d76d@github.com>

On Thu, 25 Aug 2022 16:34:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When comboBox have focus, pressing Alt+Down (or Up) should render the popup which is not happening for Aqua L&F.
>> 
>> Fix is to add toggleAction for Alt+Down/Up keys as has been done for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L912)
>> 
>> closed problemlisted test is used to check the fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use camelCase

Looks OK to me ..  I presume the closed test now passes . .

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10014


From aivanov at openjdk.org  Thu Sep  1 16:36:35 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 1 Sep 2022 16:36:35 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v25]
In-Reply-To: <Qep3yBG39dxx7SuFQ7G0uVBcAJnvbUFuN6a7fKcbsXs=.f7fea131-2b93-4876-8a35-ccf9a38c6c55@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <Qep3yBG39dxx7SuFQ7G0uVBcAJnvbUFuN6a7fKcbsXs=.f7fea131-2b93-4876-8a35-ccf9a38c6c55@github.com>
Message-ID: <KsP78-nOt4K-hdtbaIDMvCNSbj0Kz0qh8cgPL9NxcJo=.73936add-9fd4-4b86-a1de-818e47289a3d@github.com>

On Fri, 26 Aug 2022 14:30:10 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated as per suggested changes

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 64:

> 62:     public static void test() {
> 63:         JFrame frame = new JFrame("JFileChooser File Size test");
> 64:         JFileChooser fc = new JFileChooser();

If you add,


fc.setControlButtonsAreShown(false);


the panel with _Open_ and _Cancel_ button will be hidden. I think it improves user experience, clicking either button does nothing.

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

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Thu Sep  1 16:49:10 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 1 Sep 2022 16:49:10 GMT
Subject: RFR: 7148092: [macosx] When Alt+down arrow key is pressed,
 the combobox popup does not appear. [v3]
In-Reply-To: <qZ73vv-_D5w5uwUVAnkfn5PSgFn6BY2PO3PO65sAy7g=.2f4cde9e-2601-4499-81b2-c34ffcb3d76d@github.com>
References: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
 <9_6m09UHBqjqrDWnuPS7Imjl3tciQr1q7RCxyOY0xXs=.47f6bcbe-38db-40c5-86b5-4329d5c365ef@github.com>
 <qZ73vv-_D5w5uwUVAnkfn5PSgFn6BY2PO3PO65sAy7g=.2f4cde9e-2601-4499-81b2-c34ffcb3d76d@github.com>
Message-ID: <R5uB8zTwI0tNPu4XHeucEilShFVE4Cq5JrNIXJgt5ew=.bf47ce5b-d18c-4098-b381-ee051fb0aacf@github.com>

On Thu, 1 Sep 2022 16:23:58 GMT, Phil Race <prr at openjdk.org> wrote:

> Looks OK to me .. I presume the closed test now passes . .

Yes, it passes. Will you also review the closed part in orahub as it involves removing the test from PL?

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

PR: https://git.openjdk.org/jdk/pull/10014


From psadhukhan at openjdk.org  Thu Sep  1 17:07:13 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 1 Sep 2022 17:07:13 GMT
Subject: RFR: 8287912: GTK L&F : Background of tree icons are red
In-Reply-To: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
References: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
Message-ID: <Mv1Qs1Uv_3QGF6AoMrLkoHCCWqOWpmczmABbVBE3JWs=.fdcf820d-7b1c-4e12-9a97-643d13a0baa6@github.com>

On Thu, 1 Sep 2022 06:27:17 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> The background of tree icons are not red in GTK LAF when setOpaque is set to false for tree component.
> It has been observed that while painting tree cell background in GTK LAF, a rectangular area is also painted with background color (white). 
> 
> Proposed solution is to check the opacity of tree component before drawing tree cell background. If the opacity is set to "false" then the background shouldn't be painted.
> 
> An automated test case has been added and checked in CI, link is added in JBS.

test/jdk/javax/swing/JTree/TestTreeBackgroundColor.java line 1:

> 1: 

remove this empty line

test/jdk/javax/swing/JTree/TestTreeBackgroundColor.java line 81:

> 79:                     if (c.equals(Color.RED)) {
> 80:                         passed = true;
> 81:                     }

better to check at midpoint tree.width/2, tree.height/2 and also break if it's RED, no need to check all pixels.

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

PR: https://git.openjdk.org/jdk/pull/10112


From duke at openjdk.org  Thu Sep  1 17:37:55 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 1 Sep 2022 17:37:55 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v22]
In-Reply-To: <WpACU8gTJx70mWq_zfoVFWdArGaISxMPDlzQgvbDog0=.7b796562-7a3b-4924-a8ee-443ba846ba95@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <NViC-ENZFMOxUzMlAta92OURfx31rHaUaVTeK2jnAXg=.889c8747-a819-44ea-b1af-712c91ccc7b9@github.com>
 <1vIZK9GjFmvSFEiDeXaRrYIm6pF9vwHZkOvGjuhKQ_E=.628cf54f-af74-45ca-81bd-51f99a723753@github.com>
 <Z-TGx99-lIFcZtVy3HVXAK_YQZpx__xyJ9qKtFgSRLc=.c882e45b-1c34-49eb-b806-e1a67d74bf4a@github.com>
 <WpACU8gTJx70mWq_zfoVFWdArGaISxMPDlzQgvbDog0=.7b796562-7a3b-4924-a8ee-443ba846ba95@github.com>
Message-ID: <yP6XI-vybHsNfkjLwPVyoL4NZMB95eVwQh3KxpA49FY=.24879e4e-ec2d-450a-ab01-973b20356ff6@github.com>

On Thu, 1 Sep 2022 16:13:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> "formatToDouble" method is taking filesize as a long value in parameter and convert it to one decimal precision value. 
>> The reason for converting to one decimal point is to make it similar to native file system which shows file size in one decimal precision.
>> 
>> can "formatToDouble" method rename to "getOneDecimalPrecisionFileSize" ?
>> 
>> Since we are displaying file size in one decimal precision, files having size from 1 to 199 byte will be 0.1 KB. 
>> 1 to 99 byte file size is handled separately otherwise it will show 0.0 KB.
>> 
>> I will add few test case for 100 to 199 byte file.
>
>> Since we are displaying file size in one decimal precision, files having size from 1 to 199 byte will be 0.1 KB.
> 
> Yes, I see that. My point is it seems wrong.

Can you please suggest me what should I do to handle 1 byte to199 bytes ?

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Sep  1 17:37:59 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 1 Sep 2022 17:37:59 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v25]
In-Reply-To: <KsP78-nOt4K-hdtbaIDMvCNSbj0Kz0qh8cgPL9NxcJo=.73936add-9fd4-4b86-a1de-818e47289a3d@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <Qep3yBG39dxx7SuFQ7G0uVBcAJnvbUFuN6a7fKcbsXs=.f7fea131-2b93-4876-8a35-ccf9a38c6c55@github.com>
 <KsP78-nOt4K-hdtbaIDMvCNSbj0Kz0qh8cgPL9NxcJo=.73936add-9fd4-4b86-a1de-818e47289a3d@github.com>
Message-ID: <K_-mB1qCUlQPf_iDkwbFmWZ7nGprUbga-LKgPOvcrvw=.f01bd6fb-3499-446f-a333-c1d40a6d4721@github.com>

On Thu, 1 Sep 2022 16:29:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated as per suggested changes
>
> test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 64:
> 
>> 62:     public static void test() {
>> 63:         JFrame frame = new JFrame("JFileChooser File Size test");
>> 64:         JFileChooser fc = new JFileChooser();
> 
> If you add,
> 
> 
> fc.setControlButtonsAreShown(false);
> 
> 
> the panel with _Open_ and _Cancel_ button will be hidden. I think it improves user experience, clicking either button does nothing.

Yeah sure, I will update it.

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

PR: https://git.openjdk.org/jdk/pull/9327


From prr at openjdk.org  Thu Sep  1 20:24:13 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 Sep 2022 20:24:13 GMT
Subject: RFR: 8293159: Use try-with-resources in
 X11FontManager.registerFontDir
In-Reply-To: <05z0cNBF7JPLVHQGt0B5WBYiZIXwgEey8XEsWG9yCYg=.9ef77c92-2ef1-4e23-ad44-15da001a4a05@github.com>
References: <05z0cNBF7JPLVHQGt0B5WBYiZIXwgEey8XEsWG9yCYg=.9ef77c92-2ef1-4e23-ad44-15da001a4a05@github.com>
Message-ID: <X1rXZ0MbhFPe4SJQJ0GQqes1JuW2PxSX2CXBcMaz5gI=.9ad57c85-9a6a-4a6c-b85b-63dcf69a1eed@github.com>

On Mon, 15 Aug 2022 13:13:33 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Makes code easier to read.

github did not make it easy to compare what should be a trivial diff .

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9879


From djelinski at openjdk.org  Thu Sep  1 20:42:11 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 1 Sep 2022 20:42:11 GMT
Subject: RFR: 8293088: Fix compilation with the new Visual Studio
 preprocessor
In-Reply-To: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
References: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
Message-ID: <N7dMjcy3kc0A4tq5o39qW8ZVp-Q7SzQnJQ-zomAi768=.cab26eb9-a451-435a-9143-e6382eb95c17@github.com>

On Tue, 30 Aug 2022 12:08:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Fix compilation with Zc:preprocessor enabled. 
> 
> The flag itself will be enabled in [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283); I enabled the flag using instructions found in Magnus's comment on that issue.
> 
> Windows 10 SDK version 2104 (10.0.20348.0) is required for successful compilation. Compilation fails with a warning (treated as error by default) with older versions of Windows 10 SDK.
> 
> I verified that the compilation completes successfully with this patch, both in debug and in release mode, both with and without Zc:preprocessor.

I verified that client tests still pass. I also verified on a separate project that merging strings with and without ## is equivalent when Zc:preprocessor is absent. When it is present, merging with ## is an error.

I did not verify the output of the changed macros, but I'm pretty confident that their behavior will not change. If you could suggest a test, I'll be happy to perform it.

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

PR: https://git.openjdk.org/jdk/pull/10080


From prr at openjdk.org  Thu Sep  1 20:43:11 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 Sep 2022 20:43:11 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v10]
In-Reply-To: <3K40K0Roy0-H5dqJr4TqChwOOCRbEQYnsezkiKe3gEw=.6a48b650-6421-4b32-abc9-f1543b554ac9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <3K40K0Roy0-H5dqJr4TqChwOOCRbEQYnsezkiKe3gEw=.6a48b650-6421-4b32-abc9-f1543b554ac9@github.com>
Message-ID: <Ihkbvib2yyDV811hGaHSqrsbb1sjFPUQZK3PeE3yg0Q=.ca018f86-e100-4549-982f-1f70d46d5dac@github.com>

On Mon, 29 Aug 2022 14:24:59 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adds transparent and RGB case insensitive tests.
>   
>   When <rgb()> and <rgba()> values contains at least an uppercase character, getAttribute returns null.
>   When using 'transparent' keyword getAttribute returns null.

Changes requested by prr (Reviewer).

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1398:

> 1396:     static Color stringToColor(String str) {
> 1397:         String strlc = str.toLowerCase(Locale.ROOT);
> 1398:         if (str == null) {

What's the point in testing if it is null after you already de-referenced it ?

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1411:

> 1409:             Color color = colorNamed.get(strlc);
> 1410:             if (color != null) {
> 1411:                 return new Color(color.getRGB(), true);

Can you explain why you can't return the color instance directly ?
They are immutable so I don't see the reason.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1562:

> 1560:             Map.entry("tomato", new Color(255, 99, 71, 255)),
> 1561:             Map.entry("transparent", new Color(0, 0, 0, 0)),
> 1562:             Map.entry("turquoise", new Color(64, 224, 208, 255)),

So all of these have the extra 255 alpha arg just so this ONE entry can be different ? Do you expect others like this ? If not why not special case that in the caller method ?

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

PR: https://git.openjdk.org/jdk/pull/9825


From prr at openjdk.org  Fri Sep  2 00:49:03 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 2 Sep 2022 00:49:03 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v25]
In-Reply-To: <Qep3yBG39dxx7SuFQ7G0uVBcAJnvbUFuN6a7fKcbsXs=.f7fea131-2b93-4876-8a35-ccf9a38c6c55@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <Qep3yBG39dxx7SuFQ7G0uVBcAJnvbUFuN6a7fKcbsXs=.f7fea131-2b93-4876-8a35-ccf9a38c6c55@github.com>
Message-ID: <BQLmYqdoK1-EjLWP0e2u4rJVW4Cy57r-iOCxL0pHjLs=.fa3a7bd5-c1b0-4960-9ea1-4e88d601e16d@github.com>

On Fri, 26 Aug 2022 14:30:10 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated as per suggested changes

AK > Since we are displaying file size in one decimal precision, files having size from 1 to 199 byte will be 0.1 KB.

PR > Yes, I see that. My point is it seems wrong.
 
AK > Can you please suggest me what should I do to handle 1 byte to199 bytes ?

PR : Just consistently round up 
- 0 bytes is 0 kb
- 1-100 bytes is 0.1 kb
- 101-199 bytes is 0.2 kb
- 901 -1000 bytes is 1kb
and so on

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

PR: https://git.openjdk.org/jdk/pull/9327


From dnguyen at openjdk.org  Fri Sep  2 01:17:09 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 2 Sep 2022 01:17:09 GMT
Subject: RFR: 8287912: GTK L&F : Background of tree icons are red
In-Reply-To: <Mv1Qs1Uv_3QGF6AoMrLkoHCCWqOWpmczmABbVBE3JWs=.fdcf820d-7b1c-4e12-9a97-643d13a0baa6@github.com>
References: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
 <Mv1Qs1Uv_3QGF6AoMrLkoHCCWqOWpmczmABbVBE3JWs=.fdcf820d-7b1c-4e12-9a97-643d13a0baa6@github.com>
Message-ID: <5rfMGeAuR5EKbTbfDnwIu-7fkuKXMilG8YywPHbfH7s=.5532e2d9-923a-40e2-bbff-e0a9b18dfd17@github.com>

On Thu, 1 Sep 2022 16:56:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The background of tree icons are not red in GTK LAF when setOpaque is set to false for tree component.
>> It has been observed that while painting tree cell background in GTK LAF, a rectangular area is also painted with background color (white). 
>> 
>> Proposed solution is to check the opacity of tree component before drawing tree cell background. If the opacity is set to "false" then the background shouldn't be painted.
>> 
>> An automated test case has been added and checked in CI, link is added in JBS.
>
> test/jdk/javax/swing/JTree/TestTreeBackgroundColor.java line 81:
> 
>> 79:                     if (c.equals(Color.RED)) {
>> 80:                         passed = true;
>> 81:                     }
> 
> better to check at midpoint tree.width/2, tree.height/2 and also break if it's RED, no need to check all pixels.

Another possible solution that I used in a previous test was a midpoint as suggested, but also one pixel near each edge. This eliminates the chance of the red still existing but not being detected at the midpoint because the red is at a different location.

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

PR: https://git.openjdk.org/jdk/pull/10112


From tr at openjdk.org  Fri Sep  2 05:49:43 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 2 Sep 2022 05:49:43 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v2]
In-Reply-To: <8DX6ByDjUI9pIhOkGyzozxV2di1b7XI0dXcDTpWkI2E=.1fc54dee-f22b-4dab-912b-3313cadf44ac@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <8DX6ByDjUI9pIhOkGyzozxV2di1b7XI0dXcDTpWkI2E=.1fc54dee-f22b-4dab-912b-3313cadf44ac@github.com>
Message-ID: <Go3Kj0VWKN6MW9m9g4MWzNnyUaJULIIUawTGuvOLXpk=.60f77d7e-1f54-4966-9bce-dac01f81a855@github.com>

On Thu, 1 Sep 2022 06:24:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1760:
> 
>> 1758:             //If selected, retain them and update the selected files in FileChooser class.
>> 1759:             File[] selectedFiles = null;
>> 1760:             if(getFileChooser().getSelectedFiles().length != 0) {
> 
> let's add space after `if`s

Updated.

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

PR: https://git.openjdk.org/jdk/pull/9996


From djelinski at openjdk.org  Fri Sep  2 05:55:43 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 2 Sep 2022 05:55:43 GMT
Subject: RFR: 8293088: Fix compilation with the new Visual Studio
 preprocessor
In-Reply-To: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
References: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
Message-ID: <x-L4S9dK3F9qy_KiAyfhEFAPkPaOz08sdO2uP5CRPis=.51b3a808-3b39-42eb-80ac-e23cc4a65ca1@github.com>

On Tue, 30 Aug 2022 12:08:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Fix compilation with Zc:preprocessor enabled. 
> 
> The flag itself will be enabled in [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283); I enabled the flag using instructions found in Magnus's comment on that issue.
> 
> Windows 10 SDK version 2104 (10.0.20348.0) is required for successful compilation. Compilation fails with a warning (treated as error by default) with older versions of Windows 10 SDK.
> 
> I verified that the compilation completes successfully with this patch, both in debug and in release mode, both with and without Zc:preprocessor.

FWIW, here's the test that I used:


#include <stdio.h>

#define PRINTERR(res) \
  PRINT(res, " " ## #res ## " in file " __FILE__);
  
#define PRINT(res, msg) \
  printf("- " ## msg ## " val=%d\n", res);
  
int main() {
	for (int i = 0; i < 2; i++) {
		PRINTERR(i);
	}
}

Output:

-  i in file test.c val=0
-  i in file test.c val=1

removing `##` does not change the output.

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

PR: https://git.openjdk.org/jdk/pull/10080


From jdv at openjdk.org  Fri Sep  2 06:15:51 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 2 Sep 2022 06:15:51 GMT
Subject: RFR: 8287912: GTK L&F : Background of tree icons are red
In-Reply-To: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
References: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
Message-ID: <_bIYExydlnYYOOicYeV0d5ytc4dW8Vp3Es-Ep4tLc1o=.7150c1ca-1fcd-4e26-a6d9-b4781f1f6da7@github.com>

On Thu, 1 Sep 2022 06:27:17 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> The background of tree icons are not red in GTK LAF when setOpaque is set to false for tree component.
> It has been observed that while painting tree cell background in GTK LAF, a rectangular area is also painted with background color (white). 
> 
> Proposed solution is to check the opacity of tree component before drawing tree cell background. If the opacity is set to "false" then the background shouldn't be painted.
> 
> An automated test case has been added and checked in CI, link is added in JBS.

test/jdk/javax/swing/JTree/TestTreeBackgroundColor.java line 84:

> 82:                 }
> 83:             }
> 84:             if (!passed) {

This test will pass even in the case of last pixel check is RED. We should check for pixel data and whenever it is not RED we should bail out.

Also if test fails it will leave TreeBackgroundColorTestFail.png, we should use temporary file and delete it on exit.

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

PR: https://git.openjdk.org/jdk/pull/10112


From duke at openjdk.org  Fri Sep  2 07:06:54 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 2 Sep 2022 07:06:54 GMT
Subject: RFR: 8287912: GTK L&F : Background of tree icons are red [v2]
In-Reply-To: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
References: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
Message-ID: <BAFYnQ4EaVOcpQ-w4PERn4-uIzGbqt2JbpHdLuga02M=.8e99ab7f-ab25-49df-af4b-6aca31be4046@github.com>

> The background of tree icons are not red in GTK LAF when setOpaque is set to false for tree component.
> It has been observed that while painting tree cell background in GTK LAF, a rectangular area is also painted with background color (white). 
> 
> Proposed solution is to check the opacity of tree component before drawing tree cell background. If the opacity is set to "false" then the background shouldn't be painted.
> 
> An automated test case has been added and checked in CI, link is added in JBS.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Review Comments fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10112/files
  - new: https://git.openjdk.org/jdk/pull/10112/files/17d61005..fb3db43f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10112&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10112&range=00-01

  Stats: 8 lines in 1 file changed: 0 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10112.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10112/head:pull/10112

PR: https://git.openjdk.org/jdk/pull/10112


From psadhukhan at openjdk.org  Fri Sep  2 07:16:41 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 2 Sep 2022 07:16:41 GMT
Subject: RFR: 8292948: JEditorPane ignores font-size styles in external
 linked css-file [v3]
In-Reply-To: <DdTUT7vC4FVOCZdCPTiEegnyq8vi9uXgLddgU0rCJuo=.9a817522-794d-47a3-923e-540d9cf2d973@github.com>
References: <CXQy2fQCcs9PeBtCtUZmEdKhx9le3CQxQQAf564QVTM=.e448a883-d2e3-425d-aaa4-1b9d32431b60@github.com>
 <DdTUT7vC4FVOCZdCPTiEegnyq8vi9uXgLddgU0rCJuo=.9a817522-794d-47a3-923e-540d9cf2d973@github.com>
Message-ID: <IAmwJkxY2YsJOeoXyDY7yj9Z9VQZ9LvanCHMP4lMW0k=.a978bfcc-e1bc-4967-9ed1-6b9574841b81@github.com>

On Sun, 28 Aug 2022 05:14:08 GMT, Stanimir Stamenkov <duke at openjdk.org> wrote:

>> [JDK-8292948] reveals a regression by the fix for [JDK-8257664] (#1759) causing `font-size` declarations from external style sheets to be ignored.
>> 
>> As far as I've traced, the problem is with the `isDefined(CSS.Attribute.FONT_SIZE)` test:
>> 
>> https://github.com/openjdk/jdk/blob/70b5b3119b2ed032b021a080f34a4fa28d092fb5/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#L2825-L2830
>> 
>> It misses declarations from linked styles via a `resolver` ([`AttributeSet.ResolveAttribute`](https://github.com/openjdk/jdk/blob/b0e0b87891eb81c2b33c1cfa598701b7bd2e5bdf/src/java.desktop/share/classes/javax/swing/text/AttributeSet.java#L187-L191)) attribute that happens to hold the external style sheet rules.  The fix for this would be to move the implied `CSS.Attribute.FONT_SIZE` handling after:
>> 
>> https://github.com/openjdk/jdk/blob/70b5b3119b2ed032b021a080f34a4fa28d092fb5/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#L2833-L2835
>> 
>> and drop the `isDefined()` test.
>> 
>> [I'll prepare a jtreg test further.]
>> 
>> [JDK-8292948]: https://bugs.openjdk.org/browse/JDK-8292948 "JEditorPane ignores font-size styles in external linked css-file"
>> [JDK-8257664]: https://bugs.openjdk.org/browse/JDK-8257664 "HTMLEditorKit: Wrong CSS relative font sizes"
>
> Stanimir Stamenkov has updated the pull request incrementally with seven additional commits since the last revision:
> 
>  - 8292948: Make captureImage() an instance method
>    
>    Use just the instance editor component.
>  - 8292948: Use bigger/different base font than the default
>    
>    Make potential discrepancies with not resolving the base more obvious.
>  - 8292948: Make the setUp(), run/verify() sequence invocation explicit
>    
>    Simplify overall setup.
>  - 8292948: Avoid failing to save image capture when editor == null
>    
>    The failure to save the image suppresses the original failure.
>  - 8292948: Capitalize messages
>  - 8292948: Resolve test HTML file from the classpath
>    
>    Don't rely on the current working directory.
>  - 8292948: Adjust @summary

Marked as reviewed by psadhukhan (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10054


From duke at openjdk.org  Fri Sep  2 07:23:41 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 2 Sep 2022 07:23:41 GMT
Subject: RFR: 8287912: GTK L&F : Background of tree icons are red [v2]
In-Reply-To: <5rfMGeAuR5EKbTbfDnwIu-7fkuKXMilG8YywPHbfH7s=.5532e2d9-923a-40e2-bbff-e0a9b18dfd17@github.com>
References: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
 <Mv1Qs1Uv_3QGF6AoMrLkoHCCWqOWpmczmABbVBE3JWs=.fdcf820d-7b1c-4e12-9a97-643d13a0baa6@github.com>
 <5rfMGeAuR5EKbTbfDnwIu-7fkuKXMilG8YywPHbfH7s=.5532e2d9-923a-40e2-bbff-e0a9b18dfd17@github.com>
Message-ID: <njTFJM63uHjzwimqmAylFxh8YSW9sq1nkW5cNiPfpl0=.c7ddb59d-bfcd-4982-bc45-c8023e2c3588@github.com>

On Fri, 2 Sep 2022 01:14:10 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> test/jdk/javax/swing/JTree/TestTreeBackgroundColor.java line 81:
>> 
>>> 79:                     if (c.equals(Color.RED)) {
>>> 80:                         passed = true;
>>> 81:                     }
>> 
>> better to check at midpoint tree.width/2, tree.height/2 and also break if it's RED, no need to check all pixels.
>
> Another possible solution that I used in a previous test was a midpoint as suggested, but also one pixel near each edge. This eliminates the chance of the red still existing but not being detected at the midpoint because the red is at a different location.

The test check has been changed to compare the pixels of entire width keeping the height constant to half of tree height. Now it will check pixel color and if it is not red , the test will fail.

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

PR: https://git.openjdk.org/jdk/pull/10112


From duke at openjdk.org  Fri Sep  2 07:23:43 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 2 Sep 2022 07:23:43 GMT
Subject: RFR: 8287912: GTK L&F : Background of tree icons are red [v2]
In-Reply-To: <_bIYExydlnYYOOicYeV0d5ytc4dW8Vp3Es-Ep4tLc1o=.7150c1ca-1fcd-4e26-a6d9-b4781f1f6da7@github.com>
References: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
 <_bIYExydlnYYOOicYeV0d5ytc4dW8Vp3Es-Ep4tLc1o=.7150c1ca-1fcd-4e26-a6d9-b4781f1f6da7@github.com>
Message-ID: <pAXpYLdpio_m61gi-Qcy4SO-_6gEgukma6rihUxu0dY=.b914f57a-87cb-4a17-8a03-a88b7035986b@github.com>

On Fri, 2 Sep 2022 06:11:47 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review Comments fix
>
> test/jdk/javax/swing/JTree/TestTreeBackgroundColor.java line 84:
> 
>> 82:                 }
>> 83:             }
>> 84:             if (!passed) {
> 
> This test will pass even in the case of last pixel check is RED. We should check for pixel data and whenever it is not RED we should bail out.
> 
> Also if test fails it will leave TreeBackgroundColorTestFail.png, we should use temporary file and delete it on exit.

I have removed the writing of test image in case of fail operation and test condition changed to check if pixel color is not red then test will fail.

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

PR: https://git.openjdk.org/jdk/pull/10112


From duke at openjdk.org  Fri Sep  2 11:12:53 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 2 Sep 2022 11:12:53 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v26]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <QYaW5bTaDAzVkGYK11xiLSPLTSdIU6DiBrBR-dKCQOI=.2f3ab314-85a9-44d6-9526-1ad9d9f7056b@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 KB.
> Manual Test Case "FileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Filesize calculation logic modified

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/8ffcc83a..cea398f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=24-25

  Stats: 31 lines in 2 files changed: 7 ins; 2 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Fri Sep  2 11:37:02 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 2 Sep 2022 11:37:02 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v25]
In-Reply-To: <BQLmYqdoK1-EjLWP0e2u4rJVW4Cy57r-iOCxL0pHjLs=.fa3a7bd5-c1b0-4960-9ea1-4e88d601e16d@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <Qep3yBG39dxx7SuFQ7G0uVBcAJnvbUFuN6a7fKcbsXs=.f7fea131-2b93-4876-8a35-ccf9a38c6c55@github.com>
 <BQLmYqdoK1-EjLWP0e2u4rJVW4Cy57r-iOCxL0pHjLs=.fa3a7bd5-c1b0-4960-9ea1-4e88d601e16d@github.com>
Message-ID: <Xdvwe4nPH_fbn0XGeOWod7hmHQczR5o3rvYNUx4vhng=.24b98596-b81a-4928-88d5-1a04fe26be0f@github.com>

On Fri, 2 Sep 2022 00:46:39 GMT, Phil Race <prr at openjdk.org> wrote:

> AK > Since we are displaying file size in one decimal precision, files having size from 1 to 199 byte will be 0.1 KB.
> 
> PR > Yes, I see that. My point is it seems wrong.
> 
> AK > Can you please suggest me what should I do to handle 1 byte to199 bytes ?
> 
> PR : Just consistently round up
> 
>     * 0 bytes is 0 kb
> 
>     * 1-100 bytes is 0.1 kb
> 
>     * 101-199 bytes is 0.2 kb
> 
>     * 901 -1000 bytes is 1kb
>       and so on

The file size calculation logic has been changed to display the file size with round up value for < 1000 byte size. It will show similar values as mentioned here.
![Smaller_File_Size](https://user-images.githubusercontent.com/107542245/188130510-330ee330-a4c4-46ce-9f2a-cce880f4e264.png)



But the native file system in linux does the rounding off for file length >1000 bytes.
For example :
1250 bytes is displayed as 1.2 KB and 1251 bytes is displayed as 1.3 KB.

So to keep JFileChooser behavior similar to native file system, the existing logic has been changed to use DecimalFormat object for formatting file size.

It returns the file size similar to file managers on linux.

JFileChooser File Size:
![JFileChooser_File_Size1](https://user-images.githubusercontent.com/107542245/188130027-d43f70de-0501-4e61-900d-55f12525c35d.png)

Native System File Size:
![Native_File_System_Size](https://user-images.githubusercontent.com/107542245/188130137-78e4a82b-9edc-4103-b120-9f70bbecce58.png)

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Fri Sep  2 11:42:42 2022
From: duke at openjdk.org (ScientificWare)
Date: Fri, 2 Sep 2022 11:42:42 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v10]
In-Reply-To: <Ihkbvib2yyDV811hGaHSqrsbb1sjFPUQZK3PeE3yg0Q=.ca018f86-e100-4549-982f-1f70d46d5dac@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <3K40K0Roy0-H5dqJr4TqChwOOCRbEQYnsezkiKe3gEw=.6a48b650-6421-4b32-abc9-f1543b554ac9@github.com>
 <Ihkbvib2yyDV811hGaHSqrsbb1sjFPUQZK3PeE3yg0Q=.ca018f86-e100-4549-982f-1f70d46d5dac@github.com>
Message-ID: <6TqA6trYJCQmj_UnMJU5YZYGJvEiIP2h5GGpA3TZ3VI=.15d7a51d-6ca0-4f05-a02b-7eb15bdceae5@github.com>

On Thu, 1 Sep 2022 20:29:00 GMT, Phil Race <prr at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adds transparent and RGB case insensitive tests.
>>   
>>   When <rgb()> and <rgba()> values contains at least an uppercase character, getAttribute returns null.
>>   When using 'transparent' keyword getAttribute returns null.
>
> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1398:
> 
>> 1396:     static Color stringToColor(String str) {
>> 1397:         String strlc = str.toLowerCase(Locale.ROOT);
>> 1398:         if (str == null) {
> 
> What's the point in testing if it is null after you already de-referenced it ?

Big logical mistake. I going to change the command order.

> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1411:
> 
>> 1409:             Color color = colorNamed.get(strlc);
>> 1410:             if (color != null) {
>> 1411:                 return new Color(color.getRGB(), true);
> 
> Can you explain why you can't return the color instance directly ?
> They are immutable so I don't see the reason.

To avoid change method behaviour, I tried to reproduce previous behaviors because returned objects can be publicly exposed trough javax.swing.text.html.StyleSheet stringToColor method.
Previous implementation :
When, "" returns always the same object Color.Black.
When,  "black", "silver", "white", ...,  rgb colors defined ... returns a new object.
I haven't a example list in mind but at least Color1 == Color2 is different according implementation.

> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1562:
> 
>> 1560:             Map.entry("tomato", new Color(255, 99, 71, 255)),
>> 1561:             Map.entry("transparent", new Color(0, 0, 0, 0)),
>> 1562:             Map.entry("turquoise", new Color(64, 224, 208, 255)),
> 
> So all of these have the extra 255 alpha arg just so this ONE entry can be different ? Do you expect others like this ? If not why not special case that in the caller method ?

I will correct this.

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

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Sat Sep  3 01:36:43 2022
From: duke at openjdk.org (SWinxy)
Date: Sat, 3 Sep 2022 01:36:43 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v10]
In-Reply-To: <6TqA6trYJCQmj_UnMJU5YZYGJvEiIP2h5GGpA3TZ3VI=.15d7a51d-6ca0-4f05-a02b-7eb15bdceae5@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <3K40K0Roy0-H5dqJr4TqChwOOCRbEQYnsezkiKe3gEw=.6a48b650-6421-4b32-abc9-f1543b554ac9@github.com>
 <Ihkbvib2yyDV811hGaHSqrsbb1sjFPUQZK3PeE3yg0Q=.ca018f86-e100-4549-982f-1f70d46d5dac@github.com>
 <6TqA6trYJCQmj_UnMJU5YZYGJvEiIP2h5GGpA3TZ3VI=.15d7a51d-6ca0-4f05-a02b-7eb15bdceae5@github.com>
Message-ID: <PtQnn_uBr02qFCeSty5w4k9_thCaWVt18TIiJvzBaiA=.7c9980c9-0e46-4f0e-bb01-497999388e23@github.com>

On Fri, 2 Sep 2022 11:38:27 GMT, ScientificWare <duke at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1411:
>> 
>>> 1409:             Color color = colorNamed.get(strlc);
>>> 1410:             if (color != null) {
>>> 1411:                 return new Color(color.getRGB(), true);
>> 
>> Can you explain why you can't return the color instance directly ?
>> They are immutable so I don't see the reason.
>
> To avoid change method behaviour, I tried to reproduce previous behaviors because returned objects can be publicly exposed trough javax.swing.text.html.StyleSheet stringToColor method.
> Previous implementation :
> When, "" returns always the same object Color.Black.
> When,  "black", "silver", "white", ...,  rgb colors defined ... returns a new object.
> I haven't a example list in mind but at least Color1 == Color2 is different according implementation.

I think Phil is talking about just `return`ing the result, which doesn't change behavior. `""` can still `return Color.BLACK;` with the others creating a new object, ditching the oddly-placed temporary `Color` object.

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

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Sat Sep  3 03:29:32 2022
From: duke at openjdk.org (ScientificWare)
Date: Sat, 3 Sep 2022 03:29:32 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v10]
In-Reply-To: <PtQnn_uBr02qFCeSty5w4k9_thCaWVt18TIiJvzBaiA=.7c9980c9-0e46-4f0e-bb01-497999388e23@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <3K40K0Roy0-H5dqJr4TqChwOOCRbEQYnsezkiKe3gEw=.6a48b650-6421-4b32-abc9-f1543b554ac9@github.com>
 <Ihkbvib2yyDV811hGaHSqrsbb1sjFPUQZK3PeE3yg0Q=.ca018f86-e100-4549-982f-1f70d46d5dac@github.com>
 <6TqA6trYJCQmj_UnMJU5YZYGJvEiIP2h5GGpA3TZ3VI=.15d7a51d-6ca0-4f05-a02b-7eb15bdceae5@github.com>
 <PtQnn_uBr02qFCeSty5w4k9_thCaWVt18TIiJvzBaiA=.7c9980c9-0e46-4f0e-bb01-497999388e23@github.com>
Message-ID: <2q3e4KHR1d_Oit9Byhd3qWwstuG5yPJjB6pSvsYGEQE=.159a981c-7259-444c-be0d-f032dddebf87@github.com>

On Sat, 3 Sep 2022 01:33:02 GMT, SWinxy <duke at openjdk.org> wrote:

>> To avoid change method behaviour, I tried to reproduce previous behaviors because returned objects can be publicly exposed trough javax.swing.text.html.StyleSheet stringToColor method.
>> Previous implementation :
>> When, "" returns always the same object Color.Black.
>> When,  "black", "silver", "white", ...,  rgb colors defined ... returns a new object.
>> I haven't a example list in mind but at least Color1 == Color2 is different according implementation.
>
> I think Phil is talking about just `return`ing the result, which doesn't change behavior. `""` can still `return Color.BLACK;` with the others creating a new object, ditching the oddly-placed temporary `Color` object.

@SWinxy,
- if you're suggesting this
  ```
  } else {
              return colorNamed.get(strlc);
  ```
  We change the behavior (your comment) and lose the last test (color hex coded but without # prefix).
- or if you have in mind 

        } else {
                return new Color(colorNamed.get(strlc).color.getRGB(), true);

We preserve the behavior but still lose the last test (color hex coded but without # prefix).
- The way I interpreted @prrace comment :
  ```
          } else {
              Color color = colorNamed.get(strlc);
              if (color != null) {
                  return color;
  ```
  We change the behavior :
  - In the code before this PR. The results were : null, Color.Black if "", and new Color Object for all other colors (the 10 named colors and all hex coded colors).
  - In the first implementation achieved in this PR, like the code above, results changed to : null, Color.Black if "", the same Object for each (149) named-color or hex coded color.
  - After your comment, results became : null, Color.Black if "", and new Color Object for all other Color (149 named or hex coded).

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

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Sat Sep  3 23:43:41 2022
From: duke at openjdk.org (SWinxy)
Date: Sat, 3 Sep 2022 23:43:41 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v10]
In-Reply-To: <2q3e4KHR1d_Oit9Byhd3qWwstuG5yPJjB6pSvsYGEQE=.159a981c-7259-444c-be0d-f032dddebf87@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <3K40K0Roy0-H5dqJr4TqChwOOCRbEQYnsezkiKe3gEw=.6a48b650-6421-4b32-abc9-f1543b554ac9@github.com>
 <Ihkbvib2yyDV811hGaHSqrsbb1sjFPUQZK3PeE3yg0Q=.ca018f86-e100-4549-982f-1f70d46d5dac@github.com>
 <6TqA6trYJCQmj_UnMJU5YZYGJvEiIP2h5GGpA3TZ3VI=.15d7a51d-6ca0-4f05-a02b-7eb15bdceae5@github.com>
 <PtQnn_uBr02qFCeSty5w4k9_thCaWVt18TIiJvzBaiA=.7c9980c9-0e46-4f0e-bb01-497999388e23@github.com>
 <2q3e4KHR1d_Oit9Byhd3qWwstuG5yPJjB6pSvsYGEQE=.159a981c-7259-444c-be0d-f032dddebf87@github.com>
Message-ID: <tAzm0oiaFOUQ9ZyzUbjbuxTzAg87XU9oVX1-yT0BXHQ=.a1263983-74a5-4f04-a406-7bec51b613e9@github.com>

On Sat, 3 Sep 2022 03:26:05 GMT, ScientificWare <duke at openjdk.org> wrote:

>> I think Phil is talking about just `return`ing the result, which doesn't change behavior. `""` can still `return Color.BLACK;` with the others creating a new object, ditching the oddly-placed temporary `Color` object.
>
> @SWinxy,
> - if you're suggesting this
>   ```
>   } else {
>               return colorNamed.get(strlc);
>   ```
>   We change the behavior (your comment) and lose the last test (color hex coded but without # prefix).
> - or if you have in mind 
> 
>         } else {
>                 return new Color(colorNamed.get(strlc).color.getRGB(), true);
> 
> We preserve the behavior but still lose the last test (color hex coded but without # prefix).
> - The way I interpreted @prrace comment :
>   ```
>           } else {
>               Color color = colorNamed.get(strlc);
>               if (color != null) {
>                   return color;
>   ```
>   We change the behavior :
>   - In the code before this PR. The results were : null, Color.Black if "", and new Color Object for all other colors (the 10 named colors and all hex coded colors).
>   - In the first implementation achieved in this PR, like the code above, results changed to : null, Color.Black if "", the same Object for each (149) named-color or hex coded color.
>   - After your comment, results became : null, Color.Black if "", and new Color Object for all other Color (149 named or hex coded).

Mmm I completely forgot that we're using the map here, and for that we'll need to create a `new Color` from it. My b. There could be a check to `colorNames.has(str)` and return the `new Color(colorNames.get(str))` since there will never be a `null` returned for a valid key.

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

PR: https://git.openjdk.org/jdk/pull/9825


From psadhukhan at openjdk.org  Mon Sep  5 07:11:39 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 5 Sep 2022 07:11:39 GMT
Subject: RFR: 8287912: GTK L&F : Background of tree icons are red [v2]
In-Reply-To: <njTFJM63uHjzwimqmAylFxh8YSW9sq1nkW5cNiPfpl0=.c7ddb59d-bfcd-4982-bc45-c8023e2c3588@github.com>
References: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
 <Mv1Qs1Uv_3QGF6AoMrLkoHCCWqOWpmczmABbVBE3JWs=.fdcf820d-7b1c-4e12-9a97-643d13a0baa6@github.com>
 <5rfMGeAuR5EKbTbfDnwIu-7fkuKXMilG8YywPHbfH7s=.5532e2d9-923a-40e2-bbff-e0a9b18dfd17@github.com>
 <njTFJM63uHjzwimqmAylFxh8YSW9sq1nkW5cNiPfpl0=.c7ddb59d-bfcd-4982-bc45-c8023e2c3588@github.com>
Message-ID: <-TZ3xL49ZfKOWCG3ZQ6pIUjrMP5OiXOveJL8SA31eh0=.ade2a135-4c74-4f67-b090-c0a18a101c51@github.com>

On Fri, 2 Sep 2022 07:18:13 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Another possible solution that I used in a previous test was a midpoint as suggested, but also one pixel near each edge. This eliminates the chance of the red still existing but not being detected at the midpoint because the red is at a different location.
>
> The test check has been changed to compare the pixels of entire width keeping the height constant to half of tree height. Now it will check pixel color and if it is not red , the test will fail.

For me, test is not failing without the fix.
Also, if you test entire width and fail if it is not red, it might encounter black pixel of text font too and might fail, so I think it's better to check width/2 to width -1 and not entire width.

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

PR: https://git.openjdk.org/jdk/pull/10112


From psadhukhan at openjdk.org  Mon Sep  5 07:11:39 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 5 Sep 2022 07:11:39 GMT
Subject: RFR: 8287912: GTK L&F : Background of tree icons are red [v2]
In-Reply-To: <-TZ3xL49ZfKOWCG3ZQ6pIUjrMP5OiXOveJL8SA31eh0=.ade2a135-4c74-4f67-b090-c0a18a101c51@github.com>
References: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
 <Mv1Qs1Uv_3QGF6AoMrLkoHCCWqOWpmczmABbVBE3JWs=.fdcf820d-7b1c-4e12-9a97-643d13a0baa6@github.com>
 <5rfMGeAuR5EKbTbfDnwIu-7fkuKXMilG8YywPHbfH7s=.5532e2d9-923a-40e2-bbff-e0a9b18dfd17@github.com>
 <njTFJM63uHjzwimqmAylFxh8YSW9sq1nkW5cNiPfpl0=.c7ddb59d-bfcd-4982-bc45-c8023e2c3588@github.com>
 <-TZ3xL49ZfKOWCG3ZQ6pIUjrMP5OiXOveJL8SA31eh0=.ade2a135-4c74-4f67-b090-c0a18a101c51@github.com>
Message-ID: <SwZibHoGkWkFFIyQir8oJssSsdFnKYZfXfweiYJfGeI=.1f3f6e79-9aaa-4bf3-b340-c5debb399ae5@github.com>

On Mon, 5 Sep 2022 07:06:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The test check has been changed to compare the pixels of entire width keeping the height constant to half of tree height. Now it will check pixel color and if it is not red , the test will fail.
>
> For me, test is not failing without the fix.
> Also, if you test entire width and fail if it is not red, it might encounter black pixel of text font too and might fail, so I think it's better to check width/2 to width -1 and not entire width.

Also, it's might be better to write the image in case of failure so that it gives an idea why it failed.

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

PR: https://git.openjdk.org/jdk/pull/10112


From djelinski at openjdk.org  Mon Sep  5 07:25:28 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 5 Sep 2022 07:25:28 GMT
Subject: RFR: 8293088: Fix compilation with the new Visual Studio
 preprocessor
In-Reply-To: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
References: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
Message-ID: <p9GGSes8rI9lo9gU-HAPfXd29oeooC0x_obHGQ7rOkk=.ec08aee6-0772-49ec-a8a2-31a68c0e44dd@github.com>

On Tue, 30 Aug 2022 12:08:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Fix compilation with Zc:preprocessor enabled. 
> 
> The flag itself will be enabled in [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283); I enabled the flag using instructions found in Magnus's comment on that issue.
> 
> Windows 10 SDK version 2104 (10.0.20348.0) is required for successful compilation. Compilation fails with a warning (treated as error by default) with older versions of Windows 10 SDK.
> 
> I verified that the compilation completes successfully with this patch, both in debug and in release mode, both with and without Zc:preprocessor.

I verified the preprocessor output on `D3DResourceManager.cpp` file, which uses 3 of the 4 changed macros in `D3DPipeline.h` (`RETURN_STATUS_IF_EXP_FAILED` is not used anywhere). The generated files have only cosmetic differences - `##` removes whitespace between the concatenated string literals, and without `##` the whitespace is preserved. This whitespace is ignored by the compiler.

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

PR: https://git.openjdk.org/jdk/pull/10080


From djelinski at openjdk.org  Mon Sep  5 07:25:29 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 5 Sep 2022 07:25:29 GMT
Subject: Integrated: 8293088: Fix compilation with the new Visual Studio
 preprocessor
In-Reply-To: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
References: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
Message-ID: <8jbP_1Aah3x4T_snhUAcWiN5NsxDJgst1JHiFYOrngY=.fe496f0d-51e9-4e0f-a6f4-c1df98174f4b@github.com>

On Tue, 30 Aug 2022 12:08:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Fix compilation with Zc:preprocessor enabled. 
> 
> The flag itself will be enabled in [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283); I enabled the flag using instructions found in Magnus's comment on that issue.
> 
> Windows 10 SDK version 2104 (10.0.20348.0) is required for successful compilation. Compilation fails with a warning (treated as error by default) with older versions of Windows 10 SDK.
> 
> I verified that the compilation completes successfully with this patch, both in debug and in release mode, both with and without Zc:preprocessor.

This pull request has now been integrated.

Changeset: e945619d
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e945619ddd38091eaa010f65472141443b8f214d
Stats:     6 lines in 2 files changed: 0 ins; 0 del; 6 mod

8293088: Fix compilation with the new Visual Studio preprocessor

Reviewed-by: ihse

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

PR: https://git.openjdk.org/jdk/pull/10080


From duke at openjdk.org  Mon Sep  5 09:35:34 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Mon, 5 Sep 2022 09:35:34 GMT
Subject: RFR: 8292848: AWT_Mixing and TrayIcon tests fail on el8 with
 hard-coded isOel7
In-Reply-To: <aH8UVH574D88IUnIf8B3SlA2NAXBfFxo8lqrnM5CVNc=.6ebdfd83-13e1-4326-acc3-5311a205a4f4@github.com>
References: <ZJrPLHPk000YQPHb73cCqw1l7jP1vwRLEXMlOgrqVSs=.a599b437-a90f-4f81-8ca5-aa2809bde6f7@github.com>
 <aH8UVH574D88IUnIf8B3SlA2NAXBfFxo8lqrnM5CVNc=.6ebdfd83-13e1-4326-acc3-5311a205a4f4@github.com>
Message-ID: <Hc9-roDS86WMlgDzUfb0OKZV0sVNeuta2s7WrN8C3vs=.32a599df-2570-4c89-833e-c29090e785c5@github.com>

On Thu, 25 Aug 2022 18:56:59 GMT, Phil Race <prr at openjdk.org> wrote:

>> Could you please review the JDK-8292848 bug fixes?
>> The purpose of the isOel7 method is to detect differences in GNOME version changes, and the isOel7 
>> result should be true after version 8.
>> I modified the isOel7 method to use regular expressions instead of hard-coded versions to be able to 
>> detect the new os version.
>> I also changed the method name to match the new conditions.
>
> I guess this will do what was previously being done on OL7 .. but the way it is done it is fragile
> and surely it can't be specific to OL .. and there's some pretty hokey adjustments going on in some of these tests.
> I think some day these tests will need to be re-examined.

@prrace 
Thank you for your review. I agree with another consideration .

I think two reviews are required thisfix to be integrated. Could anyone please review this fix?

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

PR: https://git.openjdk.org/jdk/pull/9995


From psadhukhan at openjdk.org  Mon Sep  5 10:52:52 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 5 Sep 2022 10:52:52 GMT
Subject: Integrated: 8267374: macOS: Option+Up/Down Arrow don't traverse to
 beginning/end of line in JTextArea
In-Reply-To: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
Message-ID: <jwTbd_J_UBRQMb6Dnr5GqcHTsOqg1VVPSl-z25bYhY0=.84f94c5d-94e3-4485-a4f3-990bd5b55851@github.com>

On Wed, 22 Jun 2022 03:28:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Unlike in native "Notes" editor where Option+Up/Down traverses to start/end of each line respectively,
> Java does not honour these key combination in editor.
> 
> Added the key combination support by moving the caret to start/end of line and then doing caret up/down a line depending on if we are pressing UP or DOWN key.

This pull request has now been integrated.

Changeset: 955baa3c
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/955baa3c44805538df5f95ccc91d2d5a08c85b81
Stats:     397 lines in 8 files changed: 367 ins; 16 del; 14 mod

8267374: macOS: Option+Up/Down Arrow don't traverse to beginning/end of line in JTextArea

Reviewed-by: prr

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

PR: https://git.openjdk.org/jdk/pull/9230


From psadhukhan at openjdk.org  Mon Sep  5 12:55:41 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 5 Sep 2022 12:55:41 GMT
Subject: RFR: 6529151: NullPointerException in
 swing.plaf.synth.SynthLookAndFeel$Handler
Message-ID: <LNDDuM1Xo2waUauHyNK8iyw6y9cRGnawCO0ZbkVAIm4=.b2b2e136-5728-4734-b060-e61caa21f6c3@github.com>

NPE is thrown for closed/disposed JDialogs after uninstalling the UI which is because for SynthEditorPaneUI even though is disposed of, Nimbus propertyHandler tries to get the style of this disposed component resulting in NPE, 
which is fixed by a null check to prevent deferencing style object to get the color.

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

Commit messages:
 - 6529151: NullPointerException in swing.plaf.synth.SynthLookAndFeel

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

PR: https://git.openjdk.org/jdk/pull/10167


From duke at openjdk.org  Mon Sep  5 16:55:17 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Mon, 5 Sep 2022 16:55:17 GMT
Subject: RFR: 8287912: GTK L&F : Background of tree icons are red [v2]
In-Reply-To: <SwZibHoGkWkFFIyQir8oJssSsdFnKYZfXfweiYJfGeI=.1f3f6e79-9aaa-4bf3-b340-c5debb399ae5@github.com>
References: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
 <Mv1Qs1Uv_3QGF6AoMrLkoHCCWqOWpmczmABbVBE3JWs=.fdcf820d-7b1c-4e12-9a97-643d13a0baa6@github.com>
 <5rfMGeAuR5EKbTbfDnwIu-7fkuKXMilG8YywPHbfH7s=.5532e2d9-923a-40e2-bbff-e0a9b18dfd17@github.com>
 <njTFJM63uHjzwimqmAylFxh8YSW9sq1nkW5cNiPfpl0=.c7ddb59d-bfcd-4982-bc45-c8023e2c3588@github.com>
 <-TZ3xL49ZfKOWCG3ZQ6pIUjrMP5OiXOveJL8SA31eh0=.ade2a135-4c74-4f67-b090-c0a18a101c51@github.com>
 <SwZibHoGkWkFFIyQir8oJssSsdFnKYZfXfweiYJfGeI=.1f3f6e79-9aaa-4bf3-b340-c5debb399ae5@github.com>
Message-ID: <Q11V-2BM0Jb9HwC31NXA9tTW8KETNOEO3RqGnfXKiWE=.9845f5cb-d2c8-4bb6-adee-3002604a45cf@github.com>

On Mon, 5 Sep 2022 07:08:13 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> For me, test is not failing without the fix.
>> Also, if you test entire width and fail if it is not red, it might encounter black pixel of text font too and might fail, so I think it's better to check width/2 to width -1 and not entire width.
>
> Also, it's might be better to write the image in case of failure so that it gives an idea why it failed.

> For me, test is not failing without the fix. Also, if you test entire width and fail if it is not red, it might encounter black pixel of text font too and might fail, so I think it's better to check width/2 to width -1 and not entire width.

Test was not failing without the fix because the second argument of getRGB method is height/2, and for that pixel value the returned color is red. 
Changing the argument from height/2 to height/4 will fail the test without the fix otherwise it will pass the test.

Also writing the image in case of failure.

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

PR: https://git.openjdk.org/jdk/pull/10112


From duke at openjdk.org  Mon Sep  5 17:08:57 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Mon, 5 Sep 2022 17:08:57 GMT
Subject: RFR: 8287912: GTK L&F : Background of tree icons are red [v3]
In-Reply-To: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
References: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
Message-ID: <9AWUb8sAYxabyp0I2Xka-6GAFDxUCxCOnVaUbr7Ezj8=.13a72fa3-f5e3-4c24-adbb-885c90d70f86@github.com>

> The background of tree icons are not red in GTK LAF when setOpaque is set to false for tree component.
> It has been observed that while painting tree cell background in GTK LAF, a rectangular area is also painted with background color (white). 
> 
> Proposed solution is to check the opacity of tree component before drawing tree cell background. If the opacity is set to "false" then the background shouldn't be painted.
> 
> An automated test case has been added and checked in CI, link is added in JBS.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10112/files
  - new: https://git.openjdk.org/jdk/pull/10112/files/fb3db43f..f3fd0e7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10112&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10112&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/10112


From aturbanov at openjdk.org  Mon Sep  5 20:01:53 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 Sep 2022 20:01:53 GMT
Subject: Integrated: 8293159: Use try-with-resources in
 X11FontManager.registerFontDir
In-Reply-To: <05z0cNBF7JPLVHQGt0B5WBYiZIXwgEey8XEsWG9yCYg=.9ef77c92-2ef1-4e23-ad44-15da001a4a05@github.com>
References: <05z0cNBF7JPLVHQGt0B5WBYiZIXwgEey8XEsWG9yCYg=.9ef77c92-2ef1-4e23-ad44-15da001a4a05@github.com>
Message-ID: <c79Qwx-HCC_kCqClVtnR1cyU47J_vxKOEwuXLkVU4hA=.adc029d4-3be0-4fe6-adea-9bc21e8b0000@github.com>

On Mon, 15 Aug 2022 13:13:33 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Makes code easier to read.

This pull request has now been integrated.

Changeset: ef20ffe4
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef20ffe4d222d48f0bdba81a0b864d9fb455e9a6
Stats:     164 lines in 1 file changed: 45 ins; 55 del; 64 mod

8293159: Use try-with-resources in X11FontManager.registerFontDir

Reviewed-by: prr

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

PR: https://git.openjdk.org/jdk/pull/9879


From psadhukhan at openjdk.org  Tue Sep  6 06:04:36 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 6 Sep 2022 06:04:36 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is not
 shown on disabled checkbox and radio button with Nimbus LAF
Message-ID: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>

CheckBox.disabledText and RadioButton.disabledText color UIProperty is not honoured by Nimbus L&F when disabled text is drawn for JCheckBox and JRadioButton, so disabled text color was rendered incorrectly.
Fix is to honour these UIProperty color if they are set by user, else use the color from the component or via getColorForState().

Closed test as mentioned in JBS is used to check the fix.

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

Commit messages:
 - 8075916: The regression-swing case failed as colored text is not shown on disabled checkbox and radio button with Nimbus LAF

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

PR: https://git.openjdk.org/jdk/pull/10177


From duke at openjdk.org  Tue Sep  6 06:19:31 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 6 Sep 2022 06:19:31 GMT
Subject: RFR: 8234315: GTK LAF does not gray out disabled JMenu
Message-ID: <s7Az0JMKFqPbKlMnUgUUsQSa2ygH9SW08N0DGr7sQQM=.2561a3ba-40ce-4902-a2d2-992aa1ad565f@github.com>

Disabled JMenu foreground color was not grayed out in GTK LAF for version 3. The issue didn't occur in GTK-2. 
After analysis it has been found that the JMenu widget type was changed to JMenuBar and the color value returned for the foreground color in disabled state was close to black color (RGB 0,0,0) for menubar which is not differentiable from enabled state foreground color.

As a fix for this problem, if the menubar is in disabled state then the widget is changed to JMenu and color value returned for disabled menu is gray color.

An automated test case has been added and checked in CI, link is added in JBS.

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

Commit messages:
 - Whitespace fix
 - Disabled JMenu foreground color grayed out fix

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

PR: https://git.openjdk.org/jdk/pull/10176


From tr at openjdk.org  Tue Sep  6 06:36:05 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 6 Sep 2022 06:36:05 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null
In-Reply-To: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
Message-ID: <ZfNl9XvvYsXeXuvjizi7YH-CYAJVfjFdoRhc4gginOI=.15d78369-4242-46c9-a432-c8bfd92e6112@github.com>

On Fri, 26 Aug 2022 04:47:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Default echo character obtained through `PasswordField.echoChar` UIProperty returns null for Nimbus L&F,
> which is fixed by adding the default character * in the UIDefault table.

test/jdk/javax/swing/plaf/nimbus/PasswordFieldTest.java line 56:

> 54:             if (UIManager.get("PasswordField.echoChar") == null) {
> 55:                 throw new RuntimeException(
> 56:                     "PasswordField.echoChar returns null for NimbusL&F");

Hardcoding of NimbusL&F for exception string can be replaced with L&F name. Since the traversal is happening for all L&F, expecting only Nimbus might not be right I guess.

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

PR: https://git.openjdk.org/jdk/pull/10035


From psadhukhan at openjdk.org  Tue Sep  6 06:56:49 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 6 Sep 2022 06:56:49 GMT
Subject: RFR: 8287912: GTK L&F : Background of tree icons are red [v3]
In-Reply-To: <Q11V-2BM0Jb9HwC31NXA9tTW8KETNOEO3RqGnfXKiWE=.9845f5cb-d2c8-4bb6-adee-3002604a45cf@github.com>
References: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
 <Mv1Qs1Uv_3QGF6AoMrLkoHCCWqOWpmczmABbVBE3JWs=.fdcf820d-7b1c-4e12-9a97-643d13a0baa6@github.com>
 <5rfMGeAuR5EKbTbfDnwIu-7fkuKXMilG8YywPHbfH7s=.5532e2d9-923a-40e2-bbff-e0a9b18dfd17@github.com>
 <njTFJM63uHjzwimqmAylFxh8YSW9sq1nkW5cNiPfpl0=.c7ddb59d-bfcd-4982-bc45-c8023e2c3588@github.com>
 <-TZ3xL49ZfKOWCG3ZQ6pIUjrMP5OiXOveJL8SA31eh0=.ade2a135-4c74-4f67-b090-c0a18a101c51@github.com>
 <SwZibHoGkWkFFIyQir8oJssSsdFnKYZfXfweiYJfGeI=.1f3f6e79-9aaa-4bf3-b340-c5debb399ae5@github.com>
 <Q11V-2BM0Jb9HwC31NXA9tTW8KETNOEO3RqGnfXKiWE=.9845f5cb-d2c8-4bb6-adee-3002604a45cf@github.com>
Message-ID: <mIDWZkvO1R23bnKGDLAqqcc7xilatWDJTrGNaxgs-F4=.ba272b54-8e8f-4ad6-b68d-34254f0e3366@github.com>

On Mon, 5 Sep 2022 16:51:48 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Also, it's might be better to write the image in case of failure so that it gives an idea why it failed.
>
>> For me, test is not failing without the fix. Also, if you test entire width and fail if it is not red, it might encounter black pixel of text font too and might fail, so I think it's better to check width/2 to width -1 and not entire width.
> 
> Test was not failing without the fix because the second argument of getRGB method is height/2, and for that pixel value the returned color is red. 
> Changing the argument from height/2 to height/4 will fail the test without the fix otherwise it will pass the test.
> 
> Also writing the image in case of failure.

This looks ok .Please remove the empty 1st line in the test.

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

PR: https://git.openjdk.org/jdk/pull/10112


From psadhukhan at openjdk.org  Tue Sep  6 07:00:43 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 6 Sep 2022 07:00:43 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v2]
In-Reply-To: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
Message-ID: <z5cIRuzWVpcdvSwJ_7ICFowmCAraWPXrv9b5hBhWHTM=.7c4ee5bb-3d06-41f4-9f59-74f4235e9dc7@github.com>

> Default echo character obtained through `PasswordField.echoChar` UIProperty returns null for Nimbus L&F,
> which is fixed by adding the default character * in the UIDefault table.

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

  Removal of Nimbus L&F hardcode

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10035/files
  - new: https://git.openjdk.org/jdk/pull/10035/files/16f2df60..51919462

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10035&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10035&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/10035


From psadhukhan at openjdk.org  Tue Sep  6 07:00:44 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 6 Sep 2022 07:00:44 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v2]
In-Reply-To: <ZfNl9XvvYsXeXuvjizi7YH-CYAJVfjFdoRhc4gginOI=.15d78369-4242-46c9-a432-c8bfd92e6112@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <ZfNl9XvvYsXeXuvjizi7YH-CYAJVfjFdoRhc4gginOI=.15d78369-4242-46c9-a432-c8bfd92e6112@github.com>
Message-ID: <FQErpB1bVGY5HoqtvRixZVTmpce8y66Nrh1C34Lnlz0=.3a96850e-793d-4f49-a457-30bda494fb54@github.com>

On Tue, 6 Sep 2022 06:33:14 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removal of Nimbus L&F hardcode
>
> test/jdk/javax/swing/plaf/nimbus/PasswordFieldTest.java line 56:
> 
>> 54:             if (UIManager.get("PasswordField.echoChar") == null) {
>> 55:                 throw new RuntimeException(
>> 56:                     "PasswordField.echoChar returns null for NimbusL&F");
> 
> Hardcoding of NimbusL&F for exception string can be replaced with L&F name. Since the traversal is happening for all L&F, expecting only Nimbus might not be right I guess.

yes, removed since we are already printing the L&F being tested in the beginning.

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

PR: https://git.openjdk.org/jdk/pull/10035


From duke at openjdk.org  Tue Sep  6 07:07:53 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 6 Sep 2022 07:07:53 GMT
Subject: RFR: 8287912: GTK L&F : Background of tree icons are red [v4]
In-Reply-To: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
References: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
Message-ID: <Pcjv9HXS7dPM79MUm6S0jLbovSigsSGhyare_7ZoUtc=.4c770bf8-3116-40ec-ac49-2ed920f7ce5a@github.com>

> The background of tree icons are not red in GTK LAF when setOpaque is set to false for tree component.
> It has been observed that while painting tree cell background in GTK LAF, a rectangular area is also painted with background color (white). 
> 
> Proposed solution is to check the opacity of tree component before drawing tree cell background. If the opacity is set to "false" then the background shouldn't be painted.
> 
> An automated test case has been added and checked in CI, link is added in JBS.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Empty 1st line removed in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10112/files
  - new: https://git.openjdk.org/jdk/pull/10112/files/f3fd0e7d..930a7fb4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10112&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10112&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/10112


From psadhukhan at openjdk.org  Tue Sep  6 07:28:47 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 6 Sep 2022 07:28:47 GMT
Subject: RFR: 8287912: GTK L&F : Background of tree icons are red [v4]
In-Reply-To: <Pcjv9HXS7dPM79MUm6S0jLbovSigsSGhyare_7ZoUtc=.4c770bf8-3116-40ec-ac49-2ed920f7ce5a@github.com>
References: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
 <Pcjv9HXS7dPM79MUm6S0jLbovSigsSGhyare_7ZoUtc=.4c770bf8-3116-40ec-ac49-2ed920f7ce5a@github.com>
Message-ID: <GZDKWJvGW03lFQVsZBNpGBwu8nhHOW6hmx9X6cyTgkQ=.7d2ef2e1-07ba-402f-adac-5c8a099b93d9@github.com>

On Tue, 6 Sep 2022 07:07:53 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> The background of tree icons are not red in GTK LAF when setOpaque is set to false for tree component.
>> It has been observed that while painting tree cell background in GTK LAF, a rectangular area is also painted with background color (white). 
>> 
>> Proposed solution is to check the opacity of tree component before drawing tree cell background. If the opacity is set to "false" then the background shouldn't be painted.
>> 
>> An automated test case has been added and checked in CI, link is added in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Empty 1st line removed in test

Marked as reviewed by psadhukhan (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10112


From tr at openjdk.org  Tue Sep  6 08:23:43 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 6 Sep 2022 08:23:43 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v2]
In-Reply-To: <z5cIRuzWVpcdvSwJ_7ICFowmCAraWPXrv9b5hBhWHTM=.7c4ee5bb-3d06-41f4-9f59-74f4235e9dc7@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <z5cIRuzWVpcdvSwJ_7ICFowmCAraWPXrv9b5hBhWHTM=.7c4ee5bb-3d06-41f4-9f59-74f4235e9dc7@github.com>
Message-ID: <-x20m0yYydYluLbsIi6E0wUrv7V9IU9wGcdi8HqyLRw=.ee1dd71d-fec9-4157-9cdf-bf4d5da5eae2@github.com>

On Tue, 6 Sep 2022 07:00:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Default echo character obtained through `PasswordField.echoChar` UIProperty returns null for Nimbus L&F,
>> which is fixed by adding the default character * in the UIDefault table.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removal of Nimbus L&F hardcode

Marked as reviewed by tr (Author).

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

PR: https://git.openjdk.org/jdk/pull/10035


From duke at openjdk.org  Tue Sep  6 08:57:43 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 6 Sep 2022 08:57:43 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v2]
In-Reply-To: <CffGJYwFN0vfbFSdzLpwGGGivp4BcLuX_KbQoBNwPzE=.56090a62-5906-4dc8-a6fe-605392db07ea@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <CffGJYwFN0vfbFSdzLpwGGGivp4BcLuX_KbQoBNwPzE=.56090a62-5906-4dc8-a6fe-605392db07ea@github.com>
Message-ID: <8myPQ3LIb1PCluP9Bi4JccijmRVF64m42PE09kf-A9w=.cbfa821d-a706-42b5-9901-bb2ed51f33af@github.com>

On Thu, 1 Sep 2022 06:40:08 GMT, Tejesh R <tr at openjdk.org> wrote:

>> JFileChooser.getSelectedFiles() failed to retrieve files with multi-selection and double-click. This occurs when a single file is selected then enable multi-selection then select the same file through mouse double-click(Two file chooser dialogs used before and after multi-selection enabled). SelectedFiles are updated when a change in files/directory selection is done or when selection is made through keyboard selection. In this case since a single file is selected before multi-selection is enabled and same file is selected again without changing the selection index/directory, leaving selected Files un-updated. 
>> **Proposed Fix** : Whenever Multi-Selection is enabled check if any files are selected, if yes update the selected Files of JFileChoooser.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

src/java.desktop/share/classes/sun/swing/FilePane.java line 1763:

> 1761:                 selectedFiles = getFileChooser().getSelectedFiles();
> 1762:             } else if (getFileChooser().getSelectedFile() != null) {
> 1763:                 File selectedFile = getFileChooser().getSelectedFile();

File selectedFile = getFileChooser().getSelectedFile();
selectedFiles = new File[1];
selectedFiles[0] = selectedFile;

You can directly assign getFileChooser().getSelectedFile() value to selectedFiles[0]. I think no need to create extra selectedFile variable.

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

PR: https://git.openjdk.org/jdk/pull/9996


From jdv at openjdk.org  Tue Sep  6 09:05:41 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 6 Sep 2022 09:05:41 GMT
Subject: RFR: 8287912: GTK L&F : Background of tree icons are red [v4]
In-Reply-To: <Pcjv9HXS7dPM79MUm6S0jLbovSigsSGhyare_7ZoUtc=.4c770bf8-3116-40ec-ac49-2ed920f7ce5a@github.com>
References: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
 <Pcjv9HXS7dPM79MUm6S0jLbovSigsSGhyare_7ZoUtc=.4c770bf8-3116-40ec-ac49-2ed920f7ce5a@github.com>
Message-ID: <BOxYPVyo6ctKxBEdZ6R76B344a_n4Tm3F2ly_rwJHvU=.1bf57b6b-32ff-4b5b-83d0-baa1002dc5ce@github.com>

On Tue, 6 Sep 2022 07:07:53 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> The background of tree icons are not red in GTK LAF when setOpaque is set to false for tree component.
>> It has been observed that while painting tree cell background in GTK LAF, a rectangular area is also painted with background color (white). 
>> 
>> Proposed solution is to check the opacity of tree component before drawing tree cell background. If the opacity is set to "false" then the background shouldn't be painted.
>> 
>> An automated test case has been added and checked in CI, link is added in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Empty 1st line removed in test

Marked as reviewed by jdv (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10112


From duke at openjdk.org  Tue Sep  6 09:30:57 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 6 Sep 2022 09:30:57 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v2]
In-Reply-To: <CffGJYwFN0vfbFSdzLpwGGGivp4BcLuX_KbQoBNwPzE=.56090a62-5906-4dc8-a6fe-605392db07ea@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <CffGJYwFN0vfbFSdzLpwGGGivp4BcLuX_KbQoBNwPzE=.56090a62-5906-4dc8-a6fe-605392db07ea@github.com>
Message-ID: <2QtPmDcACUnqsvjMVDj81t2rN_LahmtRpVokpXAImFE=.15a96cc6-33e6-43df-a85c-7cbe8df581e9@github.com>

On Thu, 1 Sep 2022 06:40:08 GMT, Tejesh R <tr at openjdk.org> wrote:

>> JFileChooser.getSelectedFiles() failed to retrieve files with multi-selection and double-click. This occurs when a single file is selected then enable multi-selection then select the same file through mouse double-click(Two file chooser dialogs used before and after multi-selection enabled). SelectedFiles are updated when a change in files/directory selection is done or when selection is made through keyboard selection. In this case since a single file is selected before multi-selection is enabled and same file is selected again without changing the selection index/directory, leaving selected Files un-updated. 
>> **Proposed Fix** : Whenever Multi-Selection is enabled check if any files are selected, if yes update the selected Files of JFileChoooser.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

test/jdk/javax/swing/JFileChooser/MultiSelectionEnabledSelectedFilesTest.java line 87:

> 85:         File[] files = chooser.getSelectedFiles();
> 86: 
> 87:         if(files.length <= 0) {

`if(files.length <= 0) {`

Please add space after if.

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

PR: https://git.openjdk.org/jdk/pull/9996


From duke at openjdk.org  Tue Sep  6 10:58:14 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 6 Sep 2022 10:58:14 GMT
Subject: Integrated: 8287912: GTK L&F : Background of tree icons are red
In-Reply-To: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
References: <wRhC1-0VOOkERgX3OP4h9fhITbofU8VKaWLMu0KAzvg=.984ef9d3-b2fa-40db-a5a7-ededc476150b@github.com>
Message-ID: <v8UJmeOa5EPoTj5idc47XhS99Le2eWg26sJe0xqELGk=.394a1e14-f5bb-4674-a2a6-40f4cc087539@github.com>

On Thu, 1 Sep 2022 06:27:17 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> The background of tree icons are not red in GTK LAF when setOpaque is set to false for tree component.
> It has been observed that while painting tree cell background in GTK LAF, a rectangular area is also painted with background color (white). 
> 
> Proposed solution is to check the opacity of tree component before drawing tree cell background. If the opacity is set to "false" then the background shouldn't be painted.
> 
> An automated test case has been added and checked in CI, link is added in JBS.

This pull request has now been integrated.

Changeset: a92c1ff7
Author:    Abhishek Kumar <abhishek.cx.kumar at oracle.com>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a92c1ff700925b400ee92057ae3dc3030487a886
Stats:     115 lines in 2 files changed: 113 ins; 0 del; 2 mod

8287912: GTK L&F : Background of tree icons are red

Reviewed-by: psadhukhan, jdv

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

PR: https://git.openjdk.org/jdk/pull/10112


From tr at openjdk.org  Tue Sep  6 11:14:49 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 6 Sep 2022 11:14:49 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
Message-ID: <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>

> JFileChooser.getSelectedFiles() failed to retrieve files with multi-selection and double-click. This occurs when a single file is selected then enable multi-selection then select the same file through mouse double-click(Two file chooser dialogs used before and after multi-selection enabled). SelectedFiles are updated when a change in files/directory selection is done or when selection is made through keyboard selection. In this case since a single file is selected before multi-selection is enabled and same file is selected again without changing the selection index/directory, leaving selected Files un-updated. 
> **Proposed Fix** : Whenever Multi-Selection is enabled check if any files are selected, if yes update the selected Files of JFileChoooser.

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

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9996/files
  - new: https://git.openjdk.org/jdk/pull/9996/files/71c936a0..1d7f271b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9996&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9996&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/9996


From duke at openjdk.org  Tue Sep  6 11:14:51 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 6 Sep 2022 11:14:51 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v2]
In-Reply-To: <CffGJYwFN0vfbFSdzLpwGGGivp4BcLuX_KbQoBNwPzE=.56090a62-5906-4dc8-a6fe-605392db07ea@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <CffGJYwFN0vfbFSdzLpwGGGivp4BcLuX_KbQoBNwPzE=.56090a62-5906-4dc8-a6fe-605392db07ea@github.com>
Message-ID: <5Y6GY-MycmJkFjgVOw7l9ysKuIgWKWVUZ5wwPz-YcU0=.92bf4183-78c0-42d1-b8c4-7cb4a1fe1866@github.com>

On Thu, 1 Sep 2022 06:40:08 GMT, Tejesh R <tr at openjdk.org> wrote:

>> JFileChooser.getSelectedFiles() failed to retrieve files with multi-selection and double-click. This occurs when a single file is selected then enable multi-selection then select the same file through mouse double-click(Two file chooser dialogs used before and after multi-selection enabled). SelectedFiles are updated when a change in files/directory selection is done or when selection is made through keyboard selection. In this case since a single file is selected before multi-selection is enabled and same file is selected again without changing the selection index/directory, leaving selected Files un-updated. 
>> **Proposed Fix** : Whenever Multi-Selection is enabled check if any files are selected, if yes update the selected Files of JFileChoooser.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

I guess copyright year for FilePane.java needs to be updated.

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

PR: https://git.openjdk.org/jdk/pull/9996


From tr at openjdk.org  Tue Sep  6 11:14:53 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 6 Sep 2022 11:14:53 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v2]
In-Reply-To: <5Y6GY-MycmJkFjgVOw7l9ysKuIgWKWVUZ5wwPz-YcU0=.92bf4183-78c0-42d1-b8c4-7cb4a1fe1866@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <CffGJYwFN0vfbFSdzLpwGGGivp4BcLuX_KbQoBNwPzE=.56090a62-5906-4dc8-a6fe-605392db07ea@github.com>
 <5Y6GY-MycmJkFjgVOw7l9ysKuIgWKWVUZ5wwPz-YcU0=.92bf4183-78c0-42d1-b8c4-7cb4a1fe1866@github.com>
Message-ID: <SI7m6lARXBsyUXrtHHiJHfIIKGoarGBgQFLtcRmh85A=.5c507b0d-54a9-48b4-9575-c4a55fcd07a7@github.com>

On Tue, 6 Sep 2022 11:07:09 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> I guess copyright year for FilePane.java needs to be updated.

Updated.

> src/java.desktop/share/classes/sun/swing/FilePane.java line 1763:
> 
>> 1761:                 selectedFiles = getFileChooser().getSelectedFiles();
>> 1762:             } else if (getFileChooser().getSelectedFile() != null) {
>> 1763:                 File selectedFile = getFileChooser().getSelectedFile();
> 
> File selectedFile = getFileChooser().getSelectedFile();
> selectedFiles = new File[1];
> selectedFiles[0] = selectedFile;
> 
> You can directly assign getFileChooser().getSelectedFile() value to selectedFiles[0]. I think no need to create extra selectedFile variable.

Updated.

> test/jdk/javax/swing/JFileChooser/MultiSelectionEnabledSelectedFilesTest.java line 87:
> 
>> 85:         File[] files = chooser.getSelectedFiles();
>> 86: 
>> 87:         if(files.length <= 0) {
> 
> `if(files.length <= 0) {`
> 
> Please add space after if.

Updated.

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

PR: https://git.openjdk.org/jdk/pull/9996


From duke at openjdk.org  Tue Sep  6 11:34:44 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 6 Sep 2022 11:34:44 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
Message-ID: <wQpkcvln2xwipwLhPRt_oNr3ePUPgant29T141UN78Y=.61f9fcd1-88e9-4317-b082-e907dda8525b@github.com>

On Tue, 6 Sep 2022 11:14:49 GMT, Tejesh R <tr at openjdk.org> wrote:

>> JFileChooser.getSelectedFiles() failed to retrieve files with multi-selection and double-click. This occurs when a single file is selected then enable multi-selection then select the same file through mouse double-click(Two file chooser dialogs used before and after multi-selection enabled). SelectedFiles are updated when a change in files/directory selection is done or when selection is made through keyboard selection. In this case since a single file is selected before multi-selection is enabled and same file is selected again without changing the selection index/directory, leaving selected Files un-updated. 
>> **Proposed Fix** : Whenever Multi-Selection is enabled check if any files are selected, if yes update the selected Files of JFileChoooser.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Applied the patch and tested, attached test case is passed with your fix.

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

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

PR: https://git.openjdk.org/jdk/pull/9996


From asotona at openjdk.org  Tue Sep  6 12:25:24 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 6 Sep 2022 12:25:24 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v15]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <b5mMEanymucbX0tCOED4m3GZJ9hOrDP_RsxQWl4s-hc=.3330a4a4-d1bc-4286-9edf-1c9c7f7fee7f@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le
 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - ... and 9 more: https://git.openjdk.org/jdk/compare/6a1e98cb...4a7ce942

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

Changes: https://git.openjdk.org/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=14
  Stats: 439 lines in 14 files changed: 437 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.org/jdk/pull/8599


From ihse at openjdk.org  Tue Sep  6 12:29:23 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Sep 2022 12:29:23 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v7]
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: <nVR9S4sBxWNkwXKxRPDbXWqOQCsZn_LdS7yp15HZGrg=.b3530cab-b73e-4999-b440-5d8dffccd8f7@github.com>

> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
> 
> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Revert changes in libjpeg
 - Revert changes in libfreetype

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8328/files
  - new: https://git.openjdk.org/jdk/pull/8328/files/98e635a5..19409c23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8328&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8328&range=05-06

  Stats: 9 lines in 6 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/8328.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8328/head:pull/8328

PR: https://git.openjdk.org/jdk/pull/8328


From ihse at openjdk.org  Tue Sep  6 12:42:05 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Sep 2022 12:42:05 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v8]
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>

> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
> 
> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:

 - Merge branch 'master' into typos-in-java.desktop
 - Revert changes in libjpeg
 - Revert changes in libfreetype
 - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - ... and 36 more: https://git.openjdk.org/jdk/compare/6a1e98cb...1ce28314

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

Changes: https://git.openjdk.org/jdk/pull/8328/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8328&range=07
  Stats: 1028 lines in 486 files changed: 0 ins; 0 del; 1028 mod
  Patch: https://git.openjdk.org/jdk/pull/8328.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8328/head:pull/8328

PR: https://git.openjdk.org/jdk/pull/8328


From ihse at openjdk.org  Tue Sep  6 12:42:05 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Sep 2022 12:42:05 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v7]
In-Reply-To: <nVR9S4sBxWNkwXKxRPDbXWqOQCsZn_LdS7yp15HZGrg=.b3530cab-b73e-4999-b440-5d8dffccd8f7@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <nVR9S4sBxWNkwXKxRPDbXWqOQCsZn_LdS7yp15HZGrg=.b3530cab-b73e-4999-b440-5d8dffccd8f7@github.com>
Message-ID: <Hl542x4zGsdM4vphDlHp_4mI0ngo5EhyWwaY8pT1Tgs=.f1c199d1-f56a-467b-8328-68592abe6c5b@github.com>

On Tue, 6 Sep 2022 12:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert changes in libjpeg
>  - Revert changes in libfreetype

I have now removed the changes to libfreetype, and also libjpeg. These were the only 3rd party source I could locate.

I apologize for this PR. It was too huge. If it is of any comfort, I've learnt my lesson and won't repeat it. And once it started getting pushed down by more prioritized work, I got  a bit scared about going back and look through all this for additional (unspecified) 3rd party sources, so it got left behind, hanging around.

@prrace I hope this is acceptable to merge now.

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

PR: https://git.openjdk.org/jdk/pull/8328


From tr at openjdk.org  Tue Sep  6 16:58:11 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 6 Sep 2022 16:58:11 GMT
Subject: RFR: 8292376: A few Swing methods use inheritDoc on exceptions
 which are not inherited [v2]
In-Reply-To: <NL96eVu0zHujvOrGCR9P98jZRcVbf8rezkzLIPzA7OA=.30b5f2b1-84c1-42a3-babf-ccf9e96ff6f6@github.com>
References: <W1yenf_2rr8sMDSjJcKF-IGZa_mGYSG572YrlWcxH7w=.9388229b-7cd5-42b7-aaf8-00cdd955278a@github.com>
 <NL96eVu0zHujvOrGCR9P98jZRcVbf8rezkzLIPzA7OA=.30b5f2b1-84c1-42a3-babf-ccf9e96ff6f6@github.com>
Message-ID: <zo7W-XDAUtT7atl5xA5rrJREy0L2g3ibrpCPnjx11J8=.bf27e680-fa00-4f1e-a60f-c8300e3574fb@github.com>

On Wed, 17 Aug 2022 12:07:27 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Document update for getBaselineResizeBehavior() and getBaseline() method description in JSpinner, AbstractBorder and TitledBorder .
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year updated

src/java.desktop/share/classes/javax/swing/border/AbstractBorder.java line 184:

> 182:      * @return an enum indicating how the baseline changes as the border is
> 183:      *         resized
> 184:      * @throws NullPointerException if passed in {@code Component} is {@code null}

`if passed in {@code Component} is {@code null}` - Rephrasing this sentence would be better. Something like `if {@code Component} is {@code null}`.

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

PR: https://git.openjdk.org/jdk/pull/9902


From swinxythecat at gmail.com  Tue Sep  6 18:49:32 2022
From: swinxythecat at gmail.com (SWinxy)
Date: Tue, 6 Sep 2022 14:49:32 -0400
Subject: Inlining SDRenderType returns in QuartzRenderer.m
Message-ID: <CAPRuVTVswHugV6xE058G8gtdS+LZUSLcovXxBLVvraBBc94Zdg@mail.gmail.com>

Hey y'all, I was looking at QuartzRenderer.m
<https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzRenderer.m>,
and noticed that a bunch of functions could directly return an SDRenderType
enum at the end, rather than returning a local variable set at the start
<https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzRenderer.m#L173-L182>.
Can they be changed so that the logic to determine what is returned sits at
the end of the functions instead? E.g. `return fill ? SD_Fill : SD_Stroke`.
Way more concise!

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220906/9deecf05/attachment.htm>

From serb at openjdk.org  Tue Sep  6 23:00:28 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 Sep 2022 23:00:28 GMT
Subject: RFR: 8234315: GTK LAF does not gray out disabled JMenu
In-Reply-To: <s7Az0JMKFqPbKlMnUgUUsQSa2ygH9SW08N0DGr7sQQM=.2561a3ba-40ce-4902-a2d2-992aa1ad565f@github.com>
References: <s7Az0JMKFqPbKlMnUgUUsQSa2ygH9SW08N0DGr7sQQM=.2561a3ba-40ce-4902-a2d2-992aa1ad565f@github.com>
Message-ID: <bGfzgsDcqWsaQ_GSN2gcRfRW5WIbwcbdUAo8G4jd0Hg=.dd10ede5-6fea-42e5-90f8-32dbd757a8ec@github.com>

On Tue, 6 Sep 2022 05:37:02 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> Disabled JMenu foreground color was not grayed out in GTK LAF for version 3. The issue didn't occur in GTK-2. 
> After analysis it has been found that the JMenu widget type was changed to JMenuBar and the color value returned for the foreground color in disabled state was close to black color (RGB 0,0,0) for menubar which is not differentiable from enabled state foreground color.
> 
> As a fix for this problem, if the menubar is in disabled state then the widget is changed to JMenu and color value returned for disabled menu is gray color.
> 
> An automated test case has been added and checked in CI, link is added in JBS.

Does the new color looks the same as in the native applications?

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

PR: https://git.openjdk.org/jdk/pull/10176


From serb at openjdk.org  Tue Sep  6 23:09:49 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 Sep 2022 23:09:49 GMT
Subject: RFR: 6529151: NullPointerException in
 swing.plaf.synth.SynthLookAndFeel$Handler
In-Reply-To: <LNDDuM1Xo2waUauHyNK8iyw6y9cRGnawCO0ZbkVAIm4=.b2b2e136-5728-4734-b060-e61caa21f6c3@github.com>
References: <LNDDuM1Xo2waUauHyNK8iyw6y9cRGnawCO0ZbkVAIm4=.b2b2e136-5728-4734-b060-e61caa21f6c3@github.com>
Message-ID: <ygFiH0PGJxxpqkwqikHsKT3gwcayTf7TeTNGXN58PXU=.0d12f7e5-1d6a-4df2-b024-481414676642@github.com>

On Mon, 5 Sep 2022 12:45:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> NPE is thrown for closed/disposed JDialogs after uninstalling the UI which is because for SynthEditorPaneUI even though is disposed of, Nimbus propertyHandler tries to get the style of this disposed component resulting in NPE, 
> which is fixed by a null check to prevent deferencing style object to get the color.

test/jdk/javax/swing/plaf/synth/RepaintNPE.java line 84:

> 82:                     try
> 83:                     {
> 84:                         Method method = jComp.getClass().getMethod ( "getUI" );

The getUI() method is public, can be used directly.

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

PR: https://git.openjdk.org/jdk/pull/10167


From serb at openjdk.org  Tue Sep  6 23:14:39 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 Sep 2022 23:14:39 GMT
Subject: RFR: 8225012: sanity/client/SwingSet/src/ToolTipDemoTest.java
 fails on Windows
In-Reply-To: <1rb8LBNCEl28QDHvpFScS19N2BP37UKIbc2qyMM33ig=.6957698e-677a-4b5e-bdf1-1f6aa28d4d81@github.com>
References: <1rb8LBNCEl28QDHvpFScS19N2BP37UKIbc2qyMM33ig=.6957698e-677a-4b5e-bdf1-1f6aa28d4d81@github.com>
Message-ID: <ZlU3jNtsiYlzUEM_6v0Ec9gexBXHJVGcPdwPYld7pDU=.214256e3-d7fb-43ed-a0ad-88befffadf5d@github.com>

On Sat, 27 Aug 2022 00:32:11 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> Activate the window with a mouse click.
> Close tooltip by moving the window out of the component.
> 
> Multiple runs have been performed in the CI, totaling 500 runs on each Windows and Mac OS.
> 
> While testing the fix, I have discovered that, while this fixes the problem on Mac and Windows, on linux the test is not fully stable. I have created a bug for that and excluded the test on Linux.

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10053


From serb at openjdk.org  Tue Sep  6 23:14:44 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 Sep 2022 23:14:44 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v2]
In-Reply-To: <z5cIRuzWVpcdvSwJ_7ICFowmCAraWPXrv9b5hBhWHTM=.7c4ee5bb-3d06-41f4-9f59-74f4235e9dc7@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <z5cIRuzWVpcdvSwJ_7ICFowmCAraWPXrv9b5hBhWHTM=.7c4ee5bb-3d06-41f4-9f59-74f4235e9dc7@github.com>
Message-ID: <QuSCtto50ALNpcrQo8TszCEYIY2aFQ5-zQLaZfgDxIo=.9197c0b1-8349-4801-89c7-a6c9356adbe1@github.com>

On Tue, 6 Sep 2022 07:00:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Default echo character obtained through `PasswordField.echoChar` UIProperty returns null for Nimbus L&F,
>> which is fixed by adding the default character * in the UIDefault table.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removal of Nimbus L&F hardcode

I guess currently the Nimbus L&F use some char for the password field, how that place will intrract with this new ui property?

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

PR: https://git.openjdk.org/jdk/pull/10035


From serb at openjdk.org  Tue Sep  6 23:26:40 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 Sep 2022 23:26:40 GMT
Subject: RFR: 7148092: [macosx] When Alt+down arrow key is pressed,
 the combobox popup does not appear. [v3]
In-Reply-To: <9_6m09UHBqjqrDWnuPS7Imjl3tciQr1q7RCxyOY0xXs=.47f6bcbe-38db-40c5-86b5-4329d5c365ef@github.com>
References: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
 <9_6m09UHBqjqrDWnuPS7Imjl3tciQr1q7RCxyOY0xXs=.47f6bcbe-38db-40c5-86b5-4329d5c365ef@github.com>
Message-ID: <jiJjSWCGKuIZum3QI0_85DYYqfGCYvdl0hHI137FKqg=.cdfbfa55-4020-42e3-baf4-f2dcb30564ce@github.com>

On Thu, 25 Aug 2022 16:34:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When comboBox have focus, pressing Alt+Down (or Up) should render the popup which is not happening for Aqua L&F.
>> 
>> Fix is to add toggleAction for Alt+Down/Up keys as has been done for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L912)
>> 
>> closed problemlisted test is used to check the fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use camelCase

Don't we need to align this behaviour to the native apps rather than metal?

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

PR: https://git.openjdk.org/jdk/pull/10014


From serb at openjdk.org  Tue Sep  6 23:34:38 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 Sep 2022 23:34:38 GMT
Subject: RFR: 8292848: AWT_Mixing and TrayIcon tests fail on el8 with
 hard-coded isOel7
In-Reply-To: <ZJrPLHPk000YQPHb73cCqw1l7jP1vwRLEXMlOgrqVSs=.a599b437-a90f-4f81-8ca5-aa2809bde6f7@github.com>
References: <ZJrPLHPk000YQPHb73cCqw1l7jP1vwRLEXMlOgrqVSs=.a599b437-a90f-4f81-8ca5-aa2809bde6f7@github.com>
Message-ID: <d7QG4vaqXjWm4V8GaErxk1GNThZFJoEqFCY8wNc1eiY=.e3079eea-0c65-4951-b980-742b57aec501@github.com>

On Wed, 24 Aug 2022 07:06:15 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> Could you please review the JDK-8292848 bug fixes?
> The purpose of the isOel7 method is to detect differences in GNOME version changes, and the isOel7 
> result should be true after version 8.
> I modified the isOel7 method to use regular expressions instead of hard-coded versions to be able to 
> detect the new os version.
> I also changed the method name to match the new conditions.

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9995


From serb at openjdk.org  Tue Sep  6 23:40:45 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 Sep 2022 23:40:45 GMT
Subject: RFR: 8292738 : JInternalFrame backgroundShadowBorder &
 foregroundShadowBorder line is longer in Mac Look and Feel
In-Reply-To: <X5vBs9CaLJoEiIfONbCx0cwTdHuGIC5mrcEP30AOE48=.f605d66a-e387-4d5f-ba42-a7102f00939f@github.com>
References: <X5vBs9CaLJoEiIfONbCx0cwTdHuGIC5mrcEP30AOE48=.f605d66a-e387-4d5f-ba42-a7102f00939f@github.com>
Message-ID: <4U8fL_K_ckMSfeKzCjb7g5VsuCumQapEA8NL_29_U2c=.15004b40-aab1-4381-a1a7-4e1ca160fb45@github.com>

On Mon, 22 Aug 2022 21:20:54 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> Border line is seen outside  round Rectangle both for JInternalFrame backgroundShadowBorder & foregroundShadowBorder line in mac L&F.
> ![Screen Shot 2022-08-22 at 4 17 49 PM](https://user-images.githubusercontent.com/87324768/186021010-d21aed21-9e05-4b28-846b-2628e367f183.png)
> 
> I have circled the extra part of the line. To make it more visible I changed the color of the backgroundShadowBorder to red
> ![Screen Shot 2022-08-22 at 4 17 37 PM](https://user-images.githubusercontent.com/87324768/186021095-cbfffdba-d43a-47e7-a50b-551c59cb767b.png)
> 
> Fixed the extra length of the line 
> ![Fixed](https://user-images.githubusercontent.com/87324768/186021195-688c3613-fc50-41c3-8cad-94173385dfeb.png)

I assume this is not a regression and reproduced since jdk8?

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

PR: https://git.openjdk.org/jdk/pull/9971


From duke at openjdk.org  Tue Sep  6 23:40:46 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Tue, 6 Sep 2022 23:40:46 GMT
Subject: RFR: 8292738 : JInternalFrame backgroundShadowBorder &
 foregroundShadowBorder line is longer in Mac Look and Feel
In-Reply-To: <X5vBs9CaLJoEiIfONbCx0cwTdHuGIC5mrcEP30AOE48=.f605d66a-e387-4d5f-ba42-a7102f00939f@github.com>
References: <X5vBs9CaLJoEiIfONbCx0cwTdHuGIC5mrcEP30AOE48=.f605d66a-e387-4d5f-ba42-a7102f00939f@github.com>
Message-ID: <NmZq4MwmbrRwLQ7AQov_asrE24qhJ6vCsf6qBwbxGZM=.f5e9fb7f-2a50-4f5b-9eff-1edba2d2087a@github.com>

On Mon, 22 Aug 2022 21:20:54 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> Border line is seen outside  round Rectangle both for JInternalFrame backgroundShadowBorder & foregroundShadowBorder line in mac L&F.
> ![Screen Shot 2022-08-22 at 4 17 49 PM](https://user-images.githubusercontent.com/87324768/186021010-d21aed21-9e05-4b28-846b-2628e367f183.png)
> 
> I have circled the extra part of the line. To make it more visible I changed the color of the backgroundShadowBorder to red
> ![Screen Shot 2022-08-22 at 4 17 37 PM](https://user-images.githubusercontent.com/87324768/186021095-cbfffdba-d43a-47e7-a50b-551c59cb767b.png)
> 
> Fixed the extra length of the line 
> ![Fixed](https://user-images.githubusercontent.com/87324768/186021195-688c3613-fc50-41c3-8cad-94173385dfeb.png)

Yes, this is not a regression & I was able to reproduce this from JDK 1.8.0_201
The line was looking odd hence I added a fix.

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

PR: https://git.openjdk.org/jdk/pull/9971


From serb at openjdk.org  Tue Sep  6 23:42:39 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 Sep 2022 23:42:39 GMT
Subject: RFR: 7175397: The divider color is not changed to green when
 dragging for Nimbus LaF. [v2]
In-Reply-To: <-21DskiK73HbWK0fvkx1WKzGv9hDLuUM7vCMgMDDpG4=.c7df46c6-9f62-45ed-a8f2-d8f309924015@github.com>
References: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
 <-21DskiK73HbWK0fvkx1WKzGv9hDLuUM7vCMgMDDpG4=.c7df46c6-9f62-45ed-a8f2-d8f309924015@github.com>
Message-ID: <KToUfHglTLs7sKMpBmchKZdihyo916qETdKHr7Sur8c=.f95ecbc0-8d32-4de4-9798-3520fad8f10e@github.com>

On Wed, 24 Aug 2022 04:21:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SplitPaneDivider.draggingColor UIProperty was not honoured in Nimbus L&F. 
>> Added support for setting SplitPane dragging color for Nimbus L&F by drawing a fillRect of the set color as done in BasicLookAndFeel.
>> The fix relies on `continuousLayout` property being false by default which is enabled for Nimbus, which is set to default false now, same as in other L&F. I think it was set true just to have documented default value in JDK-6937415
>> 
>> closed test mentioned in JBS is used for fix check.
>> All jtreg swing tests are ok along with SwingSet2 JSplitPane demo in Nimbus L&F.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert default value

Isn't this is a similar bug reported here?
https://bugs.openjdk.org/browse/JDK-8075608
Can we compare evaluation of that and this bug?

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

PR: https://git.openjdk.org/jdk/pull/9937


From serb at openjdk.org  Tue Sep  6 23:45:42 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 6 Sep 2022 23:45:42 GMT
Subject: RFR: 8292328 : AccessibleActionsTest.java test instruction for
 show popup on JLabel did not specify shift key
In-Reply-To: <PRgGYMbpY_r_y1Rb7qpIn7ffmOZiqisA5i1QBuwFFHY=.3df5c35c-bcb8-4eba-be25-23e13db36f99@github.com>
References: <PRgGYMbpY_r_y1Rb7qpIn7ffmOZiqisA5i1QBuwFFHY=.3df5c35c-bcb8-4eba-be25-23e13db36f99@github.com>
Message-ID: <_d6ErXuzVGEE1mM1DwHFE9_vsXynSmFTn_wn4JDfQ5Y=.df53418a-8f15-452a-8346-526f55b5c0b4@github.com>

On Sat, 13 Aug 2022 22:44:52 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> Corrected the test instruction to show the popup menu on JLabel when voice over is enabled .
> 
> @shurymury

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9868


From psadhukhan at openjdk.org  Wed Sep  7 04:31:42 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 7 Sep 2022 04:31:42 GMT
Subject: RFR: 7148092: [macosx] When Alt+down arrow key is pressed,
 the combobox popup does not appear. [v3]
In-Reply-To: <9_6m09UHBqjqrDWnuPS7Imjl3tciQr1q7RCxyOY0xXs=.47f6bcbe-38db-40c5-86b5-4329d5c365ef@github.com>
References: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
 <9_6m09UHBqjqrDWnuPS7Imjl3tciQr1q7RCxyOY0xXs=.47f6bcbe-38db-40c5-86b5-4329d5c365ef@github.com>
Message-ID: <dTZpC9YgwsUz0KT9Xg9E3c7He5AXBNNzr88n9rBEyes=.1bb81bd7-0ac8-4923-af88-c4347711b6a0@github.com>

On Thu, 25 Aug 2022 16:34:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When comboBox have focus, pressing Alt+Down (or Up) should render the popup which is not happening for Aqua L&F.
>> 
>> Fix is to add toggleAction for Alt+Down/Up keys as has been done for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L912)
>> 
>> closed problemlisted test is used to check the fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use camelCase

Native behaves same as is being done in this PR (which is extra from Metal) which is already mentioned above.

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

PR: https://git.openjdk.org/jdk/pull/10014


From psadhukhan at openjdk.org  Wed Sep  7 04:40:56 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 7 Sep 2022 04:40:56 GMT
Subject: RFR: 6529151: NullPointerException in
 swing.plaf.synth.SynthLookAndFeel$Handler [v2]
In-Reply-To: <LNDDuM1Xo2waUauHyNK8iyw6y9cRGnawCO0ZbkVAIm4=.b2b2e136-5728-4734-b060-e61caa21f6c3@github.com>
References: <LNDDuM1Xo2waUauHyNK8iyw6y9cRGnawCO0ZbkVAIm4=.b2b2e136-5728-4734-b060-e61caa21f6c3@github.com>
Message-ID: <gmecXQOdnDbdAyGedDD2IU7pAPe2IBnR46v-lJvHozI=.852f031d-dfb9-4d54-9914-226084196545@github.com>

> NPE is thrown for closed/disposed JDialogs after uninstalling the UI which is because for SynthEditorPaneUI even though is disposed of, Nimbus propertyHandler tries to get the style of this disposed component resulting in NPE, 
> which is fixed by a null check to prevent deferencing style object to get the color.

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

  test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10167/files
  - new: https://git.openjdk.org/jdk/pull/10167/files/44cc6fbd..f62d58b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10167&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10167&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/10167


From psadhukhan at openjdk.org  Wed Sep  7 04:40:57 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 7 Sep 2022 04:40:57 GMT
Subject: RFR: 6529151: NullPointerException in
 swing.plaf.synth.SynthLookAndFeel$Handler [v2]
In-Reply-To: <ygFiH0PGJxxpqkwqikHsKT3gwcayTf7TeTNGXN58PXU=.0d12f7e5-1d6a-4df2-b024-481414676642@github.com>
References: <LNDDuM1Xo2waUauHyNK8iyw6y9cRGnawCO0ZbkVAIm4=.b2b2e136-5728-4734-b060-e61caa21f6c3@github.com>
 <ygFiH0PGJxxpqkwqikHsKT3gwcayTf7TeTNGXN58PXU=.0d12f7e5-1d6a-4df2-b024-481414676642@github.com>
Message-ID: <Lfbkd3bNmSi7fdJtKcBck_i96lnWLF7ZixSdgyi4cvc=.3056bc46-d988-4a23-b780-393d4d6fe932@github.com>

On Tue, 6 Sep 2022 23:05:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test fix
>
> test/jdk/javax/swing/plaf/synth/RepaintNPE.java line 84:
> 
>> 82:                     try
>> 83:                     {
>> 84:                         Method method = jComp.getClass().getMethod ( "getUI" );
> 
> The getUI() method is public, can be used directly.

Yes. modified.

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

PR: https://git.openjdk.org/jdk/pull/10167


From dnguyen at openjdk.org  Wed Sep  7 06:21:48 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 7 Sep 2022 06:21:48 GMT
Subject: RFR: 7175397: The divider color is not changed to green when
 dragging for Nimbus LaF. [v2]
In-Reply-To: <-21DskiK73HbWK0fvkx1WKzGv9hDLuUM7vCMgMDDpG4=.c7df46c6-9f62-45ed-a8f2-d8f309924015@github.com>
References: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
 <-21DskiK73HbWK0fvkx1WKzGv9hDLuUM7vCMgMDDpG4=.c7df46c6-9f62-45ed-a8f2-d8f309924015@github.com>
Message-ID: <QqbAcyo6iSxc8BKf_ZdFjNPUF5S9iLYzzfjjg9m24go=.872198bf-7883-4a6d-b8cb-2451dbbf5068@github.com>

On Wed, 24 Aug 2022 04:21:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SplitPaneDivider.draggingColor UIProperty was not honoured in Nimbus L&F. 
>> Added support for setting SplitPane dragging color for Nimbus L&F by drawing a fillRect of the set color as done in BasicLookAndFeel.
>> The fix relies on `continuousLayout` property being false by default which is enabled for Nimbus, which is set to default false now, same as in other L&F. I think it was set true just to have documented default value in JDK-6937415
>> 
>> closed test mentioned in JBS is used for fix check.
>> All jtreg swing tests are ok along with SwingSet2 JSplitPane demo in Nimbus L&F.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert default value

Changes requested by dnguyen (Author).

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java line 369:

> 367: 
> 368:             g.setColor(dividerDraggingColor);
> 369:             if(jc.getOrientation() == JSplitPane.HORIZONTAL_SPLIT) {

I know these if's already existed, but now might be a good time to also update these by adding a space after the if's to match the space after the else?

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

PR: https://git.openjdk.org/jdk/pull/9937


From psadhukhan at openjdk.org  Wed Sep  7 06:21:49 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 7 Sep 2022 06:21:49 GMT
Subject: RFR: 7175397: The divider color is not changed to green when
 dragging for Nimbus LaF. [v2]
In-Reply-To: <KToUfHglTLs7sKMpBmchKZdihyo916qETdKHr7Sur8c=.f95ecbc0-8d32-4de4-9798-3520fad8f10e@github.com>
References: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
 <-21DskiK73HbWK0fvkx1WKzGv9hDLuUM7vCMgMDDpG4=.c7df46c6-9f62-45ed-a8f2-d8f309924015@github.com>
 <KToUfHglTLs7sKMpBmchKZdihyo916qETdKHr7Sur8c=.f95ecbc0-8d32-4de4-9798-3520fad8f10e@github.com>
Message-ID: <CF5ldp7V6i7S5iZiH1oefypzAAeaCcCwkDGCkwELlic=.5f0866d0-fa37-45e2-8dd7-5ec8e6ef68af@github.com>

On Tue, 6 Sep 2022 23:39:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Isn't this is a similar bug reported here? https://bugs.openjdk.org/browse/JDK-8075608 Can we compare evaluation of that and this bug?

It was mentioned in that bug that we need to change the painter to fill the component, which is  not the case.
We dont necessarily have to change the component to honour this proprty of dragging color.  
Since this SplitPane dragging color is honoured for **non-continuous layout** only, even for other L&F, we can just a do a fill rect of the specified color and show that rectangle, as is being done, instead of changing the divider component (as is the case for continuous layout) when the divider is moved, so that the specified color rectangle is shown till the divider stops moving, at which point the divider component will be drawn again along with splitted components. 
In case of **continuous layout**, the divider component needs to be shown **always** along with real-time repaint of splitted components, for which case, this divider dragging color is not honoured.

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

PR: https://git.openjdk.org/jdk/pull/9937


From duke at openjdk.org  Wed Sep  7 07:47:59 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 7 Sep 2022 07:47:59 GMT
Subject: RFR: 8292376: A few Swing methods use inheritDoc on exceptions
 which are not inherited [v3]
In-Reply-To: <W1yenf_2rr8sMDSjJcKF-IGZa_mGYSG572YrlWcxH7w=.9388229b-7cd5-42b7-aaf8-00cdd955278a@github.com>
References: <W1yenf_2rr8sMDSjJcKF-IGZa_mGYSG572YrlWcxH7w=.9388229b-7cd5-42b7-aaf8-00cdd955278a@github.com>
Message-ID: <7DrIMbypxFJ46pfk_b6CdZ030d6p8s-PUJM_XsyQZCI=.a72c2f2c-bbf8-4750-9758-848988642a4f@github.com>

> Document update for getBaselineResizeBehavior() and getBaseline() method description in JSpinner, AbstractBorder and TitledBorder .

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Review comment fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9902/files
  - new: https://git.openjdk.org/jdk/pull/9902/files/f4e9d288..cae9de86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9902&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9902&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/9902


From duke at openjdk.org  Wed Sep  7 07:48:00 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 7 Sep 2022 07:48:00 GMT
Subject: RFR: 8292376: A few Swing methods use inheritDoc on exceptions
 which are not inherited [v2]
In-Reply-To: <zo7W-XDAUtT7atl5xA5rrJREy0L2g3ibrpCPnjx11J8=.bf27e680-fa00-4f1e-a60f-c8300e3574fb@github.com>
References: <W1yenf_2rr8sMDSjJcKF-IGZa_mGYSG572YrlWcxH7w=.9388229b-7cd5-42b7-aaf8-00cdd955278a@github.com>
 <NL96eVu0zHujvOrGCR9P98jZRcVbf8rezkzLIPzA7OA=.30b5f2b1-84c1-42a3-babf-ccf9e96ff6f6@github.com>
 <zo7W-XDAUtT7atl5xA5rrJREy0L2g3ibrpCPnjx11J8=.bf27e680-fa00-4f1e-a60f-c8300e3574fb@github.com>
Message-ID: <F_t3AFfaVD9tk6N3XBObGBICg2QKaeDIivWv-yP33G0=.cdf1ba23-3f88-4ba6-8827-e212e52fccd6@github.com>

On Tue, 6 Sep 2022 16:55:12 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright year updated
>
> src/java.desktop/share/classes/javax/swing/border/AbstractBorder.java line 184:
> 
>> 182:      * @return an enum indicating how the baseline changes as the border is
>> 183:      *         resized
>> 184:      * @throws NullPointerException if passed in {@code Component} is {@code null}
> 
> `if passed in {@code Component} is {@code null}` - Rephrasing this sentence would be better. Something like `if {@code Component} is {@code null}`.

Updated in method description.

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

PR: https://git.openjdk.org/jdk/pull/9902


From tr at openjdk.org  Wed Sep  7 09:53:37 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 7 Sep 2022 09:53:37 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v2]
In-Reply-To: <VIoRxdYnxXyLcWgaeR8nIXS4OH2KU86KDTLIK6V7cv8=.a425eff7-976f-4e8d-8e01-80a9ebdf06c6@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
 <VIoRxdYnxXyLcWgaeR8nIXS4OH2KU86KDTLIK6V7cv8=.a425eff7-976f-4e8d-8e01-80a9ebdf06c6@github.com>
Message-ID: <RdqjwrNyXb5EVO5RzzmswSC0iHt8q4CqD0PdV0p37cU=.94fc2682-43b6-4fc9-88c6-3aeff3215e89@github.com>

On Wed, 24 Aug 2022 04:43:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Label.foreground UIProperty is not honored by Nimbus L&F.
>> Added support for setting JLabel foreground color for Nimbus L&F
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Fix is working fine.

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

Marked as reviewed by tr (Author).

PR: https://git.openjdk.org/jdk/pull/9900


From duke at openjdk.org  Wed Sep  7 10:31:46 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 7 Sep 2022 10:31:46 GMT
Subject: RFR: 8234315: GTK LAF does not gray out disabled JMenu
In-Reply-To: <bGfzgsDcqWsaQ_GSN2gcRfRW5WIbwcbdUAo8G4jd0Hg=.dd10ede5-6fea-42e5-90f8-32dbd757a8ec@github.com>
References: <s7Az0JMKFqPbKlMnUgUUsQSa2ygH9SW08N0DGr7sQQM=.2561a3ba-40ce-4902-a2d2-992aa1ad565f@github.com>
 <bGfzgsDcqWsaQ_GSN2gcRfRW5WIbwcbdUAo8G4jd0Hg=.dd10ede5-6fea-42e5-90f8-32dbd757a8ec@github.com>
Message-ID: <RSaFzguhGV7ycGKMuqM1dsbWNC91B4G4jw9KJvR7G9E=.8aa3da70-de50-4b54-ace8-f9b494d296b8@github.com>

On Tue, 6 Sep 2022 22:57:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Does the new color looks the same as in the native applications?

I think it is same as in native application. Attached a screenshot of test application and text editor (gedit) in ubuntu. 
![DisableMenuColor](https://user-images.githubusercontent.com/107542245/188856123-0aedbfd7-1834-4fb2-ab1a-07ec572627cb.png)

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

PR: https://git.openjdk.org/jdk/pull/10176


From duke at openjdk.org  Wed Sep  7 10:34:44 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 7 Sep 2022 10:34:44 GMT
Subject: RFR: 8292376: A few Swing methods use inheritDoc on exceptions
 which are not inherited [v3]
In-Reply-To: <7DrIMbypxFJ46pfk_b6CdZ030d6p8s-PUJM_XsyQZCI=.a72c2f2c-bbf8-4750-9758-848988642a4f@github.com>
References: <W1yenf_2rr8sMDSjJcKF-IGZa_mGYSG572YrlWcxH7w=.9388229b-7cd5-42b7-aaf8-00cdd955278a@github.com>
 <7DrIMbypxFJ46pfk_b6CdZ030d6p8s-PUJM_XsyQZCI=.a72c2f2c-bbf8-4750-9758-848988642a4f@github.com>
Message-ID: <-6W6lU5fpF4n7PQJ9Jm5rNLQ5x1z8wCghIGnKJ7D-kI=.8829488c-f965-452b-911f-6e9eed34eba2@github.com>

On Wed, 7 Sep 2022 07:47:59 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Document update for getBaselineResizeBehavior() and getBaseline() method description in JSpinner, AbstractBorder and TitledBorder .
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

Attached the CSR link
https://bugs.openjdk.org/browse/JDK-8293470

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

PR: https://git.openjdk.org/jdk/pull/9902


From psadhukhan at openjdk.org  Wed Sep  7 12:38:51 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 7 Sep 2022 12:38:51 GMT
Subject: Integrated: 4850101: Setting mnemonic to VK_F4 underlines the letter S
 in a button.
In-Reply-To: <fwQauIncMy46_rhIyR9OW70AWjzoa3NO4FfMjIZ3wkE=.e4a6d40e-a004-4d6c-b543-1e8a7f31cca7@github.com>
References: <fwQauIncMy46_rhIyR9OW70AWjzoa3NO4FfMjIZ3wkE=.e4a6d40e-a004-4d6c-b543-1e8a7f31cca7@github.com>
Message-ID: <WABq50z7BMjDnvb30qD3-rcF7TYHif6VriML6YByy3A=.7df4db22-87cd-4da9-bd47-9b78709ebada@github.com>

On Tue, 2 Aug 2022 10:22:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is seen that using VK_F4 in JButton's setMnemonic(int i), causes the letter 'S' in the JButton to be underlined if JButton's text has 'S' in its string.
> This is because [**VK_F4**](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/event/KeyEvent.java#L506) keycode is 0x73 (115 in decimal) which happens to be value of lowercase [**'s'** ](https://www.cs.cmu.edu/~pattis/15-1XX/common/handouts/ascii.html) so as per the logic implemented in SwingUtilities.findDisplayedMnemonicIndex(), the first index of the character (either lowecasr or uppercase) is returned as a mnemonic, which gets underlined.
> 
> Fix is made to ignore Action Keys from VK_F1->VK_F11 as displayed mnemonic which corresponds to lowercase p->z

This pull request has now been integrated.

Changeset: d6961045
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d6961045353897967bb734740225bd1cddf158e5
Stats:     129 lines in 2 files changed: 129 ins; 0 del; 0 mod

4850101: Setting mnemonic to VK_F4 underlines the letter S in a button.

Reviewed-by: prr

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

PR: https://git.openjdk.org/jdk/pull/9712


From psadhukhan at openjdk.org  Wed Sep  7 16:23:43 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 7 Sep 2022 16:23:43 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v3]
In-Reply-To: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
Message-ID: <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>

> Default echo character obtained through `PasswordField.echoChar` UIProperty returns null for Nimbus L&F,
> which is fixed by adding the default character * in the UIDefault table.

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

  Honour PasswordField.echoChar property

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10035/files
  - new: https://git.openjdk.org/jdk/pull/10035/files/51919462..63998b9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10035&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10035&range=01-02

  Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10035.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10035/head:pull/10035

PR: https://git.openjdk.org/jdk/pull/10035


From psadhukhan at openjdk.org  Wed Sep  7 16:23:44 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 7 Sep 2022 16:23:44 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v2]
In-Reply-To: <QuSCtto50ALNpcrQo8TszCEYIY2aFQ5-zQLaZfgDxIo=.9197c0b1-8349-4801-89c7-a6c9356adbe1@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <z5cIRuzWVpcdvSwJ_7ICFowmCAraWPXrv9b5hBhWHTM=.7c4ee5bb-3d06-41f4-9f59-74f4235e9dc7@github.com>
 <QuSCtto50ALNpcrQo8TszCEYIY2aFQ5-zQLaZfgDxIo=.9197c0b1-8349-4801-89c7-a6c9356adbe1@github.com>
Message-ID: <PHMcTuOrjKefqmC2jQs_53kRfWf22AGMEWTiVYB0MEU=.b5f782ff-ad94-4efe-a36c-48d910de6170@github.com>

On Tue, 6 Sep 2022 23:12:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I guess currently the Nimbus L&F use some char for the password field, how that place will intrract with this new ui property?

Added code to interact with the property same way other L&F does. tested with



public class PasswordFieldTest {
        public static void main(String[] args) {
                UIManager.put("PasswordField.echoChar", '@');
                JFrame mainFrame = new JFrame("");
                JPasswordField passwordField = new javax.swing.JPasswordField();
                passwordField.setEnabled(true);
                passwordField.setText("blahblahblah");
                mainFrame.getContentPane().add(passwordField);
                mainFrame.setSize(300,100);
                mainFrame.setVisible(true);
        }
}

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

PR: https://git.openjdk.org/jdk/pull/10035


From duke at openjdk.org  Wed Sep  7 18:51:39 2022
From: duke at openjdk.org (SWinxy)
Date: Wed, 7 Sep 2022 18:51:39 GMT
Subject: RFR: 8293478: [java.desktop/macOS] Condense SDRenderType usages in
 QuartzRenderer.m
Message-ID: <levplAHOHGYRedb1qypkWNb4hcv6W0rO6vF2wbfbf7M=.79250f01-b07e-41e6-b1d3-166ffde6bd76@github.com>

The `SDRenderType` enum is often returned using a variable declared at the start of functions. These can be inlined in the `return` itself. Using a ternary operator condenses what may be 12 lines into one, in the most extreme cases. `doRectUsingCG` and `doPolyUsingCG` were both modified more than the rest, but still are equivalent.

Example change:

SDRenderType renderType = SD_Nothing;

if (fill == YES)
{
    renderType = SD_Fill;
}
else
{
    renderType = SD_Stroke;
}

// ...

return renderType;



// ...

return fill ? SD_Fill : SD_Stroke;

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

Commit messages:
 - Inline SDRenderType in QuartzRenderer.m

Changes: https://git.openjdk.org/jdk/pull/10174/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10174&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293478
  Stats: 125 lines in 1 file changed: 17 ins; 68 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/10174.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10174/head:pull/10174

PR: https://git.openjdk.org/jdk/pull/10174


From duke at openjdk.org  Wed Sep  7 18:51:39 2022
From: duke at openjdk.org (SWinxy)
Date: Wed, 7 Sep 2022 18:51:39 GMT
Subject: RFR: 8293478: [java.desktop/macOS] Condense SDRenderType usages in
 QuartzRenderer.m
In-Reply-To: <levplAHOHGYRedb1qypkWNb4hcv6W0rO6vF2wbfbf7M=.79250f01-b07e-41e6-b1d3-166ffde6bd76@github.com>
References: <levplAHOHGYRedb1qypkWNb4hcv6W0rO6vF2wbfbf7M=.79250f01-b07e-41e6-b1d3-166ffde6bd76@github.com>
Message-ID: <uBYerno12C9tfTDYHbGcbI7GKMcS43dlURnGewrhRlQ=.94aa6f5c-14c0-4354-8daa-e3f12d061d06@github.com>

On Mon, 5 Sep 2022 23:41:40 GMT, SWinxy <duke at openjdk.org> wrote:

> The `SDRenderType` enum is often returned using a variable declared at the start of functions. These can be inlined in the `return` itself. Using a ternary operator condenses what may be 12 lines into one, in the most extreme cases. `doRectUsingCG` and `doPolyUsingCG` were both modified more than the rest, but still are equivalent.
> 
> Example change:
> 
> SDRenderType renderType = SD_Nothing;
> 
> if (fill == YES)
> {
>     renderType = SD_Fill;
> }
> else
> {
>     renderType = SD_Stroke;
> }
> 
> // ...
> 
> return renderType;
> 
> 
> 
> // ...
> 
> return fill ? SD_Fill : SD_Stroke;

Hey, @TheShermanTanker, could you please create an issue number for this? Thanks!

I have emailed the client-dev group after you mentioned it (though I prefer to keep discussions centralized here, bah). I thought in the past that the checks were necessary but nope, they fail just because.

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

PR: https://git.openjdk.org/jdk/pull/10174


From jwaters at openjdk.org  Wed Sep  7 18:51:40 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 7 Sep 2022 18:51:40 GMT
Subject: RFR: 8293478: [java.desktop/macOS] Condense SDRenderType usages in
 QuartzRenderer.m
In-Reply-To: <levplAHOHGYRedb1qypkWNb4hcv6W0rO6vF2wbfbf7M=.79250f01-b07e-41e6-b1d3-166ffde6bd76@github.com>
References: <levplAHOHGYRedb1qypkWNb4hcv6W0rO6vF2wbfbf7M=.79250f01-b07e-41e6-b1d3-166ffde6bd76@github.com>
Message-ID: <N4bgMq7etDO9Ji-bqhDTPc6ouFPjm5xr1tScN3ZGPlo=.7b64383f-7190-4b22-825f-0e81a0a3a83a@github.com>

On Mon, 5 Sep 2022 23:41:40 GMT, SWinxy <duke at openjdk.org> wrote:

> The `SDRenderType` enum is often returned using a variable declared at the start of functions. These can be inlined in the `return` itself. Using a ternary operator condenses what may be 12 lines into one, in the most extreme cases. `doRectUsingCG` and `doPolyUsingCG` were both modified more than the rest, but still are equivalent.
> 
> Example change:
> 
> SDRenderType renderType = SD_Nothing;
> 
> if (fill == YES)
> {
>     renderType = SD_Fill;
> }
> else
> {
>     renderType = SD_Stroke;
> }
> 
> // ...
> 
> return renderType;
> 
> 
> 
> // ...
> 
> return fill ? SD_Fill : SD_Stroke;

No problem, but have you checked with the relevant groups about this change yet? If not, I'd recommend doing so before I create the entry for this PR. A MacOS test also seems to be failing, though it doesn't seem to be related to the changes made here

I agree it's a frustrating process, but unfortunately that's how most maintainers prefer to discuss changes. However, I've had enough of waiting, so I'm just crossing my fingers and creating it anyway
https://bugs.openjdk.org/browse/JDK-8293478

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

PR: https://git.openjdk.org/jdk/pull/10174


From duke at openjdk.org  Wed Sep  7 18:59:38 2022
From: duke at openjdk.org (SWinxy)
Date: Wed, 7 Sep 2022 18:59:38 GMT
Subject: RFR: 8293478: [java.desktop/macOS] Condense SDRenderType usages in
 QuartzRenderer.m
In-Reply-To: <levplAHOHGYRedb1qypkWNb4hcv6W0rO6vF2wbfbf7M=.79250f01-b07e-41e6-b1d3-166ffde6bd76@github.com>
References: <levplAHOHGYRedb1qypkWNb4hcv6W0rO6vF2wbfbf7M=.79250f01-b07e-41e6-b1d3-166ffde6bd76@github.com>
Message-ID: <U_I4vJ1-2V7CBkTnohAbm6crTXDaZ8ggNGgZT1brRVU=.767df833-4b2e-479a-b19c-36d18eaa9398@github.com>

On Mon, 5 Sep 2022 23:41:40 GMT, SWinxy <duke at openjdk.org> wrote:

> The `SDRenderType` enum is often returned using a variable declared at the start of functions. These can be inlined in the `return` itself. Using a ternary operator condenses what may be 12 lines into one, in the most extreme cases. `doRectUsingCG` and `doPolyUsingCG` were both modified more than the rest, but still are equivalent.
> 
> Example change:
> 
> SDRenderType renderType = SD_Nothing;
> 
> if (fill == YES)
> {
>     renderType = SD_Fill;
> }
> else
> {
>     renderType = SD_Stroke;
> }
> 
> // ...
> 
> return renderType;
> 
> 
> 
> // ...
> 
> return fill ? SD_Fill : SD_Stroke;

Much thanks. I forgot that the bot just *immediately* requests a review when there's a bug in the title.

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

PR: https://git.openjdk.org/jdk/pull/10174


From duke at openjdk.org  Wed Sep  7 21:19:45 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 7 Sep 2022 21:19:45 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v11]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <PWiDgXMcBqvAVWCzSSY7MAi32jAfVeBeRs_x1ymvahY=.6d7b364c-f4c3-4497-82fb-8b4d1a71d4f2@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

  Adds a test for null value.
  
  The stringToColor method accepts null argument and must returns null.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/23416aaa..05ec5d32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=09-10

  Stats: 15 lines in 1 file changed: 6 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/9825.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9825/head:pull/9825

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Wed Sep  7 21:48:03 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 7 Sep 2022 21:48:03 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v12]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <hx7Smlmdg1jL1r20YUR0CnXgLApduepW4CvpXjb8oIM=.8f947601-702c-443e-b4ea-0fcfe8e2feae@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

  Null value - Opaque color declaration 
  
  Fixes handling of null argument and simplifies opaque color declarations.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/05ec5d32..1f501bc6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=10-11

  Stats: 152 lines in 1 file changed: 2 ins; 1 del; 149 mod
  Patch: https://git.openjdk.org/jdk/pull/9825.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9825/head:pull/9825

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Wed Sep  7 21:55:53 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 7 Sep 2022 21:55:53 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v13]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <vc031T8ZH6oYeJacuKa7BfWxF16TITrxAvwD1dwFgjM=.61ece218-0ed8-42e2-a11e-fce75b5519aa@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

   Whitespace errors
  
  Removes whitespaces.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/1f501bc6..c606d8bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=11-12

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

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Wed Sep  7 22:13:59 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Wed, 7 Sep 2022 22:13:59 GMT
Subject: RFR: 8292271 : Fix
 java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java test [v2]
In-Reply-To: <gpnPCT4GfLO7w3w3uuUVk3BBehfPYJeFseqU2dZ_yZk=.69f0df8a-10a7-47da-9de0-3c7b269ab9f9@github.com>
References: <gpnPCT4GfLO7w3w3uuUVk3BBehfPYJeFseqU2dZ_yZk=.69f0df8a-10a7-47da-9de0-3c7b269ab9f9@github.com>
Message-ID: <tU3HPyHA-K39Oa3GrSLi69PqsUO95C2nfDKAXWveHbc=.df574065-e1ba-4f8a-b66d-39f558c2062b@github.com>

> 1) This test was failing due to yesno 
> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno 
> 2) PrintCheckboxManualTest.html file was missing
> 3) Added os.family since test instruction says that its a linux and solair toolkit only test
> 4) Removed Sysout & TestDialog class &  added a better manual framework to show the instruction and test frame. 
> 
> @shurymury

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

  Show Frame within EDT

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9858/files
  - new: https://git.openjdk.org/jdk/pull/9858/files/dcfc89a3..7d7d0989

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9858&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9858&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/9858


From duke at openjdk.org  Wed Sep  7 22:30:55 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Wed, 7 Sep 2022 22:30:55 GMT
Subject: RFR: 8292271 : Fix
 java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java test [v3]
In-Reply-To: <gpnPCT4GfLO7w3w3uuUVk3BBehfPYJeFseqU2dZ_yZk=.69f0df8a-10a7-47da-9de0-3c7b269ab9f9@github.com>
References: <gpnPCT4GfLO7w3w3uuUVk3BBehfPYJeFseqU2dZ_yZk=.69f0df8a-10a7-47da-9de0-3c7b269ab9f9@github.com>
Message-ID: <GtgEncYIH3IH0cg1SamQ0exHfnOBJjpwEcwxAzfm518=.b16988d1-3cb6-4e81-9798-b6aed0184f94@github.com>

> 1) This test was failing due to yesno 
> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno 
> 2) PrintCheckboxManualTest.html file was missing
> 3) Added os.family since test instruction says that its a linux and solair toolkit only test
> 4) Removed Sysout & TestDialog class &  added a better manual framework to show the instruction and test frame. 
> 
> @shurymury

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

  Fixed white space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9858/files
  - new: https://git.openjdk.org/jdk/pull/9858/files/7d7d0989..ad3fd8af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9858&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9858&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/9858


From duke at openjdk.org  Wed Sep  7 22:33:17 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Wed, 7 Sep 2022 22:33:17 GMT
Subject: RFR: 8292271 : Fix
 java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java test [v4]
In-Reply-To: <gpnPCT4GfLO7w3w3uuUVk3BBehfPYJeFseqU2dZ_yZk=.69f0df8a-10a7-47da-9de0-3c7b269ab9f9@github.com>
References: <gpnPCT4GfLO7w3w3uuUVk3BBehfPYJeFseqU2dZ_yZk=.69f0df8a-10a7-47da-9de0-3c7b269ab9f9@github.com>
Message-ID: <TgxAXnZLR8Zgf4YBL-M-XOsX2lnDcDzugvygTdfhHbo=.eda78da6-64ec-449c-9555-f25bcb59f741@github.com>

> 1) This test was failing due to yesno 
> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno 
> 2) PrintCheckboxManualTest.html file was missing
> 3) Added os.family since test instruction says that its a linux and solair toolkit only test
> 4) Removed Sysout & TestDialog class &  added a better manual framework to show the instruction and test frame. 
> 
> @shurymury

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

  Fixed space issue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9858/files
  - new: https://git.openjdk.org/jdk/pull/9858/files/ad3fd8af..7e848533

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9858&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9858&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/9858


From duke at openjdk.org  Wed Sep  7 22:42:35 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Wed, 7 Sep 2022 22:42:35 GMT
Subject: RFR: 8292309 : Fix
 java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java test
 [v2]
In-Reply-To: <uFqQUzkuWOrGXowhXEwVwRN5HjCisrPLGNK-rpaUyUc=.6c97b5ba-e463-45d1-8cb4-e4799148e212@github.com>
References: <uFqQUzkuWOrGXowhXEwVwRN5HjCisrPLGNK-rpaUyUc=.6c97b5ba-e463-45d1-8cb4-e4799148e212@github.com>
Message-ID: <VMTD0XIVmHyVmza1t3HgFiZccJ7EMmzXgooQlQPgmyk=.74207d3f-3ed3-4c3c-9fa1-a90df2e411b2@github.com>

> 1) Fixed Parse Exception by removing yesno
> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno
> 2) Throw jtreg.SkippedException when printer is not configured on the test host
> 3) Replaced Sysout & TestDialog with ManualTestFrame, which allows to the user to better decide test results and to take screen shot if test fails.
> 
> @shurymury

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

  Show Frame with in EDT

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9865/files
  - new: https://git.openjdk.org/jdk/pull/9865/files/aea79929..07495189

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9865&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9865&range=00-01

  Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9865.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9865/head:pull/9865

PR: https://git.openjdk.org/jdk/pull/9865


From serb at openjdk.org  Thu Sep  8 03:33:49 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Sep 2022 03:33:49 GMT
Subject: RFR: 6529151: NullPointerException in
 swing.plaf.synth.SynthLookAndFeel$Handler [v2]
In-Reply-To: <gmecXQOdnDbdAyGedDD2IU7pAPe2IBnR46v-lJvHozI=.852f031d-dfb9-4d54-9914-226084196545@github.com>
References: <LNDDuM1Xo2waUauHyNK8iyw6y9cRGnawCO0ZbkVAIm4=.b2b2e136-5728-4734-b060-e61caa21f6c3@github.com>
 <gmecXQOdnDbdAyGedDD2IU7pAPe2IBnR46v-lJvHozI=.852f031d-dfb9-4d54-9914-226084196545@github.com>
Message-ID: <gmbIhDXnMwI_KYuY5m0k3xIskBPikt9HxPSUz7PW39U=.1602dc9b-07ee-4651-9498-c2bd7b8ece8e@github.com>

On Wed, 7 Sep 2022 04:40:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> NPE is thrown for closed/disposed JDialogs after uninstalling the UI which is because for SynthEditorPaneUI even though is disposed of, Nimbus propertyHandler tries to get the style of this disposed component resulting in NPE, 
>> which is fixed by a null check to prevent deferencing style object to get the color.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test fix

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10167


From serb at openjdk.org  Thu Sep  8 03:39:42 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Sep 2022 03:39:42 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v3]
In-Reply-To: <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>
Message-ID: <OKwiyluDGrJJzJjqurX6vA4apF1Dz-v39QJlk8s7vGA=.189ba8bb-9d6f-4ea7-b399-801a857981b9@github.com>

On Wed, 7 Sep 2022 16:23:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Default echo character obtained through `PasswordField.echoChar` UIProperty returns null for Nimbus L&F,
>> which is fixed by adding the default character * in the UIDefault table.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Honour PasswordField.echoChar property

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java line 731:

> 729:                   });
> 730: 
> 731:         table.put("PasswordField.echoChar", '*');

It is still unclear where this "*" was stored before(will we ignore it now?), since the Nimbus used that symbol already.

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

PR: https://git.openjdk.org/jdk/pull/10035


From serb at openjdk.org  Thu Sep  8 03:41:50 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Sep 2022 03:41:50 GMT
Subject: RFR: 8292738 : JInternalFrame backgroundShadowBorder &
 foregroundShadowBorder line is longer in Mac Look and Feel
In-Reply-To: <X5vBs9CaLJoEiIfONbCx0cwTdHuGIC5mrcEP30AOE48=.f605d66a-e387-4d5f-ba42-a7102f00939f@github.com>
References: <X5vBs9CaLJoEiIfONbCx0cwTdHuGIC5mrcEP30AOE48=.f605d66a-e387-4d5f-ba42-a7102f00939f@github.com>
Message-ID: <Cpl7ZxeFgd6cOVsR8ZgCxjWWhlZipOELC9NHzm-5N7A=.eeb20c84-6ccc-4038-af5f-61d289987a60@github.com>

On Mon, 22 Aug 2022 21:20:54 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> Border line is seen outside  round Rectangle both for JInternalFrame backgroundShadowBorder & foregroundShadowBorder line in mac L&F.
> ![Screen Shot 2022-08-22 at 4 17 49 PM](https://user-images.githubusercontent.com/87324768/186021010-d21aed21-9e05-4b28-846b-2628e367f183.png)
> 
> I have circled the extra part of the line. To make it more visible I changed the color of the backgroundShadowBorder to red
> ![Screen Shot 2022-08-22 at 4 17 37 PM](https://user-images.githubusercontent.com/87324768/186021095-cbfffdba-d43a-47e7-a50b-551c59cb767b.png)
> 
> Fixed the extra length of the line 
> ![Fixed](https://user-images.githubusercontent.com/87324768/186021195-688c3613-fc50-41c3-8cad-94173385dfeb.png)

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9971


From serb at openjdk.org  Thu Sep  8 03:42:45 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Sep 2022 03:42:45 GMT
Subject: RFR: 7148092: [macosx] When Alt+down arrow key is pressed,
 the combobox popup does not appear. [v3]
In-Reply-To: <9_6m09UHBqjqrDWnuPS7Imjl3tciQr1q7RCxyOY0xXs=.47f6bcbe-38db-40c5-86b5-4329d5c365ef@github.com>
References: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
 <9_6m09UHBqjqrDWnuPS7Imjl3tciQr1q7RCxyOY0xXs=.47f6bcbe-38db-40c5-86b5-4329d5c365ef@github.com>
Message-ID: <fSudqW4F5ZpCam-pcB-w8TfMH8cfiiqrDSz2r_XbylY=.faece71f-bce6-4cf0-a594-733cfacec9b2@github.com>

On Thu, 25 Aug 2022 16:34:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When comboBox have focus, pressing Alt+Down (or Up) should render the popup which is not happening for Aqua L&F.
>> 
>> Fix is to add toggleAction for Alt+Down/Up keys as has been done for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L912)
>> 
>> closed problemlisted test is used to check the fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use camelCase

Then the test mentioned above should be updated as well to cover that extra?

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

PR: https://git.openjdk.org/jdk/pull/10014


From serb at openjdk.org  Thu Sep  8 03:45:58 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Sep 2022 03:45:58 GMT
Subject: RFR: 8234315: GTK LAF does not gray out disabled JMenu
In-Reply-To: <s7Az0JMKFqPbKlMnUgUUsQSa2ygH9SW08N0DGr7sQQM=.2561a3ba-40ce-4902-a2d2-992aa1ad565f@github.com>
References: <s7Az0JMKFqPbKlMnUgUUsQSa2ygH9SW08N0DGr7sQQM=.2561a3ba-40ce-4902-a2d2-992aa1ad565f@github.com>
Message-ID: <pJntJvb61HqD0o9acLZXL1ZcM4oTAhfbPHptz4qUcLQ=.90ba1712-442c-46c8-ae07-eaa0ddf131ea@github.com>

On Tue, 6 Sep 2022 05:37:02 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> Disabled JMenu foreground color was not grayed out in GTK LAF for version 3. The issue didn't occur in GTK-2. 
> After analysis it has been found that the JMenu widget type was changed to JMenuBar and the color value returned for the foreground color in disabled state was close to black color (RGB 0,0,0) for menubar which is not differentiable from enabled state foreground color.
> 
> As a fix for this problem, if the menubar is in disabled state then the widget is changed to JMenu and color value returned for disabled menu is gray color.
> 
> An automated test case has been added and checked in CI, link is added in JBS.

Looks fine, please double how it will work if the dark theme is set.

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

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10176


From psadhukhan at openjdk.org  Thu Sep  8 05:20:56 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Sep 2022 05:20:56 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v3]
In-Reply-To: <OKwiyluDGrJJzJjqurX6vA4apF1Dz-v39QJlk8s7vGA=.189ba8bb-9d6f-4ea7-b399-801a857981b9@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>
 <OKwiyluDGrJJzJjqurX6vA4apF1Dz-v39QJlk8s7vGA=.189ba8bb-9d6f-4ea7-b399-801a857981b9@github.com>
Message-ID: <U8w2BKrB9bFKrDtUkEM19LFr66BrhIbCjqtqUY_59n4=.46d7d53b-d1f4-40c7-a4f9-c8be44140ed6@github.com>

On Thu, 8 Sep 2022 03:37:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Honour PasswordField.echoChar property
>
> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java line 731:
> 
>> 729:                   });
>> 730: 
>> 731:         table.put("PasswordField.echoChar", '*');
> 
> It is still unclear where this "*" was stored before(will we ignore it now?), since the Nimbus used that symbol already.

"*" is the default char unless overridden by echoChar property and is set [here](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/JPasswordField.java#L178)

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

PR: https://git.openjdk.org/jdk/pull/10035


From duke at openjdk.org  Thu Sep  8 05:23:40 2022
From: duke at openjdk.org (SWinxy)
Date: Thu, 8 Sep 2022 05:23:40 GMT
Subject: RFR: 8293478: [java.desktop/macOS] Condense SDRenderType usages in
 QuartzRenderer.m [v2]
In-Reply-To: <levplAHOHGYRedb1qypkWNb4hcv6W0rO6vF2wbfbf7M=.79250f01-b07e-41e6-b1d3-166ffde6bd76@github.com>
References: <levplAHOHGYRedb1qypkWNb4hcv6W0rO6vF2wbfbf7M=.79250f01-b07e-41e6-b1d3-166ffde6bd76@github.com>
Message-ID: <5D4kwT0_P1FqA37WkR02ETZmfBBPRVSjRHrNrp_TpVM=.71142c60-22e7-487f-8b77-d30820d5b957@github.com>

> The `SDRenderType` enum is often returned using a variable declared at the start of functions. These can be inlined in the `return` itself. Using a ternary operator condenses what may be 12 lines into one, in the most extreme cases. `doRectUsingCG` and `doPolyUsingCG` were both modified more than the rest, but still are equivalent.
> 
> Example change:
> 
> SDRenderType renderType = SD_Nothing;
> 
> if (fill == YES)
> {
>     renderType = SD_Fill;
> }
> else
> {
>     renderType = SD_Stroke;
> }
> 
> // ...
> 
> return renderType;
> 
> 
> 
> // ...
> 
> return fill ? SD_Fill : SD_Stroke;

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

  We can do this here, too

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10174/files
  - new: https://git.openjdk.org/jdk/pull/10174/files/f83cbcdf..8fbaaa69

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10174&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10174&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/10174


From duke at openjdk.org  Thu Sep  8 05:44:41 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 8 Sep 2022 05:44:41 GMT
Subject: RFR: 8234315: GTK LAF does not gray out disabled JMenu
In-Reply-To: <pJntJvb61HqD0o9acLZXL1ZcM4oTAhfbPHptz4qUcLQ=.90ba1712-442c-46c8-ae07-eaa0ddf131ea@github.com>
References: <s7Az0JMKFqPbKlMnUgUUsQSa2ygH9SW08N0DGr7sQQM=.2561a3ba-40ce-4902-a2d2-992aa1ad565f@github.com>
 <pJntJvb61HqD0o9acLZXL1ZcM4oTAhfbPHptz4qUcLQ=.90ba1712-442c-46c8-ae07-eaa0ddf131ea@github.com>
Message-ID: <l4oXS4tCjRsNmI84iuREM_qV2u61F06drR3YKbSDB28=.5a55ec07-501a-4441-88a7-d4a6bc19d3ac@github.com>

On Thu, 8 Sep 2022 03:42:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Looks fine, please double how it will work if the dark theme is set.

In case of dark theme set, foreground color is grayed out. 
![Enabled_Menu_Dark_Theme](https://user-images.githubusercontent.com/107542245/189043107-3393c933-d868-4834-8f3b-e2254969cac7.png)

![Disabled_Menu_Dark_Theme](https://user-images.githubusercontent.com/107542245/189043132-45b75066-083e-4220-adbf-8947c7ee7e43.png)

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

PR: https://git.openjdk.org/jdk/pull/10176


From psadhukhan at openjdk.org  Thu Sep  8 08:01:10 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Sep 2022 08:01:10 GMT
Subject: RFR: 7148092: [macosx] When Alt+down arrow key is pressed,
 the combobox popup does not appear. [v4]
In-Reply-To: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
References: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
Message-ID: <f_qn1QW62ZBVRlx4iCUXGfDYZWeXBUxqVRr2bvS7OFA=.2f8b7c3f-7032-4ae3-bfc8-44e63145cef0@github.com>

> When comboBox have focus, pressing Alt+Down (or Up) should render the popup which is not happening for Aqua L&F.
> 
> Fix is to add toggleAction for Alt+Down/Up keys as has been done for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L912)
> 
> closed problemlisted test is used to check the fix.

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

  Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10014/files
  - new: https://git.openjdk.org/jdk/pull/10014/files/531dec1f..180f73d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10014&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10014&range=02-03

  Stats: 121 lines in 2 files changed: 102 ins; 8 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10014.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10014/head:pull/10014

PR: https://git.openjdk.org/jdk/pull/10014


From psadhukhan at openjdk.org  Thu Sep  8 09:55:28 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 8 Sep 2022 09:55:28 GMT
Subject: RFR: 6286501: JTabbedPane throws NPE from its stateChanged listener in
 particular case
Message-ID: <lqTnk1Sa-Qj3elOMsgW6WZkp_m3I3OQ_L2BdovhsieA=.8b329b54-c744-46cd-81e7-f4249a03f9f6@github.com>

JTabbedPane throws NPE from its stateChanged listener as it tries to access uninstantiated TabbedPane.
Fix is to use the tabPane passed to stateChangeListener so that correct tabPane is accessed.

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

Commit messages:
 - 6286501: JTabbedPane throws NPE from its stateChanged listener in particular case

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

PR: https://git.openjdk.org/jdk/pull/10216


From jdv at openjdk.org  Thu Sep  8 09:56:59 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 8 Sep 2022 09:56:59 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
Message-ID: <yNi7xs_ywEsyNtx9lJu98vra_-n6mFJftxaCsNE6FJM=.eee780bb-286c-4c6c-bb63-26f92b65bbc1@github.com>

On Tue, 6 Sep 2022 11:14:49 GMT, Tejesh R <tr at openjdk.org> wrote:

>> JFileChooser.getSelectedFiles() failed to retrieve files with multi-selection and double-click. This occurs when a single file is selected then enable multi-selection then select the same file through mouse double-click(Two file chooser dialogs used before and after multi-selection enabled). SelectedFiles are updated when a change in files/directory selection is done or when selection is made through keyboard selection. In this case since a single file is selected before multi-selection is enabled and same file is selected again without changing the selection index/directory, leaving selected Files un-updated. 
>> **Proposed Fix** : Whenever Multi-Selection is enabled check if any files are selected, if yes update the selected Files of JFileChoooser.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

test/jdk/javax/swing/JFileChooser/MultiSelectionEnabledSelectedFilesTest.java line 39:

> 37:  * @run main/manual MultiSelectionEnabledSelectedFilesTest
> 38:  */
> 39: public class MultiSelectionEnabledSelectedFilesTest {

Is this bug specific to any platform?
Because the test is created to run on all platforms and it doesnt fail in my Mac.

test/jdk/javax/swing/JFileChooser/MultiSelectionEnabledSelectedFilesTest.java line 56:

> 54:     static void runTest() {
> 55:         //Initialize the components
> 56:         String INSTRUCTIONS

Instruction should be updated to specify that we need to use double-click.
Also when i select a file using double click in first and then select same file using double-click(without moving mouse) test doesnt exit. JFileChooser second dialog just stays on the screen.

test/jdk/javax/swing/JFileChooser/MultiSelectionEnabledSelectedFilesTest.java line 87:

> 85:         File[] files = chooser.getSelectedFiles();
> 86: 
> 87:         if (files.length <= 0) {

Can File[] length be negative? I think just a "==" to "0" check should suffice.

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

PR: https://git.openjdk.org/jdk/pull/9996


From tr at openjdk.org  Thu Sep  8 10:11:44 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 8 Sep 2022 10:11:44 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <yNi7xs_ywEsyNtx9lJu98vra_-n6mFJftxaCsNE6FJM=.eee780bb-286c-4c6c-bb63-26f92b65bbc1@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
 <yNi7xs_ywEsyNtx9lJu98vra_-n6mFJftxaCsNE6FJM=.eee780bb-286c-4c6c-bb63-26f92b65bbc1@github.com>
Message-ID: <jXIciMjpx9KrA9kQmzJUyDeJZm4qw4j_7cTWvAxQrB0=.ca8a301e-1493-4590-84f1-437e6ee037bb@github.com>

On Thu, 8 Sep 2022 09:50:04 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> test/jdk/javax/swing/JFileChooser/MultiSelectionEnabledSelectedFilesTest.java line 39:
> 
>> 37:  * @run main/manual MultiSelectionEnabledSelectedFilesTest
>> 38:  */
>> 39: public class MultiSelectionEnabledSelectedFilesTest {
> 
> Is this bug specific to any platform?
> Because the test is created to run on all platforms and it doesnt fail in my Mac.

Yeah, it doesn't fail in mac. It does fail in windows and linux, so didn't make any os specific. Still I have tested in all platforms and it works fine. The bug was raised as linux specific.

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

PR: https://git.openjdk.org/jdk/pull/9996


From jdv at openjdk.org  Thu Sep  8 10:21:44 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 8 Sep 2022 10:21:44 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
Message-ID: <iCyVfsm9B_RKwfGFlQIgpkIqzdkixbAweBpy5h0uDoU=.ef98bc43-7b7b-4e6a-83ef-fef6ac533289@github.com>

On Tue, 6 Sep 2022 11:14:49 GMT, Tejesh R <tr at openjdk.org> wrote:

>> JFileChooser.getSelectedFiles() failed to retrieve files with multi-selection and double-click. This occurs when a single file is selected then enable multi-selection then select the same file through mouse double-click(Two file chooser dialogs used before and after multi-selection enabled). SelectedFiles are updated when a change in files/directory selection is done or when selection is made through keyboard selection. In this case since a single file is selected before multi-selection is enabled and same file is selected again without changing the selection index/directory, leaving selected Files un-updated. 
>> **Proposed Fix** : Whenever Multi-Selection is enabled check if any files are selected, if yes update the selected Files of JFileChoooser.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

src/java.desktop/share/classes/sun/swing/FilePane.java line 1766:

> 1764:                 selectedFiles[0] = getFileChooser().getSelectedFile();
> 1765:             }
> 1766: 

Is this problem seen only when single file is selected? What happens when more than one file is selected?
By default, is MultiSelection enabled on JfileChooser?

In FilePane.java, i see that get/setSelectedFiles() is exclusively used when multi-selection mode is enabled and get/setSelectedFile() is used when multi-selection is not enabled. Using getSelectedFile() to change the state when multi-selection is enabled might introduce state corruption issues in other scenarios.

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

PR: https://git.openjdk.org/jdk/pull/9996


From tr at openjdk.org  Thu Sep  8 10:29:42 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 8 Sep 2022 10:29:42 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <iCyVfsm9B_RKwfGFlQIgpkIqzdkixbAweBpy5h0uDoU=.ef98bc43-7b7b-4e6a-83ef-fef6ac533289@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
 <iCyVfsm9B_RKwfGFlQIgpkIqzdkixbAweBpy5h0uDoU=.ef98bc43-7b7b-4e6a-83ef-fef6ac533289@github.com>
Message-ID: <oGlE9_o7V8o_MlY_REGQ-OFDrGETgo9IQvqmJGvSR8A=.907cd497-1439-4ae4-b8f3-b37161dd0ef2@github.com>

On Thu, 8 Sep 2022 10:18:04 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1766:
> 
>> 1764:                 selectedFiles[0] = getFileChooser().getSelectedFile();
>> 1765:             }
>> 1766: 
> 
> Is this problem seen only when single file is selected? What happens when more than one file is selected?
> By default, is MultiSelection enabled on JfileChooser?
> 
> In FilePane.java, i see that get/setSelectedFiles() is exclusively used when multi-selection mode is enabled and get/setSelectedFile() is used when multi-selection is not enabled. Using getSelectedFile() to change the state when multi-selection is enabled might introduce state corruption issues in other scenarios.

This problem occurs when user switch the mode from single selection to multi selection, that too on specified scenario. By default multiselection will be disabled. When user selects a file in single selection and then switch to multi selection the selected single file is not retained in selectedFiles (Even though its a single file). So In order to handle this situation, whenever user switch from any state to multiselection enabled state, the previously selected files(if present) is set to selectedFiles().

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

PR: https://git.openjdk.org/jdk/pull/9996


From tr at openjdk.org  Thu Sep  8 10:29:43 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 8 Sep 2022 10:29:43 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <oGlE9_o7V8o_MlY_REGQ-OFDrGETgo9IQvqmJGvSR8A=.907cd497-1439-4ae4-b8f3-b37161dd0ef2@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
 <iCyVfsm9B_RKwfGFlQIgpkIqzdkixbAweBpy5h0uDoU=.ef98bc43-7b7b-4e6a-83ef-fef6ac533289@github.com>
 <oGlE9_o7V8o_MlY_REGQ-OFDrGETgo9IQvqmJGvSR8A=.907cd497-1439-4ae4-b8f3-b37161dd0ef2@github.com>
Message-ID: <yPr6eSz3SRbDBo1On13s9g-KoZb3lqKAfE_jBHZjooU=.181d07a8-6b57-4fbb-9385-dbe79d627b91@github.com>

On Thu, 8 Sep 2022 10:25:13 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/swing/FilePane.java line 1766:
>> 
>>> 1764:                 selectedFiles[0] = getFileChooser().getSelectedFile();
>>> 1765:             }
>>> 1766: 
>> 
>> Is this problem seen only when single file is selected? What happens when more than one file is selected?
>> By default, is MultiSelection enabled on JfileChooser?
>> 
>> In FilePane.java, i see that get/setSelectedFiles() is exclusively used when multi-selection mode is enabled and get/setSelectedFile() is used when multi-selection is not enabled. Using getSelectedFile() to change the state when multi-selection is enabled might introduce state corruption issues in other scenarios.
>
> This problem occurs when user switch the mode from single selection to multi selection, that too on specified scenario. By default multiselection will be disabled. When user selects a file in single selection and then switch to multi selection the selected single file is not retained in selectedFiles (Even though its a single file). So In order to handle this situation, whenever user switch from any state to multiselection enabled state, the previously selected files(if present) is set to selectedFiles().

Other state are not altered or modified during the process, just the selected files are set to setSelectedFiles.

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

PR: https://git.openjdk.org/jdk/pull/9996


From jdv at openjdk.org  Thu Sep  8 10:34:43 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 8 Sep 2022 10:34:43 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
Message-ID: <87to_TWEwp56w4tmpqqSwY7DBxBoemZ4t5kZ2v_ebxo=.e604fc0e-d5a2-44d4-b9da-c4765af317af@github.com>

On Tue, 6 Sep 2022 11:14:49 GMT, Tejesh R <tr at openjdk.org> wrote:

>> JFileChooser.getSelectedFiles() failed to retrieve files with multi-selection and double-click. This occurs when a single file is selected then enable multi-selection then select the same file through mouse double-click(Two file chooser dialogs used before and after multi-selection enabled). SelectedFiles are updated when a change in files/directory selection is done or when selection is made through keyboard selection. In this case since a single file is selected before multi-selection is enabled and same file is selected again without changing the selection index/directory, leaving selected Files un-updated. 
>> **Proposed Fix** : Whenever Multi-Selection is enabled check if any files are selected, if yes update the selected Files of JFileChoooser.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

src/java.desktop/share/classes/sun/swing/FilePane.java line 1772:

> 1770:         } else {
> 1771:             listSelectionModel.setSelectionMode(ListSelectionModel.SINGLE_SELECTION);
> 1772:             clearSelection();

When we move from multi-selection enabled to disable. We are clearing the selection and calling setSelectedFiles(null). Do we need to replicate similar state update when we move from multi-selection disable to enable (clearing selection and calling setSelectedFile(null))?

It looks like somewhere we are not clearing SelectedFile() and it is causing this issue.

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

PR: https://git.openjdk.org/jdk/pull/9996


From tr at openjdk.org  Thu Sep  8 10:45:49 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 8 Sep 2022 10:45:49 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <87to_TWEwp56w4tmpqqSwY7DBxBoemZ4t5kZ2v_ebxo=.e604fc0e-d5a2-44d4-b9da-c4765af317af@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
 <87to_TWEwp56w4tmpqqSwY7DBxBoemZ4t5kZ2v_ebxo=.e604fc0e-d5a2-44d4-b9da-c4765af317af@github.com>
Message-ID: <ngrXkLF2mK0_jn5YzK8mG7r0NiNoH0vbEZcbRpVVo3o=.a6cd6622-8547-4645-a69e-004216479fdc@github.com>

On Thu, 8 Sep 2022 10:32:32 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1772:
> 
>> 1770:         } else {
>> 1771:             listSelectionModel.setSelectionMode(ListSelectionModel.SINGLE_SELECTION);
>> 1772:             clearSelection();
> 
> When we move from multi-selection enabled to disable. We are clearing the selection and calling setSelectedFiles(null). Do we need to replicate similar state update when we move from multi-selection disable to enable (clearing selection and calling setSelectedFile(null))?
> 
> It looks like somewhere we are not clearing SelectedFile() and it is causing this issue.

If we replicate the same then previously selected files will be cleared and user wont be able to retain the selected files.

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

PR: https://git.openjdk.org/jdk/pull/9996


From tr at openjdk.org  Thu Sep  8 10:45:50 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 8 Sep 2022 10:45:50 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <ngrXkLF2mK0_jn5YzK8mG7r0NiNoH0vbEZcbRpVVo3o=.a6cd6622-8547-4645-a69e-004216479fdc@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
 <87to_TWEwp56w4tmpqqSwY7DBxBoemZ4t5kZ2v_ebxo=.e604fc0e-d5a2-44d4-b9da-c4765af317af@github.com>
 <ngrXkLF2mK0_jn5YzK8mG7r0NiNoH0vbEZcbRpVVo3o=.a6cd6622-8547-4645-a69e-004216479fdc@github.com>
Message-ID: <Zcq_MKhZsW4_c5Yzr0Al27i8z5kaSjQOgA8gHASccXk=.f8a91643-a202-48ff-a562-478d465dee5e@github.com>

On Thu, 8 Sep 2022 10:38:22 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/swing/FilePane.java line 1772:
>> 
>>> 1770:         } else {
>>> 1771:             listSelectionModel.setSelectionMode(ListSelectionModel.SINGLE_SELECTION);
>>> 1772:             clearSelection();
>> 
>> When we move from multi-selection enabled to disable. We are clearing the selection and calling setSelectedFiles(null). Do we need to replicate similar state update when we move from multi-selection disable to enable (clearing selection and calling setSelectedFile(null))?
>> 
>> It looks like somewhere we are not clearing SelectedFile() and it is causing this issue.
>
> If we replicate the same then previously selected files will be cleared and user wont be able to retain the selected files.

Clearing the selection from multi to single is fine, but the reverse might not be right I guess..... Since selected file/files can be retained when user switch to multi selection.

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

PR: https://git.openjdk.org/jdk/pull/9996


From jdv at openjdk.org  Thu Sep  8 10:45:51 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 8 Sep 2022 10:45:51 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <jXIciMjpx9KrA9kQmzJUyDeJZm4qw4j_7cTWvAxQrB0=.ca8a301e-1493-4590-84f1-437e6ee037bb@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
 <yNi7xs_ywEsyNtx9lJu98vra_-n6mFJftxaCsNE6FJM=.eee780bb-286c-4c6c-bb63-26f92b65bbc1@github.com>
 <jXIciMjpx9KrA9kQmzJUyDeJZm4qw4j_7cTWvAxQrB0=.ca8a301e-1493-4590-84f1-437e6ee037bb@github.com>
Message-ID: <5ly-7MCOy5_-N5_cKwjASkTLo9uoUDTodkqByDQahZg=.d8e04260-67db-4031-a9d9-599381a6a468@github.com>

On Thu, 8 Sep 2022 10:09:24 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/MultiSelectionEnabledSelectedFilesTest.java line 39:
>> 
>>> 37:  * @run main/manual MultiSelectionEnabledSelectedFilesTest
>>> 38:  */
>>> 39: public class MultiSelectionEnabledSelectedFilesTest {
>> 
>> Is this bug specific to any platform?
>> Because the test is created to run on all platforms and it doesnt fail in my Mac.
>
> Yeah, it doesn't fail in mac. It does fail in windows and linux, so didn't make any os specific. Still I have tested in all platforms and it works fine. The bug was raised as linux specific.

Why the test doesnt fail in Mac(In my case second dialog doesnt exit and it stays on the screen, which will result in timeout and jtreg error on Mac)? 

It looks like fix is not some platform specific change.

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

PR: https://git.openjdk.org/jdk/pull/9996


From jdv at openjdk.org  Thu Sep  8 10:53:41 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 8 Sep 2022 10:53:41 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <Zcq_MKhZsW4_c5Yzr0Al27i8z5kaSjQOgA8gHASccXk=.f8a91643-a202-48ff-a562-478d465dee5e@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
 <87to_TWEwp56w4tmpqqSwY7DBxBoemZ4t5kZ2v_ebxo=.e604fc0e-d5a2-44d4-b9da-c4765af317af@github.com>
 <ngrXkLF2mK0_jn5YzK8mG7r0NiNoH0vbEZcbRpVVo3o=.a6cd6622-8547-4645-a69e-004216479fdc@github.com>
 <Zcq_MKhZsW4_c5Yzr0Al27i8z5kaSjQOgA8gHASccXk=.f8a91643-a202-48ff-a562-478d465dee5e@github.com>
Message-ID: <t-y8-p6M1UScws4ofTEXBMRhUxPFkduWC5mrYntEXgM=.6e10bdb7-a3ad-4a18-bc81-f79284653096@github.com>

On Thu, 8 Sep 2022 10:41:11 GMT, Tejesh R <tr at openjdk.org> wrote:

>> If we replicate the same then previously selected files will be cleared and user wont be able to retain the selected files.
>
> Clearing the selection from multi to single is fine, but the reverse might not be right I guess..... Since selected file/files can be retained when user switch to multi selection.

In this scenario we are actually closing the first JFileChooser dialog and then opening another JFileChooser dialog with multi-selection. Do we need to maintain selected file state between these dialogs? If yes, why? Please clarify.

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

PR: https://git.openjdk.org/jdk/pull/9996


From tr at openjdk.org  Thu Sep  8 10:58:58 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 8 Sep 2022 10:58:58 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <5ly-7MCOy5_-N5_cKwjASkTLo9uoUDTodkqByDQahZg=.d8e04260-67db-4031-a9d9-599381a6a468@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
 <yNi7xs_ywEsyNtx9lJu98vra_-n6mFJftxaCsNE6FJM=.eee780bb-286c-4c6c-bb63-26f92b65bbc1@github.com>
 <jXIciMjpx9KrA9kQmzJUyDeJZm4qw4j_7cTWvAxQrB0=.ca8a301e-1493-4590-84f1-437e6ee037bb@github.com>
 <5ly-7MCOy5_-N5_cKwjASkTLo9uoUDTodkqByDQahZg=.d8e04260-67db-4031-a9d9-599381a6a468@github.com>
Message-ID: <p_MIFHO00D1iPDyhWN5j_pdazK6TMK-OX90nbbrqaf8=.e5c88351-b871-4432-88b2-68fef2d6211d@github.com>

On Thu, 8 Sep 2022 10:43:45 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Yeah, it doesn't fail in mac. It does fail in windows and linux, so didn't make any os specific. Still I have tested in all platforms and it works fine. The bug was raised as linux specific.
>
> Why the test doesnt fail in Mac(In my case second dialog doesnt exit and it stays on the screen, which will result in timeout and jtreg error on Mac)? 
> 
> It looks like fix is not some platform specific change.

The fix handles Windows and linux platforms, since FilePane.class is involved on mode selection. In Mac its doesn't come thought this path, I guess it handles some other way. The issue doesn't occur on key press also (All platforms), since the path of setting selected files are different for each scenario.

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

PR: https://git.openjdk.org/jdk/pull/9996


From tr at openjdk.org  Thu Sep  8 10:58:58 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 8 Sep 2022 10:58:58 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <p_MIFHO00D1iPDyhWN5j_pdazK6TMK-OX90nbbrqaf8=.e5c88351-b871-4432-88b2-68fef2d6211d@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
 <yNi7xs_ywEsyNtx9lJu98vra_-n6mFJftxaCsNE6FJM=.eee780bb-286c-4c6c-bb63-26f92b65bbc1@github.com>
 <jXIciMjpx9KrA9kQmzJUyDeJZm4qw4j_7cTWvAxQrB0=.ca8a301e-1493-4590-84f1-437e6ee037bb@github.com>
 <5ly-7MCOy5_-N5_cKwjASkTLo9uoUDTodkqByDQahZg=.d8e04260-67db-4031-a9d9-599381a6a468@github.com>
 <p_MIFHO00D1iPDyhWN5j_pdazK6TMK-OX90nbbrqaf8=.e5c88351-b871-4432-88b2-68fef2d6211d@github.com>
Message-ID: <q9nFSuy2lp2v1Ss0kJthXD1X2HzAyXbPH7wLCI1vt6o=.05cd7ebd-3b25-4ad5-a6fc-9db587869137@github.com>

On Thu, 8 Sep 2022 10:53:53 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Why the test doesnt fail in Mac(In my case second dialog doesnt exit and it stays on the screen, which will result in timeout and jtreg error on Mac)? 
>> 
>> It looks like fix is not some platform specific change.
>
> The fix handles Windows and linux platforms, since FilePane.class is involved on mode selection. In Mac its doesn't come thought this path, I guess it handles some other way. The issue doesn't occur on key press also (All platforms), since the path of setting selected files are different for each scenario.

I guess the dialogue is not not been removed when exception is thrown. Will take a look into it.

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

PR: https://git.openjdk.org/jdk/pull/9996


From tr at openjdk.org  Thu Sep  8 11:09:52 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 8 Sep 2022 11:09:52 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <t-y8-p6M1UScws4ofTEXBMRhUxPFkduWC5mrYntEXgM=.6e10bdb7-a3ad-4a18-bc81-f79284653096@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
 <87to_TWEwp56w4tmpqqSwY7DBxBoemZ4t5kZ2v_ebxo=.e604fc0e-d5a2-44d4-b9da-c4765af317af@github.com>
 <ngrXkLF2mK0_jn5YzK8mG7r0NiNoH0vbEZcbRpVVo3o=.a6cd6622-8547-4645-a69e-004216479fdc@github.com>
 <Zcq_MKhZsW4_c5Yzr0Al27i8z5kaSjQOgA8gHASccXk=.f8a91643-a202-48ff-a562-478d465dee5e@github.com>
 <t-y8-p6M1UScws4ofTEXBMRhUxPFkduWC5mrYntEXgM=.6e10bdb7-a3ad-4a18-bc81-f79284653096@github.com>
Message-ID: <qnQYFBymio4mDhcD07487j7gQd0weZpo1QUNFjgXIjM=.2fd23885-f238-46d5-8abd-87bdb30e6b4b@github.com>

On Thu, 8 Sep 2022 10:51:34 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Clearing the selection from multi to single is fine, but the reverse might not be right I guess..... Since selected file/files can be retained when user switch to multi selection.
>
> In this scenario we are actually closing the first JFileChooser dialog and then opening another JFileChooser dialog with multi-selection. Do we need to maintain selected file state between these dialogs? If yes, why? Please clarify.

In mac, the selection is maintained during this state transition, only in this scenario its not handled. And since same filechooser is used in selecting the files ( Just pop-up dialogue is used to select the files) I think it would be better to retain the selection.

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

PR: https://git.openjdk.org/jdk/pull/9996


From tr at openjdk.org  Thu Sep  8 11:09:52 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 8 Sep 2022 11:09:52 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <qnQYFBymio4mDhcD07487j7gQd0weZpo1QUNFjgXIjM=.2fd23885-f238-46d5-8abd-87bdb30e6b4b@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
 <87to_TWEwp56w4tmpqqSwY7DBxBoemZ4t5kZ2v_ebxo=.e604fc0e-d5a2-44d4-b9da-c4765af317af@github.com>
 <ngrXkLF2mK0_jn5YzK8mG7r0NiNoH0vbEZcbRpVVo3o=.a6cd6622-8547-4645-a69e-004216479fdc@github.com>
 <Zcq_MKhZsW4_c5Yzr0Al27i8z5kaSjQOgA8gHASccXk=.f8a91643-a202-48ff-a562-478d465dee5e@github.com>
 <t-y8-p6M1UScws4ofTEXBMRhUxPFkduWC5mrYntEXgM=.6e10bdb7-a3ad-4a18-bc81-f79284653096@github.com>
 <qnQYFBymio4mDhcD07487j7gQd0weZpo1QUNFjgXIjM=.2fd23885-f238-46d5-8abd-87bdb30e6b4b@github.com>
Message-ID: <ZxfYxjWQkBFUCWe72YMgak1r4eDYA3zjLFA-3PfDwz4=.597ec994-c432-44d9-9c7d-6c046af8d4eb@github.com>

On Thu, 8 Sep 2022 11:00:14 GMT, Tejesh R <tr at openjdk.org> wrote:

>> In this scenario we are actually closing the first JFileChooser dialog and then opening another JFileChooser dialog with multi-selection. Do we need to maintain selected file state between these dialogs? If yes, why? Please clarify.
>
> In mac, the selection is maintained during this state transition, only in this scenario its not handled. And since same filechooser is used in selecting the files ( Just pop-up dialogue is used to select the files) I think it would be better to retain the selection.

In keyboard selection the state is actually not maintained. Then do you think it better to clear the selection and set selected files to null....?

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

PR: https://git.openjdk.org/jdk/pull/9996


From tr at openjdk.org  Thu Sep  8 11:09:53 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 8 Sep 2022 11:09:53 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <ZxfYxjWQkBFUCWe72YMgak1r4eDYA3zjLFA-3PfDwz4=.597ec994-c432-44d9-9c7d-6c046af8d4eb@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
 <87to_TWEwp56w4tmpqqSwY7DBxBoemZ4t5kZ2v_ebxo=.e604fc0e-d5a2-44d4-b9da-c4765af317af@github.com>
 <ngrXkLF2mK0_jn5YzK8mG7r0NiNoH0vbEZcbRpVVo3o=.a6cd6622-8547-4645-a69e-004216479fdc@github.com>
 <Zcq_MKhZsW4_c5Yzr0Al27i8z5kaSjQOgA8gHASccXk=.f8a91643-a202-48ff-a562-478d465dee5e@github.com>
 <t-y8-p6M1UScws4ofTEXBMRhUxPFkduWC5mrYntEXgM=.6e10bdb7-a3ad-4a18-bc81-f79284653096@github.com>
 <qnQYFBymio4mDhcD07487j7gQd0weZpo1QUNFjgXIjM=.2fd23885-f238-46d5-8abd-87bdb30e6b4b@github.com>
 <ZxfYxjWQkBFUCWe72YMgak1r4eDYA3zjLFA-3PfDwz4=.597ec994-c432-44d9-9c7d-6c046af8d4eb@github.com>
Message-ID: <_usGkRuX1Jrds8aCy2udq6VAL7QY_6VxIO80-8C7TkM=.e6557ae5-92ac-455a-9704-5e0cef679dde@github.com>

On Thu, 8 Sep 2022 11:02:24 GMT, Tejesh R <tr at openjdk.org> wrote:

>> In mac, the selection is maintained during this state transition, only in this scenario its not handled. And since same filechooser is used in selecting the files ( Just pop-up dialogue is used to select the files) I think it would be better to retain the selection.
>
> In keyboard selection the state is actually not maintained. Then do you think it better to clear the selection and set selected files to null....?

Clearing the selection and setting it to null also solves the problem though. When we call clear selection, reset will happen and selectedFiles will be set.

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

PR: https://git.openjdk.org/jdk/pull/9996


From jdv at openjdk.org  Thu Sep  8 11:09:55 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 8 Sep 2022 11:09:55 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <q9nFSuy2lp2v1Ss0kJthXD1X2HzAyXbPH7wLCI1vt6o=.05cd7ebd-3b25-4ad5-a6fc-9db587869137@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
 <yNi7xs_ywEsyNtx9lJu98vra_-n6mFJftxaCsNE6FJM=.eee780bb-286c-4c6c-bb63-26f92b65bbc1@github.com>
 <jXIciMjpx9KrA9kQmzJUyDeJZm4qw4j_7cTWvAxQrB0=.ca8a301e-1493-4590-84f1-437e6ee037bb@github.com>
 <5ly-7MCOy5_-N5_cKwjASkTLo9uoUDTodkqByDQahZg=.d8e04260-67db-4031-a9d9-599381a6a468@github.com>
 <p_MIFHO00D1iPDyhWN5j_pdazK6TMK-OX90nbbrqaf8=.e5c88351-b871-4432-88b2-68fef2d6211d@github.com>
 <q9nFSuy2lp2v1Ss0kJthXD1X2HzAyXbPH7wLCI1vt6o=.05cd7ebd-3b25-4ad5-a6fc-9db587869137@github.com>
Message-ID: <rgAZJB6n3rgKumeVtObxDcBIlNi87539UZNyj6-cFIM=.773867e6-8ef6-45c2-bbbb-ebd7b79e214a@github.com>

On Thu, 8 Sep 2022 10:54:48 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The fix handles Windows and linux platforms, since FilePane.class is involved on mode selection. In Mac its doesn't come thought this path, I guess it handles some other way. The issue doesn't occur on key press also (All platforms), since the path of setting selected files are different for each scenario.
>
> I guess the dialogue is not not been removed when exception is thrown. Will take a look into it.

If the product fix that is being done will touch only Linux and Windows(And in Mac it looks like it not exiting properly), we can make this regression test to run only on Linux and Windows using jtreg tag:
@requires (os.family == "windows" | os.family == "linux")

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

PR: https://git.openjdk.org/jdk/pull/9996


From jdv at openjdk.org  Thu Sep  8 11:51:46 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 8 Sep 2022 11:51:46 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <_usGkRuX1Jrds8aCy2udq6VAL7QY_6VxIO80-8C7TkM=.e6557ae5-92ac-455a-9704-5e0cef679dde@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
 <87to_TWEwp56w4tmpqqSwY7DBxBoemZ4t5kZ2v_ebxo=.e604fc0e-d5a2-44d4-b9da-c4765af317af@github.com>
 <ngrXkLF2mK0_jn5YzK8mG7r0NiNoH0vbEZcbRpVVo3o=.a6cd6622-8547-4645-a69e-004216479fdc@github.com>
 <Zcq_MKhZsW4_c5Yzr0Al27i8z5kaSjQOgA8gHASccXk=.f8a91643-a202-48ff-a562-478d465dee5e@github.com>
 <t-y8-p6M1UScws4ofTEXBMRhUxPFkduWC5mrYntEXgM=.6e10bdb7-a3ad-4a18-bc81-f79284653096@github.com>
 <qnQYFBymio4mDhcD07487j7gQd0weZpo1QUNFjgXIjM=.2fd23885-f238-46d5-8abd-87bdb30e6b4b@github.com>
 <ZxfYxjWQkBFUCWe72YMgak1r4eDYA3zjLFA-3PfDwz4=.597ec994-c432-44d9-9c7d-6c046af8d4eb@github.com>
 <_usGkRuX1Jrds8aCy2udq6VAL7QY_6VxIO80-8C7TkM=.e6557ae5-92ac-455a-9704-5e0cef679dde@github.com>
Message-ID: <DpRKOf5tq9EB8T3XEbDe417oPMUMWOdxs3alO0K_hKo=.aef56d70-83d4-43bf-93e0-83ae84b52a3c@github.com>

On Thu, 8 Sep 2022 11:05:35 GMT, Tejesh R <tr at openjdk.org> wrote:

>> In keyboard selection the state is actually not maintained. Then do you think it better to clear the selection and set selected files to null....?
>
> Clearing the selection and setting it to null also solves the problem though. When we call clear selection, reset will happen and selectedFiles will be set.

As discussed on call its better to clear selection when we move between multi-selection enabled/disabled as captured in https://github.com/openjdk/jdk/pull/9996#discussion_r965791205

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

PR: https://git.openjdk.org/jdk/pull/9996


From duke at openjdk.org  Thu Sep  8 12:45:34 2022
From: duke at openjdk.org (duke)
Date: Thu, 8 Sep 2022 12:45:34 GMT
Subject: Withdrawn: 8282578: AIOOBE in javax.sound.sampled.Clip
In-Reply-To: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
References: <JT02WoIlKEcksG5oghEuieR00WOudCnvNQ9DRvf5nAE=.146555d8-2483-464a-900a-804ce6dff183@github.com>
Message-ID: <jFAxC3thFJ4P4uuWjC0vpPrPTlKnNtb09VKM8bjKfco=.f97dd8ec-a89d-45f8-a031-1033472f1836@github.com>

On Fri, 3 Jun 2022 15:43:39 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add try/catch clause to ignore an exception since it is harmless for we isolated
> the massge data before passing it ro processor.
> Add test case.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/9016


From aivanov at openjdk.org  Thu Sep  8 14:24:44 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 8 Sep 2022 14:24:44 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v13]
In-Reply-To: <vc031T8ZH6oYeJacuKa7BfWxF16TITrxAvwD1dwFgjM=.61ece218-0ed8-42e2-a11e-fce75b5519aa@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <vc031T8ZH6oYeJacuKa7BfWxF16TITrxAvwD1dwFgjM=.61ece218-0ed8-42e2-a11e-fce75b5519aa@github.com>
Message-ID: <-sdqQrwQUzVXb1238wegpay5WBEWwp5RqMRzw27j4Lo=.054c3db2-21cf-4688-8040-f821d49c1108@github.com>

On Wed, 7 Sep 2022 21:55:53 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>    Whitespace errors
>   
>   Removes whitespaces.

Swing supports [CSS1](https://www.w3.org/TR/REC-CSS1/) only, it defines color names for [16 colors](https://www.w3.org/TR/REC-CSS1/#color-units):

> The suggested list of keyword color names is: aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white, and yellow. These 16 colors are taken from the Windows VGA palette, and their RGB values are not defined in this specification.

Would the addition of color names from CSS4 give a wrong impression that Swing implements CSS4?

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

PR: https://git.openjdk.org/jdk/pull/9825


From shurailine at openjdk.org  Thu Sep  8 16:01:40 2022
From: shurailine at openjdk.org (Alexandre Iline)
Date: Thu, 8 Sep 2022 16:01:40 GMT
Subject: RFR: 8292309 : Fix
 java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java test
 [v2]
In-Reply-To: <VMTD0XIVmHyVmza1t3HgFiZccJ7EMmzXgooQlQPgmyk=.74207d3f-3ed3-4c3c-9fa1-a90df2e411b2@github.com>
References: <uFqQUzkuWOrGXowhXEwVwRN5HjCisrPLGNK-rpaUyUc=.6c97b5ba-e463-45d1-8cb4-e4799148e212@github.com>
 <VMTD0XIVmHyVmza1t3HgFiZccJ7EMmzXgooQlQPgmyk=.74207d3f-3ed3-4c3c-9fa1-a90df2e411b2@github.com>
Message-ID: <o_rmnaOTEoRihK65LXvnJQZYje4V7Rp_YVXNI5J0rBg=.f3590773-fab5-4382-829b-5a6e8edf97a0@github.com>

On Wed, 7 Sep 2022 22:42:35 GMT, lawrence.andrews <duke at openjdk.org> wrote:

>> 1) Fixed Parse Exception by removing yesno
>> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno
>> 2) Throw jtreg.SkippedException when printer is not configured on the test host
>> 3) Replaced Sysout & TestDialog with ManualTestFrame, which allows to the user to better decide test results and to take screen shot if test fails.
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Show Frame with in EDT

LGTM

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

PR: https://git.openjdk.org/jdk/pull/9865


From shurailine at openjdk.org  Thu Sep  8 16:09:46 2022
From: shurailine at openjdk.org (Alexandre Iline)
Date: Thu, 8 Sep 2022 16:09:46 GMT
Subject: RFR: 8292271 : Fix
 java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java test [v4]
In-Reply-To: <TgxAXnZLR8Zgf4YBL-M-XOsX2lnDcDzugvygTdfhHbo=.eda78da6-64ec-449c-9555-f25bcb59f741@github.com>
References: <gpnPCT4GfLO7w3w3uuUVk3BBehfPYJeFseqU2dZ_yZk=.69f0df8a-10a7-47da-9de0-3c7b269ab9f9@github.com>
 <TgxAXnZLR8Zgf4YBL-M-XOsX2lnDcDzugvygTdfhHbo=.eda78da6-64ec-449c-9555-f25bcb59f741@github.com>
Message-ID: <2HuRkpIul8oVnWgea2W6r6BMN2mRqYMJASZs7bXxP2k=.a4d594e6-ca65-45a7-b9f2-d9887e31ab89@github.com>

On Wed, 7 Sep 2022 22:33:17 GMT, lawrence.andrews <duke at openjdk.org> wrote:

>> 1) This test was failing due to yesno 
>> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno 
>> 2) PrintCheckboxManualTest.html file was missing
>> 3) Added os.family since test instruction says that its a linux and solair toolkit only test
>> 4) Removed Sysout & TestDialog class &  added a better manual framework to show the instruction and test frame. 
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed space issue

test/jdk/java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java line 69:

> 67: 
> 68:         String instruction = """
> 69:                Linux or Solaris with XToolkit ONLY!

since there already is
@requires (os.family == "linux" | os.family == "solaris")
is this line needed? 
Can there be anything else besides XToolkit on linux or solaris? If yes, is there a way to determine that programmatically? If no, how does user finds that out?
Lastly, what is the test executor supposed to do if it is not XToolkit on linux or solaris?

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

PR: https://git.openjdk.org/jdk/pull/9858


From aivanov at openjdk.org  Thu Sep  8 17:35:04 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 8 Sep 2022 17:35:04 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v26]
In-Reply-To: <QYaW5bTaDAzVkGYK11xiLSPLTSdIU6DiBrBR-dKCQOI=.2f3ab314-85a9-44d6-9526-1ad9d9f7056b@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <QYaW5bTaDAzVkGYK11xiLSPLTSdIU6DiBrBR-dKCQOI=.2f3ab314-85a9-44d6-9526-1ad9d9f7056b@github.com>
Message-ID: <i-40SOCdt6Zlk-UukGR9ZoII2KvYK5nuGox6hU7xycw=.61a284b4-7731-4f8b-b7d7-3aa10d8be802@github.com>

On Fri, 2 Sep 2022 11:12:53 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Filesize calculation logic modified

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/sun/swing/FilePane.java line 1277:

> 1275:             DecimalFormat df = new DecimalFormat("0.0");
> 1276:             double val = fileSize/baseFileSize;
> 1277:             return  Double.valueOf(df.format(val));

The new code to round up looks difficult to understand. I liked the previous version better. The only thing required to introduce rounding up is updating `roundToOneDecimalPlace`:


        private static double roundToOneDecimalPlace(long fileSize) {
            return  Math.ceilDiv(fileSize, 100L) / 10.0d;
        }


[`Math.ceilDiv`](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/Math.html#ceilDiv(long,long)) is available since Java 18.

However, this code also works and is better suited for backporting:


        private static double roundToOneDecimalPlace(long fileSize) {
            return  Math.ceil(fileSize / 100.0d) / 10.0d;
        }

Note that the first division is also floating point.

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

PR: https://git.openjdk.org/jdk/pull/9327


From honkar at openjdk.org  Thu Sep  8 20:58:41 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 8 Sep 2022 20:58:41 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v7]
In-Reply-To: <qay_twnp4S2mtoyFXNfTAxWJuMmiK4eZrK1MKdvBUgA=.b614b959-f157-4b90-bbce-e1626474e15c@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <qay_twnp4S2mtoyFXNfTAxWJuMmiK4eZrK1MKdvBUgA=.b614b959-f157-4b90-bbce-e1626474e15c@github.com>
Message-ID: <y-b4LPZM5dB95SeqhCRC2KnoDKU6-Yl6kEQbCm2-Px8=.c64ec018-dd24-4583-96e1-cd34706dcb28@github.com>

On Wed, 17 Aug 2022 22:37:46 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
>> 
>> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
>> 
>> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright date. Added MacOS text to test.

Tested on non-retina display, combobox height of 22 works well. 
Increasing or decreasing the height by 1 produces slight offset. I think height=22 works well here.

**With Height = 23**
![image](https://user-images.githubusercontent.com/95945681/189221941-c0293708-0369-41dc-b765-32d7c2985345.png)

**With Height = 21**
![image](https://user-images.githubusercontent.com/95945681/189222977-763b3e49-a4d6-47e9-9445-c3caf5baeb66.png)

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

PR: https://git.openjdk.org/jdk/pull/9473


From duke at openjdk.org  Thu Sep  8 21:02:39 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Thu, 8 Sep 2022 21:02:39 GMT
Subject: RFR: 8292271 : Fix
 java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java test [v5]
In-Reply-To: <gpnPCT4GfLO7w3w3uuUVk3BBehfPYJeFseqU2dZ_yZk=.69f0df8a-10a7-47da-9de0-3c7b269ab9f9@github.com>
References: <gpnPCT4GfLO7w3w3uuUVk3BBehfPYJeFseqU2dZ_yZk=.69f0df8a-10a7-47da-9de0-3c7b269ab9f9@github.com>
Message-ID: <uNJdZmARcOgg99phu_jSIKRKNTio6TVFX5TFIhI61Ho=.f471c670-5106-47e9-8c16-752a00c616a0@github.com>

> 1) This test was failing due to yesno 
> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno 
> 2) PrintCheckboxManualTest.html file was missing
> 3) Added os.family since test instruction says that its a linux and solair toolkit only test
> 4) Removed Sysout & TestDialog class &  added a better manual framework to show the instruction and test frame. 
> 
> @shurymury

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

  Check for XToolkit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9858/files
  - new: https://git.openjdk.org/jdk/pull/9858/files/7e848533..0ef8c12c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9858&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9858&range=03-04

  Stats: 18 lines in 1 file changed: 10 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/9858.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9858/head:pull/9858

PR: https://git.openjdk.org/jdk/pull/9858


From honkar at openjdk.org  Thu Sep  8 21:11:32 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 8 Sep 2022 21:11:32 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v7]
In-Reply-To: <qay_twnp4S2mtoyFXNfTAxWJuMmiK4eZrK1MKdvBUgA=.b614b959-f157-4b90-bbce-e1626474e15c@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <qay_twnp4S2mtoyFXNfTAxWJuMmiK4eZrK1MKdvBUgA=.b614b959-f157-4b90-bbce-e1626474e15c@github.com>
Message-ID: <LGs0QzfpkWfvFXkIZGmCQtckVvgrUgg1738a-vVYjjY=.a01c2304-ad89-4758-90b1-4a101ce1c9ff@github.com>

On Wed, 17 Aug 2022 22:37:46 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
>> 
>> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
>> 
>> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright date. Added MacOS text to test.

test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java line 74:

> 72:             frame = new JFrame();
> 73:             frame.getContentPane().add(panel);
> 74:             frame.setVisible(true);

@DamonGuy To avoid flickering of the test frame move `frame.setVisible(true)` after `PassFailJFrame.positionTestWindow()`

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

PR: https://git.openjdk.org/jdk/pull/9473


From serb at openjdk.org  Thu Sep  8 23:44:41 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Sep 2022 23:44:41 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v3]
In-Reply-To: <U8w2BKrB9bFKrDtUkEM19LFr66BrhIbCjqtqUY_59n4=.46d7d53b-d1f4-40c7-a4f9-c8be44140ed6@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>
 <OKwiyluDGrJJzJjqurX6vA4apF1Dz-v39QJlk8s7vGA=.189ba8bb-9d6f-4ea7-b399-801a857981b9@github.com>
 <U8w2BKrB9bFKrDtUkEM19LFr66BrhIbCjqtqUY_59n4=.46d7d53b-d1f4-40c7-a4f9-c8be44140ed6@github.com>
Message-ID: <8_EXfD0W-aphoJsroB4e0r8hsMrcxpfATTWDGHXP_Es=.c22772e4-447a-48b2-b5de-1918059670f2@github.com>

On Thu, 8 Sep 2022 05:17:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java line 731:
>> 
>>> 729:                   });
>>> 730: 
>>> 731:         table.put("PasswordField.echoChar", '*');
>> 
>> It is still unclear where this "*" was stored before(will we ignore it now?), since the Nimbus used that symbol already.
>
> "*" is the default char unless overridden by echoChar property and is set [here](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/JPasswordField.java#L178)

I just found my comment at that bug that the ui properties for nimbus are stored in the "skin.laf" and the "echoChar" is missed there. This is the reason why the UIDefaults table is small in Nimbus, unlike Metal where we have a long list of properties. Take a look to the `NimbusDefaults.java` which is generated during the build it contains all the props, and it is a place where I think we should update the echoChar.

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

PR: https://git.openjdk.org/jdk/pull/10035


From serb at openjdk.org  Thu Sep  8 23:46:38 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Sep 2022 23:46:38 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is
 not shown on disabled checkbox and radio button with Nimbus LAF
In-Reply-To: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
References: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
Message-ID: <h5Ou2ShiqfXka9nBYM3z77ia9W_PU0_0ormHADfLG7M=.10dec212-ffac-4cc8-81bc-3427d4697b22@github.com>

On Tue, 6 Sep 2022 05:57:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CheckBox.disabledText and RadioButton.disabledText color UIProperty is not honoured by Nimbus L&F when disabled text is drawn for JCheckBox and JRadioButton, so disabled text color was rendered incorrectly.
> Fix is to honour these UIProperty color if they are set by user, else use the color from the component or via getColorForState().
> 
> Closed test as mentioned in JBS is used to check the fix.

>?? Failed to retrieve information on issue 8075916.
JBS issue is closed.

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

PR: https://git.openjdk.org/jdk/pull/10177


From serb at openjdk.org  Thu Sep  8 23:53:29 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 8 Sep 2022 23:53:29 GMT
Subject: RFR: 8292309 : Fix
 java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java test
 [v2]
In-Reply-To: <VMTD0XIVmHyVmza1t3HgFiZccJ7EMmzXgooQlQPgmyk=.74207d3f-3ed3-4c3c-9fa1-a90df2e411b2@github.com>
References: <uFqQUzkuWOrGXowhXEwVwRN5HjCisrPLGNK-rpaUyUc=.6c97b5ba-e463-45d1-8cb4-e4799148e212@github.com>
 <VMTD0XIVmHyVmza1t3HgFiZccJ7EMmzXgooQlQPgmyk=.74207d3f-3ed3-4c3c-9fa1-a90df2e411b2@github.com>
Message-ID: <TxElUteCPhgbWgWjKQYgouj7stNVAA7BcTsFIUEma3s=.c47a6f6c-d600-41de-af50-ca5158273388@github.com>

On Wed, 7 Sep 2022 22:42:35 GMT, lawrence.andrews <duke at openjdk.org> wrote:

>> 1) Fixed Parse Exception by removing yesno
>> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno
>> 2) Throw jtreg.SkippedException when printer is not configured on the test host
>> 3) Replaced Sysout & TestDialog with ManualTestFrame, which allows to the user to better decide test results and to take screen shot if test fails.
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Show Frame with in EDT

I still not sure about the case when we start to throw the "SkippedException" if the printer is not found and the "printer" keyword is set, especially for the manual test case. Is it expected that the user will run the "printer" related test and it will pass automcatically, how we will force to actually run the test in proper envirement?

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

PR: https://git.openjdk.org/jdk/pull/9865


From duke at openjdk.org  Fri Sep  9 03:01:48 2022
From: duke at openjdk.org (ScientificWare)
Date: Fri, 9 Sep 2022 03:01:48 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v13]
In-Reply-To: <-sdqQrwQUzVXb1238wegpay5WBEWwp5RqMRzw27j4Lo=.054c3db2-21cf-4688-8040-f821d49c1108@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <vc031T8ZH6oYeJacuKa7BfWxF16TITrxAvwD1dwFgjM=.61ece218-0ed8-42e2-a11e-fce75b5519aa@github.com>
 <-sdqQrwQUzVXb1238wegpay5WBEWwp5RqMRzw27j4Lo=.054c3db2-21cf-4688-8040-f821d49c1108@github.com>
Message-ID: <SdCymoy6N9aAKTRE8Dmsg3h3WzyptQAHJZCCv9tmC-M=.fc997936-79ca-45ab-935e-75621b99d4ad@github.com>

On Thu, 8 Sep 2022 14:22:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>    Whitespace errors
>>   
>>   Removes whitespaces.
>
> Swing supports [CSS1](https://www.w3.org/TR/REC-CSS1/) only, it defines color names for [16 colors](https://www.w3.org/TR/REC-CSS1/#color-units):
> 
>> The suggested list of keyword color names is: aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white, and yellow. These 16 colors are taken from the Windows VGA palette, and their RGB values are not defined in this specification.
> 
> Would the addition of color names from CSS4 give a wrong impression that Swing implements CSS4?

@aivanov-jdk It's a good question :
- knowing that CSS Level 4 doesn't recommend usage of these names.
- before my next PR about  3, 4, 6 or 8 digits hex coded colors (following CSS Level 4 Colors recommendations).
- and this one in project (https://bugs.openjdk.org/browse/JDK-8289722).

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

PR: https://git.openjdk.org/jdk/pull/9825


From psadhukhan at openjdk.org  Fri Sep  9 04:18:42 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 9 Sep 2022 04:18:42 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is
 not shown on disabled checkbox and radio button with Nimbus LAF
In-Reply-To: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
References: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
Message-ID: <YxWB2FEPiKaX8ije7DK6-5qc6L-hUEMB7rBFxxxmM1k=.bcc5aa95-398d-4510-b33e-155ed7716f14@github.com>

On Tue, 6 Sep 2022 05:57:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CheckBox.disabledText and RadioButton.disabledText color UIProperty is not honoured by Nimbus L&F when disabled text is drawn for JCheckBox and JRadioButton, so disabled text color was rendered incorrectly.
> Fix is to honour these UIProperty color if they are set by user, else use the color from the component or via getColorForState().
> 
> Closed test as mentioned in JBS is used to check the fix.

Its open now

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

PR: https://git.openjdk.org/jdk/pull/10177


From psadhukhan at openjdk.org  Fri Sep  9 04:25:35 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 9 Sep 2022 04:25:35 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v3]
In-Reply-To: <8_EXfD0W-aphoJsroB4e0r8hsMrcxpfATTWDGHXP_Es=.c22772e4-447a-48b2-b5de-1918059670f2@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>
 <OKwiyluDGrJJzJjqurX6vA4apF1Dz-v39QJlk8s7vGA=.189ba8bb-9d6f-4ea7-b399-801a857981b9@github.com>
 <U8w2BKrB9bFKrDtUkEM19LFr66BrhIbCjqtqUY_59n4=.46d7d53b-d1f4-40c7-a4f9-c8be44140ed6@github.com>
 <8_EXfD0W-aphoJsroB4e0r8hsMrcxpfATTWDGHXP_Es=.c22772e4-447a-48b2-b5de-1918059670f2@github.com>
Message-ID: <-qOkFQnlLYWH_LFc0JpgxLICPgTG1mtzXG7xrnRppns=.cf90f4bc-bec9-4f99-aa5c-ee867c585f95@github.com>

On Thu, 8 Sep 2022 23:40:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> "*" is the default char unless overridden by echoChar property and is set [here](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/JPasswordField.java#L178)
>
> I just found my comment at that bug that the ui properties for nimbus are stored in the "skin.laf" and the "echoChar" is missed there. This is the reason why the UIDefaults table is small in Nimbus, unlike Metal where we have a long list of properties. Take a look to the `NimbusDefaults.java` which is generated during the build it contains all the props, and it is a place where I think we should update the echoChar.

It will have the problem as you mentioned so I did it as it is. Since we have already UIDefaults table defined, I think it can be used for this, without changing the doc which might cause compatibility issues.

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

PR: https://git.openjdk.org/jdk/pull/10035


From psadhukhan at openjdk.org  Fri Sep  9 04:38:44 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 9 Sep 2022 04:38:44 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v3]
In-Reply-To: <-qOkFQnlLYWH_LFc0JpgxLICPgTG1mtzXG7xrnRppns=.cf90f4bc-bec9-4f99-aa5c-ee867c585f95@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>
 <OKwiyluDGrJJzJjqurX6vA4apF1Dz-v39QJlk8s7vGA=.189ba8bb-9d6f-4ea7-b399-801a857981b9@github.com>
 <U8w2BKrB9bFKrDtUkEM19LFr66BrhIbCjqtqUY_59n4=.46d7d53b-d1f4-40c7-a4f9-c8be44140ed6@github.com>
 <8_EXfD0W-aphoJsroB4e0r8hsMrcxpfATTWDGHXP_Es=.c22772e4-447a-48b2-b5de-1918059670f2@github.com>
 <-qOkFQnlLYWH_LFc0JpgxLICPgTG1mtzXG7xrnRppns=.cf90f4bc-bec9-4f99-aa5c-ee867c585f95@github.com>
Message-ID: <1Y0OKsbNSaopRmrW3VQF8rh6RrClWmjbycO4qgfIY7I=.34c463c5-ccec-4bb5-981b-23e2a5bbab24@github.com>

On Fri, 9 Sep 2022 04:21:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I just found my comment at that bug that the ui properties for nimbus are stored in the "skin.laf" and the "echoChar" is missed there. This is the reason why the UIDefaults table is small in Nimbus, unlike Metal where we have a long list of properties. Take a look to the `NimbusDefaults.java` which is generated during the build it contains all the props, and it is a place where I think we should update the echoChar.
>
> It will have the problem as you mentioned so I did it as it is. Since we have already UIDefaults table defined, I think it can be used for this, without changing the doc which might cause compatibility issues.

it will also probably need change in compiler as to how it generates/parses the type as I am getting

Exception in thread "main" java.lang.NullPointerException: Cannot invoke "build.tools.generatenimbus.UIProperty$PropertyType.ordinal()" because "this.type" is null
	at build.tools.generatenimbus.UIProperty.write(UIProperty.java:87)
	at build.tools.generatenimbus.UIStyle.write(UIStyle.java:156)
	at build.tools.generatenimbus.UIRegion.write(UIRegion.java:213)
	at build.tools.generatenimbus.SynthModel.write(SynthModel.java:102)
	at build.tools.generatenimbus.Generator.generate(Generator.java:212)
	at build.tools.generatenimbus.Generator.main(Generator.java:118)

so I think this is the safer and cleaner alternative as I am not creating a new UIDefaults table, just adding a new entry to it..

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

PR: https://git.openjdk.org/jdk/pull/10035


From psadhukhan at openjdk.org  Fri Sep  9 05:05:45 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 9 Sep 2022 05:05:45 GMT
Subject: RFR: 8234315: GTK LAF does not gray out disabled JMenu
In-Reply-To: <s7Az0JMKFqPbKlMnUgUUsQSa2ygH9SW08N0DGr7sQQM=.2561a3ba-40ce-4902-a2d2-992aa1ad565f@github.com>
References: <s7Az0JMKFqPbKlMnUgUUsQSa2ygH9SW08N0DGr7sQQM=.2561a3ba-40ce-4902-a2d2-992aa1ad565f@github.com>
Message-ID: <lzM_4PwVXph-l2rpdIxgJ4ybntIxCjlUrFB6WEvSeVE=.27eedfe6-3647-4de1-8790-23a6d284643a@github.com>

On Tue, 6 Sep 2022 05:37:02 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> Disabled JMenu foreground color was not grayed out in GTK LAF for version 3. The issue didn't occur in GTK-2. 
> After analysis it has been found that the JMenu widget type was changed to JMenuBar and the color value returned for the foreground color in disabled state was close to black color (RGB 0,0,0) for menubar which is not differentiable from enabled state foreground color.
> 
> As a fix for this problem, if the menubar is in disabled state then the widget is changed to JMenu and color value returned for disabled menu is gray color.
> 
> An automated test case has been added and checked in CI, link is added in JBS.

Marked as reviewed by psadhukhan (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10176


From dnguyen at openjdk.org  Fri Sep  9 06:41:44 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 9 Sep 2022 06:41:44 GMT
Subject: RFR: 6529151: NullPointerException in
 swing.plaf.synth.SynthLookAndFeel$Handler [v2]
In-Reply-To: <gmecXQOdnDbdAyGedDD2IU7pAPe2IBnR46v-lJvHozI=.852f031d-dfb9-4d54-9914-226084196545@github.com>
References: <LNDDuM1Xo2waUauHyNK8iyw6y9cRGnawCO0ZbkVAIm4=.b2b2e136-5728-4734-b060-e61caa21f6c3@github.com>
 <gmecXQOdnDbdAyGedDD2IU7pAPe2IBnR46v-lJvHozI=.852f031d-dfb9-4d54-9914-226084196545@github.com>
Message-ID: <YZJFE6XM1kIgDchuv5iHmJcjY_NI7BnOg_GRYoIDlSo=.6204807b-a3a8-41b9-8db8-0c27427bc530@github.com>

On Wed, 7 Sep 2022 04:40:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> NPE is thrown for closed/disposed JDialogs after uninstalling the UI which is because for SynthEditorPaneUI even though is disposed of, Nimbus propertyHandler tries to get the style of this disposed component resulting in NPE, 
>> which is fixed by a null check to prevent deferencing style object to get the color.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test fix

Applied changes and NPE is no longer. Looks good to me

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

Marked as reviewed by dnguyen (Author).

PR: https://git.openjdk.org/jdk/pull/10167


From psadhukhan at openjdk.org  Fri Sep  9 07:06:53 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 9 Sep 2022 07:06:53 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v7]
In-Reply-To: <qay_twnp4S2mtoyFXNfTAxWJuMmiK4eZrK1MKdvBUgA=.b614b959-f157-4b90-bbce-e1626474e15c@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <qay_twnp4S2mtoyFXNfTAxWJuMmiK4eZrK1MKdvBUgA=.b614b959-f157-4b90-bbce-e1626474e15c@github.com>
Message-ID: <-4XOW9ZOMRpytje4SYUnP3YjrWhnP8PrQ8960lge76o=.5b845455-a7fa-4fc8-b908-5de2f21dc93e@github.com>

On Wed, 17 Aug 2022 22:37:46 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
>> 
>> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
>> 
>> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright date. Added MacOS text to test.

Marked as reviewed by psadhukhan (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9473


From psadhukhan at openjdk.org  Fri Sep  9 07:06:55 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 9 Sep 2022 07:06:55 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v7]
In-Reply-To: <CMda7n-jNPE4l-ardt65Ip4yS3uJGNjkrkdEC_JoEKo=.f52c18fa-e58f-4182-9a59-6bf5eb38bc3b@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <qay_twnp4S2mtoyFXNfTAxWJuMmiK4eZrK1MKdvBUgA=.b614b959-f157-4b90-bbce-e1626474e15c@github.com>
 <fLdwg5tf1pNBBPZjaC4kPq8rAR2wR6o61uJj0JPNk6w=.8dae6d77-f220-4c5a-9904-0b77465fd308@github.com>
 <CMda7n-jNPE4l-ardt65Ip4yS3uJGNjkrkdEC_JoEKo=.f52c18fa-e58f-4182-9a59-6bf5eb38bc3b@github.com>
Message-ID: <YzrzIitr8ONQ1_dBy9Nr25F1ucBTzgd6I0hH9GGotgY=.0d433acf-74ba-4bb0-9dd5-5b12da4edd4f@github.com>

On Wed, 31 Aug 2022 17:49:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 471:
>> 
>>> 469: 
>>> 470:             if (comboBox.getComponentOrientation().isLeftToRight()) {
>>> 471:                 return new Rectangle(insets.left, insets.top + midHeight,
>> 
>> OK. Since Apple has confirmed combobox height shouldn't change with font size, we can have fixed height.
>> 
>> Only thing I guess, till we sort out JDK-8023912: [macosx] JComboBox RTL orientation problem
>> lets use LTR as it seems it might give a false impression that we support RTL when we dont even know if Apple supports it or not. Do you see any difference with combobox if you use LTR code vs RTL code with RTL testcase present in the above JBS? I dont in my BigSur.
>> 
>> It will also be good to test it out in non-retina display to see if this "22" height is being shown ok there.
>
> I don't see a difference either but was following the same logic as used in BasicComboBoxUI. I can remove the LTR vs RTL logic until the other issue is resolved if needed.

You can keep this for now...You can take in JDK-8023912 incase which I guess needs a followup question to Apple.

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

PR: https://git.openjdk.org/jdk/pull/9473


From duke at openjdk.org  Fri Sep  9 07:12:45 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 9 Sep 2022 07:12:45 GMT
Subject: Integrated: 8234315: GTK LAF does not gray out disabled JMenu
In-Reply-To: <s7Az0JMKFqPbKlMnUgUUsQSa2ygH9SW08N0DGr7sQQM=.2561a3ba-40ce-4902-a2d2-992aa1ad565f@github.com>
References: <s7Az0JMKFqPbKlMnUgUUsQSa2ygH9SW08N0DGr7sQQM=.2561a3ba-40ce-4902-a2d2-992aa1ad565f@github.com>
Message-ID: <WmhTPrkY8IqmE5oe9eJGk9laEuGziub4Vl8diMTxov0=.eb5f1400-8ec0-4498-826e-d4c4d28cd574@github.com>

On Tue, 6 Sep 2022 05:37:02 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> Disabled JMenu foreground color was not grayed out in GTK LAF for version 3. The issue didn't occur in GTK-2. 
> After analysis it has been found that the JMenu widget type was changed to JMenuBar and the color value returned for the foreground color in disabled state was close to black color (RGB 0,0,0) for menubar which is not differentiable from enabled state foreground color.
> 
> As a fix for this problem, if the menubar is in disabled state then the widget is changed to JMenu and color value returned for disabled menu is gray color.
> 
> An automated test case has been added and checked in CI, link is added in JBS.

This pull request has now been integrated.

Changeset: 9d6b0285
Author:    Abhishek Kumar <abhishek.cx.kumar at oracle.com>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9d6b0285f53599816c30393b87d16772ef6314b7
Stats:     130 lines in 2 files changed: 130 ins; 0 del; 0 mod

8234315: GTK LAF does not gray out disabled JMenu

Reviewed-by: serb, psadhukhan

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

PR: https://git.openjdk.org/jdk/pull/10176


From tr at openjdk.org  Fri Sep  9 08:12:45 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 9 Sep 2022 08:12:45 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v4]
In-Reply-To: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
Message-ID: <w6ubPexUyHVKXODWkZG7KXbyhRewaBumPbqL3UlXgv8=.38c1309c-34fc-4f93-9ba7-047bae11fdfa@github.com>

> JFileChooser.getSelectedFiles() failed to retrieve files with multi-selection and double-click. This occurs when a single file is selected then enable multi-selection then select the same file through mouse double-click(Two file chooser dialogs used before and after multi-selection enabled). SelectedFiles are updated when a change in files/directory selection is done or when selection is made through keyboard selection. In this case since a single file is selected before multi-selection is enabled and same file is selected again without changing the selection index/directory, leaving selected Files un-updated. 
> **Proposed Fix** : Whenever Multi-Selection is enabled check if any files are selected, if yes update the selected Files of JFileChoooser.

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

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9996/files
  - new: https://git.openjdk.org/jdk/pull/9996/files/1d7f271b..c437cdfc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9996&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9996&range=02-03

  Stats: 27 lines in 2 files changed: 2 ins; 15 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/9996.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9996/head:pull/9996

PR: https://git.openjdk.org/jdk/pull/9996


From tr at openjdk.org  Fri Sep  9 08:12:46 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 9 Sep 2022 08:12:46 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <DpRKOf5tq9EB8T3XEbDe417oPMUMWOdxs3alO0K_hKo=.aef56d70-83d4-43bf-93e0-83ae84b52a3c@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
 <87to_TWEwp56w4tmpqqSwY7DBxBoemZ4t5kZ2v_ebxo=.e604fc0e-d5a2-44d4-b9da-c4765af317af@github.com>
 <ngrXkLF2mK0_jn5YzK8mG7r0NiNoH0vbEZcbRpVVo3o=.a6cd6622-8547-4645-a69e-004216479fdc@github.com>
 <Zcq_MKhZsW4_c5Yzr0Al27i8z5kaSjQOgA8gHASccXk=.f8a91643-a202-48ff-a562-478d465dee5e@github.com>
 <t-y8-p6M1UScws4ofTEXBMRhUxPFkduWC5mrYntEXgM=.6e10bdb7-a3ad-4a18-bc81-f79284653096@github.com>
 <qnQYFBymio4mDhcD07487j7gQd0weZpo1QUNFjgXIjM=.2fd23885-f238-46d5-8abd-87bdb30e6b4b@github.com>
 <ZxfYxjWQkBFUCWe72YMgak1r4eDYA3zjLFA-3PfDwz4=.597ec994-c432-44d9-9c7d-6c046af8d4eb@github.com>
 <_usGkRuX1Jrds8aCy2udq6VAL7QY_6VxIO80-8C7TkM=.e6557ae5-92ac-455a-9704-5e0cef679dde@github.com>
 <DpRKOf5tq9EB8T3XEbDe417oPMUMWOdxs3alO0K_hKo=.aef56d70-83d4-43bf-93e0-83ae84b52a3c@github.com>
Message-ID: <jmOFzY4DrtfN9UpUOsqxuMr_yQPoeEKulu4GPq-5z7A=.59fd51ee-13c5-460b-8547-2c31bf3fef56@github.com>

On Thu, 8 Sep 2022 11:49:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Clearing the selection and setting it to null also solves the problem though. When we call clear selection, reset will happen and selectedFiles will be set.
>
> As discussed on call its better to clear selection when we move between multi-selection enabled/disabled as captured in https://github.com/openjdk/jdk/pull/9996#discussion_r965791205.
> 
> Because using getSelectedFile() to update setSelectedFiles() might cause state management issues in some other scenarios.

Yeah, I have updated as discussed on call and tested.

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

PR: https://git.openjdk.org/jdk/pull/9996


From tr at openjdk.org  Fri Sep  9 08:12:47 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 9 Sep 2022 08:12:47 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <rgAZJB6n3rgKumeVtObxDcBIlNi87539UZNyj6-cFIM=.773867e6-8ef6-45c2-bbbb-ebd7b79e214a@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
 <yNi7xs_ywEsyNtx9lJu98vra_-n6mFJftxaCsNE6FJM=.eee780bb-286c-4c6c-bb63-26f92b65bbc1@github.com>
 <jXIciMjpx9KrA9kQmzJUyDeJZm4qw4j_7cTWvAxQrB0=.ca8a301e-1493-4590-84f1-437e6ee037bb@github.com>
 <5ly-7MCOy5_-N5_cKwjASkTLo9uoUDTodkqByDQahZg=.d8e04260-67db-4031-a9d9-599381a6a468@github.com>
 <p_MIFHO00D1iPDyhWN5j_pdazK6TMK-OX90nbbrqaf8=.e5c88351-b871-4432-88b2-68fef2d6211d@github.com>
 <q9nFSuy2lp2v1Ss0kJthXD1X2HzAyXbPH7wLCI1vt6o=.05cd7ebd-3b25-4ad5-a6fc-9db587869137@github.com>
 <rgAZJB6n3rgKumeVtObxDcBIlNi87539UZNyj6-cFIM=.773867e6-8ef6-45c2-bbbb-ebd7b79e214a@github.com>
Message-ID: <dMtsn5jLE2pzQvSCz2P_dCb34an2syS5uCLCngMCl-k=.23374889-2c22-42d1-85ff-8933c794b98d@github.com>

On Thu, 8 Sep 2022 11:03:32 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> I guess the dialogue is not not been removed when exception is thrown. Will take a look into it.
>
> If the product fix that is being done will touch only Linux and Windows(And in Mac it looks like it not exiting properly), we can make this regression test to run only on Linux and Windows using jtreg tag:
> @requires (os.family == "windows" | os.family == "linux")

Updated.

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

PR: https://git.openjdk.org/jdk/pull/9996


From tr at openjdk.org  Fri Sep  9 08:12:50 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 9 Sep 2022 08:12:50 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v3]
In-Reply-To: <yNi7xs_ywEsyNtx9lJu98vra_-n6mFJftxaCsNE6FJM=.eee780bb-286c-4c6c-bb63-26f92b65bbc1@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <E7lRSjmKV8lUarNz6SVPv6tDrhB5qtrg1Gu0TuwqpN8=.52528e29-f473-4e60-b61e-9afd6a4adaed@github.com>
 <yNi7xs_ywEsyNtx9lJu98vra_-n6mFJftxaCsNE6FJM=.eee780bb-286c-4c6c-bb63-26f92b65bbc1@github.com>
Message-ID: <P2xRz04paFOvG_Cn17JPfYEsrskOpGhh4PL1gnU__p8=.e720cc5c-f1b8-4d4b-b766-a78d9208deb5@github.com>

On Thu, 8 Sep 2022 09:51:57 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> test/jdk/javax/swing/JFileChooser/MultiSelectionEnabledSelectedFilesTest.java line 56:
> 
>> 54:     static void runTest() {
>> 55:         //Initialize the components
>> 56:         String INSTRUCTIONS
> 
> Instruction should be updated to specify that we need to use double-click.
> Also when i select a file using double click in first and then select same file using double-click(without moving mouse) test doesnt exit. JFileChooser second dialog just stays on the screen.

Updated.

> test/jdk/javax/swing/JFileChooser/MultiSelectionEnabledSelectedFilesTest.java line 87:
> 
>> 85:         File[] files = chooser.getSelectedFiles();
>> 86: 
>> 87:         if (files.length <= 0) {
> 
> Can File[] length be negative? I think just a "==" to "0" check should suffice.

Updated.

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

PR: https://git.openjdk.org/jdk/pull/9996


From duke at openjdk.org  Fri Sep  9 08:14:06 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 9 Sep 2022 08:14:06 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v26]
In-Reply-To: <i-40SOCdt6Zlk-UukGR9ZoII2KvYK5nuGox6hU7xycw=.61a284b4-7731-4f8b-b7d7-3aa10d8be802@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <QYaW5bTaDAzVkGYK11xiLSPLTSdIU6DiBrBR-dKCQOI=.2f3ab314-85a9-44d6-9526-1ad9d9f7056b@github.com>
 <i-40SOCdt6Zlk-UukGR9ZoII2KvYK5nuGox6hU7xycw=.61a284b4-7731-4f8b-b7d7-3aa10d8be802@github.com>
Message-ID: <0qCFmGLsWZ9VO8hhO2S0ki-zUpqqBn--Ow7QZrbXW0k=.347077d5-f10d-4f25-a8dc-174d15e9f57a@github.com>

On Thu, 8 Sep 2022 17:32:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Filesize calculation logic modified
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1277:
> 
>> 1275:             DecimalFormat df = new DecimalFormat("0.0");
>> 1276:             double val = fileSize/baseFileSize;
>> 1277:             return  Double.valueOf(df.format(val));
> 
> The new code to round up looks difficult to understand (I mean the addition of 99 and re-worked if-conditions). I liked the previous version better. The only thing required to introduce rounding up is updating `roundToOneDecimalPlace`:
> 
> 
>         private static double roundToOneDecimalPlace(long fileSize) {
>             return  Math.ceilDiv(fileSize, 100L) / 10.0d;
>         }
> 
> 
> [`Math.ceilDiv`](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/Math.html#ceilDiv(long,long)) is available since Java 18.
> 
> However, this code also works and is better suited for backporting:
> 
> 
>         private static double roundToOneDecimalPlace(long fileSize) {
>             return  Math.ceil(fileSize / 100.0d) / 10.0d;
>         }
> 
> Note that the first division is also floating point.
> 
> With this implementation of `roundToOneDecimalPlace` and your code before the latest update which introduced `+99`, I get the expected size displayed in `JFileChooser`, that is rounded up if there's a non-zero remainder. Could you please verify that?

I have checked with the suggested changes, it rounds up the value if the remainder is non-zero value.
But for files >1000 bytes it doesn't return the file size similar to native file manager. 

FileChooser rounded up the values to next decimal precision.
![FC_FileSize_1](https://user-images.githubusercontent.com/107542245/189302260-f99d175a-133b-45ad-bdf0-52de06aacb7d.png)

File sizes are not rounding up in all cases in native file system. For e.g. 1150 bytes file size is is 1.1 KB whereas 1151 bytes file size is 1.2 KB.   
![Native_FIleSize](https://user-images.githubusercontent.com/107542245/189302284-55e48e72-c9c0-4abe-aa17-56190f2aeaee.png)

To keep it consistent with the native file system for larger files (>1000 bytes), I tried using DecimalFormat.

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

PR: https://git.openjdk.org/jdk/pull/9327


From tr at openjdk.org  Fri Sep  9 08:14:33 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 9 Sep 2022 08:14:33 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v2]
In-Reply-To: <5Y6GY-MycmJkFjgVOw7l9ysKuIgWKWVUZ5wwPz-YcU0=.92bf4183-78c0-42d1-b8c4-7cb4a1fe1866@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <CffGJYwFN0vfbFSdzLpwGGGivp4BcLuX_KbQoBNwPzE=.56090a62-5906-4dc8-a6fe-605392db07ea@github.com>
 <5Y6GY-MycmJkFjgVOw7l9ysKuIgWKWVUZ5wwPz-YcU0=.92bf4183-78c0-42d1-b8c4-7cb4a1fe1866@github.com>
Message-ID: <XMUlTKJ8dPBTF5MG9dgugJNmwNR7T4IQ93I-8rWAkNU=.a90a8bca-a1ee-4575-8445-8e307876007f@github.com>

On Tue, 6 Sep 2022 11:07:09 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> I guess copyright year for FilePane.java needs to be updated.

@kumarabhi006 U might have to re-review the PR as we have changed the logic. Previously the selected flies state was retained, now the state is been cleared on MultiSelection enabled/disabled switch.

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

PR: https://git.openjdk.org/jdk/pull/9996


From duke at openjdk.org  Fri Sep  9 09:06:48 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 9 Sep 2022 09:06:48 GMT
Subject: RFR: 8292848: AWT_Mixing and TrayIcon tests fail on el8 with
 hard-coded isOel7
In-Reply-To: <aH8UVH574D88IUnIf8B3SlA2NAXBfFxo8lqrnM5CVNc=.6ebdfd83-13e1-4326-acc3-5311a205a4f4@github.com>
References: <ZJrPLHPk000YQPHb73cCqw1l7jP1vwRLEXMlOgrqVSs=.a599b437-a90f-4f81-8ca5-aa2809bde6f7@github.com>
 <aH8UVH574D88IUnIf8B3SlA2NAXBfFxo8lqrnM5CVNc=.6ebdfd83-13e1-4326-acc3-5311a205a4f4@github.com>
Message-ID: <8zkl2kX03CNZFOpKTvWi87Gq8a-s2_ObZcx1bzHWgGU=.eb218efd-eedc-4953-adec-18d9eb47b6d0@github.com>

On Thu, 25 Aug 2022 18:56:59 GMT, Phil Race <prr at openjdk.org> wrote:

>> Could you please review the JDK-8292848 bug fixes?
>> The purpose of the isOel7 method is to detect differences in GNOME version changes, and the isOel7 
>> result should be true after version 8.
>> I modified the isOel7 method to use regular expressions instead of hard-coded versions to be able to 
>> detect the new os version.
>> I also changed the method name to match the new conditions.
>
> I guess this will do what was previously being done on OL7 .. but the way it is done it is fragile
> and surely it can't be specific to OL .. and there's some pretty hokey adjustments going on in some of these tests.
> I think some day these tests will need to be re-examined.

@prrace 
Could you sponsor  this pull request, please?

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

PR: https://git.openjdk.org/jdk/pull/9995


From psadhukhan at openjdk.org  Fri Sep  9 09:34:02 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 9 Sep 2022 09:34:02 GMT
Subject: RFR: 7148092: [macosx] When Alt+down arrow key is pressed,
 the combobox popup does not appear. [v5]
In-Reply-To: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
References: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
Message-ID: <03fLl5XUqUXveKPvSjtrRXjx7epMGAVeYgdhECk1iB4=.ca933754-196a-443b-b004-ce4393e62379@github.com>

> When comboBox have focus, pressing Alt+Down (or Up) should render the popup which is not happening for Aqua L&F.
> 
> Fix is to add toggleAction for Alt+Down/Up keys as has been done for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L912)
> 
> closed problemlisted test is used to check the fix.

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

  Test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10014/files
  - new: https://git.openjdk.org/jdk/pull/10014/files/180f73d3..925c37d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10014&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10014&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/10014


From jdv at openjdk.org  Fri Sep  9 11:08:05 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 9 Sep 2022 11:08:05 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v2]
In-Reply-To: <XMUlTKJ8dPBTF5MG9dgugJNmwNR7T4IQ93I-8rWAkNU=.a90a8bca-a1ee-4575-8445-8e307876007f@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <CffGJYwFN0vfbFSdzLpwGGGivp4BcLuX_KbQoBNwPzE=.56090a62-5906-4dc8-a6fe-605392db07ea@github.com>
 <5Y6GY-MycmJkFjgVOw7l9ysKuIgWKWVUZ5wwPz-YcU0=.92bf4183-78c0-42d1-b8c4-7cb4a1fe1866@github.com>
 <XMUlTKJ8dPBTF5MG9dgugJNmwNR7T4IQ93I-8rWAkNU=.a90a8bca-a1ee-4575-8445-8e307876007f@github.com>
Message-ID: <TNDH4BZNacjJLAVp8Y1SJ7Ocr86mhdvtivd0TJPNnIg=.1d1ea962-329f-4129-84eb-9574222a1253@github.com>

On Fri, 9 Sep 2022 08:11:47 GMT, Tejesh R <tr at openjdk.org> wrote:

>> I guess copyright year for FilePane.java needs to be updated.
>
> @kumarabhi006 U might have to re-review the PR as we have changed the logic. Previously the selected flies state was retained, now the state is been cleared on MultiSelection enabled/disabled switch.

@TejeshR13 I see some test failures in latest CI job like javax/swing/JTree/4618767/JTreeSelectedElementTest.java.
Have you verified these are not regressions introduced by this change?

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

PR: https://git.openjdk.org/jdk/pull/9996


From tr at openjdk.org  Fri Sep  9 11:08:06 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 9 Sep 2022 11:08:06 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v2]
In-Reply-To: <XMUlTKJ8dPBTF5MG9dgugJNmwNR7T4IQ93I-8rWAkNU=.a90a8bca-a1ee-4575-8445-8e307876007f@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <CffGJYwFN0vfbFSdzLpwGGGivp4BcLuX_KbQoBNwPzE=.56090a62-5906-4dc8-a6fe-605392db07ea@github.com>
 <5Y6GY-MycmJkFjgVOw7l9ysKuIgWKWVUZ5wwPz-YcU0=.92bf4183-78c0-42d1-b8c4-7cb4a1fe1866@github.com>
 <XMUlTKJ8dPBTF5MG9dgugJNmwNR7T4IQ93I-8rWAkNU=.a90a8bca-a1ee-4575-8445-8e307876007f@github.com>
Message-ID: <6PJllq1vqYfYaSVm-ujBg3tFPGqttm7WB9kzMVGLKls=.f2baace9-bccd-4eca-91dd-da8d5a571f17@github.com>

On Fri, 9 Sep 2022 08:11:47 GMT, Tejesh R <tr at openjdk.org> wrote:

>> I guess copyright year for FilePane.java needs to be updated.
>
> @kumarabhi006 U might have to re-review the PR as we have changed the logic. Previously the selected flies state was retained, now the state is been cleared on MultiSelection enabled/disabled switch.

> @TejeshR13 I see some test failures in latest CI job like javax/swing/JTree/4618767/JTreeSelectedElementTest.java. Have you verified these are not regressions introduced by this change?

Yeah, those tests are failing without my changes too, so confirmed that it wasn't from my change.

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

PR: https://git.openjdk.org/jdk/pull/9996


From jdv at openjdk.org  Fri Sep  9 11:19:02 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 9 Sep 2022 11:19:02 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v2]
In-Reply-To: <6PJllq1vqYfYaSVm-ujBg3tFPGqttm7WB9kzMVGLKls=.f2baace9-bccd-4eca-91dd-da8d5a571f17@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <CffGJYwFN0vfbFSdzLpwGGGivp4BcLuX_KbQoBNwPzE=.56090a62-5906-4dc8-a6fe-605392db07ea@github.com>
 <5Y6GY-MycmJkFjgVOw7l9ysKuIgWKWVUZ5wwPz-YcU0=.92bf4183-78c0-42d1-b8c4-7cb4a1fe1866@github.com>
 <XMUlTKJ8dPBTF5MG9dgugJNmwNR7T4IQ93I-8rWAkNU=.a90a8bca-a1ee-4575-8445-8e307876007f@github.com>
 <6PJllq1vqYfYaSVm-ujBg3tFPGqttm7WB9kzMVGLKls=.f2baace9-bccd-4eca-91dd-da8d5a571f17@github.com>
Message-ID: <-x5W_XBp5PMR7DHa4BvPjBTwVrl-mGLToLuWI6Npf0M=.a13038fb-1102-46e5-adb8-bf18881bf54f@github.com>

On Fri, 9 Sep 2022 11:05:09 GMT, Tejesh R <tr at openjdk.org> wrote:

> > @TejeshR13 I see some test failures in latest CI job like javax/swing/JTree/4618767/JTreeSelectedElementTest.java. Have you verified these are not regressions introduced by this change?
> 
> Yeah, those tests are failing without my changes too, so confirmed that it wasn't from my change. Some tests are failing without my fix also, so to ensure that my fix doesn't cause any regression I have tested without my fix and shared the link in JBS.

Thanks for adding CI run without fix also in JBS. LGTM.

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

PR: https://git.openjdk.org/jdk/pull/9996


From jdv at openjdk.org  Fri Sep  9 11:34:40 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 9 Sep 2022 11:34:40 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v4]
In-Reply-To: <w6ubPexUyHVKXODWkZG7KXbyhRewaBumPbqL3UlXgv8=.38c1309c-34fc-4f93-9ba7-047bae11fdfa@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <w6ubPexUyHVKXODWkZG7KXbyhRewaBumPbqL3UlXgv8=.38c1309c-34fc-4f93-9ba7-047bae11fdfa@github.com>
Message-ID: <ptq6JTMMPvg8FOoNlkr17BqzX6XvspBEtvWrG6M7JJM=.e9d9f740-b999-42a5-8c22-60b235c2677d@github.com>

On Fri, 9 Sep 2022 08:12:45 GMT, Tejesh R <tr at openjdk.org> wrote:

>> JFileChooser.getSelectedFiles() failed to retrieve files with multi-selection and double-click. This occurs when a single file is selected then enable multi-selection then select the same file through mouse double-click(Two file chooser dialogs used before and after multi-selection enabled). SelectedFiles are updated when a change in files/directory selection is done or when selection is made through keyboard selection. In this case since a single file is selected before multi-selection is enabled and same file is selected again without changing the selection index/directory, leaving selected Files un-updated. 
>> **Proposed Fix** : Whenever Multi-Selection is enabled check if any files are selected, if yes update the selected Files of JFileChoooser.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Marked as reviewed by jdv (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9996


From duke at openjdk.org  Fri Sep  9 11:34:42 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 9 Sep 2022 11:34:42 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click [v2]
In-Reply-To: <5Y6GY-MycmJkFjgVOw7l9ysKuIgWKWVUZ5wwPz-YcU0=.92bf4183-78c0-42d1-b8c4-7cb4a1fe1866@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
 <CffGJYwFN0vfbFSdzLpwGGGivp4BcLuX_KbQoBNwPzE=.56090a62-5906-4dc8-a6fe-605392db07ea@github.com>
 <5Y6GY-MycmJkFjgVOw7l9ysKuIgWKWVUZ5wwPz-YcU0=.92bf4183-78c0-42d1-b8c4-7cb4a1fe1866@github.com>
Message-ID: <xueMTTbHhTCS7UH-p5WrcaqE5s-b7LJlmRDoE1QNi9g=.e51b4705-afe6-4e6d-96d5-0be2fa7d5289@github.com>

On Tue, 6 Sep 2022 11:07:09 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> I guess copyright year for FilePane.java needs to be updated.

> @kumarabhi006 U might have to re-review the PR as we have changed the logic. Previously the selected flies state was retained, now the state is been cleared on MultiSelection enabled/disabled switch.

Applied the patch and tested, attached test case is passed with your recent fix.

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

PR: https://git.openjdk.org/jdk/pull/9996


From mdoerr at openjdk.org  Fri Sep  9 15:49:57 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 9 Sep 2022 15:49:57 GMT
Subject: RFR: JDK-8292866:
 Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation check MultiByteToWideChar
 return value for failures [v2]
In-Reply-To: <lI4kmR6aNZL2iuCY9Qfe93XtrF8sry7ZgjCspBW8gGg=.656cb9a7-aa39-4f39-9b54-ba91a34ada60@github.com>
References: <prlZNHespV4sJHeN-XKbLbDg5MIXWigO8OS5F03Fcy8=.186655cf-7fc6-41c0-aa6b-3602fae9ca01@github.com>
 <lI4kmR6aNZL2iuCY9Qfe93XtrF8sry7ZgjCspBW8gGg=.656cb9a7-aa39-4f39-9b54-ba91a34ada60@github.com>
Message-ID: <wDTjiOztx2d2oqQPDegm4zhZvH7wXuLJoir2NdAQsSI=.4158bb49-f4e3-4672-9cc7-e580569ed7d6@github.com>

On Fri, 26 Aug 2022 07:54:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
>> states about MultiByteToWideChar : "The function returns 0 if it does not succeed" and lists a few failure cases.
>> However we miss checking the failure case in Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation , seems we assume the function always works nicely (in most of the JDK coding the return value is checked ).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust added return syntax

This version LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10015


From duke at openjdk.org  Fri Sep  9 17:24:17 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 9 Sep 2022 17:24:17 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v27]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <eNhAVzUfQh4Jm9qe4CYUFH_tMVeaOW5Nit_9I-ZFO0M=.970bbf0d-6be1-412a-abd2-bb347c9ecd91@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 KB.
> Manual Test Case "FileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Review comments fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/cea398f5..99224c1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=25-26

  Stats: 33 lines in 1 file changed: 2 ins; 20 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Fri Sep  9 17:24:17 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 9 Sep 2022 17:24:17 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v26]
In-Reply-To: <QYaW5bTaDAzVkGYK11xiLSPLTSdIU6DiBrBR-dKCQOI=.2f3ab314-85a9-44d6-9526-1ad9d9f7056b@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <QYaW5bTaDAzVkGYK11xiLSPLTSdIU6DiBrBR-dKCQOI=.2f3ab314-85a9-44d6-9526-1ad9d9f7056b@github.com>
Message-ID: <8UehoJHcX3siRRz4chDJOcxnxAmfbGoKqcDelYlhM0Q=.425a5eb4-2ad8-427f-87d0-c10c8dcf07ea@github.com>

On Fri, 2 Sep 2022 11:12:53 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Filesize calculation logic modified

Updated as per review comments

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

PR: https://git.openjdk.org/jdk/pull/9327


From honkar at openjdk.org  Fri Sep  9 23:18:05 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 9 Sep 2022 23:18:05 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v8]
In-Reply-To: <9GipfZodYw6JMprg7PAn2ysOARY6uqNRgkzQQi57ugE=.fab92818-9a2a-4b8c-b670-fca1d53206af@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <9GipfZodYw6JMprg7PAn2ysOARY6uqNRgkzQQi57ugE=.fab92818-9a2a-4b8c-b670-fca1d53206af@github.com>
Message-ID: <SXsCbrbRdV495EmJFGT93jtbfQ-YCWLA6DvJmGqBY3w=.66004437-4de7-476b-a67a-4714a0782e91@github.com>

On Fri, 9 Sep 2022 23:13:57 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
>> 
>> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
>> 
>> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reordered set visible

Marked as reviewed by honkar (Author).

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

PR: https://git.openjdk.org/jdk/pull/9473


From dnguyen at openjdk.org  Fri Sep  9 23:18:05 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 9 Sep 2022 23:18:05 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v8]
In-Reply-To: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
Message-ID: <9GipfZodYw6JMprg7PAn2ysOARY6uqNRgkzQQi57ugE=.fab92818-9a2a-4b8c-b670-fca1d53206af@github.com>

> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
> 
> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
> 
> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Reordered set visible

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9473/files
  - new: https://git.openjdk.org/jdk/pull/9473/files/0eae1016..6fec827e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9473&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9473&range=06-07

  Stats: 6 lines in 1 file changed: 2 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9473.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9473/head:pull/9473

PR: https://git.openjdk.org/jdk/pull/9473


From dnguyen at openjdk.org  Fri Sep  9 23:18:05 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 9 Sep 2022 23:18:05 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v7]
In-Reply-To: <LGs0QzfpkWfvFXkIZGmCQtckVvgrUgg1738a-vVYjjY=.a01c2304-ad89-4758-90b1-4a101ce1c9ff@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <qay_twnp4S2mtoyFXNfTAxWJuMmiK4eZrK1MKdvBUgA=.b614b959-f157-4b90-bbce-e1626474e15c@github.com>
 <LGs0QzfpkWfvFXkIZGmCQtckVvgrUgg1738a-vVYjjY=.a01c2304-ad89-4758-90b1-4a101ce1c9ff@github.com>
Message-ID: <un7yJWR_gIlElTlNe5mwgaCMuuem3uYHS7g9imwvyNk=.6a52e530-6f9f-4b77-880d-c6a6627cd56d@github.com>

On Thu, 8 Sep 2022 21:07:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated copyright date. Added MacOS text to test.
>
> test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java line 74:
> 
>> 72:             frame = new JFrame();
>> 73:             frame.getContentPane().add(panel);
>> 74:             frame.setVisible(true);
> 
> @DamonGuy To avoid flickering of the test frame move `frame.setVisible(true)` after `PassFailJFrame.positionTestWindow()`

Updated. Thanks, will note for the future.

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

PR: https://git.openjdk.org/jdk/pull/9473


From duke at openjdk.org  Sat Sep 10 13:37:57 2022
From: duke at openjdk.org (ScientificWare)
Date: Sat, 10 Sep 2022 13:37:57 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v14]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <qYgDumzox1SUYZyeXVodYu5T6vY4J1X82MDxpvVpaOI=.2482dd87-4f58-4737-930c-b6f1364cee85@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

  Error in comment.
  
  Sync. comment with code : "fails ... if stringToColor(null) doesn't return null".

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/c606d8bf..978ad292

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=12-13

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

PR: https://git.openjdk.org/jdk/pull/9825


From stuefe at openjdk.org  Sun Sep 11 06:20:45 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 11 Sep 2022 06:20:45 GMT
Subject: RFR: JDK-8292866:
 Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation check MultiByteToWideChar
 return value for failures [v2]
In-Reply-To: <lI4kmR6aNZL2iuCY9Qfe93XtrF8sry7ZgjCspBW8gGg=.656cb9a7-aa39-4f39-9b54-ba91a34ada60@github.com>
References: <prlZNHespV4sJHeN-XKbLbDg5MIXWigO8OS5F03Fcy8=.186655cf-7fc6-41c0-aa6b-3602fae9ca01@github.com>
 <lI4kmR6aNZL2iuCY9Qfe93XtrF8sry7ZgjCspBW8gGg=.656cb9a7-aa39-4f39-9b54-ba91a34ada60@github.com>
Message-ID: <LauiAWK3ZzT-gkbCbU590Ejbc6TwcagJDFiU__cjZ1w=.3ae101a0-69c4-4e28-9c46-d73f897ea415@github.com>

On Fri, 26 Aug 2022 07:54:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
>> states about MultiByteToWideChar : "The function returns 0 if it does not succeed" and lists a few failure cases.
>> However we miss checking the failure case in Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation , seems we assume the function always works nicely (in most of the JDK coding the return value is checked ).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust added return syntax

LGTM

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10015


From duke at openjdk.org  Mon Sep 12 05:31:46 2022
From: duke at openjdk.org (Stanimir Stamenkov)
Date: Mon, 12 Sep 2022 05:31:46 GMT
Subject: RFR: 8292948: JEditorPane ignores font-size styles in external
 linked css-file [v3]
In-Reply-To: <IAmwJkxY2YsJOeoXyDY7yj9Z9VQZ9LvanCHMP4lMW0k=.a978bfcc-e1bc-4967-9ed1-6b9574841b81@github.com>
References: <CXQy2fQCcs9PeBtCtUZmEdKhx9le3CQxQQAf564QVTM=.e448a883-d2e3-425d-aaa4-1b9d32431b60@github.com>
 <DdTUT7vC4FVOCZdCPTiEegnyq8vi9uXgLddgU0rCJuo=.9a817522-794d-47a3-923e-540d9cf2d973@github.com>
 <IAmwJkxY2YsJOeoXyDY7yj9Z9VQZ9LvanCHMP4lMW0k=.a978bfcc-e1bc-4967-9ed1-6b9574841b81@github.com>
Message-ID: <7lFEiyBO3ip7lIq_WpkwFkTnY7KOaIog3FJze9-L8vg=.1ae6f9c7-bea8-437e-873e-e8b920d7c67e@github.com>

On Fri, 2 Sep 2022 07:13:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Stanimir Stamenkov has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - 8292948: Make captureImage() an instance method
>>    
>>    Use just the instance editor component.
>>  - 8292948: Use bigger/different base font than the default
>>    
>>    Make potential discrepancies with not resolving the base more obvious.
>>  - 8292948: Make the setUp(), run/verify() sequence invocation explicit
>>    
>>    Simplify overall setup.
>>  - 8292948: Avoid failing to save image capture when editor == null
>>    
>>    The failure to save the image suppresses the original failure.
>>  - 8292948: Capitalize messages
>>  - 8292948: Resolve test HTML file from the classpath
>>    
>>    Don't rely on the current working directory.
>>  - 8292948: Adjust @summary
>
> Marked as reviewed by psadhukhan (Reviewer).

If there are no other reviewers, @prsadhuk, would you sponsor this change?

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

PR: https://git.openjdk.org/jdk/pull/10054


From mbaesken at openjdk.org  Mon Sep 12 06:45:07 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 12 Sep 2022 06:45:07 GMT
Subject: RFR: JDK-8292866:
 Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation check MultiByteToWideChar
 return value for failures [v2]
In-Reply-To: <lI4kmR6aNZL2iuCY9Qfe93XtrF8sry7ZgjCspBW8gGg=.656cb9a7-aa39-4f39-9b54-ba91a34ada60@github.com>
References: <prlZNHespV4sJHeN-XKbLbDg5MIXWigO8OS5F03Fcy8=.186655cf-7fc6-41c0-aa6b-3602fae9ca01@github.com>
 <lI4kmR6aNZL2iuCY9Qfe93XtrF8sry7ZgjCspBW8gGg=.656cb9a7-aa39-4f39-9b54-ba91a34ada60@github.com>
Message-ID: <RmGSO6pRKPI29TaDh-UIqJ9nTqeZqfJTE1fcNaluu4Y=.78376142-71df-412e-b2b6-ea5dfe92833b@github.com>

On Fri, 26 Aug 2022 07:54:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
>> states about MultiByteToWideChar : "The function returns 0 if it does not succeed" and lists a few failure cases.
>> However we miss checking the failure case in Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation , seems we assume the function always works nicely (in most of the JDK coding the return value is checked ).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust added return syntax

Hi , thanks for the reviews !

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

PR: https://git.openjdk.org/jdk/pull/10015


From mbaesken at openjdk.org  Mon Sep 12 06:45:08 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 12 Sep 2022 06:45:08 GMT
Subject: Integrated: JDK-8292866:
 Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation check MultiByteToWideChar
 return value for failures
In-Reply-To: <prlZNHespV4sJHeN-XKbLbDg5MIXWigO8OS5F03Fcy8=.186655cf-7fc6-41c0-aa6b-3602fae9ca01@github.com>
References: <prlZNHespV4sJHeN-XKbLbDg5MIXWigO8OS5F03Fcy8=.186655cf-7fc6-41c0-aa6b-3602fae9ca01@github.com>
Message-ID: <hbVYSn3k0rLsiCaZ0vN9PY-sNjrAYSB_KPcrkpQCaCQ=.4d7d7dda-7401-4040-b0a7-31298ac20646@github.com>

On Thu, 25 Aug 2022 08:02:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
> states about MultiByteToWideChar : "The function returns 0 if it does not succeed" and lists a few failure cases.
> However we miss checking the failure case in Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation , seems we assume the function always works nicely (in most of the JDK coding the return value is checked ).

This pull request has now been integrated.

Changeset: 699c4296
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/699c42962eeaa6aa950ad86c2dd1f77316a1da3e
Stats:     10 lines in 1 file changed: 7 ins; 0 del; 3 mod

8292866: Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation check MultiByteToWideChar return value for failures

Reviewed-by: mdoerr, stuefe

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

PR: https://git.openjdk.org/jdk/pull/10015


From aivanov at openjdk.org  Mon Sep 12 10:47:07 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Sep 2022 10:47:07 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v27]
In-Reply-To: <eNhAVzUfQh4Jm9qe4CYUFH_tMVeaOW5Nit_9I-ZFO0M=.970bbf0d-6be1-412a-abd2-bb347c9ecd91@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <eNhAVzUfQh4Jm9qe4CYUFH_tMVeaOW5Nit_9I-ZFO0M=.970bbf0d-6be1-412a-abd2-bb347c9ecd91@github.com>
Message-ID: <W6DI1y7TN7C8o0tJFP12_S-EA1nVTTquCnivQ21ccrs=.2aba28a2-af6a-4abb-a9e3-85cf1b9f84c4@github.com>

On Fri, 9 Sep 2022 17:24:17 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fix

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/sun/swing/FilePane.java line 59:

> 57: import java.io.FileNotFoundException;
> 58: import java.text.DateFormat;
> 59: import java.text.DecimalFormat;

`DecimalFormat` has become unused.

src/java.desktop/share/classes/sun/swing/FilePane.java line 1212:

> 1210:                 if (listViewWindowsStyle) {
> 1211:                     updateMessageFormatPattern(kiloByteString);
> 1212:                     displayedFileSize[0] = roundToOneDecimalPlace(len);

Does it correctly display the file sizes when `listViewWindowsStyle` is `true`?

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

PR: https://git.openjdk.org/jdk/pull/9327


From aivanov at openjdk.org  Mon Sep 12 10:57:59 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Sep 2022 10:57:59 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v27]
In-Reply-To: <eNhAVzUfQh4Jm9qe4CYUFH_tMVeaOW5Nit_9I-ZFO0M=.970bbf0d-6be1-412a-abd2-bb347c9ecd91@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <eNhAVzUfQh4Jm9qe4CYUFH_tMVeaOW5Nit_9I-ZFO0M=.970bbf0d-6be1-412a-abd2-bb347c9ecd91@github.com>
Message-ID: <N6zQqJcSndDXR1do1pxMR_wf66CZHR91U9-piVGBGtg=.7729591b-0ea1-4fa1-8fc1-43f3e59bc8f1@github.com>

On Fri, 9 Sep 2022 17:24:17 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments fix

With lots of comments, it has become hard to see the changes in the code.

The updated code in `FilePane.java`:

* [File size formatting](https://github.com/openjdk/jdk/blob/99224c1c9c82aa2882f001cfd5bf9597c871b4b3/src/java.desktop/share/classes/sun/swing/FilePane.java#L1198-L1231)
* Helper method [`updateMessageFormatPattern`](https://github.com/openjdk/jdk/blob/99224c1c9c82aa2882f001cfd5bf9597c871b4b3/src/java.desktop/share/classes/sun/swing/FilePane.java#L1245-L1248)
* Helper method [`roundToOneDecimalPlace`](https://github.com/openjdk/jdk/blob/99224c1c9c82aa2882f001cfd5bf9597c871b4b3/src/java.desktop/share/classes/sun/swing/FilePane.java#L1258-L1260)

The links above are anchored to Abhishek's latest commit: [99224c1](https://github.com/openjdk/jdk/pull/9327/commits/99224c1c9c82aa2882f001cfd5bf9597c871b4b3) on Sep 9.

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

PR: https://git.openjdk.org/jdk/pull/9327


From aivanov at openjdk.org  Mon Sep 12 11:05:15 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Sep 2022 11:05:15 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v26]
In-Reply-To: <0qCFmGLsWZ9VO8hhO2S0ki-zUpqqBn--Ow7QZrbXW0k=.347077d5-f10d-4f25-a8dc-174d15e9f57a@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <QYaW5bTaDAzVkGYK11xiLSPLTSdIU6DiBrBR-dKCQOI=.2f3ab314-85a9-44d6-9526-1ad9d9f7056b@github.com>
 <i-40SOCdt6Zlk-UukGR9ZoII2KvYK5nuGox6hU7xycw=.61a284b4-7731-4f8b-b7d7-3aa10d8be802@github.com>
 <0qCFmGLsWZ9VO8hhO2S0ki-zUpqqBn--Ow7QZrbXW0k=.347077d5-f10d-4f25-a8dc-174d15e9f57a@github.com>
Message-ID: <TD9YEmgT5l_DjStGbjnNRm1UDEz_pMNo8oeHNIyfAfA=.90bd9a09-4aa1-40c0-8b7d-096f1966771c@github.com>

On Fri, 9 Sep 2022 08:11:56 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/swing/FilePane.java line 1277:
>> 
>>> 1275:             DecimalFormat df = new DecimalFormat("0.0");
>>> 1276:             double val = fileSize/baseFileSize;
>>> 1277:             return  Double.valueOf(df.format(val));
>> 
>> The new code to round up looks difficult to understand (I mean the addition of 99 and re-worked if-conditions). I liked the previous version better. The only thing required to introduce rounding up is updating `roundToOneDecimalPlace`:
>> 
>> 
>>         private static double roundToOneDecimalPlace(long fileSize) {
>>             return  Math.ceilDiv(fileSize, 100L) / 10.0d;
>>         }
>> 
>> 
>> [`Math.ceilDiv`](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/Math.html#ceilDiv(long,long)) is available since Java 18.
>> 
>> However, this code also works and is better suited for backporting:
>> 
>> 
>>         private static double roundToOneDecimalPlace(long fileSize) {
>>             return  Math.ceil(fileSize / 100.0d) / 10.0d;
>>         }
>> 
>> Note that the first division is also floating point.
>> 
>> With this implementation of `roundToOneDecimalPlace` and your code before the latest update which introduced `+99`, I get the expected size displayed in `JFileChooser`, that is rounded up if there's a non-zero remainder. Could you please verify that?
>
> I have checked with the suggested changes, it rounds up the value if the remainder is non-zero value.
> But for files >1000 bytes it doesn't return the file size similar to native file manager. 
> 
> FileChooser rounded up the values to next decimal precision.
> ![FC_FileSize_1](https://user-images.githubusercontent.com/107542245/189302260-f99d175a-133b-45ad-bdf0-52de06aacb7d.png)
> 
> File sizes are not rounding up in all cases in native file system. For e.g. 1150 bytes file size is is 1.1 KB whereas 1151 bytes file size is 1.2 KB.   
> ![Native_FIleSize](https://user-images.githubusercontent.com/107542245/189302284-55e48e72-c9c0-4abe-aa17-56190f2aeaee.png)
> 
> To keep it consistent with the native file system for larger files (>1000 bytes), I tried using DecimalFormat.

To clarify: Abhishek and I were discussing the approach, it's still *inconsistent* in the same way: the file size was rounded up if it's less than 1 KB, but rounded (down) if it's larger.

The native file manager in Ubuntu rounds the file size.

`JFileChooser` does not display bytes that's why we round up the size. To avoid confusion, the size displayed in `JFileChooser` is always rounded up as Phil @prrace suggested.

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

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Mon Sep 12 11:47:36 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 12 Sep 2022 11:47:36 GMT
Subject: RFR: 5074006: Swing JOptionPane shows </html> tag as a string
 after newline [v2]
In-Reply-To: <DWhqieaffzn6xk--zvJwqX4LVNFtVnuI-5rnfuFGTL0=.55ec4218-3188-4917-9233-cbce1562f3e2@github.com>
References: <DWhqieaffzn6xk--zvJwqX4LVNFtVnuI-5rnfuFGTL0=.55ec4218-3188-4917-9233-cbce1562f3e2@github.com>
Message-ID: <2BmZo0HFOMAvei4VnM5WPD_BoIauCM1nyhnuipD8oV0=.a4b8b627-6d68-4789-99b8-bdd09c8a9cf0@github.com>

> If JOptionPane's message contains both linefeed/cursor return and HTML tag ie, **<html\>" + "This is a test\n" + "</html\>**,
> then  "</html\>" will be shown in the JOptionPane dialog box because after every new line it creates a new messageComponent so the characters after the newline ie "</html\>"tag will be considered as a new JLabel string and displayed.
> 
> Fix is to ignore closing html tag if appearing after newline from the displayed string.

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

  Fix handling HTML message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10081/files
  - new: https://git.openjdk.org/jdk/pull/10081/files/deba74f3..2b00d425

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10081&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10081&range=00-01

  Stats: 93 lines in 1 file changed: 50 ins; 35 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10081.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10081/head:pull/10081

PR: https://git.openjdk.org/jdk/pull/10081


From psadhukhan at openjdk.org  Mon Sep 12 11:57:20 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 12 Sep 2022 11:57:20 GMT
Subject: RFR: 6529151: NullPointerException in
 swing.plaf.synth.SynthLookAndFeel$Handler [v3]
In-Reply-To: <LNDDuM1Xo2waUauHyNK8iyw6y9cRGnawCO0ZbkVAIm4=.b2b2e136-5728-4734-b060-e61caa21f6c3@github.com>
References: <LNDDuM1Xo2waUauHyNK8iyw6y9cRGnawCO0ZbkVAIm4=.b2b2e136-5728-4734-b060-e61caa21f6c3@github.com>
Message-ID: <yvj-n7cm11YVfCLxvKlZpqHxKmpz2mF0H76pzDxushs=.fdf5dcc9-40ac-447f-9694-f67f349746cd@github.com>

> NPE is thrown for closed/disposed JDialogs after uninstalling the UI which is because for SynthEditorPaneUI even though is disposed of, Nimbus propertyHandler tries to get the style of this disposed component resulting in NPE, 
> which is fixed by a null check to prevent deferencing style object to get the color.

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

  Test made headful

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10167/files
  - new: https://git.openjdk.org/jdk/pull/10167/files/f62d58b9..8c378448

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10167&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10167&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/10167


From psadhukhan at openjdk.org  Mon Sep 12 11:58:52 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 12 Sep 2022 11:58:52 GMT
Subject: Integrated: 6529151: NullPointerException in
 swing.plaf.synth.SynthLookAndFeel$Handler
In-Reply-To: <LNDDuM1Xo2waUauHyNK8iyw6y9cRGnawCO0ZbkVAIm4=.b2b2e136-5728-4734-b060-e61caa21f6c3@github.com>
References: <LNDDuM1Xo2waUauHyNK8iyw6y9cRGnawCO0ZbkVAIm4=.b2b2e136-5728-4734-b060-e61caa21f6c3@github.com>
Message-ID: <XYg_NQStDrZ5F3OzM5WpW-fEd7927T-KqrIeYsj8mzU=.475b967c-0271-4716-bc45-4be687f67bdd@github.com>

On Mon, 5 Sep 2022 12:45:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> NPE is thrown for closed/disposed JDialogs after uninstalling the UI which is because for SynthEditorPaneUI even though is disposed of, Nimbus propertyHandler tries to get the style of this disposed component resulting in NPE, 
> which is fixed by a null check to prevent deferencing style object to get the color.

This pull request has now been integrated.

Changeset: 4c77bd32
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4c77bd32a0d2cfbdd15e58a9b48f6952d52e7156
Stats:     127 lines in 2 files changed: 127 ins; 0 del; 0 mod

6529151: NullPointerException in swing.plaf.synth.SynthLookAndFeel$Handler

Reviewed-by: serb, dnguyen

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

PR: https://git.openjdk.org/jdk/pull/10167


From aivanov at openjdk.org  Mon Sep 12 15:45:43 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Sep 2022 15:45:43 GMT
Subject: RFR: 8292738 : JInternalFrame backgroundShadowBorder &
 foregroundShadowBorder line is longer in Mac Look and Feel
In-Reply-To: <X5vBs9CaLJoEiIfONbCx0cwTdHuGIC5mrcEP30AOE48=.f605d66a-e387-4d5f-ba42-a7102f00939f@github.com>
References: <X5vBs9CaLJoEiIfONbCx0cwTdHuGIC5mrcEP30AOE48=.f605d66a-e387-4d5f-ba42-a7102f00939f@github.com>
Message-ID: <iaEHEjqippglirVZxLrob1c0emqVwtIbHDy6R81lClY=.969579d5-85d5-49b5-b54c-5b72053378a9@github.com>

On Mon, 22 Aug 2022 21:20:54 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> Border line is seen outside  round Rectangle both for JInternalFrame backgroundShadowBorder & foregroundShadowBorder line in mac L&F.
> ![Screen Shot 2022-08-22 at 4 17 49 PM](https://user-images.githubusercontent.com/87324768/186021010-d21aed21-9e05-4b28-846b-2628e367f183.png)
> 
> I have circled the extra part of the line. To make it more visible I changed the color of the backgroundShadowBorder to red
> ![Screen Shot 2022-08-22 at 4 17 37 PM](https://user-images.githubusercontent.com/87324768/186021095-cbfffdba-d43a-47e7-a50b-551c59cb767b.png)
> 
> Fixed the extra length of the line 
> ![Fixed](https://user-images.githubusercontent.com/87324768/186021195-688c3613-fc50-41c3-8cad-94173385dfeb.png)

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9971


From duke at openjdk.org  Mon Sep 12 15:54:53 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Mon, 12 Sep 2022 15:54:53 GMT
Subject: Integrated: 8292738 : JInternalFrame backgroundShadowBorder &
 foregroundShadowBorder line is longer in Mac Look and Feel
In-Reply-To: <X5vBs9CaLJoEiIfONbCx0cwTdHuGIC5mrcEP30AOE48=.f605d66a-e387-4d5f-ba42-a7102f00939f@github.com>
References: <X5vBs9CaLJoEiIfONbCx0cwTdHuGIC5mrcEP30AOE48=.f605d66a-e387-4d5f-ba42-a7102f00939f@github.com>
Message-ID: <n_1eOEXe0c-Rmgbw1AKmKqBdt27pHqzMHNH1VPEEGUo=.4764a41f-eace-41e2-aa6e-33b2ab27a215@github.com>

On Mon, 22 Aug 2022 21:20:54 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> Border line is seen outside  round Rectangle both for JInternalFrame backgroundShadowBorder & foregroundShadowBorder line in mac L&F.
> ![Screen Shot 2022-08-22 at 4 17 49 PM](https://user-images.githubusercontent.com/87324768/186021010-d21aed21-9e05-4b28-846b-2628e367f183.png)
> 
> I have circled the extra part of the line. To make it more visible I changed the color of the backgroundShadowBorder to red
> ![Screen Shot 2022-08-22 at 4 17 37 PM](https://user-images.githubusercontent.com/87324768/186021095-cbfffdba-d43a-47e7-a50b-551c59cb767b.png)
> 
> Fixed the extra length of the line 
> ![Fixed](https://user-images.githubusercontent.com/87324768/186021195-688c3613-fc50-41c3-8cad-94173385dfeb.png)

This pull request has now been integrated.

Changeset: cea409cc
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cea409cc2822ccdc9cbf6df04d46742e3c73b0fe
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8292738: JInternalFrame backgroundShadowBorder & foregroundShadowBorder line is longer in Mac Look and Feel

Reviewed-by: serb, aivanov

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

PR: https://git.openjdk.org/jdk/pull/9971


From aivanov at openjdk.org  Mon Sep 12 19:52:49 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Sep 2022 19:52:49 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v14]
In-Reply-To: <qYgDumzox1SUYZyeXVodYu5T6vY4J1X82MDxpvVpaOI=.2482dd87-4f58-4737-930c-b6f1364cee85@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <qYgDumzox1SUYZyeXVodYu5T6vY4J1X82MDxpvVpaOI=.2482dd87-4f58-4737-930c-b6f1364cee85@github.com>
Message-ID: <0aVa8Lbf6gm9jrbAqC_uzqr0HeMwMZIN7KW8fY6KQEQ=.8a320dc0-ce8e-4c95-9c24-55bc93d09882@github.com>

On Sat, 10 Sep 2022 13:37:57 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Error in comment.
>   
>   Sync. comment with code : "fails ... if stringToColor(null) doesn't return null".

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 133:

> 131:  * @author  Timothy Prinzing
> 132:  * @author  Scott Violet
> 133:  * @author  Guy Abossolo Foh - ScientificWare

New author tags aren't added.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1419:

> 1417:     }
> 1418: 
> 1419:     private static Map<String, Color> colorNamed =

It should also be declared `final`.

The field should be either `colorNames` or `namedColors`. You meant the former?

test/jdk/javax/swing/text/html/CSS/JDK8292276MissingColorNamesInCSS/JDK8292276MissingColorNamesInCSS.java line 31:

> 29:  * @summary Missing Color Names in CSS
> 30:  * @run main JDK8292276MissingColorNamesInCSS
> 31:  * @author Guy Abossolo Foh - ScientificWare

Author tags aren't added any more, existing ones are usually removed from tests when modified.

test/jdk/javax/swing/text/html/CSS/JDK8292276MissingColorNamesInCSS/JDK8292276MissingColorNamesInCSS.java line 44:

> 42: import static javax.swing.text.html.CSS.Attribute.BORDER_RIGHT_COLOR;
> 43: 
> 44: public class JDK8292276MissingColorNamesInCSS {

The class name can be shortened: `MissingColorNames`. It should placed in `CSS` folder or add to `ColorValue` folder.

test/jdk/javax/swing/text/html/CSS/JDK8292276MissingColorNamesInCSS/JDK8292276MissingColorNamesInCSS.java line 77:

> 75:         color = attributeSet.getAttribute(COLOR);
> 76:         bdleftcolor = attributeSet.getAttribute(BORDER_LEFT_COLOR);
> 77:         bdrightcolor = attributeSet.getAttribute(BORDER_RIGHT_COLOR);

Declare the variables where they're used for the first time, `attributeSet` is also included.

Use camelCase for readability of `leftColor` and `rightColor`.

test/jdk/javax/swing/text/html/CSS/JDK8292276MissingColorNamesInCSS/JDK8292276MissingColorNamesInCSS.java line 79:

> 77:         bdrightcolor = attributeSet.getAttribute(BORDER_RIGHT_COLOR);
> 78: 
> 79:         if(styleSheet.stringToColor(null) != null){

Suggestion:

        if (styleSheet.stringToColor(null) != null){

Space is missing.

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

PR: https://git.openjdk.org/jdk/pull/9825


From aivanov at openjdk.org  Mon Sep 12 19:52:50 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 12 Sep 2022 19:52:50 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v10]
In-Reply-To: <tAzm0oiaFOUQ9ZyzUbjbuxTzAg87XU9oVX1-yT0BXHQ=.a1263983-74a5-4f04-a406-7bec51b613e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <3K40K0Roy0-H5dqJr4TqChwOOCRbEQYnsezkiKe3gEw=.6a48b650-6421-4b32-abc9-f1543b554ac9@github.com>
 <Ihkbvib2yyDV811hGaHSqrsbb1sjFPUQZK3PeE3yg0Q=.ca018f86-e100-4549-982f-1f70d46d5dac@github.com>
 <6TqA6trYJCQmj_UnMJU5YZYGJvEiIP2h5GGpA3TZ3VI=.15d7a51d-6ca0-4f05-a02b-7eb15bdceae5@github.com>
 <PtQnn_uBr02qFCeSty5w4k9_thCaWVt18TIiJvzBaiA=.7c9980c9-0e46-4f0e-bb01-497999388e23@github.com>
 <2q3e4KHR1d_Oit9Byhd3qWwstuG5yPJjB6pSvsYGEQE=.159a981c-7259-444c-be0d-f032dddebf87@github.com>
 <tAzm0oiaFOUQ9ZyzUbjbuxTzAg87XU9oVX1-yT0BXHQ=.a1263983-74a5-4f04-a406-7bec51b613e9@github.com>
Message-ID: <uB-hDEwdu1mVgTxsrZQR__NOyvhq3Icxp_XezuK0vLc=.ec8c2119-2d48-4019-b68d-7e55bc1acd5e@github.com>

On Sat, 3 Sep 2022 23:40:02 GMT, SWinxy <duke at openjdk.org> wrote:

>> @SWinxy,
>> - if you're suggesting this
>>   ```
>>   } else {
>>               return colorNamed.get(strlc);
>>   ```
>>   We change the behavior (your comment) and lose the last test (color hex coded but without # prefix).
>> - or if you have in mind 
>> 
>>         } else {
>>                 return new Color(colorNamed.get(strlc).color.getRGB(), true);
>> 
>> We preserve the behavior but still lose the last test (color hex coded but without # prefix).
>> - The way I interpreted @prrace comment :
>>   ```
>>           } else {
>>               Color color = colorNamed.get(strlc);
>>               if (color != null) {
>>                   return color;
>>   ```
>>   We change the behavior :
>>   - In the code before this PR. The results were : null, Color.Black if "", and new Color Object for all other colors (the 10 named colors and all hex coded colors).
>>   - In the first implementation achieved in this PR, like the code above, results changed to : null, Color.Black if "", the same Object for each (149) named-color or hex coded color.
>>   - After your comment, results became : null, Color.Black if "", and new Color Object for all other Color (149 named or hex coded).
>
> Mmm I completely forgot that we're using the map here, and for that we'll need to create a `new Color` from it. My b. There could be a check to `colorNames.has(str)` and return the `new Color(colorNames.get(str))` since there will never be a `null` returned for a valid key.

The old code didn't have any cache, it simply returned a color. Now that the colors are in a map, return the `Color` instance from the map if there's one.

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

PR: https://git.openjdk.org/jdk/pull/9825


From serb at openjdk.org  Tue Sep 13 03:01:48 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 Sep 2022 03:01:48 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v3]
In-Reply-To: <1Y0OKsbNSaopRmrW3VQF8rh6RrClWmjbycO4qgfIY7I=.34c463c5-ccec-4bb5-981b-23e2a5bbab24@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>
 <OKwiyluDGrJJzJjqurX6vA4apF1Dz-v39QJlk8s7vGA=.189ba8bb-9d6f-4ea7-b399-801a857981b9@github.com>
 <U8w2BKrB9bFKrDtUkEM19LFr66BrhIbCjqtqUY_59n4=.46d7d53b-d1f4-40c7-a4f9-c8be44140ed6@github.com>
 <8_EXfD0W-aphoJsroB4e0r8hsMrcxpfATTWDGHXP_Es=.c22772e4-447a-48b2-b5de-1918059670f2@github.com>
 <-qOkFQnlLYWH_LFc0JpgxLICPgTG1mtzXG7xrnRppns=.cf90f4bc-bec9-4f99-aa5c-ee867c585f95@github.com>
 <1Y0OKsbNSaopRmrW3VQF8rh6RrClWmjbycO4qgfIY7I=.34c463c5-ccec-4bb5-981b-23e2a5bbab24@github.com>
Message-ID: <kNaivUIpR-df4L93gfTtCzu_sbW-pnhFrvytIt272KA=.c6ba15de-a70a-4e8e-8225-2b5c5519614c@github.com>

On Fri, 9 Sep 2022 04:35:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It will have the problem as you mentioned so I did it as it is. Since we have already UIDefaults table defined, I think it can be used for this, without changing the doc which might cause compatibility issues.
>
> it will also probably need change in compiler as to how it generates/parses the type as I am getting
> 
> Exception in thread "main" java.lang.NullPointerException: Cannot invoke "build.tools.generatenimbus.UIProperty$PropertyType.ordinal()" because "this.type" is null
> 	at build.tools.generatenimbus.UIProperty.write(UIProperty.java:87)
> 	at build.tools.generatenimbus.UIStyle.write(UIStyle.java:156)
> 	at build.tools.generatenimbus.UIRegion.write(UIRegion.java:213)
> 	at build.tools.generatenimbus.SynthModel.write(SynthModel.java:102)
> 	at build.tools.generatenimbus.Generator.generate(Generator.java:212)
> 	at build.tools.generatenimbus.Generator.main(Generator.java:118)
> 
> so I think this is the safer and cleaner alternative as I am not creating a new UIDefaults table, just adding a new entry to it..

It is probably simpler but we already store all tha properties in the generated NimbusDefaults, I do not think we should split the storage in two parts.

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

PR: https://git.openjdk.org/jdk/pull/10035


From serb at openjdk.org  Tue Sep 13 03:02:46 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 Sep 2022 03:02:46 GMT
Subject: RFR: 7148092: [macosx] When Alt+down arrow key is pressed,
 the combobox popup does not appear. [v5]
In-Reply-To: <03fLl5XUqUXveKPvSjtrRXjx7epMGAVeYgdhECk1iB4=.ca933754-196a-443b-b004-ce4393e62379@github.com>
References: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
 <03fLl5XUqUXveKPvSjtrRXjx7epMGAVeYgdhECk1iB4=.ca933754-196a-443b-b004-ce4393e62379@github.com>
Message-ID: <wyTZIyVAtF-bomv6YKJsl4yAOV2nZJ7LTs2Bzw93FLA=.fb0ae6b1-a3be-4882-9e83-e1e9766f7d4e@github.com>

On Fri, 9 Sep 2022 09:34:02 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When comboBox have focus, pressing Alt+Down (or Up) should render the popup which is not happening for Aqua L&F.
>> 
>> Fix is to add toggleAction for Alt+Down/Up keys as has been done for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L912)
>> 
>> closed problemlisted test is used to check the fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10014


From serb at openjdk.org  Tue Sep 13 03:06:42 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 Sep 2022 03:06:42 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v2]
In-Reply-To: <VIoRxdYnxXyLcWgaeR8nIXS4OH2KU86KDTLIK6V7cv8=.a425eff7-976f-4e8d-8e01-80a9ebdf06c6@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
 <VIoRxdYnxXyLcWgaeR8nIXS4OH2KU86KDTLIK6V7cv8=.a425eff7-976f-4e8d-8e01-80a9ebdf06c6@github.com>
Message-ID: <ql8Lgrbr58dokyfADBm9tND6LLdwQiIyLyC8V50EZDw=.b2c75707-aa7b-4608-9c7f-31f1a4bdef68@github.com>

On Wed, 24 Aug 2022 04:43:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Label.foreground UIProperty is not honored by Nimbus L&F.
>> Added support for setting JLabel foreground color for Nimbus L&F
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLabelUI.java line 220:

> 218:             Color col = UIManager.getColor("Label.foreground");
> 219:             if (col != null) {
> 220:                 label.setForeground(col);

Are you sure that the text color of the label should be changed on each repain?

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

PR: https://git.openjdk.org/jdk/pull/9900


From tr at openjdk.org  Tue Sep 13 04:56:48 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 13 Sep 2022 04:56:48 GMT
Subject: Integrated: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click
In-Reply-To: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
References: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>
Message-ID: <aFe6d4aBNQNXqgNLzaSX0zz8jPUHn-6DZvRIGMWLEoE=.3b872663-c651-4359-9273-280cd3ae4067@github.com>

On Wed, 24 Aug 2022 07:44:52 GMT, Tejesh R <tr at openjdk.org> wrote:

> JFileChooser.getSelectedFiles() failed to retrieve files with multi-selection and double-click. This occurs when a single file is selected then enable multi-selection then select the same file through mouse double-click(Two file chooser dialogs used before and after multi-selection enabled). SelectedFiles are updated when a change in files/directory selection is done or when selection is made through keyboard selection. In this case since a single file is selected before multi-selection is enabled and same file is selected again without changing the selection index/directory, leaving selected Files un-updated. 
> **Proposed Fix** : Whenever Multi-Selection is enabled check if any files are selected, if yes update the selected Files of JFileChoooser.

This pull request has now been integrated.

Changeset: 9cd3e355
Author:    Tejesh R <tr at openjdk.org>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9cd3e355d1f5216626daa6a9669b0c95343ca4f0
Stats:     95 lines in 2 files changed: 93 ins; 1 del; 1 mod

4834298: JFileChooser.getSelectedFiles() failed with multi-selection and double-click

Reviewed-by: jdv

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

PR: https://git.openjdk.org/jdk/pull/9996


From psadhukhan at openjdk.org  Tue Sep 13 07:49:38 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 13 Sep 2022 07:49:38 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v3]
In-Reply-To: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
Message-ID: <4VvhgKSAGDnjWdmTfvaNCcTsSmOmCQR8UsYNOSmRO5w=.be1165bd-2d1f-44bc-8027-3ae9923617ce@github.com>

> Label.foreground UIProperty is not honored by Nimbus L&F.
> Added support for setting JLabel foreground color for Nimbus L&F

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

  Get color once during init

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9900/files
  - new: https://git.openjdk.org/jdk/pull/9900/files/e6de6d08..b6d0a8bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9900&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9900&range=01-02

  Stats: 9 lines in 2 files changed: 4 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9900.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9900/head:pull/9900

PR: https://git.openjdk.org/jdk/pull/9900


From martin.desruisseaux at geomatys.com  Tue Sep 13 09:53:37 2022
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Tue, 13 Sep 2022 11:53:37 +0200
Subject: Misleading message when using Image I/O for write operations
Message-ID: <87caf995-97f8-d816-821a-66a2d79fc237@geomatys.com>

Hello all

The ImageIO class contains the following method (copying only relevant 
parts). The key point to notice is that any IOException is assumed to be 
a problem with the cache file, never with the main output stream:


    /**
      * ?snip?
      * @return an {@code ImageOutputStream}, or {@code null}.
      * ?snip?
      * @exception IOException if a cache file is needed but cannot be created.
      */
    public static ImageOutputStream createImageOutputStream(Object output) throws IOException {
         // ?snip?
         try {
             return spi.createOutputStreamInstance(output,
                                                   usecache,
                                                   getCacheDirectory());
         } catch (IOException e) {
             throw new IIOException("Can't create cache file!", e);
         }
         // ?snip?
         return null;
    }


In the particular case where the output is a java.io.File, the SPI 
implementation is as below (augmented with a copy of the Javadoc from 
public API). Note that the javadoc does not mention that 
ImageOutputStreamSpi.createOutputStreamInstance(?) may return null.


    /**
      * ?snip?
      * @return an {@code ImageOutputStream} instance.
      * ?snip?
      * @exception IOException if a cache file is needed but cannot be created.
      */
    public ImageOutputStream createOutputStreamInstance(?snip?) throws IOException {
         // ?snip?
         try {
             return new FileImageOutputStream((File)output);
         } catch (Exception e) {
             e.printStackTrace();
             return null;
         }
         // ?snip?
    }


In case of failure to create the output stream, ImageIO.write(?) throws 
an exception with the "Can't create an ImageOutputStream!" message, but 
we don't know why. The cause (for example no space left on device) is 
hidden in the System.err outputs. If we replace the 
com.sun.imageio.spi.FileImageOutputStreamSpi implementation by our own 
provider propagating the IOException instead of returning null, it is 
slightly better but the exception is caught by 
ImageIO.createImageOutputStream and rethrown with the misleading "Can't 
create cache file!" message. The consequence is that when writing 
millions of images (e.g. Earth Observation data) and the process fails 
somewhere at ImageOutputStream creation time, it is currently difficult 
to identify the cause.

Possible actions for improving the situation could be (from less 
disruptive to most disruptive):

  * Replace the e.printStackTrace() call by the use of logger.
  * Remove the try ? catch block in ImageIO.createImageOutputStream(?),
    so if an SPI choose to throw IOException (at the cost of violating
    current Image I/O contract), ImageIO does not misleadingly said that
    it is a problem with the cache.
  * Modify ImageIO.createImageOutputStream(?) contract by saying that
    IOException may be thrown because of failure to create the main
    output stream, not only because of failure to create the cache file.
    Adapt FileImageOutputStreamSpi implementation accordingly.

Is there any thought about what would be reasonable, what would be too 
much disruption?

 ??? Regards,

 ??? ??? Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220913/73871112/attachment.htm>

From alanb at openjdk.org  Tue Sep 13 13:17:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Sep 2022 13:17:34 GMT
Subject: RFR: 8289610: Degrade Thread.stop
Message-ID: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>

Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.

Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.

To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.

The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

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

Commit messages:
 - Deprecate for removal
 - Next iteration, update dates in headers
 - Merge
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/10230/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289610
  Stats: 311 lines in 23 files changed: 114 ins; 147 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/10230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10230/head:pull/10230

PR: https://git.openjdk.org/jdk/pull/10230


From duke at openjdk.org  Tue Sep 13 13:17:35 2022
From: duke at openjdk.org (ExE Boss)
Date: Tue, 13 Sep 2022 13:17:35 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <R3vbwdphf7LyGlOStrdg-vizkYQ6WooThta7Utu_ntE=.39121758-eff2-4992-aaad-875e1fdfcfae@github.com>

On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

src/java.base/share/classes/java/lang/ThreadDeath.java line 42:

> 40:  */
> 41: @Deprecated(since="20")
> 42: public class ThreadDeath extends Error {

Actually, `ThreadDeath` is?thrown?manually by?**JShell** instrumentation?code since?[JDK?8289613] ([GH?10166])[^1].

[JDK?8289613]: https://bugs.openjdk.org/browse/JDK-8289613
[GH?10166]: https://github.com/openjdk/jdk/pull/10166
[^1]: https://github.com/openjdk/jdk/blob/00befddd7ce97d324250807824469daaa9434eef/src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java#L104-L107

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

PR: https://git.openjdk.org/jdk/pull/10230


From duke at openjdk.org  Tue Sep 13 13:45:46 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 13 Sep 2022 13:45:46 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v28]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <itQkJngjXpuUQYlgAyQ1WNTyNQ2PoGsbQtVMalUFR40=.bb0cffdb-42cc-4383-83ba-9ddbb58d4d4e@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 KB.
> Manual Test Case "FileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Review comment fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/99224c1c..3d6ae268

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=26-27

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Tue Sep 13 13:45:50 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 13 Sep 2022 13:45:50 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v27]
In-Reply-To: <W6DI1y7TN7C8o0tJFP12_S-EA1nVTTquCnivQ21ccrs=.2aba28a2-af6a-4abb-a9e3-85cf1b9f84c4@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <eNhAVzUfQh4Jm9qe4CYUFH_tMVeaOW5Nit_9I-ZFO0M=.970bbf0d-6be1-412a-abd2-bb347c9ecd91@github.com>
 <W6DI1y7TN7C8o0tJFP12_S-EA1nVTTquCnivQ21ccrs=.2aba28a2-af6a-4abb-a9e3-85cf1b9f84c4@github.com>
Message-ID: <hUddUVdwvHNUxjZAYWiF2JMjQDMOJ2jEHpgK2VNfzos=.fcfb8841-1042-4948-b097-792fe9362522@github.com>

On Mon, 12 Sep 2022 10:40:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments fix
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 59:
> 
>> 57: import java.io.FileNotFoundException;
>> 58: import java.text.DateFormat;
>> 59: import java.text.DecimalFormat;
> 
> `DecimalFormat` has become unused.

Updated.

> src/java.desktop/share/classes/sun/swing/FilePane.java line 1212:
> 
>> 1210:                 if (listViewWindowsStyle) {
>> 1211:                     updateMessageFormatPattern(kiloByteString);
>> 1212:                     displayedFileSize[0] = roundToOneDecimalPlace(len);
> 
> Does it correctly display the file sizes when `listViewWindowsStyle` is `true`?

Yeah, it will show file size is KB.

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

PR: https://git.openjdk.org/jdk/pull/9327


From rriggs at openjdk.org  Tue Sep 13 14:12:48 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Sep 2022 14:12:48 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <aJKDQu_rOWDcc8-F2LXmygH9d-QBKSd5NOEAlUVI7lQ=.6235cad5-1193-4bc6-89ff-edbf75be21db@github.com>

On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

core-libs parts look fine.

src/java.base/share/classes/java/lang/Thread.java line 1635:

> 1633:      *
> 1634:      * @throws  UnsupportedOperationException
> 1635:      *          always

fold with previous line.

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

PR: https://git.openjdk.org/jdk/pull/10230


From aivanov at openjdk.org  Tue Sep 13 14:58:01 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 13 Sep 2022 14:58:01 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v28]
In-Reply-To: <itQkJngjXpuUQYlgAyQ1WNTyNQ2PoGsbQtVMalUFR40=.bb0cffdb-42cc-4383-83ba-9ddbb58d4d4e@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <itQkJngjXpuUQYlgAyQ1WNTyNQ2PoGsbQtVMalUFR40=.bb0cffdb-42cc-4383-83ba-9ddbb58d4d4e@github.com>
Message-ID: <ADBbdJRm06dM_FnT5e7P6HLAzMcC8IMZq70Fd2E3emI=.ced7f590-8483-4ee7-a6e8-f77ce02d44da@github.com>

On Tue, 13 Sep 2022 13:45:46 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

Looks good.

Thank you for adding the test case which proves the file size is rounded up.

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

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Tue Sep 13 14:59:50 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 13 Sep 2022 14:59:50 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v3]
In-Reply-To: <kNaivUIpR-df4L93gfTtCzu_sbW-pnhFrvytIt272KA=.c6ba15de-a70a-4e8e-8225-2b5c5519614c@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>
 <OKwiyluDGrJJzJjqurX6vA4apF1Dz-v39QJlk8s7vGA=.189ba8bb-9d6f-4ea7-b399-801a857981b9@github.com>
 <U8w2BKrB9bFKrDtUkEM19LFr66BrhIbCjqtqUY_59n4=.46d7d53b-d1f4-40c7-a4f9-c8be44140ed6@github.com>
 <8_EXfD0W-aphoJsroB4e0r8hsMrcxpfATTWDGHXP_Es=.c22772e4-447a-48b2-b5de-1918059670f2@github.com>
 <-qOkFQnlLYWH_LFc0JpgxLICPgTG1mtzXG7xrnRppns=.cf90f4bc-bec9-4f99-aa5c-ee867c585f95@github.com>
 <1Y0OKsbNSaopRmrW3VQF8rh6RrClWmjbycO4qgfIY7I=.34c463c5-ccec-4bb5-981b-23e2a5bbab24@github.com>
 <kNaivUIpR-df4L93gfTtCzu_sbW-pnhFrvytIt272KA=.c6ba15de-a70a-4e8e-8225-2b5c5519614c@github.com>
Message-ID: <oMTCqSIOfus9EhEL_dlZTeZoEvbd-6nD2imC1URRq4w=.cc5fa2c6-6f54-477d-9e62-7a5f7f4451f5@github.com>

On Tue, 13 Sep 2022 02:58:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> it will also probably need change in compiler as to how it generates/parses the type as I am getting
>> 
>> Exception in thread "main" java.lang.NullPointerException: Cannot invoke "build.tools.generatenimbus.UIProperty$PropertyType.ordinal()" because "this.type" is null
>> 	at build.tools.generatenimbus.UIProperty.write(UIProperty.java:87)
>> 	at build.tools.generatenimbus.UIStyle.write(UIStyle.java:156)
>> 	at build.tools.generatenimbus.UIRegion.write(UIRegion.java:213)
>> 	at build.tools.generatenimbus.SynthModel.write(SynthModel.java:102)
>> 	at build.tools.generatenimbus.Generator.generate(Generator.java:212)
>> 	at build.tools.generatenimbus.Generator.main(Generator.java:118)
>> 
>> so I think this is the safer and cleaner alternative as I am not creating a new UIDefaults table, just adding a new entry to it..
>
> It is probably simpler but we already store all tha properties in the generated NimbusDefaults, I do not think we should split the storage in two parts.

Properties are **already** being stored in two parts so I am not inventing it for this fix. I am just adding an entry to the already created UIDefaults. Also, as I told, storing a character in skin.laf involves changing the generator tool which might not be scalable and prone to regressions, not to mention what/where should be changed in the tool for this is not known to me.

Also, as Synth is a skinnable look and feel, I think it would have been an issue if the property to be added affects "skin" in anyways, like **color, font, dimension** property etc, in which case it would have made sense to be mandatorily put in skin.laf which is the "visual designer"
 but this Password echo character property will not affect the skin in anyway, like the other properties added in UIDefaults table in SynthLookAndFeel, so I think it should be ok.

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

PR: https://git.openjdk.org/jdk/pull/10035


From duke at openjdk.org  Tue Sep 13 16:49:59 2022
From: duke at openjdk.org (ScientificWare)
Date: Tue, 13 Sep 2022 16:49:59 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v15]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <9Df7BTBxCYMa54kW4tC_z2FygYkoY1XRIQbzvl-tguU=.22519568-3e5c-413b-a085-649a4d4b623e@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

  Update test/jdk/javax/swing/text/html/CSS/JDK8292276MissingColorNamesInCSS/JDK8292276MissingColorNamesInCSS.java
  
  Missing space.
  
  Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/978ad292..e6d2ba81

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=13-14

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

PR: https://git.openjdk.org/jdk/pull/9825


From cjplummer at openjdk.org  Tue Sep 13 17:50:55 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 13 Sep 2022 17:50:55 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <8ZLJ1_MCq61Of0Jb2zUNFDskX7BYN1LFwGQ3JGSPcUQ=.f971b32e-491d-400d-bced-c13aabc30a0f@github.com>

On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

serviceability changes look good

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

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10230


From mullan at openjdk.org  Tue Sep 13 19:01:51 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 Sep 2022 19:01:51 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <FccBcuRP60nXHjvizhgiU_wr0QoD7vP6ZsJJYsdheLU=.0a392f5f-f3d7-4a28-9183-d1f6a8bfc29f@github.com>

On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

What about also removing and undocumenting `RuntimePermission("stopThread")` as part of this change?

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

PR: https://git.openjdk.org/jdk/pull/10230


From eosterlund at openjdk.org  Tue Sep 13 19:09:42 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 13 Sep 2022 19:09:42 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <NvkrIiKWBp863qr4zH4amdPEXgnWp64PdDnOjoab5Bs=.ac39b71a-f73b-442b-ad1e-978c186aa77f@github.com>

On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

There is a bunch of VM code for this too. Should we clean that up separately?

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

PR: https://git.openjdk.org/jdk/pull/10230


From alanb at openjdk.org  Tue Sep 13 19:17:45 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Sep 2022 19:17:45 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <NvkrIiKWBp863qr4zH4amdPEXgnWp64PdDnOjoab5Bs=.ac39b71a-f73b-442b-ad1e-978c186aa77f@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <NvkrIiKWBp863qr4zH4amdPEXgnWp64PdDnOjoab5Bs=.ac39b71a-f73b-442b-ad1e-978c186aa77f@github.com>
Message-ID: <yNN_3wT_cFTtm-ZmdtbtxVE0HiHT9HKcdVYe6eV_Gn4=.f5b40a33-284f-4577-bfa3-bf9ceaaa0ef4@github.com>

On Tue, 13 Sep 2022 19:06:14 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> There is a bunch of VM code for this too. Should we clean that up separately?

Yes chatted with @dholmes-ora about this recently and he suggested separating out so there is a follow-on JBS issue created for that. Aside from JVM_StopThread, I suspect code that deals with pending exceptions before a thread start can go away as the JVM TI StopThread can't cause an async exception on an unstarted thread. I'm hoping Thread.stillborn can go away too.

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

PR: https://git.openjdk.org/jdk/pull/10230


From eosterlund at openjdk.org  Tue Sep 13 19:17:46 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 13 Sep 2022 19:17:46 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <yNN_3wT_cFTtm-ZmdtbtxVE0HiHT9HKcdVYe6eV_Gn4=.f5b40a33-284f-4577-bfa3-bf9ceaaa0ef4@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <NvkrIiKWBp863qr4zH4amdPEXgnWp64PdDnOjoab5Bs=.ac39b71a-f73b-442b-ad1e-978c186aa77f@github.com>
 <yNN_3wT_cFTtm-ZmdtbtxVE0HiHT9HKcdVYe6eV_Gn4=.f5b40a33-284f-4577-bfa3-bf9ceaaa0ef4@github.com>
Message-ID: <o-0jNj4vm7C4U-FuAnD5XzemL-oal-x-flVVPk-oyow=.e35d8591-8312-4f5d-9068-1092f4112e29@github.com>

On Tue, 13 Sep 2022 19:12:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > There is a bunch of VM code for this too. Should we clean that up separately?
> 
> 
> 
> Yes chatted with @dholmes-ora about this recently and he suggested separating out so there is a follow-on JBS issue created for that. Aside from JVM_StopThread, I suspect code that deals with pending exceptions before a thread start can go away as the JVM TI StopThread can't cause an async exception on an unstarted thread. I'm hoping Thread.stillborn can go away too.

Sounds good.

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

PR: https://git.openjdk.org/jdk/pull/10230


From alanb at openjdk.org  Tue Sep 13 19:17:47 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Sep 2022 19:17:47 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <FccBcuRP60nXHjvizhgiU_wr0QoD7vP6ZsJJYsdheLU=.0a392f5f-f3d7-4a28-9183-d1f6a8bfc29f@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <FccBcuRP60nXHjvizhgiU_wr0QoD7vP6ZsJJYsdheLU=.0a392f5f-f3d7-4a28-9183-d1f6a8bfc29f@github.com>
Message-ID: <g0EEBLhi7sK7lvdB8ocA1pzZungwW5grIhxctMyaiQ0=.e70a7f68-a282-4926-a40d-81836c488270@github.com>

On Tue, 13 Sep 2022 18:57:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> What about also removing and undocumenting `RuntimePermission("stopThread")` as part of this change?

Ah yes, the table RuntimePermission can be updated as part of this (and the corresponding constant in sun/security/util/SecurityConstants).

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

PR: https://git.openjdk.org/jdk/pull/10230


From duke at openjdk.org  Tue Sep 13 19:51:59 2022
From: duke at openjdk.org (ScientificWare)
Date: Tue, 13 Sep 2022 19:51:59 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v16]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <lPtRR7pV8HsYN4iUAgmJryjAqQw3Igox1Aqb8VfNAvc=.2420b69e-ed7c-418a-b00b-9984401099ac@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

  Update and rename test/jdk/javax/swing/text/html/CSS/JDK8292276MissingColorNamesInCSS/JDK8292276MissingColorNamesInCSS.java to test/jdk/javax/swing/text/html/CSS/MissingColorNames.java
  
  Removes author tag.
  Renames this class.
  Moves the file to the CSS folder.
  Corrects some variable declarations.
  Renames some variables according Java usages.
  Corrects a typo.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/e6d2ba81..f89b6592

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=14-15

  Stats: 192 lines in 2 files changed: 93 ins; 99 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9825.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9825/head:pull/9825

PR: https://git.openjdk.org/jdk/pull/9825


From aivanov at openjdk.org  Tue Sep 13 20:07:53 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 13 Sep 2022 20:07:53 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v8]
In-Reply-To: <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
Message-ID: <j1nnUJONoEMCGF0W9fQK0krEPMTWgV-HCeG3VgbGTlo=.356e6da2-cab8-46cf-8dae-3020edda387e@github.com>

On Tue, 6 Sep 2022 12:42:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
> 
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes in libjpeg
>  - Revert changes in libfreetype
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 36 more: https://git.openjdk.org/jdk/compare/6a1e98cb...1ce28314

Is `src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c` a third-party code?

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 87:

> 85:         J2dTraceLn4(J2D_TRACE_VERBOSE,
> 86:                     "MTLLayer.blitTexture: uninitialized (mtlc=%p, javaLayer=%p, buffer=%p, device=%p)", self.ctx,
> 87:                     self.javaLayer, self.buffer, ctx.device);

Is this an intended change? Or does it come from a merge?

May I suggest wrapping the line after the format string before `self.ctx`? It would make it easier to read.

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

PR: https://git.openjdk.org/jdk/pull/8328


From ihse at openjdk.org  Tue Sep 13 21:26:53 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 13 Sep 2022 21:26:53 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v8]
In-Reply-To: <j1nnUJONoEMCGF0W9fQK0krEPMTWgV-HCeG3VgbGTlo=.356e6da2-cab8-46cf-8dae-3020edda387e@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
 <j1nnUJONoEMCGF0W9fQK0krEPMTWgV-HCeG3VgbGTlo=.356e6da2-cab8-46cf-8dae-3020edda387e@github.com>
Message-ID: <jaEuqSNdK7J2BuW691f5ik4M02JVqzKUldWQmw_M7-I=.9f127461-930f-4f6f-8bd8-8097014ac600@github.com>

On Tue, 13 Sep 2022 19:48:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
>> 
>>  - Merge branch 'master' into typos-in-java.desktop
>>  - Revert changes in libjpeg
>>  - Revert changes in libfreetype
>>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - ... and 36 more: https://git.openjdk.org/jdk/compare/6a1e98cb...1ce28314
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 87:
> 
>> 85:         J2dTraceLn4(J2D_TRACE_VERBOSE,
>> 86:                     "MTLLayer.blitTexture: uninitialized (mtlc=%p, javaLayer=%p, buffer=%p, device=%p)", self.ctx,
>> 87:                     self.javaLayer, self.buffer, ctx.device);
> 
> Is this an intended change? Or does it come from a merge?
> 
> May I suggest wrapping the line after the format string before `self.ctx`? It would make it easier to read.

This is from the merge. The only difference wrt to current code is "devide" => "device". I can change wrapping if you request it, but I'd prefer to only fix typos.

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

PR: https://git.openjdk.org/jdk/pull/8328


From ihse at openjdk.org  Tue Sep 13 21:30:43 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 13 Sep 2022 21:30:43 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v8]
In-Reply-To: <j1nnUJONoEMCGF0W9fQK0krEPMTWgV-HCeG3VgbGTlo=.356e6da2-cab8-46cf-8dae-3020edda387e@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
 <j1nnUJONoEMCGF0W9fQK0krEPMTWgV-HCeG3VgbGTlo=.356e6da2-cab8-46cf-8dae-3020edda387e@github.com>
Message-ID: <0dmtHVVEvfGWQ94u7xMbddzoHbESy3mV5Gh3vdDrh-A=.10ffa679-739f-457c-b77e-c8b26c36146d@github.com>

On Tue, 13 Sep 2022 20:04:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Is `src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c` a third-party code?

I don't think so. I find no comments in the source code, or any kind of indication on this being so. If you say it is, I can revert the changes in that file.

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

PR: https://git.openjdk.org/jdk/pull/8328


From ihse at openjdk.org  Tue Sep 13 21:36:10 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 13 Sep 2022 21:36:10 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v8]
In-Reply-To: <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
Message-ID: <ui8gSZ1FuatyMVWlOCAsBEaJjUVE6ufwhMvROIZQrFQ=.6e09c806-811c-44d8-a321-11b68afde29b@github.com>

On Tue, 6 Sep 2022 12:42:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
> 
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes in libjpeg
>  - Revert changes in libfreetype
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 36 more: https://git.openjdk.org/jdk/compare/6a1e98cb...1ce28314

I see now that Phil cryptically said:

> Regarding changes in gif + freetype
diff --git a/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c b/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c \
\
diff --git a/src/java.desktop/share/native/libfontmanager/freetypeScaler.c b/src/java.desktop/share/native/libfontmanager/freetypeScaler.c \
\
Please exclude ALL 3rd party libraries from this PR.

That might be interpreted as stating that `gifdecoder.c` is 3rd party source code (although that was by no means clear to me the first time I read it). I'll revert the changes in that file, and also `src/java.desktop/share/native/libfontmanager/freetypeScaler.c`.

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

PR: https://git.openjdk.org/jdk/pull/8328


From prr at openjdk.org  Tue Sep 13 22:05:46 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 13 Sep 2022 22:05:46 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v8]
In-Reply-To: <ui8gSZ1FuatyMVWlOCAsBEaJjUVE6ufwhMvROIZQrFQ=.6e09c806-811c-44d8-a321-11b68afde29b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
 <ui8gSZ1FuatyMVWlOCAsBEaJjUVE6ufwhMvROIZQrFQ=.6e09c806-811c-44d8-a321-11b68afde29b@github.com>
Message-ID: <alS4RnqiswWATvVIotbyYFGhRJDyO5_JCAU24l30HBs=.2fa01b63-f674-4c78-b7bc-798120cf9694@github.com>

On Tue, 13 Sep 2022 21:32:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I see now that Phil cryptically said:
> 
> > Regarding changes in gif + freetype
> > diff --git a/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c b/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c 
> > 
> > diff --git a/src/java.desktop/share/native/libfontmanager/freetypeScaler.c b/src/java.desktop/share/native/libfontmanager/freetypeScaler.c 
> > 
> > Please exclude ALL 3rd party libraries from this PR.
> 
> That might be interpreted as stating that `gifdecoder.c` is 3rd party source code (although that was by no means clear to me the first time I read it). I'll revert the changes in that file, and also `src/java.desktop/share/native/libfontmanager/freetypeScaler.c`.

I don't know why I mentioned those two files like that but those particular two are JDK code so are fair game.

I did write 
"Please exclude ALL 3rd party libraries from this PR."
and later :
"We need to revert the native code changes to "libfreetype".
and those points are correct.

You did fix the latter, but there are still some 3rd party files in there that are edited : glext.h, wsutils.h, multiVis.c

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

PR: https://git.openjdk.org/jdk/pull/8328


From mchung at openjdk.org  Tue Sep 13 23:54:31 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 13 Sep 2022 23:54:31 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <GUqUvGAgZaq3V6d7zLstLPcnDXJfC3Tn9nJ7FKCP4Is=.5d7a18f1-55fb-45f6-81e3-9a1372832d38@github.com>

On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

The change looks good.   There are other tests that reference `ThreadDeath` for example `test/lib/jdk/test/lib/process/ProcessTools.java`, `test/jdk/java/util/Timer/KillThread.java` , `test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/flow/support/NonFatal.java` etc.    Is it expected to update them in a follow-on issue?

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

PR: https://git.openjdk.org/jdk/pull/10230


From duke at openjdk.org  Wed Sep 14 03:51:40 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 14 Sep 2022 03:51:40 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v17]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <y5k25RAzsoK-qBbL-9tDK3U0aN4z7p1YN4eJYA618L4=.61b537f1-8d1d-46c7-9a64-da8bcc5279ea@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

  Author tag, Modifier, Returned value.
  
  Removes the last added author tag.
  Returns the Color instance from the map if there's one.
  Renames colorNamed Object to colorNames.
  Adds final modifier to colorNames.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/f89b6592..4b05b937

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=15-16

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

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Wed Sep 14 06:48:34 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 14 Sep 2022 06:48:34 GMT
Subject: RFR: 8292848: AWT_Mixing and TrayIcon tests fail on el8 with
 hard-coded isOel7
In-Reply-To: <ZJrPLHPk000YQPHb73cCqw1l7jP1vwRLEXMlOgrqVSs=.a599b437-a90f-4f81-8ca5-aa2809bde6f7@github.com>
References: <ZJrPLHPk000YQPHb73cCqw1l7jP1vwRLEXMlOgrqVSs=.a599b437-a90f-4f81-8ca5-aa2809bde6f7@github.com>
Message-ID: <4YHfZ-__ULHO7ChfKx9NcWl9fRADxAd74MdOB-eDcGU=.0a3582e2-8a1d-4398-b07b-803bebb3a9e7@github.com>

On Wed, 24 Aug 2022 07:06:15 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> Could you please review the JDK-8292848 bug fixes?
> The purpose of the isOel7 method is to detect differences in GNOME version changes, and the isOel7 
> result should be true after version 8.
> I modified the isOel7 method to use regular expressions instead of hard-coded versions to be able to 
> detect the new os version.
> I also changed the method name to match the new conditions.

Thank you for your support.

@mrserb 
If @prrace cannot be sponsor, could you sponsor this pull request, please?

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

PR: https://git.openjdk.org/jdk/pull/9995


From asotona at openjdk.org  Wed Sep 14 11:10:15 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Sep 2022 11:10:15 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v16]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <C_FYdM2XDe98ShJRXMXZq3m7kyt30HOhvleFxV8hK4E=.cbb2971e-a4de-4d51-af0a-5e6bc3628081@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le
 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - ... and 10 more: https://git.openjdk.org/jdk/compare/7f3250d7...4b78b1c5

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

Changes: https://git.openjdk.org/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=15
  Stats: 439 lines in 14 files changed: 437 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.org/jdk/pull/8599


From asotona at openjdk.org  Wed Sep 14 11:25:38 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Sep 2022 11:25:38 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v16]
In-Reply-To: <C_FYdM2XDe98ShJRXMXZq3m7kyt30HOhvleFxV8hK4E=.cbb2971e-a4de-4d51-af0a-5e6bc3628081@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <C_FYdM2XDe98ShJRXMXZq3m7kyt30HOhvleFxV8hK4E=.cbb2971e-a4de-4d51-af0a-5e6bc3628081@github.com>
Message-ID: <7HAZTQI9U8tr8hrc3uRhkeAnZU4yjyjVDhTB2vXd00E=.69ffd410-c37e-45ec-b812-69bf4a2782ea@github.com>

On Wed, 14 Sep 2022 11:10:15 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
>> 
>> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
>> 
>> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
>> 
>> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
>> 
>> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
>> 
>> Thanks for your review,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
>  - Added man-page line about lossy-conversion lint
>  - Merge branch 'openjdk:master' into JDK-8244681
>  - 8244681: Add a warning for possibly lossy conversion in compound assignments
>    re-enabled warnings for java.base, java.rmi and java.smartcardio
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/7f3250d7...4b78b1c5

Please review also linked Release Note issue.

Thanks,
Adam

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

PR: https://git.openjdk.org/jdk/pull/8599


From asotona at openjdk.org  Wed Sep 14 11:35:03 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Sep 2022 11:35:03 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v17]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <k9Qdyal0bxpvBIXY0gfBLch7SG9PO7LjV5zNhQumCWQ=.34d833b1-fe0d-481b-bb40-59b154689842@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  re-enabled lossy-conversions warnings for jdk.hotspot.agent

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8599/files
  - new: https://git.openjdk.org/jdk/pull/8599/files/4b78b1c5..0b93c284

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=15-16

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

PR: https://git.openjdk.org/jdk/pull/8599


From aivanov at openjdk.org  Wed Sep 14 12:09:53 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 14 Sep 2022 12:09:53 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v17]
In-Reply-To: <y5k25RAzsoK-qBbL-9tDK3U0aN4z7p1YN4eJYA618L4=.61b537f1-8d1d-46c7-9a64-da8bcc5279ea@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <y5k25RAzsoK-qBbL-9tDK3U0aN4z7p1YN4eJYA618L4=.61b537f1-8d1d-46c7-9a64-da8bcc5279ea@github.com>
Message-ID: <fAU-_ruprquogiXEtoBWWNZobbMxRGXA8fotCUEX1dY=.85047113-51f5-4d14-a157-fd75ff61209a@github.com>

On Wed, 14 Sep 2022 03:51:40 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Author tag, Modifier, Returned value.
>   
>   Removes the last added author tag.
>   Returns the Color instance from the map if there's one.
>   Renames colorNamed Object to colorNames.
>   Adds final modifier to colorNames.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1406:

> 1404:         } else if (strlc.startsWith("rgba(")) {
> 1405:             return parseRGBA(str);
> 1406:         } else if (str.charAt(0) == '#') {

Suggestion:

        } else if (strlc.charAt(0) == '#') {

For consistency?

test/jdk/javax/swing/text/html/CSS/MissingColorNames.java line 26:

> 24:  */
> 25: 
> 26:  /*

This was right, it should start in the first column.

test/jdk/javax/swing/text/html/CSS/MissingColorNames.java line 48:

> 46:     //   Missing Color Names In CSS.
> 47:     //   'cyan' keyword, as 131 <name-color> keywords also defined in CSS Color Module
> 48:     //   Level 4, are not referenced in CSS.java.

Maybe we should simplify the description?

- 'cyan' is one of the missing <name-color> keywords which are defined in CSS Color Module Level 4.

test/jdk/javax/swing/text/html/CSS/MissingColorNames.java line 77:

> 75:             result.append(" [stringToColor(null) must return null]");
> 76:         }
> 77:         if (!color.toString().toLowerCase(Locale.ROOT).equals("cyan")) {

I wonder if `toLowerCase` required here.

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

PR: https://git.openjdk.org/jdk/pull/9825


From alanb at openjdk.org  Wed Sep 14 14:09:52 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Sep 2022 14:09:52 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

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

 - Merge
 - Remove stopThread permission from RuntimePermission table, exclude jshell tests
 - Deprecate for removal
 - Next iteration, update dates in headers
 - Merge
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10230/files
  - new: https://git.openjdk.org/jdk/pull/10230/files/380e4043..86424b65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=00-01

  Stats: 2990 lines in 108 files changed: 2115 ins; 353 del; 522 mod
  Patch: https://git.openjdk.org/jdk/pull/10230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10230/head:pull/10230

PR: https://git.openjdk.org/jdk/pull/10230


From alanb at openjdk.org  Wed Sep 14 14:09:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Sep 2022 14:09:53 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <GUqUvGAgZaq3V6d7zLstLPcnDXJfC3Tn9nJ7FKCP4Is=.5d7a18f1-55fb-45f6-81e3-9a1372832d38@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <GUqUvGAgZaq3V6d7zLstLPcnDXJfC3Tn9nJ7FKCP4Is=.5d7a18f1-55fb-45f6-81e3-9a1372832d38@github.com>
Message-ID: <Y68P0aWEnsCoTeHVCyMDGD0YSkvUA6Z2Szi8wKNqsZw=.bcff87c3-29b9-4c42-b84a-200d9e6efd5f@github.com>

On Tue, 13 Sep 2022 23:51:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The change looks good. There are other tests that reference `ThreadDeath` for example `test/lib/jdk/test/lib/process/ProcessTools.java`, `test/jdk/java/util/Timer/KillThread.java` , `test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/flow/support/NonFatal.java` etc. Is it expected to update them in a follow-on issue?

I've been trying to keep the test cleanup separate if possible, only because the changes become unwieldy. Aside from jshell, the tests that used Thread.stop have already been changed or removed in advance of this PR. The tests that have catch blocks for ThreadDeath will work as before as there is no Thread.stop. There are one or two tests that will need special attention - the reactivestreams-tck tests that you listed is 3rd party code and we might decide to do nothing there.

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

PR: https://git.openjdk.org/jdk/pull/10230


From alanb at openjdk.org  Wed Sep 14 14:09:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Sep 2022 14:09:55 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <aJKDQu_rOWDcc8-F2LXmygH9d-QBKSd5NOEAlUVI7lQ=.6235cad5-1193-4bc6-89ff-edbf75be21db@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <aJKDQu_rOWDcc8-F2LXmygH9d-QBKSd5NOEAlUVI7lQ=.6235cad5-1193-4bc6-89ff-edbf75be21db@github.com>
Message-ID: <Cam8C9hPg7hx4THYlkkTjowCfvLTS_lDEFG5LdIeEHI=.62bf0954-d2fc-4991-8152-305329f2b38a@github.com>

On Tue, 13 Sep 2022 14:03:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> fold with previous line.

Done.

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

PR: https://git.openjdk.org/jdk/pull/10230


From jpai at openjdk.org  Wed Sep 14 14:24:42 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Sep 2022 14:24:42 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <mpzUIufncDST2C3xklaTg_IzMRpfF3BRD8VHQs2W0E4=.c41ae0b2-450c-4345-a551-3b2ca3c37b3e@github.com>

On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

The changes to the `core-libs` look fine to me. There are some test security policy files (for example `IsKeepingAlive.policy`) and the `DynamicPolicy` which use the `stopThread` `RuntimePermission` which no longer exists. Should those policy files and artifacts be updated to remove reference to this permission too?

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

PR: https://git.openjdk.org/jdk/pull/10230


From jpai at openjdk.org  Wed Sep 14 14:29:11 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Sep 2022 14:29:11 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <fPWT9f28uph0lYEBP7BTDEnQLASgOa6ZRln7P0ITZd4=.854a1da6-21e1-4467-97a0-c9b17fefaacc@github.com>

On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

src/java.logging/share/classes/java/util/logging/LogManager.java line 2670:

> 2668:                 c.run();
> 2669:             } catch (ThreadDeath death) {
> 2670:                 throw death;

In theory, before this change, some (odd/weird) application code which was registered as a `listener` could throw a `ThreadDeath` and we would then abort any other `listeners` from being run. With this change that would no longer be that case. However, I think that is fine, since the API doc of `LogManager.addConfigurationListener()` already states:


* It is recommended that listeners do not throw errors or exceptions.
*
* If a listener terminates with an uncaught error or exception then
* the first exception will be propagated to the caller of
* {@link #readConfiguration()} (or {@link #readConfiguration(java.io.InputStream)})
* after all listeners have been invoked.

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

PR: https://git.openjdk.org/jdk/pull/10230


From alanb at openjdk.org  Wed Sep 14 14:38:41 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Sep 2022 14:38:41 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <mpzUIufncDST2C3xklaTg_IzMRpfF3BRD8VHQs2W0E4=.c41ae0b2-450c-4345-a551-3b2ca3c37b3e@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
 <mpzUIufncDST2C3xklaTg_IzMRpfF3BRD8VHQs2W0E4=.c41ae0b2-450c-4345-a551-3b2ca3c37b3e@github.com>
Message-ID: <V5ZUDTNRCBqbJFWqfiDZthxL-c6rdpf9YvNrcKa3OJs=.ac4dbf11-de65-4981-b0bd-719a969cb30e@github.com>

On Wed, 14 Sep 2022 14:21:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The changes to the `core-libs` look fine to me. There are some test security policy files (for example `IsKeepingAlive.policy`) and the `DynamicPolicy` which use the `stopThread` `RuntimePermission` which no longer exists. Should those policy files and artifacts be updated to remove reference to this permission too?

Mandy asked the test cleanup too. I'm hoping that we will do the test cleanup separately, only to avoid the changes being too unwieldly.

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

PR: https://git.openjdk.org/jdk/pull/10230


From jpai at openjdk.org  Wed Sep 14 15:26:41 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Sep 2022 15:26:41 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <S2NGdOvBFqHCU3kZ71lO-pI_be3rgiAjWyLymGkl7IQ=.f5c55647-8862-4b3f-a1cc-c9bcb74ffaf9@github.com>

On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

Marked as reviewed by jpai (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10230


From jpai at openjdk.org  Wed Sep 14 15:26:42 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Sep 2022 15:26:42 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <V5ZUDTNRCBqbJFWqfiDZthxL-c6rdpf9YvNrcKa3OJs=.ac4dbf11-de65-4981-b0bd-719a969cb30e@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
 <mpzUIufncDST2C3xklaTg_IzMRpfF3BRD8VHQs2W0E4=.c41ae0b2-450c-4345-a551-3b2ca3c37b3e@github.com>
 <V5ZUDTNRCBqbJFWqfiDZthxL-c6rdpf9YvNrcKa3OJs=.ac4dbf11-de65-4981-b0bd-719a969cb30e@github.com>
Message-ID: <zqC1A9QUMyPBsucqh-ACPnCgu9NGXHuYEoIQVGocNDo=.aabd8baa-d81e-4c26-acd3-fad2f587404b@github.com>

On Wed, 14 Sep 2022 14:35:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > The changes to the `core-libs` look fine to me. There are some test security policy files (for example `IsKeepingAlive.policy`) and the `DynamicPolicy` which use the `stopThread` `RuntimePermission` which no longer exists. Should those policy files and artifacts be updated to remove reference to this permission too?
> 
> Mandy asked the test cleanup too. I'm hoping that we will do the test cleanup separately, only to avoid the changes being too unwieldly.

Sorry, I missed your previous response to that similar question. Doing those changes separately sounds fine to me.

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

PR: https://git.openjdk.org/jdk/pull/10230


From rriggs at openjdk.org  Wed Sep 14 15:33:45 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 14 Sep 2022 15:33:45 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <YV7yQcn2WBeqFXs0VJYYUaE0UQxX-o6155kHHgocV-4=.cfa6c0b8-477d-4db2-83b2-11313fce5e5d@github.com>

On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10230


From mchung at openjdk.org  Wed Sep 14 15:59:53 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 14 Sep 2022 15:59:53 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <Neq3XrV6wPCdnoNLwVcgAhgaK2Ei3hJIOZ0JARq9BNc=.1996b1f5-4220-433e-b6d2-24dd79c13200@github.com>

On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10230


From aivanov at openjdk.org  Wed Sep 14 16:38:22 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 14 Sep 2022 16:38:22 GMT
Subject: RFR: 8293811: Provide a reason for PassFailJFrame.forceFail
Message-ID: <4UPN6ayNXV_zTOkwv12NUxxXOlFpISWUC5qO6_HPK_w=.16c4cbd2-069c-43cf-afbf-95e8fc6f9aea@github.com>

Add `forceFail` implementation which allows passing the reason why the test is failed.

I used the newly added method `forceFail(reason)` instead of throwing an exception in `PrintAllPagesTest`. When the test is run outside of jtreg and printing is cancelled, the the test UI becomes ?hung?: clicking Pass or Fail or closing windows does not stop the test.

I also converted the `ret` field to local variable.

In addition to this, I reduced the size of the test frame, its size of 1000?800 doesn't fit even full HD screens when positioned close to the instruction frame.

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

Commit messages:
 - Reduce the frame size where the table is displayed
 - 8293811: Provide a reason for PassFailJFrame.forceFail

Changes: https://git.openjdk.org/jdk/pull/10269/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10269&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293811
  Stats: 26 lines in 2 files changed: 16 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10269.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10269/head:pull/10269

PR: https://git.openjdk.org/jdk/pull/10269


From prr at openjdk.org  Wed Sep 14 17:53:55 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 14 Sep 2022 17:53:55 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <PD97EHa4KSPIKDKxaS9ZqxwonA3e5DPhTiaTN90Wy9Y=.6d8d9d01-f294-45d4-a817-063cf1b8d40e@github.com>

On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10230


From honkar at openjdk.org  Wed Sep 14 18:47:33 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 14 Sep 2022 18:47:33 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame
Message-ID: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>

JInternalFrame background color seems to overflow into the border region. This issue is more prominently seen on Windows - Metal LAF (with fractional scaling, as show below). The primary reason is border scaling issue as observed in  - [JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614) & [JDK-8282958](https://bugs.openjdk.org/browse/JDK-8282958)

The fix involves a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. The test checks the midpoint and corners of borders to check if the internal frame's background color is located out of JInternalFrame.

![image](https://user-images.githubusercontent.com/95945681/190233555-a7e00f2c-9003-4c11-84fb-207957838c2f.png)

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

Commit messages:
 - added test summary
 - updated test case
 - Added test case, minor position changes to shadow lines
 - expanded imports
 - JIF Metal Border Scaling - Initial changes

Changes: https://git.openjdk.org/jdk/pull/10274/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10274&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8015739
  Stats: 402 lines in 2 files changed: 354 ins; 5 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/10274.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10274/head:pull/10274

PR: https://git.openjdk.org/jdk/pull/10274


From aivanov at openjdk.org  Wed Sep 14 20:08:47 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 14 Sep 2022 20:08:47 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v8]
In-Reply-To: <jaEuqSNdK7J2BuW691f5ik4M02JVqzKUldWQmw_M7-I=.9f127461-930f-4f6f-8bd8-8097014ac600@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
 <j1nnUJONoEMCGF0W9fQK0krEPMTWgV-HCeG3VgbGTlo=.356e6da2-cab8-46cf-8dae-3020edda387e@github.com>
 <jaEuqSNdK7J2BuW691f5ik4M02JVqzKUldWQmw_M7-I=.9f127461-930f-4f6f-8bd8-8097014ac600@github.com>
Message-ID: <iaKFPi1yXKpSGs9qou4bPbOrZ4T4SC7SwluAtTB4gzo=.be8d2610-82a1-4e72-86d5-30860bad0ae9@github.com>

On Tue, 13 Sep 2022 21:23:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I'd prefer to only fix typos.

Let us keep only the typos.

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

PR: https://git.openjdk.org/jdk/pull/8328


From duke at openjdk.org  Wed Sep 14 20:20:47 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Wed, 14 Sep 2022 20:20:47 GMT
Subject: RFR: 8293811: Provide a reason for PassFailJFrame.forceFail
In-Reply-To: <4UPN6ayNXV_zTOkwv12NUxxXOlFpISWUC5qO6_HPK_w=.16c4cbd2-069c-43cf-afbf-95e8fc6f9aea@github.com>
References: <4UPN6ayNXV_zTOkwv12NUxxXOlFpISWUC5qO6_HPK_w=.16c4cbd2-069c-43cf-afbf-95e8fc6f9aea@github.com>
Message-ID: <ZVkJPez9cbQj-v6xBS91AgdykRxYWNTNk-bYO3B7DHU=.8b2d9236-6ea7-49df-b9c2-3f749ace9dbf@github.com>

On Wed, 14 Sep 2022 16:27:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Add `forceFail` implementation which allows passing the reason why the test is failed.
> 
> I used the newly added method `forceFail(reason)` instead of throwing an exception in `PrintAllPagesTest`. When the test is run outside of jtreg and printing is cancelled, the the test UI becomes ?hung?: clicking Pass or Fail or closing windows does not stop the test.
> 
> I also converted the `ret` field to local variable.
> 
> In addition to this, I reduced the size of the test frame, its size of 1000?800 doesn't fit even full HD screens when positioned close to the instruction frame.

LGTM

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

PR: https://git.openjdk.org/jdk/pull/10269


From mullan at openjdk.org  Wed Sep 14 20:32:47 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 14 Sep 2022 20:32:47 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <7rR40Xh40dmqQRAmSYBOl-h7vbUwKpq204tERqKKn0Q=.c168ee8e-2cb8-4aaa-a6b4-c562367013fb@github.com>

On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

src/java.base/share/classes/java/lang/Thread.java line 1642:

> 1640:      *       {@code ThreadDeath} exception propagating up the stack).  If
> 1641:      *       any of the objects previously protected by these monitors were in
> 1642:      *       an inconsistent state, the damaged objects become visible to

s/become/became/ 
(because you are writing in past tense now).

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

PR: https://git.openjdk.org/jdk/pull/10230


From honkar at openjdk.org  Wed Sep 14 21:21:06 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 14 Sep 2022 21:21:06 GMT
Subject: RFR: 8293811: Provide a reason for PassFailJFrame.forceFail
In-Reply-To: <4UPN6ayNXV_zTOkwv12NUxxXOlFpISWUC5qO6_HPK_w=.16c4cbd2-069c-43cf-afbf-95e8fc6f9aea@github.com>
References: <4UPN6ayNXV_zTOkwv12NUxxXOlFpISWUC5qO6_HPK_w=.16c4cbd2-069c-43cf-afbf-95e8fc6f9aea@github.com>
Message-ID: <JaBt6JRE_i_k2-zoE1LzImAdKBu4PknpznHZBmoeEo0=.af522125-ac3e-4ca7-87be-231278963e9a@github.com>

On Wed, 14 Sep 2022 16:27:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Add `forceFail` implementation which allows passing the reason why the test is failed.
> 
> I used the newly added method `forceFail(reason)` instead of throwing an exception in `PrintAllPagesTest`. When the test is run outside of jtreg and printing is cancelled, the the test UI becomes ?hung?: clicking Pass or Fail or closing windows does not stop the test.
> 
> I also converted the `ret` field to local variable.
> 
> In addition to this, I reduced the size of the test frame, its size of 1000?800 doesn't fit even full HD screens when positioned close to the instruction frame.

Addition of reason to force fail test makes it more clear. Changes look good.

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

Marked as reviewed by honkar (Author).

PR: https://git.openjdk.org/jdk/pull/10269


From prr at openjdk.org  Wed Sep 14 21:35:08 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 14 Sep 2022 21:35:08 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v28]
In-Reply-To: <itQkJngjXpuUQYlgAyQ1WNTyNQ2PoGsbQtVMalUFR40=.bb0cffdb-42cc-4383-83ba-9ddbb58d4d4e@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <itQkJngjXpuUQYlgAyQ1WNTyNQ2PoGsbQtVMalUFR40=.bb0cffdb-42cc-4383-83ba-9ddbb58d4d4e@github.com>
Message-ID: <YPDUxqUA1R9PhW5_RWY-prKlvjPYVXzUv1pctQDQeps=.72fed5bc-37c4-44ef-84db-624f54c4ab19@github.com>

On Tue, 13 Sep 2022 13:45:46 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

Rounding to the nearest 0.1KB (or 0.1Mb ?) doesn't work well if it causes you to round the size down to zero.
If I am understanding the thread correctly, the native chooser ducks this by displaying the exact byte count for < 1,000 - no rounding either up or down. 
So if we wanted to round to nearest for > 1KB we'd need to do the same - correct ?
But we'd decided (due to localization issues) to just always use Kb not byte, or bytes .. 

So leaving aside what the native chooser does, we then just have to be consistent and round up. 

That's what the current version is trying to do isn't it ?

Thoughts ?

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Sep 15 02:39:07 2022
From: duke at openjdk.org (ScientificWare)
Date: Thu, 15 Sep 2022 02:39:07 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v18]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <nA-aZWjlnAovYQ3PPbLV4VLlRx2RP_I7d14AyRNzc6k=.327a9d49-fbd2-4972-a017-87b350a8ac8d@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

  Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java
  
  Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/4b05b937..65c61ea5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=16-17

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

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Thu Sep 15 03:32:51 2022
From: duke at openjdk.org (ScientificWare)
Date: Thu, 15 Sep 2022 03:32:51 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v19]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <283LZGG_MAMDrtvXAZhNiuDzhRP2aYavIY6sHSlZxmM=.a7f022f4-9637-48bd-8fac-58139216dd89@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

  Simplification, typos, unnecessary conversion.
  
  Simplifies cyan issue description.
  Corrects typos.
  Removes an unnecessary to lower case conversion.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/65c61ea5..ac7b1731

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=17-18

  Stats: 8 lines in 1 file changed: 0 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9825.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9825/head:pull/9825

PR: https://git.openjdk.org/jdk/pull/9825


From jdv at openjdk.org  Thu Sep 15 05:09:04 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 15 Sep 2022 05:09:04 GMT
Subject: RFR: 8293811: Provide a reason for PassFailJFrame.forceFail
In-Reply-To: <4UPN6ayNXV_zTOkwv12NUxxXOlFpISWUC5qO6_HPK_w=.16c4cbd2-069c-43cf-afbf-95e8fc6f9aea@github.com>
References: <4UPN6ayNXV_zTOkwv12NUxxXOlFpISWUC5qO6_HPK_w=.16c4cbd2-069c-43cf-afbf-95e8fc6f9aea@github.com>
Message-ID: <nQFI0wNkpKbr64pljnuzrDU3RNNMh1L7bOQuNedZprQ=.0e725492-ed1a-4ff8-97a6-c5ea28870977@github.com>

On Wed, 14 Sep 2022 16:27:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Add `forceFail` implementation which allows passing the reason why the test is failed.
> 
> I used the newly added method `forceFail(reason)` instead of throwing an exception in `PrintAllPagesTest`. When the test is run outside of jtreg and printing is cancelled, the the test UI becomes ?hung?: clicking Pass or Fail or closing windows does not stop the test.
> 
> I also converted the `ret` field to local variable.
> 
> In addition to this, I reduced the size of the test frame, its size of 1000?800 doesn't fit even full HD screens when positioned close to the instruction frame.

If there are other tests where we can use PassFailJFrame.forceFail(String) instead of throwing RuntimeException, we should raise a bug and keep it for tracking.

LGTM.

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

Marked as reviewed by jdv (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10269


From jdv at openjdk.org  Thu Sep 15 06:03:43 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 15 Sep 2022 06:03:43 GMT
Subject: RFR: 6286501: JTabbedPane throws NPE from its stateChanged
 listener in particular case
In-Reply-To: <lqTnk1Sa-Qj3elOMsgW6WZkp_m3I3OQ_L2BdovhsieA=.8b329b54-c744-46cd-81e7-f4249a03f9f6@github.com>
References: <lqTnk1Sa-Qj3elOMsgW6WZkp_m3I3OQ_L2BdovhsieA=.8b329b54-c744-46cd-81e7-f4249a03f9f6@github.com>
Message-ID: <9X7VGnQKbpI1FZ_Y-QdV0XS-XqiVIa_g9l1-uVtnEJ8=.a98053ba-1d16-4a9c-9c5b-08e6a824b373@github.com>

On Thu, 8 Sep 2022 09:46:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> JTabbedPane throws NPE from its stateChanged listener as it tries to access uninstantiated TabbedPane.
> Fix is to use the tabPane passed to stateChangeListener so that correct tabPane is accessed.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java line 4102:

> 4100:             setFocusIndex(tabPane.getSelectedIndex(), false);
> 4101: 
> 4102:             if (tabPane.getLayout() instanceof TabbedPaneScrollLayout) {

I see BasicTabbedPaneUI.tabPane object getting used in other listeners in this Handler class. Is there a reason why only when we hit stateChanged() function we are seeing NPE?

Is this NPE for tabPane object itself or Layout not being initialized?

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

PR: https://git.openjdk.org/jdk/pull/10216


From jdv at openjdk.org  Thu Sep 15 06:16:46 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 15 Sep 2022 06:16:46 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is
 not shown on disabled checkbox and radio button with Nimbus LAF
In-Reply-To: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
References: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
Message-ID: <qOEYAssuNFXY47fPKTPXhr2anh5IXjYNycxE4Tk1llQ=.b7cad0a9-d814-486d-92e9-82178d462a82@github.com>

On Tue, 6 Sep 2022 05:57:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CheckBox.disabledText and RadioButton.disabledText color UIProperty is not honoured by Nimbus L&F when disabled text is drawn for JCheckBox and JRadioButton, so disabled text color was rendered incorrectly.
> Fix is to honour these UIProperty color if they are set by user, else use the color from the component or via getColorForState().
> 
> Closed test as mentioned in JBS is used to check the fix.

Does this fix the issue in GTK LAF also? I see a comment in JBS that same issue is with GTK LAF.

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

PR: https://git.openjdk.org/jdk/pull/10177


From duke at openjdk.org  Thu Sep 15 06:21:32 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 15 Sep 2022 06:21:32 GMT
Subject: RFR: 8271328: User is able to choose the color after disabling the
 color chooser.
Message-ID: <dXWt4SdWl0Zj6wwwMcNWGEB9Q8tROYT-Y23cMUn4fLI=.9c994d26-4ffe-455e-919c-fb37b76371c7@github.com>

The proposed solution for this defect is to check the color chooser enabled state. If it is disabled then disable all the components (spinner, textfield etc.) in panel and don't process the mouse event when user click on a color triangle or color wheel.

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

Commit messages:
 - Whitespace error fix
 - Disabled ColorChooser fix

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

PR: https://git.openjdk.org/jdk/pull/10276


From jdv at openjdk.org  Thu Sep 15 06:45:43 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 15 Sep 2022 06:45:43 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is
 not shown on disabled checkbox and radio button with Nimbus LAF
In-Reply-To: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
References: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
Message-ID: <D5NsMCyUbY-392IHsgmrkR7Cwr4iHIdmLlTs9yhTXyo=.561fa4d6-9794-42a7-8eda-5276c8b1cdd0@github.com>

On Tue, 6 Sep 2022 05:57:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CheckBox.disabledText and RadioButton.disabledText color UIProperty is not honoured by Nimbus L&F when disabled text is drawn for JCheckBox and JRadioButton, so disabled text color was rendered incorrectly.
> Fix is to honour these UIProperty color if they are set by user, else use the color from the component or via getColorForState().
> 
> Closed test as mentioned in JBS is used to check the fix.

Closed test case mentioned in JBS runs only in Default LAF. We need to explicitly specify LAF.
Also it looks like closed test is unstable:
1) With default LAF test hangs in my mac
2) With Nimbus LAF it passes without the fix.

Its better to add separate regression test to verify this fix.

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

PR: https://git.openjdk.org/jdk/pull/10177


From jdv at openjdk.org  Thu Sep 15 06:49:48 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 15 Sep 2022 06:49:48 GMT
Subject: RFR: 5074006: Swing JOptionPane shows </html> tag as a string
 after newline [v2]
In-Reply-To: <2BmZo0HFOMAvei4VnM5WPD_BoIauCM1nyhnuipD8oV0=.a4b8b627-6d68-4789-99b8-bdd09c8a9cf0@github.com>
References: <DWhqieaffzn6xk--zvJwqX4LVNFtVnuI-5rnfuFGTL0=.55ec4218-3188-4917-9233-cbce1562f3e2@github.com>
 <2BmZo0HFOMAvei4VnM5WPD_BoIauCM1nyhnuipD8oV0=.a4b8b627-6d68-4789-99b8-bdd09c8a9cf0@github.com>
Message-ID: <ifnfzD_zrzieqVQ_lzGWojTy8viRYANgboJNdals-aQ=.1b2bc4c0-6ba8-40fa-b9b0-6d4228786961@github.com>

On Mon, 12 Sep 2022 11:47:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If JOptionPane's message contains both linefeed/cursor return and HTML tag ie, **<html\>" + "This is a test\n" + "</html\>**,
>> then  "</html\>" will be shown in the JOptionPane dialog box because after every new line it creates a new messageComponent so the characters after the newline ie "</html\>"tag will be considered as a new JLabel string and displayed.
>> 
>> Fix is to ignore closing html tag if appearing after newline from the displayed string.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix handling HTML message

Marked as reviewed by jdv (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10081


From psadhukhan at openjdk.org  Thu Sep 15 06:59:47 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 15 Sep 2022 06:59:47 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is
 not shown on disabled checkbox and radio button with Nimbus LAF
In-Reply-To: <D5NsMCyUbY-392IHsgmrkR7Cwr4iHIdmLlTs9yhTXyo=.561fa4d6-9794-42a7-8eda-5276c8b1cdd0@github.com>
References: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
 <D5NsMCyUbY-392IHsgmrkR7Cwr4iHIdmLlTs9yhTXyo=.561fa4d6-9794-42a7-8eda-5276c8b1cdd0@github.com>
Message-ID: <IP1_L2jvfzSlWkwKOzXgPwp2dLYAHz3BZ7x2-1kPROE=.a129d3d8-462c-4834-b819-1d259963907d@github.com>

On Thu, 15 Sep 2022 06:42:17 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Closed test case mentioned in JBS runs only in Default LAF. We need to explicitly specify LAF. Also it looks like closed test is unstable:
> 
>     1. With default LAF test hangs in my mac
> 
>     2. With Nimbus LAF it passes without the fix.
> 
> 
> Its better to add separate regression test to verify this fix.

I dont see this problem. In my mac BigSur, default LAF passed and Nimbus L&F fails without the fix.

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

PR: https://git.openjdk.org/jdk/pull/10177


From jdv at openjdk.org  Thu Sep 15 07:10:44 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 15 Sep 2022 07:10:44 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is
 not shown on disabled checkbox and radio button with Nimbus LAF
In-Reply-To: <IP1_L2jvfzSlWkwKOzXgPwp2dLYAHz3BZ7x2-1kPROE=.a129d3d8-462c-4834-b819-1d259963907d@github.com>
References: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
 <D5NsMCyUbY-392IHsgmrkR7Cwr4iHIdmLlTs9yhTXyo=.561fa4d6-9794-42a7-8eda-5276c8b1cdd0@github.com>
 <IP1_L2jvfzSlWkwKOzXgPwp2dLYAHz3BZ7x2-1kPROE=.a129d3d8-462c-4834-b819-1d259963907d@github.com>
Message-ID: <_K3jvfs8QIHYhEf2GtQE-ZRvjE3UM3BU9mLnU9xyuFk=.3ca8830a-80da-4877-805c-cef3330f8f36@github.com>

On Thu, 15 Sep 2022 06:57:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > Closed test case mentioned in JBS runs only in Default LAF. We need to explicitly specify LAF. Also it looks like closed test is unstable:
> > ```
> > 1. With default LAF test hangs in my mac
> > 
> > 2. With Nimbus LAF it passes without the fix.
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Its better to add separate regression test to verify this fix.
> 
> I dont see this problem. In my mac BigSur, default LAF passed and Nimbus L&F fails without the fix.

I have Monterey. I think its better to have open test case which verifies the behavior specific to Nimbus LAF(and may be GTK LAF if that is also getting fixed under this bug)

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

PR: https://git.openjdk.org/jdk/pull/10177


From duke at openjdk.org  Thu Sep 15 07:26:02 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 15 Sep 2022 07:26:02 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v28]
In-Reply-To: <YPDUxqUA1R9PhW5_RWY-prKlvjPYVXzUv1pctQDQeps=.72fed5bc-37c4-44ef-84db-624f54c4ab19@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <itQkJngjXpuUQYlgAyQ1WNTyNQ2PoGsbQtVMalUFR40=.bb0cffdb-42cc-4383-83ba-9ddbb58d4d4e@github.com>
 <YPDUxqUA1R9PhW5_RWY-prKlvjPYVXzUv1pctQDQeps=.72fed5bc-37c4-44ef-84db-624f54c4ab19@github.com>
Message-ID: <1cVWZI5OKOOwYmaUzkHFmcT5N8idxaYQPmPg6NHBizk=.cd8ec33c-92d9-48c6-b4b8-9e661862fe25@github.com>

On Wed, 14 Sep 2022 21:33:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Rounding to the nearest 0.1KB (or 0.1Mb ?) doesn't work well if it causes you to round the size down to zero. If I am understanding the thread correctly, the native chooser ducks this by displaying the exact byte count for < 1,000 - no rounding either up or down. So if we wanted to round to nearest for > 1KB we'd need to do the same - correct ? But we'd decided (due to localization issues) to just always use Kb not byte, or bytes ..
> 
> So leaving aside what the native chooser does, we then just have to be consistent and round up.
> 
> That's what the current version is trying to do isn't it ?
> 
> Thoughts ?

Yeah, as per the current fix we are doing consistently round up for all file sizes.

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

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Thu Sep 15 07:36:36 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 15 Sep 2022 07:36:36 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is
 not shown on disabled checkbox and radio button with Nimbus LAF
In-Reply-To: <_K3jvfs8QIHYhEf2GtQE-ZRvjE3UM3BU9mLnU9xyuFk=.3ca8830a-80da-4877-805c-cef3330f8f36@github.com>
References: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
 <D5NsMCyUbY-392IHsgmrkR7Cwr4iHIdmLlTs9yhTXyo=.561fa4d6-9794-42a7-8eda-5276c8b1cdd0@github.com>
 <IP1_L2jvfzSlWkwKOzXgPwp2dLYAHz3BZ7x2-1kPROE=.a129d3d8-462c-4834-b819-1d259963907d@github.com>
 <_K3jvfs8QIHYhEf2GtQE-ZRvjE3UM3BU9mLnU9xyuFk=.3ca8830a-80da-4877-805c-cef3330f8f36@github.com>
Message-ID: <06Z2x0bxVe7WfDu4UUTqeYfp0O4t4NAk5kCJZo9zeOg=.88e6e6e4-880c-4b22-89ee-1439626594ca@github.com>

On Thu, 15 Sep 2022 07:06:58 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> > > Closed test case mentioned in JBS runs only in Default LAF. We need to explicitly specify LAF. Also it looks like closed test is unstable:
> > > ```
> > > 1. With default LAF test hangs in my mac
> > > 
> > > 2. With Nimbus LAF it passes without the fix.
> > > ```
> > > 
> > > 
> > >     
> > >       
> > >     
> > > 
> > >       
> > >     
> > > 
> > >     
> > >   
> > > Its better to add separate regression test to verify this fix.
> > 
> > 
> > I dont see this problem. In my mac BigSur, default LAF passed and Nimbus L&F fails without the fix.
> 
> I have Monterey. I think its better to have open test case which verifies the behavior specific to Nimbus LAF(and may be GTK LAF if that is also getting fixed under this bug)

I tested on Monterey also and there also I didn't see this problem. 
Default L&F passed and Nimbus L&F failed without fix.

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

PR: https://git.openjdk.org/jdk/pull/10177


From psadhukhan at openjdk.org  Thu Sep 15 08:18:35 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 15 Sep 2022 08:18:35 GMT
Subject: RFR: 7172359: HTML parser StackOverflowError on invalid HTML: <li> tag
 inside an <option>
Message-ID: <edPACBk6ADLPsapJLTvWRDOYjYN_YgZXPDYn-hDo6Pc=.51f30a46-e66a-49a1-bfbe-9241827d0751@github.com>

If there is invalid tag, stack terminates but it still tries to recurse through by calling legalElementContext() which results in StackOverflowError.
Fix is to return if stack is terminated after endTag is handled.

All other test/html/parser tests are ok with the fix.

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

Commit messages:
 - Test fix
 - Test fix
 - 7172359: HTML parser StackOverflowError on invalid HTML: <li> tag inside an <option>

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

PR: https://git.openjdk.org/jdk/pull/10279


From duke at openjdk.org  Thu Sep 15 08:20:51 2022
From: duke at openjdk.org (Stanimir Stamenkov)
Date: Thu, 15 Sep 2022 08:20:51 GMT
Subject: Integrated: 8292948: JEditorPane ignores font-size styles in external
 linked css-file
In-Reply-To: <CXQy2fQCcs9PeBtCtUZmEdKhx9le3CQxQQAf564QVTM=.e448a883-d2e3-425d-aaa4-1b9d32431b60@github.com>
References: <CXQy2fQCcs9PeBtCtUZmEdKhx9le3CQxQQAf564QVTM=.e448a883-d2e3-425d-aaa4-1b9d32431b60@github.com>
Message-ID: <AtRr0Jggr8US0v9Fckp1IoIGE9HWpTmw5qMMoXR1F6Q=.4d3171ce-4322-4e04-b4ba-f859a91d12b1@github.com>

On Sat, 27 Aug 2022 08:54:41 GMT, Stanimir Stamenkov <duke at openjdk.org> wrote:

> [JDK-8292948] reveals a regression by the fix for [JDK-8257664] (#1759) causing `font-size` declarations from external style sheets to be ignored.
> 
> As far as I've traced, the problem is with the `isDefined(CSS.Attribute.FONT_SIZE)` test:
> 
> https://github.com/openjdk/jdk/blob/70b5b3119b2ed032b021a080f34a4fa28d092fb5/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#L2825-L2830
> 
> It misses declarations from linked styles via a `resolver` ([`AttributeSet.ResolveAttribute`](https://github.com/openjdk/jdk/blob/b0e0b87891eb81c2b33c1cfa598701b7bd2e5bdf/src/java.desktop/share/classes/javax/swing/text/AttributeSet.java#L187-L191)) attribute that happens to hold the external style sheet rules.  The fix for this would be to move the implied `CSS.Attribute.FONT_SIZE` handling after:
> 
> https://github.com/openjdk/jdk/blob/70b5b3119b2ed032b021a080f34a4fa28d092fb5/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#L2833-L2835
> 
> and drop the `isDefined()` test.
> 
> [I'll prepare a jtreg test further.]
> 
> [JDK-8292948]: https://bugs.openjdk.org/browse/JDK-8292948 "JEditorPane ignores font-size styles in external linked css-file"
> [JDK-8257664]: https://bugs.openjdk.org/browse/JDK-8257664 "HTMLEditorKit: Wrong CSS relative font sizes"

This pull request has now been integrated.

Changeset: 1caba0f1
Author:    Stanimir Stamenkov <stanio at yahoo.com>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1caba0f13c42121c9e1c6648715ec7c31349b537
Stats:     217 lines in 4 files changed: 211 ins; 4 del; 2 mod

8292948: JEditorPane ignores font-size styles in external linked css-file

Reviewed-by: psadhukhan

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

PR: https://git.openjdk.org/jdk/pull/10054


From jdv at openjdk.org  Thu Sep 15 08:57:06 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 15 Sep 2022 08:57:06 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is
 not shown on disabled checkbox and radio button with Nimbus LAF
In-Reply-To: <06Z2x0bxVe7WfDu4UUTqeYfp0O4t4NAk5kCJZo9zeOg=.88e6e6e4-880c-4b22-89ee-1439626594ca@github.com>
References: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
 <D5NsMCyUbY-392IHsgmrkR7Cwr4iHIdmLlTs9yhTXyo=.561fa4d6-9794-42a7-8eda-5276c8b1cdd0@github.com>
 <IP1_L2jvfzSlWkwKOzXgPwp2dLYAHz3BZ7x2-1kPROE=.a129d3d8-462c-4834-b819-1d259963907d@github.com>
 <_K3jvfs8QIHYhEf2GtQE-ZRvjE3UM3BU9mLnU9xyuFk=.3ca8830a-80da-4877-805c-cef3330f8f36@github.com>
 <06Z2x0bxVe7WfDu4UUTqeYfp0O4t4NAk5kCJZo9zeOg=.88e6e6e4-880c-4b22-89ee-1439626594ca@github.com>
Message-ID: <BzPvt2RkPE7kVIx-zCPi8EnV9fDM_-WEGt5N7fkG9Xo=.f40ce8b9-bffe-4194-b285-b9b6e42e2243@github.com>

On Thu, 15 Sep 2022 07:32:54 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > > > Closed test case mentioned in JBS runs only in Default LAF. We need to explicitly specify LAF. Also it looks like closed test is unstable:
> > > > ```
> > > > 1. With default LAF test hangs in my mac
> > > > 
> > > > 2. With Nimbus LAF it passes without the fix.
> > > > ```
> > > > 
> > > > 
> > > >     
> > > >       
> > > >     
> > > > 
> > > >       
> > > >     
> > > > 
> > > >     
> > > >   
> > > > Its better to add separate regression test to verify this fix.
> > > 
> > > 
> > > I dont see this problem. In my mac BigSur, default LAF passed and Nimbus L&F fails without the fix.
> > 
> > 
> > I have Monterey. I think its better to have open test case which verifies the behavior specific to Nimbus LAF(and may be GTK LAF if that is also getting fixed under this bug)
> 
> I tested on Monterey also and there also I didn't see this problem. Default L&F passed and Nimbus L&F failed without fix.

Okay. I have new M1 machine may be it is machine specific issue.

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

PR: https://git.openjdk.org/jdk/pull/10177


From aivanov at openjdk.org  Thu Sep 15 09:50:43 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 15 Sep 2022 09:50:43 GMT
Subject: RFR: 8293811: Provide a reason for PassFailJFrame.forceFail
In-Reply-To: <nQFI0wNkpKbr64pljnuzrDU3RNNMh1L7bOQuNedZprQ=.0e725492-ed1a-4ff8-97a6-c5ea28870977@github.com>
References: <4UPN6ayNXV_zTOkwv12NUxxXOlFpISWUC5qO6_HPK_w=.16c4cbd2-069c-43cf-afbf-95e8fc6f9aea@github.com>
 <nQFI0wNkpKbr64pljnuzrDU3RNNMh1L7bOQuNedZprQ=.0e725492-ed1a-4ff8-97a6-c5ea28870977@github.com>
Message-ID: <SrPo68vUWQ5sidKNZTiAtM_2edXoRbMaPPISifNW8w8=.6be69f37-1124-43fe-97e9-03e29046c5de@github.com>

On Thu, 15 Sep 2022 05:06:08 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> If there are other tests where we can use PassFailJFrame.forceFail(String) instead of throwing RuntimeException, we should raise a bug and keep it for tracking.
> 
> LGTM.

That's the only test I know about.

jtreg handles it gracefully, so it's not a very big issue. At the same time, we should handle the case where exception is thrown from the code which prepares the test. It is [one of problems to be addressed](https://github.com/openjdk/jdk/pull/9525#issuecomment-1220057640).

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

PR: https://git.openjdk.org/jdk/pull/10269


From psadhukhan at openjdk.org  Thu Sep 15 10:02:37 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 15 Sep 2022 10:02:37 GMT
Subject: RFR: 6286501: JTabbedPane throws NPE from its stateChanged
 listener in particular case
In-Reply-To: <9X7VGnQKbpI1FZ_Y-QdV0XS-XqiVIa_g9l1-uVtnEJ8=.a98053ba-1d16-4a9c-9c5b-08e6a824b373@github.com>
References: <lqTnk1Sa-Qj3elOMsgW6WZkp_m3I3OQ_L2BdovhsieA=.8b329b54-c744-46cd-81e7-f4249a03f9f6@github.com>
 <9X7VGnQKbpI1FZ_Y-QdV0XS-XqiVIa_g9l1-uVtnEJ8=.a98053ba-1d16-4a9c-9c5b-08e6a824b373@github.com>
Message-ID: <5SgctjWLgcQEQAVv3o_fNsS8Ar_QhVvfegYoyiBeZy0=.b9f9a5d3-4bf4-412c-9b52-3e0289fb117a@github.com>

On Thu, 15 Sep 2022 06:01:37 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> JTabbedPane throws NPE from its stateChanged listener as it tries to access uninstantiated TabbedPane.
>> Fix is to use the tabPane passed to stateChangeListener so that correct tabPane is accessed.
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java line 4102:
> 
>> 4100:             setFocusIndex(tabPane.getSelectedIndex(), false);
>> 4101: 
>> 4102:             if (tabPane.getLayout() instanceof TabbedPaneScrollLayout) {
> 
> I see BasicTabbedPaneUI.tabPane object getting used in other listeners in this Handler class. Is there a reason why only when we hit stateChanged() function we are seeing NPE?
> 
> Is this NPE for tabPane object itself or Layout not being initialized?

Basically, when a tab index is selected via `tbp.setSelectedIndex()` in testcase, it fires a state change event (via `DefaultSingleSelectionModel#setSelectedIndex`) which is caught by the application and in this case, state change listener in the testcase calls `JTabbedPane.updateUI() `which calls `JComponent.setUI() `which first uninstalls UI (which made `tabPane null` in `BasicTabbedPaneUI#uninstallUI`) and then install new UI instance but when it goes to JDK's stateChange listener `BasicTabbedPaneUI.stateChanged()` it passes the new instance but scrollableTabLayoutEnabled() still uses old UI instance in which tabPane is already made null so NPE happens, so it is better to use the tabPane instance passed to UI's stateChange listener..

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

PR: https://git.openjdk.org/jdk/pull/10216


From tr at openjdk.org  Thu Sep 15 10:07:47 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 15 Sep 2022 10:07:47 GMT
Subject: RFR: 8271328: User is able to choose the color after disabling the
 color chooser.
In-Reply-To: <dXWt4SdWl0Zj6wwwMcNWGEB9Q8tROYT-Y23cMUn4fLI=.9c994d26-4ffe-455e-919c-fb37b76371c7@github.com>
References: <dXWt4SdWl0Zj6wwwMcNWGEB9Q8tROYT-Y23cMUn4fLI=.9c994d26-4ffe-455e-919c-fb37b76371c7@github.com>
Message-ID: <6hPw-3o7bPN6qAZjfea3QjSRh-lIId41DqIgs3rD3nU=.ad890497-7b79-4eac-85c3-36ae12a0e394@github.com>

On Thu, 15 Sep 2022 06:07:30 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> The proposed solution for this defect is to check the color chooser enabled state. If it is disabled then disable all the components (spinner, textfield etc.) in panel and don't process the mouse event when user click on a color triangle or color wheel.

test/jdk/javax/swing/JColorChooser/TestDisabledColorChooser.java line 39:

> 37: import java.awt.Point;
> 38: import java.awt.Robot;
> 39: import javax.swing.*;

Please import only used swing components/functionalities. Can remove the generic `swing.*` import.

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

PR: https://git.openjdk.org/jdk/pull/10276


From asotona at openjdk.org  Thu Sep 15 10:12:53 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 15 Sep 2022 10:12:53 GMT
Subject: Integrated: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <z-bQGuu0bN_VqBmdbjUEkFe7TyQXUo47sVNnCXKvuvU=.23ec3739-9d31-484d-a296-11d5991ed934@github.com>

On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

This pull request has now been integrated.

Changeset: aff5ff14
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aff5ff14b208b3c2be93d7b4fab8b07c5be12f3e
Stats:     438 lines in 13 files changed: 437 ins; 0 del; 1 mod

8244681: Add a warning for possibly lossy conversion in compound assignments
8293797: Release Note: Javac warns about type casts in compound assignments with possible lossy conversions

Reviewed-by: erikj, prr

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

PR: https://git.openjdk.org/jdk/pull/8599


From duke at openjdk.org  Thu Sep 15 11:14:50 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 15 Sep 2022 11:14:50 GMT
Subject: RFR: 8271328: User is able to choose the color after disabling the
 color chooser. [v2]
In-Reply-To: <dXWt4SdWl0Zj6wwwMcNWGEB9Q8tROYT-Y23cMUn4fLI=.9c994d26-4ffe-455e-919c-fb37b76371c7@github.com>
References: <dXWt4SdWl0Zj6wwwMcNWGEB9Q8tROYT-Y23cMUn4fLI=.9c994d26-4ffe-455e-919c-fb37b76371c7@github.com>
Message-ID: <iQRBXhi_onmGlXXgNYjccREa-JACQbzx0Tjey1pC2zU=.a92b087d-eebb-4f50-bb31-c8fb00b1352f@github.com>

> The proposed solution for this defect is to check the color chooser enabled state. If it is disabled then disable all the components (spinner, textfield etc.) in panel and don't process the mouse event when user click on a color triangle or color wheel.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Review comment fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10276/files
  - new: https://git.openjdk.org/jdk/pull/10276/files/a5a123c8..9f1e8d18

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10276&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10276&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/10276


From duke at openjdk.org  Thu Sep 15 11:14:52 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 15 Sep 2022 11:14:52 GMT
Subject: RFR: 8271328: User is able to choose the color after disabling the
 color chooser. [v2]
In-Reply-To: <6hPw-3o7bPN6qAZjfea3QjSRh-lIId41DqIgs3rD3nU=.ad890497-7b79-4eac-85c3-36ae12a0e394@github.com>
References: <dXWt4SdWl0Zj6wwwMcNWGEB9Q8tROYT-Y23cMUn4fLI=.9c994d26-4ffe-455e-919c-fb37b76371c7@github.com>
 <6hPw-3o7bPN6qAZjfea3QjSRh-lIId41DqIgs3rD3nU=.ad890497-7b79-4eac-85c3-36ae12a0e394@github.com>
Message-ID: <XIgFaRnrZOU8qbFxbUYsl5BwZTIPB_Mwmlk-0_yV6dU=.53b717d1-ef78-4036-9ff8-7f419a01bcb8@github.com>

On Thu, 15 Sep 2022 10:05:34 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment fix
>
> test/jdk/javax/swing/JColorChooser/TestDisabledColorChooser.java line 39:
> 
>> 37: import java.awt.Point;
>> 38: import java.awt.Robot;
>> 39: import javax.swing.*;
> 
> Please import only used swing components/functionalities. Can remove the generic `swing.*` import.

Updated the import statements.

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

PR: https://git.openjdk.org/jdk/pull/10276


From psadhukhan at openjdk.org  Thu Sep 15 11:51:38 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 15 Sep 2022 11:51:38 GMT
Subject: RFR: JDK-8293767: AWT test TestSinhalaChar.java has old SCCS markings
Message-ID: <tZu0buhAOwRO0r3f6NM2QGu7dOay_6VyuvxbIR5TLp0=.fc8fb3a0-0c64-4daa-99de-2fddd5e7ee93@github.com>

Old SCCS markings removed from the jtreg tag.

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

Commit messages:
 - JDK-8293767: AWT test TestSinhalaChar.java has old SCCS markings

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

PR: https://git.openjdk.org/jdk/pull/10285


From jdv at openjdk.org  Thu Sep 15 12:22:55 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 15 Sep 2022 12:22:55 GMT
Subject: RFR: 6286501: JTabbedPane throws NPE from its stateChanged
 listener in particular case
In-Reply-To: <5SgctjWLgcQEQAVv3o_fNsS8Ar_QhVvfegYoyiBeZy0=.b9f9a5d3-4bf4-412c-9b52-3e0289fb117a@github.com>
References: <lqTnk1Sa-Qj3elOMsgW6WZkp_m3I3OQ_L2BdovhsieA=.8b329b54-c744-46cd-81e7-f4249a03f9f6@github.com>
 <9X7VGnQKbpI1FZ_Y-QdV0XS-XqiVIa_g9l1-uVtnEJ8=.a98053ba-1d16-4a9c-9c5b-08e6a824b373@github.com>
 <5SgctjWLgcQEQAVv3o_fNsS8Ar_QhVvfegYoyiBeZy0=.b9f9a5d3-4bf4-412c-9b52-3e0289fb117a@github.com>
Message-ID: <dUy1BVCSFxanWnBzj7dT9nmyqNFAifyTmmK3YNr36Yo=.d6463c9a-90c2-46cd-9353-f4d897438679@github.com>

On Thu, 15 Sep 2022 09:58:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java line 4102:
>> 
>>> 4100:             setFocusIndex(tabPane.getSelectedIndex(), false);
>>> 4101: 
>>> 4102:             if (tabPane.getLayout() instanceof TabbedPaneScrollLayout) {
>> 
>> I see BasicTabbedPaneUI.tabPane object getting used in other listeners in this Handler class. Is there a reason why only when we hit stateChanged() function we are seeing NPE?
>> 
>> Is this NPE for tabPane object itself or Layout not being initialized?
>
> Basically, when a tab index is selected via `tbp.setSelectedIndex()` in testcase, it fires a state change event (via `DefaultSingleSelectionModel#setSelectedIndex`) which is caught by the application and in this case, state change listener in the testcase calls `JTabbedPane.updateUI() `which calls `JComponent.setUI() `which first uninstalls UI (which made `tabPane null` in `BasicTabbedPaneUI#uninstallUI`) and then install new UI instance but when it goes to JDK's stateChange listener `BasicTabbedPaneUI.stateChanged()` it passes the new instance but scrollableTabLayoutEnabled() still uses old UI instance in which tabPane is already made null so NPE happens, so it is better to use the tabPane instance passed to UI's stateChange listener..

When we install new UI instance will we not call BasicTabbedPaneUI.installUI() to update current tabPane object? or is it happening at later stage(like after BasicTabbedPaneUI.stateChanged() is called)?

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

PR: https://git.openjdk.org/jdk/pull/10216


From psadhukhan at openjdk.org  Thu Sep 15 12:31:46 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 15 Sep 2022 12:31:46 GMT
Subject: RFR: 6286501: JTabbedPane throws NPE from its stateChanged
 listener in particular case
In-Reply-To: <dUy1BVCSFxanWnBzj7dT9nmyqNFAifyTmmK3YNr36Yo=.d6463c9a-90c2-46cd-9353-f4d897438679@github.com>
References: <lqTnk1Sa-Qj3elOMsgW6WZkp_m3I3OQ_L2BdovhsieA=.8b329b54-c744-46cd-81e7-f4249a03f9f6@github.com>
 <9X7VGnQKbpI1FZ_Y-QdV0XS-XqiVIa_g9l1-uVtnEJ8=.a98053ba-1d16-4a9c-9c5b-08e6a824b373@github.com>
 <5SgctjWLgcQEQAVv3o_fNsS8Ar_QhVvfegYoyiBeZy0=.b9f9a5d3-4bf4-412c-9b52-3e0289fb117a@github.com>
 <dUy1BVCSFxanWnBzj7dT9nmyqNFAifyTmmK3YNr36Yo=.d6463c9a-90c2-46cd-9353-f4d897438679@github.com>
Message-ID: <expcZ0LssCHIFvK-31xLDww1glHx5PnmrwpXq2q5pRA=.3aa69d44-ca78-4fdd-b7f9-289f6dc5cf88@github.com>

On Thu, 15 Sep 2022 12:20:51 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Basically, when a tab index is selected via `tbp.setSelectedIndex()` in testcase, it fires a state change event (via `DefaultSingleSelectionModel#setSelectedIndex`) which is caught by the application and in this case, state change listener in the testcase calls `JTabbedPane.updateUI() `which calls `JComponent.setUI() `which first uninstalls UI (which made `tabPane null` in `BasicTabbedPaneUI#uninstallUI`) and then install new UI instance but when it goes to JDK's stateChange listener `BasicTabbedPaneUI.stateChanged()` it passes the new instance but scrollableTabLayoutEnabled() still uses old UI instance in which tabPane is already made null so NPE happens, so it is better to use the tabPane instance passed to UI's stateChange listener..
>
> When we install new UI instance will we not call BasicTabbedPaneUI.installUI() to update current tabPane object? or is it happening at later stage(like after BasicTabbedPaneUI.stateChanged() is called)?

installUI is called for new UI instance with current tabpane object but scrollableTabLayoutEnabled was using the old UI instance whose tabpane object is already reset to null.

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

PR: https://git.openjdk.org/jdk/pull/10216


From iris at openjdk.org  Thu Sep 15 15:10:55 2022
From: iris at openjdk.org (Iris Clark)
Date: Thu, 15 Sep 2022 15:10:55 GMT
Subject: RFR: JDK-8293767: AWT test TestSinhalaChar.java has old SCCS
 markings
In-Reply-To: <tZu0buhAOwRO0r3f6NM2QGu7dOay_6VyuvxbIR5TLp0=.fc8fb3a0-0c64-4daa-99de-2fddd5e7ee93@github.com>
References: <tZu0buhAOwRO0r3f6NM2QGu7dOay_6VyuvxbIR5TLp0=.fc8fb3a0-0c64-4daa-99de-2fddd5e7ee93@github.com>
Message-ID: <BuyavMdTyi6SELJGrpKTgbayg_fR9TcJmOO7489S54o=.f05e6efa-e8e4-4012-bca8-cc49eb305648@github.com>

On Thu, 15 Sep 2022 11:44:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Old SCCS markings removed from the jtreg tag.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10285


From omikhaltcova at openjdk.org  Thu Sep 15 20:01:18 2022
From: omikhaltcova at openjdk.org (Olga Mikhaltsova)
Date: Thu, 15 Sep 2022 20:01:18 GMT
Subject: RFR: 8165943: LineBreakMeasurer does not measure correctly if
 TextAttribute.TRACKING is set.
Message-ID: <nR-8uNeYQ5IHSe3RVQGizNWAy7zMd-wi82kcqyP0xfQ=.ed8fe6a6-6c40-4439-be11-25d78e61f88c@github.com>

This is a fix for LineBreakMeasurer. It takes into account the TextAttribute.TRACKING value (not eq 0) while calculating the line breaks.

Tested on Linux x64, Windows x64, macOS x64 with the reproducer (LineBreakSample.java) attached to JDK-8165943 and the following group of tests:
`$JTREG_HOME/bin/jtreg -jdk:$BUILD_HOME ./test/jdk/java/awt/font`

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

Commit messages:
 - Removed unnecessary comment
 - 8165943: LineBreakMeasurer does not measure correctly if TextAttribute.TRACKING is set.

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

PR: https://git.openjdk.org/jdk/pull/10289


From jdv at openjdk.org  Fri Sep 16 05:47:46 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 16 Sep 2022 05:47:46 GMT
Subject: RFR: 6286501: JTabbedPane throws NPE from its stateChanged
 listener in particular case
In-Reply-To: <lqTnk1Sa-Qj3elOMsgW6WZkp_m3I3OQ_L2BdovhsieA=.8b329b54-c744-46cd-81e7-f4249a03f9f6@github.com>
References: <lqTnk1Sa-Qj3elOMsgW6WZkp_m3I3OQ_L2BdovhsieA=.8b329b54-c744-46cd-81e7-f4249a03f9f6@github.com>
Message-ID: <d30kjkprVGlq0hXptZFqfFl9k7D3FrptDfTXwBDWRXY=.7e116079-e141-48fe-93e0-ad6cf798f157@github.com>

On Thu, 8 Sep 2022 09:46:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> JTabbedPane throws NPE from its stateChanged listener as it tries to access uninstantiated TabbedPane.
> Fix is to use the tabPane passed to stateChangeListener so that correct tabPane is accessed.

Marked as reviewed by jdv (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10216


From psadhukhan at openjdk.org  Fri Sep 16 08:00:56 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 16 Sep 2022 08:00:56 GMT
Subject: RFR: 8271328: User is able to choose the color after disabling the
 color chooser. [v2]
In-Reply-To: <iQRBXhi_onmGlXXgNYjccREa-JACQbzx0Tjey1pC2zU=.a92b087d-eebb-4f50-bb31-c8fb00b1352f@github.com>
References: <dXWt4SdWl0Zj6wwwMcNWGEB9Q8tROYT-Y23cMUn4fLI=.9c994d26-4ffe-455e-919c-fb37b76371c7@github.com>
 <iQRBXhi_onmGlXXgNYjccREa-JACQbzx0Tjey1pC2zU=.a92b087d-eebb-4f50-bb31-c8fb00b1352f@github.com>
Message-ID: <2zYhH6pRs8nP0xekQkN398Gbe4yz6pIboPR0QTNrDgc=.55bcbd1a-e591-470e-95a1-b205f19c5ee8@github.com>

On Thu, 15 Sep 2022 11:14:50 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> The proposed solution for this defect is to check the color chooser enabled state. If it is disabled then disable all the components (spinner, textfield etc.) in panel and don't process the mouse event when user click on a color triangle or color wheel.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

Marked as reviewed by psadhukhan (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10276


From psadhukhan at openjdk.org  Fri Sep 16 08:00:56 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 16 Sep 2022 08:00:56 GMT
Subject: Integrated: JDK-8293767: AWT test TestSinhalaChar.java has old SCCS
 markings
In-Reply-To: <tZu0buhAOwRO0r3f6NM2QGu7dOay_6VyuvxbIR5TLp0=.fc8fb3a0-0c64-4daa-99de-2fddd5e7ee93@github.com>
References: <tZu0buhAOwRO0r3f6NM2QGu7dOay_6VyuvxbIR5TLp0=.fc8fb3a0-0c64-4daa-99de-2fddd5e7ee93@github.com>
Message-ID: <W7ozzBJdwzBiPg448dz27qRDa58U_-w_xRUKhkudNiQ=.8e6e18b0-44f6-44a9-890b-7f0c6b24992b@github.com>

On Thu, 15 Sep 2022 11:44:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Old SCCS markings removed from the jtreg tag.

This pull request has now been integrated.

Changeset: 141d5f5d
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/141d5f5deec488531e410af875c781f4b70490da
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8293767: AWT test TestSinhalaChar.java has old SCCS markings

Reviewed-by: iris

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

PR: https://git.openjdk.org/jdk/pull/10285


From aturbanov at openjdk.org  Fri Sep 16 08:15:48 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 16 Sep 2022 08:15:48 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v3]
In-Reply-To: <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>
Message-ID: <ioZ6TgIhc7n9J1b6BcT-N7EE5iIEOpaHL0xM--ZvxAw=.48e21fd7-e87c-4924-b22f-92618f098a89@github.com>

On Wed, 7 Sep 2022 16:23:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Default echo character obtained through `PasswordField.echoChar` UIProperty returns null for Nimbus L&F,
>> which is fixed by adding the default character * in the UIDefault table.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Honour PasswordField.echoChar property

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthPasswordFieldUI.java line 74:

> 72:         String prefix = getPropertyPrefix();
> 73:         Character echoChar = (Character)UIManager.getDefaults().get(prefix + ".echoChar");
> 74:         if(echoChar != null) {

let's add space after `if`

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

PR: https://git.openjdk.org/jdk/pull/10035


From tr at openjdk.org  Fri Sep 16 08:29:09 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 16 Sep 2022 08:29:09 GMT
Subject: RFR: 8271328: User is able to choose the color after disabling the
 color chooser. [v2]
In-Reply-To: <iQRBXhi_onmGlXXgNYjccREa-JACQbzx0Tjey1pC2zU=.a92b087d-eebb-4f50-bb31-c8fb00b1352f@github.com>
References: <dXWt4SdWl0Zj6wwwMcNWGEB9Q8tROYT-Y23cMUn4fLI=.9c994d26-4ffe-455e-919c-fb37b76371c7@github.com>
 <iQRBXhi_onmGlXXgNYjccREa-JACQbzx0Tjey1pC2zU=.a92b087d-eebb-4f50-bb31-c8fb00b1352f@github.com>
Message-ID: <z3poecARpcjfR_Bpd7TNKMeDByIfSrttMYUM_pxXd8M=.e61b35e6-c56a-4076-b7e9-7a51c8edf815@github.com>

On Thu, 15 Sep 2022 11:14:50 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> The proposed solution for this defect is to check the color chooser enabled state. If it is disabled then disable all the components (spinner, textfield etc.) in panel and don't process the mouse event when user click on a color triangle or color wheel.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

Marked as reviewed by tr (Author).

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

PR: https://git.openjdk.org/jdk/pull/10276


From alanb at openjdk.org  Fri Sep 16 09:45:14 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Sep 2022 09:45:14 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v3]
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <aZkbd6g9FC4Q6gGvqygI1B3F5tk6bj6JE6y17_lZGrw=.60e86c67-9f06-4b82-801a-131c3eb044bf@github.com>

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

Alan Bateman 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 10 additional commits since the last revision:

 - Repalce "it" with "victim thread"
 - Merge
 - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
 - become -> became in javadoc
 - Merge
 - Remove stopThread permission from RuntimePermission table, exclude jshell tests
 - Deprecate for removal
 - Next iteration, update dates in headers
 - Merge
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10230/files
  - new: https://git.openjdk.org/jdk/pull/10230/files/86424b65..a00f38a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=01-02

  Stats: 2575 lines in 102 files changed: 1741 ins; 370 del; 464 mod
  Patch: https://git.openjdk.org/jdk/pull/10230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10230/head:pull/10230

PR: https://git.openjdk.org/jdk/pull/10230


From jpai at openjdk.org  Fri Sep 16 10:03:51 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 Sep 2022 10:03:51 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v3]
In-Reply-To: <aZkbd6g9FC4Q6gGvqygI1B3F5tk6bj6JE6y17_lZGrw=.60e86c67-9f06-4b82-801a-131c3eb044bf@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <aZkbd6g9FC4Q6gGvqygI1B3F5tk6bj6JE6y17_lZGrw=.60e86c67-9f06-4b82-801a-131c3eb044bf@github.com>
Message-ID: <gGA9M5tP46bhCY9PI2iJWQ_2Cn82ti6v8m3T4LgWkOg=.500b0275-0ba5-4b4b-9d42-15cee27bad5b@github.com>

On Fri, 16 Sep 2022 09:45:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> Alan Bateman 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 10 additional commits since the last revision:
> 
>  - Repalce "it" with "victim thread"
>  - Merge
>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>  - become -> became in javadoc
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

Marked as reviewed by jpai (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10230


From mullan at openjdk.org  Fri Sep 16 13:16:53 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 16 Sep 2022 13:16:53 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v3]
In-Reply-To: <aZkbd6g9FC4Q6gGvqygI1B3F5tk6bj6JE6y17_lZGrw=.60e86c67-9f06-4b82-801a-131c3eb044bf@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <aZkbd6g9FC4Q6gGvqygI1B3F5tk6bj6JE6y17_lZGrw=.60e86c67-9f06-4b82-801a-131c3eb044bf@github.com>
Message-ID: <JdnXbrQe1rDRzupg-hiZip7CEa_7OuPafwdNWzpZods=.031f494b-eb2e-44e2-8f03-58220a34139b@github.com>

On Fri, 16 Sep 2022 09:45:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> Alan Bateman 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 10 additional commits since the last revision:
> 
>  - Repalce "it" with "victim thread"
>  - Merge
>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>  - become -> became in javadoc
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

Marked as reviewed by mullan (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10230


From duke at openjdk.org  Fri Sep 16 19:49:06 2022
From: duke at openjdk.org (ScientificWare)
Date: Fri, 16 Sep 2022 19:49:06 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v20]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <RXvCdL46ajICuB4PLDwgDQG59Qa8twwPzasUv_yssu4=.d43110a1-877c-4f6f-81fe-ffe9cd957189@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

  Misalignment comment delimiters.
  
  Corrects a misalignment of a comment delimiter.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/ac7b1731..f3989131

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=18-19

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

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Fri Sep 16 23:21:52 2022
From: duke at openjdk.org (ScientificWare)
Date: Fri, 16 Sep 2022 23:21:52 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color
Message-ID: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>

This is referenced in Java Bug Database as
- [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)

This is tracked in JBS as 
- [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)

Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
CSS Color Module Level 4
W3C Candidate Recommendation Snapshot, 5 July 2022
[6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)

Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)

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

Commit messages:
 - Adds final modifier.
 - Adds or removes spaces.
 - Removes int cast.
 - Update Copyrigth.
 - Remove NumberFormatException
 - Adds missing import and declaration.
 - Typo.
 - Adds new color hex formats.

Changes: https://git.openjdk.org/jdk/pull/10317/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293776
  Stats: 49 lines in 1 file changed: 28 ins; 3 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/10317.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10317/head:pull/10317

PR: https://git.openjdk.org/jdk/pull/10317


From aivanov at openjdk.org  Fri Sep 16 23:23:04 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 16 Sep 2022 23:23:04 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v28]
In-Reply-To: <1cVWZI5OKOOwYmaUzkHFmcT5N8idxaYQPmPg6NHBizk=.cd8ec33c-92d9-48c6-b4b8-9e661862fe25@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <itQkJngjXpuUQYlgAyQ1WNTyNQ2PoGsbQtVMalUFR40=.bb0cffdb-42cc-4383-83ba-9ddbb58d4d4e@github.com>
 <YPDUxqUA1R9PhW5_RWY-prKlvjPYVXzUv1pctQDQeps=.72fed5bc-37c4-44ef-84db-624f54c4ab19@github.com>
 <1cVWZI5OKOOwYmaUzkHFmcT5N8idxaYQPmPg6NHBizk=.cd8ec33c-92d9-48c6-b4b8-9e661862fe25@github.com>
Message-ID: <Mwnrb4JamgXJJRWXtYmbDRkBCFNs0MaI_wO2h0MURc4=.c558c364-d5c1-4f08-a0f6-414d9c795f2c@github.com>

On Thu, 15 Sep 2022 07:22:18 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> > So leaving aside what the native chooser does, we then just have to be consistent and round up.
> > That's what the current version is trying to do isn't it ?
> > Thoughts ?
> 
> Yeah, as per the current fix we are doing consistently round up for all file sizes.

Nearly.

It works correctly for KB:


      0      0.0 KB
      1      0.1 KB
     99      0.1 KB
    100      0.1 KB
    101      0.2 KB
    900      0.9 KB
    901      1.0 KB

999,000    999.0 KB
999,001    999.1 KB
999,900    999.9 KB
999,901      1.0 MB


But the rounding is not right as soon as the size is larger than 1 MB:


1,000,000    1.0 MB
1,000,001    1.0 MB
1,000,999    1.0 MB
1,001,000    1.1 MB


The kilobytes are ignored. The displayed size must be 1.1 MB for all the files but the first one.

And this is due to flooring the values by casting a double to long. The cast should be replaced with `Math.ceil`. The following patch resolves the problem:


diff --git a/src/java.desktop/share/classes/sun/swing/FilePane.java b/src/java.desktop/share/classes/sun/swing/FilePane.java
index 91935f0ed00..acc7dad6927 100644
--- a/src/java.desktop/share/classes/sun/swing/FilePane.java
+++ b/src/java.desktop/share/classes/sun/swing/FilePane.java
@@ -1194,7 +1194,7 @@ public class FilePane extends JPanel implements PropertyChangeListener {
                 Icon icon = chooser.getIcon(file);
                 setIcon(icon);
 
-            } else if (value instanceof Long len) {
+            } else if (value instanceof final Long len) {
                 /*
                  * This code block is relevant to Linux.
                  * File size is displayed up to 1 decimal precision.
@@ -1211,19 +1211,17 @@ public class FilePane extends JPanel implements PropertyChangeListener {
                     displayedFileSize[0] = roundToOneDecimalPlace(len);
                 } else {
                     double kbVal = roundToOneDecimalPlace(len);
-                    len = (long) kbVal;
                     if (kbVal < baseFileSize) {
                         updateMessageFormatPattern(kiloByteString);
                         displayedFileSize[0] = kbVal;
                     } else {
-                        double mbVal = roundToOneDecimalPlace(len);
-                        len = (long) mbVal;
+                        double mbVal = roundToOneDecimalPlace(Math.ceil(kbVal));
                         if (mbVal < baseFileSize) {
                             updateMessageFormatPattern(megaByteString);
                             displayedFileSize[0] = mbVal;
                         } else {
                             updateMessageFormatPattern(gigaByteString);
-                            displayedFileSize[0] = roundToOneDecimalPlace(len);
+                            displayedFileSize[0] = roundToOneDecimalPlace(Math.ceil(mbVal));
                         }
                     }
                 }
@@ -1254,7 +1252,7 @@ public class FilePane extends JPanel implements PropertyChangeListener {
          * @param fileSize the file size to round to one decimal place
          * @return file size rounded to one decimal place
          */
-        private static double roundToOneDecimalPlace(long fileSize) {
+        private static double roundToOneDecimalPlace(double fileSize) {
             return Math.ceil(fileSize / 100.0d) / 10.0d;
         }
     }


When the above patch is applied to the latest code in the PR, it produces the correct result for MBs as shown above as well as for GBs:


1,000,000,000    1.0 GB
1,000,000,001    1.1 GB

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Sat Sep 17 00:22:38 2022
From: duke at openjdk.org (ScientificWare)
Date: Sat, 17 Sep 2022 00:22:38 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v2]
In-Reply-To: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
Message-ID: <nkR-1xBOqOo3QdDeeV9ahS6AM2pcI7PP_5XTV4kbQCY=.6afe4781-a927-4f3a-a60e-e7339454eb88@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
> 
> This is tracked in JBS as 
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
> 
> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
> 
> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)

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

  Improper Name in comments
  
  Modifies the improper name of the recommendation with CSS Color Level 4.
  CSS Level 4 doesn't exist. CSS is a set of Modules, one of them is Color.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10317/files
  - new: https://git.openjdk.org/jdk/pull/10317/files/7a99e7ca..5b365172

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/10317


From alanb at openjdk.org  Sat Sep 17 08:41:19 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 17 Sep 2022 08:41:19 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

Alan Bateman 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 12 additional commits since the last revision:

 - Merge
 - Updates to Java Thread Primitive Deprecation page
 - Repalce "it" with "victim thread"
 - Merge
 - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
 - become -> became in javadoc
 - Merge
 - Remove stopThread permission from RuntimePermission table, exclude jshell tests
 - Deprecate for removal
 - Next iteration, update dates in headers
 - ... and 2 more: https://git.openjdk.org/jdk/compare/214db2f4...93806f99

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10230/files
  - new: https://git.openjdk.org/jdk/pull/10230/files/a00f38a2..93806f99

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=02-03

  Stats: 5663 lines in 389 files changed: 1218 ins; 1745 del; 2700 mod
  Patch: https://git.openjdk.org/jdk/pull/10230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10230/head:pull/10230

PR: https://git.openjdk.org/jdk/pull/10230


From duke at openjdk.org  Sat Sep 17 16:28:47 2022
From: duke at openjdk.org (ScientificWare)
Date: Sat, 17 Sep 2022 16:28:47 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v3]
In-Reply-To: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
Message-ID: <FMmw9qnp8D73Z8fNTbaUln5rIeyegaz_agJ7KfwBK2o=.15703fc8-8a7e-4e3e-8bcc-3bc71786f5b2@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
> 
> This is tracked in JBS as 
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
> 
> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
> 
> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)

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

  Adds regression test.
  
  Adds a regression for DK-8293776 : Adds CSS 4 and 8 digits hex coded Color #13

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10317/files
  - new: https://git.openjdk.org/jdk/pull/10317/files/5b365172..93dc0bbd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=01-02

  Stats: 93 lines in 1 file changed: 93 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10317.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10317/head:pull/10317

PR: https://git.openjdk.org/jdk/pull/10317


From duke at openjdk.org  Sat Sep 17 16:33:41 2022
From: duke at openjdk.org (ScientificWare)
Date: Sat, 17 Sep 2022 16:33:41 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v4]
In-Reply-To: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
Message-ID: <3zRRzGGzRP8MNyttEBCWWqHS3eXkmX-6DCR25ylScVc=.121df206-6a52-459f-88f9-0e135b802409@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
> 
> This is tracked in JBS as 
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
> 
> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
> 
> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)

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

  Removes author name.
  
  Removes author name for JDK main-line development repository.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10317/files
  - new: https://git.openjdk.org/jdk/pull/10317/files/93dc0bbd..24040cf6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/10317


From duke at openjdk.org  Sat Sep 17 17:16:41 2022
From: duke at openjdk.org (ExE Boss)
Date: Sat, 17 Sep 2022 17:16:41 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v4]
In-Reply-To: <3zRRzGGzRP8MNyttEBCWWqHS3eXkmX-6DCR25ylScVc=.121df206-6a52-459f-88f9-0e135b802409@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <3zRRzGGzRP8MNyttEBCWWqHS3eXkmX-6DCR25ylScVc=.121df206-6a52-459f-88f9-0e135b802409@github.com>
Message-ID: <3YYXAf08Oa8xLa6Ku6YpAsKGYP8D-YCSwwHhG8KXnlQ=.e7bf8ba3-093e-4fa5-b933-cb2be201e677@github.com>

On Sat, 17 Sep 2022 16:33:41 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
>> 
>> This is tracked in JBS as 
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
>> 
>> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
>> 
>> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes author name.
>   
>   Removes author name for JDK main-line development repository.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1404:

> 1402:         } else if (n != 8 || !hex.matcher(digits).matches()) {
> 1403:             return null;
> 1404:         }

Using `charAt` avoids creating temporary strings of length `1`.

Also, using?the `%[argument_index$]conversion` format?specifier?form allows?halving the?lengths of?the?vararg?arrays.
Suggestion:

        if (n == 3 && hex.matcher(digits).matches()) {
            final char r = digits.charAt(0);
            final char g = digits.charAt(1);
            final char b = digits.charAt(2);
            digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$sff", r, g, b);
        } else if (n == 4 && hex.matcher(digits).matches()) {
            final char r = digits.charAt(0);
            final char g = digits.charAt(1);
            final char b = digits.charAt(2);
            final char a = digits.charAt(3);
            digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$s%4$s%4$s", r, g, b, a);
        } else if (n == 6 && hex.matcher(digits).matches()) {
            digits += "ff";
        } else if (n != 8 || !hex.matcher(digits).matches()) {
            return null;
        }

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1407:

> 1405:         try {
> 1406:             Integer intValue = Integer.parseUnsignedInt(digits, 16);
> 1407:             int l = intValue.intValue();

No?need to?box only?to immediately?unbox[^1]:
Suggestion:

            int l = Integer.parseUnsignedInt(digits, 16);


[^1]: [`Integer.parseUnsignedInt(String,?int)`] returns?an?unboxed?`int`, not?a?boxed?`Integer`, it?s?[`Integer.valueOf(String,?int)`] that?does?that.

[`Integer.parseUnsignedInt(String,?int)`]: https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/Integer.html#parseUnsignedInt(java.lang.String,int)
[`Integer.valueOf(String,?int)`]: https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/Integer.html#valueOf(java.lang.String,int)

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

PR: https://git.openjdk.org/jdk/pull/10317


From prr at openjdk.org  Sat Sep 17 20:07:45 2022
From: prr at openjdk.org (Phil Race)
Date: Sat, 17 Sep 2022 20:07:45 GMT
Subject: RFR: 8292376: A few Swing methods use inheritDoc on exceptions
 which are not inherited [v3]
In-Reply-To: <7DrIMbypxFJ46pfk_b6CdZ030d6p8s-PUJM_XsyQZCI=.a72c2f2c-bbf8-4750-9758-848988642a4f@github.com>
References: <W1yenf_2rr8sMDSjJcKF-IGZa_mGYSG572YrlWcxH7w=.9388229b-7cd5-42b7-aaf8-00cdd955278a@github.com>
 <7DrIMbypxFJ46pfk_b6CdZ030d6p8s-PUJM_XsyQZCI=.a72c2f2c-bbf8-4750-9758-848988642a4f@github.com>
Message-ID: <4gKjpEX3UbnOGeDi4-ggsJ2k3qpc6Jdud775OZjxYMk=.e8e27d89-ecd7-479d-bcb6-7358e13fd1ee@github.com>

On Wed, 7 Sep 2022 07:47:59 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Document update for getBaselineResizeBehavior() and getBaseline() method description in JSpinner, AbstractBorder and TitledBorder .
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

Marked as reviewed by prr (Reviewer).

The bug report has no evaluation.
The PR just says "Doc update for Null Pointer Exception"
The bug should always have a proper evaluation and the PR can then refer to that or copy it.
The CSR has a lot of what should have appeared in these places too ..

Here's my take on it

The bug complains of 3 methods incorrectly using inheritdoc for NPE
and the resolution for each case is as follows

- javax.swing.JSpinner.DefaultEditor.getBaselineResizeBehavior()
It is unclear why the inheritdoc appears on this method.
This nested class extends JPanel and so the method is inherited from JComponent
and then in turn from Component and neither of these seems like it will throw NPE
The fix is to remove it - doc only no behavioural change.

- javax.swing.border.TitledBorder.getBaseline(java.awt.Component,int,int)
The superclass (AbstractBorder) method cannot throw NPE so inheritdoc is wrong.
However this method can throw NPE so the fix is to replace it with appropriate
documentation for this method. So also doc only no behavioural change.

- javax.swing.border.TitledBorder.getBaselineResizeBehavior(java.awt.Component)
 This method delegates to the super class method which can throw NPE but omits to specify it.
 The fix is to add the declaration to the super class method and then the inheritdoc
 is appropriate and can be left in place.  Again doc only no behavioural change.

So the changes look correct - it just is better with an explanation.

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

PR: https://git.openjdk.org/jdk/pull/9902


From duke at openjdk.org  Sun Sep 18 07:11:33 2022
From: duke at openjdk.org (ScientificWare)
Date: Sun, 18 Sep 2022 07:11:33 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v5]
In-Reply-To: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
Message-ID: <Yv1wUh24b7Bs9r2VsrcOpprbD9V8tYQeQENKwluOV9U=.c45cbb71-2160-48df-864f-4d8b98713bf7@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
> 
> This is tracked in JBS as 
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
> 
> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
> 
> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)

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

  Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java
  
  Sorry. Thanks.
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10317/files
  - new: https://git.openjdk.org/jdk/pull/10317/files/24040cf6..59709803

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/10317


From duke at openjdk.org  Sun Sep 18 09:33:42 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Sun, 18 Sep 2022 09:33:42 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v29]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <67J5y7EUu-fv68E35nDZIr7VVFjvhpJQOVpPQ-knbVo=.afe79c4e-8a9c-4146-9fc7-c0d29f211f66@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 KB.
> Manual Test Case "FileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Review comment fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/3d6ae268..6d2b9557

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=27-28

  Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Sun Sep 18 09:33:43 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Sun, 18 Sep 2022 09:33:43 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v28]
In-Reply-To: <itQkJngjXpuUQYlgAyQ1WNTyNQ2PoGsbQtVMalUFR40=.bb0cffdb-42cc-4383-83ba-9ddbb58d4d4e@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <itQkJngjXpuUQYlgAyQ1WNTyNQ2PoGsbQtVMalUFR40=.bb0cffdb-42cc-4383-83ba-9ddbb58d4d4e@github.com>
Message-ID: <TNcokAnRum7PG_XMdA3tl_1mCe9GemTPMTjb3il5cxM=.fa7c54ff-7135-4245-9309-4bdd2f357f7b@github.com>

On Tue, 13 Sep 2022 13:45:46 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

> > > So leaving aside what the native chooser does, we then just have to be consistent and round up.
> > > That's what the current version is trying to do isn't it ?
> > > Thoughts ?
> > 
> > 
> > Yeah, as per the current fix we are doing consistently round up for all file sizes.
> 
> Nearly.
> 
> It works correctly for KB:
> 
> ```
>       0      0.0 KB
>       1      0.1 KB
>      99      0.1 KB
>     100      0.1 KB
>     101      0.2 KB
>     900      0.9 KB
>     901      1.0 KB
> 
> 999,000    999.0 KB
> 999,001    999.1 KB
> 999,900    999.9 KB
> 999,901      1.0 MB
> ```
> 
> But the rounding is not right as soon as the size is larger than 1 MB:
> 
> ```
> 1,000,000    1.0 MB
> 1,000,001    1.0 MB
> 1,000,999    1.0 MB
> 1,001,000    1.1 MB
> ```
> 
> The kilobytes are ignored. The displayed size must be 1.1 MB for all the files but the first one.
> 
> And this is due to flooring the values by casting a double to long. The cast should be replaced with `Math.ceil`. The following patch resolves the problem:
> 
> ```diff
> diff --git a/src/java.desktop/share/classes/sun/swing/FilePane.java b/src/java.desktop/share/classes/sun/swing/FilePane.java
> index 91935f0ed00..acc7dad6927 100644
> --- a/src/java.desktop/share/classes/sun/swing/FilePane.java
> +++ b/src/java.desktop/share/classes/sun/swing/FilePane.java
> @@ -1194,7 +1194,7 @@ public class FilePane extends JPanel implements PropertyChangeListener {
>                  Icon icon = chooser.getIcon(file);
>                  setIcon(icon);
>  
> -            } else if (value instanceof Long len) {
> +            } else if (value instanceof final Long len) {
>                  /*
>                   * This code block is relevant to Linux.
>                   * File size is displayed up to 1 decimal precision.
> @@ -1211,19 +1211,17 @@ public class FilePane extends JPanel implements PropertyChangeListener {
>                      displayedFileSize[0] = roundToOneDecimalPlace(len);
>                  } else {
>                      double kbVal = roundToOneDecimalPlace(len);
> -                    len = (long) kbVal;
>                      if (kbVal < baseFileSize) {
>                          updateMessageFormatPattern(kiloByteString);
>                          displayedFileSize[0] = kbVal;
>                      } else {
> -                        double mbVal = roundToOneDecimalPlace(len);
> -                        len = (long) mbVal;
> +                        double mbVal = roundToOneDecimalPlace(Math.ceil(kbVal));
>                          if (mbVal < baseFileSize) {
>                              updateMessageFormatPattern(megaByteString);
>                              displayedFileSize[0] = mbVal;
>                          } else {
>                              updateMessageFormatPattern(gigaByteString);
> -                            displayedFileSize[0] = roundToOneDecimalPlace(len);
> +                            displayedFileSize[0] = roundToOneDecimalPlace(Math.ceil(mbVal));
>                          }
>                      }
>                  }
> @@ -1254,7 +1252,7 @@ public class FilePane extends JPanel implements PropertyChangeListener {
>           * @param fileSize the file size to round to one decimal place
>           * @return file size rounded to one decimal place
>           */
> -        private static double roundToOneDecimalPlace(long fileSize) {
> +        private static double roundToOneDecimalPlace(double fileSize) {
>              return Math.ceil(fileSize / 100.0d) / 10.0d;
>          }
>      }
> ```
> 
> When the above patch is applied to the latest code in the PR, it produces the correct result for MBs as shown above as well as for GBs:
> 
> ```
> 1,000,000,000    1.0 GB
> 1,000,000,001    1.1 GB
> ```

Updated the patch to latest commit and it shows correct result for MBs and GBs files as you mentioned above.

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Sun Sep 18 15:21:29 2022
From: duke at openjdk.org (ScientificWare)
Date: Sun, 18 Sep 2022 15:21:29 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v6]
In-Reply-To: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
Message-ID: <592sDW2VIvByGwKDoAYG5P7a4Iygc5CYtPVG7vr9qrk=.12f3db5e-a3a7-41c6-b5f9-e1588507bbe2@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
> 
> This is tracked in JBS as 
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
> 
> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
> 
> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)

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

  Corrects typos and digit extraction.
  
  Corrects typos.
  And applies a better digit extraction as suggested in main-line review thread.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10317/files
  - new: https://git.openjdk.org/jdk/pull/10317/files/59709803..e6454c11

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/10317


From duke at openjdk.org  Sun Sep 18 15:32:36 2022
From: duke at openjdk.org (ScientificWare)
Date: Sun, 18 Sep 2022 15:32:36 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v4]
In-Reply-To: <3YYXAf08Oa8xLa6Ku6YpAsKGYP8D-YCSwwHhG8KXnlQ=.e7bf8ba3-093e-4fa5-b933-cb2be201e677@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <3zRRzGGzRP8MNyttEBCWWqHS3eXkmX-6DCR25ylScVc=.121df206-6a52-459f-88f9-0e135b802409@github.com>
 <3YYXAf08Oa8xLa6Ku6YpAsKGYP8D-YCSwwHhG8KXnlQ=.e7bf8ba3-093e-4fa5-b933-cb2be201e677@github.com>
Message-ID: <epTePqs85KjTvlJl5gccEY4bwesRUpjSOsRZHuGDjNw=.3996651f-a13e-4625-8701-dafe4b00594a@github.com>

On Sat, 17 Sep 2022 17:00:30 GMT, ExE Boss <duke at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removes author name.
>>   
>>   Removes author name for JDK main-line development repository.
>
> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1404:
> 
>> 1402:         } else if (n != 8 || !hex.matcher(digits).matches()) {
>> 1403:             return null;
>> 1404:         }
> 
> Using `charAt` avoids creating temporary strings of length `1`.
> 
> Also, using?the `%[argument_index$]conversion` format?specifier?form allows?halving the?lengths of?the?vararg?arrays.
> Suggestion:
> 
>         if (n == 3 && hex.matcher(digits).matches()) {
>             final char r = digits.charAt(0);
>             final char g = digits.charAt(1);
>             final char b = digits.charAt(2);
>             digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$sff", r, g, b);
>         } else if (n == 4 && hex.matcher(digits).matches()) {
>             final char r = digits.charAt(0);
>             final char g = digits.charAt(1);
>             final char b = digits.charAt(2);
>             final char a = digits.charAt(3);
>             digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$s%4$s%4$s", r, g, b, a);
>         } else if (n == 6 && hex.matcher(digits).matches()) {
>             digits += "ff";
>         } else if (n != 8 || !hex.matcher(digits).matches()) {
>             return null;
>         }

@ExE-Boss The GitHub "Commit suggestion" didn't work ! I received an error message. I had to make changes "by hand".

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

PR: https://git.openjdk.org/jdk/pull/10317


From tr at openjdk.org  Mon Sep 19 06:00:46 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 19 Sep 2022 06:00:46 GMT
Subject: RFR: 8292376: A few Swing methods use inheritDoc on exceptions
 which are not inherited [v3]
In-Reply-To: <7DrIMbypxFJ46pfk_b6CdZ030d6p8s-PUJM_XsyQZCI=.a72c2f2c-bbf8-4750-9758-848988642a4f@github.com>
References: <W1yenf_2rr8sMDSjJcKF-IGZa_mGYSG572YrlWcxH7w=.9388229b-7cd5-42b7-aaf8-00cdd955278a@github.com>
 <7DrIMbypxFJ46pfk_b6CdZ030d6p8s-PUJM_XsyQZCI=.a72c2f2c-bbf8-4750-9758-848988642a4f@github.com>
Message-ID: <q1MzNY9bVQZLRFhDELOjG4GVq9ZoK2Wkjnv7wwmgSMI=.e4395790-e3d7-44cb-8a73-1467f927aec6@github.com>

On Wed, 7 Sep 2022 07:47:59 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> Document update for getBaselineResizeBehavior() and getBaseline() method description in JSpinner, AbstractBorder and TitledBorder .
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

Marked as reviewed by tr (Author).

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

PR: https://git.openjdk.org/jdk/pull/9902


From dnguyen at openjdk.org  Mon Sep 19 06:45:45 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 19 Sep 2022 06:45:45 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v5]
In-Reply-To: <PekUUNpC2oxcidxOrEBr-JOmBIyrANdJo0k37mDH1tU=.edd6d308-421c-4b4b-a71e-a6b885e1c71a@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <2WFsgc4z6xE1yQQl2_LQxnr3ji7Uwrp0KtzucAz_mUQ=.941647bc-f562-41b6-af06-9dfca2262d81@github.com>
 <aiGrm0biUjAb0wZAsbR2fW7bvKYjGeNoYug1MLvOk3A=.5f43448f-0636-4ddd-a73c-580381cb955f@github.com>
 <PekUUNpC2oxcidxOrEBr-JOmBIyrANdJo0k37mDH1tU=.edd6d308-421c-4b4b-a71e-a6b885e1c71a@github.com>
Message-ID: <84IMQ_7HppdVBHJQGoMP308KeZYMp2ceM5gTM6HTRW8=.94108932-6f70-47b9-b46f-c60634cfd94f@github.com>

On Tue, 23 Aug 2022 05:45:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> @andy-goryachev-oracle I took into consideration your comment regarding RTL and LTR behavior regarding JComboBoxes. I did the testing as we briefly discussed and all results led me to believe Aqua L&F combo boxes only supported the button being on the right. Will still need to check with a device natively set to RTL, but it turns out a nearly decade old JBS issue already exists for this JComboBox button issue. I'll leave that separate from this PR and possibly look into that other issue later.
>
>> @andy-goryachev-oracle I took into consideration your comment regarding RTL and LTR behavior regarding JComboBoxes. I did the testing as we briefly discussed and all results led me to believe Aqua L&F combo boxes only supported the button being on the right. Will still need to check with a device natively set to RTL, but it turns out a nearly decade old JBS issue already exists for this JComboBox button issue. I'll leave that separate from this PR and possibly look into that other issue later.
> 
> Yes, [JDK-8023912](https://bugs.openjdk.org/browse/JDK-8023912)...
> I am not sure if this RTL is an issue. I guess it was mentioned in our meeting that RTL should not affect JComboBox button. 
> Maybe another question for apple, since the button image drawn by JRS?

@prsadhuk Could you sponsor this PR?

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

PR: https://git.openjdk.org/jdk/pull/9473


From aturbanov at openjdk.org  Mon Sep 19 07:03:38 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 19 Sep 2022 07:03:38 GMT
Subject: RFR: 8293984: Unnecessary Vector usage in PropertyEditorSupport
Message-ID: <d_Iu8wlX0aPiKtfN2F6okrdy8lyeM8zzG8F8Dett58E=.1bfbea3a-8bd1-4b46-8f14-8a860049081f@github.com>

Field PropertyEditorSupport.listeners is accessed only under `synchronized(this)`.
It means extra synchronization by Vector is not needed.

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

Commit messages:
 - [PATCH] Unnecessary Vector usage in PropertyEditorSupport

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

PR: https://git.openjdk.org/jdk/pull/10331


From aturbanov at openjdk.org  Mon Sep 19 07:14:57 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 19 Sep 2022 07:14:57 GMT
Subject: RFR: JDK-8263467: Incorrect double-checked locking in
 sun.java2d.CRenderer [v2]
In-Reply-To: <kHqn5LKHE-Ik-aJJ4cFATDAn1oEW7q1lHUj38QfSE9o=.e1cc7adf-5943-4f08-9515-b89247b6dda8@github.com>
References: <ZAfgFTYJDWkDgRxjL7ImOf0t73VhZXsnZdamRe76x6o=.adb2a7e2-d92c-4a10-85be-f7a15b287da6@github.com>
 <kHqn5LKHE-Ik-aJJ4cFATDAn1oEW7q1lHUj38QfSE9o=.e1cc7adf-5943-4f08-9515-b89247b6dda8@github.com>
Message-ID: <l5IrlhxwmvvxWdOpaOz8bijNzq3AveVtRQB0sC6Pdv0=.9dc58157-c165-4eb5-a0b8-8c42007a9d3f@github.com>

On Fri, 12 Mar 2021 07:22:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> SonarCloud reports multiple incorrect double-checked locking cases in `sun.java2d.CRenderer`. For example:
>> 
>> 
>>   Arc2D arcToShape;
>> 
>>   ...
>>             if (arcToShape == null) {
>>                 synchronized (this) {
>>                     if (arcToShape == null) {
>>                         arcToShape = new Arc2D.Float();
>>                     }
>>                 }
>>             }
>> 
>> 
>> `Arc2D` contains fields that are not `final`. `arcToShape` is not `volatile`. This makes it an incorrect DCL.
>> This code is used by Mac OS, do it would probably blow up some time later on M1.
>> 
>> This is the candidate fix that preserves the semantics. I am doing this fix blindly so far, without testing on real Mac OS. But maybe there is no need to do any of this, because the setter methods overwrite the contents of all these objects under their own sync. So, maybe we can just allocate those objects without DCL-backed caching and pass them in?
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop DCL and useless synchronization completely

Seems this PR was lost for some reason.
@shipilev can you please reopen it?

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

PR: https://git.openjdk.org/jdk/pull/2948


From aivanov at openjdk.org  Mon Sep 19 08:05:06 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 Sep 2022 08:05:06 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v29]
In-Reply-To: <67J5y7EUu-fv68E35nDZIr7VVFjvhpJQOVpPQ-knbVo=.afe79c4e-8a9c-4146-9fc7-c0d29f211f66@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <67J5y7EUu-fv68E35nDZIr7VVFjvhpJQOVpPQ-knbVo=.afe79c4e-8a9c-4146-9fc7-c0d29f211f66@github.com>
Message-ID: <M9WXqA3WJuSSJtvOUK7q0qe-GBi7iQJwAG2YLoeGS-E=.96a0fb59-e6a6-425c-8d91-bead6de1f220@github.com>

On Sun, 18 Sep 2022 09:33:42 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Mon Sep 19 10:02:08 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 19 Sep 2022 10:02:08 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v7]
In-Reply-To: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
Message-ID: <u4pHyoq95hsu2m40nMVR-_3d8CXlQyCYBvLRVJODeZ4=.83cf3a21-2f7f-4b65-8c33-0ba50ebd98e7@github.com>

> Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
> I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.

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

  Do not ignore 0 divider size

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9566/files
  - new: https://git.openjdk.org/jdk/pull/9566/files/ec9429aa..e876ddbc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9566&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9566&range=05-06

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9566.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9566/head:pull/9566

PR: https://git.openjdk.org/jdk/pull/9566


From psadhukhan at openjdk.org  Mon Sep 19 10:27:55 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 19 Sep 2022 10:27:55 GMT
Subject: Integrated: 6286501: JTabbedPane throws NPE from its stateChanged
 listener in particular case
In-Reply-To: <lqTnk1Sa-Qj3elOMsgW6WZkp_m3I3OQ_L2BdovhsieA=.8b329b54-c744-46cd-81e7-f4249a03f9f6@github.com>
References: <lqTnk1Sa-Qj3elOMsgW6WZkp_m3I3OQ_L2BdovhsieA=.8b329b54-c744-46cd-81e7-f4249a03f9f6@github.com>
Message-ID: <HT_q_Z7dbQYGekwv1l0hLnvHMw14bBQ9KCR8f3WjELM=.e069bc3e-3b16-49c6-be1f-492db00ec639@github.com>

On Thu, 8 Sep 2022 09:46:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> JTabbedPane throws NPE from its stateChanged listener as it tries to access uninstantiated TabbedPane.
> Fix is to use the tabPane passed to stateChangeListener so that correct tabPane is accessed.

This pull request has now been integrated.

Changeset: ab7f58a3
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ab7f58a3771f5f8e7240f53d595bdf91a17874d2
Stats:     77 lines in 2 files changed: 76 ins; 0 del; 1 mod

6286501: JTabbedPane throws NPE from its stateChanged listener in particular case

Reviewed-by: jdv

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

PR: https://git.openjdk.org/jdk/pull/10216


From duke at openjdk.org  Mon Sep 19 11:34:53 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Mon, 19 Sep 2022 11:34:53 GMT
Subject: Integrated: 8271328: User is able to choose the color after disabling
 the color chooser.
In-Reply-To: <dXWt4SdWl0Zj6wwwMcNWGEB9Q8tROYT-Y23cMUn4fLI=.9c994d26-4ffe-455e-919c-fb37b76371c7@github.com>
References: <dXWt4SdWl0Zj6wwwMcNWGEB9Q8tROYT-Y23cMUn4fLI=.9c994d26-4ffe-455e-919c-fb37b76371c7@github.com>
Message-ID: <IntcFpE17F6ij6jg2o-pwRnto7anK11YzTqfa2l67RM=.44430b93-67c8-49ce-87e9-1f934cf0d3a1@github.com>

On Thu, 15 Sep 2022 06:07:30 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> The proposed solution for this defect is to check the color chooser enabled state. If it is disabled then disable all the components (spinner, textfield etc.) in panel and don't process the mouse event when user click on a color triangle or color wheel.

This pull request has now been integrated.

Changeset: b920d299
Author:    Abhishek Kumar <abhishek.cx.kumar at oracle.com>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b920d2999fed5ec5afe666559e14f8e1a0e90852
Stats:     118 lines in 2 files changed: 118 ins; 0 del; 0 mod

8271328: User is able to choose the color after disabling the color chooser.

Reviewed-by: psadhukhan, tr

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

PR: https://git.openjdk.org/jdk/pull/10276


From dnguyen at openjdk.org  Mon Sep 19 11:36:37 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 19 Sep 2022 11:36:37 GMT
Subject: Integrated: 8054572: [macosx] JComboBox paints the border incorrectly
In-Reply-To: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
Message-ID: <H3yP9VeXqZzsiZLsbnOVWiH4JkmRo_m6VSv1dszmKPE=.41e76123-1dc8-4656-901d-0d4e16d4a23b@github.com>

On Tue, 12 Jul 2022 18:16:06 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
> 
> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
> 
> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.

This pull request has now been integrated.

Changeset: 8082c24a
Author:    Damon Nguyen <dnguyen at openjdk.org>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8082c24a0df3f4861ea391266bdfe6cdd1a77bab
Stats:     123 lines in 2 files changed: 120 ins; 2 del; 1 mod

8054572: [macosx] JComboBox paints the border incorrectly

Reviewed-by: honkar, psadhukhan

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

PR: https://git.openjdk.org/jdk/pull/9473


From aivanov at openjdk.org  Mon Sep 19 14:25:53 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 Sep 2022 14:25:53 GMT
Subject: Integrated: 8293811: Provide a reason for PassFailJFrame.forceFail
In-Reply-To: <4UPN6ayNXV_zTOkwv12NUxxXOlFpISWUC5qO6_HPK_w=.16c4cbd2-069c-43cf-afbf-95e8fc6f9aea@github.com>
References: <4UPN6ayNXV_zTOkwv12NUxxXOlFpISWUC5qO6_HPK_w=.16c4cbd2-069c-43cf-afbf-95e8fc6f9aea@github.com>
Message-ID: <D5f55sHPNTCFUzdKI4dixR1A74MLUc16ls8bYQKGaSY=.ffeb4be1-94b4-469c-9c40-aacb3cebf53d@github.com>

On Wed, 14 Sep 2022 16:27:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Add `forceFail` implementation which allows passing the reason why the test is failed.
> 
> I used the newly added method `forceFail(reason)` instead of throwing an exception in `PrintAllPagesTest`. When the test is run outside of jtreg and printing is cancelled, the the test UI becomes ?hung?: clicking Pass or Fail or closing windows does not stop the test.
> 
> I also converted the `ret` field to local variable.
> 
> In addition to this, I reduced the size of the test frame, its size of 1000?800 doesn't fit even full HD screens when positioned close to the instruction frame.

This pull request has now been integrated.

Changeset: 64b96e5c
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64b96e5cf57023a5d55b4392074e3922ac7c0534
Stats:     26 lines in 2 files changed: 16 ins; 2 del; 8 mod

8293811: Provide a reason for PassFailJFrame.forceFail

Reviewed-by: honkar, jdv

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

PR: https://git.openjdk.org/jdk/pull/10269


From tr at openjdk.org  Mon Sep 19 17:13:54 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 19 Sep 2022 17:13:54 GMT
Subject: RFR: 5074006: Swing JOptionPane shows </html> tag as a string
 after newline [v2]
In-Reply-To: <2BmZo0HFOMAvei4VnM5WPD_BoIauCM1nyhnuipD8oV0=.a4b8b627-6d68-4789-99b8-bdd09c8a9cf0@github.com>
References: <DWhqieaffzn6xk--zvJwqX4LVNFtVnuI-5rnfuFGTL0=.55ec4218-3188-4917-9233-cbce1562f3e2@github.com>
 <2BmZo0HFOMAvei4VnM5WPD_BoIauCM1nyhnuipD8oV0=.a4b8b627-6d68-4789-99b8-bdd09c8a9cf0@github.com>
Message-ID: <v-ZCJI9fpEbSJ5AYWTc8fa6LXklVkL-F8CsRznZHXtI=.6994210e-40ab-4193-bd12-dc5b14507374@github.com>

On Mon, 12 Sep 2022 11:47:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If JOptionPane's message contains both linefeed/cursor return and HTML tag ie, **<html\>" + "This is a test\n" + "</html\>**,
>> then  "</html\>" will be shown in the JOptionPane dialog box because after every new line it creates a new messageComponent so the characters after the newline ie "</html\>"tag will be considered as a new JLabel string and displayed.
>> 
>> Fix is to ignore closing html tag if appearing after newline from the displayed string.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix handling HTML message

Tested and verified.

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

Marked as reviewed by tr (Author).

PR: https://git.openjdk.org/jdk/pull/10081


From tr at openjdk.org  Mon Sep 19 18:07:46 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 19 Sep 2022 18:07:46 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is
 not shown on disabled checkbox and radio button with Nimbus LAF
In-Reply-To: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
References: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
Message-ID: <0fGlOOIR6R4sng-IHU5xvUvMDMJ1jhj8jrr_PiHgFLA=.2febb9b9-556a-41fc-8a6f-69bc890f5ffd@github.com>

On Tue, 6 Sep 2022 05:57:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CheckBox.disabledText and RadioButton.disabledText color UIProperty is not honoured by Nimbus L&F when disabled text is drawn for JCheckBox and JRadioButton, so disabled text color was rendered incorrectly.
> Fix is to honour these UIProperty color if they are set by user, else use the color from the component or via getColorForState().
> 
> Closed test as mentioned in JBS is used to check the fix.

Fix tested and verified.

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

Marked as reviewed by tr (Author).

PR: https://git.openjdk.org/jdk/pull/10177


From aivanov at openjdk.org  Mon Sep 19 18:15:49 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 Sep 2022 18:15:49 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v6]
In-Reply-To: <592sDW2VIvByGwKDoAYG5P7a4Iygc5CYtPVG7vr9qrk=.12f3db5e-a3a7-41c6-b5f9-e1588507bbe2@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <592sDW2VIvByGwKDoAYG5P7a4Iygc5CYtPVG7vr9qrk=.12f3db5e-a3a7-41c6-b5f9-e1588507bbe2@github.com>
Message-ID: <DmaK20O4iPQJGHZyci3IQEsFFbdhnBgMmB4Aok-GE9g=.4884358d-108b-4115-a948-180727268137@github.com>

On Sun, 18 Sep 2022 15:21:29 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
>> 
>> This is tracked in JBS as 
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
>> 
>> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
>> 
>> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrects typos and digit extraction.
>   
>   Corrects typos.
>   And applies a better digit extraction as suggested in main-line review thread.

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1366:

> 1364:             digits = digits.substring(1, Math.min(n, 9));
> 1365:             n--;
> 1366:         }

Should the method return `null` immediately if `n < 3 || n > 8` after the if block at lines 1363-1366? It's already known the format is invalid.

I also propose adding `hex.matcher(digits).matches()` here to avoid running the matcher at each attempt.

In short, the next statement should be:


if (n < 3 || n == 7 || n > 8 || !hex.matcher(digits).matches()) {
    return null;
}


The following code deals with a valid color notation.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1399:

> 1397:             final char b = digits.charAt(2);
> 1398:             final char a = digits.charAt(3);
> 1399:             digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$s%4$s%4$s", r, g, b, a);

Does it make sense to combine these two cases into one?

Suggestion:

        if (n == 3 || n == 4) {
            final char r = digits.charAt(0);
            final char g = digits.charAt(1);
            final char b = digits.charAt(2);
            final char a = n == 4 ? digits.charAt(3) : 'f';
            digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$s%4$s%4$s", r, g, b, a);


The only difference between these two case is in `a` which is hard-coded as `ff` in the format string for `n == 3`.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1406:

> 1404:         }
> 1405:         try {
> 1406:             int l = Integer.parseUnsignedInt(digits, 16);

It's not recommended to use `l` as an identifier because it could be confused with `1`. I propose `x` (hex), `v` (value), or even `i` (int). If you rename `n` to `len`, then `n` will be another option.

test/jdk/javax/swing/text/html/CSS/Hex3468DigitsColor.java line 9:

> 7:  * published by the Free Software Foundation.  Oracle designates this
> 8:  * particular file as subject to the "Classpath" exception as provided
> 9:  * by Oracle in the LICENSE file that accompanied this code.

Tests must not include *the "Classpath" exception*.

test/jdk/javax/swing/text/html/CSS/Hex3468DigitsColor.java line 71:

> 69:         alpha = color.getAlpha();
> 70:         result.append("\n  Test for #ff1122aa");
> 71:         if (red != 255) {

`red`, `green` and `blue` haven't changed here. You may want to get them from the `color` object.

Alternatively, you can compare the RGB:

if (0xaaff1122 != color.getRGB()) {
    // fail the test
}

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

PR: https://git.openjdk.org/jdk/pull/10317


From honkar at openjdk.org  Mon Sep 19 18:25:47 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 19 Sep 2022 18:25:47 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v2]
In-Reply-To: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
Message-ID: <hq4fw0TvjG57Xt36S774I-661Y6R-ZDOa_MoerInAZc=.906e64f5-b8dd-4060-84de-0e396903e2be@github.com>

> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
> 
> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
> 
> The test is generic though the issue and fix is on Windows platform because the condition 
> `frame.getSize() == frame.getPreferredSize()` should be true on all platforms when frame.pack() is called.
> 
> Following is the link to Windows System Metrics (used for native insets) - https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics

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

 - Merge branch 'master' into NonResize_8288325
 - Non-Resizable AWT Frame insets fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9954/files
  - new: https://git.openjdk.org/jdk/pull/9954/files/63bacba0..04c26764

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9954&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9954&range=00-01

  Stats: 103852 lines in 1920 files changed: 48811 ins; 42648 del; 12393 mod
  Patch: https://git.openjdk.org/jdk/pull/9954.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9954/head:pull/9954

PR: https://git.openjdk.org/jdk/pull/9954


From aivanov at openjdk.org  Mon Sep 19 19:04:50 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 Sep 2022 19:04:50 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v20]
In-Reply-To: <RXvCdL46ajICuB4PLDwgDQG59Qa8twwPzasUv_yssu4=.d43110a1-877c-4f6f-81fe-ffe9cd957189@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <RXvCdL46ajICuB4PLDwgDQG59Qa8twwPzasUv_yssu4=.d43110a1-877c-4f6f-81fe-ffe9cd957189@github.com>
Message-ID: <LI-NCUccrf7gvmwLmzJjM528sCXHsEQfWX8F_YfGpq8=.d28d4d7e-9461-4339-8453-dd204fd2778d@github.com>

On Fri, 16 Sep 2022 19:49:06 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Misalignment comment delimiters.
>   
>   Corrects a misalignment of a comment delimiter.

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/text/html/CSS/MissingColorNames.java line 9:

> 7:  * published by the Free Software Foundation.  Oracle designates this
> 8:  * particular file as subject to the "Classpath" exception as provided
> 9:  * by Oracle in the LICENSE file that accompanied this code.

Tests must not include the "Classpath" exception.

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

PR: https://git.openjdk.org/jdk/pull/9825


From kizune at openjdk.org  Mon Sep 19 19:44:45 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 19 Sep 2022 19:44:45 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame
In-Reply-To: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
Message-ID: <glDfktBW_QWp6lWhUl9nS7woY9CLFYPu1N-TbBjD1Ao=.eb0a6ac1-25f3-4e05-ac11-22c75f370674@github.com>

On Wed, 14 Sep 2022 18:33:47 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> JInternalFrame background color seems to overflow into the border region. This issue is more prominently seen on Windows - Metal LAF (with fractional scaling, as shown below). The primary reason is border scaling issue as observed in  - [JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614) & [JDK-8282958](https://bugs.openjdk.org/browse/JDK-8282958)
> 
> The fix involves a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. The test checks the midpoint and corners of borders to check if the internal frame's background color is located out of JInternalFrame.
> 
> ![image](https://user-images.githubusercontent.com/95945681/190233555-a7e00f2c-9003-4c11-84fb-207957838c2f.png)

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 242:

> 240:     @SuppressWarnings("serial") // Superclass is not serializable across versions
> 241:     public static class InternalFrameBorder extends AbstractBorder implements UIResource {
> 242:         private static int corner = 14;

Before it was final, now it is not and it is static - means you are changing it down the line. What will happen if two instances will try to change it in a different ways - i.e. if there are more than one window and they are on a screens with different scale factors? I do not really get the logic - either this value is a local one and being calculated for each instance or it is a final and constant for all. And seeing how you update it continuously - will it not accumulate this change is paintBorder will be called multiple times?

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

PR: https://git.openjdk.org/jdk/pull/10274


From honkar at openjdk.org  Mon Sep 19 20:19:54 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 19 Sep 2022 20:19:54 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame
In-Reply-To: <glDfktBW_QWp6lWhUl9nS7woY9CLFYPu1N-TbBjD1Ao=.eb0a6ac1-25f3-4e05-ac11-22c75f370674@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <glDfktBW_QWp6lWhUl9nS7woY9CLFYPu1N-TbBjD1Ao=.eb0a6ac1-25f3-4e05-ac11-22c75f370674@github.com>
Message-ID: <M46IdjY_mvO3acH7wyiG2wl4-RdfJs-bP9Qkdyy-gd4=.1bedc26b-942d-4bd7-89c1-e6598b78c95e@github.com>

On Mon, 19 Sep 2022 19:42:29 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> JInternalFrame background color seems to overflow into the border region. This issue is more prominently seen on Windows - Metal LAF (with fractional scaling, as shown below). The primary reason is border scaling issue as observed in  - [JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614) & [JDK-8282958](https://bugs.openjdk.org/browse/JDK-8282958)
>> 
>> The fix involves a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. The test checks the midpoint and corners of borders to check if the internal frame's background color is located out of JInternalFrame.
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/190233555-a7e00f2c-9003-4c11-84fb-207957838c2f.png)
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 242:
> 
>> 240:     @SuppressWarnings("serial") // Superclass is not serializable across versions
>> 241:     public static class InternalFrameBorder extends AbstractBorder implements UIResource {
>> 242:         private static int corner = 14;
> 
> Before it was final, now it is not and it is static - means you are changing it down the line. What will happen if two instances will try to change it in a different ways - i.e. if there are more than one window and they are on a screens with different scale factors? I do not really get the logic - either this value is a local one and being calculated for each instance or it is a final and constant for all. And seeing how you update it continuously - will it not accumulate this change is paintBorder will be called multiple times?

@azuev-java Thank you for reviewing and bringing up - **_"multiple windows on multiple screens with different scaling"_** scenario. I missed accounting for the above scenario in the present fix. Yes, I believe that `corner` should be local variable that is calculated depending on the screen's scale on which it is displayed. 

I was also thinking if we can - may be precompute & store all the corner values in a `HashMap` for all the scale values that we can expect?

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

PR: https://git.openjdk.org/jdk/pull/10274


From honkar at openjdk.org  Mon Sep 19 21:31:48 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 19 Sep 2022 21:31:48 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v3]
In-Reply-To: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
Message-ID: <7U4stw4f0Nu9D1U0qtZBLVmzp-HntyWr5re1KDixw1Y=.234b63ff-c1a7-42c8-87a5-62f3387d4422@github.com>

> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
> 
> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
> 
> The test is generic though the issue and fix is on Windows platform because the condition 
> `frame.getSize() == frame.getPreferredSize()` should be true on all platforms when frame.pack() is called.
> 
> Following is the link to Windows System Metrics (used for native insets) - https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics

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

  updated fix to get the right insets for Non-Resizable frame

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9954/files
  - new: https://git.openjdk.org/jdk/pull/9954/files/04c26764..9bec5c34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9954&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9954&range=01-02

  Stats: 16 lines in 2 files changed: 1 ins; 10 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9954.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9954/head:pull/9954

PR: https://git.openjdk.org/jdk/pull/9954


From honkar at openjdk.org  Mon Sep 19 21:39:13 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 19 Sep 2022 21:39:13 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v3]
In-Reply-To: <_Fu286WNCl5BafCscQ293DwCjpJ0C4SnXMkUHjLZvyY=.6c3abdca-9331-4974-99af-e6dc50baa1c4@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <cdRzm-sk68j0WgIWw2W8x7lQ_6Srmhlyo-h2BD7Dvfo=.931e46c3-8ec4-4efc-9e14-3878ec6dbf34@github.com>
 <xoXoBIymERTNe4aeom-6qlkjqZj7xZxDyV9nD_geBnE=.6b0d75f8-f3b3-4354-978c-acfcc388b33b@github.com>
 <MjNE1aU3pyeifNsMVvPPZg-UhRyQYDC0YKetR2CAKcQ=.60fcd97a-69d9-46b3-a8bf-130c3534a089@github.com>
 <_Fu286WNCl5BafCscQ293DwCjpJ0C4SnXMkUHjLZvyY=.6c3abdca-9331-4974-99af-e6dc50baa1c4@github.com>
Message-ID: <fcSxJaMAHgihSQ92rhHK5GUIam1UeYLPwcZJ6z79SJE=.e733c384-bb79-471b-9ad5-6dcb50fe931a@github.com>

On Mon, 22 Aug 2022 21:53:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> And this is unclear to me. The frame is set to non-resizeable, `frame.pack()` is called. This, I assume, results in this code block being executed, so the calculated insets should be cached.
>> 
>> Why do the following calls to `getInsets` or `getPreferredSize` return the *resizeable* insets if the cached ones are *non-resizeable*?
>
>> Is this applicable to windows?
> 
> I mean to `Window` objects.

> And this is unclear to me. The frame is set to non-resizeable, `frame.pack()` is called. This, I assume, results in this code block being executed, so the calculated insets should be cached.
> 
> Why do the following calls to `getInsets` or `getPreferredSize` return the _resizeable_ insets if the cached ones are _non-resizeable_?

Initially the cause for swapping of insets was unclear to me as well. After looking closely at the native debug logs, it was found that the insets calculated using Client & Non-Client Rects were different in comparison to the native insets obtained from system metrics for Non-Resizable frame.

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

PR: https://git.openjdk.org/jdk/pull/9954


From honkar at openjdk.org  Mon Sep 19 22:25:48 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 19 Sep 2022 22:25:48 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v3]
In-Reply-To: <7U4stw4f0Nu9D1U0qtZBLVmzp-HntyWr5re1KDixw1Y=.234b63ff-c1a7-42c8-87a5-62f3387d4422@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <7U4stw4f0Nu9D1U0qtZBLVmzp-HntyWr5re1KDixw1Y=.234b63ff-c1a7-42c8-87a5-62f3387d4422@github.com>
Message-ID: <njVwQuLv2ccx-PazBmqhNLi5Q--9mzT6HtkOdunQ3lo=.58351a28-9680-4532-a3c4-8d623e3522c4@github.com>

On Mon, 19 Sep 2022 21:31:48 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
>> 
>> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
>> 
>> The test is generic though the issue and fix is on Windows platform because the condition 
>> `frame.getSize() == frame.getPreferredSize()` should be true on all platforms when frame.pack() is called.
>> 
>> Following is the link to Windows System Metrics (used for native insets) - https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated fix to get the right insets for Non-Resizable frame

In AwtWindow::UpdateInsets, insets are obtained in two ways: 

1. **By subtracting Client rect from Non-Client rect:** If the insets obtained by this approach returns a negative value for either top, bottom, left or right it means that the window isn't sized yet and we need to get the associated default native insets through approach 2.

2. **Through Default native insets**  - Obtained using GetSystemMetrics(<appropriate_metric>) on Windows. Once the frame is sized, the insets obtained by step 1 are taken as final insets and cached in the respective peers.

For the Non-Resizable Frame these two approaches returned different values, because of which the actual size and preferred size differed when frame.pack() is called. Earlier the metric used for Non-Resizable frame was  **SM_CXDLGFRAME/ SM_CXFIXEDFRAME**, which returned slightly smaller inset values compared to that returned by Client and Non-Client rects. To match the insets returned in both the cases, **SM_CXSIZEFRAME/ SM_CYSIZEFRAME** is used as system metric for both - Resizable/ Non-Resizable frames in the updated fix. This ensures that the same inset values are returned for Non-Resizable frame.

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

PR: https://git.openjdk.org/jdk/pull/9954


From honkar at openjdk.org  Mon Sep 19 23:24:45 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 19 Sep 2022 23:24:45 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v4]
In-Reply-To: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
Message-ID: <kCzHnECHQqkjWksA-W2MrYWheE7WPjgFk8oziVgtDPU=.3f93daaf-315a-4140-a866-354ceddc5ca4@github.com>

> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
> 
> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
> 
> The test is generic though the issue and fix is on Windows platform because the condition 
> `frame.getSize() == frame.getPreferredSize()` should be true on all platforms when frame.pack() is called.
> 
> Following is the link to Windows System Metrics (used for native insets) - https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics

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

  reverted the changes related to previous fix - checking the type of target object

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9954/files
  - new: https://git.openjdk.org/jdk/pull/9954/files/9bec5c34..72272055

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9954&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9954&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/9954


From honkar at openjdk.org  Tue Sep 20 00:01:27 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 20 Sep 2022 00:01:27 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v2]
In-Reply-To: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
Message-ID: <-du2igQ7Bn4EWJTLVes8IAxFV79-rZJy4Ew1k1EYRi0=.2bfe3cce-89eb-43b9-893e-d770b3ea22cc@github.com>

> JInternalFrame background color seems to overflow into the border region. This issue is more prominently seen on Windows - Metal LAF (with fractional scaling, as shown below). The primary reason is border scaling issue as observed in  - [JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614) & [JDK-8282958](https://bugs.openjdk.org/browse/JDK-8282958)
> 
> The fix involves a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. The test checks the midpoint and corners of borders to check if the internal frame's background color is located out of JInternalFrame.
> 
> ![image](https://user-images.githubusercontent.com/95945681/190233555-a7e00f2c-9003-4c11-84fb-207957838c2f.png)

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

 - Merge branch 'master' into JIFBorder_8015739
 - added test summary
 - updated test case
 - Added test case, minor position changes to shadow lines
 - expanded imports
 - JIF Metal Border Scaling - Initial changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10274/files
  - new: https://git.openjdk.org/jdk/pull/10274/files/955265c0..b02179cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10274&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10274&range=00-01

  Stats: 25148 lines in 921 files changed: 13276 ins; 7013 del; 4859 mod
  Patch: https://git.openjdk.org/jdk/pull/10274.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10274/head:pull/10274

PR: https://git.openjdk.org/jdk/pull/10274


From dholmes at openjdk.org  Tue Sep 20 05:42:57 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 20 Sep 2022 05:42:57 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
Message-ID: <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>

On Sat, 17 Sep 2022 08:41:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> Alan Bateman 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 12 additional commits since the last revision:
> 
>  - Merge
>  - Updates to Java Thread Primitive Deprecation page
>  - Repalce "it" with "victim thread"
>  - Merge
>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>  - become -> became in javadoc
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/4a31f682...93806f99

Hi Alan,

Good to see this finally become non-functional but as long as the debugger/JVMTI can trigger throwing an async ThreadDeath then I have to question the potential change in behaviour introduced by removing all the `catch (ThreadDeath td)` logic in various places.

src/java.base/share/classes/java/io/FilterOutputStream.java line 195:

> 193:                    // evaluate possible precedence of flushException over closeException
> 194:                    if ((flushException instanceof ThreadDeath) &&
> 195:                        !(closeException instanceof ThreadDeath)) {

If the ThreadDeath originates from the debugger then this is now a change in behaviour.

src/java.base/share/classes/java/lang/Shutdown.java line 132:

> 130:                 if (hook != null) hook.run();
> 131:             } catch (Throwable t) {
> 132:                 // ignore

Again change of behaviour if TD originates from debugger.

src/java.base/share/classes/java/lang/ThreadDeath.java line 30:

> 28: /**
> 29:  * An instance of {@code ThreadDeath} was originally specified to be thrown
> 30:  * by a victim thread when "stopped" with {@link Thread#stop()}.

Should this have always mentioned the possibility of TD coming from a debugger as well?

src/java.base/share/classes/java/lang/ThreadGroup.java line 700:

> 698:                 ueh.uncaughtException(t, e);
> 699:             } else {
> 700:                 System.err.print("Exception in thread \"" + t.getName() + "\" ");

Again change in behaviour.

src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html line 37:

> 35: stop a thread removed?</h2>
> 36: <p>Because it was inherently unsafe. Stopping a thread caused it to
> 37: unlock all the monitors that it had locked. (The monitors were

Just an aside but this rationale was always a significant under-statement as async-exceptions are inherently unsafe even if no concurrency or monitors are involved.

src/java.desktop/macosx/classes/sun/lwawt/LWToolkit.java line 170:

> 168:                     }
> 169:                 }
> 170:             } catch (ThreadDeath td) {

Again change in behaviour

src/java.desktop/share/classes/java/awt/EventDispatchThread.java line 205:

> 203:             eq.dispatchEvent(event);
> 204:         }
> 205:         catch (ThreadDeath death) {

Again change in behaviour.

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

PR: https://git.openjdk.org/jdk/pull/10230


From alanb at openjdk.org  Tue Sep 20 06:05:14 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Sep 2022 06:05:14 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
 <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>
Message-ID: <jhvaxnF1s7-oPaVsF9nf5ko8wP1gBWOo5TfO8T_j40A=.731ea409-ca17-488e-a0b1-3cb15334515a@github.com>

On Tue, 20 Sep 2022 04:21:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Alan Bateman 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 12 additional commits since the last revision:
>> 
>>  - Merge
>>  - Updates to Java Thread Primitive Deprecation page
>>  - Repalce "it" with "victim thread"
>>  - Merge
>>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>>  - become -> became in javadoc
>>  - Merge
>>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>>  - Deprecate for removal
>>  - Next iteration, update dates in headers
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/26f404b2...93806f99
>
> src/java.base/share/classes/java/io/FilterOutputStream.java line 195:
> 
>> 193:                    // evaluate possible precedence of flushException over closeException
>> 194:                    if ((flushException instanceof ThreadDeath) &&
>> 195:                        !(closeException instanceof ThreadDeath)) {
> 
> If the ThreadDeath originates from the debugger then this is now a change in behaviour.

> Good to see this finally become non-functional but as long as the debugger/JVMTI can trigger throwing an async ThreadDeath then I have to question the potential change in behaviour introduced by removing all the `catch (ThreadDeath td)` logic in various places.

I've gone through a few times too and concluded it would be better to remove these untestable code paths. The debugger scenario is more like what used to be Thread.stop(Throwable). It can be used to throw any exception or error, e.g. ask the debugger to throw IllegalArgumentException or SQLException when I'm at this breakpoint so I can see how the code behaves. Yes, the user could ask the debugger to throw java.lang.ThreadDeath when prompted but it's not really interesting now because code won't get this error outside of a debugger. We could leave the special handing but we have no way to test is and we'll need to the remove the special handling when TD is removed.  As a general point, the special casing of TD is a bit inconsistent and more likely to be seen in older code rather newer code. A static analysis of 24M classes found very few usages in 3rd libraries.

> Should this have always mentioned the possibility of TD coming from a debugger as well?

The debugger can cause any error or exception to be thrown so I don't think we should put anything in the TD spec about this.

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

PR: https://git.openjdk.org/jdk/pull/10230


From psadhukhan at openjdk.org  Tue Sep 20 09:24:17 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 20 Sep 2022 09:24:17 GMT
Subject: RFR: 8294046: Newly added test
 test/jdk/javax/swing/JTabbedPane/TestNPEStateChgListener.java fails in macos
Message-ID: <LYC3GduX3FoAk2SGNJsAYIrsWRtp0mj-e_rM62nHLms=.c5317ae2-844a-4dbc-aba0-5ef7130136fd@github.com>

Test added for fix [JDK-6286501](https://bugs.openjdk.org/browse/JDK-6286501)  fails in macos citing 

java.lang.NullPointerException: Cannot invoke "javax.swing.JTabbedPane.getSelectedIndex()" 
because "this.this$0.tabPane" is null
at java.desktop/com.apple.laf.AquaTabbedPaneUI$2.stateChanged(AquaTabbedPaneUI.java:813) 


for Aqua L&F owing to same issue as described in https://github.com/openjdk/jdk/pull/10216#discussion_r971787291 wherein the old instance is uninstalled and tabPane is reset to null when updateUI() is called in stateChange Listener in testcase, so we need to use the tabPane instance passed in TabbedPane's stateChange listener as has been done for BasicTabbedPaneUI case.

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

Commit messages:
 - 8294046: Newly added test test/jdk/javax/swing/JTabbedPane/TestNPEStateChgListener.java fails in macos

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

PR: https://git.openjdk.org/jdk/pull/10354


From duke at openjdk.org  Tue Sep 20 09:48:36 2022
From: duke at openjdk.org (Martin Desruisseaux)
Date: Tue, 20 Sep 2022 09:48:36 GMT
Subject: RFR: 8290973: In AffineTransform,
 equals(Object) is inconsistent with hashCode() [v2]
In-Reply-To: <ct_RNqaFw2LBdH6FJWYUuAgW9I2aZIoUQ0mg_GY3ZPU=.901a3dd2-b1b1-4d87-970d-5aa6c70a96e4@github.com>
References: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
 <ct_RNqaFw2LBdH6FJWYUuAgW9I2aZIoUQ0mg_GY3ZPU=.901a3dd2-b1b1-4d87-970d-5aa6c70a96e4@github.com>
Message-ID: <myEc84kcgPnHrXG1Fj0id1V7l2jTiLK5jKcjeQdu1Kc=.bf83ae68-91f8-4168-8d52-16c49fa6bd19@github.com>

On Mon, 22 Aug 2022 17:13:26 GMT, Martin Desruisseaux <duke at openjdk.org> wrote:

>> `AffineTransform.equals(Object)` and `hashCode()` break two contracts:
>> 
>> * `A.equals(A)` returns `false` if at least one affine transform coefficient is NaN.
>> * `A.equals(B)` should imply `A.hashCode() == B.hashCode()`, but it is not the case if a coefficient is zero with an opposite sign in A and B.
>> 
>> This patch preserves the current behaviour regarding 0 (i.e. -0 is considered equal to +0) for backward compatibility reason. Instead the `hashCode()` method is updated for being consistent with `equals(Object)` behaviour.
>
> Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a trivial typo: "into to" -> "to".

A ping for preventing this merge request to be automatically closed. This MR has been approved in August 11 and is ready for integration by a committer (if no more comment).

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

PR: https://git.openjdk.org/jdk/pull/9121


From azvegint at openjdk.org  Tue Sep 20 13:28:37 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 20 Sep 2022 13:28:37 GMT
Subject: RFR: 8294046: Newly added test
 test/jdk/javax/swing/JTabbedPane/TestNPEStateChgListener.java fails in macos
In-Reply-To: <LYC3GduX3FoAk2SGNJsAYIrsWRtp0mj-e_rM62nHLms=.c5317ae2-844a-4dbc-aba0-5ef7130136fd@github.com>
References: <LYC3GduX3FoAk2SGNJsAYIrsWRtp0mj-e_rM62nHLms=.c5317ae2-844a-4dbc-aba0-5ef7130136fd@github.com>
Message-ID: <XzzS0EtzjMvQ-WpI-m1XVZpKdI8-1uZWZq06MQfaceI=.ebd07410-8b16-4e3b-b0b8-13a9a28cf6a8@github.com>

On Tue, 20 Sep 2022 09:16:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test added for fix [JDK-6286501](https://bugs.openjdk.org/browse/JDK-6286501)  fails in macos citing 
> 
> java.lang.NullPointerException: Cannot invoke "javax.swing.JTabbedPane.getSelectedIndex()" 
> because "this.this$0.tabPane" is null
> at java.desktop/com.apple.laf.AquaTabbedPaneUI$2.stateChanged(AquaTabbedPaneUI.java:813) 
> 
> 
> for Aqua L&F owing to same issue as described in https://github.com/openjdk/jdk/pull/10216#discussion_r971787291 wherein the old instance is uninstalled and tabPane is reset to null when updateUI() is called in stateChange Listener in testcase, so we need to use the tabPane instance passed in TabbedPane's stateChange listener as has been done for BasicTabbedPaneUI case.

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10354


From prr at openjdk.org  Tue Sep 20 15:21:44 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Sep 2022 15:21:44 GMT
Subject: RFR: 8294046: Newly added test
 test/jdk/javax/swing/JTabbedPane/TestNPEStateChgListener.java fails in macos
In-Reply-To: <LYC3GduX3FoAk2SGNJsAYIrsWRtp0mj-e_rM62nHLms=.c5317ae2-844a-4dbc-aba0-5ef7130136fd@github.com>
References: <LYC3GduX3FoAk2SGNJsAYIrsWRtp0mj-e_rM62nHLms=.c5317ae2-844a-4dbc-aba0-5ef7130136fd@github.com>
Message-ID: <lE9iwb8a2uq1HDvonxBWxa_IBlZelzFf480a8tJIEZ0=.ed00b1d2-94bb-4991-8b62-3e21e746d937@github.com>

On Tue, 20 Sep 2022 09:16:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test added for fix [JDK-6286501](https://bugs.openjdk.org/browse/JDK-6286501)  fails in macos citing 
> 
> java.lang.NullPointerException: Cannot invoke "javax.swing.JTabbedPane.getSelectedIndex()" 
> because "this.this$0.tabPane" is null
> at java.desktop/com.apple.laf.AquaTabbedPaneUI$2.stateChanged(AquaTabbedPaneUI.java:813) 
> 
> 
> for Aqua L&F owing to same issue as described in https://github.com/openjdk/jdk/pull/10216#discussion_r971787291 wherein the old instance is uninstalled and tabPane is reset to null when updateUI() is called in stateChange Listener in testcase, so we need to use the tabPane instance passed in TabbedPane's stateChange listener as has been done for BasicTabbedPaneUI case.

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10354


From psadhukhan at openjdk.org  Tue Sep 20 15:24:26 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 20 Sep 2022 15:24:26 GMT
Subject: Integrated: 8294046: Newly added test
 test/jdk/javax/swing/JTabbedPane/TestNPEStateChgListener.java fails in macos
In-Reply-To: <LYC3GduX3FoAk2SGNJsAYIrsWRtp0mj-e_rM62nHLms=.c5317ae2-844a-4dbc-aba0-5ef7130136fd@github.com>
References: <LYC3GduX3FoAk2SGNJsAYIrsWRtp0mj-e_rM62nHLms=.c5317ae2-844a-4dbc-aba0-5ef7130136fd@github.com>
Message-ID: <mXlzIgjDiR-6HNBbEgPi_Bm6GCApnwhBZwsowbYXyB8=.d518cd03-6eb6-470d-a08e-5533a3007467@github.com>

On Tue, 20 Sep 2022 09:16:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test added for fix [JDK-6286501](https://bugs.openjdk.org/browse/JDK-6286501)  fails in macos citing 
> 
> java.lang.NullPointerException: Cannot invoke "javax.swing.JTabbedPane.getSelectedIndex()" 
> because "this.this$0.tabPane" is null
> at java.desktop/com.apple.laf.AquaTabbedPaneUI$2.stateChanged(AquaTabbedPaneUI.java:813) 
> 
> 
> for Aqua L&F owing to same issue as described in https://github.com/openjdk/jdk/pull/10216#discussion_r971787291 wherein the old instance is uninstalled and tabPane is reset to null when updateUI() is called in stateChange Listener in testcase, so we need to use the tabPane instance passed in TabbedPane's stateChange listener as has been done for BasicTabbedPaneUI case.

This pull request has now been integrated.

Changeset: df8ec09f
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df8ec09f8dd21de2910212a6d98c1970a2a1a3d3
Stats:     2 lines in 2 files changed: 1 ins; 0 del; 1 mod

8294046: Newly added test test/jdk/javax/swing/JTabbedPane/TestNPEStateChgListener.java fails in macos

Reviewed-by: azvegint, prr

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

PR: https://git.openjdk.org/jdk/pull/10354


From dnguyen at openjdk.org  Tue Sep 20 16:05:14 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 20 Sep 2022 16:05:14 GMT
Subject: RFR: 8294067: [macOS] javax/swing/JComboBox/6559152/bug6559152.java
 Cannot select an item from popup with the ENTER key.
Message-ID: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>

The newly fix-sized JComboBox has its dropdown menu opened with this test's mouse click. The goal of the test is to focus the JComboBox, open the dropdown menu, and select the 2nd option of the menu using arrow keys and ENTER key. Since the JComboBox is focused without the click already, the click can be removed.

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

Commit messages:
 - Remove comment
 - Fix test for JComboBox change

Changes: https://git.openjdk.org/jdk/pull/10359/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10359&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294067
  Stats: 15 lines in 1 file changed: 5 ins; 8 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10359.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10359/head:pull/10359

PR: https://git.openjdk.org/jdk/pull/10359


From smarks at openjdk.org  Tue Sep 20 16:32:54 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 20 Sep 2022 16:32:54 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <jhvaxnF1s7-oPaVsF9nf5ko8wP1gBWOo5TfO8T_j40A=.731ea409-ca17-488e-a0b1-3cb15334515a@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
 <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>
 <jhvaxnF1s7-oPaVsF9nf5ko8wP1gBWOo5TfO8T_j40A=.731ea409-ca17-488e-a0b1-3cb15334515a@github.com>
Message-ID: <q6ToSabdUIWS0vK-13JWdvQySwco64A_gP20tVsm9FI=.7722abf4-9470-4a52-9f8e-48cb2481eb77@github.com>

On Tue, 20 Sep 2022 06:00:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/FilterOutputStream.java line 195:
>> 
>>> 193:                    // evaluate possible precedence of flushException over closeException
>>> 194:                    if ((flushException instanceof ThreadDeath) &&
>>> 195:                        !(closeException instanceof ThreadDeath)) {
>> 
>> If the ThreadDeath originates from the debugger then this is now a change in behaviour.
>
>> Good to see this finally become non-functional but as long as the debugger/JVMTI can trigger throwing an async ThreadDeath then I have to question the potential change in behaviour introduced by removing all the `catch (ThreadDeath td)` logic in various places.
> 
> I've gone through this a few times too and concluded it would be better to remove these untestable code paths. The debugger scenario is more like what used to be Thread.stop(Throwable). It can be used to throw any exception or error, e.g. ask the debugger to throw IllegalArgumentException or SQLException when I'm at this breakpoint so I can see how the code behaves. Yes, the user could ask the debugger to throw java.lang.ThreadDeath when prompted but it's not really interesting now because code won't get this error outside of a debugger. We could leave the special handing but we have no way to test is and we'll need to the remove the special handling when TD is removed.  As a general point, the special casing of TD is a bit inconsistent and more likely to be seen in older code rather newer code. A static analysis of 24M classes found very few usages in 3rd party libraries.

I agree with Alan on this. First, use and handling of `ThreadDeath` is quite rare; see my [analysis](https://bugs.openjdk.org/browse/JDK-8289610?focusedCommentId=14523723&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14523723) of the corpus search results in the bug report. Second, while this does change the behavior in the debugger case, I'm hard-pressed to see how anybody is _relying_ on such behavior. And maybe somebody somewhere is indeed relying on this behavior, but it doesn't seem to me this behavior is guaranteed by any specifications.

A more likely way that programs could observe changes in `ThreadDeath` handling occurs when programs throw `ThreadDeath` explicitly, that is, not using `Thread.stop`. This does seem to occur infrequently "in the wild" (we'll fix the jshell case). The point of throwing `ThreadDeath` explicitly is to take advantage of special-case handling of `ThreadDeath` that might occur higher in the call stack. Such special-casing was at one time an accepted exception handing idiom, but it's essentially disused. I don't think the JDK needs to continue to support this old idiom.

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

PR: https://git.openjdk.org/jdk/pull/10230


From aivanov at openjdk.org  Tue Sep 20 16:40:33 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 Sep 2022 16:40:33 GMT
Subject: RFR: 8294038: Remove "Classpath" exception from javax/swing tests
Message-ID: <Ey3xTLlK02zVshgF2rO7Y0wf9-36QQ_68LkmQfcVJcE=.80f191f8-def2-49dd-8ab6-7353f164120a@github.com>

Remove *the "Classpath" exception* from tests in `javax/swing`. The tests should not have it.

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

Commit messages:
 - 8294038: Remove "Classpath" exception from javax/swing tests
 - 8294038: Remove "Classpath" exception from javax/swing tests

Changes: https://git.openjdk.org/jdk/pull/10360/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10360&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294038
  Stats: 34 lines in 11 files changed: 0 ins; 23 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10360.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10360/head:pull/10360

PR: https://git.openjdk.org/jdk/pull/10360


From prr at openjdk.org  Tue Sep 20 16:42:13 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Sep 2022 16:42:13 GMT
Subject: RFR: 8294067: [macOS]
 javax/swing/JComboBox/6559152/bug6559152.java Cannot select an item from popup
 with the ENTER key.
In-Reply-To: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
References: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
Message-ID: <LPKPrLM0Hx-ZuQta78kyT-ah9xqQAfZDx4d-3UFKKEU=.1a57c7bb-f662-47ae-97f2-1a4b2363b9cd@github.com>

On Tue, 20 Sep 2022 15:57:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> The newly fix-sized JComboBox has its dropdown menu opened with this test's mouse click. The goal of the test is to focus the JComboBox, open the dropdown menu, and select the 2nd option of the menu using arrow keys and ENTER key. Since the JComboBox is focused without the click already, the click can be removed.

I note that the mouse click was added to stabilise this test in this PR
https://github.com/openjdk/jdk/pull/1666/files#diff-92c0c78d42028b3d6bb57bd687afe28b5947ba8e3ccae9025a5a62214a21930c

@prsadhuk was it really needed ?

The comment back then was 
"and also made this test's frame gain focus by clicking on the frame, as it seems the frame does not get focus sometime so that keyevent does not get registered causing it to fail."

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

PR: https://git.openjdk.org/jdk/pull/10359


From azvegint at openjdk.org  Tue Sep 20 16:46:51 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 20 Sep 2022 16:46:51 GMT
Subject: RFR: 8294067: [macOS]
 javax/swing/JComboBox/6559152/bug6559152.java Cannot select an item from popup
 with the ENTER key.
In-Reply-To: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
References: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
Message-ID: <L-943GR77EeDFW-2xQmhuRIpXE-g0dGtOyLsLKMHIFE=.cd511b33-3fc0-4aa0-8805-04b0f53a04fa@github.com>

On Tue, 20 Sep 2022 15:57:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> The newly fix-sized JComboBox has its dropdown menu opened with this test's mouse click. The goal of the test is to focus the JComboBox, open the dropdown menu, and select the 2nd option of the menu using arrow keys and ENTER key. Since the JComboBox is focused without the click already, the click can be removed.

Personally I would prefer to keep the click for better test stability. 
Let's hear some thoughts from other reviewers.

P.S. looks like I am not the only one concerning about this.

test/jdk/javax/swing/JComboBox/6559152/bug6559152.java line 100:

> 98: 
> 99:     private static void test() throws Exception {
> 100:         robot.mouseMove(p.x, p.y);

Are we still need this? There is no more mouse click.

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

Marked as reviewed by azvegint (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10359


From aivanov at openjdk.org  Tue Sep 20 16:47:23 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 Sep 2022 16:47:23 GMT
Subject: RFR: 8294039: Remove "Classpath" exception from java/awt tests
Message-ID: <cow8RaT1qCUrcC5APnQwQTFeQ2SOxI2e53Ysc3SgqTY=.87596b1c-9219-4991-863f-e22dca71f5e6@github.com>

Remove *the "Classpath" exception* from tests in `javax/awt`. The tests should not have it.

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

Commit messages:
 - 8294039: Remove "Classpath" exception from java/awt tests

Changes: https://git.openjdk.org/jdk/pull/10361/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10361&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294039
  Stats: 106 lines in 29 files changed: 0 ins; 77 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/10361.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10361/head:pull/10361

PR: https://git.openjdk.org/jdk/pull/10361


From psadhukhan at openjdk.org  Tue Sep 20 16:53:55 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 20 Sep 2022 16:53:55 GMT
Subject: RFR: 8294067: [macOS]
 javax/swing/JComboBox/6559152/bug6559152.java Cannot select an item from popup
 with the ENTER key.
In-Reply-To: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
References: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
Message-ID: <pKMIsCE2lhSLHAf8K3hy_x2jTwBQ9XAAb9rk49vbDlw=.fd10f571-b164-4ac0-a09f-6bd07e3c96a6@github.com>

On Tue, 20 Sep 2022 15:57:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> The newly fix-sized JComboBox has its dropdown menu opened with this test's mouse click. The goal of the test is to focus the JComboBox, open the dropdown menu, and select the 2nd option of the menu using arrow keys and ENTER key. Since the JComboBox is focused without the click already, the click can be removed.

I think the click is needed to gain focus in some CI systems..
The thing is it does not fail in non macos systems so far makes it interesting..
Probably the mouseMove(p.x, p.y) is not actually moving the mouse to the combobox interior area in hidpi systems and it does not fail in windows probably because it is running in nonhidpi systems.

I guess probably the right fix will be to do
`robot.mouseMove(p.x + comboBox.width/2, p.y + comboxBox.height/2)` to make sure it is clicked inside the combobox

Also, better to run in all platforms after the test fix and put in JBS.

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

PR: https://git.openjdk.org/jdk/pull/10359


From dnguyen at openjdk.org  Tue Sep 20 17:02:14 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 20 Sep 2022 17:02:14 GMT
Subject: RFR: 8294067: [macOS]
 javax/swing/JComboBox/6559152/bug6559152.java Cannot select an item from popup
 with the ENTER key. [v2]
In-Reply-To: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
References: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
Message-ID: <VBH0bbWXVRsnETmZswcwAt9HIeuZGPn_fKAyfdwbqm0=.09da304f-44a9-4e89-9843-522ff7dc8cba@github.com>

> The newly fix-sized JComboBox has its dropdown menu opened with this test's mouse click. The goal of the test is to focus the JComboBox, open the dropdown menu, and select the 2nd option of the menu using arrow keys and ENTER key. Since the JComboBox is focused without the click already, the click can be removed.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Re-add click. Update mouse position

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10359/files
  - new: https://git.openjdk.org/jdk/pull/10359/files/fbf09562..9b2a8f6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10359&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10359&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/10359


From dnguyen at openjdk.org  Tue Sep 20 17:02:15 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 20 Sep 2022 17:02:15 GMT
Subject: RFR: 8294067: [macOS]
 javax/swing/JComboBox/6559152/bug6559152.java Cannot select an item from popup
 with the ENTER key. [v2]
In-Reply-To: <L-943GR77EeDFW-2xQmhuRIpXE-g0dGtOyLsLKMHIFE=.cd511b33-3fc0-4aa0-8805-04b0f53a04fa@github.com>
References: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
 <L-943GR77EeDFW-2xQmhuRIpXE-g0dGtOyLsLKMHIFE=.cd511b33-3fc0-4aa0-8805-04b0f53a04fa@github.com>
Message-ID: <4gR4i-39o6HTi49awJ7X8KSYottUEMu6AnAL1sTQ0aI=.93110eed-7ace-4d3f-99b5-70fc5adcf9e0@github.com>

On Tue, 20 Sep 2022 16:08:58 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re-add click. Update mouse position
>
> test/jdk/javax/swing/JComboBox/6559152/bug6559152.java line 100:
> 
>> 98: 
>> 99:     private static void test() throws Exception {
>> 100:         robot.mouseMove(p.x, p.y);
> 
> Are we still need this? There is no more mouse click.

I re-added the mouse click and took Prasanta's advice to just center the mouse on the combobox, instead of adding to the y position by 1.

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

PR: https://git.openjdk.org/jdk/pull/10359


From azvegint at openjdk.org  Tue Sep 20 17:05:00 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 20 Sep 2022 17:05:00 GMT
Subject: RFR: 8294067: [macOS]
 javax/swing/JComboBox/6559152/bug6559152.java Cannot select an item from popup
 with the ENTER key. [v2]
In-Reply-To: <VBH0bbWXVRsnETmZswcwAt9HIeuZGPn_fKAyfdwbqm0=.09da304f-44a9-4e89-9843-522ff7dc8cba@github.com>
References: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
 <VBH0bbWXVRsnETmZswcwAt9HIeuZGPn_fKAyfdwbqm0=.09da304f-44a9-4e89-9843-522ff7dc8cba@github.com>
Message-ID: <WRrHTewIDfTA8yJQBGOpbLIAzrETA_GbVDJ9CvzXzuc=.0933348c-8406-491f-a506-b0a6aa0188f4@github.com>

On Tue, 20 Sep 2022 17:02:14 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The newly fix-sized JComboBox has its dropdown menu opened with this test's mouse click. The goal of the test is to focus the JComboBox, open the dropdown menu, and select the 2nd option of the menu using arrow keys and ENTER key. Since the JComboBox is focused without the click already, the click can be removed.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-add click. Update mouse position

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10359


From psadhukhan at openjdk.org  Tue Sep 20 17:11:47 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 20 Sep 2022 17:11:47 GMT
Subject: RFR: 8294067: [macOS]
 javax/swing/JComboBox/6559152/bug6559152.java Cannot select an item from popup
 with the ENTER key. [v2]
In-Reply-To: <VBH0bbWXVRsnETmZswcwAt9HIeuZGPn_fKAyfdwbqm0=.09da304f-44a9-4e89-9843-522ff7dc8cba@github.com>
References: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
 <VBH0bbWXVRsnETmZswcwAt9HIeuZGPn_fKAyfdwbqm0=.09da304f-44a9-4e89-9843-522ff7dc8cba@github.com>
Message-ID: <NsrynXeU81YX9w3F4VOdoLxkFFS9LkmjuG_C5j1KinE=.dfa0cf8b-947f-4ec5-96dd-c084175a82c3@github.com>

On Tue, 20 Sep 2022 17:02:14 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The newly fix-sized JComboBox has its dropdown menu opened with this test's mouse click. The goal of the test is to focus the JComboBox, open the dropdown menu, and select the 2nd option of the menu using arrow keys and ENTER key. Since the JComboBox is focused without the click already, the click can be removed.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-add click. Update mouse position

test/jdk/javax/swing/JComboBox/6559152/bug6559152.java line 101:

> 99: 
> 100:     private static void test() throws Exception {
> 101:         robot.mouseMove(p.x + cb.getWidth() / 2, p.y + cb.getHeight() / 2);

Since `cb` is swing component, appropriate will be to do 
(Dimension) d = comp.getSize(); inside blockTillDisplayed() which is called in EDT

and use mouseMove(p.x + d.width/2, p.y + d.height/2)

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

PR: https://git.openjdk.org/jdk/pull/10359


From dnguyen at openjdk.org  Tue Sep 20 17:17:04 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 20 Sep 2022 17:17:04 GMT
Subject: RFR: 8294067: [macOS]
 javax/swing/JComboBox/6559152/bug6559152.java Cannot select an item from popup
 with the ENTER key. [v3]
In-Reply-To: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
References: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
Message-ID: <vvPJiLaebH8iU5CP6pMuDWCACIQD_aSxYrZ1FQjDPVA=.af74cdab-ac8e-4637-b4e8-7ef44f7b1968@github.com>

> The newly fix-sized JComboBox has its dropdown menu opened with this test's mouse click. The goal of the test is to focus the JComboBox, open the dropdown menu, and select the 2nd option of the menu using arrow keys and ENTER key. Since the JComboBox is focused without the click already, the click can be removed.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Add dimension to get dimensions from EDT

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10359/files
  - new: https://git.openjdk.org/jdk/pull/10359/files/9b2a8f6a..e5217e08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10359&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10359&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/10359


From dnguyen at openjdk.org  Tue Sep 20 17:21:22 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 20 Sep 2022 17:21:22 GMT
Subject: RFR: 8294067: [macOS]
 javax/swing/JComboBox/6559152/bug6559152.java Cannot select an item from popup
 with the ENTER key. [v4]
In-Reply-To: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
References: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
Message-ID: <9hNf99QjPQJpN91w-Zf51aImIk-sSI6-bdrKiD1E1t8=.5858b823-e3c9-435a-bbab-ba03d5ea78f4@github.com>

> The newly fix-sized JComboBox has its dropdown menu opened with this test's mouse click. The goal of the test is to focus the JComboBox, open the dropdown menu, and select the 2nd option of the menu using arrow keys and ENTER key. Since the JComboBox is focused without the click already, the click can be removed.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Use dimension width and height

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10359/files
  - new: https://git.openjdk.org/jdk/pull/10359/files/e5217e08..d6bd577d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10359&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10359&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/10359


From psadhukhan at openjdk.org  Tue Sep 20 17:21:22 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 20 Sep 2022 17:21:22 GMT
Subject: RFR: 8294067: [macOS]
 javax/swing/JComboBox/6559152/bug6559152.java Cannot select an item from popup
 with the ENTER key. [v4]
In-Reply-To: <9hNf99QjPQJpN91w-Zf51aImIk-sSI6-bdrKiD1E1t8=.5858b823-e3c9-435a-bbab-ba03d5ea78f4@github.com>
References: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
 <9hNf99QjPQJpN91w-Zf51aImIk-sSI6-bdrKiD1E1t8=.5858b823-e3c9-435a-bbab-ba03d5ea78f4@github.com>
Message-ID: <gRBiZSqoikv21dfQC2URYRkYbSav0CwIcs6Yb3XvmFU=.51e8f720-38a6-4df6-8722-db26f933ed74@github.com>

On Tue, 20 Sep 2022 17:17:40 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The newly fix-sized JComboBox has its dropdown menu opened with this test's mouse click. The goal of the test is to focus the JComboBox, open the dropdown menu, and select the 2nd option of the menu using arrow keys and ENTER key. Since the JComboBox is focused without the click already, the click can be removed.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use dimension width and height

Marked as reviewed by psadhukhan (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10359


From kizune at openjdk.org  Tue Sep 20 18:15:48 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 20 Sep 2022 18:15:48 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v2]
In-Reply-To: <M46IdjY_mvO3acH7wyiG2wl4-RdfJs-bP9Qkdyy-gd4=.1bedc26b-942d-4bd7-89c1-e6598b78c95e@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <glDfktBW_QWp6lWhUl9nS7woY9CLFYPu1N-TbBjD1Ao=.eb0a6ac1-25f3-4e05-ac11-22c75f370674@github.com>
 <M46IdjY_mvO3acH7wyiG2wl4-RdfJs-bP9Qkdyy-gd4=.1bedc26b-942d-4bd7-89c1-e6598b78c95e@github.com>
Message-ID: <mjoKxOdXYdmhfAuBeKtmJy9HTKksMoTKEJZbcAeUBrY=.a7bf4607-104a-4b67-afc2-5083b97e4777@github.com>

On Mon, 19 Sep 2022 20:14:24 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> I was also thinking if we can - may be precompute & store all the corner values in a `HashMap` for all the scale values that we can expect?

It depends on how often this value is being computed and how complicated the computation is. Since we request the current transform value anyways on every paint i do not see how accessing the HashMap would be more beneficial than the simple floating point multiplication and a rounding up the result. Just make the static final constant storing the default corner size and a local variable that stores the calculated current corner. You can try to use HashMap but i doubt it will make much difference performance wise. It is not a complex calculation. I might be wrong so you can try both ways and check for the performance impact.

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

PR: https://git.openjdk.org/jdk/pull/10274


From dnguyen at openjdk.org  Tue Sep 20 18:18:02 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 20 Sep 2022 18:18:02 GMT
Subject: Integrated: 8294067: [macOS]
 javax/swing/JComboBox/6559152/bug6559152.java Cannot select an item from popup
 with the ENTER key.
In-Reply-To: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
References: <C-6OQAhP6RCfI8K-WuJ6ATlfjLjn3AhML-pN_s2Q3DA=.8adf8d97-d7da-4a35-bf45-13b14e0d6d73@github.com>
Message-ID: <BWUsoEy7G5q3E8qBV9ddkNA-RIefYCkigiHJu0HXa2w=.0d91447b-295f-46e3-b235-2c2ec65da431@github.com>

On Tue, 20 Sep 2022 15:57:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> The newly fix-sized JComboBox has its dropdown menu opened with this test's mouse click. The goal of the test is to focus the JComboBox, open the dropdown menu, and select the 2nd option of the menu using arrow keys and ENTER key. Since the JComboBox is focused without the click already, the click can be removed.

This pull request has now been integrated.

Changeset: 3b438a68
Author:    Damon Nguyen <dnguyen at openjdk.org>
Committer: Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b438a68ea605959edcb836e116f29a4a55c31fa
Stats:     17 lines in 1 file changed: 9 ins; 5 del; 3 mod

8294067: [macOS] javax/swing/JComboBox/6559152/bug6559152.java Cannot select an item from popup with the ENTER key.

Reviewed-by: azvegint, psadhukhan

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

PR: https://git.openjdk.org/jdk/pull/10359


From kizune at openjdk.org  Tue Sep 20 18:20:55 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 20 Sep 2022 18:20:55 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v2]
In-Reply-To: <-du2igQ7Bn4EWJTLVes8IAxFV79-rZJy4Ew1k1EYRi0=.2bfe3cce-89eb-43b9-893e-d770b3ea22cc@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <-du2igQ7Bn4EWJTLVes8IAxFV79-rZJy4Ew1k1EYRi0=.2bfe3cce-89eb-43b9-893e-d770b3ea22cc@github.com>
Message-ID: <RrQbzEncoIiA_7gxtvqRwege39wogyouDDr3pM7F4M8=.0dd479f7-5d2a-48fb-865b-f9106d84b95a@github.com>

On Tue, 20 Sep 2022 00:01:27 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> JInternalFrame background color seems to overflow into the border region. This issue is more prominently seen on Windows - Metal LAF (with fractional scaling, as shown below). The primary reason is border scaling issue as observed in  - [JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614) & [JDK-8282958](https://bugs.openjdk.org/browse/JDK-8282958)
>> 
>> The fix involves a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. The test checks the midpoint and corners of borders to check if the internal frame's background color is located out of JInternalFrame.
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/190233555-a7e00f2c-9003-4c11-84fb-207957838c2f.png)
>
> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into JIFBorder_8015739
>  - added test summary
>  - updated test case
>  - Added test case, minor position changes to shadow lines
>  - expanded imports
>  - JIF Metal Border Scaling - Initial changes

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 365:

> 363: 
> 364:         public Insets getBorderInsets(Component c, Insets newInsets) {
> 365:           newInsets.set(5, 5, 5, 5);

The default code inset is 4 so this formatting looks incorrect. Plus, i understand that you were trying to better indent the code but usually if code is not changed functionally we avoid changing the lines to make code annotation more informative.

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

PR: https://git.openjdk.org/jdk/pull/10274


From kizune at openjdk.org  Tue Sep 20 18:25:36 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 20 Sep 2022 18:25:36 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v2]
In-Reply-To: <-du2igQ7Bn4EWJTLVes8IAxFV79-rZJy4Ew1k1EYRi0=.2bfe3cce-89eb-43b9-893e-d770b3ea22cc@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <-du2igQ7Bn4EWJTLVes8IAxFV79-rZJy4Ew1k1EYRi0=.2bfe3cce-89eb-43b9-893e-d770b3ea22cc@github.com>
Message-ID: <MLqQD57AUwPmzF3cANN4iN1dNv7s0i4FFs3mOHAAtcM=.9b06fcce-9974-4c92-bd02-2e6a043f2965@github.com>

On Tue, 20 Sep 2022 00:01:27 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> JInternalFrame background color seems to overflow into the border region. This issue is more prominently seen on Windows - Metal LAF (with fractional scaling, as shown below). The primary reason is border scaling issue as observed in  - [JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614) & [JDK-8282958](https://bugs.openjdk.org/browse/JDK-8282958)
>> 
>> The fix involves a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. The test checks the midpoint and corners of borders to check if the internal frame's background color is located out of JInternalFrame.
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/190233555-a7e00f2c-9003-4c11-84fb-207957838c2f.png)
>
> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into JIFBorder_8015739
>  - added test summary
>  - updated test case
>  - Added test case, minor position changes to shadow lines
>  - expanded imports
>  - JIF Metal Border Scaling - Initial changes

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 277:

> 275:             }
> 276: 
> 277:             Graphics2D g2d = (Graphics2D) g;

Regardless, i see that absolutely similar code down this file for FrameBorder and DialogBorder. Are these UI elements suffer from the same issue or is it only limited to InternalFrame? If they do suffer from the same issue i would suggest either fixing it all together or at least submitting new bugs tracking existence of the problem. Of course problem might not be present for some reason in these components but it is worth checking it out while you are working on the code and remember all the details.

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

PR: https://git.openjdk.org/jdk/pull/10274


From achung at openjdk.org  Tue Sep 20 18:32:31 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 20 Sep 2022 18:32:31 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0
Message-ID: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>

Fixed test bug where mouse location was being calculated before robot mouseMove operation was complete

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

Commit messages:
 - added robot wait to prevent mouse position from being calculated before robot finishes mouseMove

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

PR: https://git.openjdk.org/jdk/pull/10363


From duke at openjdk.org  Tue Sep 20 19:20:00 2022
From: duke at openjdk.org (ScientificWare)
Date: Tue, 20 Sep 2022 19:20:00 GMT
Subject: RFR: 8294038: Remove "Classpath" exception from javax/swing tests
In-Reply-To: <Ey3xTLlK02zVshgF2rO7Y0wf9-36QQ_68LkmQfcVJcE=.80f191f8-def2-49dd-8ab6-7353f164120a@github.com>
References: <Ey3xTLlK02zVshgF2rO7Y0wf9-36QQ_68LkmQfcVJcE=.80f191f8-def2-49dd-8ab6-7353f164120a@github.com>
Message-ID: <9PsrA12Xjje0E8PT39XDDOFBwVjzJUAHllDgXo30wlI=.7fbd0e0a-4ef0-4395-818c-86225be4cd1d@github.com>

On Tue, 20 Sep 2022 16:34:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Remove *the "Classpath" exception* from tests in `javax/swing`. The tests should not have it.

Is there an official Copyright License Header for test codes.
Adding `@author` tag is not allowed but what's about copyright mention ?

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

PR: https://git.openjdk.org/jdk/pull/10360


From aivanov at openjdk.org  Tue Sep 20 19:49:40 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 Sep 2022 19:49:40 GMT
Subject: RFR: 8294038: Remove "Classpath" exception from javax/swing tests
In-Reply-To: <9PsrA12Xjje0E8PT39XDDOFBwVjzJUAHllDgXo30wlI=.7fbd0e0a-4ef0-4395-818c-86225be4cd1d@github.com>
References: <Ey3xTLlK02zVshgF2rO7Y0wf9-36QQ_68LkmQfcVJcE=.80f191f8-def2-49dd-8ab6-7353f164120a@github.com>
 <9PsrA12Xjje0E8PT39XDDOFBwVjzJUAHllDgXo30wlI=.7fbd0e0a-4ef0-4395-818c-86225be4cd1d@github.com>
Message-ID: <i02kJCwteHF14iHBUMWxrzgVIXLfvtu_J8veLf6fNew=.5d5984ab-9b48-4003-9316-1768a72a5c63@github.com>

On Tue, 20 Sep 2022 19:15:22 GMT, ScientificWare <duke at openjdk.org> wrote:

> Is there an official Copyright License Header for test codes.

For new files, you usually take the copyright comment from a file nearby. All tests should use GPLv2 _**without** the "Classpath" exception_. The source code in `src` directory has the "Classpath" exception.

> Adding `@author` tag is not allowed

Here's a quote from [the jtreg tag spec](https://openjdk.org/jtreg/tag-spec.html#INFORMATIONAL_TAGS): ?Use of this tag is now generally _discouraged_; information about the author and other contributions is generally better left to the source code management system for the test suite.?

With Git, your name will be associated with the commit, thus all the code you contribute, unless modified, will be attributed to you without the use of the `@author` tag.

> ?but what's about copyright mention ?

You contribute the code [under the OCA](https://openjdk.org/guide/#sign-the-oca), ?This agreement gives Oracle and you as a contributor joint copyright interests in the code. You will retain your copyright while also granting those rights to Oracle.?

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

PR: https://git.openjdk.org/jdk/pull/10360


From duke at openjdk.org  Tue Sep 20 21:38:48 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Tue, 20 Sep 2022 21:38:48 GMT
Subject: RFR: 8292309 : Fix
 java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java test
 [v3]
In-Reply-To: <uFqQUzkuWOrGXowhXEwVwRN5HjCisrPLGNK-rpaUyUc=.6c97b5ba-e463-45d1-8cb4-e4799148e212@github.com>
References: <uFqQUzkuWOrGXowhXEwVwRN5HjCisrPLGNK-rpaUyUc=.6c97b5ba-e463-45d1-8cb4-e4799148e212@github.com>
Message-ID: <pj-9Z23sskoEF5GTDQfp_n-xFTZSQ9JfEpTL4M5thwA=.247a77a6-6cb0-4741-bdc6-adce5254bf2a@github.com>

> 1) Fixed Parse Exception by removing yesno
> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno
> 2) Throw jtreg.SkippedException when printer is not configured on the test host
> 3) Replaced Sysout & TestDialog with ManualTestFrame, which allows to the user to better decide test results and to take screen shot if test fails.
> 
> @shurymury

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

  Removed @key printer keyword since this is a manual test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9865/files
  - new: https://git.openjdk.org/jdk/pull/9865/files/07495189..f9e40ce1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9865&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9865&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/9865


From duke at openjdk.org  Tue Sep 20 21:38:49 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Tue, 20 Sep 2022 21:38:49 GMT
Subject: RFR: 8292309 : Fix
 java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java test
 [v2]
In-Reply-To: <VMTD0XIVmHyVmza1t3HgFiZccJ7EMmzXgooQlQPgmyk=.74207d3f-3ed3-4c3c-9fa1-a90df2e411b2@github.com>
References: <uFqQUzkuWOrGXowhXEwVwRN5HjCisrPLGNK-rpaUyUc=.6c97b5ba-e463-45d1-8cb4-e4799148e212@github.com>
 <VMTD0XIVmHyVmza1t3HgFiZccJ7EMmzXgooQlQPgmyk=.74207d3f-3ed3-4c3c-9fa1-a90df2e411b2@github.com>
Message-ID: <KYRoBpA-t6IYL3SsIBYFijkLFoJ5JdAuM9km2BV3L4M=.bf5bde62-fedd-4bd5-ae76-5f28e59e2280@github.com>

On Wed, 7 Sep 2022 22:42:35 GMT, lawrence.andrews <duke at openjdk.org> wrote:

>> 1) Fixed Parse Exception by removing yesno
>> test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno
>> 2) Throw jtreg.SkippedException when printer is not configured on the test host
>> 3) Replaced Sysout & TestDialog with ManualTestFrame, which allows to the user to better decide test results and to take screen shot if test fails.
>> 
>> @shurymury
>
> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Show Frame with in EDT

Removed @key printer since its a label on the test that used to filter the test & since its a manual test we dn't need the label. We can use SkippedException if printer on available we can throw the exception.

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

PR: https://git.openjdk.org/jdk/pull/9865


From duke at openjdk.org  Wed Sep 21 03:29:35 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 21 Sep 2022 03:29:35 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v21]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <u3_r-i91t0JS7esESob9Nc6Ev2vi6UnPOGrkbsJ6p-c=.7430af68-f4ee-4974-b271-a72fce89aed5@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

  Corrects Licence Header.
  
  Removes Classpath exception.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/f3989131..0942e727

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=19-20

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

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Wed Sep 21 03:37:44 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 21 Sep 2022 03:37:44 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v7]
In-Reply-To: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
Message-ID: <ZCAzpPxly5LM7N0RzuqEj6XlAMwQBy1a1-9XRQLiufE=.fba0e65b-7bd1-4657-9337-6beefb256e5c@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
> 
> This is tracked in JBS as 
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
> 
> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
> 
> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)

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

  Corrects Licence Header.
  
  Removes Classpath exception.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10317/files
  - new: https://git.openjdk.org/jdk/pull/10317/files/e6454c11..478f285e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/10317


From duke at openjdk.org  Wed Sep 21 04:19:47 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 21 Sep 2022 04:19:47 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v6]
In-Reply-To: <DmaK20O4iPQJGHZyci3IQEsFFbdhnBgMmB4Aok-GE9g=.4884358d-108b-4115-a948-180727268137@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <592sDW2VIvByGwKDoAYG5P7a4Iygc5CYtPVG7vr9qrk=.12f3db5e-a3a7-41c6-b5f9-e1588507bbe2@github.com>
 <DmaK20O4iPQJGHZyci3IQEsFFbdhnBgMmB4Aok-GE9g=.4884358d-108b-4115-a948-180727268137@github.com>
Message-ID: <9IcWmdIdCMrumRyOS5x7jDOze5q-l4ORUnX4LlF4ivY=.dc5404a8-e79d-4384-a6c1-28ccdba78a65@github.com>

On Mon, 19 Sep 2022 16:36:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Corrects typos and digit extraction.
>>   
>>   Corrects typos.
>>   And applies a better digit extraction as suggested in main-line review thread.
>
> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1366:
> 
>> 1364:             digits = digits.substring(1, Math.min(n, 9));
>> 1365:             n--;
>> 1366:         }
> 
> Should the method return `null` immediately if `n < 3 || n > 8` after the if block at lines 1363-1366? It's already known the format is invalid.
> 
> I also propose adding `hex.matcher(digits).matches()` here to avoid running the matcher at each attempt.
> 
> In short, the next statement should be:
> 
> 
> if (n < 3 || n == 7 || n > 8 || !hex.matcher(digits).matches()) {
>     return null;
> }
> 
> 
> The following code deals with a valid color notation.

@aivanov-jdk, I suppose that most of color notations are correct.
Adding these tests in first place has a time cost.
With `&&`, `hex.matcher(digits).matches()` is evaluated only once.
That why I separated length test from hex test. Pattern usage has a significant time cost.

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

PR: https://git.openjdk.org/jdk/pull/10317


From dholmes at openjdk.org  Wed Sep 21 06:47:58 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Sep 2022 06:47:58 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <q6ToSabdUIWS0vK-13JWdvQySwco64A_gP20tVsm9FI=.7722abf4-9470-4a52-9f8e-48cb2481eb77@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
 <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>
 <jhvaxnF1s7-oPaVsF9nf5ko8wP1gBWOo5TfO8T_j40A=.731ea409-ca17-488e-a0b1-3cb15334515a@github.com>
 <q6ToSabdUIWS0vK-13JWdvQySwco64A_gP20tVsm9FI=.7722abf4-9470-4a52-9f8e-48cb2481eb77@github.com>
Message-ID: <babX5XCHpbm-0i8-pwGE7t-8E4suI6kn5k3DAzgnkGs=.66c28495-4492-409f-8bf6-c92f87a153ec@github.com>

On Tue, 20 Sep 2022 16:29:08 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>>> Good to see this finally become non-functional but as long as the debugger/JVMTI can trigger throwing an async ThreadDeath then I have to question the potential change in behaviour introduced by removing all the `catch (ThreadDeath td)` logic in various places.
>> 
>> I've gone through this a few times too and concluded it would be better to remove these untestable code paths. The debugger scenario is more like what used to be Thread.stop(Throwable). It can be used to throw any exception or error, e.g. ask the debugger to throw IllegalArgumentException or SQLException when I'm at this breakpoint so I can see how the code behaves. Yes, the user could ask the debugger to throw java.lang.ThreadDeath when prompted but it's not really interesting now because code won't get this error outside of a debugger. We could leave the special handing but we have no way to test is and we'll need to the remove the special handling when TD is removed.  As a general point, the special casing of TD is a bit inconsistent and more likely to be seen in older code rather newer code. A static analysis of 24M classes found very few usages in 3rd party libraries.
>
> I agree with Alan on this. First, use and handling of `ThreadDeath` is quite rare; see my [analysis](https://bugs.openjdk.org/browse/JDK-8289610?focusedCommentId=14523723&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14523723) of the corpus search results in the bug report. Second, while this does change the behavior in the debugger case, I'm hard-pressed to see how anybody is _relying_ on such behavior. And maybe somebody somewhere is indeed relying on this behavior, but it doesn't seem to me this behavior is guaranteed by any specifications.
> 
> A more likely way that programs could observe changes in `ThreadDeath` handling occurs when programs throw `ThreadDeath` explicitly, that is, not using `Thread.stop`. This does seem to occur infrequently "in the wild" (we'll fix the jshell case). The point of throwing `ThreadDeath` explicitly is to take advantage of special-case handling of `ThreadDeath` that might occur higher in the call stack. Such special-casing was at one time an accepted exception handing idiom, but it's essentially disused. I don't think the JDK needs to continue to support this old idiom.

Okay I will defer to your views here. Thanks.

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

PR: https://git.openjdk.org/jdk/pull/10230


From alanb at openjdk.org  Wed Sep 21 07:52:03 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Sep 2022 07:52:03 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <babX5XCHpbm-0i8-pwGE7t-8E4suI6kn5k3DAzgnkGs=.66c28495-4492-409f-8bf6-c92f87a153ec@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
 <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>
 <jhvaxnF1s7-oPaVsF9nf5ko8wP1gBWOo5TfO8T_j40A=.731ea409-ca17-488e-a0b1-3cb15334515a@github.com>
 <q6ToSabdUIWS0vK-13JWdvQySwco64A_gP20tVsm9FI=.7722abf4-9470-4a52-9f8e-48cb2481eb77@github.com>
 <babX5XCHpbm-0i8-pwGE7t-8E4suI6kn5k3DAzgnkGs=.66c28495-4492-409f-8bf6-c92f87a153ec@github.com>
Message-ID: <Nmq49Pi6YsAZQTWFK3729Iyyd6XCdVvCYlKFbETzv0U=.daeca85f-2d9e-4c02-af56-0754165b6466@github.com>

On Wed, 21 Sep 2022 06:43:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Okay I will defer to your views here. Thanks.

Thank you, I'll get the CSR moving again and we'll try to get this done.

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

PR: https://git.openjdk.org/jdk/pull/10230


From aturbanov at openjdk.org  Wed Sep 21 08:09:36 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 21 Sep 2022 08:09:36 GMT
Subject: RFR: 8293986: Incorrect double-checked locking in
 com.sun.beans.introspect.ClassInfo
Message-ID: <xy5SGxYpSr1HEYXXTGxlr_dJz4bwQmMaHZ0-rSnzbxk=.fbede544-9152-4320-b97c-aa50209f0b42@github.com>

Fields `methods`, `properties`, `eventSets` are not volatile and read multiple times. This makes it an incorrect DCL.

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

Commit messages:
 - 8293986: Incorrect double-checked locking in com.sun.beans.introspect.ClassInfo

Changes: https://git.openjdk.org/jdk/pull/10372/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10372&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293986
  Stats: 25 lines in 1 file changed: 9 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/10372.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10372/head:pull/10372

PR: https://git.openjdk.org/jdk/pull/10372


From dmarkov at openjdk.org  Wed Sep 21 09:30:44 2022
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Wed, 21 Sep 2022 09:30:44 GMT
Subject: RFR: 8294039: Remove "Classpath" exception from java/awt tests
In-Reply-To: <cow8RaT1qCUrcC5APnQwQTFeQ2SOxI2e53Ysc3SgqTY=.87596b1c-9219-4991-863f-e22dca71f5e6@github.com>
References: <cow8RaT1qCUrcC5APnQwQTFeQ2SOxI2e53Ysc3SgqTY=.87596b1c-9219-4991-863f-e22dca71f5e6@github.com>
Message-ID: <8qSTxj47BnHjPLVuSHnJfjGFv_dK6O_bkplwlD9M3YQ=.9bbdc67b-3975-41a2-bcd2-ac6d90551f0c@github.com>

On Tue, 20 Sep 2022 16:38:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Remove *the "Classpath" exception* from tests in `javax/awt`. The tests should not have it.

Marked as reviewed by dmarkov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10361


From dmarkov at openjdk.org  Wed Sep 21 09:34:57 2022
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Wed, 21 Sep 2022 09:34:57 GMT
Subject: RFR: 8294038: Remove "Classpath" exception from javax/swing tests
In-Reply-To: <Ey3xTLlK02zVshgF2rO7Y0wf9-36QQ_68LkmQfcVJcE=.80f191f8-def2-49dd-8ab6-7353f164120a@github.com>
References: <Ey3xTLlK02zVshgF2rO7Y0wf9-36QQ_68LkmQfcVJcE=.80f191f8-def2-49dd-8ab6-7353f164120a@github.com>
Message-ID: <HYYqo-PjS1ircyMHAeNwEXFIHC8rCnl2ARBY0lqYNbo=.6a495750-9b48-475d-93df-540ac771b96f@github.com>

On Tue, 20 Sep 2022 16:34:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Remove *the "Classpath" exception* from tests in `javax/swing`. The tests should not have it.

Marked as reviewed by dmarkov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10360


From ihse at openjdk.org  Wed Sep 21 11:49:11 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Sep 2022 11:49:11 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v9]
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: <Z-vGVQyCFE5X1N4KLD21UXXI6z2XF309PkIQU8hgzKw=.cf11bc16-75a9-4ecf-8b41-54304233a686@github.com>

> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
> 
> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Revert changes to glext.h
 - Revert changes to multiVis.c and wsutils.h

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8328/files
  - new: https://git.openjdk.org/jdk/pull/8328/files/1ce28314..e9f67a30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8328&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8328&range=07-08

  Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/8328.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8328/head:pull/8328

PR: https://git.openjdk.org/jdk/pull/8328


From ihse at openjdk.org  Wed Sep 21 11:52:57 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Sep 2022 11:52:57 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>

> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
> 
> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:

 - Merge branch 'master' into typos-in-java.desktop
 - Revert changes to glext.h
 - Revert changes to multiVis.c and wsutils.h
 - Merge branch 'master' into typos-in-java.desktop
 - Revert changes in libjpeg
 - Revert changes in libfreetype
 - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - ... and 39 more: https://git.openjdk.org/jdk/compare/cddd6def...2850610d

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

Changes: https://git.openjdk.org/jdk/pull/8328/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8328&range=09
  Stats: 1018 lines in 483 files changed: 0 ins; 0 del; 1018 mod
  Patch: https://git.openjdk.org/jdk/pull/8328.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8328/head:pull/8328

PR: https://git.openjdk.org/jdk/pull/8328


From ihse at openjdk.org  Wed Sep 21 11:52:57 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Sep 2022 11:52:57 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v8]
In-Reply-To: <alS4RnqiswWATvVIotbyYFGhRJDyO5_JCAU24l30HBs=.2fa01b63-f674-4c78-b7bc-798120cf9694@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <ODn97JJKjKBx4onwvwec5ORddVWdcX_dBcwKK6OWjxI=.0b575727-55d6-4a5e-8f1b-4ea3c0dab18c@github.com>
 <ui8gSZ1FuatyMVWlOCAsBEaJjUVE6ufwhMvROIZQrFQ=.6e09c806-811c-44d8-a321-11b68afde29b@github.com>
 <alS4RnqiswWATvVIotbyYFGhRJDyO5_JCAU24l30HBs=.2fa01b63-f674-4c78-b7bc-798120cf9694@github.com>
Message-ID: <9vrVAfhskr81N1Y120kxvtI9Y9y_Y5G50uDkW1Ynvh0=.569c74fd-5ae2-46f5-8bea-7e903e53ffc9@github.com>

On Tue, 13 Sep 2022 22:03:44 GMT, Phil Race <prr at openjdk.org> wrote:

>> I see now that Phil cryptically said:
>> 
>>> Regarding changes in gif + freetype
>> diff --git a/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c b/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c \
>> \
>> diff --git a/src/java.desktop/share/native/libfontmanager/freetypeScaler.c b/src/java.desktop/share/native/libfontmanager/freetypeScaler.c \
>> \
>> Please exclude ALL 3rd party libraries from this PR.
>> 
>> That might be interpreted as stating that `gifdecoder.c` is 3rd party source code (although that was by no means clear to me the first time I read it). I'll revert the changes in that file, and also `src/java.desktop/share/native/libfontmanager/freetypeScaler.c`.
>
>> I see now that Phil cryptically said:
>> 
>> > Regarding changes in gif + freetype
>> > diff --git a/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c b/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c 
>> > 
>> > diff --git a/src/java.desktop/share/native/libfontmanager/freetypeScaler.c b/src/java.desktop/share/native/libfontmanager/freetypeScaler.c 
>> > 
>> > Please exclude ALL 3rd party libraries from this PR.
>> 
>> That might be interpreted as stating that `gifdecoder.c` is 3rd party source code (although that was by no means clear to me the first time I read it). I'll revert the changes in that file, and also `src/java.desktop/share/native/libfontmanager/freetypeScaler.c`.
> 
> I don't know why I mentioned those two files like that but those particular two are JDK code so are fair game.
> 
> I did write 
> "Please exclude ALL 3rd party libraries from this PR."
> and later :
> "We need to revert the native code changes to "libfreetype".
> and those points are correct.
> 
> You did fix the latter, but there are still some 3rd party files in there that are edited : glext.h, wsutils.h, multiVis.c

@prrace I have now reverted the changes to glext.h, wsutils.h and multiVis.c. Is this finally ready for merging?

(Going forward, I think we absolutely need to have some way to document in the code tree that certain files is 3rd party, like the UPSTREAM notation I previously suggested, or some variant thereof. This "tribal knowledge" about what is 3rd party is not beneficial to anyone, and only wastes both your and my time...)

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

PR: https://git.openjdk.org/jdk/pull/8328


From psadhukhan at openjdk.org  Wed Sep 21 12:35:05 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 21 Sep 2022 12:35:05 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create method are contrary to the
 documentation
Message-ID: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>

API specification says about BasicTextAreaUI.create "Returns a WrappedPlainView or PlainView". 
But for [bidi](https://github.com/openjdk/jdk/blob/d14e96d9701dae951aa365029f58afb6687a646a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java#L168) text, this method returns BoxView and other views , so the documentation needs to be updated.

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

Commit messages:
 - JDK-6229853: BasicTextAreaUI:create method are contrary to the documentation

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

PR: https://git.openjdk.org/jdk/pull/10376


From iris at openjdk.org  Wed Sep 21 16:36:27 2022
From: iris at openjdk.org (Iris Clark)
Date: Wed, 21 Sep 2022 16:36:27 GMT
Subject: RFR: 8294039: Remove "Classpath" exception from java/awt tests
In-Reply-To: <cow8RaT1qCUrcC5APnQwQTFeQ2SOxI2e53Ysc3SgqTY=.87596b1c-9219-4991-863f-e22dca71f5e6@github.com>
References: <cow8RaT1qCUrcC5APnQwQTFeQ2SOxI2e53Ysc3SgqTY=.87596b1c-9219-4991-863f-e22dca71f5e6@github.com>
Message-ID: <0g_4vgG_e4nixg7-IgcwTnBaBto6-bG3J3Cf4r5cEjU=.08c6661a-df51-4cb7-9820-5616ec35b0d9@github.com>

On Tue, 20 Sep 2022 16:38:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Remove *the "Classpath" exception* from tests in `javax/awt`. The tests should not have it.

The updated license appears to match the GPL header (https://github.com/openjdk/jdk/blob/master/make/data/license-templates/gpl-header) as expected.

Thank you!

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

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10361


From iris at openjdk.org  Wed Sep 21 16:41:24 2022
From: iris at openjdk.org (Iris Clark)
Date: Wed, 21 Sep 2022 16:41:24 GMT
Subject: RFR: 8294038: Remove "Classpath" exception from javax/swing tests
In-Reply-To: <Ey3xTLlK02zVshgF2rO7Y0wf9-36QQ_68LkmQfcVJcE=.80f191f8-def2-49dd-8ab6-7353f164120a@github.com>
References: <Ey3xTLlK02zVshgF2rO7Y0wf9-36QQ_68LkmQfcVJcE=.80f191f8-def2-49dd-8ab6-7353f164120a@github.com>
Message-ID: <m6KFrdP4C6kM-lV039-5kScMx0RkOKUXu2Ubn7Pwfkc=.7903aa06-36fe-4bde-88d3-2d6f4a5ad3a8@github.com>

On Tue, 20 Sep 2022 16:34:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Remove *the "Classpath" exception* from tests in `javax/swing`. The tests should not have it.

The updated license appears to match the GPL header (https://github.com/openjdk/jdk/blob/master/make/data/license-templates/gpl-header) as expected.

Thanks!

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

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10360


From aivanov at openjdk.org  Wed Sep 21 17:03:43 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Sep 2022 17:03:43 GMT
Subject: Integrated: 8294038: Remove "Classpath" exception from javax/swing
 tests
In-Reply-To: <Ey3xTLlK02zVshgF2rO7Y0wf9-36QQ_68LkmQfcVJcE=.80f191f8-def2-49dd-8ab6-7353f164120a@github.com>
References: <Ey3xTLlK02zVshgF2rO7Y0wf9-36QQ_68LkmQfcVJcE=.80f191f8-def2-49dd-8ab6-7353f164120a@github.com>
Message-ID: <ESpgj7Za4gFztHiQaCPzZrPezQRlQlHaaRsxcC2gg90=.9231f5f9-365c-484e-be91-e36e7b9303fd@github.com>

On Tue, 20 Sep 2022 16:34:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Remove *the "Classpath" exception* from tests in `javax/swing`. The tests should not have it.

This pull request has now been integrated.

Changeset: 27b8e2f4
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/27b8e2f49e372e09e8f070e9c90babd82e015dbf
Stats:     34 lines in 11 files changed: 0 ins; 23 del; 11 mod

8294038: Remove "Classpath" exception from javax/swing tests

Reviewed-by: dmarkov, iris

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

PR: https://git.openjdk.org/jdk/pull/10360


From aivanov at openjdk.org  Wed Sep 21 17:04:43 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 21 Sep 2022 17:04:43 GMT
Subject: Integrated: 8294039: Remove "Classpath" exception from java/awt tests
In-Reply-To: <cow8RaT1qCUrcC5APnQwQTFeQ2SOxI2e53Ysc3SgqTY=.87596b1c-9219-4991-863f-e22dca71f5e6@github.com>
References: <cow8RaT1qCUrcC5APnQwQTFeQ2SOxI2e53Ysc3SgqTY=.87596b1c-9219-4991-863f-e22dca71f5e6@github.com>
Message-ID: <hHiHr4nKeaZWBI4FE-r7p-nxSFnzqD4Olf0CJmri568=.24a9d1e7-f97c-498a-8e16-ed86887c595a@github.com>

On Tue, 20 Sep 2022 16:38:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Remove *the "Classpath" exception* from tests in `javax/awt`. The tests should not have it.

This pull request has now been integrated.

Changeset: 711e2520
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/711e2520adf87b8c285db07ff485fe4f6d0c349b
Stats:     106 lines in 29 files changed: 0 ins; 77 del; 29 mod

8294039: Remove "Classpath" exception from java/awt tests

Reviewed-by: dmarkov, iris

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

PR: https://git.openjdk.org/jdk/pull/10361


From honkar at openjdk.org  Wed Sep 21 17:50:38 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 21 Sep 2022 17:50:38 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v2]
In-Reply-To: <MLqQD57AUwPmzF3cANN4iN1dNv7s0i4FFs3mOHAAtcM=.9b06fcce-9974-4c92-bd02-2e6a043f2965@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <-du2igQ7Bn4EWJTLVes8IAxFV79-rZJy4Ew1k1EYRi0=.2bfe3cce-89eb-43b9-893e-d770b3ea22cc@github.com>
 <MLqQD57AUwPmzF3cANN4iN1dNv7s0i4FFs3mOHAAtcM=.9b06fcce-9974-4c92-bd02-2e6a043f2965@github.com>
Message-ID: <-1VSj22dIo66d_Ba03me1C9TvX2MpZDJSXkSa_f2iaw=.088f0366-28dd-4257-85c1-d20399767a4d@github.com>

On Tue, 20 Sep 2022 18:22:20 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JIFBorder_8015739
>>  - added test summary
>>  - updated test case
>>  - Added test case, minor position changes to shadow lines
>>  - expanded imports
>>  - JIF Metal Border Scaling - Initial changes
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 277:
> 
>> 275:             }
>> 276: 
>> 277:             Graphics2D g2d = (Graphics2D) g;
> 
> Regardless, i see that absolutely similar code down this file for FrameBorder and DialogBorder. Are these UI elements suffer from the same issue or is it only limited to InternalFrame? If they do suffer from the same issue i would suggest either fixing it all together or at least submitting new bugs tracking existence of the problem. Of course problem might not be present for some reason in these components but it is worth checking it out while you are working on the code and remember all the details.

@azuev-java Sure. I'll check if there is any observable distortion in other components and either make changes as part of this PR or track it under JDK-8282958. Currently there exists a generic umbrella issue created for border scaling issue - [JDK-8282958](https://bugs.openjdk.org/browse/JDK-8282958), all the related issues are linked to it. The plan is to create a utility method (for common steps) that can be reused across components where this border rendering issue is observed.

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

PR: https://git.openjdk.org/jdk/pull/10274


From duke at openjdk.org  Wed Sep 21 18:05:23 2022
From: duke at openjdk.org (Stanimir Stamenkov)
Date: Wed, 21 Sep 2022 18:05:23 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v2]
In-Reply-To: <-du2igQ7Bn4EWJTLVes8IAxFV79-rZJy4Ew1k1EYRi0=.2bfe3cce-89eb-43b9-893e-d770b3ea22cc@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <-du2igQ7Bn4EWJTLVes8IAxFV79-rZJy4Ew1k1EYRi0=.2bfe3cce-89eb-43b9-893e-d770b3ea22cc@github.com>
Message-ID: <HmFK_XRFaFHmlLEdj028fVwAHDQoRPSeoQDGO7R7nCY=.dbb04422-fc58-439b-901c-edd3d97be93d@github.com>

On Tue, 20 Sep 2022 00:01:27 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> JInternalFrame background color seems to overflow into the border region. This issue is more prominently seen on Windows - Metal LAF (with fractional scaling, as shown below). The primary reason is border scaling issue as observed in  - [JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614) & [JDK-8282958](https://bugs.openjdk.org/browse/JDK-8282958)
>> 
>> The fix involves a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. The test checks the midpoint and corners of borders to check if the internal frame's background color is located out of JInternalFrame.
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/190233555-a7e00f2c-9003-4c11-84fb-207957838c2f.png)
>
> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into JIFBorder_8015739
>  - added test summary
>  - updated test case
>  - Added test case, minor position changes to shadow lines
>  - expanded imports
>  - JIF Metal Border Scaling - Initial changes

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 313:

> 311: 
> 312:             // border and corner scaling
> 313:             corner = (int) Math.round(corner * at.getScaleX());

I'm likely missing something from the big picture but wouldn't this accumulate on every `paintBorder()` invocation (into a static field)?

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

PR: https://git.openjdk.org/jdk/pull/10274


From honkar at openjdk.org  Wed Sep 21 18:16:39 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 21 Sep 2022 18:16:39 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v3]
In-Reply-To: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
Message-ID: <O3RhpyTj4fWb7_7miXFCYpBDg75eWI_6c5BC3DfYSVY=.40dea9d8-237e-4d49-ab77-c77e0fd7d942@github.com>

> JInternalFrame background color seems to overflow into the border region. This issue is more prominently seen on Windows - Metal LAF (with fractional scaling, as shown below). The primary reason is border scaling issue as observed in  - [JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614) & [JDK-8282958](https://bugs.openjdk.org/browse/JDK-8282958)
> 
> The fix involves a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. The test checks the midpoint and corners of borders to check if the internal frame's background color is located out of JInternalFrame.
> 
> ![image](https://user-images.githubusercontent.com/95945681/190233555-a7e00f2c-9003-4c11-84fb-207957838c2f.png)

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

  added local variable for scaled corner

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10274/files
  - new: https://git.openjdk.org/jdk/pull/10274/files/b02179cd..ced69a3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10274&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10274&range=01-02

  Stats: 18 lines in 1 file changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/10274.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10274/head:pull/10274

PR: https://git.openjdk.org/jdk/pull/10274


From honkar at openjdk.org  Wed Sep 21 18:22:29 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 21 Sep 2022 18:22:29 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v2]
In-Reply-To: <HmFK_XRFaFHmlLEdj028fVwAHDQoRPSeoQDGO7R7nCY=.dbb04422-fc58-439b-901c-edd3d97be93d@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <-du2igQ7Bn4EWJTLVes8IAxFV79-rZJy4Ew1k1EYRi0=.2bfe3cce-89eb-43b9-893e-d770b3ea22cc@github.com>
 <HmFK_XRFaFHmlLEdj028fVwAHDQoRPSeoQDGO7R7nCY=.dbb04422-fc58-439b-901c-edd3d97be93d@github.com>
Message-ID: <z6UeX7tEq1awWTp5FCITLT89aJM1Ey8CDDJ_Z0Hfcos=.8469ea5a-5a80-4cd7-933b-166c19194473@github.com>

On Wed, 21 Sep 2022 18:03:08 GMT, Stanimir Stamenkov <duke at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JIFBorder_8015739
>>  - added test summary
>>  - updated test case
>>  - Added test case, minor position changes to shadow lines
>>  - expanded imports
>>  - JIF Metal Border Scaling - Initial changes
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 313:
> 
>> 311: 
>> 312:             // border and corner scaling
>> 313:             corner = (int) Math.round(corner * at.getScaleX());
> 
> I'm likely missing something from the big picture but wouldn't this accumulate on every `paintBorder()` invocation (into a static field)?

@stanio Hi, @azuev-java did bring up the same point earlier - https://github.com/openjdk/jdk/pull/10274#discussion_r974609469. In the recent commit, I have update the code to use a different local variable - `scaledCorner` to compute and store the scaled value for each new instance.

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

PR: https://git.openjdk.org/jdk/pull/10274


From achung at openjdk.org  Wed Sep 21 20:25:55 2022
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 21 Sep 2022 20:25:55 GMT
Subject: RFR: 8292214: Memory leak in getAllConfigs of awt_GraphicsEnv.c:386
Message-ID: <1gj0XMmbPLGkiWBwJ09LeKvujGCrLa45Qm5utSp-dCI=.1c9f3e8d-4ef4-4e4e-8a57-cd288645b961@github.com>

changed return to cleanup in getAllConfigs
changed cleanup to loop thru and free all allocated memory adjacent to graphicsConfig pointer

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

Commit messages:
 - corrected loop thru graphicsConfigs
 - init commit

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

PR: https://git.openjdk.org/jdk/pull/10378


From honkar at openjdk.org  Wed Sep 21 22:59:19 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 21 Sep 2022 22:59:19 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v4]
In-Reply-To: <kCzHnECHQqkjWksA-W2MrYWheE7WPjgFk8oziVgtDPU=.3f93daaf-315a-4140-a866-354ceddc5ca4@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <kCzHnECHQqkjWksA-W2MrYWheE7WPjgFk8oziVgtDPU=.3f93daaf-315a-4140-a866-354ceddc5ca4@github.com>
Message-ID: <GlekI298_pMUxeVBPG-5DEkww2GIWgBnJzqvbO571gE=.93b51a17-40bd-493f-ab4e-6924cfd2a844@github.com>

On Mon, 19 Sep 2022 23:24:45 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
>> 
>> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
>> 
>> The test is generic though the issue and fix is on Windows platform because the condition 
>> `frame.getSize() == frame.getPreferredSize()` should be true on all platforms when frame.pack() is called.
>> 
>> Following is the link to Windows System Metrics (used for native insets) - https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted the changes related to previous fix - checking the type of target object

Additionally `extraBottomInsets` variable which is initialized to zero from the start, does not seem to change anything and can be removed as part of this PR changes. https://github.com/openjdk/jdk/blob/e1958971c95a651da9e7fca7a98828f7fd0391bb/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L1391

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

PR: https://git.openjdk.org/jdk/pull/9954


From kizune at openjdk.org  Thu Sep 22 00:13:21 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 22 Sep 2022 00:13:21 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v4]
In-Reply-To: <kCzHnECHQqkjWksA-W2MrYWheE7WPjgFk8oziVgtDPU=.3f93daaf-315a-4140-a866-354ceddc5ca4@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <kCzHnECHQqkjWksA-W2MrYWheE7WPjgFk8oziVgtDPU=.3f93daaf-315a-4140-a866-354ceddc5ca4@github.com>
Message-ID: <gshHs6vhjxNq48-fdKVVnajxuaabIgqRZEHAZn-A8TI=.7db8338a-a24c-42d4-ab7b-ed671a841776@github.com>

On Mon, 19 Sep 2022 23:24:45 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
>> 
>> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
>> 
>> The test is generic though the issue and fix is on Windows platform because the condition 
>> `frame.getSize() == frame.getPreferredSize()` should be true on all platforms when frame.pack() is called.
>> 
>> Following is the link to Windows System Metrics (used for native insets) - https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted the changes related to previous fix - checking the type of target object

Final version looks good to me.

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

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9954


From duke at openjdk.org  Thu Sep 22 01:31:33 2022
From: duke at openjdk.org (SWinxy)
Date: Thu, 22 Sep 2022 01:31:33 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
Message-ID: <uFQfE9tIok8RZQgHeC5lfNaifh1V1-Sb-QFEJqfzXVc=.eae5e99b-e369-439b-aae3-b83ad0edc407@github.com>

On Wed, 21 Sep 2022 11:52:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:
> 
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes to glext.h
>  - Revert changes to multiVis.c and wsutils.h
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes in libjpeg
>  - Revert changes in libfreetype
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 39 more: https://git.openjdk.org/jdk/compare/cddd6def...2850610d

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTheme.java line 68:

> 66: public abstract class MetalTheme {
> 67: 
> 68:     // Constants identifying the various Fonts that a Theme can support

I think this is possibly meant to say "constants that *our* theme can support"?

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

PR: https://git.openjdk.org/jdk/pull/8328


From duke at openjdk.org  Thu Sep 22 01:39:24 2022
From: duke at openjdk.org (SWinxy)
Date: Thu, 22 Sep 2022 01:39:24 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
Message-ID: <uXWf5UhTZR3rpC8bxMwwQmCk_y0a6wzG-Qfvsmoj1yY=.79628968-cbf7-4c0e-b306-bb12255b9db2@github.com>

On Wed, 21 Sep 2022 11:52:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:
> 
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes to glext.h
>  - Revert changes to multiVis.c and wsutils.h
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes in libjpeg
>  - Revert changes in libfreetype
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 39 more: https://git.openjdk.org/jdk/compare/cddd6def...2850610d

src/java.desktop/share/classes/sun/awt/SunToolkit.java line 1434:

> 1432: 
> 1433:     /**
> 1434:      * Parameterless version of realsync which uses default timeout (see DEFAULT_WAIT_TIME).

Suggestion:

     * Parameterless version of realsync which uses the {@link #DEFAULT_WAIT_TIME default timeout}.

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

PR: https://git.openjdk.org/jdk/pull/8328


From duke at openjdk.org  Thu Sep 22 01:56:31 2022
From: duke at openjdk.org (SWinxy)
Date: Thu, 22 Sep 2022 01:56:31 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
Message-ID: <XCg0TwFX1eu2C06QhdXUNs95QGqcb4COV8MHi7V7Uuc=.894a9033-7a80-4232-8d4b-8527a1c3c6b3@github.com>

On Wed, 21 Sep 2022 11:52:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:
> 
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes to glext.h
>  - Revert changes to multiVis.c and wsutils.h
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes in libjpeg
>  - Revert changes in libfreetype
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 39 more: https://git.openjdk.org/jdk/compare/cddd6def...2850610d

Everything looks fine, and you can freely ignore my suggestions. They are just thoughts. And yeah we should probably earmark third party files to avoid "tribal knowledge".

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

PR: https://git.openjdk.org/jdk/pull/8328


From psadhukhan at openjdk.org  Thu Sep 22 04:26:17 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 22 Sep 2022 04:26:17 GMT
Subject: RFR: 8292214: Memory leak in getAllConfigs of
 awt_GraphicsEnv.c:386
In-Reply-To: <1gj0XMmbPLGkiWBwJ09LeKvujGCrLa45Qm5utSp-dCI=.1c9f3e8d-4ef4-4e4e-8a57-cd288645b961@github.com>
References: <1gj0XMmbPLGkiWBwJ09LeKvujGCrLa45Qm5utSp-dCI=.1c9f3e8d-4ef4-4e4e-8a57-cd288645b961@github.com>
Message-ID: <Aa8ffOmqr6gLu2-AjxfI4TOVhsFvWhJ72q70MM-QnZU=.d9e0a9b1-e22c-4473-b5c6-1d54365630d2@github.com>

On Wed, 21 Sep 2022 20:15:48 GMT, Alisen Chung <achung at openjdk.org> wrote:

> changed return to cleanup in getAllConfigs
> changed cleanup to loop thru and free all allocated memory adjacent to graphicsConfig pointer

src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c line 578:

> 576:             if (graphicsConfigs[i] != 0) {
> 577:                 free(graphicsConfigs[i]);
> 578:             }

It seems  `screenDataPtr->numConfigs` is updated only when `success = JNI_TRUE` and here we are checking if `success != JNI_TRUE` condition, so amnot sure if we will be getting the correct updated configs number.
I think condition should be `i< ind-1` which is updated before every allocation, but it should be verified.

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

PR: https://git.openjdk.org/jdk/pull/10378


From darcy at openjdk.org  Thu Sep 22 04:38:30 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 22 Sep 2022 04:38:30 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
Message-ID: <zjl7cwFlpwxgYjDbchAw8qBNLcLq5n4CP940XDIlq8s=.91594dec-7c4a-45b9-8cbe-ec7ec51dc74c@github.com>

On Sat, 17 Sep 2022 08:41:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>> 
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>> 
>> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>> 
>> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
>
> Alan Bateman 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 12 additional commits since the last revision:
> 
>  - Merge
>  - Updates to Java Thread Primitive Deprecation page
>  - Repalce "it" with "victim thread"
>  - Merge
>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>  - become -> became in javadoc
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/c06e7ac5...93806f99

src/java.base/share/classes/java/lang/Thread.java line 1632:

> 1630: 
> 1631:     /**
> 1632:      * Throws {@code UnsupportedOperationException}.

Consider using an implSpec tag here.

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

PR: https://git.openjdk.org/jdk/pull/10230


From tr at openjdk.org  Thu Sep 22 07:07:28 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 22 Sep 2022 07:07:28 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
Message-ID: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>

The color returned for `InteriorBackground` property is the default color used for only _WindowsClassicLookAndFeel_. For _WindowsLookAndFeel_ the `InteriorBackground` color is not been used when checkbox paint happens. In _WindowsLookAndFeel_ the CheckBox check/uncheck is drawn using `ImageCache` which is totally independent of `InteriorBackground` color in which the user expects it to be.
The proposed fix is to return null for _WindowsLookAndFeel_ (which is what happens in other LookAndFeel like Metal/Synth/Motif/Aqua ) and return default color which is the actual color used in _WindowsClassicLookAndFeel_.

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

Commit messages:
 - New line added at end of test case
 - Added Test case
 - Initial Test Fix
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge branch 'master' of github.com:TejeshR13/jdk
 - Merge branch 'openjdk:master' into master
 - ... and 4 more: https://git.openjdk.org/jdk/compare/77398430...ff011fb2

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

PR: https://git.openjdk.org/jdk/pull/10385


From alanb at openjdk.org  Thu Sep 22 07:12:29 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Sep 2022 07:12:29 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <zjl7cwFlpwxgYjDbchAw8qBNLcLq5n4CP940XDIlq8s=.91594dec-7c4a-45b9-8cbe-ec7ec51dc74c@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
 <zjl7cwFlpwxgYjDbchAw8qBNLcLq5n4CP940XDIlq8s=.91594dec-7c4a-45b9-8cbe-ec7ec51dc74c@github.com>
Message-ID: <vWJUYm6IkJ8IwojilwR4D6_uBXhPU6GsOAKgFZfG7XE=.6280413f-e994-4cad-a9e6-8d9eff0bf5dd@github.com>

On Thu, 22 Sep 2022 04:36:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Consider using an implSpec tag here.

implSpec is usually for default methods or overrideable methods. In this case, Thread.stop is final so code that extends Thread can't override and change the behavior. So it's not clear to me that implSpec would be useful as it would duplicate the description in the generated javadoc.

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

PR: https://git.openjdk.org/jdk/pull/10230


From duke at openjdk.org  Thu Sep 22 07:42:29 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 22 Sep 2022 07:42:29 GMT
Subject: Integrated: 8292376: A few Swing methods use inheritDoc on exceptions
 which are not inherited
In-Reply-To: <W1yenf_2rr8sMDSjJcKF-IGZa_mGYSG572YrlWcxH7w=.9388229b-7cd5-42b7-aaf8-00cdd955278a@github.com>
References: <W1yenf_2rr8sMDSjJcKF-IGZa_mGYSG572YrlWcxH7w=.9388229b-7cd5-42b7-aaf8-00cdd955278a@github.com>
Message-ID: <hGY3Fff20tU2nOV7p2QfzWCFDwfUWW_zKLkUcspzACs=.93ff54f7-dd89-4298-a3d9-0f878f8c679b@github.com>

On Wed, 17 Aug 2022 11:49:28 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> Document update for getBaselineResizeBehavior() and getBaseline() method description in JSpinner, AbstractBorder and TitledBorder .

This pull request has now been integrated.

Changeset: 5652030f
Author:    Abhishek Kumar <abhishek.cx.kumar at oracle.com>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5652030f1684240105fec2fc04aac8fbbe356024
Stats:     6 lines in 3 files changed: 1 ins; 1 del; 4 mod

8292376: A few Swing methods use inheritDoc on exceptions which are not inherited

Reviewed-by: prr, tr

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

PR: https://git.openjdk.org/jdk/pull/9902


From psadhukhan at openjdk.org  Thu Sep 22 12:23:36 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 22 Sep 2022 12:23:36 GMT
Subject: RFR: 7172359: HTML parser StackOverflowError on invalid HTML: <li>
 tag inside an <option> [v2]
In-Reply-To: <edPACBk6ADLPsapJLTvWRDOYjYN_YgZXPDYn-hDo6Pc=.51f30a46-e66a-49a1-bfbe-9241827d0751@github.com>
References: <edPACBk6ADLPsapJLTvWRDOYjYN_YgZXPDYn-hDo6Pc=.51f30a46-e66a-49a1-bfbe-9241827d0751@github.com>
Message-ID: <14Xsw8yK2ppDcaqcWeWUfTjA-cH86IE1mN30vxdITjg=.a5dcd15c-424a-48fa-b38d-283f20a0fe0c@github.com>

> If there is invalid tag, stack terminates but it still tries to recurse through by calling legalElementContext() which results in StackOverflowError.
> Fix is to return if stack is terminated after endTag is handled.
> 
> All other test/html/parser tests are ok with the fix.

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

  Return only if current tag is not valid in current context

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10279/files
  - new: https://git.openjdk.org/jdk/pull/10279/files/8a7b5bb5..4296729f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10279&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10279&range=00-01

  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10279.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10279/head:pull/10279

PR: https://git.openjdk.org/jdk/pull/10279


From duke at openjdk.org  Thu Sep 22 12:56:28 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 22 Sep 2022 12:56:28 GMT
Subject: RFR: 6777156: GTK JFileChooser can show /../../../.. in combobox and
 selection textarea
Message-ID: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>

When a user selects ../ from directory list in GTK FileChooser continuosly, it leads to '../../../.....' in combobox and selection textarea even though it the current directory is at root level.

Fix for the issue is to check if current directory is root then don't process the selection of ' ../ '.

Test case has been added and checked in CI pipeline. Link is attached in JBS.

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

Commit messages:
 - JFileChooser combobox and selection textarea displayed directory list fix

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

PR: https://git.openjdk.org/jdk/pull/10390


From duke at openjdk.org  Thu Sep 22 15:21:14 2022
From: duke at openjdk.org (SWinxy)
Date: Thu, 22 Sep 2022 15:21:14 GMT
Subject: RFR: 8293478: [java.desktop/macOS] Condense SDRenderType usages in
 QuartzRenderer.m [v2]
In-Reply-To: <5D4kwT0_P1FqA37WkR02ETZmfBBPRVSjRHrNrp_TpVM=.71142c60-22e7-487f-8b77-d30820d5b957@github.com>
References: <levplAHOHGYRedb1qypkWNb4hcv6W0rO6vF2wbfbf7M=.79250f01-b07e-41e6-b1d3-166ffde6bd76@github.com>
 <5D4kwT0_P1FqA37WkR02ETZmfBBPRVSjRHrNrp_TpVM=.71142c60-22e7-487f-8b77-d30820d5b957@github.com>
Message-ID: <MMHW2zV3ZQDO8DwKL6N8cwFBDqLht8i-95qlmCitAFU=.cf7cd2eb-5650-4a16-9f95-22dae6836f90@github.com>

On Thu, 8 Sep 2022 05:23:40 GMT, SWinxy <duke at openjdk.org> wrote:

>> The `SDRenderType` enum is often returned using a variable declared at the start of functions. These can be inlined in the `return` itself. Using a ternary operator condenses what may be 12 lines into one, in the most extreme cases. `doRectUsingCG` and `doPolyUsingCG` were both modified more than the rest, but are still basically the same.
>> 
>> Example change:
>> 
>> SDRenderType renderType = SD_Nothing;
>> 
>> if (fill == YES)
>> {
>>     renderType = SD_Fill;
>> }
>> else
>> {
>>     renderType = SD_Stroke;
>> }
>> 
>> // ...
>> 
>> return renderType;
>> 
>> 
>> 
>> // ...
>> 
>> return fill ? SD_Fill : SD_Stroke;
>
> SWinxy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   We can do this here, too

Hi mailing list, would anyone kindly review this patch?

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

PR: https://git.openjdk.org/jdk/pull/10174


From aivanov at openjdk.org  Thu Sep 22 16:58:39 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Sep 2022 16:58:39 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <uFQfE9tIok8RZQgHeC5lfNaifh1V1-Sb-QFEJqfzXVc=.eae5e99b-e369-439b-aae3-b83ad0edc407@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
 <uFQfE9tIok8RZQgHeC5lfNaifh1V1-Sb-QFEJqfzXVc=.eae5e99b-e369-439b-aae3-b83ad0edc407@github.com>
Message-ID: <j3snodAghZ9TmSwS53ZE_IuOYzIEe77oN9NVqn5EhM0=.d9c9b001-2bc1-4c13-b26b-6faf798620a8@github.com>

On Thu, 22 Sep 2022 01:29:24 GMT, SWinxy <duke at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:
>> 
>>  - Merge branch 'master' into typos-in-java.desktop
>>  - Revert changes to glext.h
>>  - Revert changes to multiVis.c and wsutils.h
>>  - Merge branch 'master' into typos-in-java.desktop
>>  - Revert changes in libjpeg
>>  - Revert changes in libfreetype
>>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - ... and 39 more: https://git.openjdk.org/jdk/compare/cddd6def...2850610d
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTheme.java line 68:
> 
>> 66: public abstract class MetalTheme {
>> 67: 
>> 68:     // Constants identifying the various Fonts that a Theme can support
> 
> I think this is possibly meant to say "constants that *our* theme can support"?

Please submit a new JBS issue for it if you can; if you can't, I can submit one on your behalf.

Possibly it meant to say ?_the_ theme?.

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

PR: https://git.openjdk.org/jdk/pull/8328


From aivanov at openjdk.org  Thu Sep 22 17:03:27 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Sep 2022 17:03:27 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <uXWf5UhTZR3rpC8bxMwwQmCk_y0a6wzG-Qfvsmoj1yY=.79628968-cbf7-4c0e-b306-bb12255b9db2@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
 <uXWf5UhTZR3rpC8bxMwwQmCk_y0a6wzG-Qfvsmoj1yY=.79628968-cbf7-4c0e-b306-bb12255b9db2@github.com>
Message-ID: <Vb6DqcHNIW7gZmG99lqihiljl33VF7wSpRGirO_-qhg=.a8758631-18f6-4a92-8ca1-fde626a223e5@github.com>

On Thu, 22 Sep 2022 01:35:49 GMT, SWinxy <duke at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:
>> 
>>  - Merge branch 'master' into typos-in-java.desktop
>>  - Revert changes to glext.h
>>  - Revert changes to multiVis.c and wsutils.h
>>  - Merge branch 'master' into typos-in-java.desktop
>>  - Revert changes in libjpeg
>>  - Revert changes in libfreetype
>>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - ... and 39 more: https://git.openjdk.org/jdk/compare/cddd6def...2850610d
>
> src/java.desktop/share/classes/sun/awt/SunToolkit.java line 1434:
> 
>> 1432: 
>> 1433:     /**
>> 1434:      * Parameterless version of realsync which uses default timeout (see DEFAULT_WAIT_TIME).
> 
> Suggestion:
> 
>      * Parameterless version of realsync which uses the {@link #DEFAULT_WAIT_TIME default timeout}.
> 
> I mean this suggestion [might not be warranted](https://github.com/openjdk/jdk/pull/8328/files#r872596373).

I'm for a clearer message:

Parameterless version of `{@code realsSync}` which uses _the_ default timeout of `{@link #DEFAULT_WAIT_TIME}`.

Let us address this in a separate issue.

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

PR: https://git.openjdk.org/jdk/pull/8328


From duke at openjdk.org  Thu Sep 22 17:23:29 2022
From: duke at openjdk.org (SWinxy)
Date: Thu, 22 Sep 2022 17:23:29 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <j3snodAghZ9TmSwS53ZE_IuOYzIEe77oN9NVqn5EhM0=.d9c9b001-2bc1-4c13-b26b-6faf798620a8@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
 <uFQfE9tIok8RZQgHeC5lfNaifh1V1-Sb-QFEJqfzXVc=.eae5e99b-e369-439b-aae3-b83ad0edc407@github.com>
 <j3snodAghZ9TmSwS53ZE_IuOYzIEe77oN9NVqn5EhM0=.d9c9b001-2bc1-4c13-b26b-6faf798620a8@github.com>
Message-ID: <eHfGEaNx7mjF70YMaihZ2p1fzX7fPvonO2vUmKaGaWM=.53be37da-e844-4908-9b02-0d2e874a0fae@github.com>

On Thu, 22 Sep 2022 16:54:39 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTheme.java line 68:
>> 
>>> 66: public abstract class MetalTheme {
>>> 67: 
>>> 68:     // Constants identifying the various Fonts that a Theme can support
>> 
>> I think this is possibly meant to say "constants that *our* theme can support"?
>
> Please submit a new JBS issue for it if you can; if you can't, I can submit one on your behalf.
> 
> Possibly it meant to say ?_the_ theme?.

I unfortunately don't have a JBS (yet..), so if you could, that would be amazing.

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

PR: https://git.openjdk.org/jdk/pull/8328


From aivanov at openjdk.org  Thu Sep 22 17:29:43 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Sep 2022 17:29:43 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v4]
In-Reply-To: <kCzHnECHQqkjWksA-W2MrYWheE7WPjgFk8oziVgtDPU=.3f93daaf-315a-4140-a866-354ceddc5ca4@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <kCzHnECHQqkjWksA-W2MrYWheE7WPjgFk8oziVgtDPU=.3f93daaf-315a-4140-a866-354ceddc5ca4@github.com>
Message-ID: <CO5Yn_o9ReptxG5aNoTGATJK8i3Tf1JCgahRD6h29js=.ed48e3a0-c494-454c-9305-0c284d09572e@github.com>

On Mon, 19 Sep 2022 23:24:45 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
>> 
>> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
>> 
>> The test is generic though the issue and fix is on Windows platform because the condition 
>> `frame.getSize() == frame.getPreferredSize()` should be true on all platforms when frame.pack() is called.
>> 
>> Following is the link to Windows System Metrics (used for native insets) - https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted the changes related to previous fix - checking the type of target object

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1411:

> 1409: 
> 1410:     if (m_insets.left < 0 || m_insets.top < 0 ||
> 1411:         m_insets.right < 0 || m_insets.bottom < 0) {

No strong opinion here, yet I'd rather leave these lines unchanged. Having the opening brace on its own line avoids the confusion between the condition and the code in the body; on the other hand, it starts with a comment which visually separates the condition from the code inside the if-block.

src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1419:

> 1417:                 ::GetSystemMetrics(SM_CXSIZEFRAME) + extraPaddedBorderInsets;
> 1418:             m_insets.top = m_insets.bottom =
> 1419:                 ::GetSystemMetrics(SM_CYSIZEFRAME) + extraPaddedBorderInsets;

Is it worth adding a comment clarifying why the style isn't checked? Maybe not, since now it's gone from the code. On the other hand, a reader may wonder why we always uses the sizing frame insets even for non-resizeable frames.

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

PR: https://git.openjdk.org/jdk/pull/9954


From tr at openjdk.org  Thu Sep 22 17:29:43 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 22 Sep 2022 17:29:43 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v4]
In-Reply-To: <kCzHnECHQqkjWksA-W2MrYWheE7WPjgFk8oziVgtDPU=.3f93daaf-315a-4140-a866-354ceddc5ca4@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <kCzHnECHQqkjWksA-W2MrYWheE7WPjgFk8oziVgtDPU=.3f93daaf-315a-4140-a866-354ceddc5ca4@github.com>
Message-ID: <GPladDdPlW0tDRY52Zb9ziiJPIvjCVxJFemkxdYRmPg=.af509aee-8849-4bd3-8b3e-ca3265bd3c9f@github.com>

On Mon, 19 Sep 2022 23:24:45 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
>> 
>> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
>> 
>> The test is generic though the issue and fix is on Windows platform because the condition 
>> `frame.getSize() == frame.getPreferredSize()` should be true on all platforms when frame.pack() is called.
>> 
>> Following is the link to Windows System Metrics (used for native insets) - https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted the changes related to previous fix - checking the type of target object

Marked as reviewed by tr (Author).

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

PR: https://git.openjdk.org/jdk/pull/9954


From honkar at openjdk.org  Thu Sep 22 17:38:25 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 22 Sep 2022 17:38:25 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v4]
In-Reply-To: <CO5Yn_o9ReptxG5aNoTGATJK8i3Tf1JCgahRD6h29js=.ed48e3a0-c494-454c-9305-0c284d09572e@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <kCzHnECHQqkjWksA-W2MrYWheE7WPjgFk8oziVgtDPU=.3f93daaf-315a-4140-a866-354ceddc5ca4@github.com>
 <CO5Yn_o9ReptxG5aNoTGATJK8i3Tf1JCgahRD6h29js=.ed48e3a0-c494-454c-9305-0c284d09572e@github.com>
Message-ID: <zcQ74if8xMitH2GgM7IrMvZ5HmCDp1Oz6k4wN2UAufc=.0bee6db5-721e-423c-84bc-507a0a90ca32@github.com>

On Thu, 22 Sep 2022 17:09:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reverted the changes related to previous fix - checking the type of target object
>
> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1419:
> 
>> 1417:                 ::GetSystemMetrics(SM_CXSIZEFRAME) + extraPaddedBorderInsets;
>> 1418:             m_insets.top = m_insets.bottom =
>> 1419:                 ::GetSystemMetrics(SM_CYSIZEFRAME) + extraPaddedBorderInsets;
> 
> Is it worth adding a comment clarifying why the style isn't checked? Maybe not, since now it's gone from the code. On the other hand, a reader may wonder why we always uses the sizing frame insets even for non-resizeable frames.

@aivanov-jdk I agree, comment would add more clarity. Additionally instead of using **SM_CXSIZEFRAME** (the name can be ambiguous too) can we change it to **SM_CXFRAME** ? Since both are mentioned to be same metrics in the documentation https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics

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

PR: https://git.openjdk.org/jdk/pull/9954


From aivanov at openjdk.org  Thu Sep 22 17:43:23 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Sep 2022 17:43:23 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v4]
In-Reply-To: <zcQ74if8xMitH2GgM7IrMvZ5HmCDp1Oz6k4wN2UAufc=.0bee6db5-721e-423c-84bc-507a0a90ca32@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <kCzHnECHQqkjWksA-W2MrYWheE7WPjgFk8oziVgtDPU=.3f93daaf-315a-4140-a866-354ceddc5ca4@github.com>
 <CO5Yn_o9ReptxG5aNoTGATJK8i3Tf1JCgahRD6h29js=.ed48e3a0-c494-454c-9305-0c284d09572e@github.com>
 <zcQ74if8xMitH2GgM7IrMvZ5HmCDp1Oz6k4wN2UAufc=.0bee6db5-721e-423c-84bc-507a0a90ca32@github.com>
Message-ID: <AHc0wchxI3o-Oe9UQVTgAhQpdtNEJOZhPnEddqJz9UU=.d2621500-d336-4931-af71-02af4f5e6f78@github.com>

On Thu, 22 Sep 2022 17:34:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Additionally instead of using **SM_CXSIZEFRAME** (the name can be ambiguous too) can we change it to **SM_CXFRAME** ?

Yes, `SM_CXFRAME` is neutral, it doesn't refer to either resizeable or non-resizeable frame.

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

PR: https://git.openjdk.org/jdk/pull/9954


From honkar at openjdk.org  Thu Sep 22 18:42:50 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 22 Sep 2022 18:42:50 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v5]
In-Reply-To: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
Message-ID: <UZ-mVjc51DuyTiFnpmQPMfeS7WdPtQItEtkJQvLfFa8=.a9bec4e1-01b0-4f56-bcdd-db15645f682d@github.com>

> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
> 
> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
> 
> The test is generic though the issue and fix is on Windows platform because the condition 
> `frame.getSize() == frame.getPreferredSize()` should be true on all platforms when frame.pack() is called.
> 
> Following is the link to Windows System Metrics (used for native insets) - https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics

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

 - Merge branch 'master' into NonResize_8288325
 - reverted the changes related to previous fix - checking the type of target object
 - updated fix to get the right insets for Non-Resizable frame
 - Merge branch 'master' into NonResize_8288325
 - Non-Resizable AWT Frame insets fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9954/files
  - new: https://git.openjdk.org/jdk/pull/9954/files/72272055..1333b824

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9954&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9954&range=03-04

  Stats: 9937 lines in 248 files changed: 5608 ins; 3559 del; 770 mod
  Patch: https://git.openjdk.org/jdk/pull/9954.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9954/head:pull/9954

PR: https://git.openjdk.org/jdk/pull/9954


From honkar at openjdk.org  Thu Sep 22 19:17:21 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 22 Sep 2022 19:17:21 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
In-Reply-To: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
References: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
Message-ID: <eyoTId42r1xHmZOGk66wVvNNEdzp1pVhu_nToShIBbQ=.857d3f89-7619-4856-a9df-eb77e880bf57@github.com>

On Thu, 22 Sep 2022 06:59:59 GMT, Tejesh R <tr at openjdk.org> wrote:

> The color returned for `InteriorBackground` property is the default color used for only _WindowsClassicLookAndFeel_. For _WindowsLookAndFeel_ the `InteriorBackground` color is not been used when checkbox paint happens. In _WindowsLookAndFeel_ the CheckBox check/uncheck is drawn using `ImageCache` which is totally independent of `InteriorBackground` color in which the user expects it to be.
> The proposed fix is to return null for _WindowsLookAndFeel_ (which is what happens in other LookAndFeel like Metal/Synth/Motif/Aqua ) and return default color which is the actual color used in _WindowsClassicLookAndFeel_.

test/jdk/javax/swing/JCheckBox/InteriorBackgroundTest.java line 33:

> 31:  * @test
> 32:  * @bug 8289539
> 33:  * @key headful

Is this test marked headful to load system colors associated with the LAF? 
Since we are not displaying anything on screen.

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

PR: https://git.openjdk.org/jdk/pull/10385


From honkar at openjdk.org  Thu Sep 22 19:24:25 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 22 Sep 2022 19:24:25 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v6]
In-Reply-To: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
Message-ID: <7bDtDszTHQm2GWAXvgOVi7E0-ddJb-jaCofbmhshYJQ=.f2aa6a46-6665-4c00-b60d-9a4e35c99537@github.com>

> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
> 
> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
> 
> The test is generic though the issue and fix is on Windows platform because the condition 
> `frame.getSize() == frame.getPreferredSize()` should be true on all platforms when frame.pack() is called.
> 
> Following is the link to Windows System Metrics (used for native insets) - https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics

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

  added comments, changed system metric

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9954/files
  - new: https://git.openjdk.org/jdk/pull/9954/files/1333b824..4d3e1c24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9954&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9954&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/9954


From aivanov at openjdk.org  Thu Sep 22 19:54:30 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Sep 2022 19:54:30 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v6]
In-Reply-To: <7bDtDszTHQm2GWAXvgOVi7E0-ddJb-jaCofbmhshYJQ=.f2aa6a46-6665-4c00-b60d-9a4e35c99537@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <7bDtDszTHQm2GWAXvgOVi7E0-ddJb-jaCofbmhshYJQ=.f2aa6a46-6665-4c00-b60d-9a4e35c99537@github.com>
Message-ID: <Ck8eHtn2gLqz5-gJ54LbX31j-Xpa4O9naM5MG9QhCDI=.bc9e36af-16a7-496a-9811-661e2c605a85@github.com>

On Thu, 22 Sep 2022 19:24:25 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
>> 
>> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
>> 
>> The test is generic though the issue and fix is on Windows platform because the condition 
>> `frame.getSize() == frame.getPreferredSize()` should be true on all platforms when frame.pack() is called.
>> 
>> Following is the link to Windows System Metrics (used for native insets) - https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comments, changed system metric

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1419:

> 1417:             // System metrics are same for resizable & non-resizable frame.
> 1418:             // SM_CXFRAME is the width of the horizontal border in pixels.
> 1419:             // SM_CYFRAME is the height of the vertical border in pixels.

I guess the meaning of `CX/CYFRAME` is quite obvious.

The first sentence about the metrics being the same is helpful.

src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1482:

> 1480:         env->CallVoidMethod(peer, AwtComponent::replaceSurfaceDataLaterMID);
> 1481:     }
> 1482: 

Probably, this line could remain.

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

PR: https://git.openjdk.org/jdk/pull/9954


From aivanov at openjdk.org  Thu Sep 22 20:07:23 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Sep 2022 20:07:23 GMT
Subject: RFR: 8292328 : AccessibleActionsTest.java test instruction for
 show popup on JLabel did not specify shift key
In-Reply-To: <PRgGYMbpY_r_y1Rb7qpIn7ffmOZiqisA5i1QBuwFFHY=.3df5c35c-bcb8-4eba-be25-23e13db36f99@github.com>
References: <PRgGYMbpY_r_y1Rb7qpIn7ffmOZiqisA5i1QBuwFFHY=.3df5c35c-bcb8-4eba-be25-23e13db36f99@github.com>
Message-ID: <zbmCYyK63cnTusm_jq-HTqp4MxT-zhGphTdgEk-p8Xs=.d12b8679-12e3-4aa0-813f-4d41f0313514@github.com>

On Sat, 13 Aug 2022 22:44:52 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> Corrected the test instruction to show the popup menu on JLabel when voice over is enabled .
> 
> @shurymury

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9868


From honkar at openjdk.org  Thu Sep 22 20:16:41 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 22 Sep 2022 20:16:41 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v7]
In-Reply-To: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
Message-ID: <wWOOvAVIp6H3JO_1WrwVfOMZ_sJ7NwwV8dpsDkCIwMI=.6350b068-ea09-433d-b5dd-5b0865572e6f@github.com>

> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
> 
> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
> 
> The test is generic though the issue and fix is on Windows platform because the condition 
> `frame.getSize() == frame.getPreferredSize()` should be true on all platforms when frame.pack() is called.
> 
> Following is the link to Windows System Metrics (used for native insets) - https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics

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

  minor changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9954/files
  - new: https://git.openjdk.org/jdk/pull/9954/files/4d3e1c24..b6f90abb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9954&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9954&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/9954


From duke at openjdk.org  Thu Sep 22 20:19:03 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Thu, 22 Sep 2022 20:19:03 GMT
Subject: Integrated: 8292328 : AccessibleActionsTest.java test instruction for
 show popup on JLabel did not specify shift key
In-Reply-To: <PRgGYMbpY_r_y1Rb7qpIn7ffmOZiqisA5i1QBuwFFHY=.3df5c35c-bcb8-4eba-be25-23e13db36f99@github.com>
References: <PRgGYMbpY_r_y1Rb7qpIn7ffmOZiqisA5i1QBuwFFHY=.3df5c35c-bcb8-4eba-be25-23e13db36f99@github.com>
Message-ID: <j9Bml4bkqTgKJ_x2MtxUamaQ0QHZQPwX3yn7Zlpj1Bw=.59372a81-d763-48cc-954b-f07a42254eae@github.com>

On Sat, 13 Aug 2022 22:44:52 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> Corrected the test instruction to show the popup menu on JLabel when voice over is enabled .
> 
> @shurymury

This pull request has now been integrated.

Changeset: df53fa75
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df53fa752a81a88b9495978cccb3d7b9f5ed553c
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8292328: AccessibleActionsTest.java test instruction for show popup on JLabel did not specify shift key

Reviewed-by: serb, aivanov

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

PR: https://git.openjdk.org/jdk/pull/9868


From aivanov at openjdk.org  Thu Sep 22 20:22:47 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Sep 2022 20:22:47 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <eHfGEaNx7mjF70YMaihZ2p1fzX7fPvonO2vUmKaGaWM=.53be37da-e844-4908-9b02-0d2e874a0fae@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
 <uFQfE9tIok8RZQgHeC5lfNaifh1V1-Sb-QFEJqfzXVc=.eae5e99b-e369-439b-aae3-b83ad0edc407@github.com>
 <j3snodAghZ9TmSwS53ZE_IuOYzIEe77oN9NVqn5EhM0=.d9c9b001-2bc1-4c13-b26b-6faf798620a8@github.com>
 <eHfGEaNx7mjF70YMaihZ2p1fzX7fPvonO2vUmKaGaWM=.53be37da-e844-4908-9b02-0d2e874a0fae@github.com>
Message-ID: <roNZDEigW_m6kd7yVsQMbEcJaqRMAxOLbppVAiC1gOo=.000515f2-0771-4b10-a59d-80146998bc50@github.com>

On Thu, 22 Sep 2022 17:21:05 GMT, SWinxy <duke at openjdk.org> wrote:

>> Please submit a new JBS issue for it if you can; if you can't, I can submit one on your behalf.
>> 
>> Possibly it meant to say ?_the_ theme?.
>
> I unfortunately don't have a JBS (yet..), so if you could, that would be amazing.

I think the text is correct here: ?that _**a** Theme_ can support

`MetalTheme` is a superclass for classes which implement Themes. Thus the constants define fonts which _a particular theme_ may use.

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

PR: https://git.openjdk.org/jdk/pull/8328


From aivanov at openjdk.org  Thu Sep 22 20:22:48 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Sep 2022 20:22:48 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <Vb6DqcHNIW7gZmG99lqihiljl33VF7wSpRGirO_-qhg=.a8758631-18f6-4a92-8ca1-fde626a223e5@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
 <uXWf5UhTZR3rpC8bxMwwQmCk_y0a6wzG-Qfvsmoj1yY=.79628968-cbf7-4c0e-b306-bb12255b9db2@github.com>
 <Vb6DqcHNIW7gZmG99lqihiljl33VF7wSpRGirO_-qhg=.a8758631-18f6-4a92-8ca1-fde626a223e5@github.com>
Message-ID: <8wgnrs5UNZfQxgyoSNxQzjszOCUTxDZY2TGXXUs-1W0=.9ce61a4c-9375-4c80-a4f2-645d7972c96c@github.com>

On Thu, 22 Sep 2022 16:59:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/awt/SunToolkit.java line 1434:
>> 
>>> 1432: 
>>> 1433:     /**
>>> 1434:      * Parameterless version of realsync which uses default timeout (see DEFAULT_WAIT_TIME).
>> 
>> Suggestion:
>> 
>>      * Parameterless version of realsync which uses the {@link #DEFAULT_WAIT_TIME default timeout}.
>> 
>> I mean this suggestion [might not be warranted](https://github.com/openjdk/jdk/pull/8328/files#r872596373).
>
> I'm for a clearer message:
> 
> Parameterless version of `{@code realsSync}` which uses _the_ default timeout of `{@link #DEFAULT_WAIT_TIME}`.
> 
> Let us address this in a separate issue.

[JDK-8294255](https://bugs.openjdk.org/browse/JDK-8294255): Add link to DEFAULT_WAIT_TIME in javadoc for SunToolKit.realsSync

Feel free to provide a patch.

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

PR: https://git.openjdk.org/jdk/pull/8328


From aivanov at openjdk.org  Thu Sep 22 20:28:23 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Sep 2022 20:28:23 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v7]
In-Reply-To: <wWOOvAVIp6H3JO_1WrwVfOMZ_sJ7NwwV8dpsDkCIwMI=.6350b068-ea09-433d-b5dd-5b0865572e6f@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <wWOOvAVIp6H3JO_1WrwVfOMZ_sJ7NwwV8dpsDkCIwMI=.6350b068-ea09-433d-b5dd-5b0865572e6f@github.com>
Message-ID: <O3EqFj5SZm0ozlLbtFim49Vvnh8bdSYGVJ3WT8xXwaU=.f500fe27-cf00-452d-aee6-26804c6cb056@github.com>

On Thu, 22 Sep 2022 20:16:41 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
>> 
>> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
>> 
>> The test is generic though the issue and fix is on Windows platform because the condition 
>> `frame.getSize() == frame.getPreferredSize()` should be true on all platforms when frame.pack() is called.
>> 
>> Following is the link to Windows System Metrics (used for native insets) - https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor changes

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9954


From honkar at openjdk.org  Thu Sep 22 20:58:16 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 22 Sep 2022 20:58:16 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v8]
In-Reply-To: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
Message-ID: <425yPx1GVY2rQOavjF3lB4k4hz4J0Wju6JgOOIXZ7yM=.440b6cef-8434-49f5-86c3-fe31da8813b9@github.com>

> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
> 
> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
> 
> The test is generic though the issue and fix is on Windows platform because the condition 
> `frame.getSize() == frame.getPreferredSize()` should be true on all platforms when frame.pack() is called.
> 
> Following is the link to Windows System Metrics (used for native insets) - https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics

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

  removed unused extraBottomInsets, code cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9954/files
  - new: https://git.openjdk.org/jdk/pull/9954/files/b6f90abb..edcb53a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9954&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9954&range=06-07

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

PR: https://git.openjdk.org/jdk/pull/9954


From duke at openjdk.org  Fri Sep 23 03:14:34 2022
From: duke at openjdk.org (ScientificWare)
Date: Fri, 23 Sep 2022 03:14:34 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v8]
In-Reply-To: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
Message-ID: <1_r5hUo5IsGP0pNCrqr4c0vLvR55LRh9r3X1syhVxvw=.3d52522f-4fbd-48f3-9348-3c529313d5c7@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
> 
> This is tracked in JBS as 
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
> 
> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
> 
> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)

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

  Renames an identifier.
  
  Suggested change, not to use `l` as an identifier because it could be confused with `1`.
  This part of code could change and be replaced by bits right rotation after  performance tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10317/files
  - new: https://git.openjdk.org/jdk/pull/10317/files/478f285e..767c87ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=06-07

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

PR: https://git.openjdk.org/jdk/pull/10317


From duke at openjdk.org  Fri Sep 23 03:35:21 2022
From: duke at openjdk.org (ScientificWare)
Date: Fri, 23 Sep 2022 03:35:21 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v6]
In-Reply-To: <DmaK20O4iPQJGHZyci3IQEsFFbdhnBgMmB4Aok-GE9g=.4884358d-108b-4115-a948-180727268137@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <592sDW2VIvByGwKDoAYG5P7a4Iygc5CYtPVG7vr9qrk=.12f3db5e-a3a7-41c6-b5f9-e1588507bbe2@github.com>
 <DmaK20O4iPQJGHZyci3IQEsFFbdhnBgMmB4Aok-GE9g=.4884358d-108b-4115-a948-180727268137@github.com>
Message-ID: <qNrVXI_sLUl_nLStcratdK-OUhBax_v9z2vm7tMDTGs=.7d8763f5-0985-4015-bb29-06b89d44593c@github.com>

On Mon, 19 Sep 2022 16:41:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Corrects typos and digit extraction.
>>   
>>   Corrects typos.
>>   And applies a better digit extraction as suggested in main-line review thread.
>
> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1399:
> 
>> 1397:             final char b = digits.charAt(2);
>> 1398:             final char a = digits.charAt(3);
>> 1399:             digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$s%4$s%4$s", r, g, b, a);
> 
> Does it make sense to combine these two cases into one?
> 
> Suggestion:
> 
>         if (n == 3 || n == 4) {
>             final char r = digits.charAt(0);
>             final char g = digits.charAt(1);
>             final char b = digits.charAt(2);
>             final char a = n == 4 ? digits.charAt(3) : 'f';
>             digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$s%4$s%4$s", r, g, b, a);
> 
> 
> The only difference between these two case is in `a` which is hard-coded as `ff` in the format string for `n == 3`.

With this change, the code is more concise but we double the number of tests ?

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

PR: https://git.openjdk.org/jdk/pull/10317


From duke at openjdk.org  Fri Sep 23 04:10:06 2022
From: duke at openjdk.org (ScientificWare)
Date: Fri, 23 Sep 2022 04:10:06 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v6]
In-Reply-To: <DmaK20O4iPQJGHZyci3IQEsFFbdhnBgMmB4Aok-GE9g=.4884358d-108b-4115-a948-180727268137@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <592sDW2VIvByGwKDoAYG5P7a4Iygc5CYtPVG7vr9qrk=.12f3db5e-a3a7-41c6-b5f9-e1588507bbe2@github.com>
 <DmaK20O4iPQJGHZyci3IQEsFFbdhnBgMmB4Aok-GE9g=.4884358d-108b-4115-a948-180727268137@github.com>
Message-ID: <EG1YwvCYVMB2ltYk0h6-c_y6ZycpV14mztbtvC06y4o=.9acaa22f-95ec-4f85-9f66-2f0f7c2c1ecb@github.com>

On Mon, 19 Sep 2022 18:10:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Corrects typos and digit extraction.
>>   
>>   Corrects typos.
>>   And applies a better digit extraction as suggested in main-line review thread.
>
> test/jdk/javax/swing/text/html/CSS/Hex3468DigitsColor.java line 71:
> 
>> 69:         alpha = color.getAlpha();
>> 70:         result.append("\n  Test for #ff1122aa");
>> 71:         if (red != 255) {
> 
> `red`, `green` and `blue` haven't changed here. You may want to get them from the `color` object.
> 
> Alternatively, you can compare the RGB:
> 
> if (0xaaff1122 != color.getRGB()) {
>     // fail the test
> }

I'm going to work on rgb() and rgba() notations (https://bugs.openjdk.org/browse/JDK-8294090). Could we let this unchanged or differ this change ?

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

PR: https://git.openjdk.org/jdk/pull/10317


From alanb at openjdk.org  Fri Sep 23 07:59:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 Sep 2022 07:59:16 GMT
Subject: Integrated: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <rApjpOiHjrtsAtbAXYhxuyOB3uAhSHS58h8VmrVi7BA=.53a55061-ea0c-4b9d-b57b-b72b34e0a0bd@github.com>

On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
> 
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
> 
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
> 
> The change here has no  impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.

This pull request has now been integrated.

Changeset: acd5bcfc
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/acd5bcfc8897908d82e9008ee2def9476f046a4d
Stats:     341 lines in 26 files changed: 115 ins; 162 del; 64 mod

8289610: Degrade Thread.stop

Reviewed-by: rriggs, cjplummer, jpai, mchung, prr, mullan

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

PR: https://git.openjdk.org/jdk/pull/10230


From duke at openjdk.org  Fri Sep 23 08:58:16 2022
From: duke at openjdk.org (SWinxy)
Date: Fri, 23 Sep 2022 08:58:16 GMT
Subject: RFR: 8294255: Add link to DEFAULT_WAIT_TIME in javadoc for
 SunToolKit.realsSync
Message-ID: <5IKSHb5lsL9So0XoN2YDv7GhGjL0j_gi9FWtpZ0IykE=.f315a62e-1d87-4ed5-a6a7-f86d6db34b7f@github.com>

I also took the opportunity to link to `realSync(long)`.

/**
  * Parameterless version of realsync which uses default timout (see DEFAUL_WAIT_TIME).
  */


/**
  * Parameterless version of {@link #realSync(long)} which uses
  * the default timeout of {@link #DEFAULT_WAIT_TIME}.
  */

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

Commit messages:
 - 8294255: Add link to DEFAULT_WAIT_TIME in javadoc for SunToolKit.realsSync

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

PR: https://git.openjdk.org/jdk/pull/10399


From dholmes at openjdk.org  Fri Sep 23 08:58:42 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Sep 2022 08:58:42 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup
Message-ID: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>

Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).

Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.

Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).

Testing: tiers 1-3

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

Commit messages:
 - Removal all special handling of ThreadDeath.
 - Remove all references to the stillborn field
 - Initial commit: remove JVM_StopThread
 - Merge
 - Updates to Java Thread Primitive Deprecation page
 - Repalce "it" with "victim thread"
 - Merge
 - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
 - become -> became in javadoc
 - Merge
 - ... and 5 more: https://git.openjdk.org/jdk/compare/01e7b881...58bfb313

Changes: https://git.openjdk.org/jdk/pull/10400/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10400&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293592
  Stats: 549 lines in 43 files changed: 134 ins; 308 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/10400.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10400/head:pull/10400

PR: https://git.openjdk.org/jdk/pull/10400


From alanb at openjdk.org  Fri Sep 23 11:12:24 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 Sep 2022 11:12:24 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup
In-Reply-To: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
Message-ID: <Bfq-Tx0S9oPszwvfoUkCtVd16ARxYp6c8Y1Oe9S1_y4=.1b7e4278-2ba0-455e-9cd8-2d0b27f49d70@github.com>

On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
> 
> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
> 
> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
> 
> Testing: tiers 1-3

(JDK-8289610 is integrated now so once you sync up it should remove the changes from the dependent PR once the list of changed files. You should be able to trim down the labels too.)

I did a pass over the src/hotspot change and didn't spot any issues. It's good that stillborn can go away. The removal of the special-casing of ThreadDeath is consistent with the libs side of the change, including the change to ExceptionDescribe.

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

PR: https://git.openjdk.org/jdk/pull/10400


From tr at openjdk.org  Fri Sep 23 11:18:22 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 23 Sep 2022 11:18:22 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser shouldn't display /../../../..
 in combobox and selection textarea.
In-Reply-To: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
Message-ID: <avWNqZ7QEX_PKBFQedGijjmgZi3KPQZG5z8QOGZqX40=.38191ebe-a37f-455c-b911-8c5933e96dae@github.com>

On Thu, 22 Sep 2022 12:48:14 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> When a user selects ../ from directory list in GTK FileChooser continuosly, it leads to '../../../.....' in combobox and selection textarea even though it the current directory is at root level.
> 
> Fix for the issue is to check if current directory is root then don't process the selection of ' ../ '.
> 
> Test case has been added and checked in CI pipeline. Link is attached in JBS.

src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java line 436:

> 434:                 int index = list.locationToIndex(e.getPoint());
> 435:                 File currentDirectory = getFileChooser().getCurrentDirectory();
> 436:                 if (currentDirectory.getParentFile() == null && index == 1) {

Adding a Comment explaining the statement `index == 1` would be better to understand that it signifies root directory index.

test/jdk/javax/swing/JFileChooser/TestFileChooserDirectorySelection.java line 71:

> 69:                     passed = true;
> 70:                     break;
> 71:                 } else if (++i > 5) {

Retries will be 4 right......? Since you are starting with 2 till 5......?

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

PR: https://git.openjdk.org/jdk/pull/10390


From tr at openjdk.org  Fri Sep 23 11:27:18 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 23 Sep 2022 11:27:18 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser shouldn't display /../../../..
 in combobox and selection textarea.
In-Reply-To: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
Message-ID: <4oKkNRdQ4UNy8rElxDwMSFTSpMKxK9yrhdb4YcdFg3g=.1784792d-1c86-46c5-a340-d107222dcd32@github.com>

On Thu, 22 Sep 2022 12:48:14 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> When a user selects ../ from directory list in GTK FileChooser continuosly, it leads to '../../../.....' in combobox and selection textarea even though it the current directory is at root level.
> 
> Fix for the issue is to check if current directory is root then don't process the selection of ' ../ '.
> 
> Test case has been added and checked in CI pipeline. Link is attached in JBS.

Is there any possibility to check for current Directory to be `root` before confirming that the traversal is stopping at root?

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

PR: https://git.openjdk.org/jdk/pull/10390


From psadhukhan at openjdk.org  Fri Sep 23 13:37:14 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 23 Sep 2022 13:37:14 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails
Message-ID: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>

DefaultListSelectionModel.removeIndexInterva accepts `int` value which allows it to take in Integer.MAX_VALUE theoratically but it does calculation with that value which can results in IOOBE.
Fix is to make sure the calculation stays within bounds.

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

Commit messages:
 - Test fix
 - 6187113: DefaultListSelectionModel.removeIndexInterval(0, Integer.MAX_VALUE) fails

Changes: https://git.openjdk.org/jdk/pull/10409/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10409&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6187113
  Stats: 46 lines in 2 files changed: 44 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10409.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10409/head:pull/10409

PR: https://git.openjdk.org/jdk/pull/10409


From aivanov at openjdk.org  Fri Sep 23 16:03:20 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 23 Sep 2022 16:03:20 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different [v8]
In-Reply-To: <425yPx1GVY2rQOavjF3lB4k4hz4J0Wju6JgOOIXZ7yM=.440b6cef-8434-49f5-86c3-fe31da8813b9@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <425yPx1GVY2rQOavjF3lB4k4hz4J0Wju6JgOOIXZ7yM=.440b6cef-8434-49f5-86c3-fe31da8813b9@github.com>
Message-ID: <JisaykIsNs7ci7RUFYXn5jFL8pUPYFXWCrGw_PWPO5w=.dd183741-8e9f-4d5e-9935-de2d698814ac@github.com>

On Thu, 22 Sep 2022 20:58:16 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
>> 
>> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
>> 
>> The test is generic though the issue and fix is on Windows platform because the condition 
>> `frame.getSize() == frame.getPreferredSize()` should be true on all platforms when frame.pack() is called.
>> 
>> Following is the link to Windows System Metrics (used for native insets) - https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unused extraBottomInsets, code cleanup

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9954


From honkar at openjdk.org  Fri Sep 23 16:29:27 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 23 Sep 2022 16:29:27 GMT
Subject: Integrated: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different
In-Reply-To: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
Message-ID: <2H_2H-1ViJuwWOtorlVXbwgzVmYuN_j2DqXTylV1HLo=.8ea25e9e-87e5-4cad-a5a0-cba88a81883b@github.com>

On Fri, 19 Aug 2022 23:47:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
> 
> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
> 
> The test is generic though the issue and fix is on Windows platform because the condition 
> `frame.getSize() == frame.getPreferredSize()` should be true on all platforms when frame.pack() is called.
> 
> Following is the link to Windows System Metrics (used for native insets) - https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics

This pull request has now been integrated.

Changeset: eca9749d
Author:    Harshitha Onkar <honkar at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eca9749da01d732033c07f2bbb38800a9d80f18d
Stats:     56 lines in 2 files changed: 24 ins; 12 del; 20 mod

8288325: [windows] Actual and Preferred Size of AWT Non-resizable frame are different

Reviewed-by: kizune, aivanov, tr

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

PR: https://git.openjdk.org/jdk/pull/9954


From aivanov at openjdk.org  Fri Sep 23 16:52:35 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 23 Sep 2022 16:52:35 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v6]
In-Reply-To: <qNrVXI_sLUl_nLStcratdK-OUhBax_v9z2vm7tMDTGs=.7d8763f5-0985-4015-bb29-06b89d44593c@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <592sDW2VIvByGwKDoAYG5P7a4Iygc5CYtPVG7vr9qrk=.12f3db5e-a3a7-41c6-b5f9-e1588507bbe2@github.com>
 <DmaK20O4iPQJGHZyci3IQEsFFbdhnBgMmB4Aok-GE9g=.4884358d-108b-4115-a948-180727268137@github.com>
 <qNrVXI_sLUl_nLStcratdK-OUhBax_v9z2vm7tMDTGs=.7d8763f5-0985-4015-bb29-06b89d44593c@github.com>
Message-ID: <32gcqBPrkOpDtMLmeh7KGGnXrYf-4VMabEXYPOt0rFY=.8fc58c48-dd7e-4444-9344-7f2ba33bc7a9@github.com>

On Fri, 23 Sep 2022 03:33:06 GMT, ScientificWare <duke at openjdk.org> wrote:

> With this change, the code is more concise but we double the number of tests ?

For a rather rare case. I don't think it's a critical path which affects performance.

If you like, you can create a variable to store the result of `n == 4` to avoid testing once again. I still don't think it's worth it.

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

PR: https://git.openjdk.org/jdk/pull/10317


From aivanov at openjdk.org  Fri Sep 23 17:04:19 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 23 Sep 2022 17:04:19 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v6]
In-Reply-To: <DmaK20O4iPQJGHZyci3IQEsFFbdhnBgMmB4Aok-GE9g=.4884358d-108b-4115-a948-180727268137@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <592sDW2VIvByGwKDoAYG5P7a4Iygc5CYtPVG7vr9qrk=.12f3db5e-a3a7-41c6-b5f9-e1588507bbe2@github.com>
 <DmaK20O4iPQJGHZyci3IQEsFFbdhnBgMmB4Aok-GE9g=.4884358d-108b-4115-a948-180727268137@github.com>
Message-ID: <hcDkUi8E2kOcGCdJ_kCMmOpi4surhe2DmDaFOXnNwGA=.53d454da-4373-4190-9471-dc4fc1aecff7@github.com>

On Mon, 19 Sep 2022 16:36:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Corrects typos and digit extraction.
>>   
>>   Corrects typos.
>>   And applies a better digit extraction as suggested in main-line review thread.
>
> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1366:
> 
>> 1364:             digits = digits.substring(1, Math.min(n, 9));
>> 1365:             n--;
>> 1366:         }
> 
> Should the method return `null` immediately if `n < 3 || n > 8` after the if block at lines 1363-1366? It's already known the format is invalid.
> 
> I also propose adding `hex.matcher(digits).matches()` here to avoid running the matcher at each attempt.
> 
> In short, the next statement should be:
> 
> 
> if (n < 3 || n == 7 || n > 8 || !hex.matcher(digits).matches()) {
>     return null;
> }
> 
> 
> The following code deals with a valid color notation.

> @aivanov-jdk, I suppose that most of color notations are correct.

Likely, otherwise the colors wouldn't show up.

> Adding these tests in first place has a time cost.

The time is rather negligible, in my opinion. Yet the code is clearer.

If you care about micro-optimisations, the `n == 6` case should be the first one in the chain of `if`-blocks as the most common case.

> With `&&`, `hex.matcher(digits).matches()` is evaluated only once. That why I separated length test from hex test.

Yes, you're absolutely right. I agree it is evaluated only once, which wasn't apparent to me from the start. Someone else may also consider it as inefficiency.

> Pattern usage has a significant time cost.

Exactly. Is it even needed? The previous code did well without it.

I'm sure it's not needed, `Integer.parseUnsignedInt` validates the digits are valid, if not, it throws `NumberFormatException`. Since, as you say, it's rare that the color notation is invalid, I see no reason to avoid the exception using the pattern.

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

PR: https://git.openjdk.org/jdk/pull/10317


From aivanov at openjdk.org  Fri Sep 23 17:12:07 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 23 Sep 2022 17:12:07 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v6]
In-Reply-To: <EG1YwvCYVMB2ltYk0h6-c_y6ZycpV14mztbtvC06y4o=.9acaa22f-95ec-4f85-9f66-2f0f7c2c1ecb@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <592sDW2VIvByGwKDoAYG5P7a4Iygc5CYtPVG7vr9qrk=.12f3db5e-a3a7-41c6-b5f9-e1588507bbe2@github.com>
 <DmaK20O4iPQJGHZyci3IQEsFFbdhnBgMmB4Aok-GE9g=.4884358d-108b-4115-a948-180727268137@github.com>
 <EG1YwvCYVMB2ltYk0h6-c_y6ZycpV14mztbtvC06y4o=.9acaa22f-95ec-4f85-9f66-2f0f7c2c1ecb@github.com>
Message-ID: <hYf28fRsZSU5d43Q6CwrqTHSH_QpAdBZOF-caxAK7N8=.c045fb3a-9a0e-4a7f-ad8f-2604ff20f2e4@github.com>

On Fri, 23 Sep 2022 04:06:48 GMT, ScientificWare <duke at openjdk.org> wrote:

> I'm going to work on rgb() and rgba() notations (https://bugs.openjdk.org/browse/JDK-8294090). Could we let this unchanged or differ this change ?

How is this comment related to the `rgb()` and `rgba()` functions?

I think using `color.getRGB()` and comparing the value to a hex-number representing the colour (with the alpha byte moved to the higher byte of the double word) is concise and clear.

My other point was that you still validate the red, green and blue components of the color but you don't read them from the color parsed on line 68. If you don't update `red`, `green` and `blue`, they're not changed, verifying the values for the second time won't catch an error even if `styleSheet.stringToColor` returned a different color.

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

PR: https://git.openjdk.org/jdk/pull/10317


From honkar at openjdk.org  Fri Sep 23 17:42:22 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 23 Sep 2022 17:42:22 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v3]
In-Reply-To: <4VvhgKSAGDnjWdmTfvaNCcTsSmOmCQR8UsYNOSmRO5w=.be1165bd-2d1f-44bc-8027-3ae9923617ce@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
 <4VvhgKSAGDnjWdmTfvaNCcTsSmOmCQR8UsYNOSmRO5w=.be1165bd-2d1f-44bc-8027-3ae9923617ce@github.com>
Message-ID: <hgY9F5FMgdYT4_Wh7zTIAoUFO7UFo9Hy0fHIXd9xwU4=.14dabbb3-abbc-42c1-996d-ba298f1f99ed@github.com>

On Tue, 13 Sep 2022 07:49:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Label.foreground UIProperty is not honored by Nimbus L&F.
>> Added support for setting JLabel foreground color for Nimbus L&F
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get color once during init

Marked as reviewed by honkar (Author).

Updated fix looks good.

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

PR: https://git.openjdk.org/jdk/pull/9900


From cjplummer at openjdk.org  Fri Sep 23 18:31:23 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 23 Sep 2022 18:31:23 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup
In-Reply-To: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
Message-ID: <jPQnZdvskvzHDQZrF45DW8L9zsvSxiQKQHrODS2RAdk=.2fc75db3-f9d0-4bbb-8283-e387481cbc30@github.com>

On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
> 
> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
> 
> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
> 
> Testing: tiers 1-3

src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 102:

> 100:             try {
> 101:                 connector = connectors.next();
> 102:             } catch (Exception | Error x) {

Maybe this should just catch `Throwable`, although it is unclear to me why we would want to catch any exception here.

src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 126:

> 124:             try {
> 125:                 transportService = transportServices.next();
> 126:             } catch (Exception | Error x) {

Another that could be just catch `Throwable`

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

PR: https://git.openjdk.org/jdk/pull/10400


From prr at openjdk.org  Fri Sep 23 19:09:12 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 23 Sep 2022 19:09:12 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create method are contrary to
 the documentation
In-Reply-To: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
Message-ID: <pYuKs-vM1qUaUDVjaCuiOF40D7oTTYBN9ibik3vRH98=.e9dcddd6-da98-44e0-a68a-fd1c7f6ec570@github.com>

On Wed, 21 Sep 2022 12:25:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> API specification says about BasicTextAreaUI.create "Returns a WrappedPlainView or PlainView". 
> But for [bidi](https://github.com/openjdk/jdk/blob/d14e96d9701dae951aa365029f58afb6687a646a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java#L168) text, this method returns BoxView and other views , so the documentation needs to be updated.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java line 143:

> 141:      * PlainView if non-bidi text is handled
> 142:      * else returns PlainParagraph or BoxView if bidi text is being handled.
> 143:      *

So .. what if the text wasn't bidi but then some one adds bidi text ?

And can we change the summary of the BUG and PR to something grammatically correct, and perhaps even
descriptive such as
"BasicTextAreaUI:create incompletely documents the possible returned View types"

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

PR: https://git.openjdk.org/jdk/pull/10376


From dholmes at openjdk.org  Fri Sep 23 21:47:06 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Sep 2022 21:47:06 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup [v2]
In-Reply-To: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
Message-ID: <BlMK7IMjTgIiiwSkkF_1-qLlM1AqaKAhLP55-Z1-eeI=.2383991e-22d3-4c0c-afab-353985e1f8fc@github.com>

> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
> 
> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
> 
> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
> 
> Testing: tiers 1-3

David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' into 8293592-JVM_StopThread
 - Removal all special handling of ThreadDeath.
 - Remove all references to the stillborn field
 - Initial commit: remove JVM_StopThread
 - Merge
 - Updates to Java Thread Primitive Deprecation page
 - Repalce "it" with "victim thread"
 - Merge
 - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
 - become -> became in javadoc
 - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903

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

Changes: https://git.openjdk.org/jdk/pull/10400/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10400&range=01
  Stats: 208 lines in 18 files changed: 19 ins; 146 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/10400.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10400/head:pull/10400

PR: https://git.openjdk.org/jdk/pull/10400


From dholmes at openjdk.org  Fri Sep 23 21:47:08 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Sep 2022 21:47:08 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup
In-Reply-To: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
Message-ID: <pe2S9eAR6fAkhNMkE7zsvJjErBsmkHbm5PrW6Sm8jE4=.1c30dc46-dafb-4b16-be3f-73e27fc8e5fd@github.com>

On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
> 
> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
> 
> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
> 
> Testing: tiers 1-3

This PR is now back to its proper form after merging the upstream changes.  I can't say I like the "dependent PR" feature.

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

PR: https://git.openjdk.org/jdk/pull/10400


From dholmes at openjdk.org  Fri Sep 23 21:47:10 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Sep 2022 21:47:10 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup [v2]
In-Reply-To: <jPQnZdvskvzHDQZrF45DW8L9zsvSxiQKQHrODS2RAdk=.2fc75db3-f9d0-4bbb-8283-e387481cbc30@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
 <jPQnZdvskvzHDQZrF45DW8L9zsvSxiQKQHrODS2RAdk=.2fc75db3-f9d0-4bbb-8283-e387481cbc30@github.com>
Message-ID: <WlSewOOWwaXOlFuSI6NrOYXMvwwp1xvfYxpLZF4xAPE=.9efe45f9-a6df-4bd5-bece-7e349b092a9c@github.com>

On Fri, 23 Sep 2022 18:21:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Merge branch 'master' into 8293592-JVM_StopThread
>>  - Removal all special handling of ThreadDeath.
>>  - Remove all references to the stillborn field
>>  - Initial commit: remove JVM_StopThread
>>  - Merge
>>  - Updates to Java Thread Primitive Deprecation page
>>  - Repalce "it" with "victim thread"
>>  - Merge
>>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>>  - become -> became in javadoc
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903
>
> src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 102:
> 
>> 100:             try {
>> 101:                 connector = connectors.next();
>> 102:             } catch (Exception | Error x) {
> 
> Maybe this should just catch `Throwable`, although it is unclear to me why we would want to catch any exception here.

@plummercj  these changes are not actually part of this PR but came from the upstream PR this was dependent on.

> src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 126:
> 
>> 124:             try {
>> 125:                 transportService = transportServices.next();
>> 126:             } catch (Exception | Error x) {
> 
> Another that could be just catch `Throwable`

@plummercj  these changes are not actually part of this PR but came from the upstream PR this was dependent on.

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

PR: https://git.openjdk.org/jdk/pull/10400


From duke at openjdk.org  Fri Sep 23 22:27:16 2022
From: duke at openjdk.org (ScientificWare)
Date: Fri, 23 Sep 2022 22:27:16 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v6]
In-Reply-To: <32gcqBPrkOpDtMLmeh7KGGnXrYf-4VMabEXYPOt0rFY=.8fc58c48-dd7e-4444-9344-7f2ba33bc7a9@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <592sDW2VIvByGwKDoAYG5P7a4Iygc5CYtPVG7vr9qrk=.12f3db5e-a3a7-41c6-b5f9-e1588507bbe2@github.com>
 <DmaK20O4iPQJGHZyci3IQEsFFbdhnBgMmB4Aok-GE9g=.4884358d-108b-4115-a948-180727268137@github.com>
 <qNrVXI_sLUl_nLStcratdK-OUhBax_v9z2vm7tMDTGs=.7d8763f5-0985-4015-bb29-06b89d44593c@github.com>
 <32gcqBPrkOpDtMLmeh7KGGnXrYf-4VMabEXYPOt0rFY=.8fc58c48-dd7e-4444-9344-7f2ba33bc7a9@github.com>
Message-ID: <9r8cFmlOw3FVG1jvE974QoOW7Aph9MnUWnj5w44bBR8=.a077b623-99dd-4f8b-83fa-bd6054d7616d@github.com>

On Fri, 23 Sep 2022 16:48:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> With this change, the code is more concise but we double the number of tests ?
>
>> With this change, the code is more concise but we double the number of tests ?
> 
> For a rather rare case. I don't think it's a critical path which affects performance.
> 
> If you like, you can create a variable to store the result of `n == 4` to avoid testing once again. I still don't think it's worth it.

Could we reach a conciliation with this version. ? All cases are treated in 2 or 3 tests.
It incorporates all your suggestions and my single comment about the number of tests.

        if (n < 5) {
            if (n < 3) {
                return null;
            } else {
                final char r = digits.charAt(0);
                final char g = digits.charAt(1);
                final char b = digits.charAt(2);
                final char a = n == 4 ? digits.charAt(3) : 'f';
                digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$s%4$s%4$s", r, g, b, a);
            }
        } else if (n < 7) {
            if (n == 5) {
                return null;
            } else {
                digits = String.format("%sff", digits);
            }
        } else if (n != 8 ) {
            return null;
        }
        try {
            int i = Integer.parseUnsignedInt(digits, 16);
            return new Color((i >> 24) & 0xFF, (i >> 16) & 0xFF, (i >> 8) & 0xFF, i & 0xFF);
        } catch (NumberFormatException nfe) {
            return null;
        }

Some articles suggest to avoid using exceptions as flow controls. I never tested this point. That's why I introduced Patterns in this method. May I run tests in this case ? With the code below :

        if (n < 5) {
            if (n < 3 || !hex.matcher(digits).matches()) {
                return null;
            } else {
                final char r = digits.charAt(0);
                final char g = digits.charAt(1);
                final char b = digits.charAt(2);
                final char a = n == 4 ? digits.charAt(3) : 'f';
                digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$s%4$s%4$s", r, g, b, a);
            }
        } else if (n < 7) {
            if (n == 5 || !hex.matcher(digits).matches()) {
                return null;
            } else {
                digits = String.format("%sff", digits);
            }
        } else if (n != 8 || !hex.matcher(digits).matches()) {
            return null;
        }
        try {
            int i = Integer.parseUnsignedInt(digits, 16);
            return new Color((i >> 24) & 0xFF, (i >> 16) & 0xFF, (i >> 8) & 0xFF, i & 0xFF);
        } catch (NumberFormatException nfe) {
            return null;
        }

I also wish to test the version with bit rotation too :

        if (n < 5) {
            if (n < 3 || !hex.matcher(digits).matches()) {
                return null;
            } else {
                final char r = digits.charAt(0);
                final char g = digits.charAt(1);
                final char b = digits.charAt(2);
                final char a = n == 4 ? digits.charAt(3) : 'f';
                digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$s%4$s%4$s", r, g, b, a);
            }
        } else if (n < 7) {
            if (n == 5 || !hex.matcher(digits).matches()) {
                return null;
            } else {
                digits = String.format("%sff", digits);
            }
        } else if (n != 8 || !hex.matcher(digits).matches()) {
            return null;
        }
        try {
            return new Color(Integer.rotateRight(Integer.parseUnsignedInt(digits, 16),8),
                             true);
        } catch (NumberFormatException nfe) {
            return null;
        }

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

PR: https://git.openjdk.org/jdk/pull/10317


From duke at openjdk.org  Sat Sep 24 00:51:17 2022
From: duke at openjdk.org (ScientificWare)
Date: Sat, 24 Sep 2022 00:51:17 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v6]
In-Reply-To: <hYf28fRsZSU5d43Q6CwrqTHSH_QpAdBZOF-caxAK7N8=.c045fb3a-9a0e-4a7f-ad8f-2604ff20f2e4@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <592sDW2VIvByGwKDoAYG5P7a4Iygc5CYtPVG7vr9qrk=.12f3db5e-a3a7-41c6-b5f9-e1588507bbe2@github.com>
 <DmaK20O4iPQJGHZyci3IQEsFFbdhnBgMmB4Aok-GE9g=.4884358d-108b-4115-a948-180727268137@github.com>
 <EG1YwvCYVMB2ltYk0h6-c_y6ZycpV14mztbtvC06y4o=.9acaa22f-95ec-4f85-9f66-2f0f7c2c1ecb@github.com>
 <hYf28fRsZSU5d43Q6CwrqTHSH_QpAdBZOF-caxAK7N8=.c045fb3a-9a0e-4a7f-ad8f-2604ff20f2e4@github.com>
Message-ID: <PS70zgz0TA3ZhhOK6y0NJGdAqGvzqoRSzCbuErijsJg=.9244b228-6d21-45ac-8adf-9b74e7666e81@github.com>

On Fri, 23 Sep 2022 17:08:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I'm going to work on rgb() and rgba() notations (https://bugs.openjdk.org/browse/JDK-8294090). Could we let this unchanged or differ this change ?
>
>> I'm going to work on rgb() and rgba() notations (https://bugs.openjdk.org/browse/JDK-8294090). Could we let this unchanged or differ this change ?
> 
> How is this comment related to the `rgb()` and `rgba()` functions?
> 
> I think using `color.getRGB()` and comparing the value to a hex-number representing the colour (with the alpha byte moved to the higher byte of the double word) is concise and clear.
> 
> My other point was that you still validate the red, green and blue components of the color but you don't read them from the color parsed on line 68. If you don't update `red`, `green` and `blue`, they're not changed, verifying the values for the second time won't catch an error even if `styleSheet.stringToColor` returned a different color.

Big mistake. I forgot to update red, green and blue when I extended the test to these values. Anyway I'm going to apply your suggestion.

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

PR: https://git.openjdk.org/jdk/pull/10317


From duke at openjdk.org  Sun Sep 25 00:31:20 2022
From: duke at openjdk.org (ScientificWare)
Date: Sun, 25 Sep 2022 00:31:20 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v9]
In-Reply-To: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
Message-ID: <GWoMl0PpIqFtTWN3pot5Iy9S2ceimXTgYz09oE_r2gE=.3af4fb5b-e4b5-44a1-8fcf-85fbbc1b6c52@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
> 
> This is tracked in JBS as 
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
> 
> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
> 
> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)

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

  Simplifications of the test.
  
  Removes individual color tests and only compares the RGB value.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10317/files
  - new: https://git.openjdk.org/jdk/pull/10317/files/767c87ce..a95d2824

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=07-08

  Stats: 41 lines in 1 file changed: 3 ins; 31 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10317.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10317/head:pull/10317

PR: https://git.openjdk.org/jdk/pull/10317


From duke at openjdk.org  Sun Sep 25 00:31:27 2022
From: duke at openjdk.org (ScientificWare)
Date: Sun, 25 Sep 2022 00:31:27 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v4]
In-Reply-To: <3YYXAf08Oa8xLa6Ku6YpAsKGYP8D-YCSwwHhG8KXnlQ=.e7bf8ba3-093e-4fa5-b933-cb2be201e677@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <3zRRzGGzRP8MNyttEBCWWqHS3eXkmX-6DCR25ylScVc=.121df206-6a52-459f-88f9-0e135b802409@github.com>
 <3YYXAf08Oa8xLa6Ku6YpAsKGYP8D-YCSwwHhG8KXnlQ=.e7bf8ba3-093e-4fa5-b933-cb2be201e677@github.com>
Message-ID: <ySILgEOEm7uQQX4QabyseVaToQG81qqM9-uu898B6FQ=.83644754-fbda-4b1f-ae83-52d9f84c1746@github.com>

On Sat, 17 Sep 2022 17:00:30 GMT, ExE Boss <duke at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removes author name.
>>   
>>   Removes author name for JDK main-line development repository.
>
> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1404:
> 
>> 1402:         } else if (n != 8 || !hex.matcher(digits).matches()) {
>> 1403:             return null;
>> 1404:         }
> 
> Using `charAt` avoids creating temporary strings of length `1`.
> 
> Also, using?the `%[argument_index$]conversion` format?specifier?form allows?halving the?lengths of?the?vararg?arrays.
> Suggestion:
> 
>         if (n == 3 && hex.matcher(digits).matches()) {
>             final char r = digits.charAt(0);
>             final char g = digits.charAt(1);
>             final char b = digits.charAt(2);
>             digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$sff", r, g, b);
>         } else if (n == 4 && hex.matcher(digits).matches()) {
>             final char r = digits.charAt(0);
>             final char g = digits.charAt(1);
>             final char b = digits.charAt(2);
>             final char a = digits.charAt(3);
>             digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$s%4$s%4$s", r, g, b, a);
>         } else if (n == 6 && hex.matcher(digits).matches()) {
>             digits += "ff";
>         } else if (n != 8 || !hex.matcher(digits).matches()) {
>             return null;
>         }

@ExE-Boss After a quick performance test, I note that `%1$s%1$s%2$s%2$s%3$s%3$s%4$s%4$s` usage multiplies time execution at least by 4.

I'm going to test if there is other solutions than %n$s or %s. First of all by using a simple concatenation.

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

PR: https://git.openjdk.org/jdk/pull/10317


From duke at openjdk.org  Sun Sep 25 00:31:28 2022
From: duke at openjdk.org (ScientificWare)
Date: Sun, 25 Sep 2022 00:31:28 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v4]
In-Reply-To: <ySILgEOEm7uQQX4QabyseVaToQG81qqM9-uu898B6FQ=.83644754-fbda-4b1f-ae83-52d9f84c1746@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <3zRRzGGzRP8MNyttEBCWWqHS3eXkmX-6DCR25ylScVc=.121df206-6a52-459f-88f9-0e135b802409@github.com>
 <3YYXAf08Oa8xLa6Ku6YpAsKGYP8D-YCSwwHhG8KXnlQ=.e7bf8ba3-093e-4fa5-b933-cb2be201e677@github.com>
 <ySILgEOEm7uQQX4QabyseVaToQG81qqM9-uu898B6FQ=.83644754-fbda-4b1f-ae83-52d9f84c1746@github.com>
Message-ID: <-s6IzyosG5NkkHws82XC7iE_IdQTuBgiEBaFqqaJmp4=.fec39ce0-8a5e-4db0-8a84-900ea3afb9af@github.com>

On Sat, 24 Sep 2022 12:29:18 GMT, ScientificWare <duke at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1404:
>> 
>>> 1402:         } else if (n != 8 || !hex.matcher(digits).matches()) {
>>> 1403:             return null;
>>> 1404:         }
>> 
>> Using `charAt` avoids creating temporary strings of length `1`.
>> 
>> Also, using?the `%[argument_index$]conversion` format?specifier?form allows?halving the?lengths of?the?vararg?arrays.
>> Suggestion:
>> 
>>         if (n == 3 && hex.matcher(digits).matches()) {
>>             final char r = digits.charAt(0);
>>             final char g = digits.charAt(1);
>>             final char b = digits.charAt(2);
>>             digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$sff", r, g, b);
>>         } else if (n == 4 && hex.matcher(digits).matches()) {
>>             final char r = digits.charAt(0);
>>             final char g = digits.charAt(1);
>>             final char b = digits.charAt(2);
>>             final char a = digits.charAt(3);
>>             digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$s%4$s%4$s", r, g, b, a);
>>         } else if (n == 6 && hex.matcher(digits).matches()) {
>>             digits += "ff";
>>         } else if (n != 8 || !hex.matcher(digits).matches()) {
>>             return null;
>>         }
>
> @ExE-Boss After a quick performance test, I note that `%1$s%1$s%2$s%2$s%3$s%3$s%4$s%4$s` usage multiplies time execution at least by 4.
> 
> I'm going to test if there is other solutions than %n$s or %s. First of all by using a simple concatenation.

If allowed `digits = "" + r + r + g + g + b + b + a + a` would be a good candidate.

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

PR: https://git.openjdk.org/jdk/pull/10317


From mernst at openjdk.org  Sun Sep 25 17:04:38 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue.

Done: https://bugs.openjdk.org/browse/SKARA-1566

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

PR: https://git.openjdk.org/jdk/pull/10029


From mernst at openjdk.org  Sun Sep 25 17:04:38 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk,
 test/jdk/jni
Message-ID: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>

8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

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

Commit messages:
 - Remove file that was removed upstream
 - Fix inconsistency in capitalization
 - Undo change in zlip
 - Fix typos

Changes: https://git.openjdk.org/jdk/pull/10029/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294321
  Stats: 317 lines in 108 files changed: 0 ins; 195 del; 122 mod
  Patch: https://git.openjdk.org/jdk/pull/10029.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029

PR: https://git.openjdk.org/jdk/pull/10029


From jpai at openjdk.org  Sun Sep 25 17:04:38 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
Message-ID: <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>

On Thu, 25 Aug 2022 19:55:47 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
>> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue.
> 
> Done: https://bugs.openjdk.org/browse/SKARA-1566

Hello Michael @mernst, these changes are mostly fine. However, they are spread across files which reside in different areas of the JDK. For changes like these, we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs.

Would you be willing to split this PR into separate ones. I would recommend starting with one PR which includes changes that are part of `test/jdk/java`, `test/jdk/jdk` and `test/jdk/jni`. If you can come up with that PR, then I'll go ahead and create a JBS issue for it and you can then link the PR against that issue.

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

PR: https://git.openjdk.org/jdk/pull/10029


From mernst at openjdk.org  Sun Sep 25 17:04:38 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:38 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
 <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>
Message-ID: <EP2u5O5H_olXmcotmpxlaoSoRHPs9N-3W2csNbysOm8=.6ad85587-573d-432d-89db-568989b754ec@github.com>

On Mon, 5 Sep 2022 06:32:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> these changes are mostly fine.

Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"?  It doesn't seem useful to make a pull request with known deficiencies.

> we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs.

Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes.

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

PR: https://git.openjdk.org/jdk/pull/10029


From duke at openjdk.org  Sun Sep 25 17:04:39 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <EP2u5O5H_olXmcotmpxlaoSoRHPs9N-3W2csNbysOm8=.6ad85587-573d-432d-89db-568989b754ec@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>
 <K8T3oImMy9VcIl8ElWlAlzrcmuvBroDqBKkMx5FbfJ4=.a1015a8f-bd22-4780-8cdb-7ad1880a494a@github.com>
 <EP2u5O5H_olXmcotmpxlaoSoRHPs9N-3W2csNbysOm8=.6ad85587-573d-432d-89db-568989b754ec@github.com>
Message-ID: <RWGt4_adstjnxq1OHM-jBMqSjzlLdAqNrpTu3JozTYM=.36dbfb8e-bbfc-4853-ad43-dbeb78bfd92d@github.com>

On Mon, 5 Sep 2022 14:54:50 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"?

These changes are fine. I don't see an instance where the duplicated words would mean a change in the specification.

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

PR: https://git.openjdk.org/jdk/pull/10029


From jpai at openjdk.org  Sun Sep 25 17:04:39 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <wFLhEno6MEH32FbXeZfWC01cobBwRBW3LbKhMpnYA3A=.dd2199f0-5725-498c-bc6d-0b764ac8ec76@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Hello Michael,

> > these changes are mostly fine.
> 
> Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"? It doesn't seem useful to make a pull request with known deficiencies.

I wasn't implying this PR had deficiencies. What I meant was, to be able to have this reviewed, in addition to code changes this will also need a issue to be created and linked to this PR (and the PR title changed to the form `<bugid>: <bug summary>`). 
I have now created https://bugs.openjdk.org/browse/JDK-8294321. Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers.

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

PR: https://git.openjdk.org/jdk/pull/10029


From mernst at openjdk.org  Sun Sep 25 17:04:39 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <wFLhEno6MEH32FbXeZfWC01cobBwRBW3LbKhMpnYA3A=.dd2199f0-5725-498c-bc6d-0b764ac8ec76@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <wFLhEno6MEH32FbXeZfWC01cobBwRBW3LbKhMpnYA3A=.dd2199f0-5725-498c-bc6d-0b764ac8ec76@github.com>
Message-ID: <kqbMO6iHpa3xNDX1Ooa6zLtG9rZJK7mBogbO83RQQLs=.b1cb0e4a-032b-438e-b1a4-7644680ecd6b@github.com>

On Sat, 24 Sep 2022 10:41:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers.

OK.  I'll repeat my comment from before:

> Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes.

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

PR: https://git.openjdk.org/jdk/pull/10029


From duke at openjdk.org  Sun Sep 25 17:04:39 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <PeWYni0LXLnheHNkbRfnq4DWiKApuzSnPDLuo6_mXZA=.c01ed027-9462-404c-a6c6-2caff919d380@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Oh no what happened
![image](https://user-images.githubusercontent.com/8303399/192155378-4bb439fa-d27a-417d-8a3c-cf7f7329458f.png)

src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053:

> 1051:    * fetch will take place at index 1.
> 1052:    *
> 1053:    * @return The current position index.

Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here.

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

PR: https://git.openjdk.org/jdk/pull/10029


From mernst at openjdk.org  Sun Sep 25 17:04:39 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <PeWYni0LXLnheHNkbRfnq4DWiKApuzSnPDLuo6_mXZA=.c01ed027-9462-404c-a6c6-2caff919d380@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <PeWYni0LXLnheHNkbRfnq4DWiKApuzSnPDLuo6_mXZA=.c01ed027-9462-404c-a6c6-2caff919d380@github.com>
Message-ID: <MnLhhKzLqR1jb7PbtrJu2AlU4xQ5EolX_Zi7TUsJ96g=.e03c2f32-7815-40e8-9450-b66e425c31ef@github.com>

On Sun, 25 Sep 2022 16:51:27 GMT, SWinxy <duke at openjdk.org> wrote:

> Oh no what happened

Oops!  Thanks for pointing out the goof.  It seems to be fixed now.

It has now been a month since I opened the pull request, and I have responded to each substantive comment promptly.  It would be great to merge this pull request to avoid the need for more merges.

> src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053:
> 
>> 1051:    * fetch will take place at index 1.
>> 1052:    *
>> 1053:    * @return The current position index.
> 
> Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here.

Thanks for pointing out the inconsistency.  I have fixed it.  (I noticed many violations of the official Javadoc style, but this is not the right pull request to fix them.)

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

PR: https://git.openjdk.org/jdk/pull/10029


From alanb at openjdk.org  Sun Sep 25 17:04:40 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 Sep 2022 17:04:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

src/java.base/share/native/libzip/zlib/zlib.h line 756:

> 754:    If this is done, the old level and strategy will be applied to the data
> 755:    compressed before deflateParams(), and the new level and strategy will be
> 756:    applied to the data compressed after deflateParams().

This is an issue for the upstream zlib project, we probably don't want to change it here.

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

PR: https://git.openjdk.org/jdk/pull/10029


From lancea at openjdk.org  Sun Sep 25 17:04:40 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 25 Sep 2022 17:04:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>
Message-ID: <x4W-bBcbveocGQIvbX-qnNqHrN7t7vh7ZFwtj-BVt2o=.5a11a98b-86b6-4cfb-82c5-a8809fbedf7f@github.com>

On Tue, 30 Aug 2022 09:31:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> src/java.base/share/native/libzip/zlib/zlib.h line 756:
> 
>> 754:    If this is done, the old level and strategy will be applied to the data
>> 755:    compressed before deflateParams(), and the new level and strategy will be
>> 756:    applied to the data compressed after deflateParams().
> 
> This is an issue for the upstream zlib project, we probably don't want to change it here.

Agree.  See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos.

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

PR: https://git.openjdk.org/jdk/pull/10029


From mernst at openjdk.org  Sun Sep 25 17:04:40 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 25 Sep 2022 17:04:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <x4W-bBcbveocGQIvbX-qnNqHrN7t7vh7ZFwtj-BVt2o=.5a11a98b-86b6-4cfb-82c5-a8809fbedf7f@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <R54YOofSpP6mkT2GyVD4iej7GhNlgZZsc9ryNTQDbNA=.0df12727-83ea-46fa-9a8c-9eacce5235e7@github.com>
 <x4W-bBcbveocGQIvbX-qnNqHrN7t7vh7ZFwtj-BVt2o=.5a11a98b-86b6-4cfb-82c5-a8809fbedf7f@github.com>
Message-ID: <rIuyz9yAlhyXwOpBnnAnmL0xQZbMk6bbr8QP4iogfzk=.33cce124-d245-46de-bb74-f3eaf9dbdfd8@github.com>

On Tue, 30 Aug 2022 09:55:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/native/libzip/zlib/zlib.h line 756:
>> 
>>> 754:    If this is done, the old level and strategy will be applied to the data
>>> 755:    compressed before deflateParams(), and the new level and strategy will be
>>> 756:    applied to the data compressed after deflateParams().
>> 
>> This is an issue for the upstream zlib project, we probably don't want to change it here.
>
> Agree.  See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos.

OK.  I backed out the change to zlib.

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

PR: https://git.openjdk.org/jdk/pull/10029


From duke at openjdk.org  Sun Sep 25 17:23:28 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 25 Sep 2022 17:23:28 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <l_BuZBAL5oEJ3CbI12q_XE9gFcXd-qEwGsRrSaIJDd0=.dea17f4e-b629-43e4-bc7e-47fccac4cb3a@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

I'm not a committer (yet) so I can't [sponsor](https://openjdk.org/sponsor/) this PR, even though I would.

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

PR: https://git.openjdk.org/jdk/pull/10029


From duke at openjdk.org  Sun Sep 25 18:00:39 2022
From: duke at openjdk.org (SWinxy)
Date: Sun, 25 Sep 2022 18:00:39 GMT
Subject: RFR: 8293478: [java.desktop/macOS] Condense SDRenderType usages in
 QuartzRenderer.m [v3]
In-Reply-To: <levplAHOHGYRedb1qypkWNb4hcv6W0rO6vF2wbfbf7M=.79250f01-b07e-41e6-b1d3-166ffde6bd76@github.com>
References: <levplAHOHGYRedb1qypkWNb4hcv6W0rO6vF2wbfbf7M=.79250f01-b07e-41e6-b1d3-166ffde6bd76@github.com>
Message-ID: <laZac6ZfK1Jgj9i16ei1eWnSiE175V-5VAW1-ty8_FI=.2a474adc-3565-466e-a376-5fe2be3165e0@github.com>

> The `SDRenderType` enum is often returned using a variable declared at the start of functions. These can be inlined in the `return` itself. Using a ternary operator condenses what may be 12 lines into one, in the most extreme cases. `doRectUsingCG` and `doPolyUsingCG` were both modified more than the rest, but are still basically the same.
> 
> Example change:
> 
> SDRenderType renderType = SD_Nothing;
> 
> if (fill == YES)
> {
>     renderType = SD_Fill;
> }
> else
> {
>     renderType = SD_Stroke;
> }
> 
> // ...
> 
> return renderType;
> 
> 
> 
> // ...
> 
> return fill ? SD_Fill : SD_Stroke;

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

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10174/files
  - new: https://git.openjdk.org/jdk/pull/10174/files/8fbaaa69..fb4b6a59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10174&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10174&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/10174


From duke at openjdk.org  Mon Sep 26 02:33:25 2022
From: duke at openjdk.org (SWinxy)
Date: Mon, 26 Sep 2022 02:33:25 GMT
Subject: RFR: 4668290: unclear spec for Polygon.bounds field
Message-ID: <jjzwWZJPW8Essivj9svlhO-LScPQV_TlMoC0GGOVgMY=.b5d5ced5-77af-4ce9-8214-10c1cc0392cb@github.com>

New documentation replaces the `This value can be null.`:

When created, {@link #invalidate() invalidated}, or {@link #reset() reset},
this becomes {@code null}. To get out of the null state,
{@link #getBounds()} called with {@link #npoints} being greater than
{@code 0} will transfer into a non-null {@link Rectangle}.


I think I've got the reason for why it can be `null` correct, but you never know.

In javax.swing.text.html.Map, I've replaced setting the field to null with the equivalent #invalidate(). This may mean we can make the field private in the future.

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

Commit messages:
 - 4668290: unclear spec for Polygon.bounds field

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

PR: https://git.openjdk.org/jdk/pull/10417


From duke at openjdk.org  Mon Sep 26 02:57:21 2022
From: duke at openjdk.org (SWinxy)
Date: Mon, 26 Sep 2022 02:57:21 GMT
Subject: RFR: 4756278: RFE: Insufficient API documentation for java.awt.Polygon
 constructor
Message-ID: <6ZyhGs5SlC42FDN3ToVFR1XybAsdWBTYzu3JBf_Pxsk=.1813b436-3c16-4686-bc0f-52b7039adb63@github.com>

Appends: `, copying the array contents of {@code xpoints} and {@code ypoints}` to specify that the arrays in the constructor are explicitly copied.

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

Commit messages:
 - 4756278: RFE: Insufficient API documentation for java.awt.Polygon constructor

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

PR: https://git.openjdk.org/jdk/pull/10418


From psadhukhan at openjdk.org  Mon Sep 26 04:26:51 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 26 Sep 2022 04:26:51 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types
In-Reply-To: <pYuKs-vM1qUaUDVjaCuiOF40D7oTTYBN9ibik3vRH98=.e9dcddd6-da98-44e0-a68a-fd1c7f6ec570@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
 <pYuKs-vM1qUaUDVjaCuiOF40D7oTTYBN9ibik3vRH98=.e9dcddd6-da98-44e0-a68a-fd1c7f6ec570@github.com>
Message-ID: <HbfL-s8TTAWQQ3C0AFZgmmQlni3zvRYANaHtNdlqID0=.bbd28654-6552-4fbf-bb83-c937c153c694@github.com>

On Fri, 23 Sep 2022 19:05:53 GMT, Phil Race <prr at openjdk.org> wrote:

>> API specification says about BasicTextAreaUI.create "Returns a WrappedPlainView or PlainView". 
>> But for [bidi](https://github.com/openjdk/jdk/blob/d14e96d9701dae951aa365029f58afb6687a646a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java#L168) text, this method returns BoxView and other views , so the documentation needs to be updated.
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java line 143:
> 
>> 141:      * PlainView if non-bidi text is handled
>> 142:      * else returns PlainParagraph or BoxView if bidi text is being handled.
>> 143:      *
> 
> So .. what if the text wasn't bidi but then some one adds bidi text ?
> 
> And can we change the summary of the BUG and PR to something grammatically correct, and perhaps even
> descriptive such as
> "BasicTextAreaUI:create incompletely documents the possible returned View types"

In that case BasicTextUI#insertUpdate() will change the model which will again call BasicTextAreaUI#create to change the view to i18n to either of BoxView or PlainParagraph.

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

PR: https://git.openjdk.org/jdk/pull/10376


From tr at openjdk.org  Mon Sep 26 05:13:40 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 26 Sep 2022 05:13:40 GMT
Subject: RFR: 7172359: HTML parser StackOverflowError on invalid HTML: <li>
 tag inside an <option> [v2]
In-Reply-To: <14Xsw8yK2ppDcaqcWeWUfTjA-cH86IE1mN30vxdITjg=.a5dcd15c-424a-48fa-b38d-283f20a0fe0c@github.com>
References: <edPACBk6ADLPsapJLTvWRDOYjYN_YgZXPDYn-hDo6Pc=.51f30a46-e66a-49a1-bfbe-9241827d0751@github.com>
 <14Xsw8yK2ppDcaqcWeWUfTjA-cH86IE1mN30vxdITjg=.a5dcd15c-424a-48fa-b38d-283f20a0fe0c@github.com>
Message-ID: <-U4zyqwY6bNuY5ztnynjMhgSWZRCo4uydE_yHt0Olmo=.64330d4d-c87b-4104-9432-a142c53ff59e@github.com>

On Thu, 22 Sep 2022 12:23:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If there is invalid tag, stack terminates but it still tries to recurse through by calling legalElementContext() which results in StackOverflowError.
>> Fix is to return if stack is terminated after checking current tag is not valid in current context
>> 
>> All other test/html/parser as well as other jtreg suite tests are ok with the fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Return only if current tag is not valid in current context

Fix is tested and works fine.

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

Marked as reviewed by tr (Author).

PR: https://git.openjdk.org/jdk/pull/10279


From tr at openjdk.org  Mon Sep 26 06:05:35 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 26 Sep 2022 06:05:35 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
In-Reply-To: <eyoTId42r1xHmZOGk66wVvNNEdzp1pVhu_nToShIBbQ=.857d3f89-7619-4856-a9df-eb77e880bf57@github.com>
References: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
 <eyoTId42r1xHmZOGk66wVvNNEdzp1pVhu_nToShIBbQ=.857d3f89-7619-4856-a9df-eb77e880bf57@github.com>
Message-ID: <CtajpYf1xN-fH1h4Fpy-BQ7QDnRAPj1Dp92o-xMHcQg=.b38cc1d7-7001-4862-be30-c366e4e01b60@github.com>

On Thu, 22 Sep 2022 19:15:05 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The color returned for `InteriorBackground` property is the default color used for only _WindowsClassicLookAndFeel_. For _WindowsLookAndFeel_ the `InteriorBackground` color is not been used when checkbox paint happens. In _WindowsLookAndFeel_ the CheckBox check/uncheck is drawn using `ImageCache` which is totally independent of `InteriorBackground` color in which the user expects it to be.
>> The proposed fix is to return null for _WindowsLookAndFeel_ (which is what happens in other LookAndFeel like Metal/Synth/Motif/Aqua ) and return default color which is the actual color used in _WindowsClassicLookAndFeel_.
>
> test/jdk/javax/swing/JCheckBox/InteriorBackgroundTest.java line 33:
> 
>> 31:  * @test
>> 32:  * @bug 8289539
>> 33:  * @key headful
> 
> Is this test marked headful to load system colors associated with the LAF? 
> Since we are not displaying anything on screen.

I specified as headful since I'm using JFrame to subclass and change the Look and Feel at Runtime. Not sure if I can make is headless.

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

PR: https://git.openjdk.org/jdk/pull/10385


From duke at openjdk.org  Mon Sep 26 06:13:47 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Mon, 26 Sep 2022 06:13:47 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser shouldn't display /../../../..
 in combobox and selection textarea. [v2]
In-Reply-To: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
Message-ID: <mqsNLbjIXRSTLLlDULdAjcUCkugwc-uUC4g2Rq062qg=.26fec366-1c69-495c-b16c-f762ff556963@github.com>

> When a user selects ../ from directory list in GTK FileChooser continuosly, it leads to '../../../.....' in combobox and selection textarea even though it the current directory is at root level.
> 
> Fix for the issue is to check if current directory is root then don't process the selection of ' ../ '.
> 
> Test case has been added and checked in CI pipeline. Link is attached in JBS.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Comment added and test case condotion update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10390/files
  - new: https://git.openjdk.org/jdk/pull/10390/files/8f8aed0c..ff3bce2c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10390&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10390&range=00-01

  Stats: 11 lines in 2 files changed: 9 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10390.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10390/head:pull/10390

PR: https://git.openjdk.org/jdk/pull/10390


From duke at openjdk.org  Mon Sep 26 06:18:41 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Mon, 26 Sep 2022 06:18:41 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser shouldn't display /../../../..
 in combobox and selection textarea. [v2]
In-Reply-To: <avWNqZ7QEX_PKBFQedGijjmgZi3KPQZG5z8QOGZqX40=.38191ebe-a37f-455c-b911-8c5933e96dae@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <avWNqZ7QEX_PKBFQedGijjmgZi3KPQZG5z8QOGZqX40=.38191ebe-a37f-455c-b911-8c5933e96dae@github.com>
Message-ID: <OHrWKX1OFuuq-pC3Fc7BSMxx6e1yIckMuAY90BXCGN8=.2f65764e-3895-47c9-90ca-ff20511a8385@github.com>

On Fri, 23 Sep 2022 11:11:12 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comment added and test case condotion update
>
> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java line 436:
> 
>> 434:                 int index = list.locationToIndex(e.getPoint());
>> 435:                 File currentDirectory = getFileChooser().getCurrentDirectory();
>> 436:                 if (currentDirectory.getParentFile() == null && index == 1) {
> 
> Adding a Comment explaining the statement `index == 1` would be better to understand that it signifies root directory index.

Added a comment. 
Basically, `getParentFile` method is used to check root directory and `index == 1` is the index of `../` directory.

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

PR: https://git.openjdk.org/jdk/pull/10390


From duke at openjdk.org  Mon Sep 26 06:38:53 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Mon, 26 Sep 2022 06:38:53 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser shouldn't display /../../../..
 in combobox and selection textarea.
In-Reply-To: <4oKkNRdQ4UNy8rElxDwMSFTSpMKxK9yrhdb4YcdFg3g=.1784792d-1c86-46c5-a340-d107222dcd32@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <4oKkNRdQ4UNy8rElxDwMSFTSpMKxK9yrhdb4YcdFg3g=.1784792d-1c86-46c5-a340-d107222dcd32@github.com>
Message-ID: <I4BYG9_XvUvpFh5dNunOOybZykWbn7tRiz5PVpJYIk0=.272fa504-8e62-4b85-b65b-a5800d24e5d1@github.com>

On Fri, 23 Sep 2022 11:23:40 GMT, Tejesh R <tr at openjdk.org> wrote:

> Is there any possibility to check for current Directory to be `root` before confirming that the traversal is stopping at root?

Added the condition to check if the current directory is root.

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

PR: https://git.openjdk.org/jdk/pull/10390


From duke at openjdk.org  Mon Sep 26 06:38:54 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Mon, 26 Sep 2022 06:38:54 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser shouldn't display /../../../..
 in combobox and selection textarea. [v2]
In-Reply-To: <avWNqZ7QEX_PKBFQedGijjmgZi3KPQZG5z8QOGZqX40=.38191ebe-a37f-455c-b911-8c5933e96dae@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <avWNqZ7QEX_PKBFQedGijjmgZi3KPQZG5z8QOGZqX40=.38191ebe-a37f-455c-b911-8c5933e96dae@github.com>
Message-ID: <jdPQo4cuPfD6T4QNgV0hOKRIp5ZQJYzGrrHBnyr_04Y=.8d5dea5d-5135-4abd-a847-0df13c5c11a2@github.com>

On Fri, 23 Sep 2022 11:14:39 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comment added and test case condotion update
>
> test/jdk/javax/swing/JFileChooser/TestFileChooserDirectorySelection.java line 71:
> 
>> 69:                     passed = true;
>> 70:                     break;
>> 71:                 } else if (++i > 5) {
> 
> Retries will be 4 right......? Since you are starting with 2 till 5......?

Updated the retries to be 5 and then break to avoid infinite loop.

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

PR: https://git.openjdk.org/jdk/pull/10390


From jdv at openjdk.org  Mon Sep 26 06:53:42 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 26 Sep 2022 06:53:42 GMT
Subject: RFR: 8278086: [REDO] ImageIO.write() method will throw
 IndexOutOfBoundsException
Message-ID: <m6yQDNwg4jCq1vRHp9i-aaiBjutuSMNboon6xAs8UGQ=.162d3d4c-641f-41d1-8392-ce7bbde96613@github.com>

This is redo of https://bugs.openjdk.org/browse/JDK-8262297
In https://bugs.openjdk.org/browse/JDK-8262297 we added similar change but we didnt allow 15bpp image in BMP, because of which many tests which were using USHORT_555_RGB format were failing as reported at https://bugs.openjdk.org/browse/JDK-8278047

There is ambiguity on whether we should support 15bpp BMP encoding also or not as captured in JBS : https://bugs.openjdk.org/browse/JDK-8278086?focusedCommentId=14521952&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14521952

Since adding tighter condition to only allow 0, 1, 4, 8, 16, 24 and 32 bpp is causing many failures. I have modified the check to allow 15bpp also.

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

Commit messages:
 - 8278086: [REDO] ImageIO.write() method will throw IndexOutOfBoundsException

Changes: https://git.openjdk.org/jdk/pull/10419/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10419&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8278086
  Stats: 92 lines in 2 files changed: 89 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10419.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10419/head:pull/10419

PR: https://git.openjdk.org/jdk/pull/10419


From psadhukhan at openjdk.org  Mon Sep 26 11:04:33 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 26 Sep 2022 11:04:33 GMT
Subject: Integrated: 4797982: Setting negative size of JSplitPane divider leads
 to unexpected results.
In-Reply-To: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
Message-ID: <lSFCaL4NfsK5DZ08NQP-qkUNlZ2NwtlhFuB78B7CIEw=.d645a436-e6b3-45f5-ad82-13370149b747@github.com>

On Wed, 20 Jul 2022 09:12:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
> I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.

This pull request has now been integrated.

Changeset: 2be31587
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2be315877b734b70170ef6375712188d7cd64268
Stats:     80 lines in 3 files changed: 80 ins; 0 del; 0 mod

4797982: Setting negative size of JSplitPane divider leads to unexpected results.

Reviewed-by: azvegint, prr

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

PR: https://git.openjdk.org/jdk/pull/9566


From aivanov at openjdk.org  Mon Sep 26 11:07:24 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 26 Sep 2022 11:07:24 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v6]
In-Reply-To: <9r8cFmlOw3FVG1jvE974QoOW7Aph9MnUWnj5w44bBR8=.a077b623-99dd-4f8b-83fa-bd6054d7616d@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <592sDW2VIvByGwKDoAYG5P7a4Iygc5CYtPVG7vr9qrk=.12f3db5e-a3a7-41c6-b5f9-e1588507bbe2@github.com>
 <DmaK20O4iPQJGHZyci3IQEsFFbdhnBgMmB4Aok-GE9g=.4884358d-108b-4115-a948-180727268137@github.com>
 <qNrVXI_sLUl_nLStcratdK-OUhBax_v9z2vm7tMDTGs=.7d8763f5-0985-4015-bb29-06b89d44593c@github.com>
 <32gcqBPrkOpDtMLmeh7KGGnXrYf-4VMabEXYPOt0rFY=.8fc58c48-dd7e-4444-9344-7f2ba33bc7a9@github.com>
 <9r8cFmlOw3FVG1jvE974QoOW7Aph9MnUWnj5w44bBR8=.a077b623-99dd-4f8b-83fa-bd6054d7616d@github.com>
Message-ID: <MiYK_L_hYq3_D6HdHWSeQ6POVfmjc2KiOiJhetL2uH4=.df7929eb-d6a9-423d-bf0d-0255782d466b@github.com>

On Fri, 23 Sep 2022 22:25:09 GMT, ScientificWare <duke at openjdk.org> wrote:

> Could we reach a conciliation with this version. ? All cases are treated in 2 or 3 tests.

Your new versions introduce one more condition to each case and make the code more complicated and less clear. I am for concise, clear and readable code. I am against premature optimisation, and it hasn't been proved yet that there's a performance issue.

Combining the cases of `n == 3` and `n == 4` avoids code duplication by introducing one more comparison to both cases. If this becomes a critical path, JIT could optimise the code.

As such, I am still for combining these two cases. If you insist, I'm okay with your original code with code duplication. Yet I'd like to eliminate the duplicate code.

> Some articles suggest to avoid using exceptions as flow controls. I never tested this point. That's why I introduced Patterns in this method.

It's true, creating an exception object is a somewhat expensive operation. Yet you say, ?_most_ of color notations are correct?, therefore an incorrect color which cannot be parsed is rare, so it's _an exceptional situation_, it is okay to use exceptions in this case. You also say, ?Pattern usage has a significant time cost,? at the same time, you introduce a small time penalty for each and every correct color.

I think the hex pattern is redundant.

> I also wish to test the version with bit rotation too :
> 
> ```java
>             return new Color(Integer.rotateRight(Integer.parseUnsignedInt(digits, 16),8),
>                             true);
> ```

It could be not as clear, yet it works.

May I suggest wrapping the code for `Color` and `rotateRight` arguments?


            return new Color(
                    Integer.rotateRight(Integer.parseUnsignedInt(digits, 16),
                                        8),
                    true);


It fits better into 80-column limit. Alternatively, wrap the second parameter of `rotateRight` only:

            return new Color(Integer.rotateRight(Integer.parseUnsignedInt(digits, 16),
                                                 8),
                             true);

This way it's easier to see how many bits are rotated.

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

PR: https://git.openjdk.org/jdk/pull/10317


From tr at openjdk.org  Mon Sep 26 11:07:25 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 26 Sep 2022 11:07:25 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0
In-Reply-To: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
Message-ID: <xSKq7POrfrJ4KYYBA8crdY5rJCjciMK4NEK-LZTcjDk=.8161df0a-2d8c-4784-948b-b7632af2d7e0@github.com>

On Tue, 20 Sep 2022 18:24:26 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Fixed test bug where mouse location was being calculated before robot mouseMove operation was complete

Can we move the test file to one directory back as we are doing it in swing test fix. Means moving the test to Multscreen folder, instead of MultiScreenLocationTest.....?

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

PR: https://git.openjdk.org/jdk/pull/10363


From aivanov at openjdk.org  Mon Sep 26 11:13:22 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 26 Sep 2022 11:13:22 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v9]
In-Reply-To: <GWoMl0PpIqFtTWN3pot5Iy9S2ceimXTgYz09oE_r2gE=.3af4fb5b-e4b5-44a1-8fcf-85fbbc1b6c52@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <GWoMl0PpIqFtTWN3pot5Iy9S2ceimXTgYz09oE_r2gE=.3af4fb5b-e4b5-44a1-8fcf-85fbbc1b6c52@github.com>
Message-ID: <-hUudp4M4kNHOKAfm-6kq_wQ3ahx7OHEiOHWJbjVtDA=.d8449e0c-cb12-437c-9f5f-c113afb23a7e@github.com>

On Sun, 25 Sep 2022 00:31:20 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
>> 
>> This is tracked in JBS as 
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
>> 
>> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
>> 
>> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplifications of the test.
>   
>   Removes individual color tests and only compares the RGB value.

test/jdk/javax/swing/text/html/CSS/Hex3468DigitsColor.java line 44:

> 42:         // Then expecting 0xaaff1122 from Color.
> 43:         Color color = styleSheet.stringToColor("#f12a");
> 44:         result.append("  Test for #f00a");

Previously, you added a message to `result` in case of failure only, now you always do it. The updated code does not output the actual value.

The tested color is `#f12a`  instead of `#f00a`.

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

PR: https://git.openjdk.org/jdk/pull/10317


From tr at openjdk.org  Mon Sep 26 12:05:24 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 26 Sep 2022 12:05:24 GMT
Subject: RFR: 8278086: [REDO] ImageIO.write() method will throw
 IndexOutOfBoundsException
In-Reply-To: <m6yQDNwg4jCq1vRHp9i-aaiBjutuSMNboon6xAs8UGQ=.162d3d4c-641f-41d1-8392-ce7bbde96613@github.com>
References: <m6yQDNwg4jCq1vRHp9i-aaiBjutuSMNboon6xAs8UGQ=.162d3d4c-641f-41d1-8392-ce7bbde96613@github.com>
Message-ID: <HCFSsS_wgXgOGnbRQ0HmbSoJF9ftawNsjCQQxqSZbrg=.6a050270-a6fb-4b60-8551-84162a16b717@github.com>

On Mon, 26 Sep 2022 06:45:58 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This is redo of https://bugs.openjdk.org/browse/JDK-8262297
> In https://bugs.openjdk.org/browse/JDK-8262297 we added similar change but we didnt allow 15bpp image in BMP, because of which many tests which were using USHORT_555_RGB format were failing as reported at https://bugs.openjdk.org/browse/JDK-8278047
> 
> There is ambiguity on whether we should support 15bpp BMP encoding also or not as captured in JBS : https://bugs.openjdk.org/browse/JDK-8278086?focusedCommentId=14521952&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14521952
> 
> Since adding tighter condition to only allow 0, 1, 4, 8, 16, 24 and 32 bpp is causing many failures. I have modified the check to allow 15bpp also.

src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java line 1458:

> 1456:             return false;
> 1457:         }
> 1458:         int biType = imgType.getBufferedImageType();

Can remove biType variable I guess, since its not been used. 
The fix is tested and verified.

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

PR: https://git.openjdk.org/jdk/pull/10419


From jdv at openjdk.org  Mon Sep 26 13:20:36 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 26 Sep 2022 13:20:36 GMT
Subject: RFR: 8278086: [REDO] ImageIO.write() method will throw
 IndexOutOfBoundsException [v2]
In-Reply-To: <m6yQDNwg4jCq1vRHp9i-aaiBjutuSMNboon6xAs8UGQ=.162d3d4c-641f-41d1-8392-ce7bbde96613@github.com>
References: <m6yQDNwg4jCq1vRHp9i-aaiBjutuSMNboon6xAs8UGQ=.162d3d4c-641f-41d1-8392-ce7bbde96613@github.com>
Message-ID: <cy1Vkb0CECBWHX0F3DDUdhDFGCKhTZlGZ9y35YGayPo=.144df86a-f0eb-4d1e-9bf2-ccf0955d857d@github.com>

> This is redo of https://bugs.openjdk.org/browse/JDK-8262297
> In https://bugs.openjdk.org/browse/JDK-8262297 we added similar change but we didnt allow 15bpp image in BMP, because of which many tests which were using USHORT_555_RGB format were failing as reported at https://bugs.openjdk.org/browse/JDK-8278047
> 
> There is ambiguity on whether we should support 15bpp BMP encoding also or not as captured in JBS : https://bugs.openjdk.org/browse/JDK-8278086?focusedCommentId=14521952&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14521952
> 
> Since adding tighter condition to only allow 0, 1, 4, 8, 16, 24 and 32 bpp is causing many failures. I have modified the check to allow 15bpp also.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Remove biType variable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10419/files
  - new: https://git.openjdk.org/jdk/pull/10419/files/3b2436f5..b5071a02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10419&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10419&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/10419


From jdv at openjdk.org  Mon Sep 26 13:20:37 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 26 Sep 2022 13:20:37 GMT
Subject: RFR: 8278086: [REDO] ImageIO.write() method will throw
 IndexOutOfBoundsException [v2]
In-Reply-To: <HCFSsS_wgXgOGnbRQ0HmbSoJF9ftawNsjCQQxqSZbrg=.6a050270-a6fb-4b60-8551-84162a16b717@github.com>
References: <m6yQDNwg4jCq1vRHp9i-aaiBjutuSMNboon6xAs8UGQ=.162d3d4c-641f-41d1-8392-ce7bbde96613@github.com>
 <HCFSsS_wgXgOGnbRQ0HmbSoJF9ftawNsjCQQxqSZbrg=.6a050270-a6fb-4b60-8551-84162a16b717@github.com>
Message-ID: <I3SprHSfhPmWjPnN7DdhASF634bJQnS33JQBJfLO-dI=.ce91ad16-023a-41ef-a96d-5f42c30993fe@github.com>

On Mon, 26 Sep 2022 12:01:43 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove biType variable
>
> src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java line 1458:
> 
>> 1456:             return false;
>> 1457:         }
>> 1458:         int biType = imgType.getBufferedImageType();
> 
> Can remove biType variable I guess, since its not been used. 
> The fix is tested and verified.

Thanks for verifying the test case. Unused variable is removed.

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

PR: https://git.openjdk.org/jdk/pull/10419


From jdv at openjdk.org  Mon Sep 26 14:07:20 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 26 Sep 2022 14:07:20 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser shouldn't display /../../../..
 in combobox and selection textarea. [v2]
In-Reply-To: <mqsNLbjIXRSTLLlDULdAjcUCkugwc-uUC4g2Rq062qg=.26fec366-1c69-495c-b16c-f762ff556963@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <mqsNLbjIXRSTLLlDULdAjcUCkugwc-uUC4g2Rq062qg=.26fec366-1c69-495c-b16c-f762ff556963@github.com>
Message-ID: <TOAKPJgOlEn-_RlSRVed0Hxd6fhrop2iorMXSGd8RH0=.9f1bb280-2c54-4800-9d99-637648bd91c0@github.com>

On Mon, 26 Sep 2022 06:13:47 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> When a user selects ../ from directory list in GTK FileChooser continuosly, it leads to '../../../.....' in combobox and selection textarea even though it the current directory is at root level.
>> 
>> Fix for the issue is to check if current directory is root then don't process the selection of ' ../ '.
>> 
>> Test case has been added and checked in CI pipeline. Link is attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment added and test case condotion update

What is the behaviour in other LAF's?
Also lets change title of this bug to something like "GTK L&F: JFileChooser can jump beyond root directory in combobox and selection textarea"

src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java line 432:

> 430:         }
> 431: 
> 432:         public void mouseClicked(MouseEvent e) {

Is this issue reproducible only through mouse click event? Can we use key navigation and return button to see same issue? Is button press using keyboard navigation treated as mouseClick event?

test/jdk/javax/swing/JFileChooser/TestFileChooserDirectorySelection.java line 57:

> 55: 
> 56:             robot.waitForIdle();
> 57:             robot.delay(1000);

After robot.setAutoDelay() why we need such large delays in robot at many places?

test/jdk/javax/swing/JFileChooser/TestFileChooserDirectorySelection.java line 102:

> 100: 
> 101:     private static void doubleClickMouse(Point p) {
> 102:         robot.mouseMove(p.x+75, p.y+frame.getHeight()/2 - 90);

We should not use magic numbers to determine location on screen. Will these coordinates hold true at different uiScales?

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

PR: https://git.openjdk.org/jdk/pull/10390


From tr at openjdk.org  Mon Sep 26 14:09:19 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 26 Sep 2022 14:09:19 GMT
Subject: RFR: 8278086: [REDO] ImageIO.write() method will throw
 IndexOutOfBoundsException [v2]
In-Reply-To: <cy1Vkb0CECBWHX0F3DDUdhDFGCKhTZlGZ9y35YGayPo=.144df86a-f0eb-4d1e-9bf2-ccf0955d857d@github.com>
References: <m6yQDNwg4jCq1vRHp9i-aaiBjutuSMNboon6xAs8UGQ=.162d3d4c-641f-41d1-8392-ce7bbde96613@github.com>
 <cy1Vkb0CECBWHX0F3DDUdhDFGCKhTZlGZ9y35YGayPo=.144df86a-f0eb-4d1e-9bf2-ccf0955d857d@github.com>
Message-ID: <OanTFInyvfAGwh3kHwthaY06Ih0JFPQGFgHpuUOCIyg=.b07266b1-0298-4859-9e1f-1781ad1ec50a@github.com>

On Mon, 26 Sep 2022 13:20:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> This is redo of https://bugs.openjdk.org/browse/JDK-8262297
>> In https://bugs.openjdk.org/browse/JDK-8262297 we added similar change but we didnt allow 15bpp image in BMP, because of which many tests which were using USHORT_555_RGB format were failing as reported at https://bugs.openjdk.org/browse/JDK-8278047
>> 
>> There is ambiguity on whether we should support 15bpp BMP encoding also or not as captured in JBS : https://bugs.openjdk.org/browse/JDK-8278086?focusedCommentId=14521952&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14521952
>> 
>> Since adding tighter condition to only allow 0, 1, 4, 8, 16, 24 and 32 bpp is causing many failures. I have modified the check to allow 15bpp also.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove biType variable

Marked as reviewed by tr (Author).

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

PR: https://git.openjdk.org/jdk/pull/10419


From jdv at openjdk.org  Mon Sep 26 15:31:23 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 26 Sep 2022 15:31:23 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
In-Reply-To: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
References: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
Message-ID: <V5rFjImQifoRiRQECLE4obAAwmGDW8JWIwEVbdbdoa8=.8ab84f21-c2ac-4d56-a474-eabb4e883af3@github.com>

On Thu, 22 Sep 2022 06:59:59 GMT, Tejesh R <tr at openjdk.org> wrote:

> The color returned for `InteriorBackground` property is the default color used for only _WindowsClassicLookAndFeel_. For _WindowsLookAndFeel_ the `InteriorBackground` color is not been used when checkbox paint happens. In _WindowsLookAndFeel_ the CheckBox check/uncheck is drawn using `ImageCache` which is totally independent of `InteriorBackground` color in which the user expects it to be.
> The proposed fix is to return null for _WindowsLookAndFeel_ (which is what happens in other LookAndFeel like Metal/Synth/Motif/Aqua ) and return default color which is the actual color used in _WindowsClassicLookAndFeel_.

Spent some time to check where all we are using these properties.
I see that we use "CheckBox.background" for CheckBoxIcon when it is pressed at https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java#L389

Can you check why we use "CheckBox.background" instead of "CheckBox.interiorBackground" in WindowsIconFactory and what is its behaviour in Windows 11?

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java line 661:

> 659: 
> 660:             "CheckBox.font", ControlFont,
> 661:             "CheckBox.interiorBackground", (xp != null)?

Do we return any color other than the default FFFFFF/null?
What is the use of "win.frame.backgroundColor" property when we always return table.get("window")?

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

PR: https://git.openjdk.org/jdk/pull/10385


From jdv at openjdk.org  Mon Sep 26 15:31:26 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 26 Sep 2022 15:31:26 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
In-Reply-To: <CtajpYf1xN-fH1h4Fpy-BQ7QDnRAPj1Dp92o-xMHcQg=.b38cc1d7-7001-4862-be30-c366e4e01b60@github.com>
References: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
 <eyoTId42r1xHmZOGk66wVvNNEdzp1pVhu_nToShIBbQ=.857d3f89-7619-4856-a9df-eb77e880bf57@github.com>
 <CtajpYf1xN-fH1h4Fpy-BQ7QDnRAPj1Dp92o-xMHcQg=.b38cc1d7-7001-4862-be30-c366e4e01b60@github.com>
Message-ID: <6iwztTGyxGUkwytGAZFH6CUgyPupIGjUtCEL73C5x2Y=.608c34b3-7107-4693-8829-ddd4de994550@github.com>

On Mon, 26 Sep 2022 06:03:27 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/javax/swing/JCheckBox/InteriorBackgroundTest.java line 33:
>> 
>>> 31:  * @test
>>> 32:  * @bug 8289539
>>> 33:  * @key headful
>> 
>> Is this test marked headful to load system colors associated with the LAF? 
>> Since we are not displaying anything on screen.
>
> I specified as headful since I'm using JFrame to subclass and change the Look and Feel at Runtime. Not sure if I can make is headless.

Just because we are extending JFrame, i think there is no need to make it headful.
You can remove the @headful tag and see whether it runs in our CI systems.

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

PR: https://git.openjdk.org/jdk/pull/10385


From joehw at openjdk.org  Mon Sep 26 16:16:34 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 26 Sep 2022 16:16:34 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <pGtnJ74g_UpsFiU5TaZ6E9jk1p0koWYtWUaoecRoxxk=.e98efc77-50d4-4959-a289-23e6a54380b8@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

We have discussed several times in the past that we don't touch upstream (in this case, Apache) code unless the change is essential. In general, if you fix a bug in a class, it's fine to fix other non-essential things within the class, such as code styles, javadocs, typos as in this case, etc.  Otherwise, I would suggest you contribute such changes to the upstream projects.  Thanks.

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

PR: https://git.openjdk.org/jdk/pull/10029


From duke at openjdk.org  Mon Sep 26 16:41:42 2022
From: duke at openjdk.org (SWinxy)
Date: Mon, 26 Sep 2022 16:41:42 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
Message-ID: <Kn4w0MAVSML79mjHW-0E4OuGF92CuQ9M5qLOhawWfAA=.2bfefbde-13ac-4b60-b16d-faa9b9d6a553@github.com>

On Wed, 21 Sep 2022 11:52:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:
> 
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes to glext.h
>  - Revert changes to multiVis.c and wsutils.h
>  - Merge branch 'master' into typos-in-java.desktop
>  - Revert changes in libjpeg
>  - Revert changes in libfreetype
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 39 more: https://git.openjdk.org/jdk/compare/cddd6def...2850610d

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

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

PR: https://git.openjdk.org/jdk/pull/8328


From duke at openjdk.org  Mon Sep 26 16:41:42 2022
From: duke at openjdk.org (SWinxy)
Date: Mon, 26 Sep 2022 16:41:42 GMT
Subject: RFR: 8285306: Fix typos in java.desktop [v10]
In-Reply-To: <roNZDEigW_m6kd7yVsQMbEcJaqRMAxOLbppVAiC1gOo=.000515f2-0771-4b10-a59d-80146998bc50@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <UX9H85oAIpBC4A-KWRW7d6KUg8SbYULTIMfMho-wDA8=.d653258a-b326-488d-9183-acc9c0c293dc@github.com>
 <uFQfE9tIok8RZQgHeC5lfNaifh1V1-Sb-QFEJqfzXVc=.eae5e99b-e369-439b-aae3-b83ad0edc407@github.com>
 <j3snodAghZ9TmSwS53ZE_IuOYzIEe77oN9NVqn5EhM0=.d9c9b001-2bc1-4c13-b26b-6faf798620a8@github.com>
 <eHfGEaNx7mjF70YMaihZ2p1fzX7fPvonO2vUmKaGaWM=.53be37da-e844-4908-9b02-0d2e874a0fae@github.com>
 <roNZDEigW_m6kd7yVsQMbEcJaqRMAxOLbppVAiC1gOo=.000515f2-0771-4b10-a59d-80146998bc50@github.com>
Message-ID: <VYecr3WzqkpHiR2aus9V1J03qMSfZTJkypcNAXtQMm4=.cddd5b34-6887-4b8b-8edd-7f6b02c9eba2@github.com>

On Thu, 22 Sep 2022 20:19:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I unfortunately don't have a JBS (yet..), so if you could, that would be amazing.
>
> I think the text is correct here: ?that _**a** Theme_ can support
> 
> `MetalTheme` is a superclass for classes which implement Themes. Thus the constants define fonts which _a particular theme_ may use.

Makes sense.

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

PR: https://git.openjdk.org/jdk/pull/8328


From mernst at openjdk.org  Mon Sep 26 16:51:36 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Mon, 26 Sep 2022 16:51:36 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Reinstate typos in Apache code that is copied into the JDK
 - Merge ../jdk-openjdk into typos-typos
 - Remove file that was removed upstream
 - Fix inconsistency in capitalization
 - Undo change in zlip
 - Fix typos

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

Changes: https://git.openjdk.org/jdk/pull/10029/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=01
  Stats: 85 lines in 76 files changed: 0 ins; 0 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/10029.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029

PR: https://git.openjdk.org/jdk/pull/10029


From joehw at openjdk.org  Mon Sep 26 17:04:25 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 26 Sep 2022 17:04:25 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <tTqHK2uU740KHuTMKapHnLcgfUbNs-4NqM-tQpds9HQ=.ba0b289d-011f-4f84-beeb-e20dd15a7d67@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Thanks for the update!

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

PR: https://git.openjdk.org/jdk/pull/10029


From aivanov at openjdk.org  Mon Sep 26 17:20:21 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 26 Sep 2022 17:20:21 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v21]
In-Reply-To: <u3_r-i91t0JS7esESob9Nc6Ev2vi6UnPOGrkbsJ6p-c=.7430af68-f4ee-4974-b271-a72fce89aed5@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <u3_r-i91t0JS7esESob9Nc6Ev2vi6UnPOGrkbsJ6p-c=.7430af68-f4ee-4974-b271-a72fce89aed5@github.com>
Message-ID: <saEeXBXXGcF1pziH_Oo9ymauVYS2vq__wjO0Y4puM38=.543d00ca-480f-44d2-bb80-ae2f25839509@github.com>

On Wed, 21 Sep 2022 03:29:35 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrects Licence Header.
>   
>   Removes Classpath exception.

test/jdk/javax/swing/text/html/CSS/MissingColorNames.java line 34:

> 32: import javax.swing.text.AttributeSet;
> 33: import javax.swing.text.html.StyleSheet;
> 34: import java.util.Locale;

`Locale` should be after `Color` in the imports list.

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

PR: https://git.openjdk.org/jdk/pull/9825


From aivanov at openjdk.org  Mon Sep 26 17:20:21 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 26 Sep 2022 17:20:21 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v21]
In-Reply-To: <saEeXBXXGcF1pziH_Oo9ymauVYS2vq__wjO0Y4puM38=.543d00ca-480f-44d2-bb80-ae2f25839509@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <u3_r-i91t0JS7esESob9Nc6Ev2vi6UnPOGrkbsJ6p-c=.7430af68-f4ee-4974-b271-a72fce89aed5@github.com>
 <saEeXBXXGcF1pziH_Oo9ymauVYS2vq__wjO0Y4puM38=.543d00ca-480f-44d2-bb80-ae2f25839509@github.com>
Message-ID: <p3glH3pDipUqH0uqbal9bdS1eJv1up2TMTv40VCgpzA=.38bbbcaf-e533-4d12-895c-b1d0f5adccab@github.com>

On Mon, 26 Sep 2022 17:13:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Corrects Licence Header.
>>   
>>   Removes Classpath exception.
>
> test/jdk/javax/swing/text/html/CSS/MissingColorNames.java line 34:
> 
>> 32: import javax.swing.text.AttributeSet;
>> 33: import javax.swing.text.html.StyleSheet;
>> 34: import java.util.Locale;
> 
> `Locale` should be after `Color` in the imports list.

Other than that, it looks fine to me.

I am not sure about the detailed comment of when the test should fail. The thing is the comment will become if the test logic is modified and the comment is not.

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

PR: https://git.openjdk.org/jdk/pull/9825


From shurailine at openjdk.org  Mon Sep 26 18:07:23 2022
From: shurailine at openjdk.org (Alexandre Iline)
Date: Mon, 26 Sep 2022 18:07:23 GMT
Subject: Integrated: 8225012: sanity/client/SwingSet/src/ToolTipDemoTest.java
 fails on Windows
In-Reply-To: <1rb8LBNCEl28QDHvpFScS19N2BP37UKIbc2qyMM33ig=.6957698e-677a-4b5e-bdf1-1f6aa28d4d81@github.com>
References: <1rb8LBNCEl28QDHvpFScS19N2BP37UKIbc2qyMM33ig=.6957698e-677a-4b5e-bdf1-1f6aa28d4d81@github.com>
Message-ID: <u2rZ-s720iv6Z_IJ4Q6168OHBBVNo-MCv42VDdTVP7I=.a535d1fb-f910-4788-b882-30fbc75d6415@github.com>

On Sat, 27 Aug 2022 00:32:11 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> Activate the window with a mouse click.
> Close tooltip by moving the window out of the component.
> 
> Multiple runs have been performed in the CI, totaling 500 runs on each Windows and Mac OS.
> 
> While testing the fix, I have discovered that, while this fixes the problem on Mac and Windows, on linux the test is not fully stable. I have created a bug for that and excluded the test on Linux.

This pull request has now been integrated.

Changeset: 1f521a12
Author:    Alexandre Iline <shurailine at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f521a12041b33b3458f952627d535fad6e928c7
Stats:     16 lines in 2 files changed: 9 ins; 3 del; 4 mod

8225012: sanity/client/SwingSet/src/ToolTipDemoTest.java fails on Windows

Reviewed-by: serb

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

PR: https://git.openjdk.org/jdk/pull/10053


From shurailine at openjdk.org  Mon Sep 26 18:33:40 2022
From: shurailine at openjdk.org (Alexandre Iline)
Date: Mon, 26 Sep 2022 18:33:40 GMT
Subject: RFR: JDK-8294379: Missing comma after copyright year
Message-ID: <7JHHQtZiGymeLYt-BFGNRCQ70zWk9xynY_t5XInIeV0=.3b3981d0-712c-418b-990a-1f5c9206102e@github.com>

Adding comma missed in the original commit.

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

Commit messages:
 - JDK-8294379: Missing comma after copyright year

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

PR: https://git.openjdk.org/jdk/pull/10431


From kcr at openjdk.org  Mon Sep 26 18:33:40 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 26 Sep 2022 18:33:40 GMT
Subject: RFR: JDK-8294379: Missing comma after copyright year
In-Reply-To: <7JHHQtZiGymeLYt-BFGNRCQ70zWk9xynY_t5XInIeV0=.3b3981d0-712c-418b-990a-1f5c9206102e@github.com>
References: <7JHHQtZiGymeLYt-BFGNRCQ70zWk9xynY_t5XInIeV0=.3b3981d0-712c-418b-990a-1f5c9206102e@github.com>
Message-ID: <hRFPg-RoqOeYB6eb5PshVPJzakudfNYBgbQDmEh94SQ=.86a88aca-748c-408d-a0bb-6e989eeb8d35@github.com>

On Mon, 26 Sep 2022 18:24:14 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> Adding comma missed in the original commit.

Looks good.

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

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.org/jdk/pull/10431


From azvegint at openjdk.org  Mon Sep 26 18:33:41 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 26 Sep 2022 18:33:41 GMT
Subject: RFR: JDK-8294379: Missing comma after copyright year
In-Reply-To: <7JHHQtZiGymeLYt-BFGNRCQ70zWk9xynY_t5XInIeV0=.3b3981d0-712c-418b-990a-1f5c9206102e@github.com>
References: <7JHHQtZiGymeLYt-BFGNRCQ70zWk9xynY_t5XInIeV0=.3b3981d0-712c-418b-990a-1f5c9206102e@github.com>
Message-ID: <OZHuIL0NMMYfKu7HkfmVqHI6bgIdUYato8No65gFO3k=.263e36f0-e4ea-43b9-90ba-98f37178a920@github.com>

On Mon, 26 Sep 2022 18:24:14 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> Adding comma missed in the original commit.

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10431


From prr at openjdk.org  Mon Sep 26 18:56:36 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 26 Sep 2022 18:56:36 GMT
Subject: RFR: JDK-8294379: Missing comma after copyright year
In-Reply-To: <7JHHQtZiGymeLYt-BFGNRCQ70zWk9xynY_t5XInIeV0=.3b3981d0-712c-418b-990a-1f5c9206102e@github.com>
References: <7JHHQtZiGymeLYt-BFGNRCQ70zWk9xynY_t5XInIeV0=.3b3981d0-712c-418b-990a-1f5c9206102e@github.com>
Message-ID: <5w1z82uSZjV-85Buh2TMOrqBW7VwWbRXb5OIf_IJB58=.466a4d81-2ea1-4b90-9ba5-96b467e8dd8f@github.com>

On Mon, 26 Sep 2022 18:24:14 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> Adding comma missed in the original commit.

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10431


From shurailine at openjdk.org  Mon Sep 26 19:30:52 2022
From: shurailine at openjdk.org (Alexandre Iline)
Date: Mon, 26 Sep 2022 19:30:52 GMT
Subject: Integrated: JDK-8294379: Missing comma after copyright year
In-Reply-To: <7JHHQtZiGymeLYt-BFGNRCQ70zWk9xynY_t5XInIeV0=.3b3981d0-712c-418b-990a-1f5c9206102e@github.com>
References: <7JHHQtZiGymeLYt-BFGNRCQ70zWk9xynY_t5XInIeV0=.3b3981d0-712c-418b-990a-1f5c9206102e@github.com>
Message-ID: <q67CdcFkVY9rl8YuxgO_8nCCgmAx9Bjhv9l_1hSp-Uk=.48d06d3f-7f44-4780-86c7-43cf57ecb612@github.com>

On Mon, 26 Sep 2022 18:24:14 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> Adding comma missed in the original commit.

This pull request has now been integrated.

Changeset: aca4276e
Author:    Alexandre Iline <shurailine at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aca4276e8938127e7e6a416cfbe325764b2c2e3f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8294379: Missing comma after copyright year

Reviewed-by: kcr, azvegint, prr

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

PR: https://git.openjdk.org/jdk/pull/10431


From lancea at openjdk.org  Mon Sep 26 19:38:20 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 26 Sep 2022 19:38:20 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Thank you for your efforts on the cleaning up these typos

I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review.  

I realize the changes are fairly trivial but this will most likely expedite getting your changes back

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

PR: https://git.openjdk.org/jdk/pull/10029


From aturbanov at openjdk.org  Mon Sep 26 21:12:41 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 26 Sep 2022 21:12:41 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v29]
In-Reply-To: <67J5y7EUu-fv68E35nDZIr7VVFjvhpJQOVpPQ-knbVo=.afe79c4e-8a9c-4146-9fc7-c0d29f211f66@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <67J5y7EUu-fv68E35nDZIr7VVFjvhpJQOVpPQ-knbVo=.afe79c4e-8a9c-4146-9fc7-c0d29f211f66@github.com>
Message-ID: <8HyTZlh3KG49Rz1mqXm8QryD7QTwzY7ESyrxa5C0EE4=.2b4630bd-b327-4feb-858e-87f8d9671f06@github.com>

On Sun, 18 Sep 2022 09:33:42 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

src/java.desktop/share/classes/sun/swing/FilePane.java line 1127:

> 1125:         JFileChooser chooser;
> 1126:         DateFormat df;
> 1127:         final static double baseFileSize = 1000.0;

let's use blessed modifiers order: `static final`

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Mon Sep 26 21:20:54 2022
From: duke at openjdk.org (ScientificWare)
Date: Mon, 26 Sep 2022 21:20:54 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v22]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <BY1Cgckwh4iA2FaUgv5SJBbgcM1V-KFTP8e8okQXJk8=.75da7e57-c703-493f-a83e-258a8122ac80@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

  Import order - Comments
  
  - Corrects import declaration order.
  - Removes comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/0942e727..25acef0e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=20-21

  Stats: 15 lines in 1 file changed: 1 ins; 14 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9825.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9825/head:pull/9825

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Tue Sep 27 02:44:04 2022
From: duke at openjdk.org (ScientificWare)
Date: Tue, 27 Sep 2022 02:44:04 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v6]
In-Reply-To: <MiYK_L_hYq3_D6HdHWSeQ6POVfmjc2KiOiJhetL2uH4=.df7929eb-d6a9-423d-bf0d-0255782d466b@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <592sDW2VIvByGwKDoAYG5P7a4Iygc5CYtPVG7vr9qrk=.12f3db5e-a3a7-41c6-b5f9-e1588507bbe2@github.com>
 <DmaK20O4iPQJGHZyci3IQEsFFbdhnBgMmB4Aok-GE9g=.4884358d-108b-4115-a948-180727268137@github.com>
 <qNrVXI_sLUl_nLStcratdK-OUhBax_v9z2vm7tMDTGs=.7d8763f5-0985-4015-bb29-06b89d44593c@github.com>
 <32gcqBPrkOpDtMLmeh7KGGnXrYf-4VMabEXYPOt0rFY=.8fc58c48-dd7e-4444-9344-7f2ba33bc7a9@github.com>
 <9r8cFmlOw3FVG1jvE974QoOW7Aph9MnUWnj5w44bBR8=.a077b623-99dd-4f8b-83fa-bd6054d7616d@github.com>
 <MiYK_L_hYq3_D6HdHWSeQ6POVfmjc2KiOiJhetL2uH4=.df7929eb-d6a9-423d-bf0d-0255782d466b@github.com>
Message-ID: <H9ZyHAwU7hduXZJoyi9mL_ZmmDx0uO963irsWJfTMVA=.3951ff9b-2aa5-4f7e-bd00-b2bd3752553c@github.com>

On Mon, 26 Sep 2022 11:03:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Could we reach a conciliation with this version. ? All cases are treated in 2 or 3 tests.
>> It incorporates all your suggestions and my single comment about the number of tests.
>> 
>>         if (n < 5) {
>>             if (n < 3) {
>>                 return null;
>>             } else {
>>                 final char r = digits.charAt(0);
>>                 final char g = digits.charAt(1);
>>                 final char b = digits.charAt(2);
>>                 final char a = n == 4 ? digits.charAt(3) : 'f';
>>                 digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$s%4$s%4$s", r, g, b, a);
>>             }
>>         } else if (n < 7) {
>>             if (n == 5) {
>>                 return null;
>>             } else {
>>                 digits = String.format("%sff", digits);
>>             }
>>         } else if (n != 8 ) {
>>             return null;
>>         }
>>         try {
>>             int i = Integer.parseUnsignedInt(digits, 16);
>>             return new Color((i >> 24) & 0xFF, (i >> 16) & 0xFF, (i >> 8) & 0xFF, i & 0xFF);
>>         } catch (NumberFormatException nfe) {
>>             return null;
>>         }
>> 
>> Some articles suggest to avoid using exceptions as flow controls. I never tested this point. That's why I introduced Patterns in this method. May I run tests in this case ? With the code below :
>> 
>>         if (n < 5) {
>>             if (n < 3 || !hex.matcher(digits).matches()) {
>>                 return null;
>>             } else {
>>                 final char r = digits.charAt(0);
>>                 final char g = digits.charAt(1);
>>                 final char b = digits.charAt(2);
>>                 final char a = n == 4 ? digits.charAt(3) : 'f';
>>                 digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$s%4$s%4$s", r, g, b, a);
>>             }
>>         } else if (n < 7) {
>>             if (n == 5 || !hex.matcher(digits).matches()) {
>>                 return null;
>>             } else {
>>                 digits = String.format("%sff", digits);
>>             }
>>         } else if (n != 8 || !hex.matcher(digits).matches()) {
>>             return null;
>>         }
>>         try {
>>             int i = Integer.parseUnsignedInt(digits, 16);
>>             return new Color((i >> 24) & 0xFF, (i >> 16) & 0xFF, (i >> 8) & 0xFF, i & 0xFF);
>>         } catch (NumberFormatException nfe) {
>>             return null;
>>         }
>> 
>> I also wish to test the version with bit rotation too :
>> 
>>         if (n < 5) {
>>             if (n < 3 || !hex.matcher(digits).matches()) {
>>                 return null;
>>             } else {
>>                 final char r = digits.charAt(0);
>>                 final char g = digits.charAt(1);
>>                 final char b = digits.charAt(2);
>>                 final char a = n == 4 ? digits.charAt(3) : 'f';
>>                 digits = String.format("%1$s%1$s%2$s%2$s%3$s%3$s%4$s%4$s", r, g, b, a);
>>             }
>>         } else if (n < 7) {
>>             if (n == 5 || !hex.matcher(digits).matches()) {
>>                 return null;
>>             } else {
>>                 digits = String.format("%sff", digits);
>>             }
>>         } else if (n != 8 || !hex.matcher(digits).matches()) {
>>             return null;
>>         }
>>         try {
>>             return new Color(Integer.rotateRight(Integer.parseUnsignedInt(digits, 16),8),
>>                              true);
>>         } catch (NumberFormatException nfe) {
>>             return null;
>>         }
>
>> Could we reach a conciliation with this version. ? All cases are treated in 2 or 3 tests.
> 
> Your new versions introduce one more condition to each case and make the code more complicated and less clear. I am for concise, clear and readable code. I am against premature optimisation, and it hasn't been proved yet that there's a performance issue.
> 
> Combining the cases of `n == 3` and `n == 4` avoids code duplication by introducing one more comparison to both cases. If this becomes a critical path, JIT could optimise the code.
> 
> As such, I am still for combining these two cases. If you insist, I'm okay with your original code with code duplication. Yet I'd like to eliminate the duplicate code.
> 
>> Some articles suggest to avoid using exceptions as flow controls. I never tested this point. That's why I introduced Patterns in this method.
> 
> It's true, creating an exception object is a somewhat expensive operation. Yet you say, ?_most_ of color notations are correct?, therefore an incorrect color which cannot be parsed is rare, so it's _an exceptional situation_, it is okay to use exceptions in this case. You also say, ?Pattern usage has a significant time cost,? at the same time, you introduce a small time penalty for each and every correct color.
> 
> I think the hex pattern is redundant.
> 
>> I also wish to test the version with bit rotation too :
>> 
>> ```java
>>             return new Color(Integer.rotateRight(Integer.parseUnsignedInt(digits, 16),8),
>>                             true);
>> ```
> 
> It could be not as clear, yet it works.
> 
> May I suggest wrapping the code for `Color` and `rotateRight` arguments?
> 
> 
>             return new Color(
>                     Integer.rotateRight(Integer.parseUnsignedInt(digits, 16),
>                                         8),
>                     true);
> 
> 
> It fits better into 80-column limit. Alternatively, wrap the second parameter of `rotateRight` only:
> 
>             return new Color(Integer.rotateRight(Integer.parseUnsignedInt(digits, 16),
>                                                  8),
>                              true);
> 
> This way it's easier to see how many bits are rotated.

@aivanov-jdk My previous proposition perfectly respected all your suggestions and didn't introduce a new test.

But this discussion should be outdated if you validate this new approach. Performance results came from my repository I mentioned in the header.
- Our previous codes ran in 1 200ms to 1800 ms with `String` + `formatted` + `%n$s` usage.
- They ran in 350ms to 380ms with `String` + `formatted` + `%s` usage.
- And in 100ms to 110ms if we replace `String` + `format` with a string concatenation.
- Now the code below gives the same results in 45ms. Since we control notation length we 
   - can bypass some controls,
   - directly generate the color value,
   - without generate a new string, 
   - and reject a wrong number format without generate any exception.


    static final Color hexToColor(String digits) {
        int st = 0;
        if (digits.startsWith("#")) {
            st = 1;
        }
        // CSS level 4
        // - defines color hex code as #[2 digits Red][2 digits Green][2 digits Blue][2 digits Alpha]. With digit 0 ... f.
        // - allows, webpage passes 3, 4, 6 or 8 digit color code.
        //   - 3 digits #[R][G][B] ........ represents #[RR][GG][BB]FF
        //   - 4 digits #[R][G][B][A] ..... represents #[RR][GG][BB][AA]
        //   - 6 digits #[RR][GG][BB] ..... represents #[RR][GG][BB]FF
        //   - 8 digits #[RR][GG][BB][AA] . represents #[RR][GG][BB][AA]
        //
        // Becareful ! In java.awt.Color hex #[2 digits Alpha][2 digits Red][2 digits Green][2 digits Blue]
        // Comme cette m?thode est d?finie dans CSS, elle doit traiter uniquement le format CSS Leve 4.
        //
        // According notes below the current OpenJDK implementation is
        // - 3 digits #[R][G][B]    represents #[RR][GG][BB]FF
        // - 6 digits #[R][G][B]    represents #[RR][GG][BB]FF
        //
        // Some webpage passes 3 digit color code as in #fff which is
        // decoded as #000FFF resulting in blue background.
        // As per https://www.w3.org/TR/CSS1/#color-units,
        // The three-digit RGB notation (#rgb) is converted into six-digit form
        // (#rrggbb) by replicating digits, not by adding zeros.
        // This makes sure that white (#ffffff) can be specified with the short notation
        // (#fff) and removes any dependencies on the color depth of the display.
        byte[] idseq;
        if ((idseq  = digit.get(Integer.valueOf(digits.length()-st))) == null) {
            // Rejects string argument with a wrong number length.
            return null;
        }
        // Only 3, 4, 6 and 8 digits notations.
        long value = 0;
        // Parses the string argument and build color value
        for(byte i : idseq){
            value *= 16;
            if (i != -1){
                int dv = Character.digit(digits.charAt(st + i),16);
                if (dv < 0) {
                    // Rejects string argument with not a valid digit in the radix-16
                    return null;
                }
                value += dv;
            } else {
                value += 15;
            }
        }
        return new Color((int)value, true);
    }

    // Index of the Digit in the Sequence -1 means f.
    private static Map<Integer, byte[]> digit =
        Map.ofEntries(
            Map.entry(Integer.valueOf(3), new byte[]{-1, -1, 0, 0, 1, 1, 2, 2}),
            Map.entry(Integer.valueOf(4), new byte[]{3, 3, 0, 0, 1, 1, 2, 2}),
            Map.entry(Integer.valueOf(6), new byte[]{-1, -1, 0, 1, 2, 3, 4, 5}),
            Map.entry(Integer.valueOf(8), new byte[]{6, 7, 0, 1, 2, 3, 4, 5})
        );

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

PR: https://git.openjdk.org/jdk/pull/10317


From duke at openjdk.org  Tue Sep 27 03:17:26 2022
From: duke at openjdk.org (ScientificWare)
Date: Tue, 27 Sep 2022 03:17:26 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v10]
In-Reply-To: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
Message-ID: <_29_WvWhzoaKDCRsAplWwmgW4bd2xP0t_PLx8MOhM-Y=.70319c16-3b88-46e0-9024-ac4f768e1ebb@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
> 
> This is tracked in JBS as 
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
> 
> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
> 
> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)

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

  Corrects a value in a message.
  
  A message is added to the result in case of failure only. The updated code does not output the actual value. The tested color is #f12a instead of #f00a.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10317/files
  - new: https://git.openjdk.org/jdk/pull/10317/files/a95d2824..b73bec53

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=08-09

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

PR: https://git.openjdk.org/jdk/pull/10317


From duke at openjdk.org  Tue Sep 27 03:25:57 2022
From: duke at openjdk.org (ScientificWare)
Date: Tue, 27 Sep 2022 03:25:57 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v9]
In-Reply-To: <-hUudp4M4kNHOKAfm-6kq_wQ3ahx7OHEiOHWJbjVtDA=.d8449e0c-cb12-437c-9f5f-c113afb23a7e@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <GWoMl0PpIqFtTWN3pot5Iy9S2ceimXTgYz09oE_r2gE=.3af4fb5b-e4b5-44a1-8fcf-85fbbc1b6c52@github.com>
 <-hUudp4M4kNHOKAfm-6kq_wQ3ahx7OHEiOHWJbjVtDA=.d8449e0c-cb12-437c-9f5f-c113afb23a7e@github.com>
Message-ID: <FBKdB53owlSmv9Cv3QR4wb9Ee3X0IDZ914lSAbJ93CY=.8e708d80-5133-46f1-8391-6a5e0bebd2f2@github.com>

On Mon, 26 Sep 2022 11:11:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplifications of the test.
>>   
>>   Removes individual color tests and only compares the RGB value.
>
> test/jdk/javax/swing/text/html/CSS/Hex3468DigitsColor.java line 44:
> 
>> 42:         // Then expecting 0xaaff1122 from Color.
>> 43:         Color color = styleSheet.stringToColor("#f12a");
>> 44:         result.append("  Test for #f00a");
> 
> Previously, you added a message to `result` in case of failure only, now you always do it. The updated code does not output the actual value.
> 
> The tested color is `#f12a`  instead of `#f00a`.

Done.

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

PR: https://git.openjdk.org/jdk/pull/10317


From tr at openjdk.org  Tue Sep 27 04:36:19 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 27 Sep 2022 04:36:19 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
In-Reply-To: <V5rFjImQifoRiRQECLE4obAAwmGDW8JWIwEVbdbdoa8=.8ab84f21-c2ac-4d56-a474-eabb4e883af3@github.com>
References: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
 <V5rFjImQifoRiRQECLE4obAAwmGDW8JWIwEVbdbdoa8=.8ab84f21-c2ac-4d56-a474-eabb4e883af3@github.com>
Message-ID: <Ptos0-NKuPInYG0w7zNZXL3HOpXkr0a8739rNyYuiAk=.69ef3f3e-ecc8-45a5-b651-5e8935a1b637@github.com>

On Mon, 26 Sep 2022 15:29:19 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Spent some time to check where all we are using these properties. I see that we use "CheckBox.background" for CheckBoxIcon when it is pressed at https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java#L389
> 
> Can you check why we use "CheckBox.background" instead of "CheckBox.interiorBackground" in WindowsIconFactory and what is its behaviour in Windows 11?

<img width="89" alt="CheckBox" src="https://user-images.githubusercontent.com/94159358/192432575-35a56b84-2d64-4aa1-ba5b-ce9f31f640f2.png">

Here Green color is interior background and red is Background. This we can set in WindowsClassic, unlike other Look and Feel.

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

PR: https://git.openjdk.org/jdk/pull/10385


From duke at openjdk.org  Tue Sep 27 04:36:21 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 27 Sep 2022 04:36:21 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser shouldn't display /../../../..
 in combobox and selection textarea. [v2]
In-Reply-To: <TOAKPJgOlEn-_RlSRVed0Hxd6fhrop2iorMXSGd8RH0=.9f1bb280-2c54-4800-9d99-637648bd91c0@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <mqsNLbjIXRSTLLlDULdAjcUCkugwc-uUC4g2Rq062qg=.26fec366-1c69-495c-b16c-f762ff556963@github.com>
 <TOAKPJgOlEn-_RlSRVed0Hxd6fhrop2iorMXSGd8RH0=.9f1bb280-2c54-4800-9d99-637648bd91c0@github.com>
Message-ID: <GzwaG7XclcgsYJfA5jTfqSMzoL6NzhjZ76aFrOvYhRA=.03227a8e-a76b-4e79-a0f2-2f18f1426112@github.com>

On Mon, 26 Sep 2022 14:05:04 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> What is the behaviour in other LAF's?

I have checked in Nimbus and Metal LAF, there is a separate button in both LAF to move to previous directory and it is disabled when current directory is root.

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

PR: https://git.openjdk.org/jdk/pull/10390


From tr at openjdk.org  Tue Sep 27 05:36:28 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 27 Sep 2022 05:36:28 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
In-Reply-To: <V5rFjImQifoRiRQECLE4obAAwmGDW8JWIwEVbdbdoa8=.8ab84f21-c2ac-4d56-a474-eabb4e883af3@github.com>
References: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
 <V5rFjImQifoRiRQECLE4obAAwmGDW8JWIwEVbdbdoa8=.8ab84f21-c2ac-4d56-a474-eabb4e883af3@github.com>
Message-ID: <akO1OGLd99VptsVbAPCFt8qTm_oHv5d0UsY_7nuPboU=.5eaab399-d5ee-4b8e-a6b0-75fec0e292f1@github.com>

On Mon, 26 Sep 2022 15:18:26 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> The color returned for `InteriorBackground` property is the default color used for only _WindowsClassicLookAndFeel_. For _WindowsLookAndFeel_ the `InteriorBackground` color is not been used when checkbox paint happens. In _WindowsLookAndFeel_ the CheckBox check/uncheck is drawn using `ImageCache` which is totally independent of `InteriorBackground` color in which the user expects it to be.
>> The proposed fix is to return null for _WindowsLookAndFeel_ (which is what happens in other LookAndFeel like Metal/Synth/Motif/Aqua ) and return default color which is the actual color used in _WindowsClassicLookAndFeel_.
>
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java line 661:
> 
>> 659: 
>> 660:             "CheckBox.font", ControlFont,
>> 661:             "CheckBox.interiorBackground", (xp != null)?
> 
> Do we return any color other than the default FFFFFF/null?
> What is the use of "win.frame.backgroundColor" property when we always return table.get("window")?

`win.frame.backgroundColor` is key and value is color set for `window`. Default color is FFFFF/null, when it is set by user the color updates.

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

PR: https://git.openjdk.org/jdk/pull/10385


From duke at openjdk.org  Tue Sep 27 06:05:06 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 27 Sep 2022 06:05:06 GMT
Subject: RFR: 6777156: GTK L&F: JFileChooser can jump beyond root directory
 in combobox and selection textarea. [v2]
In-Reply-To: <TOAKPJgOlEn-_RlSRVed0Hxd6fhrop2iorMXSGd8RH0=.9f1bb280-2c54-4800-9d99-637648bd91c0@github.com>
References: <_oBfe_QgJrCclVE_1Wr3i-MgYCztsi6gLvpSbh1fEtE=.74b31236-e722-4921-afc5-1a9fe20c59f6@github.com>
 <mqsNLbjIXRSTLLlDULdAjcUCkugwc-uUC4g2Rq062qg=.26fec366-1c69-495c-b16c-f762ff556963@github.com>
 <TOAKPJgOlEn-_RlSRVed0Hxd6fhrop2iorMXSGd8RH0=.9f1bb280-2c54-4800-9d99-637648bd91c0@github.com>
Message-ID: <ExzRvyeqbKyU775GNxUvTpoOEpGFGuSihklk7HlcAf0=.fa0348e5-dae9-4657-9695-3e36e33b39e8@github.com>

On Mon, 26 Sep 2022 13:55:04 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comment added and test case condotion update
>
> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java line 432:
> 
>> 430:         }
>> 431: 
>> 432:         public void mouseClicked(MouseEvent e) {
> 
> Is this issue reproducible only through mouse click event? Can we use key navigation and return button to see same issue? Is button press using keyboard navigation treated as mouseClick event?

The same issue has been observed in case of key navigation also. we need to handle those scenario where a user is navigating through keys. I will check and update accordingly as we discussed over call.

> test/jdk/javax/swing/JFileChooser/TestFileChooserDirectorySelection.java line 57:
> 
>> 55: 
>> 56:             robot.waitForIdle();
>> 57:             robot.delay(1000);
> 
> After robot.setAutoDelay() why we need such large delays in robot at many places?

I will check this and update.

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

PR: https://git.openjdk.org/jdk/pull/10390


From jdv at openjdk.org  Tue Sep 27 06:14:05 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 27 Sep 2022 06:14:05 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
In-Reply-To: <akO1OGLd99VptsVbAPCFt8qTm_oHv5d0UsY_7nuPboU=.5eaab399-d5ee-4b8e-a6b0-75fec0e292f1@github.com>
References: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
 <V5rFjImQifoRiRQECLE4obAAwmGDW8JWIwEVbdbdoa8=.8ab84f21-c2ac-4d56-a474-eabb4e883af3@github.com>
 <akO1OGLd99VptsVbAPCFt8qTm_oHv5d0UsY_7nuPboU=.5eaab399-d5ee-4b8e-a6b0-75fec0e292f1@github.com>
Message-ID: <YgeRyFVpXUvoG0LcKoqHkwDVw44NEaVNv2DClYe4Ldo=.5cebf4de-cdb5-4a11-9bd2-8f56d8256e24@github.com>

On Tue, 27 Sep 2022 05:34:27 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java line 661:
>> 
>>> 659: 
>>> 660:             "CheckBox.font", ControlFont,
>>> 661:             "CheckBox.interiorBackground", (xp != null)?
>> 
>> Do we return any color other than the default FFFFFF/null?
>> What is the use of "win.frame.backgroundColor" property when we always return table.get("window")?
>
> `win.frame.backgroundColor` is key and value is color set for `window`. Default color is FFFFF/null, when it is set by user the color updates.

>From WindowsDesktopProperty.java constructor it looks like these are not key value pairs. Similar observation is there in DesktopProperty.java.
It looks like table.get("window") is fallback when win.frame.backgroundColor is null.

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

PR: https://git.openjdk.org/jdk/pull/10385


From tr at openjdk.org  Tue Sep 27 06:21:25 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 27 Sep 2022 06:21:25 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
In-Reply-To: <YgeRyFVpXUvoG0LcKoqHkwDVw44NEaVNv2DClYe4Ldo=.5cebf4de-cdb5-4a11-9bd2-8f56d8256e24@github.com>
References: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
 <V5rFjImQifoRiRQECLE4obAAwmGDW8JWIwEVbdbdoa8=.8ab84f21-c2ac-4d56-a474-eabb4e883af3@github.com>
 <akO1OGLd99VptsVbAPCFt8qTm_oHv5d0UsY_7nuPboU=.5eaab399-d5ee-4b8e-a6b0-75fec0e292f1@github.com>
 <YgeRyFVpXUvoG0LcKoqHkwDVw44NEaVNv2DClYe4Ldo=.5cebf4de-cdb5-4a11-9bd2-8f56d8256e24@github.com>
Message-ID: <mRi9n9ZTwb6q3MsnyHlp7XtK98MkjPMtT_KNXOMQwHM=.0b99fc55-c2ad-49d5-b349-84ce08b5ed2e@github.com>

On Tue, 27 Sep 2022 06:10:07 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> `win.frame.backgroundColor` is key and value is color set for `window`. Default color is FFFFF/null, when it is set by user the color updates.
>
> From WindowsDesktopProperty.java constructor it looks like these are not key value pairs. Similar observation is there in DesktopProperty.java.
> It looks like table.get("window") is fallback when win.frame.backgroundColor is null.

Ok, but we are not modifying `win.frame.backgroundColor` property, only` "CheckBox.interiorBackground"` is been set to null. `WindowBackgroundColor` is also used in other properties, so nothing is modified except ` "CheckBox.interiorBackground"`.

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

PR: https://git.openjdk.org/jdk/pull/10385


From jdv at openjdk.org  Tue Sep 27 07:30:21 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 27 Sep 2022 07:30:21 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
In-Reply-To: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
References: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
Message-ID: <O0YUus64oGQkkS8tSQ5Qkc5oAiyzG9w7dMoMdyhCqy8=.8d403eae-1700-47f6-bffd-7517c6d9fd61@github.com>

On Thu, 22 Sep 2022 06:59:59 GMT, Tejesh R <tr at openjdk.org> wrote:

> The color returned for `InteriorBackground` property is the default color used for only _WindowsClassicLookAndFeel_. For _WindowsLookAndFeel_ the `InteriorBackground` color is not been used when checkbox paint happens. In _WindowsLookAndFeel_ the CheckBox check/uncheck is drawn using `ImageCache` which is totally independent of `InteriorBackground` color in which the user expects it to be.
> The proposed fix is to return null for _WindowsLookAndFeel_ (which is what happens in other LookAndFeel like Metal/Synth/Motif/Aqua ) and return default color which is the actual color used in _WindowsClassicLookAndFeel_.

We use GetSysColor(https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsyscolor) to set different values for desktop properties at https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_DesktopProperties.cpp#L511

We store these values(or some default value if desktop property is null) as shown at : https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java#L508

And then map them to individual UI components like checkbox: https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java#L660

>From https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsyscolor we can see that some parameters are not supported in particular windows platforms.

I think we should find out whether there is any way to get proper interior background color or need to map to different Desktop  color property in some platforms. If there is no way to get appropriate interior background color then we may return null after analysis. Just because we are returning null in other LAF's we should not right away return null here, it needs more analysis.

Useful link about how Windows desktop properties are mapped : https://docs.oracle.com/javase/8/docs/technotes/guides/swing/1.4/w2k_props.html

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

PR: https://git.openjdk.org/jdk/pull/10385


From tr at openjdk.org  Tue Sep 27 08:10:18 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 27 Sep 2022 08:10:18 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
In-Reply-To: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
References: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
Message-ID: <aMdA20iXovcqzi8MbKQq0f_DoCDPwOhS832nF0bbZik=.b8c41edf-e7f8-45a3-8aa1-85b640febd74@github.com>

On Thu, 22 Sep 2022 06:59:59 GMT, Tejesh R <tr at openjdk.org> wrote:

> The color returned for `InteriorBackground` property is the default color used for only _WindowsClassicLookAndFeel_. For _WindowsLookAndFeel_ the `InteriorBackground` color is not been used when checkbox paint happens. In _WindowsLookAndFeel_ the CheckBox check/uncheck is drawn using `ImageCache` which is totally independent of `InteriorBackground` color in which the user expects it to be.
> The proposed fix is to return null for _WindowsLookAndFeel_ (which is what happens in other LookAndFeel like Metal/Synth/Motif/Aqua ) and return default color which is the actual color used in _WindowsClassicLookAndFeel_.

> 

In other L&F there is no such `checkbox.interiorBackground` property hence it is null value when user tries to access it. In windows since in Classic its been used, that property exist for windowsL&F also (Which is not using that property). And also in Windows L&F I couldn't find a way to change the interior background of checkbox as in WindowsClassic, since the image is painted using ImageCache.

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

PR: https://git.openjdk.org/jdk/pull/10385


From jdv at openjdk.org  Tue Sep 27 08:35:27 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 27 Sep 2022 08:35:27 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
In-Reply-To: <aMdA20iXovcqzi8MbKQq0f_DoCDPwOhS832nF0bbZik=.b8c41edf-e7f8-45a3-8aa1-85b640febd74@github.com>
References: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
 <aMdA20iXovcqzi8MbKQq0f_DoCDPwOhS832nF0bbZik=.b8c41edf-e7f8-45a3-8aa1-85b640febd74@github.com>
Message-ID: <QHIX0ayh5itGR9GGAuDXjnVejXACShIs8m3eXdhBWG8=.77bf10b6-aec4-42ed-bc35-7a026df8bad1@github.com>

On Tue, 27 Sep 2022 08:08:01 GMT, Tejesh R <tr at openjdk.org> wrote:

> > 
> 
> In other L&F there is no such `checkbox.interiorBackground` property hence it is null value when user tries to access it. In windows since in Classic its been used, that property exist for windowsL&F also (Which is not using that property). And also in Windows L&F I couldn't find a way to change the interior background of checkbox as in WindowsClassic, since the image is painted using ImageCache.

>From where the ImageCache knows that it needs to draw/use blue bitmap for checkbox.interiorBackground for Windows 11?

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

PR: https://git.openjdk.org/jdk/pull/10385


From tr at openjdk.org  Tue Sep 27 08:45:18 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 27 Sep 2022 08:45:18 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
In-Reply-To: <QHIX0ayh5itGR9GGAuDXjnVejXACShIs8m3eXdhBWG8=.77bf10b6-aec4-42ed-bc35-7a026df8bad1@github.com>
References: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
 <aMdA20iXovcqzi8MbKQq0f_DoCDPwOhS832nF0bbZik=.b8c41edf-e7f8-45a3-8aa1-85b640febd74@github.com>
 <QHIX0ayh5itGR9GGAuDXjnVejXACShIs8m3eXdhBWG8=.77bf10b6-aec4-42ed-bc35-7a026df8bad1@github.com>
Message-ID: <yWH7Tgg_9xWnCs0osyFWpkLumBioJ8iht0y1EIJsfW8=.c04996a6-861a-414c-a6d7-03ec00d5d843@github.com>

On Tue, 27 Sep 2022 08:33:00 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> > > 
> > 
> > 
> > In other L&F there is no such `checkbox.interiorBackground` property hence it is null value when user tries to access it. In windows since in Classic its been used, that property exist for windowsL&F also (Which is not using that property). And also in Windows L&F I couldn't find a way to change the interior background of checkbox as in WindowsClassic, since the image is painted using ImageCache.
> 
> From where the ImageCache knows that it needs to draw/use blue bitmap for checkbox.interiorBackground for Windows 11?

Couldn't find the exact source, but was able to verify while debugging in `PaintSkin() ` where checkBox check/uncheck was handled by using `ImageBuffer` where it just toggle the image for check and uncheck in windows L&F. This image in windows10 and windows11  differs in interior background color.

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

PR: https://git.openjdk.org/jdk/pull/10385


From jdv at openjdk.org  Tue Sep 27 09:04:13 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 27 Sep 2022 09:04:13 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
In-Reply-To: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
References: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
Message-ID: <KOWLHbOsuTOTatNbamvhzHtB3vuiUi9s3790VwhwSR4=.ce916861-224f-4ee1-a9bf-24778eddd9c2@github.com>

On Thu, 22 Sep 2022 06:59:59 GMT, Tejesh R <tr at openjdk.org> wrote:

> The color returned for `InteriorBackground` property is the default color used for only _WindowsClassicLookAndFeel_. For _WindowsLookAndFeel_ the `InteriorBackground` color is not been used when checkbox paint happens. In _WindowsLookAndFeel_ the CheckBox check/uncheck is drawn using `ImageCache` which is totally independent of `InteriorBackground` color in which the user expects it to be.
> The proposed fix is to return null for _WindowsLookAndFeel_ (which is what happens in other LookAndFeel like Metal/Synth/Motif/Aqua ) and return default color which is the actual color used in _WindowsClassicLookAndFeel_.

> 

There are multiple ImageCache/ImageBuffer pointers, Please point to github source code. I think we should find how this ImageCache knows why it should use "blue" colored bitmap and try to replicate the same for interiorBackgroundColor property. Since we don't have such property in other LAF's, we should avoid replicating same behaviour(of returning null) in Windows LAF.

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

PR: https://git.openjdk.org/jdk/pull/10385


From tr at openjdk.org  Tue Sep 27 10:07:23 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 27 Sep 2022 10:07:23 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
In-Reply-To: <KOWLHbOsuTOTatNbamvhzHtB3vuiUi9s3790VwhwSR4=.ce916861-224f-4ee1-a9bf-24778eddd9c2@github.com>
References: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
 <KOWLHbOsuTOTatNbamvhzHtB3vuiUi9s3790VwhwSR4=.ce916861-224f-4ee1-a9bf-24778eddd9c2@github.com>
Message-ID: <Sq19Xptu7KJqz715FuOTnqGqTO32G9WgsxE7bd5Lqg8=.bba56751-62f7-4517-ac6a-30d78d318e9d@github.com>

On Tue, 27 Sep 2022 09:00:35 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> > 
> 
> There are multiple ImageCache/ImageBuffer pointers, Please point to github source code. I think we should find how this ImageCache knows why it should use "blue" colored bitmap and try to replicate the same for interiorBackgroundColor property. Since we don't have such property in other LAF's, we should avoid replicating same behaviour(of returning null) in Windows LAF.

https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/swing/CachedPainter.java#L205
Here in `Image image = cache.getImage(key, config, w, h, args);` the image is been returned.

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

PR: https://git.openjdk.org/jdk/pull/10385


From duke at openjdk.org  Tue Sep 27 11:18:28 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Tue, 27 Sep 2022 11:18:28 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v13]
In-Reply-To: <Drs_ayWoNKbaYD_kD18P3QgZd0cqNLnLIixjulgJc0g=.aa1aa625-62a4-4c27-ab68-22deca82650b@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <Drs_ayWoNKbaYD_kD18P3QgZd0cqNLnLIixjulgJc0g=.aa1aa625-62a4-4c27-ab68-22deca82650b@github.com>
Message-ID: <jlXAMRmnih15C77iNLDRBnGIPMhZ9xm12nhE7nK6KJ4=.557bfeda-7430-40ed-879a-7ba943ddbb83@github.com>

On Fri, 5 Aug 2022 12:59:48 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix italic and bold styles for colored outline glyphs

?

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

PR: https://git.openjdk.org/jdk/pull/4798


From psadhukhan at openjdk.org  Tue Sep 27 11:23:56 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 27 Sep 2022 11:23:56 GMT
Subject: RFR: 5080391: ArrayIndexOutOfBounds during "undo" of Right-to-Left
 text insert
Message-ID: <6RcEPyVsdn3GAryyi2QYk3OGfPDUGxFD-W0c_2s8iH4=.b10fa89b-07b7-4e8b-858f-1311d0ffeaae@github.com>

javax.swing.text.AbstractDocument$BranchElement.replace(...) method throws an `ArrayIndexOutOfBoundsException: arraycopy: length -1 is negative` when using an UndoManager on the default document of a JTextArea and you try to undo the insertion of a LEFT-TO-RIGHT language (e.g. Arabic) that is immediately followed by setting the component orientation on the JTextArea.

This is because System.arrayCopy() is called with -ve length because of the calculation done in AbstractDocment.replace where `src` is of 2bytes because of unicode text causing `nmove` to become -ve if `nchildren` is 1 (an unicode character is inserted)

System.arrayCopy throws `IndexOutOfBoundsException if:

    The srcPos argument is negative.
    The destPos argument is negative.
    The length argument is negative


so the fix is made to make  nmove, src, dest +ve
Also, Element.getElement() can return null which is not checked, causing NPE, if deletion of text is done which results in no element, which is also fixed in the PR

All jtreg testsuite tests are run without any regression.

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

Commit messages:
 - Test fix
 - 5080391: ArrayIndexOutOfBounds during undo of Left-to-Right text insert

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

PR: https://git.openjdk.org/jdk/pull/10446


From prappo at openjdk.org  Tue Sep 27 11:52:57 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 27 Sep 2022 11:52:57 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited
Message-ID: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>

This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.

JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.

That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.

To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:

    public class Subtype extends Supertype {

        @Override
        public void m() throws SuperException {
    ...

    public class Supertype {

        /**
         * @throws SuperException general problem
         * @throws SubExceptionA  specific problem A
         * @throws SubExceptionB  specific problem B
         */
        public void m() throws SuperException {
    ...

    public class SuperException extends Exception {
    ...

    public class SubExceptionA extends SuperException {
    ...

    public class SubExceptionB extends SuperException {
    ...

For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:

    public void m()
           throws SuperException

    Overrides:
        m in class Supertype
    Throws:
        SuperException - general problem
        SubExceptionA - specific problem A
        SubExceptionB - specific problem B 

It works for checked and unchecked exceptions, for methods in classes and interfaces.


If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.

Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.


[^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
[^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/10449/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10449&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294377
  Stats: 322 lines in 15 files changed: 311 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10449.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10449/head:pull/10449

PR: https://git.openjdk.org/jdk/pull/10449


From duke at openjdk.org  Tue Sep 27 11:56:53 2022
From: duke at openjdk.org (Nikita Provotorov)
Date: Tue, 27 Sep 2022 11:56:53 GMT
Subject: RFR: 8294426: Two fingers tap generates wrong mouse modifiers on M2
 MacBooks
Message-ID: <pMlDVWhwKtrWEeQ8aAEn-VRS7zkyOkXQ5IgKfngbsPk=.026a62ec-72ac-4d9a-88b0-21b1c02a2676@github.com>

Hi there!
JetBrains has faced with a bug on Apple M2 MacBooks when tapping (_not_ pressing) with two fingers on a trackpad generates wrong mouse modifiers (which are returned by [MouseEvent.getModifiersEx](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx())).

As far as I see, OpenJDK bug tracker still doesn't contain such a bug and I don't have rights to create a new one, so the PR doesn't refer any id. Here is the bug link from the JetBrains own tracker: [JBR-4765](https://youtrack.jetbrains.com/issue/JBR-4765/Cannot-invoke-context-menu-by-two-fingers-tapping-on-MacBook-with-M2-chip).

The bug is 100% reproducible on M2 MacBooks (at least under macOS 12.5). It's also reproducible on M1 MacBooks, but much more rarely (about 10-15% of reproducibility).

## Steps to reproduce
1. Enable `System Preferences` -> `Trackpad` -> `Tap to click`
2. Tap with two fingers in the following app:

import javax.swing.*;
import java.awt.event.MouseAdapter;
import java.awt.event.MouseEvent;

class MouseWindow {
    final JFrame frame;

    MouseWindow() {
        frame = new JFrame();
        frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);

        frame.setTitle("Mouse window");

        frame.addMouseListener(new MouseAdapter() {
            @Override
            public void mousePressed(MouseEvent e) {
                System.out.println(e);
            }
        });

        frame.pack();

        frame.setSize(300, 300);

        frame.setVisible(true);
    }

    public static void main(String[] args) {
        SwingUtilities.invokeLater(MouseWindow::new);
    }
}


### Expected
Printed mouse event has `modifiersEx` is `4096` (which is `InputEvent.BUTTON3_DOWN_MASK`)

### Actual
Printed mouse event has `modifiersEx` is `4352` (which is `InputEvent.BUTTON3_DOWN_MASK | InputEvent.META_DOWN_MASK`)

## Evaluation
The following happens when a native mouse event reaches Java:
1. `NSEvent.nsToJavaModifiers(0)` called inside [CPlatformResponder.handleMouseEvent():81](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java#L81) returns `0`. Earlier it always returned `4096` (`InputEvent.BUTTON3_DOWN_MASK`) but not in the cases of M2 tapping. For a trackpad press (not a tap) it still returns `4096`;
2. So, the `0` modifier comes into MouseEvent constructor which then [goes into MouseEvent.setOldModifiers()](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L800) which [initializes the field MouseEvent.modifiers to the value 4](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L1159) (it's `InputEvent.BUTTON3_MASK`);
3. Next, this constructed `MouseEvent` object is pushed into EDT queue.
4. Next, when a EDT thread pulls the event from the queue and starts to process it, it goes into `java.awt.LightweightDispatcher.retargetMouseEvent` and [creates a new MouseEvent based on the pulled one](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/Container.java#L4920) with the new value of the modifiers == `getModifiersEx() | getModifiers()`. From the p.2 we know, that `MouseEvent.modifiers` of the pulled event is `4`, so `getModifiersEx() | getModifiers()` is evaluated to `4`.
5. Next, the constructor of the new MouseEvent [goes into setNewModifiers()](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L795) (instead of `setOldModifiers` as in p.2) and initializes its own field modifiers to the value `4356` (`InputEvent.BUTTON3_MASK | InputEvent.BUTTON3_DOWN_MASK | InputEvent.META_DOWN_MASK`, see [setNewModifiers():1099](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L1099), [setNewModifiers():1129](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L1129)).
6. Thus, an app receives the instance of MouseEvent with `getModifiers()` == `4` and `getModifiersEx()` == `4352` so it thinks there is a `Command` keystroke.

## Fixing
Let's set manually inside `CPlatformResponder.handleMouseEvent` a mouse modifier which corresponds to the pressed button.

## What about a regression test
I've failed to write a regression test using Robot because it somehow forces the correct mouse modifiers (`NSEvent.nsToJavaModifiers()` correctly returns `InputEvent.BUTTON3_DOWN_MASK`), so I wrote a test that directly invokes `CPlatformResponder.handleMouseEvent` via reflection.

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

Commit messages:
 - 8294426: Two fingers tap generates wrong mouse modifiers on M2 MacBooks

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

PR: https://git.openjdk.org/jdk/pull/10429


From mkartashev at openjdk.org  Tue Sep 27 11:56:53 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Tue, 27 Sep 2022 11:56:53 GMT
Subject: RFR: 8294426: Two fingers tap generates wrong mouse modifiers on
 M2 MacBooks
In-Reply-To: <pMlDVWhwKtrWEeQ8aAEn-VRS7zkyOkXQ5IgKfngbsPk=.026a62ec-72ac-4d9a-88b0-21b1c02a2676@github.com>
References: <pMlDVWhwKtrWEeQ8aAEn-VRS7zkyOkXQ5IgKfngbsPk=.026a62ec-72ac-4d9a-88b0-21b1c02a2676@github.com>
Message-ID: <Qv6c1UWHIMbuGEy000Cn_LXWxJEwXA9LCqPArzOBScw=.b506ae71-e32c-447c-b23c-ea4d813d5060@github.com>

On Mon, 26 Sep 2022 17:36:04 GMT, Nikita Provotorov <duke at openjdk.org> wrote:

> Hi there!
> JetBrains has faced with a bug on Apple M2 MacBooks when tapping (_not_ pressing) with two fingers on a trackpad generates wrong mouse modifiers (which are returned by [MouseEvent.getModifiersEx](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx())).
> 
> As far as I see, OpenJDK bug tracker still doesn't contain such a bug and I don't have rights to create a new one, so the PR doesn't refer any id. Here is the bug link from the JetBrains own tracker: [JBR-4765](https://youtrack.jetbrains.com/issue/JBR-4765/Cannot-invoke-context-menu-by-two-fingers-tapping-on-MacBook-with-M2-chip).
> 
> The bug is 100% reproducible on M2 MacBooks (at least under macOS 12.5). It's also reproducible on M1 MacBooks, but much more rarely (about 10-15% of reproducibility).
> 
> ## Steps to reproduce
> 1. Enable `System Preferences` -> `Trackpad` -> `Tap to click`
> 2. Tap with two fingers in the following app:
> 
> import javax.swing.*;
> import java.awt.event.MouseAdapter;
> import java.awt.event.MouseEvent;
> 
> class MouseWindow {
>     final JFrame frame;
> 
>     MouseWindow() {
>         frame = new JFrame();
>         frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
> 
>         frame.setTitle("Mouse window");
> 
>         frame.addMouseListener(new MouseAdapter() {
>             @Override
>             public void mousePressed(MouseEvent e) {
>                 System.out.println(e);
>             }
>         });
> 
>         frame.pack();
> 
>         frame.setSize(300, 300);
> 
>         frame.setVisible(true);
>     }
> 
>     public static void main(String[] args) {
>         SwingUtilities.invokeLater(MouseWindow::new);
>     }
> }
> 
> 
> ### Expected
> Printed mouse event has `modifiersEx` is `4096` (which is `InputEvent.BUTTON3_DOWN_MASK`)
> 
> ### Actual
> Printed mouse event has `modifiersEx` is `4352` (which is `InputEvent.BUTTON3_DOWN_MASK | InputEvent.META_DOWN_MASK`)
> 
> ## Evaluation
> The following happens when a native mouse event reaches Java:
> 1. `NSEvent.nsToJavaModifiers(0)` called inside [CPlatformResponder.handleMouseEvent():81](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java#L81) returns `0`. Earlier it always returned `4096` (`InputEvent.BUTTON3_DOWN_MASK`) but not in the cases of M2 tapping. For a trackpad press (not a tap) it still returns `4096`;
> 2. So, the `0` modifier comes into MouseEvent constructor which then [goes into MouseEvent.setOldModifiers()](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L800) which [initializes the field MouseEvent.modifiers to the value 4](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L1159) (it's `InputEvent.BUTTON3_MASK`);
> 3. Next, this constructed `MouseEvent` object is pushed into EDT queue.
> 4. Next, when a EDT thread pulls the event from the queue and starts to process it, it goes into `java.awt.LightweightDispatcher.retargetMouseEvent` and [creates a new MouseEvent based on the pulled one](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/Container.java#L4920) with the new value of the modifiers == `getModifiersEx() | getModifiers()`. From the p.2 we know, that `MouseEvent.modifiers` of the pulled event is `4`, so `getModifiersEx() | getModifiers()` is evaluated to `4`.
> 5. Next, the constructor of the new MouseEvent [goes into setNewModifiers()](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L795) (instead of `setOldModifiers` as in p.2) and initializes its own field modifiers to the value `4356` (`InputEvent.BUTTON3_MASK | InputEvent.BUTTON3_DOWN_MASK | InputEvent.META_DOWN_MASK`, see [setNewModifiers():1099](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L1099), [setNewModifiers():1129](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L1129)).
> 6. Thus, an app receives the instance of MouseEvent with `getModifiers()` == `4` and `getModifiersEx()` == `4352` so it thinks there is a `Command` keystroke.
> 
> ## Fixing
> Let's set manually inside `CPlatformResponder.handleMouseEvent` a mouse modifier which corresponds to the pressed button.
> 
> ## What about a regression test
> I've failed to write a regression test using Robot because it somehow forces the correct mouse modifiers (`NSEvent.nsToJavaModifiers()` correctly returns `InputEvent.BUTTON3_DOWN_MASK`), so I wrote a test that directly invokes `CPlatformResponder.handleMouseEvent` via reflection.

I filed https://bugs.openjdk.org/browse/JDK-8294426 for this issue.

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

PR: https://git.openjdk.org/jdk/pull/10429


From prappo at openjdk.org  Tue Sep 27 12:14:23 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 27 Sep 2022 12:14:23 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
Message-ID: <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>

> This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.
> 
> JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.
> 
> That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.
> 
> To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:
> 
>     public class Subtype extends Supertype {
> 
>         @Override
>         public void m() throws SuperException {
>     ...
> 
>     public class Supertype {
> 
>         /**
>          * @throws SuperException general problem
>          * @throws SubExceptionA  specific problem A
>          * @throws SubExceptionB  specific problem B
>          */
>         public void m() throws SuperException {
>     ...
> 
>     public class SuperException extends Exception {
>     ...
> 
>     public class SubExceptionA extends SuperException {
>     ...
> 
>     public class SubExceptionB extends SuperException {
>     ...
> 
> For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:
> 
>     public void m()
>            throws SuperException
> 
>     Overrides:
>         m in class Supertype
>     Throws:
>         SuperException - general problem
>         SubExceptionA - specific problem A
>         SubExceptionB - specific problem B 
> 
> It works for checked and unchecked exceptions, for methods in classes and interfaces.
> 
> 
> If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.
> 
> Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.
> 
> 
> [^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
> [^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  revert an extraneous change to jdk.javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10449/files
  - new: https://git.openjdk.org/jdk/pull/10449/files/87bdbff4..d303f5ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10449&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10449&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/10449


From duke at openjdk.org  Tue Sep 27 16:02:22 2022
From: duke at openjdk.org (aLiEnHeAd13)
Date: Tue, 27 Sep 2022 16:02:22 GMT
Subject: RFR: JDK-4305789: BasicToolBarUI: Request conversion of private
 instance variable
Message-ID: <N5UboF5_zFk9rHep_NHX3W2BOQS_VLVRFCPJogIEbuE=.abf3564e-c68f-42a1-b053-dfa0859fac52@github.com>

Fixed Bug JDK-4305789 to support docking to any instantiated JFrame https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4305789

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

Commit messages:
 - Update BasicToolBarUI.java

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

PR: https://git.openjdk.org/jdk/pull/10309


From kcr at openjdk.org  Tue Sep 27 16:15:21 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 27 Sep 2022 16:15:21 GMT
Subject: RFR: JDK-4305789: BasicToolBarUI: Request conversion of private
 instance variable
In-Reply-To: <N5UboF5_zFk9rHep_NHX3W2BOQS_VLVRFCPJogIEbuE=.abf3564e-c68f-42a1-b053-dfa0859fac52@github.com>
References: <N5UboF5_zFk9rHep_NHX3W2BOQS_VLVRFCPJogIEbuE=.abf3564e-c68f-42a1-b053-dfa0859fac52@github.com>
Message-ID: <mDEzCcuCsMHAtnpTVLvQ-pkIqoR2NvrxPxWGRSo1Nmg=.6fe53b70-666d-4836-a9a8-10a7f95619d1@github.com>

On Fri, 16 Sep 2022 13:47:41 GMT, aLiEnHeAd13 <duke at openjdk.org> wrote:

> Fixed Bug JDK-4305789 to support docking to any instantiated JFrame https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4305789

This PR is premature, since it adds public API without any discussion on what adding and supporting that public API would entail. At a minimum, it needs to be discussed on the client-libs-dev mailing list, and if the idea is accepted, it will need a CSR.

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

PR: https://git.openjdk.org/jdk/pull/10309


From aivanov at openjdk.org  Tue Sep 27 17:49:22 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 27 Sep 2022 17:49:22 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v3]
In-Reply-To: <4VvhgKSAGDnjWdmTfvaNCcTsSmOmCQR8UsYNOSmRO5w=.be1165bd-2d1f-44bc-8027-3ae9923617ce@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
 <4VvhgKSAGDnjWdmTfvaNCcTsSmOmCQR8UsYNOSmRO5w=.be1165bd-2d1f-44bc-8027-3ae9923617ce@github.com>
Message-ID: <0L_qtZSknxD6lrlKTqn3f3U2WGYlCIIN2psEZ-dp0Yw=.6ae3b3ad-909d-4959-94ff-59759e79e799@github.com>

On Tue, 13 Sep 2022 07:49:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Label.foreground UIProperty is not honored by Nimbus L&F.
>> Added support for setting JLabel foreground color for Nimbus L&F
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get color once during init

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLabelUI.java line 222:

> 220:             if (fgColor != null) {
> 221:                 label.setForeground(fgColor);
> 222:             }

Why is the color set to the `label` component during paint?

Shouldn't it be `g.setColor(fgColor)`? And the above code which uses the `context` should be skipped if `fgColor != null`.

test/jdk/javax/swing/plaf/nimbus/TestNimbusLabel.java line 48:

> 46:     private static JLabel label;
> 47:     private static JFrame frame;
> 48:     private static boolean passed = false;

`passed` could be local variable in `main`.

`label` could also be local variable inside the lambda expression which creates the UI.

test/jdk/javax/swing/plaf/nimbus/TestNimbusLabel.java line 75:

> 73:                 frame = new JFrame();
> 74:                 UIManager.getDefaults().put("Label.foreground",
> 75:                                             java.awt.Color.red);

You import `Color` class, there's no need to specify the full class name. You should use `RED` as constants are in upper case.

test/jdk/javax/swing/plaf/nimbus/TestNimbusLabel.java line 97:

> 95:                     System.out.println("color(" + x + "," + y + ")=" +
> 96:                                         robot.getPixelColor(x, y));
> 97:                     Color color = robot.getPixelColor(x, y);

Suggestion:

                    Color color = robot.getPixelColor(x, y);
                    System.out.println("color(" + x + "," + y + ")=" +
                                        color);

test/jdk/javax/swing/plaf/nimbus/TestNimbusLabel.java line 98:

> 96:                                         robot.getPixelColor(x, y));
> 97:                     Color color = robot.getPixelColor(x, y);
> 98:                     if (checkPixel(color)) {

I wonder if disabling text antialiasing would yield a simpler code in `checkPixel`? However, it cannot be disabled on macOS which still uses grayscale antialiasing. But for Windows and Linux, it should help. Or the test could be limited to Windows and Linux.

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

PR: https://git.openjdk.org/jdk/pull/9900


From aivanov at openjdk.org  Tue Sep 27 18:06:24 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 27 Sep 2022 18:06:24 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v3]
In-Reply-To: <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>
Message-ID: <LoHGNYNKkAJxYX1seVVdAnSXJe-_dFBDmVMivwad5PM=.c21bd6a5-4f0d-4571-a237-607bf463cb99@github.com>

On Wed, 7 Sep 2022 16:23:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Default echo character obtained through `PasswordField.echoChar` UIProperty returns null for Nimbus L&F,
>> which is fixed by adding the default character * in the UIDefault table.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Honour PasswordField.echoChar property

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthPasswordFieldUI.java line 77:

> 75:             LookAndFeel.installProperty(getComponent(), "echoChar", echoChar);
> 76:         }
> 77:     }

This is a public API class, it should provide a Javadoc, the text copied from `BasicPasswordFieldUI.installDefaults` which does the same thing should be enough.

I agree with @turbanoff, let's add a space after `if`.

Let's also add `@Override` annotation which are used on the methods above and below at the very least.

test/jdk/javax/swing/plaf/nimbus/PasswordFieldTest.java line 50:

> 48:                             UIManager.getInstalledLookAndFeels()) {
> 49:             System.out.println("Testing L&F: " + laf.getClassName());
> 50:             SwingUtilities.invokeAndWait(() -> setLookAndFeel(laf));

You should probably call `setLookAndFeel` on the main thread, or you should call `UIManager.get` below on the EDT as well.

test/jdk/javax/swing/plaf/nimbus/PasswordFieldTest.java line 56:

> 54:             if (UIManager.get("PasswordField.echoChar") == null) {
> 55:                 throw new RuntimeException(
> 56:                     "PasswordField.echoChar returns null");

I agree with @TejeshR13, including the L&F name in the exception message would make the message more specific without opening the log for the test.

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

PR: https://git.openjdk.org/jdk/pull/10035


From aivanov at openjdk.org  Tue Sep 27 18:06:26 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 27 Sep 2022 18:06:26 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v3]
In-Reply-To: <oMTCqSIOfus9EhEL_dlZTeZoEvbd-6nD2imC1URRq4w=.cc5fa2c6-6f54-477d-9e62-7a5f7f4451f5@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>
 <OKwiyluDGrJJzJjqurX6vA4apF1Dz-v39QJlk8s7vGA=.189ba8bb-9d6f-4ea7-b399-801a857981b9@github.com>
 <U8w2BKrB9bFKrDtUkEM19LFr66BrhIbCjqtqUY_59n4=.46d7d53b-d1f4-40c7-a4f9-c8be44140ed6@github.com>
 <8_EXfD0W-aphoJsroB4e0r8hsMrcxpfATTWDGHXP_Es=.c22772e4-447a-48b2-b5de-1918059670f2@github.com>
 <-qOkFQnlLYWH_LFc0JpgxLICPgTG1mtzXG7xrnRppns=.cf90f4bc-bec9-4f99-aa5c-ee867c585f95@github.com>
 <1Y0OKsbNSaopRmrW3VQF8rh6RrClWmjbycO4qgfIY7I=.34c463c5-ccec-4bb5-981b-23e2a5bbab24@github.com>
 <kNaivUIpR-df4L93gfTtCzu_sbW-pnhFrvytIt272KA=.c6ba15de-a70a-4e8e-8225-2b5c5519614c@github.com>
 <oMTCqSIOfus9EhEL_dlZTeZoEvbd-6nD2imC1URRq4w=.cc5fa2c6-6f54-477d-9e62-7a5f7f4451f5@github.com>
Message-ID: <WXtjNlMxrqPtVNIO8yUYQVdPwdVp--05A-IOgxv7g2c=.f697edc4-1690-448f-bc25-5e59914f73bc@github.com>

On Tue, 13 Sep 2022 14:56:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It is probably simpler but we already store all tha properties in the generated NimbusDefaults, I do not think we should split the storage in two parts.
>
> Properties are **already** being stored in two parts so I am not inventing it for this fix. I am just adding an entry to the already created UIDefaults. Also, as I told, storing a character in skin.laf involves changing the generator tool which might not be scalable and prone to regressions, not to mention what/where should be changed in the tool for this is not known to me.
> 
> Also, as Synth is a skinnable look and feel, I think it would have been an issue if the property to be added affects "skin" in anyways, like **color, font, dimension** property etc, in which case it would have made sense to be mandatorily put in skin.laf which is the "visual designer"
>  but this Password echo character property will not affect the skin in anyway, like the other properties added in UIDefaults table in SynthLookAndFeel, so I think it should be ok.

I agree with @prsadhuk here. The `echoChar` isn't skin, it can be defined directly as is done for other properties.

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

PR: https://git.openjdk.org/jdk/pull/10035


From aivanov at openjdk.org  Tue Sep 27 18:16:16 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 27 Sep 2022 18:16:16 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is
 not shown on disabled checkbox and radio button with Nimbus LAF
In-Reply-To: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
References: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
Message-ID: <KaplknWj0teXbZY0X7lSez4kOpCkc0k14XIiOIREHp4=.feccbbcb-ddc1-4375-8f31-012f871d815c@github.com>

On Tue, 6 Sep 2022 05:57:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CheckBox.disabledText and RadioButton.disabledText color UIProperty is not honoured by Nimbus L&F when disabled text is drawn for JCheckBox and JRadioButton, so disabled text color was rendered incorrectly.
> Fix is to honour these UIProperty color if they are set by user, else use the color from the component or via getColorForState().
> 
> Closed test as mentioned in JBS is used to check the fix.

Please provide the regression test which iterates over all Look-and-Feels to make sure the setting is always honoured.

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

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10177


From honkar at openjdk.org  Tue Sep 27 18:20:19 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 27 Sep 2022 18:20:19 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails
In-Reply-To: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
Message-ID: <XvMcpD5FoqRFhEXXjs3aX8eR8zjKqHODHUDMe7PK6uA=.e2bdc254-0093-4778-89b5-5279d9e935e6@github.com>

On Fri, 23 Sep 2022 13:19:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> DefaultListSelectionModel.removeIndexInterva accepts `int` value which allows it to take in Integer.MAX_VALUE theoratically but it does calculation with that value which can results in IOOBE.
> Fix is to make sure the calculation stays within bounds.

Changes requested by honkar (Author).

test/jdk/javax/swing/TestDefListModelExcpn.java line 33:

> 31: 
> 32: public class TestDefListModelExcpn {
> 33:     public static void main(String[] args) throws Exception {

@prsadhuk A more descriptive exception message using try catch block would be more helpful than a generic throws Exception on the main method.

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

PR: https://git.openjdk.org/jdk/pull/10409


From aivanov at openjdk.org  Tue Sep 27 18:45:26 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 27 Sep 2022 18:45:26 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types
In-Reply-To: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
Message-ID: <obzIzWSUW5XC5da_AIfVFWE6QXFnwnxxAquEn3O26o4=.cc60f0c7-3fda-4b23-a399-817908fb0dc5@github.com>

On Wed, 21 Sep 2022 12:25:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> API specification says about BasicTextAreaUI.create "Returns a WrappedPlainView or PlainView". 
> But for [bidi](https://github.com/openjdk/jdk/blob/d14e96d9701dae951aa365029f58afb6687a646a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java#L168) text, this method returns BoxView and other views , so the documentation needs to be updated.

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java line 142:

> 140:      * Creates the view for an element.  Returns a WrappedPlainView or
> 141:      * PlainView if non-bidi text is handled
> 142:      * else returns PlainParagraph or BoxView if bidi text is being handled.

You cannot specify that this method returns `PlainParagraph`, it's a private class. I think we should relax the specification to allow other types to be returned without mentioning the exact types.

This issue is also relevant to `BasicTextFieldUI`, yet [it does not state explicitly](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/plaf/basic/BasicTextFieldUI.html#create(javax.swing.text.Element)) what types are valid, it only gives a hint that a `FieldView` is returned:

> Creates a view (FieldView) based on an element.

So, I propose the following text: *?Creates a view for an element. Usually returns a WrappedPlainView or PlainView.?*

The `@return` tag may be changed to ?a view (for the the element)? for this class as well as for `BasicTextFieldUI`.

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

PR: https://git.openjdk.org/jdk/pull/10376


From aivanov at openjdk.org  Tue Sep 27 20:45:33 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 27 Sep 2022 20:45:33 GMT
Subject: RFR: 7175397: The divider color is not changed to green when
 dragging for Nimbus LaF. [v2]
In-Reply-To: <-21DskiK73HbWK0fvkx1WKzGv9hDLuUM7vCMgMDDpG4=.c7df46c6-9f62-45ed-a8f2-d8f309924015@github.com>
References: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
 <-21DskiK73HbWK0fvkx1WKzGv9hDLuUM7vCMgMDDpG4=.c7df46c6-9f62-45ed-a8f2-d8f309924015@github.com>
Message-ID: <04eB0KFlqFESn9fsYVt7-ZjAenDHRP8ByXgC81Vb89c=.6db7eb87-f600-4c62-bd10-b51a65798edd@github.com>

On Wed, 24 Aug 2022 04:21:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SplitPaneDivider.draggingColor UIProperty was not honoured in Nimbus L&F. 
>> Added support for setting SplitPane dragging color for Nimbus L&F by drawing a fillRect of the set color as done in BasicLookAndFeel.
>> The fix relies on `continuousLayout` property being false by default which is enabled for Nimbus, which is set to default false now, same as in other L&F. I think it was set true just to have documented default value in JDK-6937415
>> 
>> closed test mentioned in JBS is used for fix check.
>> All jtreg swing tests are ok along with SwingSet2 JSplitPane demo in Nimbus L&F.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert default value

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java line 275:

> 273:                     Dimension      size = splitPane.getSize();
> 274: 
> 275:                     g.setColor(dividerDraggingColor);

What if `dividerDraggingColor` is null?

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java line 281:

> 279:                         g.fillRect(0, 0, size.width - 1, dividerSize - 1);
> 280:                     }
> 281:                 }

This piece of code is basically same as the code in `finishedPaintingChildren`. Can the duplication be eliminated by introducing a helper method?

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

PR: https://git.openjdk.org/jdk/pull/9937


From honkar at openjdk.org  Tue Sep 27 21:31:44 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 27 Sep 2022 21:31:44 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v2]
In-Reply-To: <MLqQD57AUwPmzF3cANN4iN1dNv7s0i4FFs3mOHAAtcM=.9b06fcce-9974-4c92-bd02-2e6a043f2965@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <-du2igQ7Bn4EWJTLVes8IAxFV79-rZJy4Ew1k1EYRi0=.2bfe3cce-89eb-43b9-893e-d770b3ea22cc@github.com>
 <MLqQD57AUwPmzF3cANN4iN1dNv7s0i4FFs3mOHAAtcM=.9b06fcce-9974-4c92-bd02-2e6a043f2965@github.com>
Message-ID: <yWnZuZWo48S8WZdc6SXiY6p1mN5T3yX28BTU7xtPRoQ=.7ffb3e5a-6d6b-400b-985d-73b455c5a252@github.com>

On Tue, 20 Sep 2022 18:22:20 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JIFBorder_8015739
>>  - added test summary
>>  - updated test case
>>  - Added test case, minor position changes to shadow lines
>>  - expanded imports
>>  - JIF Metal Border Scaling - Initial changes
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 277:
> 
>> 275:             }
>> 276: 
>> 277:             Graphics2D g2d = (Graphics2D) g;
> 
> Regardless, i see that absolutely similar code down this file for FrameBorder and DialogBorder. Are these UI elements suffer from the same issue or is it only limited to InternalFrame? If they do suffer from the same issue i would suggest either fixing it all together or at least submitting new bugs tracking existence of the problem. Of course problem might not be present for some reason in these components but it is worth checking it out while you are working on the code and remember all the details.

@azuev-java Tested FrameBorder and DialogBorder, they have a similar problem to JInternalFrameBorder (border scaling issue). Since there is a plan to create a common utility method, I'll create a new JBS issue to track FrameBorder and DialogBorder.

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

PR: https://git.openjdk.org/jdk/pull/10274


From prr at openjdk.org  Tue Sep 27 22:53:19 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 27 Sep 2022 22:53:19 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types
In-Reply-To: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
Message-ID: <rNt8Zj17SAddwQ-xLzQaUEmIxMVGgXAy3PNYh13PVMU=.7a92e41d-5e09-4c2f-a9e1-3228568d81cf@github.com>

On Wed, 21 Sep 2022 12:25:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> API specification says about BasicTextAreaUI.create "Returns a WrappedPlainView or PlainView". 
> But for [bidi](https://github.com/openjdk/jdk/blob/d14e96d9701dae951aa365029f58afb6687a646a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java#L168) text, this method returns BoxView and other views , so the documentation needs to be updated.

Yeah I don't  like the way this is documented at all. And it seems this can be swapped out on the fly when content changes too.
I think we need to start with WHY we need to document the return types. And if we don't then we don't.
If we do I'd like some detailed reasoning and contemplation of what we say about if it changes later.

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

PR: https://git.openjdk.org/jdk/pull/10376


From mernst at openjdk.org  Tue Sep 27 23:16:16 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Sep 2022 23:16:16 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>
Message-ID: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com>

On Mon, 26 Sep 2022 19:36:02 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Thank you for your efforts on the cleaning up these typos
> 
> I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review.
> 
> I realize the changes are fairly trivial but this will most likely expedite getting your changes back

Feel free to break up the pull request if that is what is needed to free it from red tape.
Thanks.

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

PR: https://git.openjdk.org/jdk/pull/10029


From psadhukhan at openjdk.org  Wed Sep 28 03:42:38 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 03:42:38 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v4]
In-Reply-To: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
Message-ID: <EjAfYfUDfJEnOCTSeBcPtH8AfuaREjtp4k6v7JjxTqA=.0d3ccaee-9b95-4c60-9189-f9707e157e7c@github.com>

> Default echo character obtained through `PasswordField.echoChar` UIProperty returns null for Nimbus L&F,
> which is fixed by adding the default character * in the UIDefault table.

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

  Review comment fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10035/files
  - new: https://git.openjdk.org/jdk/pull/10035/files/63998b9c..ae363d2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10035&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10035&range=02-03

  Stats: 18 lines in 2 files changed: 7 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10035.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10035/head:pull/10035

PR: https://git.openjdk.org/jdk/pull/10035


From psadhukhan at openjdk.org  Wed Sep 28 03:42:39 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 03:42:39 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v3]
In-Reply-To: <LoHGNYNKkAJxYX1seVVdAnSXJe-_dFBDmVMivwad5PM=.c21bd6a5-4f0d-4571-a237-607bf463cb99@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>
 <LoHGNYNKkAJxYX1seVVdAnSXJe-_dFBDmVMivwad5PM=.c21bd6a5-4f0d-4571-a237-607bf463cb99@github.com>
Message-ID: <1HXxNO0z36IJ-qBkoufs_9BBHeKWyf5cTWTlqCkZDGU=.0b9aa912-b6d9-4192-ba2f-ddb8e43bdcd3@github.com>

On Tue, 27 Sep 2022 17:57:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Honour PasswordField.echoChar property
>
> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthPasswordFieldUI.java line 77:
> 
>> 75:             LookAndFeel.installProperty(getComponent(), "echoChar", echoChar);
>> 76:         }
>> 77:     }
> 
> This is a public API class, it should provide a Javadoc, the text copied from `BasicPasswordFieldUI.installDefaults` which does the same thing should be enough.
> 
> I agree with @turbanoff, let's add a space after `if`.
> 
> Let's also add `@Override` annotation which are used on the methods above and below at the very least.

done

> test/jdk/javax/swing/plaf/nimbus/PasswordFieldTest.java line 56:
> 
>> 54:             if (UIManager.get("PasswordField.echoChar") == null) {
>> 55:                 throw new RuntimeException(
>> 56:                     "PasswordField.echoChar returns null");
> 
> I agree with @TejeshR13, including the L&F name in the exception message would make the message more specific without opening the log for the test.

ok

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

PR: https://git.openjdk.org/jdk/pull/10035


From psadhukhan at openjdk.org  Wed Sep 28 04:29:24 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 04:29:24 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails
In-Reply-To: <XvMcpD5FoqRFhEXXjs3aX8eR8zjKqHODHUDMe7PK6uA=.e2bdc254-0093-4778-89b5-5279d9e935e6@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <XvMcpD5FoqRFhEXXjs3aX8eR8zjKqHODHUDMe7PK6uA=.e2bdc254-0093-4778-89b5-5279d9e935e6@github.com>
Message-ID: <id68uQhunbERdO0AGye0vTHnuOHL-APgZDC0VeqjgSY=.786e74f1-5e1d-4d19-bf6c-a3859e5fc646@github.com>

On Tue, 27 Sep 2022 18:10:39 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> DefaultListSelectionModel.removeIndexInterva accepts `int` value which allows it to take in Integer.MAX_VALUE theoratically but it does calculation with that value which can results in IOOBE.
>> Fix is to make sure the calculation stays within bounds.
>
> test/jdk/javax/swing/TestDefListModelExcpn.java line 33:
> 
>> 31: 
>> 32: public class TestDefListModelExcpn {
>> 33:     public static void main(String[] args) throws Exception {
> 
> @prsadhuk A more descriptive exception message using try catch block would be more helpful than a generic throws Exception on the main method.

I am not sure it will, it is throwing IOOBE with the statcktrace by default and we normally relied on that for such exceptions AIOBE, IOOBE, CCE etc, not needed to catch and rethrow

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

PR: https://git.openjdk.org/jdk/pull/10409


From psadhukhan at openjdk.org  Wed Sep 28 06:44:25 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 06:44:25 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v3]
In-Reply-To: <0L_qtZSknxD6lrlKTqn3f3U2WGYlCIIN2psEZ-dp0Yw=.6ae3b3ad-909d-4959-94ff-59759e79e799@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
 <4VvhgKSAGDnjWdmTfvaNCcTsSmOmCQR8UsYNOSmRO5w=.be1165bd-2d1f-44bc-8027-3ae9923617ce@github.com>
 <0L_qtZSknxD6lrlKTqn3f3U2WGYlCIIN2psEZ-dp0Yw=.6ae3b3ad-909d-4959-94ff-59759e79e799@github.com>
Message-ID: <lWroBhXjkrbKrcN6pibZcch4zSfnr2atXBDRTf0UybQ=.0db44f84-8781-4482-a480-0238109d63e5@github.com>

On Tue, 27 Sep 2022 17:33:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Get color once during init
>
> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLabelUI.java line 222:
> 
>> 220:             if (fgColor != null) {
>> 221:                 label.setForeground(fgColor);
>> 222:             }
> 
> Why is the color set to the `label` component during paint?
> 
> Shouldn't it be `g.setColor(fgColor)`? And the above code which uses the `context` should be skipped if `fgColor != null`.

There are 2 ways JLabel can be used, one via html label and another normal label. Normal label text will work if we do `g.setColor(fgColor)` but html label will use [StyleSheet.paint](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#L1939) which does not take into account foreground Color (guess unless it's provided by html tags which is not the case here) so I need to explicitly set the foreground color of label

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

PR: https://git.openjdk.org/jdk/pull/9900


From duke at openjdk.org  Wed Sep 28 06:54:24 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 28 Sep 2022 06:54:24 GMT
Subject: RFR: 8292848: AWT_Mixing and TrayIcon tests fail on el8 with
 hard-coded isOel7
In-Reply-To: <aH8UVH574D88IUnIf8B3SlA2NAXBfFxo8lqrnM5CVNc=.6ebdfd83-13e1-4326-acc3-5311a205a4f4@github.com>
References: <ZJrPLHPk000YQPHb73cCqw1l7jP1vwRLEXMlOgrqVSs=.a599b437-a90f-4f81-8ca5-aa2809bde6f7@github.com>
 <aH8UVH574D88IUnIf8B3SlA2NAXBfFxo8lqrnM5CVNc=.6ebdfd83-13e1-4326-acc3-5311a205a4f4@github.com>
Message-ID: <RGTYSQGKj6Edwx7FHYO5DwU5E97X3udBf532-_p3kbk=.e577ddb0-4adf-447a-b350-53d51d6150e8@github.com>

On Thu, 25 Aug 2022 18:56:59 GMT, Phil Race <prr at openjdk.org> wrote:

>> Could you please review the JDK-8292848 bug fixes?
>> The purpose of the isOel7 method is to detect differences in GNOME version changes, and the isOel7 
>> result should be true after version 8.
>> I modified the isOel7 method to use regular expressions instead of hard-coded versions to be able to 
>> detect the new os version.
>> I also changed the method name to match the new conditions.
>
> I guess this will do what was previously being done on OL7 .. but the way it is done it is fragile
> and surely it can't be specific to OL .. and there's some pretty hokey adjustments going on in some of these tests.
> I think some day these tests will need to be re-examined.

@prrace 
I?m sorry to bother you again. Could you sponsor this pull request, please?

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

PR: https://git.openjdk.org/jdk/pull/9995


From psadhukhan at openjdk.org  Wed Sep 28 07:02:45 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 07:02:45 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v4]
In-Reply-To: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
Message-ID: <kPO8rq5DlNOCVSfbVwlKvmJizc16E4gVMfM9x4OLcis=.c81ceeb9-85f2-4059-8a7c-1f9f859f1447@github.com>

> Label.foreground UIProperty is not honored by Nimbus L&F.
> Added support for setting JLabel foreground color for Nimbus L&F

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

  Test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9900/files
  - new: https://git.openjdk.org/jdk/pull/9900/files/b6d0a8bd..22291af1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9900&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9900&range=02-03

  Stats: 12 lines in 1 file changed: 1 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/9900.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9900/head:pull/9900

PR: https://git.openjdk.org/jdk/pull/9900


From jdv at openjdk.org  Wed Sep 28 07:03:52 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 28 Sep 2022 07:03:52 GMT
Subject: RFR: 8292848: AWT_Mixing and TrayIcon tests fail on el8 with
 hard-coded isOel7
In-Reply-To: <ZJrPLHPk000YQPHb73cCqw1l7jP1vwRLEXMlOgrqVSs=.a599b437-a90f-4f81-8ca5-aa2809bde6f7@github.com>
References: <ZJrPLHPk000YQPHb73cCqw1l7jP1vwRLEXMlOgrqVSs=.a599b437-a90f-4f81-8ca5-aa2809bde6f7@github.com>
Message-ID: <XwYO1v9wM4PtHhpT1HsuDyDfzIAbsgvP3CJCZauUFgY=.63587191-293e-4c8c-ad57-245b28c705e0@github.com>

On Wed, 24 Aug 2022 07:06:15 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> Could you please review the JDK-8292848 bug fixes?
> The purpose of the isOel7 method is to detect differences in GNOME version changes, and the isOel7 
> result should be true after version 8.
> I modified the isOel7 method to use regular expressions instead of hard-coded versions to be able to 
> detect the new os version.
> I also changed the method name to match the new conditions.

Since it is already approved by Phil and Sergey, i have sponsored it.

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

PR: https://git.openjdk.org/jdk/pull/9995


From duke at openjdk.org  Wed Sep 28 07:03:53 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 28 Sep 2022 07:03:53 GMT
Subject: Integrated: 8292848: AWT_Mixing and TrayIcon tests fail on el8 with
 hard-coded isOel7
In-Reply-To: <ZJrPLHPk000YQPHb73cCqw1l7jP1vwRLEXMlOgrqVSs=.a599b437-a90f-4f81-8ca5-aa2809bde6f7@github.com>
References: <ZJrPLHPk000YQPHb73cCqw1l7jP1vwRLEXMlOgrqVSs=.a599b437-a90f-4f81-8ca5-aa2809bde6f7@github.com>
Message-ID: <dkiXwH2zoUohIO4cfbwDAZuVjFWWYY_H0R0YP6kL-_o=.9a585c8b-b766-4ce5-8926-f461cf6210a3@github.com>

On Wed, 24 Aug 2022 07:06:15 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> Could you please review the JDK-8292848 bug fixes?
> The purpose of the isOel7 method is to detect differences in GNOME version changes, and the isOel7 
> result should be true after version 8.
> I modified the isOel7 method to use regular expressions instead of hard-coded versions to be able to 
> detect the new os version.
> I also changed the method name to match the new conditions.

This pull request has now been integrated.

Changeset: c13e0ef3
Author:    KIRIYAMA Takuya <kiriyama.takuya at fujitsu.com>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c13e0ef3f8046a979638d6885a732553fc2b126e
Stats:     69 lines in 12 files changed: 19 ins; 0 del; 50 mod

8292848: AWT_Mixing and TrayIcon tests fail on el8 with hard-coded isOel7

Reviewed-by: prr, serb

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

PR: https://git.openjdk.org/jdk/pull/9995


From psadhukhan at openjdk.org  Wed Sep 28 07:20:48 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 07:20:48 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is
 not shown on disabled checkbox and radio button with Nimbus LAF [v2]
In-Reply-To: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
References: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
Message-ID: <T4l3jMfmpPEO-Fg0l7f2_fFtBsA_5eVc6u-2VnriT6A=.219ddbfb-5100-46f7-91b6-b5798a252632@github.com>

> CheckBox.disabledText and RadioButton.disabledText color UIProperty is not honoured by Nimbus L&F when disabled text is drawn for JCheckBox and JRadioButton, so disabled text color was rendered incorrectly.
> Fix is to honour these UIProperty color if they are set by user, else use the color from the component or via getColorForState().
> 
> Closed test as mentioned in JBS is used to check the fix.

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

  Test added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10177/files
  - new: https://git.openjdk.org/jdk/pull/10177/files/a9b7c028..5cae3706

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10177&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10177&range=00-01

  Stats: 164 lines in 1 file changed: 164 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10177.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10177/head:pull/10177

PR: https://git.openjdk.org/jdk/pull/10177


From psadhukhan at openjdk.org  Wed Sep 28 07:20:48 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 07:20:48 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is
 not shown on disabled checkbox and radio button with Nimbus LAF [v2]
In-Reply-To: <KaplknWj0teXbZY0X7lSez4kOpCkc0k14XIiOIREHp4=.feccbbcb-ddc1-4375-8f31-012f871d815c@github.com>
References: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
 <KaplknWj0teXbZY0X7lSez4kOpCkc0k14XIiOIREHp4=.feccbbcb-ddc1-4375-8f31-012f871d815c@github.com>
Message-ID: <QLdeFsPwc27JxgK7F7bUIW7uF2mLbZKjFT5aDx5Id3g=.b0d20ffc-988a-4394-bd40-44005ff366a8@github.com>

On Tue, 27 Sep 2022 18:14:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Please provide the regression test which iterates over all Look-and-Feels to make sure the setting is always honoured.

Test added

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

PR: https://git.openjdk.org/jdk/pull/10177


From psadhukhan at openjdk.org  Wed Sep 28 07:31:33 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 07:31:33 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types
In-Reply-To: <obzIzWSUW5XC5da_AIfVFWE6QXFnwnxxAquEn3O26o4=.cc60f0c7-3fda-4b23-a399-817908fb0dc5@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
 <obzIzWSUW5XC5da_AIfVFWE6QXFnwnxxAquEn3O26o4=.cc60f0c7-3fda-4b23-a399-817908fb0dc5@github.com>
Message-ID: <fQ98KpI7BeiBcnplKDPIgLb-Qe1EsLCNaw20N2lWU78=.dfcf2943-0750-44ec-b1c8-0a692b0d2241@github.com>

On Tue, 27 Sep 2022 18:41:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> API specification says about BasicTextAreaUI.create "Returns a WrappedPlainView or PlainView". 
>> But for [bidi](https://github.com/openjdk/jdk/blob/d14e96d9701dae951aa365029f58afb6687a646a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java#L168) text, this method returns BoxView and other views , so the documentation needs to be updated.
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java line 142:
> 
>> 140:      * Creates the view for an element.  Returns a WrappedPlainView or
>> 141:      * PlainView if non-bidi text is handled
>> 142:      * else returns PlainParagraph or BoxView if bidi text is being handled.
> 
> You cannot specify that this method returns `PlainParagraph`, it's a private class. I think we should relax the specification to allow other types to be returned without mentioning the exact types.
> 
> This issue is also relevant to `BasicTextFieldUI`, yet [it does not state explicitly](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/plaf/basic/BasicTextFieldUI.html#create(javax.swing.text.Element)) what types are valid, it only gives a hint that a `FieldView` is returned:
> 
>> Creates a view (FieldView) based on an element.
> 
> So, I propose the following text: *?Creates a view for an element. Usually returns a WrappedPlainView or PlainView.?*
> 
> The `@return` tag may be changed to ?a view (for the the element)? for this class as well as for `BasicTextFieldUI`.

I guess we can mention "Creates a view for an element." only.
`Usually returns a WrappedPlainView.. ` can give problem to TCK team to create testcase for all scenario. Either we mention the full `returns WrappedView or PlainView. or ParagraphView or BoxView`

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

PR: https://git.openjdk.org/jdk/pull/10376


From jdv at openjdk.org  Wed Sep 28 07:36:17 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 28 Sep 2022 07:36:17 GMT
Subject: RFR: 8289539: The color returned by CheckBox.interiorBackground is
 incorrect
In-Reply-To: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
References: <jhAJfedAGsWVhG0d-6EvnarTrz8dkF9j2nRdTvPbrEQ=.45aa47ad-c4fe-4ecd-87b5-f6cdd206d04c@github.com>
Message-ID: <LfKiak3ZyUMx6038fy9gOpHO9KQRTmKKU2X7jzPSvgo=.5f3b222b-a983-4eff-9d8e-25079fcace93@github.com>

On Thu, 22 Sep 2022 06:59:59 GMT, Tejesh R <tr at openjdk.org> wrote:

> The color returned for `InteriorBackground` property is the default color used for only _WindowsClassicLookAndFeel_. For _WindowsLookAndFeel_ the `InteriorBackground` color is not been used when checkbox paint happens. In _WindowsLookAndFeel_ the CheckBox check/uncheck is drawn using `ImageCache` which is totally independent of `InteriorBackground` color in which the user expects it to be.
> The proposed fix is to return null for _WindowsLookAndFeel_ (which is what happens in other LookAndFeel like Metal/Synth/Motif/Aqua ) and return default color which is the actual color used in _WindowsClassicLookAndFeel_.

Lets get inputs from @prsadhuk also on this. Whether to keep checkBox.interiorBackground valid only for WindowsClassicLAF and return null for WindowsLAF Or try to find ways to return valid value for WindowsLAF.

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

PR: https://git.openjdk.org/jdk/pull/10385


From aivanov at openjdk.org  Wed Sep 28 08:52:24 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 08:52:24 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails
In-Reply-To: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
Message-ID: <yNu3zjKhFeAeJxq2Wpv-9idnEsNqvcuvc5li8XEtuuA=.1faf720f-7257-4720-aa26-ec6729d200bb@github.com>

On Fri, 23 Sep 2022 13:19:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> DefaultListSelectionModel.removeIndexInterva accepts `int` value which allows it to take in Integer.MAX_VALUE theoratically but it does calculation with that value which can results in IOOBE.
> Fix is to make sure the calculation stays within bounds.

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 695:

> 693:         int rmMaxIndex = Math.max(index0, index1);
> 694:         int gapLength = ((rmMaxIndex - rmMinIndex) + 1) > (rmMaxIndex - rmMinIndex)
> 695:                 ? ((rmMaxIndex - rmMinIndex) + 1) : (rmMaxIndex - rmMinIndex);

I wonder if the model supports selections of 0 .. Integer.MAX_VALUE, it should ? but it doesn't. If I call

selectionModel.setSelectionInterval(Integer.MAX_VALUE - 1, Integer.MAX_VALUE);

it never returns, it goes into an infinite loop in `changeSelection` because the condition `i <= Math.max(setMax, clearMax)` is always `true` if either `setMax` or `clearMax` is `Integer.MAX_VALUE`. Therefore, we should prevent that from happening. With that in mind, for `removeIndexInterval`, the value of `Integer.MAX_VALUE` becomes invalid.

What will happen if negative values are passed, in particular `Integer.MIN_VALUE`?

src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 705:

> 703:             } else {
> 704:                 setState(i, value.get(gapLength));
> 705:             }

~~If `rmMaxIndex == Integer.MAX_VALUE - 1`, the code to remove the interval in the gap could remain the same. If `rmMaxIndex == Integer.MAX_VALUE`, the value of `gapLength` could be set to a value as if `rmMaxIndex == Integer.MAX_VALUE - 1`, then one more value is to be moved `setState(Integer.MAX_VALUE - gapLength, value.get(Integer.MAX_VALUE)` provided that `Integer.MAX_VALUE - gapLength <= maxIndex`.~~

This has become irrelevant taking into account my comment above that the model can't support selections up to and including `Integer.MAX_VALUE`.

test/jdk/javax/swing/TestDefListModelExcpn.java line 32:

> 30: import javax.swing.DefaultListSelectionModel;
> 31: 
> 32: public class TestDefListModelExcpn {

Why not spell `Exception`?

test/jdk/javax/swing/TestDefListModelExcpn.java line 37:

> 35:         selectionModel.setSelectionInterval(0, 1);
> 36:         selectionModel.removeIndexInterval(0, Integer.MAX_VALUE);
> 37:     }

A comment would help to understand that an exception was thrown and *no exception is expected*.

`throws Exception` in `main` declaration can be removed to hint at this too.

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

PR: https://git.openjdk.org/jdk/pull/10409


From psadhukhan at openjdk.org  Wed Sep 28 08:53:38 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 08:53:38 GMT
Subject: RFR: 7148092: [macosx] When Alt+down arrow key is pressed,
 the combobox popup does not appear. [v6]
In-Reply-To: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
References: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
Message-ID: <nwQyM0m7h2pZe_8FsKn0mH07OjomqHzDVsgSMcsohM8=.2490d060-68d9-4655-9244-408dacbc6f31@github.com>

> When comboBox have focus, pressing Alt+Down (or Up) should render the popup which is not happening for Aqua L&F.
> 
> Fix is to add toggleAction for Alt+Down/Up keys as has been done for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L912)
> 
> closed problemlisted test is used to check the fix.

Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge master
 - Test fix
 - Add test
 - Use camelCase
 - Fix as seen in native combobox
 - 7148092: [macosx] When Alt+down arrow key is pressed, the combobox popup does not appear.

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

Changes: https://git.openjdk.org/jdk/pull/10014/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10014&range=05
  Stats: 128 lines in 3 files changed: 128 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10014.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10014/head:pull/10014

PR: https://git.openjdk.org/jdk/pull/10014


From psadhukhan at openjdk.org  Wed Sep 28 08:55:13 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 08:55:13 GMT
Subject: Integrated: 7148092: [macosx] When Alt+down arrow key is pressed,
 the combobox popup does not appear.
In-Reply-To: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
References: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
Message-ID: <Sb9zYxGW3KIZM1Q2dOnxNSDXg0ieAFCUEbxQMW2TJC0=.96d5a7da-08c7-4765-a682-ce506735aae3@github.com>

On Thu, 25 Aug 2022 07:24:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When comboBox have focus, pressing Alt+Down (or Up) should render the popup which is not happening for Aqua L&F.
> 
> Fix is to add toggleAction for Alt+Down/Up keys as has been done for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L912)
> 
> closed problemlisted test is used to check the fix.

This pull request has now been integrated.

Changeset: c42ef70a
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c42ef70a453690ecdccc570161fdfda58318ecc6
Stats:     128 lines in 3 files changed: 128 ins; 0 del; 0 mod

7148092: [macosx] When Alt+down arrow key is pressed, the combobox popup does not appear.

Reviewed-by: prr, serb

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

PR: https://git.openjdk.org/jdk/pull/10014


From aivanov at openjdk.org  Wed Sep 28 09:04:43 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 09:04:43 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v3]
In-Reply-To: <LoHGNYNKkAJxYX1seVVdAnSXJe-_dFBDmVMivwad5PM=.c21bd6a5-4f0d-4571-a237-607bf463cb99@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>
 <LoHGNYNKkAJxYX1seVVdAnSXJe-_dFBDmVMivwad5PM=.c21bd6a5-4f0d-4571-a237-607bf463cb99@github.com>
Message-ID: <NyLPz9UROP3kFSYNhVYW8_cBWeKPy-GoZpd3qdet2hY=.d059c979-11e4-47ae-a81d-fea71910e947@github.com>

On Tue, 27 Sep 2022 17:59:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> You should probably call `setLookAndFeel` on the main thread, or you should call `UIManager.get` below on the EDT as well.

In fact, I was inclined to use the main thread, it produces a shorter stack trace. EDT is okay, no change is required if you don't feel like it.

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

PR: https://git.openjdk.org/jdk/pull/10035


From aivanov at openjdk.org  Wed Sep 28 09:14:28 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 09:14:28 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v4]
In-Reply-To: <EjAfYfUDfJEnOCTSeBcPtH8AfuaREjtp4k6v7JjxTqA=.0d3ccaee-9b95-4c60-9189-f9707e157e7c@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <EjAfYfUDfJEnOCTSeBcPtH8AfuaREjtp4k6v7JjxTqA=.0d3ccaee-9b95-4c60-9189-f9707e157e7c@github.com>
Message-ID: <ik0-lG-5i2eQyBnwOpq6fpZ3PYqODqqDwXrXW0w02AA=.f2d69cea-c287-46b3-99c1-bd0dd3868159@github.com>

On Wed, 28 Sep 2022 03:42:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Default echo character obtained through `PasswordField.echoChar` UIProperty returns null for Nimbus L&F,
>> which is fixed by adding the default character * in the UIDefault table.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/plaf/nimbus/PasswordFieldTest.java line 59:

> 57:                         "PasswordField.echoChar returns null for " +
> 58:                             laf.getClassName());
> 59:                 }

A question of style: do we usually wrap lines before the operator or after? [Java Coding Style](https://www.oracle.com/java/technologies/javase/codeconventions-indentation.html#248) is for the former. This versions seems to have been updated and the code formatting is lost now; [this draft](http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-wrapping-lines) is still for the same usage.

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

PR: https://git.openjdk.org/jdk/pull/10035


From psadhukhan at openjdk.org  Wed Sep 28 09:14:30 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 09:14:30 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v3]
In-Reply-To: <NyLPz9UROP3kFSYNhVYW8_cBWeKPy-GoZpd3qdet2hY=.d059c979-11e4-47ae-a81d-fea71910e947@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>
 <LoHGNYNKkAJxYX1seVVdAnSXJe-_dFBDmVMivwad5PM=.c21bd6a5-4f0d-4571-a237-607bf463cb99@github.com>
 <NyLPz9UROP3kFSYNhVYW8_cBWeKPy-GoZpd3qdet2hY=.d059c979-11e4-47ae-a81d-fea71910e947@github.com>
Message-ID: <T1Ezr49RL_6Zdnr-qtVVEGVrEfewqh9yyoy2eKzaVIo=.b4b33ebb-4681-407f-8d1f-d678a58036f4@github.com>

On Wed, 28 Sep 2022 09:00:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/plaf/nimbus/PasswordFieldTest.java line 50:
>> 
>>> 48:                             UIManager.getInstalledLookAndFeels()) {
>>> 49:             System.out.println("Testing L&F: " + laf.getClassName());
>>> 50:             SwingUtilities.invokeAndWait(() -> setLookAndFeel(laf));
>> 
>> You should probably call `setLookAndFeel` on the main thread, or you should call `UIManager.get` below on the EDT as well.
>
>> You should probably call `setLookAndFeel` on the main thread, or you should call `UIManager.get` below on the EDT as well.
> 
> In fact, I was inclined to use the main thread, it produces a shorter stack trace. EDT is okay, no change is required if you don't feel like it.

Normally, many tests does this only which is what I did initially..

public static void main(String[] args) throws Exception {
    for (UIManager.LookAndFeelInfo laf : UIManager.getInstalledLookAndFeels()) {
            System.out.println("Testing l&f : " + laf.getClassName());
            SwingUtilities.invokeAndWait(() -> setLookAndFeel(laf));


but I guess the present one will suffice too...

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

PR: https://git.openjdk.org/jdk/pull/10035


From aivanov at openjdk.org  Wed Sep 28 09:17:24 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 09:17:24 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null [v3]
In-Reply-To: <T1Ezr49RL_6Zdnr-qtVVEGVrEfewqh9yyoy2eKzaVIo=.b4b33ebb-4681-407f-8d1f-d678a58036f4@github.com>
References: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>
 <QZp1PULVUwtO8231ouUcg4a6IhrLeVtvwIWDbsweRV4=.42080b6f-8e53-4db9-8699-409d347f6395@github.com>
 <LoHGNYNKkAJxYX1seVVdAnSXJe-_dFBDmVMivwad5PM=.c21bd6a5-4f0d-4571-a237-607bf463cb99@github.com>
 <NyLPz9UROP3kFSYNhVYW8_cBWeKPy-GoZpd3qdet2hY=.d059c979-11e4-47ae-a81d-fea71910e947@github.com>
 <T1Ezr49RL_6Zdnr-qtVVEGVrEfewqh9yyoy2eKzaVIo=.b4b33ebb-4681-407f-8d1f-d678a58036f4@github.com>
Message-ID: <WSWVjw6zUpBekhPt-pwEuq2K0KAffsabNw7RXaAZ8mg=.be3df442-05fd-4d42-a7f2-de5d8413a49a@github.com>

On Wed, 28 Sep 2022 09:08:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> You should probably call `setLookAndFeel` on the main thread, or you should call `UIManager.get` below on the EDT as well.
>> 
>> In fact, I was inclined to use the main thread, it produces a shorter stack trace. EDT is okay, no change is required if you don't feel like it.
>
> Normally, many tests does this only which is what I did initially..
> 
> public static void main(String[] args) throws Exception {
>     for (UIManager.LookAndFeelInfo laf : UIManager.getInstalledLookAndFeels()) {
>             System.out.println("Testing l&f : " + laf.getClassName());
>             SwingUtilities.invokeAndWait(() -> setLookAndFeel(laf));
> 
> 
> but I guess the present one will suffice too...

My initial concern was that you use two different threads where you shouldn't. I would rather use the main thread for all operations in this particular case. As long as setting the LaF and reading the properties are on the same thread, we're safe.

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

PR: https://git.openjdk.org/jdk/pull/10035


From psadhukhan at openjdk.org  Wed Sep 28 09:27:21 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 09:27:21 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails
In-Reply-To: <yNu3zjKhFeAeJxq2Wpv-9idnEsNqvcuvc5li8XEtuuA=.1faf720f-7257-4720-aa26-ec6729d200bb@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <yNu3zjKhFeAeJxq2Wpv-9idnEsNqvcuvc5li8XEtuuA=.1faf720f-7257-4720-aa26-ec6729d200bb@github.com>
Message-ID: <dQS7C6Rb0i7nikhGNyQ3IOjcE1ohF6YBzRpH5rmbTHI=.7cb471cd-4be9-4c71-b392-2a8f89b703ec@github.com>

On Tue, 27 Sep 2022 19:42:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> DefaultListSelectionModel.removeIndexInterva accepts `int` value which allows it to take in Integer.MAX_VALUE theoratically but it does calculation with that value which can results in IOOBE.
>> Fix is to make sure the calculation stays within bounds.
>
> src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 695:
> 
>> 693:         int rmMaxIndex = Math.max(index0, index1);
>> 694:         int gapLength = ((rmMaxIndex - rmMinIndex) + 1) > (rmMaxIndex - rmMinIndex)
>> 695:                 ? ((rmMaxIndex - rmMinIndex) + 1) : (rmMaxIndex - rmMinIndex);
> 
> I wonder if the model supports selections of 0 .. Integer.MAX_VALUE, it should ? but it doesn't. If I call
> 
> selectionModel.setSelectionInterval(Integer.MAX_VALUE - 1, Integer.MAX_VALUE);
> 
> it never returns, it goes into an infinite loop in `changeSelection` because the condition `i <= Math.max(setMax, clearMax)` is always `true` if either `setMax` or `clearMax` is `Integer.MAX_VALUE`. Therefore, we should prevent that from happening. With that in mind, for `removeIndexInterval`, the value of `Integer.MAX_VALUE` becomes invalid.
> 
> What will happen if negative values are passed, in particular `Integer.MIN_VALUE`?

For negative values, the spec says "@throws IndexOutOfBoundsException if either index is less than {@code -1}" which it does.

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

PR: https://git.openjdk.org/jdk/pull/10409


From aivanov at openjdk.org  Wed Sep 28 09:40:21 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 09:40:21 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails
In-Reply-To: <dQS7C6Rb0i7nikhGNyQ3IOjcE1ohF6YBzRpH5rmbTHI=.7cb471cd-4be9-4c71-b392-2a8f89b703ec@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <yNu3zjKhFeAeJxq2Wpv-9idnEsNqvcuvc5li8XEtuuA=.1faf720f-7257-4720-aa26-ec6729d200bb@github.com>
 <dQS7C6Rb0i7nikhGNyQ3IOjcE1ohF6YBzRpH5rmbTHI=.7cb471cd-4be9-4c71-b392-2a8f89b703ec@github.com>
Message-ID: <FJv7pD4eLDNTF2AleeUAjYXHOLFTGw3psDzf_ulyvkY=.e220782a-4068-4c16-8eda-2b737529993b@github.com>

On Wed, 28 Sep 2022 09:23:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java line 695:
>> 
>>> 693:         int rmMaxIndex = Math.max(index0, index1);
>>> 694:         int gapLength = ((rmMaxIndex - rmMinIndex) + 1) > (rmMaxIndex - rmMinIndex)
>>> 695:                 ? ((rmMaxIndex - rmMinIndex) + 1) : (rmMaxIndex - rmMinIndex);
>> 
>> I wonder if the model supports selections of 0 .. Integer.MAX_VALUE, it should ? but it doesn't. If I call
>> 
>> selectionModel.setSelectionInterval(Integer.MAX_VALUE - 1, Integer.MAX_VALUE);
>> 
>> it never returns, it goes into an infinite loop in `changeSelection` because the condition `i <= Math.max(setMax, clearMax)` is always `true` if either `setMax` or `clearMax` is `Integer.MAX_VALUE`. Therefore, we should prevent that from happening. With that in mind, for `removeIndexInterval`, the value of `Integer.MAX_VALUE` becomes invalid.
>> 
>> What will happen if negative values are passed, in particular `Integer.MIN_VALUE`?
>
> For negative values, the spec says "@throws IndexOutOfBoundsException if either index is less than {@code -1}" which it does.

Well, the spec says nothing about it for this method: https://github.com/openjdk/jdk/blob/096bca4a9c5e8ac2668dd965df92153ea1d80add/src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java#L684-L690

I guess it should be update to state it explicitly.

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

PR: https://git.openjdk.org/jdk/pull/10409


From psadhukhan at openjdk.org  Wed Sep 28 09:41:56 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 09:41:56 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is
 not shown on disabled checkbox and radio button with Nimbus LAF [v3]
In-Reply-To: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
References: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
Message-ID: <7qd2lWnikmilEEK3YAZNJ5d95e5I00if6Ju_xLqBuY0=.10a2b1c5-9fb6-4f65-b0aa-246c4fca081a@github.com>

> CheckBox.disabledText and RadioButton.disabledText color UIProperty is not honoured by Nimbus L&F when disabled text is drawn for JCheckBox and JRadioButton, so disabled text color was rendered incorrectly.
> Fix is to honour these UIProperty color if they are set by user, else use the color from the component or via getColorForState().
> 
> Closed test as mentioned in JBS is used to check the fix.

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

 - Rename test
 - Rename test
 - Move test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10177/files
  - new: https://git.openjdk.org/jdk/pull/10177/files/5cae3706..1fcf9833

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10177&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10177&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/10177


From psadhukhan at openjdk.org  Wed Sep 28 09:43:21 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 09:43:21 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails
In-Reply-To: <FJv7pD4eLDNTF2AleeUAjYXHOLFTGw3psDzf_ulyvkY=.e220782a-4068-4c16-8eda-2b737529993b@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <yNu3zjKhFeAeJxq2Wpv-9idnEsNqvcuvc5li8XEtuuA=.1faf720f-7257-4720-aa26-ec6729d200bb@github.com>
 <dQS7C6Rb0i7nikhGNyQ3IOjcE1ohF6YBzRpH5rmbTHI=.7cb471cd-4be9-4c71-b392-2a8f89b703ec@github.com>
 <FJv7pD4eLDNTF2AleeUAjYXHOLFTGw3psDzf_ulyvkY=.e220782a-4068-4c16-8eda-2b737529993b@github.com>
Message-ID: <Jz8OHR9Kkc0xl8slUCaKGWeIrP0cfAa-l9zYenyv9oo=.51fd8182-7449-470c-a236-493df68e4386@github.com>

On Wed, 28 Sep 2022 09:38:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> For negative values, the spec says "@throws IndexOutOfBoundsException if either index is less than {@code -1}" which it does.
>
> Well, the spec says nothing about it for this method: https://github.com/openjdk/jdk/blob/096bca4a9c5e8ac2668dd965df92153ea1d80add/src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java#L684-L690
> 
> I guess it should be update to state it explicitly.

To remove an index, I guess we need to first do setSelection where we will already throw IOOBE so I guess that's why this method does not mention or handle it explicitly

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

PR: https://git.openjdk.org/jdk/pull/10409


From psadhukhan at openjdk.org  Wed Sep 28 09:47:22 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 09:47:22 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is
 not shown on disabled checkbox and radio button with Nimbus LAF [v4]
In-Reply-To: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
References: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
Message-ID: <kn90SKJbZzCzG7_R_MvK6bJlp0bv0O5kjwvQas4kNEk=.6022cef9-f2e3-42dc-9a3c-02d18947c2d2@github.com>

> CheckBox.disabledText and RadioButton.disabledText color UIProperty is not honoured by Nimbus L&F when disabled text is drawn for JCheckBox and JRadioButton, so disabled text color was rendered incorrectly.
> Fix is to honour these UIProperty color if they are set by user, else use the color from the component or via getColorForState().
> 
> Closed test as mentioned in JBS is used to check the fix.

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

  Test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10177/files
  - new: https://git.openjdk.org/jdk/pull/10177/files/1fcf9833..f539b8fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10177&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10177&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/10177


From aivanov at openjdk.org  Wed Sep 28 09:53:29 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 09:53:29 GMT
Subject: RFR: 6187113: DefaultListSelectionModel.removeIndexInterval(0,
 Integer.MAX_VALUE) fails
In-Reply-To: <Jz8OHR9Kkc0xl8slUCaKGWeIrP0cfAa-l9zYenyv9oo=.51fd8182-7449-470c-a236-493df68e4386@github.com>
References: <PLK1VAb44bqnVWqeJr4zFMg9B53n1PeRKfkZWXZMrlg=.d8fadb1f-7ab0-4704-87b7-98c4edd5dada@github.com>
 <yNu3zjKhFeAeJxq2Wpv-9idnEsNqvcuvc5li8XEtuuA=.1faf720f-7257-4720-aa26-ec6729d200bb@github.com>
 <dQS7C6Rb0i7nikhGNyQ3IOjcE1ohF6YBzRpH5rmbTHI=.7cb471cd-4be9-4c71-b392-2a8f89b703ec@github.com>
 <FJv7pD4eLDNTF2AleeUAjYXHOLFTGw3psDzf_ulyvkY=.e220782a-4068-4c16-8eda-2b737529993b@github.com>
 <Jz8OHR9Kkc0xl8slUCaKGWeIrP0cfAa-l9zYenyv9oo=.51fd8182-7449-470c-a236-493df68e4386@github.com>
Message-ID: <KT0UHwEiZuPO2uS1XWDJrlk1wFRdEsgVs1b_IBR3kSM=.2c862a0b-3222-485e-b713-bdd12a7f4097@github.com>

On Wed, 28 Sep 2022 09:41:02 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> To remove an index, I guess we need to first do setSelection where we will already throw IOOBE so I guess that's why this method does not mention or handle it explicitly

It's not required by the implementation.


        selectionModel.setSelectionInterval(0, 1);
        selectionModel.removeIndexInterval(Integer.MIN_VALUE, -1);


works ? that is the call to `removeIndexInterval` throws the `IndexOutOfBoundsException` because it tries to copy the bits in the removed interval. If `rmMinIndex` is negative, the implementation may throw IOOBE before doing other work as an optimisation or rely on it being thrown from the code below as it does now.

Other methods specify the behaviour for negative parameters, this method would benefit from it too.

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

PR: https://git.openjdk.org/jdk/pull/10409


From psadhukhan at openjdk.org  Wed Sep 28 10:55:28 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 10:55:28 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types [v2]
In-Reply-To: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
Message-ID: <9BYu-AIqD9LpF650C45CvMdLPNFcgqC1Zvt_POqe2sw=.a7de98da-c503-4d77-8882-d0f2eeb68b59@github.com>

> API specification says about BasicTextAreaUI.create "Returns a WrappedPlainView or PlainView". 
> But for [bidi](https://github.com/openjdk/jdk/blob/d14e96d9701dae951aa365029f58afb6687a646a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java#L168) text, this method returns BoxView and other views , so the documentation needs to be updated.

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

  javadoc fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10376/files
  - new: https://git.openjdk.org/jdk/pull/10376/files/940ed013..a690529b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10376&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10376&range=00-01

  Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10376.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10376/head:pull/10376

PR: https://git.openjdk.org/jdk/pull/10376


From aivanov at openjdk.org  Wed Sep 28 11:28:20 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 11:28:20 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types
In-Reply-To: <rNt8Zj17SAddwQ-xLzQaUEmIxMVGgXAy3PNYh13PVMU=.7a92e41d-5e09-4c2f-a9e1-3228568d81cf@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
 <rNt8Zj17SAddwQ-xLzQaUEmIxMVGgXAy3PNYh13PVMU=.7a92e41d-5e09-4c2f-a9e1-3228568d81cf@github.com>
Message-ID: <f39I98onzzPIRuGo-oTu2oSkG81w9-12lWCfjpu3qAo=.c083310a-729a-4b8e-ac67-604667e3b89d@github.com>

On Tue, 27 Sep 2022 22:51:10 GMT, Phil Race <prr at openjdk.org> wrote:

> Yeah I don't like the way this is documented at all. And it seems this can be swapped out on the fly when content changes too.

`BasicTestUI` implements `ViewFactory` which supplies views for text components.

The type of view returned depends on the document content, in particular whether it contains bidirectional text or not.

> I think we need to start with WHY we need to document the return types. And if we don't then we don't. If we do I'd like some detailed reasoning and contemplation of what we say about if it changes later.

We don't need to. The views for regular text are in public API: [`FieldView`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/text/FieldView.html) that's used by `BasicTextFieldUI` as well as [`PlainView`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/text/PlainView.html) and [`WrappedPlainView`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/text/WrappedPlainView.html) which are used by `BasicTextAreaUI`. Yet the views for bidirectional text aren't public. So it looks, the spec hints at the public types of views returned for the regular text, yet it says nothing about package-private views which support bidirectional text.

`BasicTextFieldUI` says the view is likely `FieldView` in parentheses, but `BasicTextAreaUI` states it returns `WrappedPlainView` or `PlainView` (only), which is incorrect.

Can we leave the reference to public API classes?  
Should we remove the references to types completely? If yes, `BasicTextFieldUI.create` should be updated as well.

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

PR: https://git.openjdk.org/jdk/pull/10376


From aivanov at openjdk.org  Wed Sep 28 11:31:44 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 11:31:44 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types [v2]
In-Reply-To: <9BYu-AIqD9LpF650C45CvMdLPNFcgqC1Zvt_POqe2sw=.a7de98da-c503-4d77-8882-d0f2eeb68b59@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
 <9BYu-AIqD9LpF650C45CvMdLPNFcgqC1Zvt_POqe2sw=.a7de98da-c503-4d77-8882-d0f2eeb68b59@github.com>
Message-ID: <OSMdu1HzItDg-BDwWDQYMgMCj8fMcrMrSstnx1x8aPY=.c8c86ffe-e7b5-4dbd-bce4-53d499ad3ae2@github.com>

On Wed, 28 Sep 2022 10:55:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> API specification says about BasicTextAreaUI.create "Returns a WrappedPlainView or PlainView". 
>> But for [bidi](https://github.com/openjdk/jdk/blob/d14e96d9701dae951aa365029f58afb6687a646a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java#L168) text, this method returns BoxView and other views , so the documentation needs to be updated.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc fix

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java line 140:

> 138: 
> 139:     /**
> 140:      * Creates the view for an element.

Suggestion:

     * Creates a view for an element.

It does not always return the same type of view.

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

PR: https://git.openjdk.org/jdk/pull/10376


From aivanov at openjdk.org  Wed Sep 28 11:31:45 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 11:31:45 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types [v2]
In-Reply-To: <fQ98KpI7BeiBcnplKDPIgLb-Qe1EsLCNaw20N2lWU78=.dfcf2943-0750-44ec-b1c8-0a692b0d2241@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
 <obzIzWSUW5XC5da_AIfVFWE6QXFnwnxxAquEn3O26o4=.cc60f0c7-3fda-4b23-a399-817908fb0dc5@github.com>
 <fQ98KpI7BeiBcnplKDPIgLb-Qe1EsLCNaw20N2lWU78=.dfcf2943-0750-44ec-b1c8-0a692b0d2241@github.com>
Message-ID: <v2Hq2as9NW7E8gFeyktarV2w96j7afXY5PBFSB7O8nI=.b4e4ee19-f1c9-43de-b51d-dd747955fd28@github.com>

On Wed, 28 Sep 2022 07:29:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I guess we can mention "Creates a view for an element." only. `Usually returns a WrappedPlainView.. ` can give problem to TCK team to create testcase for all scenario.

Then the current code shouldn't have passed the TCK as the spec requires either `WrappedView` or `PlainView`.

> Either we mention the full `returns WrappedView or PlainView. or ParagraphView or BoxView`

We can't specify it returns a package-private class.

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

PR: https://git.openjdk.org/jdk/pull/10376


From psadhukhan at openjdk.org  Wed Sep 28 11:41:23 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 11:41:23 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types [v3]
In-Reply-To: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
Message-ID: <KNZJlfcVyuwhS9SIyXtcBXGhFouq9ZloTV73HpVLOwA=.9976cfe0-9225-4447-ae4f-daac24e58327@github.com>

> API specification says about BasicTextAreaUI.create "Returns a WrappedPlainView or PlainView". 
> But for [bidi](https://github.com/openjdk/jdk/blob/d14e96d9701dae951aa365029f58afb6687a646a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java#L168) text, this method returns BoxView and other views , so the documentation needs to be updated.

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

  javadoc fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10376/files
  - new: https://git.openjdk.org/jdk/pull/10376/files/a690529b..ad8c03b7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10376&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10376&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/10376


From psadhukhan at openjdk.org  Wed Sep 28 11:47:23 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 11:47:23 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types [v2]
In-Reply-To: <OSMdu1HzItDg-BDwWDQYMgMCj8fMcrMrSstnx1x8aPY=.c8c86ffe-e7b5-4dbd-bce4-53d499ad3ae2@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
 <9BYu-AIqD9LpF650C45CvMdLPNFcgqC1Zvt_POqe2sw=.a7de98da-c503-4d77-8882-d0f2eeb68b59@github.com>
 <OSMdu1HzItDg-BDwWDQYMgMCj8fMcrMrSstnx1x8aPY=.c8c86ffe-e7b5-4dbd-bce4-53d499ad3ae2@github.com>
Message-ID: <iXbddbjALTzRq13D2oCuNbC7lcPGul5zG8J25oFi9ug=.8813838f-55e1-4940-a661-391fa57b6ba5@github.com>

On Wed, 28 Sep 2022 10:59:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc fix
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java line 140:
> 
>> 138: 
>> 139:     /**
>> 140:      * Creates the view for an element.
> 
> Suggestion:
> 
>      * Creates a view for an element.
> 
> It does not always return the same type of view.

ok

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

PR: https://git.openjdk.org/jdk/pull/10376


From aivanov at openjdk.org  Wed Sep 28 11:52:39 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 11:52:39 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types [v3]
In-Reply-To: <KNZJlfcVyuwhS9SIyXtcBXGhFouq9ZloTV73HpVLOwA=.9976cfe0-9225-4447-ae4f-daac24e58327@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
 <KNZJlfcVyuwhS9SIyXtcBXGhFouq9ZloTV73HpVLOwA=.9976cfe0-9225-4447-ae4f-daac24e58327@github.com>
Message-ID: <S_xwfM_NYBAhrE-_CIPYZ0pMFzZWebcXd6YMJ4k0PR8=.2638b8ba-97a3-4121-b8d6-a39fe2845ff3@github.com>

On Wed, 28 Sep 2022 11:41:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> API specification says about BasicTextAreaUI.create "Returns a WrappedPlainView or PlainView". 
>> But for [bidi](https://github.com/openjdk/jdk/blob/d14e96d9701dae951aa365029f58afb6687a646a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java#L168) text, this method returns BoxView and other views , so the documentation needs to be updated.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc fix

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextFieldUI.java line 86:

> 84: 
> 85:     /**
> 86:      * Creates a view (FieldView) based on an element.

Suggestion:

     * Creates a view based on an element.

For consistency, if we don't document the types.

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

PR: https://git.openjdk.org/jdk/pull/10376


From jdv at openjdk.org  Wed Sep 28 12:08:24 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 28 Sep 2022 12:08:24 GMT
Subject: RFR: 7175397: The divider color is not changed to green when
 dragging for Nimbus LaF. [v2]
In-Reply-To: <-21DskiK73HbWK0fvkx1WKzGv9hDLuUM7vCMgMDDpG4=.c7df46c6-9f62-45ed-a8f2-d8f309924015@github.com>
References: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
 <-21DskiK73HbWK0fvkx1WKzGv9hDLuUM7vCMgMDDpG4=.c7df46c6-9f62-45ed-a8f2-d8f309924015@github.com>
Message-ID: <R0CffOuYu7VXSb_8Lg1dtlEl0IikS2WlEoobYgMa77Y=.2514785d-cf54-4471-b0cb-7de3c25b890e@github.com>

On Wed, 24 Aug 2022 04:21:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SplitPaneDivider.draggingColor UIProperty was not honoured in Nimbus L&F. 
>> Added support for setting SplitPane dragging color for Nimbus L&F by drawing a fillRect of the set color as done in BasicLookAndFeel.
>> The fix relies on `continuousLayout` property being false by default which is enabled for Nimbus, which is set to default false now, same as in other L&F. I think it was set true just to have documented default value in JDK-6937415
>> 
>> closed test mentioned in JBS is used for fix check.
>> All jtreg swing tests are ok along with SwingSet2 JSplitPane demo in Nimbus L&F.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert default value

Changes requested by jdv (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java line 273:

> 271:                 paintDragDivider(g, 0, 0, getWidth(), getHeight());
> 272:                 if(!isContinuousLayout() && getLastDragLocation() != -1) {
> 273:                     Dimension      size = splitPane.getSize();

We can eliminate creation on new variable and use splitPane.getWidth/Height() as it is done at many places in this file.

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java line 352:

> 350:         Shape oldClip = g.getClip();
> 351:         g.clipRect(x, y, w, h);
> 352: 

Please remove these new lines

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java line 366:

> 364:         if(jc == splitPane && getLastDragLocation() != -1 &&
> 365:                               !isContinuousLayout() && !draggingHW) {
> 366:             Dimension      size = splitPane.getSize();

Same here

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

PR: https://git.openjdk.org/jdk/pull/9937


From psadhukhan at openjdk.org  Wed Sep 28 12:11:31 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 12:11:31 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types [v4]
In-Reply-To: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
Message-ID: <rt4u2JjnR9eEV5G0Dmbqhq6UjKs4gP61Jq_y79qdUN8=.68fa8334-1d6a-4d3e-adb2-ab510e86de73@github.com>

> API specification says about BasicTextAreaUI.create "Returns a WrappedPlainView or PlainView". 
> But for [bidi](https://github.com/openjdk/jdk/blob/d14e96d9701dae951aa365029f58afb6687a646a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java#L168) text, this method returns BoxView and other views , so the documentation needs to be updated.

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

  javadoc fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10376/files
  - new: https://git.openjdk.org/jdk/pull/10376/files/ad8c03b7..4a1afda9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10376&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10376&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/10376


From psadhukhan at openjdk.org  Wed Sep 28 12:11:34 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 12:11:34 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types [v3]
In-Reply-To: <S_xwfM_NYBAhrE-_CIPYZ0pMFzZWebcXd6YMJ4k0PR8=.2638b8ba-97a3-4121-b8d6-a39fe2845ff3@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
 <KNZJlfcVyuwhS9SIyXtcBXGhFouq9ZloTV73HpVLOwA=.9976cfe0-9225-4447-ae4f-daac24e58327@github.com>
 <S_xwfM_NYBAhrE-_CIPYZ0pMFzZWebcXd6YMJ4k0PR8=.2638b8ba-97a3-4121-b8d6-a39fe2845ff3@github.com>
Message-ID: <_M7loF7_IHg88xZyxy7Jt-hlZy-DMtfTR9wR354WKFg=.e2219568-a68a-4687-9429-e0e1c237b30a@github.com>

On Wed, 28 Sep 2022 11:49:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc fix
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextFieldUI.java line 86:
> 
>> 84: 
>> 85:     /**
>> 86:      * Creates a view (FieldView) based on an element.
> 
> Suggestion:
> 
>      * Creates a view based on an element.
> 
> For consistency, if we don't document the types.

ok

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

PR: https://git.openjdk.org/jdk/pull/10376


From aivanov at openjdk.org  Wed Sep 28 12:32:26 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 12:32:26 GMT
Subject: RFR: JDK-6229853: BasicTextAreaUI:create incompletely documents
 the possible returned View types [v4]
In-Reply-To: <rt4u2JjnR9eEV5G0Dmbqhq6UjKs4gP61Jq_y79qdUN8=.68fa8334-1d6a-4d3e-adb2-ab510e86de73@github.com>
References: <JGLD_vMqRHE_n1aMxgBbvV02MiHEBetnzchlLwFbLRs=.0983c36a-d37a-4865-982d-b57929f44f2b@github.com>
 <rt4u2JjnR9eEV5G0Dmbqhq6UjKs4gP61Jq_y79qdUN8=.68fa8334-1d6a-4d3e-adb2-ab510e86de73@github.com>
Message-ID: <6lI70mIUrPlclGDoFcSYkYasrOBlCxX4irw_4rQrWjY=.a1d32e29-b521-4ea9-8ebb-42eca6c04d4a@github.com>

On Wed, 28 Sep 2022 12:11:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> API specification says about BasicTextAreaUI.create "Returns a WrappedPlainView or PlainView". 
>> But for [bidi](https://github.com/openjdk/jdk/blob/d14e96d9701dae951aa365029f58afb6687a646a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java#L168) text, this method returns BoxView and other views , so the documentation needs to be updated.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc fix

Looks good if our decision is not document the types of views returned.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextFieldUI.java line 86:

> 84: 
> 85:     /**
> 86:      * Creates a view based on an element.

Should we use the wording from `BasicTextUI` for consistency?

Suggestion:

     * Creates a view for an element.


The description in [`ViewFactory.create`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/text/ViewFactory.html#create(javax.swing.text.Element)) is more detailed, a short sentence as above is enough for `TextUI`.

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

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10376


From asemenov at openjdk.org  Wed Sep 28 12:33:25 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 28 Sep 2022 12:33:25 GMT
Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v2]
In-Reply-To: <UfBh-sr7FlTUWKOsVoL1_t28GUxWp3WRrVgxJ9gYSfw=.44b84613-dc9c-49db-add7-8c96047ef9ee@github.com>
References: <iogsScwXVmrG-QaPPqnBIyBbyc30OmKOUPLjiSKpEEs=.c76d3e64-ea3e-4560-a88a-821f25f9680b@github.com>
 <UfBh-sr7FlTUWKOsVoL1_t28GUxWp3WRrVgxJ9gYSfw=.44b84613-dc9c-49db-add7-8c96047ef9ee@github.com>
Message-ID: <RugicFZP0SHh4fK970Sbdc2gP3wt6TBYROUosvWMKQw=.39aff673-22c5-4c71-9c7c-86e2b6afebc0@github.com>

On Wed, 11 May 2022 12:49:34 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> A11Y implementation on macOS has to directly call the 'JList.setSelectedIndex' method in order to request selection on an item (see 'CAccessibility.requestSelection'). The reason is that a11y API lacks appropriate method.There's only 'javax.accessibility.AccessibleSelection#addAccessibleSelection' which is mapped to 'javax.swing.JList#addSelectionInterval', it can not be used to set selected index.
>> 
>> @forantar @azuev-java @mrserb please review.
>> 
>> Please note that the new API allows you to implement a multiple selection in lists from the Java side, but I did not succeed in implementing it, because I could not determine the inclusion of the so-called "VoiceOver multiple selection mode".
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   We don't do @author tags in openjdk
>   Not 2022 ?

No, you don't need to close this pull request.
@azuev-java @mrserb @prrace please review [CSR](https://bugs.openjdk.org/browse/JDK-8286674 "[bugs.openjdk.org](http://bugs.openjdk.org/)") and this PR.

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

PR: https://git.openjdk.org/jdk/pull/8578


From psadhukhan at openjdk.org  Wed Sep 28 12:39:31 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 12:39:31 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is
 not shown on disabled checkbox and radio button with Nimbus LAF [v5]
In-Reply-To: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
References: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
Message-ID: <mqCBssZ6XNK1wGT2qdeng55O7tsZj6Z0-xTRDDH_f6E=.2e94ae17-7b05-42d2-83b5-5a6d0fc0b992@github.com>

> CheckBox.disabledText and RadioButton.disabledText color UIProperty is not honoured by Nimbus L&F when disabled text is drawn for JCheckBox and JRadioButton, so disabled text color was rendered incorrectly.
> Fix is to honour these UIProperty color if they are set by user, else use the color from the component or via getColorForState().
> 
> Closed test as mentioned in JBS is used to check the fix.

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

 - Test fix
 - Test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10177/files
  - new: https://git.openjdk.org/jdk/pull/10177/files/f539b8fc..4cc2c226

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10177&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10177&range=03-04

  Stats: 256 lines in 2 files changed: 26 ins; 211 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/10177.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10177/head:pull/10177

PR: https://git.openjdk.org/jdk/pull/10177


From psadhukhan at openjdk.org  Wed Sep 28 12:42:14 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 12:42:14 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is
 not shown on disabled checkbox and radio button with Nimbus LAF [v6]
In-Reply-To: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
References: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
Message-ID: <1SNEA4yF2vhL2WZ5nEsFIN8IPoLzDpdctrv9fq4XznA=.c7f28180-116f-406d-8a7e-ece8b3b60bae@github.com>

> CheckBox.disabledText and RadioButton.disabledText color UIProperty is not honoured by Nimbus L&F when disabled text is drawn for JCheckBox and JRadioButton, so disabled text color was rendered incorrectly.
> Fix is to honour these UIProperty color if they are set by user, else use the color from the component or via getColorForState().
> 
> Closed test as mentioned in JBS is used to check the fix.

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

  Test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10177/files
  - new: https://git.openjdk.org/jdk/pull/10177/files/4cc2c226..d2f3c6f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10177&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10177&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/10177


From jdv at openjdk.org  Wed Sep 28 12:57:18 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 28 Sep 2022 12:57:18 GMT
Subject: RFR: 7175397: The divider color is not changed to green when
 dragging for Nimbus LaF. [v2]
In-Reply-To: <-21DskiK73HbWK0fvkx1WKzGv9hDLuUM7vCMgMDDpG4=.c7df46c6-9f62-45ed-a8f2-d8f309924015@github.com>
References: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
 <-21DskiK73HbWK0fvkx1WKzGv9hDLuUM7vCMgMDDpG4=.c7df46c6-9f62-45ed-a8f2-d8f309924015@github.com>
Message-ID: <ChERilJs-wa4SoRDiqPFT7K6nQeqHYl1CBMtahy5tho=.648572d2-afc4-4db5-9de1-b2a675508c8f@github.com>

On Wed, 24 Aug 2022 04:21:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SplitPaneDivider.draggingColor UIProperty was not honoured in Nimbus L&F. 
>> Added support for setting SplitPane dragging color for Nimbus L&F by drawing a fillRect of the set color as done in BasicLookAndFeel.
>> The fix relies on `continuousLayout` property being false by default which is enabled for Nimbus, which is set to default false now, same as in other L&F. I think it was set true just to have documented default value in JDK-6937415
>> 
>> closed test mentioned in JBS is used for fix check.
>> All jtreg swing tests are ok along with SwingSet2 JSplitPane demo in Nimbus L&F.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert default value

Verified that with nonContinuousLayout, "SplitPaneDivider.draggingColor" is seen in Nimbus LAF also.

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

PR: https://git.openjdk.org/jdk/pull/9937


From jdv at openjdk.org  Wed Sep 28 13:13:26 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 28 Sep 2022 13:13:26 GMT
Subject: RFR: 7172359: HTML parser StackOverflowError on invalid HTML: <li>
 tag inside an <option> [v2]
In-Reply-To: <14Xsw8yK2ppDcaqcWeWUfTjA-cH86IE1mN30vxdITjg=.a5dcd15c-424a-48fa-b38d-283f20a0fe0c@github.com>
References: <edPACBk6ADLPsapJLTvWRDOYjYN_YgZXPDYn-hDo6Pc=.51f30a46-e66a-49a1-bfbe-9241827d0751@github.com>
 <14Xsw8yK2ppDcaqcWeWUfTjA-cH86IE1mN30vxdITjg=.a5dcd15c-424a-48fa-b38d-283f20a0fe0c@github.com>
Message-ID: <Au6D0CP5rPhc6Njup4jByXM4edU_eWzMwFEcsiq_kdM=.d64bfa8d-3022-4cf7-8b69-d5e79c76d039@github.com>

On Thu, 22 Sep 2022 12:23:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If there is invalid tag, stack terminates but it still tries to recurse through by calling legalElementContext() which results in StackOverflowError.
>> Fix is to return if stack is terminated after checking current tag is not valid in current context
>> 
>> All other test/html/parser as well as other jtreg suite tests are ok with the fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Return only if current tag is not valid in current context

Marked as reviewed by jdv (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10279


From aivanov at openjdk.org  Wed Sep 28 13:20:40 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 13:20:40 GMT
Subject: RFR: 8075916: The regression-swing case failed as colored text is
 not shown on disabled checkbox and radio button with Nimbus LAF [v6]
In-Reply-To: <1SNEA4yF2vhL2WZ5nEsFIN8IPoLzDpdctrv9fq4XznA=.c7f28180-116f-406d-8a7e-ece8b3b60bae@github.com>
References: <_Pu4ZIceztdCjw5gy3bOR39Y0Jvz_TEiHdGMN0rKu-M=.9843abff-48d9-4a66-95f3-198e897c1399@github.com>
 <1SNEA4yF2vhL2WZ5nEsFIN8IPoLzDpdctrv9fq4XznA=.c7f28180-116f-406d-8a7e-ece8b3b60bae@github.com>
Message-ID: <wbSa6sBmcoVHkqJrGDHx6FLHjtPUuk-d1zKcTXxquhI=.0a37b2ec-1c12-40f6-8b01-1430f5168372@github.com>

On Wed, 28 Sep 2022 12:42:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> CheckBox.disabledText and RadioButton.disabledText color UIProperty is not honoured by Nimbus L&F when disabled text is drawn for JCheckBox and JRadioButton, so disabled text color was rendered incorrectly.
>> Fix is to honour these UIProperty color if they are set by user, else use the color from the component or via getColorForState().
>> 
>> Closed test as mentioned in JBS is used to check the fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10177


From dfuchs at openjdk.org  Wed Sep 28 13:24:26 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Sep 2022 13:24:26 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com>
 <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com>
Message-ID: <aY7BXF5EIYZFFZcE_IWj3PwKjQLD35cJPnaJkvQpQmU=.5464c3b4-6a6b-4841-b24f-969b371dfc74@github.com>

On Tue, 27 Sep 2022 23:12:43 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> Feel free to break up the pull request if that is what is needed to free it from red tape.

Only you can do that @mernst

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

PR: https://git.openjdk.org/jdk/pull/10029


From aivanov at openjdk.org  Wed Sep 28 13:32:27 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 13:32:27 GMT
Subject: RFR: 7172359: HTML parser StackOverflowError on invalid HTML: <li>
 tag inside an <option> [v2]
In-Reply-To: <14Xsw8yK2ppDcaqcWeWUfTjA-cH86IE1mN30vxdITjg=.a5dcd15c-424a-48fa-b38d-283f20a0fe0c@github.com>
References: <edPACBk6ADLPsapJLTvWRDOYjYN_YgZXPDYn-hDo6Pc=.51f30a46-e66a-49a1-bfbe-9241827d0751@github.com>
 <14Xsw8yK2ppDcaqcWeWUfTjA-cH86IE1mN30vxdITjg=.a5dcd15c-424a-48fa-b38d-283f20a0fe0c@github.com>
Message-ID: <Xn-sZgLuKp4JKqQfHrr02ODFiCapybSSRgbddDOKWkk=.d24f03ac-9dcb-4ec6-b76d-e276daa099f1@github.com>

On Thu, 22 Sep 2022 12:23:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If there is invalid tag, stack terminates but it still tries to recurse through by calling legalElementContext() which results in StackOverflowError.
>> Fix is to return if stack is terminated after checking current tag is not valid in current context
>> 
>> All other test/html/parser as well as other jtreg suite tests are ok with the fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Return only if current tag is not valid in current context

test/jdk/javax/swing/text/html/parser/ParserCrash.java line 35:

> 33: import java.io.Reader;
> 34: 
> 35: public class ParserCrash {

It is not a **crash**, it is `StackOverflowError`, a better name would be `ParserStackOverflow(InInvalidTagContext)`.

test/jdk/javax/swing/text/html/parser/ParserCrash.java line 48:

> 46:         kit.read(reader, doc, 0); // StackOverflowError here
> 47: 
> 48:         System.out.println("Succeeded! (expected StackOverflowError");

Suggestion:

        System.out.println("Succeeded! (no StackOverflowError)");


You *do not expect* it but it was thrown before the fix.

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

PR: https://git.openjdk.org/jdk/pull/10279


From dfuchs at openjdk.org  Wed Sep 28 13:38:37 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Sep 2022 13:38:37 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
Message-ID: <WjnsB8gd3r6yurtHuMpcEK4-TJ8ox_psgBl5HRRLsLs=.512f181c-4da4-4eec-8d3d-63a8f19c2b07@github.com>

On Tue, 27 Sep 2022 12:14:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.
>> 
>> JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.
>> 
>> That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.
>> 
>> To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:
>> 
>>     public class Subtype extends Supertype {
>> 
>>         @Override
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class Supertype {
>> 
>>         /**
>>          * @throws SuperException general problem
>>          * @throws SubExceptionA  specific problem A
>>          * @throws SubExceptionB  specific problem B
>>          */
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class SuperException extends Exception {
>>     ...
>> 
>>     public class SubExceptionA extends SuperException {
>>     ...
>> 
>>     public class SubExceptionB extends SuperException {
>>     ...
>> 
>> For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:
>> 
>>     public void m()
>>            throws SuperException
>> 
>>     Overrides:
>>         m in class Supertype
>>     Throws:
>>         SuperException - general problem
>>         SubExceptionA - specific problem A
>>         SubExceptionB - specific problem B 
>> 
>> It works for checked and unchecked exceptions, for methods in classes and interfaces.
>> 
>> 
>> If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.
>> 
>> Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.
>> 
>> 
>> [^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
>> [^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert an extraneous change to jdk.javadoc

The changes to JNDI and NIO look reasonable to me - though I haven't verified whether anything was missing (or no longer needed). If you can assert that the generated docs are the same before and after the proposed change then that's enough for me.

src/java.naming/share/classes/javax/naming/directory/InitialDirContext.java line 186:

> 184:     /**
> 185:      * @throws  AttributeModificationException {@inheritDoc}
> 186:      */

Isn't `{@inheritDoc}` needed in this case to preserve the method & params  description?

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

PR: https://git.openjdk.org/jdk/pull/10449


From psadhukhan at openjdk.org  Wed Sep 28 13:39:45 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 13:39:45 GMT
Subject: RFR: 7172359: HTML parser StackOverflowError on invalid HTML: <li>
 tag inside an <option> [v3]
In-Reply-To: <edPACBk6ADLPsapJLTvWRDOYjYN_YgZXPDYn-hDo6Pc=.51f30a46-e66a-49a1-bfbe-9241827d0751@github.com>
References: <edPACBk6ADLPsapJLTvWRDOYjYN_YgZXPDYn-hDo6Pc=.51f30a46-e66a-49a1-bfbe-9241827d0751@github.com>
Message-ID: <R8xVHKxguRhSKyLaTwQxus6dacq68rx38NCVoaEjvXc=.d3b9cf2d-4f8e-4460-9540-335fceec5cac@github.com>

> If there is invalid tag, stack terminates but it still tries to recurse through by calling legalElementContext() which results in StackOverflowError.
> Fix is to return if stack is terminated after checking current tag is not valid in current context
> 
> All other test/html/parser as well as other jtreg suite tests are ok with the fix.

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

  Test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10279/files
  - new: https://git.openjdk.org/jdk/pull/10279/files/4296729f..46c477d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10279&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10279&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/10279


From psadhukhan at openjdk.org  Wed Sep 28 13:54:16 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 28 Sep 2022 13:54:16 GMT
Subject: RFR: 7172359: HTML parser StackOverflowError on invalid HTML: <li>
 tag inside an <option> [v2]
In-Reply-To: <Xn-sZgLuKp4JKqQfHrr02ODFiCapybSSRgbddDOKWkk=.d24f03ac-9dcb-4ec6-b76d-e276daa099f1@github.com>
References: <edPACBk6ADLPsapJLTvWRDOYjYN_YgZXPDYn-hDo6Pc=.51f30a46-e66a-49a1-bfbe-9241827d0751@github.com>
 <14Xsw8yK2ppDcaqcWeWUfTjA-cH86IE1mN30vxdITjg=.a5dcd15c-424a-48fa-b38d-283f20a0fe0c@github.com>
 <Xn-sZgLuKp4JKqQfHrr02ODFiCapybSSRgbddDOKWkk=.d24f03ac-9dcb-4ec6-b76d-e276daa099f1@github.com>
Message-ID: <VoD4PTXbEHYyzhan4LGxUtFQws6OJAUbJp2DkX4Dwmo=.d878ad11-9055-4334-862d-9fdb1f80a431@github.com>

On Tue, 27 Sep 2022 18:19:02 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Return only if current tag is not valid in current context
>
> test/jdk/javax/swing/text/html/parser/ParserCrash.java line 35:
> 
>> 33: import java.io.Reader;
>> 34: 
>> 35: public class ParserCrash {
> 
> It is not a **crash**, it is `StackOverflowError`, a better name would be `ParserStackOverflow(InInvalidTagContext)`.

ok

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

PR: https://git.openjdk.org/jdk/pull/10279


From prappo at openjdk.org  Wed Sep 28 14:04:25 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 28 Sep 2022 14:04:25 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <WjnsB8gd3r6yurtHuMpcEK4-TJ8ox_psgBl5HRRLsLs=.512f181c-4da4-4eec-8d3d-63a8f19c2b07@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
 <WjnsB8gd3r6yurtHuMpcEK4-TJ8ox_psgBl5HRRLsLs=.512f181c-4da4-4eec-8d3d-63a8f19c2b07@github.com>
Message-ID: <AtkGrQJlrGsyJWAgtPgeUmc1nONMsxO_vzqUAFm2csk=.05cfb965-4e97-4507-b500-f95e06583ad8@github.com>

On Wed, 28 Sep 2022 13:34:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert an extraneous change to jdk.javadoc
>
> src/java.naming/share/classes/javax/naming/directory/InitialDirContext.java line 186:
> 
>> 184:     /**
>> 185:      * @throws  AttributeModificationException {@inheritDoc}
>> 186:      */
> 
> Isn't `{@inheritDoc}` needed in this case to preserve the method & params  description?

Elements of a method declaration such as formal and type parameters as well as exceptions in the `throws` clause implicitly inherit descriptions, unless those elements are described in that method declaration. The same goes for the main description of a method: unless it exists in the method declaration, it is inherited.

To sum up, those descriptions you ask about are implicitly inherited. No additional javadoc markup is needed.

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

PR: https://git.openjdk.org/jdk/pull/10449


From alanb at openjdk.org  Wed Sep 28 14:22:10 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Sep 2022 14:22:10 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
Message-ID: <jRRrURJQpNTiCWGs_oPoRkJTFb60kh_zg2ARAg_033I=.66258e70-5760-4d88-86a9-9f7bbf47c9de@github.com>

On Tue, 27 Sep 2022 12:14:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.
>> 
>> JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.
>> 
>> That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.
>> 
>> To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:
>> 
>>     public class Subtype extends Supertype {
>> 
>>         @Override
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class Supertype {
>> 
>>         /**
>>          * @throws SuperException general problem
>>          * @throws SubExceptionA  specific problem A
>>          * @throws SubExceptionB  specific problem B
>>          */
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class SuperException extends Exception {
>>     ...
>> 
>>     public class SubExceptionA extends SuperException {
>>     ...
>> 
>>     public class SubExceptionB extends SuperException {
>>     ...
>> 
>> For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:
>> 
>>     public void m()
>>            throws SuperException
>> 
>>     Overrides:
>>         m in class Supertype
>>     Throws:
>>         SuperException - general problem
>>         SubExceptionA - specific problem A
>>         SubExceptionB - specific problem B 
>> 
>> It works for checked and unchecked exceptions, for methods in classes and interfaces.
>> 
>> 
>> If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.
>> 
>> Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.
>> 
>> 
>> [^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
>> [^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert an extraneous change to jdk.javadoc

The updates to the channel classes look okay.

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

PR: https://git.openjdk.org/jdk/pull/10449


From prappo at openjdk.org  Wed Sep 28 14:22:11 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 28 Sep 2022 14:22:11 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <WjnsB8gd3r6yurtHuMpcEK4-TJ8ox_psgBl5HRRLsLs=.512f181c-4da4-4eec-8d3d-63a8f19c2b07@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
 <WjnsB8gd3r6yurtHuMpcEK4-TJ8ox_psgBl5HRRLsLs=.512f181c-4da4-4eec-8d3d-63a8f19c2b07@github.com>
Message-ID: <xKmD22kAF0LCY9X5tja1gN_hXJdpSJl7mGI5RFNrKiY=.0911fc21-61a4-4536-bb58-1e8947aa2834@github.com>

On Wed, 28 Sep 2022 13:36:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> If you can assert that the generated docs are the same before and after the proposed change then that's enough for me.

Would it suffice if I show the result of the diff between JDK API Documentation built at the tip of this PR branch (docs) and that of the jdk/master commit (docs-old) from which this PR branches? If so, please have a look:


    % diff -qnr build/macosx-aarch64/images/docs build/macosx-aarch64/images/docs-old                                                
    Files build/macosx-aarch64/images/docs/api/index-files/index-9.html and build/macosx-aarch64/images/docs-old/api/index-files/index-9.html differ
    Files build/macosx-aarch64/images/docs/api/java.base/java/lang/class-use/Exception.html and build/macosx-aarch64/images/docs-old/api/java.base/java/lang/class-use/Exception.html differ
    Files build/macosx-aarch64/images/docs/api/java.base/java/lang/class-use/Override.html and build/macosx-aarch64/images/docs-old/api/java.base/java/lang/class-use/Override.html differ
    Files build/macosx-aarch64/images/docs/api/java.base/java/lang/class-use/String.html and build/macosx-aarch64/images/docs-old/api/java.base/java/lang/class-use/String.html differ
    Files build/macosx-aarch64/images/docs/api/java.base/java/lang/reflect/class-use/Method.html and build/macosx-aarch64/images/docs-old/api/java.base/java/lang/reflect/class-use/Method.html differ
    Files build/macosx-aarch64/images/docs/api/jdk.jshell/jdk/jshell/execution/JdiDefaultExecutionControl.html and build/macosx-aarch64/images/docs-old/api/jdk.jshell/jdk/jshell/execution/JdiDefaultExecutionControl.html differ
    Files build/macosx-aarch64/images/docs/api/jdk.jshell/jdk/jshell/execution/RemoteExecutionControl.html and build/macosx-aarch64/images/docs-old/api/jdk.jshell/jdk/jshell/execution/RemoteExecutionControl.html differ
    Files build/macosx-aarch64/images/docs/api/member-search-index.js and build/macosx-aarch64/images/docs-old/api/member-search-index.js differ

As I said in the PR description, the differences are insignificant and confined to class-use and index structures. Well, except for jdk.jshell. But even there it might be okay for now.

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

PR: https://git.openjdk.org/jdk/pull/10449


From mernst at openjdk.org  Wed Sep 28 14:49:20 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Wed, 28 Sep 2022 14:49:20 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <Jyn0vr5OLxfZ_ITdPDPtLgoutY9Uc5cenHdv7eTi9JU=.eb66135a-cf93-4661-8a64-bd16c9c1a8ed@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Regarding breaking up the pull request:
 * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape.
 * I have spent a nontrivial amount of time on these fixes.  There have been long delays, which forced me to resolve merge conflicts.  I was told that the changes are "mostly fine" without any indication of what is wrong.  I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted.
 * No one has explained what to do.  "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is.

I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to corrections.

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

PR: https://git.openjdk.org/jdk/pull/10029


From aivanov at openjdk.org  Wed Sep 28 15:06:15 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 15:06:15 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v4]
In-Reply-To: <kPO8rq5DlNOCVSfbVwlKvmJizc16E4gVMfM9x4OLcis=.c81ceeb9-85f2-4059-8a7c-1f9f859f1447@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
 <kPO8rq5DlNOCVSfbVwlKvmJizc16E4gVMfM9x4OLcis=.c81ceeb9-85f2-4059-8a7c-1f9f859f1447@github.com>
Message-ID: <MnWdeVZZxAh5XmVPekT8R9VJwCGgi7nbURE4Zbu1qWM=.c23996fa-5534-4782-a9f8-4991217428ed@github.com>

On Wed, 28 Sep 2022 07:02:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Label.foreground UIProperty is not honored by Nimbus L&F.
>> Added support for setting JLabel foreground color for Nimbus L&F
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

test/jdk/javax/swing/plaf/nimbus/TestNimbusLabel.java line 47:

> 45: {
> 46:     private static JFrame frame;
> 47:     private static int colorTolerance = 5;

Let's add `final` to the constant.

test/jdk/javax/swing/plaf/nimbus/TestNimbusLabel.java line 61:

> 59:             return true;
> 60:         }
> 61:         return false;

Could be simplified to return `<condition>;`

I wonder if this test should also verify the number of pixels of correct color as done in #10177.

test/jdk/javax/swing/plaf/nimbus/TestNimbusLabel.java line 106:

> 104:                     robot.createScreenCapture(new Rectangle(p.x, p.y,
> 105:                             d.width,
> 106:                             d.height));

Suggestion:

                    robot.createScreenCapture(new Rectangle(p, d));

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

PR: https://git.openjdk.org/jdk/pull/9900


From aivanov at openjdk.org  Wed Sep 28 15:11:38 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 15:11:38 GMT
Subject: RFR: 7172359: HTML parser StackOverflowError on invalid HTML: <li>
 tag inside an <option> [v3]
In-Reply-To: <R8xVHKxguRhSKyLaTwQxus6dacq68rx38NCVoaEjvXc=.d3b9cf2d-4f8e-4460-9540-335fceec5cac@github.com>
References: <edPACBk6ADLPsapJLTvWRDOYjYN_YgZXPDYn-hDo6Pc=.51f30a46-e66a-49a1-bfbe-9241827d0751@github.com>
 <R8xVHKxguRhSKyLaTwQxus6dacq68rx38NCVoaEjvXc=.d3b9cf2d-4f8e-4460-9540-335fceec5cac@github.com>
Message-ID: <Pui70wuQGmhVbgX8pvLBV0khKNOYRKys4SDWd1AJojA=.d13dab9d-fbf7-461f-8dad-bf60464dcaea@github.com>

On Wed, 28 Sep 2022 13:39:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If there is invalid tag, stack terminates but it still tries to recurse through by calling legalElementContext() which results in StackOverflowError.
>> Fix is to return if stack is terminated after checking current tag is not valid in current context
>> 
>> All other test/html/parser as well as other jtreg suite tests are ok with the fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/text/html/parser/ParserStackOverflow.java line 37:

> 35: public class ParserStackOverflow {
> 36:     /*
> 37:      * li element inside an option will crash javax.swing.text.html.parser.Parser

It doesn't **crash** it.

test/jdk/javax/swing/text/html/parser/ParserStackOverflow.java line 48:

> 46:         kit.read(reader, doc, 0); // StackOverflowError here
> 47: 
> 48:         System.out.println("Succeeded! (no StackOverflowError");

Suggestion:

        System.out.println("Succeeded! (no StackOverflowError)");

The closing parenthesis is missing in the string.

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

PR: https://git.openjdk.org/jdk/pull/10279


From dfuchs at openjdk.org  Wed Sep 28 15:13:39 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Sep 2022 15:13:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <Jyn0vr5OLxfZ_ITdPDPtLgoutY9Uc5cenHdv7eTi9JU=.eb66135a-cf93-4661-8a64-bd16c9c1a8ed@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <Jyn0vr5OLxfZ_ITdPDPtLgoutY9Uc5cenHdv7eTi9JU=.eb66135a-cf93-4661-8a64-bd16c9c1a8ed@github.com>
Message-ID: <kTzLFBRbJQt3hKHD094hV-0zXH9FY4Fg2wdrOvFeK34=.c79081a5-df9a-4ea0-b481-19f903f56bd9@github.com>

On Wed, 28 Sep 2022 14:45:54 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Reinstate typos in Apache code that is copied into the JDK
>>  - Merge ../jdk-openjdk into typos-typos
>>  - Remove file that was removed upstream
>>  - Fix inconsistency in capitalization
>>  - Undo change in zlip
>>  - Fix typos
>
> Regarding breaking up the pull request:
>  * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape.
>  * Despite my repeated requests, no one has justified that *this particular pull request* needs the expertise of different teams.  The only reasons stated have been custom and bureaucracy.
>  * I have spent a nontrivial amount of time on these fixes.  There have been long delays, which forced me to resolve merge conflicts.  I was told that the changes are "mostly fine" without any indication of what is wrong.  I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted.
>  * I was condescendingly told "We have discussed several times in the past ..." even though I was not privy to those discussions.  No pointer to documentation in the JDK itself, about pull requests, was given.
>  * No one has explained what to do.  "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is.
> 
> I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to contributions.

Hi @mernst, sorry if this is how it appears. Pull requests that involve changes spanning a large set of files are notoriously harder to review since they require a reviewer from each different area to chime in. Basically you will need one reviewer from each of these areas:

-     client
-     compiler
-     core-libs
-     hotspot
-     i18n
-     javadoc
-     jmx
-     net
-     nio
-     security
-     serviceability

Jaikiran suggested to reduce the scope of this PR in his first comment:
https://github.com/openjdk/jdk/pull/10029#issuecomment-1236588632

as did several other reviewers. Sorry if the meaning (or reason) was not clear.

best regards,

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

PR: https://git.openjdk.org/jdk/pull/10029


From aivanov at openjdk.org  Wed Sep 28 15:19:20 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 15:19:20 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v2]
In-Reply-To: <yWnZuZWo48S8WZdc6SXiY6p1mN5T3yX28BTU7xtPRoQ=.7ffb3e5a-6d6b-400b-985d-73b455c5a252@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <-du2igQ7Bn4EWJTLVes8IAxFV79-rZJy4Ew1k1EYRi0=.2bfe3cce-89eb-43b9-893e-d770b3ea22cc@github.com>
 <MLqQD57AUwPmzF3cANN4iN1dNv7s0i4FFs3mOHAAtcM=.9b06fcce-9974-4c92-bd02-2e6a043f2965@github.com>
 <yWnZuZWo48S8WZdc6SXiY6p1mN5T3yX28BTU7xtPRoQ=.7ffb3e5a-6d6b-400b-985d-73b455c5a252@github.com>
Message-ID: <19_qFwnjlNliZMAvM2yUUC-lshXahir4C4PxKdf7YJQ=.6144e0b9-88b2-4a67-9822-2ee30b868dbe@github.com>

On Tue, 27 Sep 2022 21:28:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 277:
>> 
>>> 275:             }
>>> 276: 
>>> 277:             Graphics2D g2d = (Graphics2D) g;
>> 
>> Regardless, i see that absolutely similar code down this file for FrameBorder and DialogBorder. Are these UI elements suffer from the same issue or is it only limited to InternalFrame? If they do suffer from the same issue i would suggest either fixing it all together or at least submitting new bugs tracking existence of the problem. Of course problem might not be present for some reason in these components but it is worth checking it out while you are working on the code and remember all the details.
>
> @azuev-java Tested FrameBorder and DialogBorder, they have a similar problem to JInternalFrameBorder (border scaling issue). I have created a new JBS issue - **[JDK-8294484](https://bugs.openjdk.org/browse/JDK-8294484)** to track Frame and Dialog Borders of Metal LAF as there is a plan to create a common utility method and refactor the common steps.

Thank you, @honkar-jdk. Once the border handling is unified, fixing `FrameBorder` and `DialogBorder` will be easier and code duplication will be avoided.

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

PR: https://git.openjdk.org/jdk/pull/10274


From aivanov at openjdk.org  Wed Sep 28 15:28:24 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 15:28:24 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

The title says under `test/jdk/*`, yet there are lots of files changed in `src/*`.

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

PR: https://git.openjdk.org/jdk/pull/10029


From mernst at openjdk.org  Wed Sep 28 15:35:40 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Wed, 28 Sep 2022 15:35:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>
Message-ID: <bj6-5xC1mWXfuzSDLowQQPxYmo9OcqnW0XYnGLvEW0c=.c97b6b36-8590-47af-bdc2-e94f2230af08@github.com>

On Wed, 28 Sep 2022 15:26:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The title says under `test/jdk/*`, yet there are lots of files changed in `src/*`.

The title was edited by someone other than me, as you can see from the PR history.

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

PR: https://git.openjdk.org/jdk/pull/10029


From aivanov at openjdk.org  Wed Sep 28 15:43:43 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 15:43:43 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v29]
In-Reply-To: <8HyTZlh3KG49Rz1mqXm8QryD7QTwzY7ESyrxa5C0EE4=.2b4630bd-b327-4feb-858e-87f8d9671f06@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <67J5y7EUu-fv68E35nDZIr7VVFjvhpJQOVpPQ-knbVo=.afe79c4e-8a9c-4146-9fc7-c0d29f211f66@github.com>
 <8HyTZlh3KG49Rz1mqXm8QryD7QTwzY7ESyrxa5C0EE4=.2b4630bd-b327-4feb-858e-87f8d9671f06@github.com>
Message-ID: <LotJ1Pv2aAyEabWZ_U1-tV6LvjQP0kDYndIeylccWZQ=.2676065b-73e8-4e19-ae10-6784bef239ac@github.com>

On Mon, 26 Sep 2022 21:08:45 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment fix
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1127:
> 
>> 1125:         JFileChooser chooser;
>> 1126:         DateFormat df;
>> 1127:         final static double baseFileSize = 1000.0;
> 
> let's use blessed modifiers order: `static final`

Thanks for catching it, I missed it.

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

PR: https://git.openjdk.org/jdk/pull/9327


From aivanov at openjdk.org  Wed Sep 28 16:02:56 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 16:02:56 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v22]
In-Reply-To: <BY1Cgckwh4iA2FaUgv5SJBbgcM1V-KFTP8e8okQXJk8=.75da7e57-c703-493f-a83e-258a8122ac80@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <BY1Cgckwh4iA2FaUgv5SJBbgcM1V-KFTP8e8okQXJk8=.75da7e57-c703-493f-a83e-258a8122ac80@github.com>
Message-ID: <0uQfMUHSd2uCkqlrBFwWdQF644L-XVF3D0xA8IlO8b8=.4da6b1dc-8b4c-46bb-8a9e-74f50a1fa6de@github.com>

On Mon, 26 Sep 2022 21:20:54 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Import order - Comments
>   
>   - Corrects import declaration order.
>   - Removes comments

test/jdk/javax/swing/text/html/CSS/MissingColorNames.java line 29:

> 27:  * @summary Missing Color Names in CSS
> 28:  * @run main MissingColorNames
> 29:  */

May I ask to move these jtreg tags to the class declaration? They work either way, yet the comment with tags isn't collapsed when viewed in an IDE if it's placed before the class declaration.

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

PR: https://git.openjdk.org/jdk/pull/9825


From aivanov at openjdk.org  Wed Sep 28 16:30:23 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 28 Sep 2022 16:30:23 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v22]
In-Reply-To: <BY1Cgckwh4iA2FaUgv5SJBbgcM1V-KFTP8e8okQXJk8=.75da7e57-c703-493f-a83e-258a8122ac80@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <BY1Cgckwh4iA2FaUgv5SJBbgcM1V-KFTP8e8okQXJk8=.75da7e57-c703-493f-a83e-258a8122ac80@github.com>
Message-ID: <OP22DTjuf3PEnN5GIT3tSST9ok-cJS9zar9rdZEM8JY=.39f6aad9-2c26-4b7d-91a3-ea31cb943b75@github.com>

On Mon, 26 Sep 2022 21:20:54 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Import order - Comments
>   
>   - Corrects import declaration order.
>   - Removes comments

I've submitted a test job with this fix.

Should it be an enhancement?

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

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Wed Sep 28 17:13:42 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 28 Sep 2022 17:13:42 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v23]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

   Moves jtreg tags to the class declaration
  
  Comment with tags isn't collapsed when viewed in an IDE if it's placed before the class declaration.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/25acef0e..070462e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=21-22

  Stats: 12 lines in 1 file changed: 6 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9825.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9825/head:pull/9825

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Wed Sep 28 17:23:55 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 28 Sep 2022 17:23:55 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v30]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <EPL4dHZoHtEn9bpIP_ivCsL28Of-xpAsgXRb6VCQUtw=.570db081-c7d9-476e-94c0-aa2ca4c66452@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 KB.
> Manual Test Case "FileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  modifiers order changed as per review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/6d2b9557..b4361c32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=28-29

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Wed Sep 28 17:23:56 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 28 Sep 2022 17:23:56 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v29]
In-Reply-To: <8HyTZlh3KG49Rz1mqXm8QryD7QTwzY7ESyrxa5C0EE4=.2b4630bd-b327-4feb-858e-87f8d9671f06@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <67J5y7EUu-fv68E35nDZIr7VVFjvhpJQOVpPQ-knbVo=.afe79c4e-8a9c-4146-9fc7-c0d29f211f66@github.com>
 <8HyTZlh3KG49Rz1mqXm8QryD7QTwzY7ESyrxa5C0EE4=.2b4630bd-b327-4feb-858e-87f8d9671f06@github.com>
Message-ID: <UOEEvJEyXag5CqPTjwNw6grjqT-al617JtidG3bN4t0=.6375b059-998e-4e8a-a573-bbce0a574546@github.com>

On Mon, 26 Sep 2022 21:08:45 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment fix
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1127:
> 
>> 1125:         JFileChooser chooser;
>> 1126:         DateFormat df;
>> 1127:         final static double baseFileSize = 1000.0;
> 
> let's use blessed modifiers order: `static final`

@turbanoff @aivanov-jdk Modifier's order updated.

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

PR: https://git.openjdk.org/jdk/pull/9327


From achung at openjdk.org  Wed Sep 28 17:31:39 2022
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 28 Sep 2022 17:31:39 GMT
Subject: RFR: 8292214: Memory leak in getAllConfigs of
 awt_GraphicsEnv.c:386 [v2]
In-Reply-To: <1gj0XMmbPLGkiWBwJ09LeKvujGCrLa45Qm5utSp-dCI=.1c9f3e8d-4ef4-4e4e-8a57-cd288645b961@github.com>
References: <1gj0XMmbPLGkiWBwJ09LeKvujGCrLa45Qm5utSp-dCI=.1c9f3e8d-4ef4-4e4e-8a57-cd288645b961@github.com>
Message-ID: <kFLmxT7O_yBBjqAU_la48ZaHBNi9ark3rAnDZU7zzjg=.a36db9ef-99d2-428b-8611-485b1dc9cbe5@github.com>

> changed return to cleanup in getAllConfigs
> changed cleanup to loop thru and free all allocated memory adjacent to graphicsConfig pointer

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

  changed loop end condition to ind-1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10378/files
  - new: https://git.openjdk.org/jdk/pull/10378/files/7d1b778d..687c55db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10378&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10378&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/10378


From duke at openjdk.org  Wed Sep 28 21:57:21 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 28 Sep 2022 21:57:21 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v23]
In-Reply-To: <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>
Message-ID: <CeOVhL5uh1g3o3K6MMyo2uVQCqsvTxDEH0Zzby_GsHQ=.9ecf0ba4-db9c-49ba-a52c-5f6d5dc69d73@github.com>

On Wed, 28 Sep 2022 17:13:42 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>    Moves jtreg tags to the class declaration
>   
>   Comment with tags isn't collapsed when viewed in an IDE if it's placed before the class declaration.

1. > Should it be an enhancement?
    This PR 
    - corrects or changes `Orange` value in (bug ?)
    - adds new values + improve performance (enhancements)
    So I think it's rather an enhancement.
    Why is it important to qualifying this ?

2. Could we consider once more times @SWinxy 's Aug 16 comment about color instance ?

    ```
    ...
            String color = colorNames.get(strlc);
            if (color != null) {
                return hexToColor(color);
            }
            // sometimes get specified without leading #
            return hexToColor(str);
        }
    }

    private static final Map<String, String> colorNames =
        Map.ofEntries(
            Map.entry("aliceblue", "#f0f8ff")),
            Map.entry("antiquewhite", "#faebd7"),
            Map.entry("aqua", "#00ffff"),
    ...
    ```
    Another way to proceed would be that Map returns the `int value` of the color, then we can return a `new Color(value)`.

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

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Wed Sep 28 22:01:12 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 28 Sep 2022 22:01:12 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v6]
In-Reply-To: <H9ZyHAwU7hduXZJoyi9mL_ZmmDx0uO963irsWJfTMVA=.3951ff9b-2aa5-4f7e-bd00-b2bd3752553c@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <592sDW2VIvByGwKDoAYG5P7a4Iygc5CYtPVG7vr9qrk=.12f3db5e-a3a7-41c6-b5f9-e1588507bbe2@github.com>
 <DmaK20O4iPQJGHZyci3IQEsFFbdhnBgMmB4Aok-GE9g=.4884358d-108b-4115-a948-180727268137@github.com>
 <qNrVXI_sLUl_nLStcratdK-OUhBax_v9z2vm7tMDTGs=.7d8763f5-0985-4015-bb29-06b89d44593c@github.com>
 <32gcqBPrkOpDtMLmeh7KGGnXrYf-4VMabEXYPOt0rFY=.8fc58c48-dd7e-4444-9344-7f2ba33bc7a9@github.com>
 <9r8cFmlOw3FVG1jvE974QoOW7Aph9MnUWnj5w44bBR8=.a077b623-99dd-4f8b-83fa-bd6054d7616d@github.com>
 <MiYK_L_hYq3_D6HdHWSeQ6POVfmjc2KiOiJhetL2uH4=.df7929eb-d6a9-423d-bf0d-0255782d466b@github.com>
 <H9ZyHAwU7hduXZJoyi9mL_ZmmDx0uO963irsWJfTMVA=.3951ff9b-2aa5-4f7e-bd00-b2bd3752553c@github.com>
Message-ID: <IABzNOAMVAPF3uX26tLrBpNG79oPsJleWRdsaM8Mo-c=.20dcb7e6-1c39-4308-aaa9-54b589934794@github.com>

On Tue, 27 Sep 2022 02:40:45 GMT, ScientificWare <duke at openjdk.org> wrote:

>>> Could we reach a conciliation with this version. ? All cases are treated in 2 or 3 tests.
>> 
>> Your new versions introduce one more condition to each case and make the code more complicated and less clear. I am for concise, clear and readable code. I am against premature optimisation, and it hasn't been proved yet that there's a performance issue.
>> 
>> Combining the cases of `n == 3` and `n == 4` avoids code duplication by introducing one more comparison to both cases. If this becomes a critical path, JIT could optimise the code.
>> 
>> As such, I am still for combining these two cases. If you insist, I'm okay with your original code with code duplication. Yet I'd like to eliminate the duplicate code.
>> 
>>> Some articles suggest to avoid using exceptions as flow controls. I never tested this point. That's why I introduced Patterns in this method.
>> 
>> It's true, creating an exception object is a somewhat expensive operation. Yet you say, ?_most_ of color notations are correct?, therefore an incorrect color which cannot be parsed is rare, so it's _an exceptional situation_, it is okay to use exceptions in this case. You also say, ?Pattern usage has a significant time cost,? at the same time, you introduce a small time penalty for each and every correct color.
>> 
>> I think the hex pattern is redundant.
>> 
>>> I also wish to test the version with bit rotation too :
>>> 
>>> ```java
>>>             return new Color(Integer.rotateRight(Integer.parseUnsignedInt(digits, 16),8),
>>>                             true);
>>> ```
>> 
>> It could be not as clear, yet it works.
>> 
>> May I suggest wrapping the code for `Color` and `rotateRight` arguments?
>> 
>> 
>>             return new Color(
>>                     Integer.rotateRight(Integer.parseUnsignedInt(digits, 16),
>>                                         8),
>>                     true);
>> 
>> 
>> It fits better into 80-column limit. Alternatively, wrap the second parameter of `rotateRight` only:
>> 
>>             return new Color(Integer.rotateRight(Integer.parseUnsignedInt(digits, 16),
>>                                                  8),
>>                              true);
>> 
>> This way it's easier to see how many bits are rotated.
>
> @aivanov-jdk My previous proposition perfectly respected all your suggestions and didn't introduce a new test.
> 
> But this discussion should be outdated if you validate this new approach. Performance results came from my repository I mentioned in the header.
> - Our previous codes ran in 1 200ms to 1800 ms with `String` + `formatted` + `%n$s` usage.
> - They ran in 350ms to 380ms with `String` + `formatted` + `%s` usage.
> - And in 100ms to 110ms if we replace `String` + `format` with a string concatenation.
> - Now the code below gives the same results in 45ms. Since we control notation length we 
>    - can bypass some controls,
>    - directly generate the color value,
>    - without generate a new string, 
>    - and reject a wrong number format without generate any exception.
> 
> 
>     static final Color hexToColor(String digits) {
>         int st = 0;
>         if (digits.startsWith("#")) {
>             st = 1;
>         }
>         // CSS level 4
>         // - defines color hex code as #[2 digits Red][2 digits Green][2 digits Blue][2 digits Alpha]. With digit 0 ... f.
>         // - allows, webpage passes 3, 4, 6 or 8 digit color code.
>         //   - 3 digits #[R][G][B] ........ represents #[RR][GG][BB]FF
>         //   - 4 digits #[R][G][B][A] ..... represents #[RR][GG][BB][AA]
>         //   - 6 digits #[RR][GG][BB] ..... represents #[RR][GG][BB]FF
>         //   - 8 digits #[RR][GG][BB][AA] . represents #[RR][GG][BB][AA]
>         //
>         // Becareful ! In java.awt.Color hex #[2 digits Alpha][2 digits Red][2 digits Green][2 digits Blue]
>         // Comme cette m?thode est d?finie dans CSS, elle doit traiter uniquement le format CSS Leve 4.
>         //
>         // According notes below the current OpenJDK implementation is
>         // - 3 digits #[R][G][B]    represents #[RR][GG][BB]FF
>         // - 6 digits #[R][G][B]    represents #[RR][GG][BB]FF
>         //
>         // Some webpage passes 3 digit color code as in #fff which is
>         // decoded as #000FFF resulting in blue background.
>         // As per https://www.w3.org/TR/CSS1/#color-units,
>         // The three-digit RGB notation (#rgb) is converted into six-digit form
>         // (#rrggbb) by replicating digits, not by adding zeros.
>         // This makes sure that white (#ffffff) can be specified with the short notation
>         // (#fff) and removes any dependencies on the color depth of the display.
>         byte[] idseq;
>         if ((idseq  = digit.get(Integer.valueOf(digits.length() - st))) == null) {
>             // Rejects string argument with a wrong number length.
>             return null;
>         }
>         // Only 3, 4, 6 and 8 digits notations.
>         long value = 0;
>         // Parses the string argument and build color value
>         for (byte i : idseq) {
>             value *= 16;
>             int dv = 15;
>             if (i != -1) {
>                 if ((dv = Character.digit(digits.charAt(st + i), 16)) < 0) {
>                     // Rejects string argument with not a valid digit in the radix-16
>                     return null;
>                 }
>             }
>             value += dv;
>         }
>         return new Color((int)value, true);
>     }
> 
>     // Index of the Digit in the Sequence
>     private static Map<Integer, byte[]> digit =
>         Map.ofEntries(
>             Map.entry(Integer.valueOf(3), new byte[]{-1, -1, 0, 0, 1, 1, 2, 2}),
>             Map.entry(Integer.valueOf(4), new byte[]{3, 3, 0, 0, 1, 1, 2, 2}),
>             Map.entry(Integer.valueOf(6), new byte[]{-1, -1, 0, 1, 2, 3, 4, 5}),
>             Map.entry(Integer.valueOf(8), new byte[]{6, 7, 0, 1, 2, 3, 4, 5})
>         );

Should I declare `idseq` as `final` for the same reasons `a`, `b`, `c` were declared `final` in the previous version.

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

PR: https://git.openjdk.org/jdk/pull/10317


From duke at openjdk.org  Wed Sep 28 22:12:55 2022
From: duke at openjdk.org (SWinxy)
Date: Wed, 28 Sep 2022 22:12:55 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v6]
In-Reply-To: <nVCzpDMzdY4CIXSx27BsR53YexilKhIyiKF3f_ticDw=.bfb3f7c1-cd41-43ec-9eda-2f807dad5e5a@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <x2YkLZxgXHqVe6EdebqiIfQQynJxBYC7PuQM0U11YFg=.d703dec2-14b6-499d-8a32-20aac151b8ea@github.com>
 <nVCzpDMzdY4CIXSx27BsR53YexilKhIyiKF3f_ticDw=.bfb3f7c1-cd41-43ec-9eda-2f807dad5e5a@github.com>
Message-ID: <Fryh6yySVjbva3NcscyhoeoWZ5P7BJ92BywQF-czMmE=.ee373a90-2622-4627-8ef8-259c5420e0a5@github.com>

On Mon, 22 Aug 2022 00:57:28 GMT, SWinxy <duke at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removes whitespace.
>>   
>>   Remove a whitespace at the end of the file
>
> I mean I think I would *prefer* the switch over a map (it looks nicer to me). My crude tests showed that the switch is indeed slower, breaking my conception that switch statements are the peak of performance. Other than [this request](#issuecomment-1216011827), I have no further comments.

> Could we consider once more times @SWinxy 's Aug 16 comment about color instance ?

Are you talking about [keeping the old behavior](https://github.com/openjdk/jdk/pull/9825#issuecomment-1216011827)? If so, your proposed solution looks to work (also reminder that `.contains(Object)` exists).

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

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Wed Sep 28 22:43:45 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 28 Sep 2022 22:43:45 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v23]
In-Reply-To: <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>
Message-ID: <bwLlrLD0TNp-80BvNsWNP94J9qw5FQFtuCXk3VQo8tc=.49998b4c-ff04-4192-91d1-6732afe99185@github.com>

On Wed, 28 Sep 2022 17:13:42 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>    Moves jtreg tags to the class declaration
>   
>   Comment with tags isn't collapsed when viewed in an IDE if it's placed before the class declaration.

> Are you talking about https://github.com/openjdk/jdk/pull/9825#issuecomment-1216011827?

@SWinxy Yes, only because the result is publicly exposed : `stringToColor` is also used by `javax.swing.text.html.StyleSheet stringToColor` method to publicly return the `Color` Object. It seems unique, I didn't see any other usages.

> also reminder that .contains...(Object) exists

I saw these methods but in our case we need a result anyway. Using `containsKey(Object)` implies a second request to get the value ?

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

PR: https://git.openjdk.org/jdk/pull/9825


From psadhukhan at openjdk.org  Thu Sep 29 09:24:21 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 29 Sep 2022 09:24:21 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v5]
In-Reply-To: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
Message-ID: <HQPlAV7lkCCFzh42RwBr90FO9wYR7ABZPveikPKsbF4=.a6698d86-f325-4e56-8eaf-7d9ba65af40d@github.com>

> Label.foreground UIProperty is not honored by Nimbus L&F.
> Added support for setting JLabel foreground color for Nimbus L&F

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

  Test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9900/files
  - new: https://git.openjdk.org/jdk/pull/9900/files/22291af1..fd80f96a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9900&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9900&range=03-04

  Stats: 10 lines in 1 file changed: 0 ins; 6 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9900.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9900/head:pull/9900

PR: https://git.openjdk.org/jdk/pull/9900


From psadhukhan at openjdk.org  Thu Sep 29 09:24:25 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 29 Sep 2022 09:24:25 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v4]
In-Reply-To: <MnWdeVZZxAh5XmVPekT8R9VJwCGgi7nbURE4Zbu1qWM=.c23996fa-5534-4782-a9f8-4991217428ed@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
 <kPO8rq5DlNOCVSfbVwlKvmJizc16E4gVMfM9x4OLcis=.c81ceeb9-85f2-4059-8a7c-1f9f859f1447@github.com>
 <MnWdeVZZxAh5XmVPekT8R9VJwCGgi7nbURE4Zbu1qWM=.c23996fa-5534-4782-a9f8-4991217428ed@github.com>
Message-ID: <Ojo5cf3e6kCvorjcWk6pE__RnPpfU-oaqrnfBeGrAbQ=.fbdb3328-6ec8-4b42-a0c8-cf59399aceee@github.com>

On Wed, 28 Sep 2022 15:03:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test fix
>
> test/jdk/javax/swing/plaf/nimbus/TestNimbusLabel.java line 47:
> 
>> 45: {
>> 46:     private static JFrame frame;
>> 47:     private static int colorTolerance = 5;
> 
> Let's add `final` to the constant.

ok

> test/jdk/javax/swing/plaf/nimbus/TestNimbusLabel.java line 106:
> 
>> 104:                     robot.createScreenCapture(new Rectangle(p.x, p.y,
>> 105:                             d.width,
>> 106:                             d.height));
> 
> Suggestion:
> 
>                     robot.createScreenCapture(new Rectangle(p, d));

ok

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

PR: https://git.openjdk.org/jdk/pull/9900


From aivanov at openjdk.org  Thu Sep 29 10:29:17 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 29 Sep 2022 10:29:17 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v23]
In-Reply-To: <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>
Message-ID: <1v2bQKuJRMqfAT8Vc8xydQxtl4iWTbj6Rr89RQaBIys=.a817f90d-8ccb-4ee0-93e0-64d04118fe6c@github.com>

On Wed, 28 Sep 2022 17:13:42 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>    Moves jtreg tags to the class declaration
>   
>   Comment with tags isn't collapsed when viewed in an IDE if it's placed before the class declaration.

> > Are you talking about [#9825 (comment)](https://github.com/openjdk/jdk/pull/9825#issuecomment-1216011827)?
> 
> @SWinxy Yes, only because the result is publicly exposed : `stringToColor` is also used by `javax.swing.text.html.StyleSheet stringToColor` method to publicly return the `Color` Object. It seems unique, I didn't see any other usages.
> 
> > also reminder that .contains...(Object) exists
> 
> I saw these methods but in our case we need a result anyway. Using `containsKey(Object)` implies a second request to get the value ?

I thought we had closed [this discussion](https://github.com/openjdk/jdk/pull/9825#issuecomment-1216011827):

A `Color` object is immutable, it is safe to return it as it's stored in the internal map. The fact that the previous implementation returned a new instance each time `stringToColor` was called is an implementation detail, no one should have relied on it.

@scientificware is right, we need the result anyway, so the code in the PR is more efficient:
https://github.com/openjdk/jdk/pull/9825/files#diff-e2c9b23b1844fa877fb1c4f048a8a8b85cd21d146f963837e039ab20b9560fe7R1409-R1412

It looks up a color in the map once whereas

        if (colorNamed.containsKey(str.toLowerCase(Locale.ROOT))) {
            return colorNamed.get(str.toLowerCase(Locale.ROOT));
        }

performs the look up twice: for `containsKey` and for `get`.

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

PR: https://git.openjdk.org/jdk/pull/9825


From aivanov at openjdk.org  Thu Sep 29 10:56:44 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 29 Sep 2022 10:56:44 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v23]
In-Reply-To: <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>
Message-ID: <mwwAdrpWtz5yY3qOuIl9bgj-W3CLBns5L5Yv9bhFNQw=.5858bac2-ef22-4856-9569-171b485c7088@github.com>

On Wed, 28 Sep 2022 17:13:42 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>    Moves jtreg tags to the class declaration
>   
>   Comment with tags isn't collapsed when viewed in an IDE if it's placed before the class declaration.

> > Should it be an enhancement?
> 
> corrects or changes `Orange` value in (bug ?)

It's probably a bug. `'Orange'` shouldn't have been there. Both [HTML 3.2](https://www.w3.org/TR/2018/SPSD-html32-20180315/#body) and [CSS 1](https://www.w3.org/TR/REC-CSS1/#color-units) declare only 16 colors from Windows VGA palette.

> adds new values + improve performance (enhancements)
> 
> So I think it's rather an enhancement.  
> Why is it important to qualifying this?

I've changed the type of the issue from bug to enhancement. This PR changes the specified behaviour of a public method [`StyleSheet.stringToColor`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/text/html/StyleSheet.html#stringToColor(java.lang.String)). It is explicitly specified, ?This will only convert the HTML3.2 color strings or a string of length 7; otherwise, it will return null.? Thus, the current behaviour is *not a bug*. What you propose is an enhancement.

> I've submitted a test job with this fix.

And one JCK (Java Compatibility Kit) test fails, the one which verifies the statement that I quoted above.

You need to update the specification of `StyleSheet.stringToColor`. Once we agree on the text in this PR, I'll submit a CSR for you. This PR can be integrated only after the CSR is approved.

Shall I edit the subject of the issue to be more specific? *?Add named colors from CSS Color Module Level 4??*

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

PR: https://git.openjdk.org/jdk/pull/9825


From tr at openjdk.org  Thu Sep 29 11:21:54 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 29 Sep 2022 11:21:54 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView
Message-ID: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>

When a custom `FileView` is used and folder traversal is restricted to a particular directory NPE occurs when user tries to traverse/select other folders except traversable folder. This is caused because when user selects folder other than traversable, the traversal is rejected and hence no file is selected as `currentDirectory` of `JFileChooser`. When user tries to access the restricted folder second time, previous selected file check is failing because of NPE since `getFileChooser().getCurrentDirectory();` is null. To fix the issue, NPE check is added.

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

Commit messages:
 - fix

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

PR: https://git.openjdk.org/jdk/pull/10485


From aivanov at openjdk.org  Thu Sep 29 12:22:13 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 29 Sep 2022 12:22:13 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v5]
In-Reply-To: <HQPlAV7lkCCFzh42RwBr90FO9wYR7ABZPveikPKsbF4=.a6698d86-f325-4e56-8eaf-7d9ba65af40d@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
 <HQPlAV7lkCCFzh42RwBr90FO9wYR7ABZPveikPKsbF4=.a6698d86-f325-4e56-8eaf-7d9ba65af40d@github.com>
Message-ID: <CDj1makyjA7UbHWXGUhHEnFQElo3sfYqYbp7HwKbobM=.45bca620-55cf-4222-90f2-d541585245e5@github.com>

On Thu, 29 Sep 2022 09:24:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Label.foreground UIProperty is not honored by Nimbus L&F.
>> Added support for setting JLabel foreground color for Nimbus L&F
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

Changes requested by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9900


From aivanov at openjdk.org  Thu Sep 29 12:22:15 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 29 Sep 2022 12:22:15 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v3]
In-Reply-To: <lWroBhXjkrbKrcN6pibZcch4zSfnr2atXBDRTf0UybQ=.0db44f84-8781-4482-a480-0238109d63e5@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
 <4VvhgKSAGDnjWdmTfvaNCcTsSmOmCQR8UsYNOSmRO5w=.be1165bd-2d1f-44bc-8027-3ae9923617ce@github.com>
 <0L_qtZSknxD6lrlKTqn3f3U2WGYlCIIN2psEZ-dp0Yw=.6ae3b3ad-909d-4959-94ff-59759e79e799@github.com>
 <lWroBhXjkrbKrcN6pibZcch4zSfnr2atXBDRTf0UybQ=.0db44f84-8781-4482-a480-0238109d63e5@github.com>
Message-ID: <f03AaWZQ8ZlmIkRQQMlM4dMjuBi8E0b6rfti6hYF42I=.b7587e10-447b-4121-9022-821cde40a71f@github.com>

On Wed, 28 Sep 2022 06:42:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLabelUI.java line 222:
>> 
>>> 220:             if (fgColor != null) {
>>> 221:                 label.setForeground(fgColor);
>>> 222:             }
>> 
>> Why is the color set to the `label` component during paint?
>> 
>> Shouldn't it be `g.setColor(fgColor)`? And the above code which uses the `context` should be skipped if `fgColor != null`.
>
> There are 2 ways JLabel can be used, one via html label and another normal label. Normal label text will work if we do `g.setColor(fgColor)` but html label will use [StyleSheet.paint](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#L1939) which does not take into account foreground Color (guess unless it's provided by html tags which is not the case here) so I need to explicitly set the foreground color of label

Do other L&Fs respect the `Label.foreground` color if the label text contains HTML?

Why is it set in each paint then? It should be set once in `installDefaults` and it should be removed in `uninstallDefaults`. In addition to that, it is to be installed if and only if `label.setForeground` is `null` or `instanceof UIResource`, and uninstalled if it is `instanceof UIResource`. If the user explicitly set foreground color of the label, it must not be overridden by the L&Fs.

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

PR: https://git.openjdk.org/jdk/pull/9900


From aivanov at openjdk.org  Thu Sep 29 12:29:26 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 29 Sep 2022 12:29:26 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v30]
In-Reply-To: <EPL4dHZoHtEn9bpIP_ivCsL28Of-xpAsgXRb6VCQUtw=.570db081-c7d9-476e-94c0-aa2ca4c66452@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <EPL4dHZoHtEn9bpIP_ivCsL28Of-xpAsgXRb6VCQUtw=.570db081-c7d9-476e-94c0-aa2ca4c66452@github.com>
Message-ID: <ZLSSGMWEcCrMFvGx8zHsCNpYJ0wp09Ha9gdkr10_jFY=.def5813d-5493-415b-b855-f60b63189080@github.com>

On Wed, 28 Sep 2022 17:23:55 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   modifiers order changed as per review comment

src/java.desktop/share/classes/sun/swing/FilePane.java line 1129:

> 1127:         static final double baseFileSize = 1000.0;
> 1128:         final MessageFormat mf = new MessageFormat("");
> 1129:         final NumberFormat nf = NumberFormat.getNumberInstance();

All these three new fields can be declared `private`, they aren't used anywhere else. For the sake of consistency, the existing fields `chooser` and `df` may also be declared `private` if they're unused outside of this class.

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

PR: https://git.openjdk.org/jdk/pull/9327


From rgiulietti at openjdk.org  Thu Sep 29 13:18:11 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 29 Sep 2022 13:18:11 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
Message-ID: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>

This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

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

Commit messages:
 - 8294456: Fix misleading-indentation warnings in JDK

Changes: https://git.openjdk.org/jdk/pull/10487/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10487&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294456
  Stats: 9 lines in 4 files changed: 1 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10487.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10487/head:pull/10487

PR: https://git.openjdk.org/jdk/pull/10487


From rgiulietti at openjdk.org  Thu Sep 29 13:18:11 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 29 Sep 2022 13:18:11 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <UPInEBzT3Pn9XU6eWbUCxoGWPwCPoGDKn9J2BlvhLtA=.21b9cd77-9d0f-4c7d-a69c-044466e6fb6b@github.com>

On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

The misleading indentation might indicate the original intent of the author, which might have forgotten to add braces around the indented code. Anyway, this fix does _not_ address whether the numerical algorithm in itself is correct, it only corrects the indentation.

The original source code also contains misleading indentation, see:
https://netlib.org/fdlibm/e_asin.c
https://netlib.org/fdlibm/k_rem_pio2.c

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

PR: https://git.openjdk.org/jdk/pull/10487


From dfuchs at openjdk.org  Thu Sep 29 13:44:26 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 Sep 2022 13:44:26 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <fpnPIYgJmPMF3y0STHhlFeO7u3X3Q9NW2vw3zKCp2nA=.79198c44-516f-4bae-aa75-3a57d8f4eaea@github.com>

On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

src/java.base/share/native/libfdlibm/e_asin.c line 102:

> 100:             } else
> 101:                 t = x*x;
> 102:             p = t*(pS0+t*(pS1+t*(pS2+t*(pS3+t*(pS4+t*pS5)))));

should we add an opening brace after the `else` (and close it before line 102) to make it more obvious that there is no problem with the indentation?

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

PR: https://git.openjdk.org/jdk/pull/10487


From rgiulietti at openjdk.org  Thu Sep 29 13:48:30 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 29 Sep 2022 13:48:30 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <fpnPIYgJmPMF3y0STHhlFeO7u3X3Q9NW2vw3zKCp2nA=.79198c44-516f-4bae-aa75-3a57d8f4eaea@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <fpnPIYgJmPMF3y0STHhlFeO7u3X3Q9NW2vw3zKCp2nA=.79198c44-516f-4bae-aa75-3a57d8f4eaea@github.com>
Message-ID: <Aw2E36VRLuXt9hakw3jP_PjI26OTtnLnuhxBGsgSc8E=.9f9b3eda-c70d-42c6-b562-5e71cce671b4@github.com>

On Thu, 29 Sep 2022 13:40:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.
>
> src/java.base/share/native/libfdlibm/e_asin.c line 102:
> 
>> 100:             } else
>> 101:                 t = x*x;
>> 102:             p = t*(pS0+t*(pS1+t*(pS2+t*(pS3+t*(pS4+t*pS5)))));
> 
> should we add an opening brace after the `else` (and close it before line 102) to make it more obvious that there is no problem with the indentation?

It seems that this code is almost a verbatim copy of the upstream code available on the indicated link.
So, while I agree that it would be better to add braces, it would make the code diverge from the upstream source, even if the change would be benign. and welcome

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

PR: https://git.openjdk.org/jdk/pull/10487


From duke at openjdk.org  Thu Sep 29 14:13:23 2022
From: duke at openjdk.org (ScientificWare)
Date: Thu, 29 Sep 2022 14:13:23 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v23]
In-Reply-To: <mwwAdrpWtz5yY3qOuIl9bgj-W3CLBns5L5Yv9bhFNQw=.5858bac2-ef22-4856-9569-171b485c7088@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>
 <mwwAdrpWtz5yY3qOuIl9bgj-W3CLBns5L5Yv9bhFNQw=.5858bac2-ef22-4856-9569-171b485c7088@github.com>
Message-ID: <a7fALFRgfFzlioTz9pDBoqYGg9vOKlxwGBiWCI9yaP8=.ec2c096d-ad6f-48bb-8e08-335ababbce9b@github.com>

On Thu, 29 Sep 2022 10:53:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Shall I edit the subject of the issue to be more specific? ?Add named colors from CSS Color Module Level 4??

Yes, you may. Thanks.

> ... please create a [CSR](https://wiki.openjdk.org/display/csr/Main) request for issue [JDK-8292276](https://bugs.openjdk.org/browse/JDK-8292276) with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

Do I need an access to JBS ? I don't have a JBS user account.

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

PR: https://git.openjdk.org/jdk/pull/9825


From shade at openjdk.org  Thu Sep 29 14:13:31 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 29 Sep 2022 14:13:31 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <IV0KJ9xSrg0X9-i25eNbCa6WRQICVGnQAaJnTuuTdjw=.b3f04a3f-96ac-40b6-b78f-5c84d36f7ba6@github.com>

On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

This looks okay, but let's wait for #10426 to integrate first?

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

PR: https://git.openjdk.org/jdk/pull/10487


From rgiulietti at openjdk.org  Thu Sep 29 14:13:32 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 29 Sep 2022 14:13:32 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <bE3u2RaRGXHflHcePwo6bC_XYMrwijyQ64kUTMGNTiw=.77413ca0-4bd1-46d3-8ce8-7d875e2c1a8a@github.com>

On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

Sure.

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

PR: https://git.openjdk.org/jdk/pull/10487


From dfuchs at openjdk.org  Thu Sep 29 14:18:22 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 Sep 2022 14:18:22 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <Aw2E36VRLuXt9hakw3jP_PjI26OTtnLnuhxBGsgSc8E=.9f9b3eda-c70d-42c6-b562-5e71cce671b4@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <fpnPIYgJmPMF3y0STHhlFeO7u3X3Q9NW2vw3zKCp2nA=.79198c44-516f-4bae-aa75-3a57d8f4eaea@github.com>
 <Aw2E36VRLuXt9hakw3jP_PjI26OTtnLnuhxBGsgSc8E=.9f9b3eda-c70d-42c6-b562-5e71cce671b4@github.com>
Message-ID: <vLqzOCBioAt246Ebl027nhIHB9lD0aHg1nQLWoPxCXs=.c2e8a136-a582-4207-8414-191413576ba2@github.com>

On Thu, 29 Sep 2022 13:44:40 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/native/libfdlibm/e_asin.c line 102:
>> 
>>> 100:             } else
>>> 101:                 t = x*x;
>>> 102:             p = t*(pS0+t*(pS1+t*(pS2+t*(pS3+t*(pS4+t*pS5)))));
>> 
>> should we add an opening brace after the `else` (and close it before line 102) to make it more obvious that there is no problem with the indentation?
>
> It seems that this code is almost a verbatim copy of the upstream code available on the indicated link.
> So, while I agree that it would be better to add braces, it would make the code diverge from the upstream source, even if the change would be benign. and welcome

OK - that's a reasonable concern indeed.

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

PR: https://git.openjdk.org/jdk/pull/10487


From aivanov at openjdk.org  Thu Sep 29 14:37:39 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 29 Sep 2022 14:37:39 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v23]
In-Reply-To: <a7fALFRgfFzlioTz9pDBoqYGg9vOKlxwGBiWCI9yaP8=.ec2c096d-ad6f-48bb-8e08-335ababbce9b@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>
 <mwwAdrpWtz5yY3qOuIl9bgj-W3CLBns5L5Yv9bhFNQw=.5858bac2-ef22-4856-9569-171b485c7088@github.com>
 <a7fALFRgfFzlioTz9pDBoqYGg9vOKlxwGBiWCI9yaP8=.ec2c096d-ad6f-48bb-8e08-335ababbce9b@github.com>
Message-ID: <0rLcSTv9S4Aa7oguUb2NraWLPLDY3KPBtGWyl6yVrkI=.497ae360-f96d-4783-89c4-a25921672dd5@github.com>

On Thu, 29 Sep 2022 14:11:03 GMT, ScientificWare <duke at openjdk.org> wrote:

> > ... please create a [CSR](https://wiki.openjdk.org/display/csr/Main) request for issue [JDK-8292276](https://bugs.openjdk.org/browse/JDK-8292276) with the correct fix version. This pull request cannot be integrated until the CSR request is approved.
> 
> Do I need an access to JBS ? I don't have a JBS user account.

Yes, you do.

I said, I would submit a CSR for you after we agree on the updated javadoc for `StyleSheet.stringToColor`.

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

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Thu Sep 29 14:39:04 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 29 Sep 2022 14:39:04 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v31]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <84Tcbg0LrWSfpvD0bb2Ca6y4T-CNhYVZHVGeTCo0Ef4=.b63d26a1-817f-498d-84b8-39ed3a987dbe@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 KB.
> Manual Test Case "FileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Review comment fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/b4361c32..604d6fd7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=29-30

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Sep 29 14:39:07 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 29 Sep 2022 14:39:07 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v30]
In-Reply-To: <ZLSSGMWEcCrMFvGx8zHsCNpYJ0wp09Ha9gdkr10_jFY=.def5813d-5493-415b-b855-f60b63189080@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <EPL4dHZoHtEn9bpIP_ivCsL28Of-xpAsgXRb6VCQUtw=.570db081-c7d9-476e-94c0-aa2ca4c66452@github.com>
 <ZLSSGMWEcCrMFvGx8zHsCNpYJ0wp09Ha9gdkr10_jFY=.def5813d-5493-415b-b855-f60b63189080@github.com>
Message-ID: <AC0k_qRSFSz7gxqCZmTQokaDmyenJv5AYKMJdo4_y_8=.95dc6843-b064-40e4-ae78-9aa02b731ee7@github.com>

On Thu, 29 Sep 2022 12:27:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   modifiers order changed as per review comment
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1129:
> 
>> 1127:         static final double baseFileSize = 1000.0;
>> 1128:         final MessageFormat mf = new MessageFormat("");
>> 1129:         final NumberFormat nf = NumberFormat.getNumberInstance();
> 
> All these three new fields can be declared `private`, they aren't used anywhere else.
> 
> For the sake of consistency, the existing fields `chooser` and `df` may also be declared `private` if they're unused outside of this class. If modified, both `chooser` and `df` can be `final` too, they're initialised in the constructor and never changed afterwards.

@aivanov-jdk Updated the suggested changes.

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

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Sep 29 15:36:32 2022
From: duke at openjdk.org (Emmanuel Bourg)
Date: Thu, 29 Sep 2022 15:36:32 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes [v6]
In-Reply-To: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
Message-ID: <Swv1MlZIHdX49KF1yvy-ZXupg7S1qyPMl0zovUa2yYk=.cd6d7358-3461-4883-97f0-e97939153237@github.com>

> When a list of icons is set on a window, the most appropiate icon is selected depending on the graphics configuration. But if the graphics configuration changes (because the window is moved to a different screen, or because the DPI settings of the screen is changed), the frame icon isn't updated.
> 
> Here is an example illustrating the issue:
> 
>     public static void main(String[] args) throws Exception {
>         SwingUtilities.invokeLater(() -> {
>             JFrame frame = new JFrame("Window Icon Test");
>             frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>             frame.setSize(400, 300);
>             frame.setVisible(true);
> 
>             List<Image> images = new ArrayList<>();
>             for (int size = 16; size <= 32; size++) {
>                 // create an image displaying the size used
>                 BufferedImage image = new BufferedImage(size, size, BufferedImage.TYPE_INT_ARGB);
>                 Graphics2D g = image.createGraphics();
>                 g.setFont(new Font("dialog", Font.BOLD, 12));
>                 g.setColor(Color.BLACK);
>                 g.drawString(String.valueOf(size), 0, size - (size - g.getFont().getSize()) / 2);
>                 images.add(image);
>             }
> 
>             frame.setIconImages(images);
>         });
>     }
> 
> On Windows if the screen scaling is set to 100% the 16x16 icon is picked from the list. If the scaling of the screen is set to 150% while the application is running, the 16x16 icon is upscaled and looks blurry.
> 
> A way to work around this issue is to listen for graphics configuration changes with:
> 
>     frame.addPropertyChangeListener("graphicsConfiguration", event -> frame.setIconImages(frame.getIconImages()));
> 
> 
> Ideally this should be done automatically by the JDK. Maybe the `WindowPeer` could call `updateIconImages()` when `updateGraphicsData()` or `displayChanged()` is invoked?

Emmanuel Bourg has updated the pull request incrementally with two additional commits since the last revision:

 - Run WindowIconUpdateOnDPIChangingTest on Windows only
 - Don't refresh the frame icon on graphics configuration changes on Linux (needs more testing with various desktop environments)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/6180/files
  - new: https://git.openjdk.org/jdk/pull/6180/files/970ea9b6..e61797a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=6180&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=6180&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/6180


From duke at openjdk.org  Thu Sep 29 15:41:07 2022
From: duke at openjdk.org (Emmanuel Bourg)
Date: Thu, 29 Sep 2022 15:41:07 GMT
Subject: RFR: 8276849: Refresh the window icon on graphics configuration
 changes [v4]
In-Reply-To: <gmxGmnLFpb-ZHVw_p2XBpVsjmbui_pnYQdAQudghMXE=.99dd0fa8-8184-4408-89b4-a6b6e7dc49a7@github.com>
References: <sQX1qwPF9WFfbp512yDqM7OKVvnjrn0FtsCCDHZCByc=.53ea42d6-736b-4829-bb58-a10e4e3d1293@github.com>
 <0oxxlnAHynu4eIJIE8cMzXJlpU7I_CF1kBk4IYSN3YY=.e8b93bca-4b06-4a70-82db-aa608d6bb350@github.com>
 <elb291CEaz1C9fY4_1Md9urOqwoyoKeaU2LPPyCHBsQ=.ba5e0960-5334-4f55-86a4-062367d4e745@github.com>
 <gmxGmnLFpb-ZHVw_p2XBpVsjmbui_pnYQdAQudghMXE=.99dd0fa8-8184-4408-89b4-a6b6e7dc49a7@github.com>
Message-ID: <z8XMQ6V1GjeG5k7fAOnR0E3OvY9fFWAxryUDdAIPNtI=.a9be0674-7346-4413-bf91-645e67bc316f@github.com>

On Thu, 24 Mar 2022 02:35:03 GMT, Phil Race <prr at openjdk.org> wrote:

>> Just tested on macOS 12 with a non Retina screen and OpenJDK 8: the icon displayed in the dock when the test frame is minimized is the 32x32 one. If I add more icons to the list, it picks the biggest one, up to 128x128. Bigger icons are ignored.
>> 
>> The issue observed on Windows doesn't really transpose to macOS, I think I'll revert the change to `LWWindowPeer`.
>
> @ebourg @aivanov-jdk are the remaining issues test issues, or might there still be product issues ?
> No pressure to push but let's not forget about it either.

@prrace @aivanov-jdk Sorry for the hiatus, I've updated the pull request to make it Windows only

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

PR: https://git.openjdk.org/jdk/pull/6180


From duke at openjdk.org  Thu Sep 29 16:13:38 2022
From: duke at openjdk.org (ScientificWare)
Date: Thu, 29 Sep 2022 16:13:38 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v23]
In-Reply-To: <0rLcSTv9S4Aa7oguUb2NraWLPLDY3KPBtGWyl6yVrkI=.497ae360-f96d-4783-89c4-a25921672dd5@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>
 <mwwAdrpWtz5yY3qOuIl9bgj-W3CLBns5L5Yv9bhFNQw=.5858bac2-ef22-4856-9569-171b485c7088@github.com>
 <a7fALFRgfFzlioTz9pDBoqYGg9vOKlxwGBiWCI9yaP8=.ec2c096d-ad6f-48bb-8e08-335ababbce9b@github.com>
 <0rLcSTv9S4Aa7oguUb2NraWLPLDY3KPBtGWyl6yVrkI=.497ae360-f96d-4783-89c4-a25921672dd5@github.com>
Message-ID: <H57-XQFq5cAvI5_-LrQiuWRKU1PvHb_QO7Wis14Zctk=.c2b0fab5-883e-4ae3-a8ed-a1227989df9b@github.com>

On Thu, 29 Sep 2022 14:35:10 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I said, I would submit a CSR for you after we agree on the updated javadoc for StyleSheet.stringToColor.

Sorry, I didn't realize the message was from the bot.

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

PR: https://git.openjdk.org/jdk/pull/9825


From azvegint at openjdk.org  Thu Sep 29 16:31:40 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 29 Sep 2022 16:31:40 GMT
Subject: RFR: 8294595: Add javax/swing/plaf/aqua/CustomComboBoxFocusTest.java
 to problem list
Message-ID: <pG5_FPxTeGpu1F9B4dr7LIT7DVIavlNMAJbZ-7nPhv4=.84b07aec-2f0a-4d8a-acc2-bfa52d162efe@github.com>

Problem listing PR

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

Commit messages:
 - initial

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

PR: https://git.openjdk.org/jdk/pull/10495


From rriggs at openjdk.org  Thu Sep 29 16:31:41 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 29 Sep 2022 16:31:41 GMT
Subject: RFR: 8294595: Add
 javax/swing/plaf/aqua/CustomComboBoxFocusTest.java to problem list
In-Reply-To: <pG5_FPxTeGpu1F9B4dr7LIT7DVIavlNMAJbZ-7nPhv4=.84b07aec-2f0a-4d8a-acc2-bfa52d162efe@github.com>
References: <pG5_FPxTeGpu1F9B4dr7LIT7DVIavlNMAJbZ-7nPhv4=.84b07aec-2f0a-4d8a-acc2-bfa52d162efe@github.com>
Message-ID: <C2DhKtoIfqsnIeLi89NB8wQwew9I3lwnt2Hi1Wca_1E=.4f0e6d17-00a8-400d-b792-7aa78729f9d5@github.com>

On Thu, 29 Sep 2022 16:22:29 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Problem listing PR

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10495


From tr at openjdk.org  Thu Sep 29 16:35:20 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 29 Sep 2022 16:35:20 GMT
Subject: RFR: 5080391: ArrayIndexOutOfBounds during "undo" of Right-to-Left
 text insert
In-Reply-To: <6RcEPyVsdn3GAryyi2QYk3OGfPDUGxFD-W0c_2s8iH4=.b10fa89b-07b7-4e8b-858f-1311d0ffeaae@github.com>
References: <6RcEPyVsdn3GAryyi2QYk3OGfPDUGxFD-W0c_2s8iH4=.b10fa89b-07b7-4e8b-858f-1311d0ffeaae@github.com>
Message-ID: <9wYwdrLSwweOABQB_pGJWw2jkPFFvGf3F5rZL_absnc=.87d5c770-c5e3-4fca-b397-0cd9373e720b@github.com>

On Tue, 27 Sep 2022 11:16:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax.swing.text.AbstractDocument$BranchElement.replace(...) method throws an `ArrayIndexOutOfBoundsException: arraycopy: length -1 is negative` when using an UndoManager on the default document of a JTextArea and you try to undo the insertion of a LEFT-TO-RIGHT language (e.g. Arabic) that is immediately followed by setting the component orientation on the JTextArea.
> 
> This is because System.arrayCopy() is called with -ve length because of the calculation done in AbstractDocment.replace where `src` is of 2bytes because of unicode text causing `nmove` to become -ve if `nchildren` is 1 (an unicode character is inserted)
> 
> System.arrayCopy throws `IndexOutOfBoundsException if:
> 
>     The srcPos argument is negative.
>     The destPos argument is negative.
>     The length argument is negative
> 
> 
> so the fix is made to make  nmove, src, dest +ve
> Also, Element.getElement() can return null which is not checked, causing NPE, if deletion of text is done which results in no element, which is also fixed in the PR
> 
> All jtreg testsuite tests are run without any regression.

Fix is tested and validated. Looks fine to me.

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

Marked as reviewed by tr (Author).

PR: https://git.openjdk.org/jdk/pull/10446


From azvegint at openjdk.org  Thu Sep 29 16:36:19 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 29 Sep 2022 16:36:19 GMT
Subject: Integrated: 8294595: Add
 javax/swing/plaf/aqua/CustomComboBoxFocusTest.java to problem list
In-Reply-To: <pG5_FPxTeGpu1F9B4dr7LIT7DVIavlNMAJbZ-7nPhv4=.84b07aec-2f0a-4d8a-acc2-bfa52d162efe@github.com>
References: <pG5_FPxTeGpu1F9B4dr7LIT7DVIavlNMAJbZ-7nPhv4=.84b07aec-2f0a-4d8a-acc2-bfa52d162efe@github.com>
Message-ID: <MXnNgJ6xN6MRPF7T8Qz1EZ_m3VX5jabwnzv2uotmxQE=.3c4f2b16-f97e-4485-a915-c94da72263f6@github.com>

On Thu, 29 Sep 2022 16:22:29 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Problem listing PR

This pull request has now been integrated.

Changeset: 29c70f1a
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/29c70f1ab7df3b386d326509db48acf91dd124ab
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8294595: Add javax/swing/plaf/aqua/CustomComboBoxFocusTest.java to problem list

Reviewed-by: rriggs

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

PR: https://git.openjdk.org/jdk/pull/10495


From kizune at openjdk.org  Thu Sep 29 19:51:22 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 29 Sep 2022 19:51:22 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v3]
In-Reply-To: <O3RhpyTj4fWb7_7miXFCYpBDg75eWI_6c5BC3DfYSVY=.40dea9d8-237e-4d49-ab77-c77e0fd7d942@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <O3RhpyTj4fWb7_7miXFCYpBDg75eWI_6c5BC3DfYSVY=.40dea9d8-237e-4d49-ab77-c77e0fd7d942@github.com>
Message-ID: <d91TviwV_Rk4dMUEFXe2FCZScKtwF12_ZuGjruoI2hE=.74f786c2-f468-466b-bbd4-30b1f9f0305a@github.com>

On Wed, 21 Sep 2022 18:16:39 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> JInternalFrame background color seems to overflow into the border region. This issue is more prominently seen on Windows - Metal LAF (with fractional scaling, as shown below). The primary reason is border scaling issue as observed in - [JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614) 
>> 
>> The fix involves a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. The test checks the midpoint and corners of borders to check if the internal frame's background color is located out of JInternalFrame.
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/190233555-a7e00f2c-9003-4c11-84fb-207957838c2f.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added local variable for scaled corner

test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 82:

> 80:  * @run main/othervm -Dsun.java2d.uiScale=1 InternalFrameBorderTest
> 81:  * @run main/othervm -Dsun.java2d.uiScale=2 InternalFrameBorderTest
> 82:  */

Are there any differences for the test instructions on mac and linux? If not then why do we keep two identical test headers instead of one that covers both mac and linux with tag `@requires (os.family == "linux" | os.family == "mac")` ?

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

PR: https://git.openjdk.org/jdk/pull/10274


From aturbanov at openjdk.org  Thu Sep 29 20:58:31 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 29 Sep 2022 20:58:31 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v5]
In-Reply-To: <HQPlAV7lkCCFzh42RwBr90FO9wYR7ABZPveikPKsbF4=.a6698d86-f325-4e56-8eaf-7d9ba65af40d@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
 <HQPlAV7lkCCFzh42RwBr90FO9wYR7ABZPveikPKsbF4=.a6698d86-f325-4e56-8eaf-7d9ba65af40d@github.com>
Message-ID: <h1B4ztdqyWU9WJDZVwGnS6ol7K6bor_K547IRAX4bIs=.a2dfb524-5ede-4036-99a7-60e00b8f3f00@github.com>

On Thu, 29 Sep 2022 09:24:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Label.foreground UIProperty is not honored by Nimbus L&F.
>> Added support for setting JLabel foreground color for Nimbus L&F
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLabelUI.java line 74:

> 72:     protected void installDefaults(JLabel c) {
> 73:         updateStyle(c);
> 74:         fgColor =  UIManager.getColor("Label.foreground");

let's remove redundant space after `=`

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

PR: https://git.openjdk.org/jdk/pull/9900


From honkar at openjdk.org  Fri Sep 30 00:19:46 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 30 Sep 2022 00:19:46 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
Message-ID: <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>

> JInternalFrame background color seems to overflow into the border region. This issue is more prominently seen on Windows - Metal LAF (with fractional scaling, as shown below). The primary reason is border scaling issue as observed in - [JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614) 
> 
> The fix involves a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. The test checks the midpoint and corners of borders to check if the internal frame's background color is located out of JInternalFrame.
> 
> ![image](https://user-images.githubusercontent.com/95945681/190233555-a7e00f2c-9003-4c11-84fb-207957838c2f.png)

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

  removed redundant jtreg header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10274/files
  - new: https://git.openjdk.org/jdk/pull/10274/files/ced69a3c..4047f9d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10274&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10274&range=02-03

  Stats: 13 lines in 1 file changed: 0 ins; 12 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10274.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10274/head:pull/10274

PR: https://git.openjdk.org/jdk/pull/10274


From honkar at openjdk.org  Fri Sep 30 00:19:47 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 30 Sep 2022 00:19:47 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v3]
In-Reply-To: <d91TviwV_Rk4dMUEFXe2FCZScKtwF12_ZuGjruoI2hE=.74f786c2-f468-466b-bbd4-30b1f9f0305a@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <O3RhpyTj4fWb7_7miXFCYpBDg75eWI_6c5BC3DfYSVY=.40dea9d8-237e-4d49-ab77-c77e0fd7d942@github.com>
 <d91TviwV_Rk4dMUEFXe2FCZScKtwF12_ZuGjruoI2hE=.74f786c2-f468-466b-bbd4-30b1f9f0305a@github.com>
Message-ID: <wYqtT_LhnVlh-J1DzmfQtLO01j6maXxkVoVikpK6GIQ=.4e0d7944-3d41-4768-bfd0-77d9841a97bb@github.com>

On Thu, 29 Sep 2022 19:47:43 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added local variable for scaled corner
>
> test/jdk/javax/swing/JInternalFrame/InternalFrameBorderTest.java line 82:
> 
>> 80:  * @run main/othervm -Dsun.java2d.uiScale=1 InternalFrameBorderTest
>> 81:  * @run main/othervm -Dsun.java2d.uiScale=2 InternalFrameBorderTest
>> 82:  */
> 
> Are there any differences for the test instructions on mac and linux? If not then why do we keep two identical test headers instead of one that covers both mac and linux with tag `@requires (os.family == "linux" | os.family == "mac")` ?

@azuev-java Thanks for catching it. Removed the redundant header.

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

PR: https://git.openjdk.org/jdk/pull/10274


From darcy at openjdk.org  Fri Sep 30 00:40:24 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 00:40:24 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org
Message-ID: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>

With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.

Updates were made using a shell script. I"ll run a copyright updater before any push.

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

Commit messages:
 - JDK-8294618: Update openjdk.java.net => openjdk.org

Changes: https://git.openjdk.org/jdk/pull/10501/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294618
  Stats: 79 lines in 39 files changed: 0 ins; 0 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501


From darcy at openjdk.org  Fri Sep 30 00:54:05 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 00:54:05 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright.
 - Revert unintended update to binary file.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/b12d774f..2f257762

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=00-01

  Stats: 10 lines in 11 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501


From mikael at openjdk.org  Fri Sep 30 00:54:06 2022
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 30 Sep 2022 00:54:06 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2]
In-Reply-To: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com>
Message-ID: <dFUTds1k1M7DaK_xGvMGBDegFeXy76CIcZ_PLh6gYC4=.188412c8-2ca0-42bb-a284-910d88d53422@github.com>

On Fri, 30 Sep 2022 00:50:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright.
>  - Revert unintended update to binary file.

Marked as reviewed by mikael (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10501


From mikael at openjdk.org  Fri Sep 30 00:54:08 2022
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 30 Sep 2022 00:54:08 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <HiyEDr1oKUXjcBsScaiI_yypZx_j0Gxo9erNEub-bRo=.7e0840cb-c2f4-4f5c-8040-20b76298f3cc@github.com>

On Fri, 30 Sep 2022 00:33:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Switch to https where needed/applicable while at it?

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

PR: https://git.openjdk.org/jdk/pull/10501


From darcy at openjdk.org  Fri Sep 30 01:01:29 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 01:01:29 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v3]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <boxVctVZD3zFCVCc9kH4kEwNs-yE1UY9fP1YMTqCWlc=.171a92b3-ddf2-4e51-b3ec-ae5c5a265487@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Undo manpage update.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/2f257762..04dfc3ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/10501


From darcy at openjdk.org  Fri Sep 30 01:11:45 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 01:11:45 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  http -> https

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/04dfc3ef..cee96d0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=02-03

  Stats: 22 lines in 6 files changed: 0 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501


From darcy at openjdk.org  Fri Sep 30 01:11:45 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 01:11:45 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org
In-Reply-To: <HiyEDr1oKUXjcBsScaiI_yypZx_j0Gxo9erNEub-bRo=.7e0840cb-c2f4-4f5c-8040-20b76298f3cc@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <HiyEDr1oKUXjcBsScaiI_yypZx_j0Gxo9erNEub-bRo=.7e0840cb-c2f4-4f5c-8040-20b76298f3cc@github.com>
Message-ID: <uBCZJHk7h3OFdIKNzXs7DXXlCJUbhiSGt7HZOnDf51Q=.c58467fe-b9cd-4edf-83af-ae99c17c196a@github.com>

On Fri, 30 Sep 2022 00:48:02 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Switch to https where needed/applicable while at it?

Good idea; might as well do the update in a single changeset.

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

PR: https://git.openjdk.org/jdk/pull/10501


From iris at openjdk.org  Fri Sep 30 04:11:19 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 30 Sep 2022 04:11:19 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
Message-ID: <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>

On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

Marked as reviewed by iris (Reviewer).

src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34:

> 32:  * the following link:
> 33:  *
> 34:  * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c

The domain for hg wasn't changed to openjdk.org.  The original URL is correct.

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

PR: https://git.openjdk.org/jdk/pull/10501


From duke at openjdk.org  Fri Sep 30 07:48:25 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 30 Sep 2022 07:48:25 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView
In-Reply-To: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
Message-ID: <oyZt9S-ycXXTii_CiqVuz-ohi3N6fftWYNqcRKkyRzQ=.7cb02cc7-c309-4094-839e-94681d303a98@github.com>

On Thu, 29 Sep 2022 11:12:41 GMT, Tejesh R <tr at openjdk.org> wrote:

> When a custom `FileView` is used and folder traversal is restricted to a particular directory NPE occurs when user tries to traverse/select other folders except traversable folder. This is caused because when user selects folder other than traversable, the traversal is rejected and hence no file is selected as `currentDirectory` of `JFileChooser`. When user tries to access the restricted folder second time, previous selected file check is failing because of NPE since `getFileChooser().getCurrentDirectory();` is null. To fix the issue, NPE check is added.

The instruction are not quite clear. Can you please modify it as we discussed over call?

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

PR: https://git.openjdk.org/jdk/pull/10485


From tr at openjdk.org  Fri Sep 30 10:57:37 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 30 Sep 2022 10:57:37 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView [v2]
In-Reply-To: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
Message-ID: <6rp5CFsnwWEFcZIPVtNzQ4X31svC1XhaKVP1kM2lTKQ=.89f0a7c0-969f-4b9d-9df1-e53caaac115b@github.com>

> When a custom `FileView` is used and folder traversal is restricted to a particular directory NPE occurs when user tries to traverse/select other folders except traversable folder. This is caused because when user selects folder other than traversable, the traversal is rejected and hence no file is selected as `currentDirectory` of `JFileChooser`. When user tries to access the restricted folder second time, previous selected file check is failing because of NPE since `getFileChooser().getCurrentDirectory();` is null. To fix the issue, NPE check is added.

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

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10485/files
  - new: https://git.openjdk.org/jdk/pull/10485/files/9b53979f..54ddc88b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10485&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10485&range=00-01

  Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10485.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10485/head:pull/10485

PR: https://git.openjdk.org/jdk/pull/10485


From tr at openjdk.org  Fri Sep 30 11:01:26 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 30 Sep 2022 11:01:26 GMT
Subject: RFR: 6616245: NullPointerException when using JFileChooser with a
 custom FileView
In-Reply-To: <oyZt9S-ycXXTii_CiqVuz-ohi3N6fftWYNqcRKkyRzQ=.7cb02cc7-c309-4094-839e-94681d303a98@github.com>
References: <BDdx397Dy-SA3PL-JIX0wIql_iWGYxncQd5Rpp2Qtbc=.88adda48-c76a-4768-8a79-db177c3648e9@github.com>
 <oyZt9S-ycXXTii_CiqVuz-ohi3N6fftWYNqcRKkyRzQ=.7cb02cc7-c309-4094-839e-94681d303a98@github.com>
Message-ID: <yQMRBKl0m2CoMKV2wONrEmtYvay2UDcOz21tl1bLBAQ=.3b0c0505-fcff-437e-b633-7574fdaab6d7@github.com>

On Fri, 30 Sep 2022 07:44:31 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> The instruction are not quite clear. Can you please modify it as we discussed over call?

Updated.

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

PR: https://git.openjdk.org/jdk/pull/10485


From magare31 at gmail.com  Fri Sep 30 11:33:41 2022
From: magare31 at gmail.com (magare31 at gmail.com)
Date: Fri, 30 Sep 2022 07:33:41 -0400
Subject: professional (24-bit) sampled audio support in the Windows native
 implementation of libjsound
Message-ID: <02e901d8d4c0$7dd12ee0$79738ca0$@gmail.com>

Would anyone want to sponsor the following simple bug fix?

 

- The purpose is to enable playback and recording of 24-bit sampled audio on
Windows.  This is already supported on other systems.

- There is no associated bug in the bug database.  I noted it as a "bug" as
the code misunderstands the WAVE RIFF format standards.

- There will be two very small changes to one Windows native cpp file under
libjsound

- I have tested the changes on a jdk build of the latest code.

 

Also, please advise which of these two groups this belongs to: client libs
or core libs?

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220930/23e544ed/attachment.htm>

From kevin.rushforth at oracle.com  Fri Sep 30 12:29:20 2022
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 30 Sep 2022 05:29:20 -0700
Subject: professional (24-bit) sampled audio support in the Windows native
 implementation of libjsound
In-Reply-To: <02e901d8d4c0$7dd12ee0$79738ca0$@gmail.com>
References: <02e901d8d4c0$7dd12ee0$79738ca0$@gmail.com>
Message-ID: <506f19c5-28ae-e606-e7f1-22464793afcb@oracle.com>

Java Sound is in the client-libs area. You can file the bug yourself at 
https://bugreport.java.com/ if you like, or ask the sponsor of your bug 
(when one steps forward) to do it.

If you want to contribute your fix, please see the contributing a patch 
section [1] in the JDK Developers Guide for the next steps.

-- Kevin

[1] https://openjdk.org/guide/#i-have-a-patch-what-do-i-do


On 9/30/2022 4:33 AM, magare31 at gmail.com wrote:
>
> Would anyone want to sponsor the following simple bug fix?
>
> - The purpose is to enable playback and recording of 24-bit sampled 
> audio on Windows.? This is already supported on other systems.
>
> - There is no associated bug in the bug database.? I noted it as a 
> "bug" as the code misunderstands the WAVE RIFF format standards.
>
> - There will be two very small changes to one Windows native cpp file 
> under libjsound
>
> - I have tested the changes on a jdk build of the latest code.
>
> Also, please advise which of these two groups this belongs to: client 
> libs or core libs?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220930/a6d05e08/attachment.htm>

From magare31 at gmail.com  Fri Sep 30 13:33:14 2022
From: magare31 at gmail.com (magare31 at gmail.com)
Date: Fri, 30 Sep 2022 09:33:14 -0400
Subject: professional (24-bit) sampled audio support in the Windows native
 implementation of libjsound
In-Reply-To: <506f19c5-28ae-e606-e7f1-22464793afcb@oracle.com>
References: <02e901d8d4c0$7dd12ee0$79738ca0$@gmail.com>
 <506f19c5-28ae-e606-e7f1-22464793afcb@oracle.com>
Message-ID: <033b01d8d4d1$318c6ed0$94a54c70$@gmail.com>

Thank you.  I am dropping "core-libs" from this thread.  I filed the bug (Bug ID : 9074122).

 

I have included a proposed solution with the bug report.  I would not attempt to contribute for now as, frankly, my experience with git repositories is limited.

 

Anton

 

From: Kevin Rushforth <kevin.rushforth at oracle.com> 
Sent: Friday, September 30, 2022 8:29 AM
To: magare31 at gmail.com; client-libs-dev at openjdk.org; core-libs-dev at openjdk.org
Subject: Re: professional (24-bit) sampled audio support in the Windows native implementation of libjsound

 

Java Sound is in the client-libs area. You can file the bug yourself at https://bugreport.java.com/ if you like, or ask the sponsor of your bug (when one steps forward) to do it.

If you want to contribute your fix, please see the contributing a patch section [1] in the JDK Developers Guide for the next steps.

-- Kevin

[1] https://openjdk.org/guide/#i-have-a-patch-what-do-i-do



On 9/30/2022 4:33 AM, magare31 at gmail.com <mailto:magare31 at gmail.com>  wrote:

Would anyone want to sponsor the following simple bug fix?

 

- The purpose is to enable playback and recording of 24-bit sampled audio on Windows.  This is already supported on other systems.

- There is no associated bug in the bug database.  I noted it as a "bug" as the code misunderstands the WAVE RIFF format standards.

- There will be two very small changes to one Windows native cpp file under libjsound

- I have tested the changes on a jdk build of the latest code.

 

Also, please advise which of these two groups this belongs to: client libs or core libs?

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220930/8461ebcb/attachment.htm>

From ihse at openjdk.org  Fri Sep 30 14:01:18 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Sep 2022 14:01:18 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
Message-ID: <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>

On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

$ grep -rl doc make -e openjdk.java.net
doc/hotspot-unit-tests.html
doc/hotspot-style.html
doc/building.html
doc/hotspot-unit-tests.md
doc/hotspot-style.md
doc/building.md
make/Doctor.gmk
make/jdk/src/classes/build/tools/taglet/Incubating.java
make/autoconf/configure.ac
make/conf/branding.conf


Think you can fix those as well?

Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..?

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

PR: https://git.openjdk.org/jdk/pull/10501


From weijun at openjdk.org  Fri Sep 30 14:18:28 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 30 Sep 2022 14:18:28 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
Message-ID: <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>

On Fri, 30 Sep 2022 04:05:51 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   http -> https
>
> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34:
> 
>> 32:  * the following link:
>> 33:  *
>> 34:  * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
> 
> The domain for hg wasn't changed to openjdk.org.  The original URL is correct.

Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`?

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

PR: https://git.openjdk.org/jdk/pull/10501


From azvegint at openjdk.org  Fri Sep 30 14:55:38 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 30 Sep 2022 14:55:38 GMT
Subject: RFR: 8292214: Memory leak in getAllConfigs of
 awt_GraphicsEnv.c:386 [v2]
In-Reply-To: <kFLmxT7O_yBBjqAU_la48ZaHBNi9ark3rAnDZU7zzjg=.a36db9ef-99d2-428b-8611-485b1dc9cbe5@github.com>
References: <1gj0XMmbPLGkiWBwJ09LeKvujGCrLa45Qm5utSp-dCI=.1c9f3e8d-4ef4-4e4e-8a57-cd288645b961@github.com>
 <kFLmxT7O_yBBjqAU_la48ZaHBNi9ark3rAnDZU7zzjg=.a36db9ef-99d2-428b-8611-485b1dc9cbe5@github.com>
Message-ID: <DLbk4bvKzqMPSS9pMCgUFCB_PmTnMpJ9Ua8GnoP92dc=.38fa8b6b-279d-4d04-ae5b-4a43e573b6f4@github.com>

On Wed, 28 Sep 2022 17:31:39 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> changed return to cleanup in getAllConfigs
>> changed cleanup to loop thru and free all allocated memory adjacent to graphicsConfig pointer
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed loop end condition to ind-1

Marked as reviewed by azvegint (Reviewer).

src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c line 575:

> 573: cleanup:
> 574:     if (success != JNI_TRUE) {
> 575:         for (int i = 0; i < ind-1; i++) {

New `int i` declaration shadows previously declared `i`, I think it can be reused.

src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c line 576:

> 574:     if (success != JNI_TRUE) {
> 575:         for (int i = 0; i < ind-1; i++) {
> 576:             if (graphicsConfigs[i] != 0) {

It it fine as it is, but this check can be omitted since `free` is no-op for null pointer arguments.

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

PR: https://git.openjdk.org/jdk/pull/10378


From joe.darcy at oracle.com  Fri Sep 30 04:41:06 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 29 Sep 2022 21:41:06 -0700
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
Message-ID: <857259f1-daa2-46a0-ded8-24d866482707@oracle.com>

Thanks for catching that Iris; I'll changes those to git URLs.

-Joe

On 9/29/2022 9:11 PM, Iris Clark wrote:
> On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>>>
>>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    http -> https
> Marked as reviewed by iris (Reviewer).
>
> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34:
>
>> 32:  * the following link:
>> 33:  *
>> 34:  * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
> The domain for hg wasn't changed to openjdk.org.  The original URL is correct.
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/10501


From prr at openjdk.org  Fri Sep 30 17:42:29 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 30 Sep 2022 17:42:29 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
 <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>
Message-ID: <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>

On Fri, 30 Sep 2022 14:16:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34:
>> 
>>> 32:  * the following link:
>>> 33:  *
>>> 34:  * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
>> 
>> The domain for hg wasn't changed to openjdk.org.  The original URL is correct.
>
> Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`?

This is correct.
AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../"

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

PR: https://git.openjdk.org/jdk/pull/10501


From aivanov at openjdk.org  Fri Sep 30 17:42:33 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 30 Sep 2022 17:42:33 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v23]
In-Reply-To: <H57-XQFq5cAvI5_-LrQiuWRKU1PvHb_QO7Wis14Zctk=.c2b0fab5-883e-4ae3-a8ed-a1227989df9b@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>
 <mwwAdrpWtz5yY3qOuIl9bgj-W3CLBns5L5Yv9bhFNQw=.5858bac2-ef22-4856-9569-171b485c7088@github.com>
 <a7fALFRgfFzlioTz9pDBoqYGg9vOKlxwGBiWCI9yaP8=.ec2c096d-ad6f-48bb-8e08-335ababbce9b@github.com>
 <0rLcSTv9S4Aa7oguUb2NraWLPLDY3KPBtGWyl6yVrkI=.497ae360-f96d-4783-89c4-a25921672dd5@github.com>
 <H57-XQFq5cAvI5_-LrQiuWRKU1PvHb_QO7Wis14Zctk=.c2b0fab5-883e-4ae3-a8ed-a1227989df9b@github.com>
Message-ID: <snrjcgI0gmw4vKoSorUnH5fup2Zrr6rDFjWvqJklL_A=.09101786-1c67-4742-b490-8216519ef10e@github.com>

On Thu, 29 Sep 2022 16:09:41 GMT, ScientificWare <duke at openjdk.org> wrote:

> "JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color" #10317 could affect this specifications too.

That's right. So you should take it into account. The updated javadoc should reference the color notation in CSS Color Module Level 4.

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

PR: https://git.openjdk.org/jdk/pull/9825


From aivanov at openjdk.org  Fri Sep 30 17:46:21 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 30 Sep 2022 17:46:21 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS [v23]
In-Reply-To: <a7fALFRgfFzlioTz9pDBoqYGg9vOKlxwGBiWCI9yaP8=.ec2c096d-ad6f-48bb-8e08-335ababbce9b@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>
 <mwwAdrpWtz5yY3qOuIl9bgj-W3CLBns5L5Yv9bhFNQw=.5858bac2-ef22-4856-9569-171b485c7088@github.com>
 <a7fALFRgfFzlioTz9pDBoqYGg9vOKlxwGBiWCI9yaP8=.ec2c096d-ad6f-48bb-8e08-335ababbce9b@github.com>
Message-ID: <HtNU4ZI24fXLSGh0IwQQCyxXcxZuPoxm6dYcHXPhU3s=.893025db-bf5f-4af3-a2ec-2c5778050cb5@github.com>

On Thu, 29 Sep 2022 14:11:03 GMT, ScientificWare <duke at openjdk.org> wrote:

> > Shall I edit the subject of the issue to be more specific? ?Add named colors from CSS Color Module Level 4??
> 
> Yes, you may. Thanks.

I have updated the subject in JBS. Please edit the title of this PR accordingly.

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

PR: https://git.openjdk.org/jdk/pull/9825


From joehw at openjdk.org  Fri Sep 30 18:12:25 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 30 Sep 2022 18:12:25 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
Message-ID: <e9sYCA3vCcVdXUjRRnPbEK3Z7Ik5WANQMziL6OStdts=.aa1ad3f4-5d91-485d-b48f-3c59579f1869@github.com>

On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

The ones in java.xml look good to me.

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

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10501


From kizune at openjdk.org  Fri Sep 30 18:39:23 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 30 Sep 2022 18:39:23 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v4]
In-Reply-To: <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <2Ggd01dT_0gfaZs3dTxNyJk0p38CaWYYg_HnsaGBGJg=.7929cd84-78dc-4c21-80c4-770d4316b051@github.com>
Message-ID: <LnUXE4o9e2Z-OO0cQs-loPbl7aZRp4MCaZhMAo5I63w=.799f7cc6-0136-4466-b85d-62fbabd30fa1@github.com>

On Fri, 30 Sep 2022 00:19:46 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> JInternalFrame background color seems to overflow into the border region. This issue is more prominently seen on Windows - Metal LAF (with fractional scaling, as shown below). The primary reason is border scaling issue as observed in - [JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614) 
>> 
>> The fix involves a similar approach as described here https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. The test checks the midpoint and corners of borders to check if the internal frame's background color is located out of JInternalFrame.
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/190233555-a7e00f2c-9003-4c11-84fb-207957838c2f.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed redundant jtreg header

Looks good to me

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

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10274


From honkar at openjdk.org  Fri Sep 30 18:52:24 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 30 Sep 2022 18:52:24 GMT
Subject: RFR: JDK-8015739: Background of JInternalFrame is located out of
 JInternalFrame [v2]
In-Reply-To: <19_qFwnjlNliZMAvM2yUUC-lshXahir4C4PxKdf7YJQ=.6144e0b9-88b2-4a67-9822-2ee30b868dbe@github.com>
References: <3MhNJ89856II0gMHYApX72zGgTm_NSRq9Tf6kdxLolw=.6486f993-6fab-4350-b30b-4e8b7d12024a@github.com>
 <-du2igQ7Bn4EWJTLVes8IAxFV79-rZJy4Ew1k1EYRi0=.2bfe3cce-89eb-43b9-893e-d770b3ea22cc@github.com>
 <MLqQD57AUwPmzF3cANN4iN1dNv7s0i4FFs3mOHAAtcM=.9b06fcce-9974-4c92-bd02-2e6a043f2965@github.com>
 <yWnZuZWo48S8WZdc6SXiY6p1mN5T3yX28BTU7xtPRoQ=.7ffb3e5a-6d6b-400b-985d-73b455c5a252@github.com>
 <19_qFwnjlNliZMAvM2yUUC-lshXahir4C4PxKdf7YJQ=.6144e0b9-88b2-4a67-9822-2ee30b868dbe@github.com>
Message-ID: <kj50XoSQHNRizqKjKk312G27MQcHyJiIHXsM7L6gTsU=.28830708-08c1-427a-9882-d33f21c855c8@github.com>

On Wed, 28 Sep 2022 15:17:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @azuev-java Tested FrameBorder and DialogBorder, they have a similar problem to JInternalFrameBorder (border scaling issue). I have created a new JBS issue - **[JDK-8294484](https://bugs.openjdk.org/browse/JDK-8294484)** to track Frame and Dialog Borders of Metal LAF as there is a plan to create a common utility method and refactor the common steps.
>
> Thank you, @honkar-jdk. Once the border handling is unified, fixing `FrameBorder` and `DialogBorder` will be easier and code duplication will be avoided.

Refactoring to create a common utility method is being tracked by - [JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680)

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

PR: https://git.openjdk.org/jdk/pull/10274


From prr at openjdk.org  Fri Sep 30 19:17:22 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 30 Sep 2022 19:17:22 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
Message-ID: <PlQjfMvDRNRyYFL9xVnKoirPgtOk_QhEMl_QbNRnzrU=.0b472944-6d3a-48f2-bc79-ec592df83c79@github.com>

On Tue, 27 Sep 2022 12:14:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.
>> 
>> JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.
>> 
>> That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.
>> 
>> To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:
>> 
>>     public class Subtype extends Supertype {
>> 
>>         @Override
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class Supertype {
>> 
>>         /**
>>          * @throws SuperException general problem
>>          * @throws SubExceptionA  specific problem A
>>          * @throws SubExceptionB  specific problem B
>>          */
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class SuperException extends Exception {
>>     ...
>> 
>>     public class SubExceptionA extends SuperException {
>>     ...
>> 
>>     public class SubExceptionB extends SuperException {
>>     ...
>> 
>> For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:
>> 
>>     public void m()
>>            throws SuperException
>> 
>>     Overrides:
>>         m in class Supertype
>>     Throws:
>>         SuperException - general problem
>>         SubExceptionA - specific problem A
>>         SubExceptionB - specific problem B 
>> 
>> It works for checked and unchecked exceptions, for methods in classes and interfaces.
>> 
>> 
>> If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.
>> 
>> Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.
>> 
>> 
>> [^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
>> [^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert an extraneous change to jdk.javadoc

src/java.desktop/share/classes/javax/imageio/stream/ImageInputStreamImpl.java line 206:

> 204:      * @throws EOFException {@inheritDoc}
> 205:      */
> 206:     public boolean readBoolean() throws IOException {

If the docs end up the same as you say that is fine by me since for the two ImageIO classes
that seems to be what we'd want.

But inheritDoc behaviour is still "surprising".
I've never been sure I understood it and now I'm just sure I don't.

1) The two ImageIO methods don't have @override or *anything* and yet javadoc infers
they'd want to inherit the docs from the interface .. clever javadoc .. I guess I can see
that some doc is better than none so this is OK

2) When it does inherit I'd expected that it copies the EXACT and ENTIRE javadoc
from the super-interface, which for your change to work can't be all its doing.
You've added JUST
/**
 * @throws SomeExceptionSubType blah-blah
 */

and yet javadoc somehow figures out this is to be ADDED to the super-type doc
for the method and not replace it .. ???

3) What the old code was doing seems to me to be "natural" to the extent any of
this does and the fix you are preparing would add to the surprising behaviours ..

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

PR: https://git.openjdk.org/jdk/pull/10449


From rriggs at openjdk.org  Fri Sep 30 20:05:28 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 30 Sep 2022 20:05:28 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <hUV_jxvIYNPdrzCMBxFsRYul-Zlc9hXhJc0ZqdmRXnk=.cecc2fa2-f8ac-452c-b051-cd1876973f7f@github.com>

On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10487


From iris at openjdk.org  Fri Sep 30 20:14:24 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 30 Sep 2022 20:14:24 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <He9lyN2nspc2lonTKoozPa2_rjKBRQ0Y8ZLmqUiUBPw=.f9c857f3-126d-44ac-aa01-53abbc7fe0f8@github.com>

On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10487


From darcy at openjdk.org  Fri Sep 30 20:29:20 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 20:29:20 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v5]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <amUS-nAMV81aBx2GLfnDtuk_O_MhFE1Oi0Sxs2DYy2o=.d8155a10-80d6-4ab2-9f2a-4bc8ee61b96b@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

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

 - Update hg URLs to git.
 - Merge branch 'master' into JDK-8294618
 - http -> https
 - Undo manpage update.
 - Update copyright.
 - Revert unintended update to binary file.
 - JDK-8294618: Update openjdk.java.net => openjdk.org

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/cee96d0a..fbaf3d4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=03-04

  Stats: 2670 lines in 133 files changed: 1729 ins; 406 del; 535 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501


From darcy at openjdk.org  Fri Sep 30 20:29:21 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 20:29:21 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>
Message-ID: <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>

On Fri, 30 Sep 2022 13:59:12 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..?

Yes; I think it is sufficient to update src and doc with this PR.

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

PR: https://git.openjdk.org/jdk/pull/10501


From darcy at openjdk.org  Fri Sep 30 20:29:22 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 20:29:22 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
 <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>
 <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>
Message-ID: <q7j-egb4NojCIVKfF-PxraFVvU3FucPfulisSzexu30=.888b04a2-1624-4de1-a81c-e65e747ccd73@github.com>

On Fri, 30 Sep 2022 17:38:54 GMT, Phil Race <prr at openjdk.org> wrote:

> This is correct. AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../"

Update to persistent git links.

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

PR: https://git.openjdk.org/jdk/pull/10501


From prr at openjdk.org  Fri Sep 30 20:39:19 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 30 Sep 2022 20:39:19 GMT
Subject: RFR: 8294426: Two fingers tap generates wrong mouse modifiers on
 M2 MacBooks
In-Reply-To: <pMlDVWhwKtrWEeQ8aAEn-VRS7zkyOkXQ5IgKfngbsPk=.026a62ec-72ac-4d9a-88b0-21b1c02a2676@github.com>
References: <pMlDVWhwKtrWEeQ8aAEn-VRS7zkyOkXQ5IgKfngbsPk=.026a62ec-72ac-4d9a-88b0-21b1c02a2676@github.com>
Message-ID: <lmrZI5DVAO7XUQ3GuorBJE-ZCImyr7mtzJ5NlwuxOPQ=.40c55899-150c-4dd8-bd96-6f29bcbac3eb@github.com>

On Mon, 26 Sep 2022 17:36:04 GMT, Nikita Provotorov <duke at openjdk.org> wrote:

> Hi there!
> JetBrains has faced with a bug on Apple M2 MacBooks when tapping (_not_ pressing) with two fingers on a trackpad generates wrong mouse modifiers (which are returned by [MouseEvent.getModifiersEx](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx())).
> 
> <s>As far as I see, OpenJDK bug tracker still doesn't contain such a bug and I don't have rights to create a new one, so the PR doesn't refer any id</s> UPD: fixed. Here is the bug link from the JetBrains own tracker: [JBR-4765](https://youtrack.jetbrains.com/issue/JBR-4765/Cannot-invoke-context-menu-by-two-fingers-tapping-on-MacBook-with-M2-chip).
> 
> The bug is 100% reproducible on M2 MacBooks (at least under macOS 12.5). It's also reproducible on M1 MacBooks, but much more rarely (about 10-15% of reproducibility).
> 
> ## Steps to reproduce
> 1. Enable `System Preferences` -> `Trackpad` -> `Tap to click`
> 2. Tap with two fingers in the following app:
> 
> import javax.swing.*;
> import java.awt.event.MouseAdapter;
> import java.awt.event.MouseEvent;
> 
> class MouseWindow {
>     final JFrame frame;
> 
>     MouseWindow() {
>         frame = new JFrame();
>         frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
> 
>         frame.setTitle("Mouse window");
> 
>         frame.addMouseListener(new MouseAdapter() {
>             @Override
>             public void mousePressed(MouseEvent e) {
>                 System.out.println(e);
>             }
>         });
> 
>         frame.pack();
> 
>         frame.setSize(300, 300);
> 
>         frame.setVisible(true);
>     }
> 
>     public static void main(String[] args) {
>         SwingUtilities.invokeLater(MouseWindow::new);
>     }
> }
> 
> 
> ### Expected
> Printed mouse event has `modifiersEx` is `4096` (which is `InputEvent.BUTTON3_DOWN_MASK`)
> 
> ### Actual
> Printed mouse event has `modifiersEx` is `4352` (which is `InputEvent.BUTTON3_DOWN_MASK | InputEvent.META_DOWN_MASK`)
> 
> ## Evaluation
> The following happens when a native mouse event reaches Java:
> 1. `NSEvent.nsToJavaModifiers(0)` called inside [CPlatformResponder.handleMouseEvent():81](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java#L81) returns `0`. Earlier it always returned `4096` (`InputEvent.BUTTON3_DOWN_MASK`) but not in the cases of M2 tapping. For a trackpad press (not a tap) it still returns `4096`;
> 2. So, the `0` modifier comes into MouseEvent constructor which then [goes into MouseEvent.setOldModifiers()](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L800) which [initializes the field MouseEvent.modifiers to the value 4](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L1159) (it's `InputEvent.BUTTON3_MASK`);
> 3. Next, this constructed `MouseEvent` object is pushed into EDT queue.
> 4. Next, when a EDT thread pulls the event from the queue and starts to process it, it goes into `java.awt.LightweightDispatcher.retargetMouseEvent` and [creates a new MouseEvent based on the pulled one](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/Container.java#L4920) with the new value of the modifiers == `getModifiersEx() | getModifiers()`. From the p.2 we know, that `MouseEvent.modifiers` of the pulled event is `4`, so `getModifiersEx() | getModifiers()` is evaluated to `4`.
> 5. Next, the constructor of the new MouseEvent [goes into setNewModifiers()](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L795) (instead of `setOldModifiers` as in p.2) and initializes its own field modifiers to the value `4356` (`InputEvent.BUTTON3_MASK | InputEvent.BUTTON3_DOWN_MASK | InputEvent.META_DOWN_MASK`, see [setNewModifiers():1099](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L1099), [setNewModifiers():1129](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L1129)).
> 6. Thus, an app receives the instance of MouseEvent with `getModifiers()` == `4` and `getModifiersEx()` == `4352` so it thinks there is a `Command` keystroke.
> 
> ## Fixing
> Let's set manually inside `CPlatformResponder.handleMouseEvent` a mouse modifier which corresponds to the pressed button.
> 
> ## What about a regression test
> I've failed to write a regression test using Robot because it somehow forces the correct mouse modifiers (`NSEvent.nsToJavaModifiers()` correctly returns `InputEvent.BUTTON3_DOWN_MASK`), so I wrote a test that directly invokes `CPlatformResponder.handleMouseEvent` via reflection.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java line 83:

> 81:         int jmodifiers = NSEvent.nsToJavaModifiers(modifierFlags);
> 82:         if ((jeventType == MouseEvent.MOUSE_PRESSED) && (jbuttonNumber > MouseEvent.NOBUTTON)) {
> 83:             // 8294426: NSEvent.nsToJavaModifiers returns 0 on M2 MacBooks if the event is generated

You say it returns 0, so you expect to only need to do that if jmodifiers is 0, yet you don't check that.
Why not ?

No way to test this on an M2 so being sure it doesn't regress something is all I can offer here.

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

PR: https://git.openjdk.org/jdk/pull/10429


From prr at openjdk.org  Fri Sep 30 20:46:19 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 30 Sep 2022 20:46:19 GMT
Subject: RFR: 5080391: ArrayIndexOutOfBounds during "undo" of Right-to-Left
 text insert
In-Reply-To: <6RcEPyVsdn3GAryyi2QYk3OGfPDUGxFD-W0c_2s8iH4=.b10fa89b-07b7-4e8b-858f-1311d0ffeaae@github.com>
References: <6RcEPyVsdn3GAryyi2QYk3OGfPDUGxFD-W0c_2s8iH4=.b10fa89b-07b7-4e8b-858f-1311d0ffeaae@github.com>
Message-ID: <svg5hS5K-OQR_85YRGgk-FHqujyV3X1R5Sj2CLfegac=.23cfd45c-56b0-44e3-ae11-832d05c07397@github.com>

On Tue, 27 Sep 2022 11:16:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> javax.swing.text.AbstractDocument$BranchElement.replace(...) method throws an `ArrayIndexOutOfBoundsException: arraycopy: length -1 is negative` when using an UndoManager on the default document of a JTextArea and you try to undo the insertion of a LEFT-TO-RIGHT language (e.g. Arabic) that is immediately followed by setting the component orientation on the JTextArea.
> 
> This is because System.arrayCopy() is called with -ve length because of the calculation done in AbstractDocment.replace where `src` is of 2bytes because of unicode text causing `nmove` to become -ve if `nchildren` is 1 (an unicode character is inserted)
> 
> System.arrayCopy throws `IndexOutOfBoundsException if:
> 
>     The srcPos argument is negative.
>     The destPos argument is negative.
>     The length argument is negative
> 
> 
> so the fix is made to make  nmove, src, dest +ve
> Also, Element.getElement() can return null which is not checked, causing NPE, if deletion of text is done which results in no element, which is also fixed in the PR
> 
> All jtreg testsuite tests are run without any regression.

There's some inconsistency in the bug report and what you pasted from it above.
I'm pretty sure this is all about RIGHT-TO-LEFT and the test is clearly inserting Arabic.

What concerns me here is that whilst using Math.abs() to make sure everything is positive is one thing, but
it isn't clear to me that the end results of the calculations are always correct.
There are various parts to this .. elements, indices into the text .. and the relationship and equivalence isn't clear to me.
If @tprinzing can take a look that would be great.

And test - which appears to be a straight copy of the sample code in the bug report is sufficient to show there's
a bug here and that you are fixing it for that one case of ONE unicode code point but I think the test needs to
be more comprehensive - inserting and then undoing at the beginning and end of some existing text.
I suspect we have no existing test which would uncover a regression being introduced here, so this test needs
to be more comprehensive.

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

PR: https://git.openjdk.org/jdk/pull/10446


From prr at openjdk.org  Fri Sep 30 20:52:32 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 30 Sep 2022 20:52:32 GMT
Subject: RFR: 8278086: [REDO] ImageIO.write() method will throw
 IndexOutOfBoundsException [v2]
In-Reply-To: <cy1Vkb0CECBWHX0F3DDUdhDFGCKhTZlGZ9y35YGayPo=.144df86a-f0eb-4d1e-9bf2-ccf0955d857d@github.com>
References: <m6yQDNwg4jCq1vRHp9i-aaiBjutuSMNboon6xAs8UGQ=.162d3d4c-641f-41d1-8392-ce7bbde96613@github.com>
 <cy1Vkb0CECBWHX0F3DDUdhDFGCKhTZlGZ9y35YGayPo=.144df86a-f0eb-4d1e-9bf2-ccf0955d857d@github.com>
Message-ID: <hTENGHR5qnfSNQCPiAPCHLsuHXoHcait9pGVQ9EyPrs=.58a20567-4da3-410a-b3aa-a6efb663e3e2@github.com>

On Mon, 26 Sep 2022 13:20:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> This is redo of https://bugs.openjdk.org/browse/JDK-8262297
>> In https://bugs.openjdk.org/browse/JDK-8262297 we added similar change but we didnt allow 15bpp image in BMP, because of which many tests which were using USHORT_555_RGB format were failing as reported at https://bugs.openjdk.org/browse/JDK-8278047
>> 
>> There is ambiguity on whether we should support 15bpp BMP encoding also or not as captured in JBS : https://bugs.openjdk.org/browse/JDK-8278086?focusedCommentId=14521952&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14521952
>> 
>> Since adding tighter condition to only allow 0, 1, 4, 8, 16, 24 and 32 bpp is causing many failures. I have modified the check to allow 15bpp also.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove biType variable

src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java line 1463:

> 1461:             return false;
> 1462:         }
> 1463:         if (compressionType == BI_RLE4 && bpp != 4) {

I'm confused. You say you are relaxing the test to allow 15bpp, but I don't see where you're removing
anything that would have rejected 15bpp.

And how does this prevent the un-specified exception being thrown ?

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

PR: https://git.openjdk.org/jdk/pull/10419


From prr at openjdk.org  Fri Sep 30 21:12:39 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 30 Sep 2022 21:12:39 GMT
Subject: RFR: 4756278: RFE: Insufficient API documentation for
 java.awt.Polygon constructor
In-Reply-To: <6ZyhGs5SlC42FDN3ToVFR1XybAsdWBTYzu3JBf_Pxsk=.1813b436-3c16-4686-bc0f-52b7039adb63@github.com>
References: <6ZyhGs5SlC42FDN3ToVFR1XybAsdWBTYzu3JBf_Pxsk=.1813b436-3c16-4686-bc0f-52b7039adb63@github.com>
Message-ID: <UfMZkAvrO62JewSBmoFx1cDIy7-LphcHudwh3NB37as=.0f4b922c-18e0-4cf5-b7f6-e9633384e99a@github.com>

On Mon, 26 Sep 2022 02:49:36 GMT, SWinxy <duke at openjdk.org> wrote:

> Appends: `, copying the array contents of {@code xpoints} and {@code ypoints}` to specify that the arrays in the constructor are explicitly copied.

Marked as reviewed by prr (Reviewer).

Really I'm not sure this is needed.
"Constructs and initializes a Polygon from the specified parameters."
Seems to be quite clear enough. It is "initialized" from these tells you right there that it won't be looking
back at this array afterwards - and there's no API that returns the array of points.

In fact I don't like the idea of saying that it "copying the array contents"
seems a bit too much like saying how the implementation must work. At least it doesn't say it copies
them into  internal arrays .. 

However .. I just noticed there are PROTECTED fields for these arrays. Grumble. Why ?
So someone stupid enough to sub-class Polygon can mess with even the copies.

So OK, let's add the new text but the reason we need it is because of questionable design.

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

PR: https://git.openjdk.org/jdk/pull/10418


From duke at openjdk.org  Fri Sep 30 21:12:40 2022
From: duke at openjdk.org (SWinxy)
Date: Fri, 30 Sep 2022 21:12:40 GMT
Subject: RFR: 4756278: RFE: Insufficient API documentation for
 java.awt.Polygon constructor
In-Reply-To: <6ZyhGs5SlC42FDN3ToVFR1XybAsdWBTYzu3JBf_Pxsk=.1813b436-3c16-4686-bc0f-52b7039adb63@github.com>
References: <6ZyhGs5SlC42FDN3ToVFR1XybAsdWBTYzu3JBf_Pxsk=.1813b436-3c16-4686-bc0f-52b7039adb63@github.com>
Message-ID: <30epa4KDuFfET_2FnTZo4f4eQdSn5yzzrjWn7BGSzlo=.47c5e970-ae62-447e-8085-6ea24826ab11@github.com>

On Mon, 26 Sep 2022 02:49:36 GMT, SWinxy <duke at openjdk.org> wrote:

> Appends: `, copying the array contents of {@code xpoints} and {@code ypoints}` to specify that the arrays in the constructor are explicitly copied.

Alright then. Just an old issue that wasn't really an issue.

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

PR: https://git.openjdk.org/jdk/pull/10418


From duke at openjdk.org  Fri Sep 30 21:12:40 2022
From: duke at openjdk.org (SWinxy)
Date: Fri, 30 Sep 2022 21:12:40 GMT
Subject: RFR: 4756278: RFE: Insufficient API documentation for
 java.awt.Polygon constructor
In-Reply-To: <UfMZkAvrO62JewSBmoFx1cDIy7-LphcHudwh3NB37as=.0f4b922c-18e0-4cf5-b7f6-e9633384e99a@github.com>
References: <6ZyhGs5SlC42FDN3ToVFR1XybAsdWBTYzu3JBf_Pxsk=.1813b436-3c16-4686-bc0f-52b7039adb63@github.com>
 <UfMZkAvrO62JewSBmoFx1cDIy7-LphcHudwh3NB37as=.0f4b922c-18e0-4cf5-b7f6-e9633384e99a@github.com>
Message-ID: <3r-SbyaI4rIUer8bItwHEfkqUzDmdJgWvB9ieanwOL8=.82415de5-a75f-4123-a2e2-ff779acb966b@github.com>

On Fri, 30 Sep 2022 21:00:30 GMT, Phil Race <prr at openjdk.org> wrote:

> So OK, let's add the new text but the reason we need it is because of questionable design.

Mhmm. OK. Unfortunately I do not have a JBS account so I'm unable to add the issue to the CSR board.

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

PR: https://git.openjdk.org/jdk/pull/10418


From prr at openjdk.org  Fri Sep 30 21:22:26 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 30 Sep 2022 21:22:26 GMT
Subject: RFR: 4668290: unclear spec for Polygon.bounds field
In-Reply-To: <jjzwWZJPW8Essivj9svlhO-LScPQV_TlMoC0GGOVgMY=.b5d5ced5-77af-4ce9-8214-10c1cc0392cb@github.com>
References: <jjzwWZJPW8Essivj9svlhO-LScPQV_TlMoC0GGOVgMY=.b5d5ced5-77af-4ce9-8214-10c1cc0392cb@github.com>
Message-ID: <j-9daFz6k8o4wdaBG_HlldjUavIAPaCBdNmC558-RKI=.e1340f43-10cb-4138-85b9-e820ea38ea02@github.com>

On Mon, 26 Sep 2022 02:27:53 GMT, SWinxy <duke at openjdk.org> wrote:

> New documentation replaces the `This value can be null.`:
> 
> When created, {@link #invalidate() invalidated}, or {@link #reset() reset},
> this becomes {@code null}. To get out of the null state,
> {@link #getBounds()} called with {@link #npoints} being greater than
> {@code 0} will transfer into a non-null {@link Rectangle}.
> 
> 
> I think I've got the reason for why it can be `null` correct, but you never know.
> 
> In javax.swing.text.html.Map, I've replaced setting the field to null with the equivalent #invalidate(). This may mean we can make the field private in the future.

src/java.desktop/share/classes/java/awt/Polygon.java line 111:

> 109:      * {@link #getBounds()} called with {@link #npoints} being greater than
> 110:      * {@code 0} will transfer into a non-null {@link Rectangle}.
> 111:      *

Another dubious piece of design. This should never have been exposed in the API.
What we need to say here is
/*
 * The value of this field is updated by the implementation which may set it to null and will
 *   re-evaluate it as needed. Application sub-classes should never access this field.
 */
And leave it at that.

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

PR: https://git.openjdk.org/jdk/pull/10417


From duke at openjdk.org  Fri Sep 30 21:30:25 2022
From: duke at openjdk.org (SWinxy)
Date: Fri, 30 Sep 2022 21:30:25 GMT
Subject: RFR: 4668290: unclear spec for Polygon.bounds field [v2]
In-Reply-To: <jjzwWZJPW8Essivj9svlhO-LScPQV_TlMoC0GGOVgMY=.b5d5ced5-77af-4ce9-8214-10c1cc0392cb@github.com>
References: <jjzwWZJPW8Essivj9svlhO-LScPQV_TlMoC0GGOVgMY=.b5d5ced5-77af-4ce9-8214-10c1cc0392cb@github.com>
Message-ID: <tGt8IEe66tdrP8cHbwmQkTup1WB68ZuobVlLXPdmB_A=.205ea7a4-07dd-4fce-a33d-ccc9920d6cd8@github.com>

> New documentation replaces the `This value can be null.`:
> 
> When created, {@link #invalidate() invalidated}, or {@link #reset() reset},
> this becomes {@code null}. To get out of the null state,
> {@link #getBounds()} called with {@link #npoints} being greater than
> {@code 0} will transfer into a non-null {@link Rectangle}.
> 
> 
> I think I've got the reason for why it can be `null` correct, but you never know.
> 
> In javax.swing.text.html.Map, I've replaced setting the field to null with the equivalent #invalidate(). This may mean we can make the field private in the future.

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

  Reword change based off of Phil's suggestion
  
  Thanks, Phil.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10417/files
  - new: https://git.openjdk.org/jdk/pull/10417/files/f08304a4..7d2e36a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10417&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10417&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/10417


From duke at openjdk.org  Fri Sep 30 21:42:11 2022
From: duke at openjdk.org (Nikita Provotorov)
Date: Fri, 30 Sep 2022 21:42:11 GMT
Subject: RFR: 8294426: Two fingers tap generates wrong mouse modifiers on
 M2 MacBooks
In-Reply-To: <lmrZI5DVAO7XUQ3GuorBJE-ZCImyr7mtzJ5NlwuxOPQ=.40c55899-150c-4dd8-bd96-6f29bcbac3eb@github.com>
References: <pMlDVWhwKtrWEeQ8aAEn-VRS7zkyOkXQ5IgKfngbsPk=.026a62ec-72ac-4d9a-88b0-21b1c02a2676@github.com>
 <lmrZI5DVAO7XUQ3GuorBJE-ZCImyr7mtzJ5NlwuxOPQ=.40c55899-150c-4dd8-bd96-6f29bcbac3eb@github.com>
Message-ID: <R1kzT51mGu8Q4xhd_D_G0ZhfnfeSCrFYqsYZ1lM8Wh0=.000eb4d8-071a-4a7f-bdd9-ac0d438052e0@github.com>

On Fri, 30 Sep 2022 20:35:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> Hi there!
>> JetBrains has faced with a bug on Apple M2 MacBooks when tapping (_not_ pressing) with two fingers on a trackpad generates wrong mouse modifiers (which are returned by [MouseEvent.getModifiersEx](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx())).
>> 
>> <s>As far as I see, OpenJDK bug tracker still doesn't contain such a bug and I don't have rights to create a new one, so the PR doesn't refer any id</s> UPD: fixed. Here is the bug link from the JetBrains own tracker: [JBR-4765](https://youtrack.jetbrains.com/issue/JBR-4765/Cannot-invoke-context-menu-by-two-fingers-tapping-on-MacBook-with-M2-chip).
>> 
>> The bug is 100% reproducible on M2 MacBooks (at least under macOS 12.5). It's also reproducible on M1 MacBooks, but much more rarely (about 10-15% of reproducibility).
>> 
>> ## Steps to reproduce
>> 1. Enable `System Preferences` -> `Trackpad` -> `Tap to click`
>> 2. Tap with two fingers in the following app:
>> 
>> import javax.swing.*;
>> import java.awt.event.MouseAdapter;
>> import java.awt.event.MouseEvent;
>> 
>> class MouseWindow {
>>     final JFrame frame;
>> 
>>     MouseWindow() {
>>         frame = new JFrame();
>>         frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
>> 
>>         frame.setTitle("Mouse window");
>> 
>>         frame.addMouseListener(new MouseAdapter() {
>>             @Override
>>             public void mousePressed(MouseEvent e) {
>>                 System.out.println(e);
>>             }
>>         });
>> 
>>         frame.pack();
>> 
>>         frame.setSize(300, 300);
>> 
>>         frame.setVisible(true);
>>     }
>> 
>>     public static void main(String[] args) {
>>         SwingUtilities.invokeLater(MouseWindow::new);
>>     }
>> }
>> 
>> 
>> ### Expected
>> Printed mouse event has `modifiersEx` is `4096` (which is `InputEvent.BUTTON3_DOWN_MASK`)
>> 
>> ### Actual
>> Printed mouse event has `modifiersEx` is `4352` (which is `InputEvent.BUTTON3_DOWN_MASK | InputEvent.META_DOWN_MASK`)
>> 
>> ## Evaluation
>> The following happens when a native mouse event reaches Java:
>> 1. `NSEvent.nsToJavaModifiers(0)` called inside [CPlatformResponder.handleMouseEvent():81](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java#L81) returns `0`. Earlier it always returned `4096` (`InputEvent.BUTTON3_DOWN_MASK`) but not in the cases of M2 tapping. For a trackpad press (not a tap) it still returns `4096`;
>> 2. So, the `0` modifier comes into MouseEvent constructor which then [goes into MouseEvent.setOldModifiers()](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L800) which [initializes the field MouseEvent.modifiers to the value 4](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L1159) (it's `InputEvent.BUTTON3_MASK`);
>> 3. Next, this constructed `MouseEvent` object is pushed into EDT queue.
>> 4. Next, when a EDT thread pulls the event from the queue and starts to process it, it goes into `java.awt.LightweightDispatcher.retargetMouseEvent` and [creates a new MouseEvent based on the pulled one](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/Container.java#L4920) with the new value of the modifiers == `getModifiersEx() | getModifiers()`. From the p.2 we know, that `MouseEvent.modifiers` of the pulled event is `4`, so `getModifiersEx() | getModifiers()` is evaluated to `4`.
>> 5. Next, the constructor of the new MouseEvent [goes into setNewModifiers()](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L795) (instead of `setOldModifiers` as in p.2) and initializes its own field modifiers to the value `4356` (`InputEvent.BUTTON3_MASK | InputEvent.BUTTON3_DOWN_MASK | InputEvent.META_DOWN_MASK`, see [setNewModifiers():1099](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L1099), [setNewModifiers():1129](https://github.com/openjdk/jdk/blob/5ae6bc23e857535532b59aae674e2b917bbf7284/src/java.desktop/share/classes/java/awt/event/MouseEvent.java#L1129)).
>> 6. Thus, an app receives the instance of MouseEvent with `getModifiers()` == `4` and `getModifiersEx()` == `4352` so it thinks there is a `Command` keystroke.
>> 
>> ## Fixing
>> Let's set manually inside `CPlatformResponder.handleMouseEvent` a mouse modifier which corresponds to the pressed button.
>> 
>> ## What about a regression test
>> I've failed to write a regression test using Robot because it somehow forces the correct mouse modifiers (`NSEvent.nsToJavaModifiers()` correctly returns `InputEvent.BUTTON3_DOWN_MASK`), so I wrote a test that directly invokes `CPlatformResponder.handleMouseEvent` via reflection.
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java line 83:
> 
>> 81:         int jmodifiers = NSEvent.nsToJavaModifiers(modifierFlags);
>> 82:         if ((jeventType == MouseEvent.MOUSE_PRESSED) && (jbuttonNumber > MouseEvent.NOBUTTON)) {
>> 83:             // 8294426: NSEvent.nsToJavaModifiers returns 0 on M2 MacBooks if the event is generated
> 
> You say it returns 0, so you expect to only need to do that if jmodifiers is 0, yet you don't check that.
> Why not ?
> 
> No way to test this on an M2 so being sure it doesn't regress something is all I can offer here.

Actually I mean that it returns 0 if you're tapping without holding any modifiers e.g. keyboard modifiers.
But if you're tapping holding a keyboard modifier it will probably return only this keyboard modifier without `InputEvent.BUTTON3_DOWN_MASK`. I didn't test this case but I would expect it that looking at the implementation of the `NSEvent.nsToJavaModifiers`.

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

PR: https://git.openjdk.org/jdk/pull/10429


From prr at openjdk.org  Fri Sep 30 22:00:23 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 30 Sep 2022 22:00:23 GMT
Subject: RFR: 8292214: Memory leak in getAllConfigs of
 awt_GraphicsEnv.c:386 [v2]
In-Reply-To: <Aa8ffOmqr6gLu2-AjxfI4TOVhsFvWhJ72q70MM-QnZU=.d9e0a9b1-e22c-4473-b5c6-1d54365630d2@github.com>
References: <1gj0XMmbPLGkiWBwJ09LeKvujGCrLa45Qm5utSp-dCI=.1c9f3e8d-4ef4-4e4e-8a57-cd288645b961@github.com>
 <Aa8ffOmqr6gLu2-AjxfI4TOVhsFvWhJ72q70MM-QnZU=.d9e0a9b1-e22c-4473-b5c6-1d54365630d2@github.com>
Message-ID: <TPdgsdJFhNpt4PRz8lMSXPdorxy5v-shd49IzMA-SA8=.ed3f73c2-ea6b-4c2f-8789-6020bf10b8ed@github.com>

On Thu, 22 Sep 2022 04:22:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed loop end condition to ind-1
>
> src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c line 578:
> 
>> 576:             if (graphicsConfigs[i] != 0) {
>> 577:                 free(graphicsConfigs[i]);
>> 578:             }
> 
> It seems  `screenDataPtr->numConfigs` is updated only when `success = JNI_TRUE` and here we are checking if `success != JNI_TRUE` condition, so amnot sure if we will be getting the correct updated configs number.
> I think condition should be `i< ind-1` which is updated before every allocation, but it should be verified.

I think "nConfig" would have been the better value to use.
Look at how the array is allocated and that it is zeroed out
   nConfig = n8p + n12p + n8s + n8gs + n8sg  + n1sg + nTrue + 1;
    graphicsConfigs = (AwtGraphicsConfigDataPtr *)
        calloc(nConfig, sizeof(AwtGraphicsConfigDataPtr));

So it should always be safe.

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

PR: https://git.openjdk.org/jdk/pull/10378


From prr at openjdk.org  Fri Sep 30 22:07:20 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 30 Sep 2022 22:07:20 GMT
Subject: RFR: 4756278: RFE: Insufficient API documentation for
 java.awt.Polygon constructor
In-Reply-To: <3r-SbyaI4rIUer8bItwHEfkqUzDmdJgWvB9ieanwOL8=.82415de5-a75f-4123-a2e2-ff779acb966b@github.com>
References: <6ZyhGs5SlC42FDN3ToVFR1XybAsdWBTYzu3JBf_Pxsk=.1813b436-3c16-4686-bc0f-52b7039adb63@github.com>
 <UfMZkAvrO62JewSBmoFx1cDIy7-LphcHudwh3NB37as=.0f4b922c-18e0-4cf5-b7f6-e9633384e99a@github.com>
 <3r-SbyaI4rIUer8bItwHEfkqUzDmdJgWvB9ieanwOL8=.82415de5-a75f-4123-a2e2-ff779acb966b@github.com>
Message-ID: <fBpwBTMgQmdCuUVqkmneO9qxMXVn96acCY73U9H7WJE=.41bce2df-261c-496c-b92b-413651ec1104@github.com>

On Fri, 30 Sep 2022 21:06:51 GMT, SWinxy <duke at openjdk.org> wrote:

>Unfortunately I do not have a JBS account so I'm unable to add the issue to the CSR board.

You need it for the other one too.
I think the best thing is for you to request one.
See https://openjdk.org/guide/#becoming-an-author

Otherwise 99% of this entire process and bug pushing etc etc will have to be done for you by others .. which isn't really a good balance. Best to pick bugs which involve mostly coding and less bureaucracy.

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

PR: https://git.openjdk.org/jdk/pull/10418


From duke at openjdk.org  Fri Sep 30 22:30:23 2022
From: duke at openjdk.org (Nikita Provotorov)
Date: Fri, 30 Sep 2022 22:30:23 GMT
Subject: RFR: 8294426: Two fingers tap generates wrong mouse modifiers on
 M2 MacBooks
In-Reply-To: <R1kzT51mGu8Q4xhd_D_G0ZhfnfeSCrFYqsYZ1lM8Wh0=.000eb4d8-071a-4a7f-bdd9-ac0d438052e0@github.com>
References: <pMlDVWhwKtrWEeQ8aAEn-VRS7zkyOkXQ5IgKfngbsPk=.026a62ec-72ac-4d9a-88b0-21b1c02a2676@github.com>
 <lmrZI5DVAO7XUQ3GuorBJE-ZCImyr7mtzJ5NlwuxOPQ=.40c55899-150c-4dd8-bd96-6f29bcbac3eb@github.com>
 <R1kzT51mGu8Q4xhd_D_G0ZhfnfeSCrFYqsYZ1lM8Wh0=.000eb4d8-071a-4a7f-bdd9-ac0d438052e0@github.com>
Message-ID: <PUxdE8gZPsQbYpACOxu8liDdcUkkfSua9If_itYkrEQ=.06e28bb0-079c-47c8-8482-baf4d1909d2a@github.com>

On Fri, 30 Sep 2022 21:38:50 GMT, Nikita Provotorov <duke at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java line 83:
>> 
>>> 81:         int jmodifiers = NSEvent.nsToJavaModifiers(modifierFlags);
>>> 82:         if ((jeventType == MouseEvent.MOUSE_PRESSED) && (jbuttonNumber > MouseEvent.NOBUTTON)) {
>>> 83:             // 8294426: NSEvent.nsToJavaModifiers returns 0 on M2 MacBooks if the event is generated
>> 
>> You say it returns 0, so you expect to only need to do that if jmodifiers is 0, yet you don't check that.
>> Why not ?
>> 
>> No way to test this on an M2 so being sure it doesn't regress something is all I can offer here.
>
> Actually I mean that it returns 0 if you're tapping without holding any modifiers e.g. keyboard modifiers.
> But if you're tapping holding a keyboard modifier it will probably return only this keyboard modifier without `InputEvent.BUTTON3_DOWN_MASK`. I didn't test this case but I would expect it that looking at the implementation of the `NSEvent.nsToJavaModifiers`.

I don't have an M2 device to check, but I think (judging to the code) if we add `jmodifiers == 0` check here then users making a tap holding the Control will receive the mouse events with `modifiers` == `CTRL_DOWN_MASK | BUTTON3_MASK | CTRL_MASK`, i.e. without modern `BUTTON3_DOWN_MASK` which is at least unusual and inconvenient.

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

PR: https://git.openjdk.org/jdk/pull/10429


From duke at openjdk.org  Fri Sep 30 22:32:21 2022
From: duke at openjdk.org (SWinxy)
Date: Fri, 30 Sep 2022 22:32:21 GMT
Subject: RFR: 4756278: RFE: Insufficient API documentation for
 java.awt.Polygon constructor
In-Reply-To: <6ZyhGs5SlC42FDN3ToVFR1XybAsdWBTYzu3JBf_Pxsk=.1813b436-3c16-4686-bc0f-52b7039adb63@github.com>
References: <6ZyhGs5SlC42FDN3ToVFR1XybAsdWBTYzu3JBf_Pxsk=.1813b436-3c16-4686-bc0f-52b7039adb63@github.com>
Message-ID: <9otBlr_WO5rFZBwviZn2QgLr9HonjWkVHYKpKlgwrFI=.ad0b8fd2-4890-4795-84c8-b21f6485d760@github.com>

On Mon, 26 Sep 2022 02:49:36 GMT, SWinxy <duke at openjdk.org> wrote:

> Appends: `, copying the array contents of {@code xpoints} and {@code ypoints}` to specify that the arrays in the constructor are explicitly copied.

The projects page on openjdk.org says that two integrated PRs are required, but I only have one and I fear that I will waste Mark Reinhold's time asking for author permissions without meeting the criteria. I was hoping these two doc issues were small enough to get me there, but alas. And I agree that asking for others to be my proxy isn't a great balance--it sucks for them and sucks for me. I guess I'll find some other fixes in the meantime...

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

PR: https://git.openjdk.org/jdk/pull/10418